Jeff King <peff@xxxxxxxx> writes:
> I realize this has veered off into talking about an "update" command,
> and not necessarily "pull", but since there a lot of proposals floating
> around, I wanted to make one point: if we are going to do such a switch,
> let's please make it something the user explicitly turns on.
I mentioned "update" in an attempt to suggest some way to avoid
breaking "git pull" for people who do want to advane the history
with real work (i.e. not just following along with fast-forwarding).
A failed "git push" that suggests to pull first, which came from the
original "To emulate CVS workflow, you can pull, work, push, and if
the push fails, pull again and then push" in the early tutorial,
turns out to be very bad in the "trunk" centric worldview.
And I think the solution is to realize that we use "git pull" for
two fairly differnt workflows.
- You know you own the tip of the "trunk" (in the global view).
You merge from other people to advance the global world view in a
way that makes sense in the "first-parent chain is the trunk"
worldview. That is what "git pull [--no-ff]" was designed to do,
and it does it very well.
- You have some work of yours (either you committed directly, you
merged your own work done on a side branch, or you merged from
other people using "git pull") on top of a commit that used to be
at the tip of the global world. You want to make sure that
branch you are on is not missing what has happened while you are
not communicating with the outside world.
The problematic case is the latter, and by introducing a new command
to do that well (which is *not* just about "swapping the order of
the parents", by the way), updating the "leaf developer" section of
"Everyday Git" document and tutorials, and suggesting to use that
upon failed "git push", I think users would get a more pleasant
experience. And move "git pull" into "integrator" section, a
command that is not necessary for leaf developers.
I am not married to the name "update". I think the ideal behaviour
of that "leaf-developer" command would be something along the lines
of the following:
- If we can fast-forward, do so and we are done.
- Otherwise, we have a history of this shape:
----O
\
-----A----B----C
\
X---Y---Z
where A was where we forked, B was a merge the user made, C was a
commit the user directly made, and X, Y, and Z (some of them may
be merges) are the "trunk" history "git pull" would create a
merge M whose parents are <C Z>, which is wrong from the
"first-parent is the trunk" worldview.
But recording the merge to have parents <Z C> does not give us
"the first-parent is the trunk" worldview, in the presense of B.
We would prefer to end up with a history more like this:
-----A ----O
\ \
X---Y---Z---B'--C'
so that your work, your contribution with two commits of yours,
was to merge the work done on a side branch and then made one
commit directly on top of it.
Hence, I think the ideal behaviour of the new command is to
replay the first-parent history on top of the updated tip of your
upstream (which by the way is different from how "rebase
--preserve-merges" works; it is more like how J6t wanted to make
"rebase --preserve-merges" work, IIRC).
After that, you can attempt to push, and it may fail again (because
somebody has grown the shared history to have a child W of Z at the
tip), in which case exactly the same "git update" would attempt to
recreate a history of this shape:
-----A ----O
\ \
X---Y---Z---W---B"--C"
During a long transition period (essentially, waiting for the
current crop of documents and tutorials to die out), we will need
extra safety to prevent people, who merely wanted to bring their
branch up to date, from running "git pull", and I think the command
needs to:
- check which branch of what repository it is trying to pull;
- check which branch of what repository it is going to update if
"git push" is given;
- if they are the same, then you are attempting to update from your
upstream, so either warn or error out. If we are going to warn
but make a merge anyway, the warning message *must* come at the
very end of the output (and tell the user the way to recover is
to reset one away and run the other command).
Or something like that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html