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

[Vadim Zeitlin]

On Sun, 20 Sep 2020 22:37:51 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-09-20 21:01, Vadim Zeitlin wrote:
GC> > On Sun, 20 Sep 2020 20:32:50 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
[...snipping all things to which I don't have anything to add...]
GC> -  # to transplant already-pushed commits to a new branch
GC> +  # to transplant unpushed commits to a new branch

 OK, thanks for confirming this.

GC>  git branch odd/foo
GC>  git reset --keep origin/master

 And, FWIW, these commands are just fine for performing this task, i.e.
they do correspond to the updated comment.

GC>    # ...and don't ever rebase that new branch
GC> 
GC> In addition to that commentary change, should I also do the following?
GC> 
GC> -  # ...and don't ever rebase that new branch
GC> +  git push --set-upstream origin odd/foo

 This change has 2 parts:

1. Remove the comment: I think it's a bit too drastic, it might be useful
   to note that you shouldn't rebase this branch on master without using
   either an explicit branch name or --no-fork-point explicitly (you don't
   have to document both ways, just choose one you like best and it will
   be enough).

2. Push setting the upstream: this is obviously a good idea if you will
   always, or often, push such branches, but you don't really have to do
   it, so it's somewhat orthogonal to the main theme of this snippet.

GC> But perhaps a wholesale replacement of that little block is wanted,
GC> so let me state exactly what I'm trying to accomplish. Sometimes
GC> when I'm on 'master' I'll make a few commits, and then decide that
GC> those commits should be on a brand-new branch instead, leaving
GC> 'master' as it was before any of those (unpushed) commits. With
GC> sufficient forethought, I might have anticipated that before
GC> committing anything, but I didn't; and I'm sure git provides a way
GC> for me to make it look like I had foreseen that.

 Well, no, not directly, i.e. not with a single command. But 2 commands is
not too bad for such a relatively uncommon operation (even though I admit I
had to do this too, because I hadn't been sufficiently farsighted).

GC> But the discussants debate about the 'git reset' part goes way
GC> over my head.

 This command is complicated because it does different things depending on
its options, but in this particular case it's only used to reset your local
branch (master) to the state of origin/master, which is not really magic at
all. I.e. previously you were in advance compared to origin/master, but
after reset your master is exactly the same as origin/master.

GC> What should the recipe be? I'm thinking of these
GC> three lines:
GC> 
GC> [1]  git branch odd/foo
GC> [2]  git reset --keep origin/master
GC> [3]  git push --set-upstream origin odd/foo
GC> 
GC> [1] I'm pretty sure of this, but maybe I'm missing some option.
GC> For a branch like valyuta/002 that is intended to persist for
GC> a long time and be modified many times, would
GC>   git branch --track odd/foo
GC> be better? Would
GC>   git branch --set-upstream-to=origin/odd/foo odd/foo
GC> be better (though repeating the new branch name seems icky),
GC> or does
GC>   git branch --track odd/foo
GC> do the same thing, automatically setting upstream to
GC> the most sensible thing ("origin/new/branch-name"), which
GC> is what I believe I'd always want?

 No, this command sets the upstream to the current branch, which is not
what you want in this case. Moreover, you can't use --set-upstream-to
neither because the remote branch doesn't exist yet. You could, of course,
create the remote branch first if you really wanted, but this doesn't seem
to have any advantages compared to just using "-u" with "git push" when you
do it on the new branch the first time, so I'd recommend to keep things
simple and just do it like this.

 I.e. for [1] you should use just the command shown above, which creates a
branch corresponding to your current state, without any upstream/tracking
branch, because there is nothing for it to track yet.

GC> [2] This git-reset command seems to be the crux of that
GC> online discussion, which I still fail to understand.
GC> Out of fear that "git reset --hard" would obliterate my
GC> latest commits, I chose "git reset --keep".

 Yes, --keep is safe, as it will fail if there are any local changes, while
--hard would gleefully overwrite them. As I had already said in the past,
but I think it's worth repeating it, "git reset --hard" is one of the very
few ways in which you can irrevocably lose your changes in Git.

GC> What I want,
GC> of course, is that those latest commits be preserved in
GC> odd/foo but removed from master. Reading the git-reset
GC> documentation leads me to think that '--keep' is exactly
GC> right in this case, but I worry that more online
GC> discussions suggest '--hard' and '--keep' seems exotic.

 I think --keep is newer. Also, sometimes you really do want to use --hard,
if you've made a mess in your local copy and *want* to destroy it utterly.
Basically, I think it's just simpler for people giving advice on Internet
to tell someone to use "git reset --hard" rather than tell them to use
"--keep" and then answer their questions if it failed because of some
changes in the local copy.

GC> [3] Is '--set-upstream' unnecessary here if [1] specifies
GC> '--track'?

 To repeat, [1] shouldn't use --track, as you don't want to track your
current branch and you can't track the not yet existent remote branch.

GC> Tying all those conjectures together, should the recipe
GC> ideally be as follows?
GC> 
GC>   git branch --track odd/foo
GC>   git reset --keep origin/master
GC>   git push origin odd/foo

 No, the initial form of the recipe was correct.

GC> My plan instead is to let 'valyuta' evolve until I'm
GC> satisfied with it, and then construct and commit (to
GC> master) the series of changes that I would have made
GC> if I had thought through everything first, perfectly.
GC> So Athena still emerges fully mature from Zeus's skull,
GC> but the public doesn't see how sausages are made.

 This is a pretty common strategy with which Git helps a lot and I do it
all the time. It usually does involve some amount of merge conflicts
resolution as I do a lot of interactive rebases to put things in just the
right order, but it usually doesn't take much time. However if you plan to
spend time on polishing your commits history often in the future, I'd like
to reiterate my suggestion to look into using Vim Fugitive plugin as merge
resolution, or even just diff/git-add-p replacement tool, it's really quite
invaluable.

 But in the meanwhile, good luck and please let me know if you have any
questions!
VZ

pgpWePqpjigK6.pgp
Description: PGP signature