Re: [lmi] [lmi-commits] valyuta/002 18ab8be 5/5: Oops

[Vadim Zeitlin]

On Sun, 20 Sep 2020 20:32:50 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Two points:
GC> 
GC> (1) I attempted it this way, without even thinking...
GC> 
GC>   /opt/lmi/src/lmi[0]$git rebase --interactive 
GC>   There is no tracking information for the current branch.
GC>   Please specify which branch you want to rebase against.
GC>   See git-rebase(1) for details.
GC>       git rebase '<branch>'
GC>   If you wish to set tracking information for this branch you can do so 
with:
GC>       git branch --set-upstream-to=<remote>/<branch> valyuta/002
GC> 
GC> ...and the '--set-upstream-to' documentation seemed
GC> abstruse enough to persuade me to sidestep the issue.

 I didn't look at the documentation, but the concept is rather simple, as
usual it's just complicated by using Git-specific terminology: "tracking"
or "upstream" branch is just the remote branch (i.e. the branch on a
machine you push to/pull from) that your local branch corresponds to.
Typically, when pushing your branch to the server the first time you would
use "--set-upstream" (short: "-u") option to also set the branch you're
pushing to as the upstream branch, e.g. I typically do

        $ git push -u origin HEAD

from my work branch. If you didn't do it when pushing the first time, you
can do it when pushing the next time or without pushing at all by doing
what Git suggests above, i.e.

        $ git branch --set-upstream-to=origin/valyuta/002

 Once this is done, the upstream branch will be used for several operations
by default, including pushing, pulling or rebasing. But that's all it is:
just a convenient default, and if you don't want to set it, you'd just have
to specify the remote branch manually every time instead. E.g. in this case
you could have done the above and then "git rebase -i" without arguments
would have worked, but you could also do "git rebase -i origin/valyuta/002"
explicitly directly.


GC> (2) More important: is it really safe?

 It's definitely safe to rewrite any commits that haven't been pushed
anywhere, as nobody is aware of their existence anyhow and so can't
reference their SHA-1s (unless they've discovered a working quantum
computer). The danger of rebasing is that it changes the hashes of the
existing commits, making them different from the one recorded elsewhere.
But if there are no references to a commit anywhere else, you're completely
free to rewrite it as much as you want.

GC> I wrote this in 'gwc/develop1.txt':
GC> 
GC>     # to transplant already-pushed commits to a new branch
GC>   git branch odd/foo
GC>   git reset --keep origin/master
GC>     # ...and don't ever rebase that new branch

 I don't think this does what the comments suggest... I think the comments
are wrong, because they don't make much sense: why would you want to
transplant already pushed commits anywhere? But I could be missing
something here, so could you please explain what exactly are you trying to
do? My current best guess is that you meant "to transplant changes already
committed to master (but _not_ pushed yet) to a new branch", but I'm afraid
of second-guessing you wrongly.

GC> IIRC, I was just trying to distill a copy-and-paste-able recipe from
GC> this discussion:
GC> 
GC> 
https://stackoverflow.com/questions/1628563/move-the-most-recent-commits-to-a-new-branch-with-git
GC> 
GC> and was alarmed by:
GC> 
GC> | WARNING: With Git version 2.0 and later, if you later git rebase the new
GC> | branch upon the original (master) branch, you may need an explicit
GC> | --no-fork-point option during the rebase to avoid losing the carried-over
GC> | commits. Having branch.autosetuprebase always set makes this more likely.
GC> 
GC> | Most previous answers are dangerously wrong!
GC> |
GC> | Do NOT do this:
GC> |
GC> | git branch -t newbranch
GC> | git reset --hard HEAD~3
GC> | git checkout newbranch
GC> |
GC> | As the next time you run git rebase (or git pull --rebase) those 3
GC> | commits would be silently discarded from newbranch!

 This is an interesting point and one I wasn't actually aware about, so
thanks for letting me know. However it isn't really relevant here: first of
all, you hadn't done any "git reset" on master after forking valyuta/002
from it, AFAIK. Second, you're not rebasing on master anyhow (this would be
bad as it would change the hashes of all commits already pushed to
origin/valyuta/002), so you're not affected by this issue. Third, according
to my git-rebase(1):

        If either <upstream> or --root is given on the command line, then
        the default is --no-fork-point

so if you specify the <upstream> to rebase upon explicitly, the problem
can't happen anyhow, and it's probably a good practice to be explicit for
all non-interactive rebases unless you're absolutely sure what you're
doing.


GC> So should I just
GC>   git branch --set-upstream-to= valyuta/002

 Note that you need to use --set-upstream-to=origin/valyuta/002 here, you
can't set a branch as its own upstream (and Git will just ignore your
attempt to do it if you try).

GC> or, what seems less arcane to me, when I next push, do:
GC>   git push --set-upstream origin valyuta/002
GC> ?

 There is no danger whatsoever in running either of those commands. And if
you do run the first one, then you could just do "git push" the next time
you push instead of spelling out where are you pushing and what.

 Hope this helps!
VZ

pgp8OmywuIqrz.pgp
Description: PGP signature