# [RFC] adding merge-node to parent lines in a commit 5 messages from 2005-05-15 to 2005-05-15. Participants: Sean, Junio C Hamano. Thread: https://gitlist.dev/t/636 ## Sean, 2005-05-15 21:22 Subject: [RFC] adding merge-node to parent lines in a commit Message-ID: <1282.10.10.10.24.1116192147.squirrel@linux1> URL: https://gitlist.dev/e/1282.10.10.10.24.1116192147.squirrel%40linux1 ``` Just a random thought presented for flamage... Would adding the merge node to each "parent" line in merge nodes be workable? parent SHA1-PARENT SHA1-MERGE-NODE It's not exactly clear cut I guess, especially in the case of multi-parent merges, but it would make descending the history slightly easier. It would let you look at any merge, and know exactly which commits were associated with that merge, without needing any repo-id or time information. This information is needed at the time of merge anyway, so recording it rather than leaving it to be calculated later makes some sense. Comments? Cheers, Sean ``` ## Junio C Hamano, 2005-05-15 21:30 Subject: Re: [RFC] adding merge-node to parent lines in a commit Message-ID: <7vfywoqira.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfywoqira.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <1282.10.10.10.24.1116192147.squirrel@linux1> ``` It is not clear to me ID of what object is being recorded as SHA1-MERGE-NODE in your proposal. Care to illustrate? ``` ## Sean, 2005-05-15 22:07 Subject: Re: [RFC] adding merge-node to parent lines in a commit Message-ID: <1441.10.10.10.24.1116194876.squirrel@linux1> URL: https://gitlist.dev/e/1441.10.10.10.24.1116194876.squirrel%40linux1 In-Reply-To: <7vfywoqira.fsf@assigned-by-dhcp.cox.net> ``` On Sun, May 15, 2005 5:30 pm, Junio C Hamano said: > It is not clear to me ID of what object is being recorded as > SHA1-MERGE-NODE in your proposal. Care to illustrate? Hey Junio, Yes, it's pretty basic unless i'm overlooking something: Rn---\ > Mn > Mn-1 Rn-1 | Rn-2 | Rn-3--/ Initial So for this particular case it's rather simple, the Rn merge node would have: parent Rn-1 (ommitted) parent Mn Rn-3 Essentially, you are recording in the merge commit the length of each branch that represents new commits that did not exist in this repository before this merge. But there are more complicated cases with multiple parent merges. What this would avoid is the need to calculate common_anscestor in routines like git-rev-list, because that information would already be stored. As far as I know this information is already available at merge time anyway, so recording it shouldn't be a burden. I'm not sure it buys you a ton out the other end, but perhaps it would be slightly easier to piece the merge history back together. Sean ``` ## Junio C Hamano, 2005-05-15 22:36 Subject: Re: [RFC] adding merge-node to parent lines in a commit Message-ID: <7v64xkqfqg.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v64xkqfqg.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <1441.10.10.10.24.1116194876.squirrel@linux1> ``` >>>>> "S" == Sean writes: S> Yes, it's pretty basic unless i'm overlooking something: Rn---\ Mn Mn-1 Rn-1 | Rn-2 | Rn-3--/ Initial S> So for this particular case it's rather simple, the Rn merge S> node would have: S> parent Rn-1 (ommitted) S> parent Mn Rn-3 Isn't that something you can obtain by scanning the parents and running merge-base across them without recording it in the commit? ``` ## Sean, 2005-05-15 22:47 Subject: Re: [RFC] adding merge-node to parent lines in a commit Message-ID: <1522.10.10.10.24.1116197263.squirrel@linux1> URL: https://gitlist.dev/e/1522.10.10.10.24.1116197263.squirrel%40linux1 In-Reply-To: <7v64xkqfqg.fsf@assigned-by-dhcp.cox.net> ``` On Sun, May 15, 2005 6:36 pm, Junio C Hamano said: >>>>>> "S" == Sean writes: > > S> Yes, it's pretty basic unless i'm overlooking something: > > Rn---\ > Mn > Mn-1 > Rn-1 | > Rn-2 | > Rn-3--/ > Initial > > S> So for this particular case it's rather simple, the Rn merge > S> node would have: > > S> parent Rn-1 (ommitted) > S> parent Mn Rn-3 > > Isn't that something you can obtain by scanning the parents and > running merge-base across them without recording it in the > commit? Yes it is, and i was mistaken to think it gave more information. It would shave some time off history traversal, but nothing else. Sean ```