pijul_org / pijul

#369 Fork without switching branch

Opened by porky11, on March 16, 2019
porky11 commented on March 16, 2019

Being able to create a fork without creating a new branch seems useful. It's the default behavior of git (git branch). This may be useful to create temporary copies of the current state.

iantownsend added a patch:
Add option to fork without switching branches by iantownsend, created on March 18, 2019

iantownsend commented on March 18, 2019


This patch adds the option --stay to pijul fork to not checkout the new branch. (I can't add patches to the discussion the proper way since that seems to crash the Nest.)

porky11 commented on March 25, 2019

cool you already implemented it. I hope, it will be merged/accepted.

pmeunier commented on March 25, 2019

Hi! I think this is cool, but for an option like this I believe the default behaviour of Git would be less disruptive for users. What do you think?

iantownsend commented on March 26, 2019

As long as Pijul gives the user proper feedback, I think that's a good idea.

lthms added tag
on March 27, 2019
pmeunier commented on March 27, 2019

Actually, I don't know what to do, because I don't know how useful branches will be in Pijul.

Creating a clone of the current version is quite useful indeed, and definitely harder to do with patches than with commits. For other purposes I don't know, Pijul's branches are essentially equivalent to Git's long-lived branches, so I guess it doesn't matter so much?

There are two things to consider in my opinion:

  • Having a set of basic commands that "feel atomic" is important for a tool like Pijul. The theory is so simple that we have the potential to achieve that.

  • One reason I like the current behaviour is complexity: "git-like fork" + "checkout" diffs the repository, and might rewrite parts of it, whereas "fork+checkout" in a single command doesn't need that. But I guess that's secondary.

Anyway, this can probably be changed later I guess. Sorry for being picky.

FlorentBecker commented on May 14, 2019

"git checkout -b" is the atomic "fork + checkout", so there's a precedent in git for having both behaviors. I think we want "checkout -b" rather than "branch" as the default behavior as it's more forgiving in case of an error (if you get confused, you end up wrongly adding patches to a new, private branch, rather than to an old, public one).

FlorentBecker commented on May 14, 2019

"git checkout -b" does discard unrecorded changes, I don't think pijul fork should: --stay allows the user control on which branch the unrecorded changes go (in other words, I think the current behavior is fine)