git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and

From
Junio C Hamano <junkio@cox.net>
Date
Apr 30, 2006, 23:19 UTC
Message-ID
<7vfyjuwt0v.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<e32kkf$amc$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
Show 14 quoted lines
>>> 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"
        
Previous: Jakub NarebskiNext: Junio C Hamano
Message 9 of 16 in “Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and”
  1. linux@horizon.comApr 29, 2006
  2. Linus TorvaldsApr 29, 2006
  3. Jakub NarebskiApr 29, 2006
  4. Junio C HamanoApr 29, 2006
  5. Jakub NarebskiApr 29, 2006
  6. Junio C HamanoApr 29, 2006
  7. Jakub NarebskiApr 29, 2006
  8. Jakub NarebskiApr 30, 2006
  9. Junio C HamanoApr 30, 2006
  10. Junio C HamanoMay 1, 2006
  11. Sam VilainMay 1, 2006
  12. Jakub NarebskiMay 1, 2006
  13. Junio C HamanoMay 1, 2006
  14. Sam VilainMay 2, 2006
  15. Martin LanghoffMay 2, 2006
  16. Sam VilainMay 1, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.