From: "Junio C Hamano" <gits...@pobox.com>
"Philip Oakley" <philipoak...@iee.org> writes:
From: "Junio C Hamano" <gits...@pobox.com>
John Keeping <j...@keeping.me.uk> writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
...
Peff already covered (1)---it is highly doubtful that a merge is
"almost always wrong". In fact, if that _were_ the case, we should
simply be defaulting to rebase, not failing the command and asking
between merge and rebase like jc/pull-training-wheel topic did.
We simply do not know what the user wants, as it heavily depends on
the project, so we ask the user to choose one (and stick to it).
We only offer a limited list. It won't be sufficient for all use
cases. It wasn't for me.
Very interesting. Tell us more.
What I do now is avoid Pull because of the hassle of fixing anything
that may have gone wrong.
Instead I now use a 'git fetch', followed by a 'push . (+etc:etc)' once
I understand what I've got, or what I need to do different if wasn't a
simple fast forward 'pull'.
When "git pull" stops because what was fetched in FETCH_HEAD does
not fast-forward, then what did _you_ do (and with the knowledge you
currently have, what would you do)? In a single project, would you
choose to sometimes rebase and sometimes merge, and if so, what is
the choice depend on? "When I am on these selected branches, I want
to merge, but on other branches I want to rebase?"
In my case I have two home machines (main Windows machine and an
occasional Linux laptop, though not directly networked together) and
github as my level group, and have MSysGit and git/git (on github) as
true upstreams, though they haven't been named that way [Aside: we are
short of a good name for one's 'across-stream server' that one uses for
backup/transfer such as github].
I general now use a forced update to bring my local machine up to date
relative to whatever is upstream or on my across stream server, such as
when transferring development from one machine to the other (where
overwrite is the desired action) - e.g. when testing on the Linux laptop
and a few corrections, before patch preparation on the Windows machine
(different levels of familiarity).
I occasionally will need to rebase my topic onto an updated git/master
or git/pu if it is to be submitted upstream (patches to the list) or if
upstream has moved, though I want to choose where I will rebase the
topic onto. I don't need merging in that scenario, as I see those via
your git repo ;-)
It's not clear to me that a single default that uses a merge or rebase,
without a 'stop if' criteria would be of any help in my situation.
My thoughts are that the options on a fetch-pull are for the branch to
be:
* Overwritte (--force) (i.e. a conflict scenario)
* Stop if not-ff (conflict scenario, this patch series)
* rebase existing onto tracked [not a conflict in terms of initiation]
* merge existing into tracked [not a conflict in terms of initiation]
* fast-forward (bring tracked onto existing) [desired]
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
