Re: irt: Re: Core statement on version control systems

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Dec 09, 2025 at 11:10:06AM -0500, Andrew Cagney wrote:
 > >  > >  :: - storing the identity of long-running branches in the history
 > >  > >  :
 > >  > >  : Can you expand on this?
 > >  > >
 > >  > > In git, you can find the merge commit, and it has two ancestors, and
 > >  > > there's a diamond in the commit graph. But you can't tell from the
 > >  > > repository metadata which side of the diamond was the trunk and which
 > >  > > was the development branch. You have to read and interpret the commit
 > >  > > messages. You also can't tell which development branch it was.
 > >  >
 > >  > I would just say that's what tags are for.  :-)
 > >
 > > You can, but it's messy and you shouldn't have to.
 > 
 > It's trivial.  It's the first hash.

Except when it's not. It's nice to think that nobody will ever stand
on the wrong side by accdent when doing a merge; they will. Then it
comes out backward. Also, some perfectly reasonable commit patterns
produce what look like backward merges. For example, if you sync with
head and then merge into master without remembering to commit
something else on your branch first, the merge into master disappears
and the only remaining merge is the "wrong" way around.

-- 
David A. Holland
dholland%netbsd.org@localhost