Re: Git haas gone wild (Rust), freebsd-update

On Sat, Sep 20, 2025 at 17:18:01 +0300, Vadim Goncharov wrote:
> On Mon, 15 Sep 2025 21:12:25 -0400
> Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:
...
> > Suppose there is a repo on a server and two developers clone it.  Then, one
> > dev creates a series of commits, and pushes them as drafts to the server.
> > The other dev pulls the series from the server, modifies one of the commits
> 
> What is "modifies one of the commits"? Amend due to mistake? If not, then why?

The idea is that while a change is being created, there are valid reasons
for rewriting of the commit.  Mistakes happen (wrong author name/email,
typos in commit description, missed code changes in the content, etc.) but,
importantly, review feedback often amounts to needing to modify the
work-in-progress commit.  These kind of history rewrites are legitimate and
should be made easy.  Once the commit is part of the "official" repo of the
project, rewrites are undesirable.

In hg, each commit is in one of three phases: secret, draft, or public.  In
short, only secret and draft commits can be rewritten.  (I wrote a blog post
a while back that describes the 3 phases in more detail:
https://blahg.josefsipek.net/?p=583)

So, when I said 'pushes them as drafts' in the example in my previous email,
I was suggesting that the two developers are collaborating on the series of
commits.  They want to collectively rewrite the series until it is ready to
be pushed to the "official" repo.

> > in the middle of the series, and pushes the result back to the server.
> > (*Not* a force-push because the server knows that the old and new commits
> > are related!)  Meanwhile, the first dev continued tweaking the series.
> > Sooner or later, the first dev will want to combine his modifications with
> > what the second dev pushed.
> > 
> > (The "same repo" I referred to in my previous email is the server repo in
> > this example.)
> > 
> > With git, this kind of rewriting results in force-pushes and awful headaches
> > and/or out-of-band mutual exclusion/coordination that the devs have to do.
> 
> Sounds like these developers for some reason did not used branches, while they
> had to. That is not a normal workflow, then.

If the developers are trying to collaborate on the same series, branching
won't help since they are trying to work on the same "branch".

> > With hg's changeset evolution, hg knows how each commit evolved (commit abc
> > turned into commit def for reason ghi) and it can use this second order DAG
> > to almost always do the right thing.  In handful of instances when it can't
> > resolve it automatically, it still gives the user the second-order DAG
> > information about how the situation happened.  (Compared to git's "here are
> > two piles of commits, enjoy" approach.)
> > 
> > 
> > Here's an example output from hg showing a portion of this second-order DAG
> > for a commit I worked on for an unrelated project (slightly trimmed for
> > brevity).  
> > 
> > $ hg obslog -r e6dd6779c419
> > o  e6dd6779c419 (8571) Document HLQ0 file format
> > |    rebased(parent) from 5943a3e1932e using histedit by Josef 'Jeff' Sipek
> > <jeffpc@josefsipek.net> (Sat May 10 11:21:02 2025 -0400) |
> > x  5943a3e1932e (8570) Document HLQ0 file format
> > |    rewritten(description, content) from 6fa0a1a05747 using amend by Josef
> > 'Jeff' Sipek <jeffpc@josefsipek.net> (Sat May 10 11:19:42 2025 -0400) |
> > x  6fa0a1a05747 (8569) WIP: Document HLQ0 file format
> > |    rebased(parent) from 32d556ef2864 using rebase by Josef 'Jeff' Sipek
> > <jeffpc@josefsipek.net> (Sat May 10 11:17:38 2025 -0400) ...
> > x  764a6f9cc777 (7549) WIP: Document HLQ0 file format
> > |    split(description, date, parent, content) from fabfad0ef96a using split
> > by Josef 'Jeff' Sipek <jeffpc@josefsipek.net> (Mon Aug 05 20:20:50 2024
> > -0400) | x  fabfad0ef96a
> > |    amended(content) from 607546bdae0f using amend by Josef 'Jeff' Sipek
> > <jeffpc@josefsipek.net> (Mon Aug 05 20:19:05 2024 -0400) |
> > x  607546bdae0f
> 
> I did not work with hg so don't know - are those comments like "rebase" just
> comments, or it is recorded more usably in artifact format and actually used?

The rebased/rewritten/split/amended strings are tokens that indicate the
operation that rewrote the commit.  The stuff in () right after indicates
what part of the commit was modified.  Both the operation and the parts
modified are automatically determined and logged by hg.  For example, the
'amended' entry was generated when I ran something like:

$ hg amend

Much like the equivalent `git commit -a --amend --no-edit` would do, it took
the contents of the existing commit (607546bdae0f) and the uncommitted
changes, and combined them into a new commit (764a6f9cc777).  Additionally,
it added the entry you see to the log of obsolete commits - noting that I
(the person running 'hg amend', who can be someone other than the commit
author) ran 'hg amend' and modified the commit's file contents ot Aug 5th
(regardless of what the commit's commit date was).

Jeff.