Re: Signal conflict on merging metadata-differing patches
On Mon, Nov 18, 2019 at 07:45:23PM +0100, Eugeniu Rosca wrote:
Show 15 quoted lines
> 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 :)
Show 16 quoted lines
> > > 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.
Show 6 quoted lines
> 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?
Show 12 quoted lines
> > 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
