Re: [lmi] Did I resolve this git issue correctly?

[Vadim Zeitlin]

On Wed, 14 Feb 2018 00:13:06 +0000 Greg Chicares <address@hidden> wrote:

GC> Not remembering this prior discussion, I did:
GC> 
GC> /opt/lmi/src/lmi[1]$git pull

 I strongly advise you to do

        $ git config pull.ff only

to change the default "git pull" behaviour to avoid making a merge by
default, this is almost never what you want to do and even if recovering
from it is not that difficult, it's better to avoid finding yourself in
this situation in the first place.

 You might want to set pull.rebase to true instead if you want to always
perform the rebase automatically, but I think that, at least in the
beginning, it's better to do everything explicitly and I also don't feel
comfortable with modifying the default command behaviour in the sense of
making it do something different than what it does by default (even if this
default is very unfortunate).

GC> Next, this seemed like a good idea (was it?)...

 Yes -- you don't want to merge, after all.

GC> /opt/lmi/src/lmi[128]$git merge --abort
GC> /opt/lmi/src/lmi[0]$git status
GC> On branch master
GC> Your branch and 'origin/master' have diverged,
GC> and have 1 and 3 different commits each, respectively.
GC>   (use "git pull" to merge the remote branch into yours)
GC> Untracked files:
GC>   (use "git add <file>..." to include in what will be committed)
GC> 
GC>         .financial.hpp.swp
GC>         .ledger_invariant.cpp.swp
GC>         .ledger_xml_io.cpp.swp

 BTW, I also recommend adding a line with ".*.sw?" to your
~/config/git/ignore (personally I use ~/.gitignore, but this requires
setting core.excludesfile to this location explicitly which is probably not
worth doing if you aren't already used to having this file in that
location).

GC> Well, I figure that at this point only my local copy is at risk, so...
GC> 
GC> /opt/lmi/src/lmi[0]$git pull --rebase

 Yes, this is indeed (and almost always) the right thing to do.

GC> [REDACTED VALIDATION OF CREDENTIALS]

 BTW, why are any credentials involved when working with the local
repository? This looks strange to me.

GC> So should I 'git push' now? Stop me before I destroy something...

 You will have to use --force with "git push" to have a chance of
destroying anything (and I don't even know if this will work or if Savannah
forbids force pushes), so please go ahead and do push, it is safe.

GC> > [...] If you'd just like a recipe for
GC> > doing what I consider to be the right thing to do, the next time you fail
GC> > to push something because your local branch is behind master, just do "git
GC> > pull --rebase" instead of "git pull". This will do exactly what you
GC> > expected to happen, i.e. it will "yank your changes", fast-forward your
GC> > local master to the remote master and then "stuff your changes back" 
(which
GC> > will change their SHA-1s, of course).
GC> I'll try to remember that.

 To repeat, you can configure git to do this by default, but IMHO this is
not necessarily the best idea. Preventing pull from creating (real) merges
by default using the first command in this email definitely is though.

 Regards,
VZ