On 20/09/2021 00:44, Ævar Arnfjörð Bjarmason wrote: > On Sun, Sep 19 2021, Jeff King wrote: > >> On Sat, Sep 18, 2021 at 03:18:47PM +0100, Philip Oakley wrote: >> >>> Is there a method within `git rev-list` to trim side branch merges where >>> the merge's tree is identical to the first parent's commit-tree? >>> [...] >>> From my reading of the `rev-list` manual this is similar to the <paths> >>> TREESAME capability, but without specifying any paths (maybe just `.` ?). >> Yes, I'd just do "git log ." for this. I don't think there's another way >> to trigger simplification. In try_to_simplify_commit(), we bail early >> unless revs->prune is set, and that is set only by the presence of >> pathspecs or by --simplify-by-decoration. >> >>> * Is there a proper term for the treesame condition of the commit-tree >>> (as recorded in the commit object)? >> In a one-parent commit, I'd just call it an empty commit. For a merge, >> it is really I'd probably call it an "ours" merge, since one obvious way >> to get there is with "git merge -s ours" (of course you can also just >> resolve all conflicts in favor of one parent). I don't know of another >> name (besides treesame, of course, but that generally implies a >> particular scope of interest given by a pathspec). > Isn't it a "theirs" merge, not "ours"? Per the description Philip has: > > In the Git-for Windows repository, the previous releases are > 'deadheaded' by merging with the upstream git, and simply taking the > upstream's tree unconditionally[...] In that sense, yes. From the gfw branch's perspective, the merge is 100% that of git/master. It provides an 'out-of-line' commit onto which the gfw patches can be rebased. It's almost identical to a ball-of-mud progressive (incremental) merge, but neatly refactored. > > I.e. if you're taking your tree unconditionally it's -s ours, but -s > theirs for theirs. Except of course for the small matter of us not > having a "-s theirs" yet. There used to be a `theirs` strategy but (IIRC) it was removed by Linus years ago (before I discovered git and it's ability to distribute control..). One thing that catches me, and I think others, is how the 'strategies' work. IIUC a merge will look at each line in the diff, and accept any change on either side that has no conflicts within the context zone. It's only when there are changes from both sides that the selection strategy kicks in. But it is difficult to describe, so it's easy to be confused. It doesn't look like this type of rebasing workflow for a multi-platform/product scenarios was considered at the time. [1-4] Either way, having a few clues (where to look in the code) to including a `--deadhead` history simplification is useful. > > I had a WIP patch a while ago for a "-s theirs -X N", for what sounds > like a similar use-case: > https://lore.kernel.org/git/87sh7sdtc1.fsf@xxxxxxxxxxxxxxxxxxx/ [1] https://stackoverflow.com/questions/173919/is-there-a-theirs-version-of-git-merge-s-ours [2] https://lore.kernel.org/git/alpine.DEB.1.00.0807290123300.2725@eeepc-johanness/ [3] https://lore.kernel.org/git/7vtzen7bul.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx/ [4] https://lore.kernel.org/git/xmqqmv5je412.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxxxxx/
