Re: Signal conflict on merging metadata-differing patches

[Greg KH]

On Mon, Nov 18, 2019 at 07:45:23PM +0100, Eugeniu Rosca wrote:
> On Mon, Nov 18, 2019 at 06:35:17PM +0100, Greg KH wrote:
> > On Mon, Nov 18, 2019 at 06:29:17PM +0100, Eugeniu Rosca wrote:
> > > Dear Git community,
> > > 
> > > Due to high inflow of patches which Linux maintainers carry on their
> > > shoulders and due to occasionally intricate relationships between
> > > consecutive revisions of the same series, it may [1] happen that two
> > > distinct revisions of the same patch (differing only/mostly in
> > > metadata, e.g. Author's time-stamp and commit description) may end up
> > > being merged on the same branch, without git to complain about that.
> > 
> > Why would git complain about that?
> 
> This would help those performing the merge identify and (if needed)
> avoid having several slightly different patches on the same branch.

The patches were not on the same branch to start with, they ended up on
two different branches that got merged together at some point in time
later on.

This happens all the time in kernel development :)

> > > Is there any "git merge" flag available off-the-shelf which (if used)
> > > would signal such situations?
> > 
> > I don't understand what you are looking for here.  Two different
> > versions of the patch were merged to different branches and then merged
> > together, and git did the right thing with the resolution of the code.
> 
> I personally care about commit metadata (i.e. Author's/Committer's names
> and timestamps, as well as commit description) as much as (and sometimes
> more than) the code contents of the patch.
> 
> If I am given multiple patches which perform the same code changes, but
> provide different descriptions, this _already_ generates potential work
> on my plate, since I have to make sense of those differences when I
> stumble upon them. Which patch do I recommend to the customer (who,
> let's say, still lives on the older v4.14 LTS), if I am asked to?

Welcome to my life :)

As I said above, this happens quite frequently, and honestly, I just
live with it.  Look at the kernel's DRM branch for the main abusers of
this, they cherry-pick patches from their local tree to a tree to send
to Linus today, with the sha1 in the commit message.  That means that
Linus ends up with a commit referencing a sha1 that will not show up in
his tree until sometime in the _future_.

It causes havoc with my scripts and I hate it.

But, it makes things easier for the developers and maintainers of that
subsystem and in the end, that's what really matters.  Stable and
backports should almost never cause developers any problems or extra
work as that is not their responsibility.

> Why should I (or anybody else) spend time doing research at all, if this
> can be avoided by just passing an additional option to "git merge"?
> 
> It is the most basic requirement I can think of that the maintainers
> select the _latest_ version of a patch series, without intertwining it
> with a superseded version.

I really don't understand what you expect to have happen here.

Look at the drm tree again, what should git do sometime in the future
when the same "logical change" gets merged into Linus's tree.  I think
it should do what it does today, handle the merge of the code changes
just fine and allow for perfect representation at any point in time what
the tree looked like if you check it out then.

What should git do instead?

> > What more can it do here?
> 
> Currently Git says nothing in below merge scenarios (all of them are
> conflict-less successful merges):
>  - Merge two commits which perform identical code changes but have
>    different metadata
>  - Merge commit "A" and commits ("B", "C", "D"), the latter being
>    subsets of "A"
> 
> I don't advocate for "git merge" to fail in the above scenarios. No.
> I just say that Git could likely detect such scenarios and help people
> like you not pushing v2 and v5 of the same patch into the main tree.

But what should it do in either of those above situations?  Fail the
merge?  No, that's not ok as those different branches were just fine on
their own and I will never expect them to be rebased/rewritten just for
something like this.  That's crazy.

thanks,

greg k-h