Jakub Narebski <jnareb@xxxxxxxxx> writes:
>>> This is not any different from usual "parent" at all (but you
>>> have to think about it a bit to realize it).
>>
>> I would say that "prior" is not THAT different from usual "parent",
>> rather than it is not ANY different.
>>
>> My doubts about recording previous head of a "union" (pu-like) branch
>> is that for merge (e.g. 'pu' to 'next', cherrypick to/from 'pu', 'pu'
>> rebase) is that for merge algorithm all parents are equivalent, with
>> eventual exception of first which can be treated special ('ours').
>
> Additionally with "prior" (or at least some convention on which of parents
> is to prior head of "union (pu-like) branch) I think we could fast-forward
> such branches...
This is why I said you have to think about it a bit to realize
that the "prior" is not _ANY_ different from the ordinary parent
for something like "pu".
We can fast-forward if (1) you pulled from "pu" the last time,
and (2) you haven't added anything on top of it on your own, and
(3) you pull from "pu" again, if the previous "pu" (i.e. your
"pu") is a parent of the updated "pu". We do not need "prior"
for that. The old "pu" being _one_ _of_ the parents, not even
necessarily be the first one, would do just fine.
If you have built on top of the last "pu", obviously we do not
want to fast-forward with or without "prior".
Your doubts about the merge is also unfounded. The current "pu"
head is (against my own recommendation not to do so) a hydra
cap. It is a direct child of the previous "pu" that merges all
the leftover bits along with what was in 'next' when the commit
was made, so you could do something like this to experiment:
git branch test-1 pu^1
echo >>Makefile '# End of Makefile'
git commit -m 'build on top of previous "pu"' Makefile
git pull . pu ;# Merge whatever happened in "pu"
-
: 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