Re: [lmi] Help combining git branches

[Vadim Zeitlin]

On Thu, 1 Oct 2020 13:35:05 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 2020-09-29 17:53, Vadim Zeitlin wrote:
GC> > On Tue, 29 Sep 2020 15:55:36 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
[...]
GC> > GC> The first of about forty commits came through okay, but the second
GC> > GC> failed, and all I have to work with is a monolithic patch file.
GC> > 
GC> >  No, it's just Git not being very helpful (although I admit I never
GC> > realized how confusing this hint could be before reading your message).
GC> That's exactly what I was missing, because
GC>   "hint: Use 'git am --show-current-patch' to see the failed patch"
GC> seemed to be suggesting that I didn't have the option of editing
GC> the individual files to resolve the conflicts.

 Yes, I do see how it could be seen like this. But I can also tell you with
certainty that this wasn't the intention of the person who wrote this
message: they just meant that you _can_ have a look at this patch (which is
also present under .git/rebase directory, but --show-current-patch is more
convenient than going hunting for it there, which is, I guess, another
reason for having this hint) in addition to the files in the working
directory to see what kind of change is being applied. And this can be
indeed quite useful, especially if you're not sure that are you merging or
rebasing where, i.e. if you're a bit lost in the middle of the process. But
it absolutely doesn't, and wasn't meant to, replace looking at the actual
files with the merge conflicts.

GC> >  If you open ihs_avsolve.cpp in Vim, for example, and search for
GC> > "^[<=>]\{7\}\( \|$\)" (without quotes),
GC> 
GC> ...because that's so handy. I had been searching for "<<<", and never
GC> thought of searching for all the markers at once--which, at least with
GC> my ~/.vimrc, causes them all to be highlighted, making the work easier.

 Exactly, I also have 'hls' on (and '\' to turn it off because sometimes
too much of a good thing can be annoying, especially if I manage to search
by something matching every character of the file...) and I have this
string in my 'f register, so I can search for it by doing "/<C-R>f<C-M>".

GC> > GC> $git pull --no-ff
GC> > 
GC> >  FWIW I still recommend not using pull to do merges implicitly. I.e.
GC> > instead of the above I'd do
GC> > 
GC> >   $ git fetch
GC> >   $ git merge origin/valyuta/002
GC> > 
GC> > which is exactly the same thing, but more clear.
GC> 
GC> Okay, here, you recommend an alternative to 'git pull --no-ff'.
GC> I feel certain that you've told me that before,

 I did, but there are 2 different slightly things here: the thing I mostly
carped about was to avoid implicit merges done by git-pull by default,
because this is very surprising and usually unwanted (so much so that I
think this is changing in the latest versions of Git, i.e. they're slowly
transitioning to not doing this by default any more). Here you're telling
git-pull to make a merge explicitly, and there is nothing really wrong with
this, but I just think that it's more clear to use git-merge for merging
rather than git-pull.

GC> |   # Update the local source tree (where I make my own changes) when
GC> |   # someone else has committed a change to the online master repo.
GC> |
GC> | git remote -v update
GC> | git pull
GC> |
GC> |   # If that yields "fatal: Not possible to fast-forward, aborting":
GC> |
GC> | git pull --rebase
GC> 
GC> Would you recommend the same fetch-and-merge as an alternative
GC> to 'git pull --rebase' there?

 This really depends on whether you want to merge or rebase. Usually rebase
is more appropriate, i.e. you just want to have your current commits, not
pushed yet, on top of the latest origin/master (or whatever is the upstream
of your current branch). But if you actually do want to merge, then I'd
indeed recommend using git-merge, if only for clarify.

 Regards,
VZ

pgpxwiTZ3wkDm.pgp
Description: PGP signature