Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes: line

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/26/13 18:34, Josh Triplett wrote:
Linux Kernel ... "Fixes:" line ... containing an abbreviated commit hash

<!-- -->
This helps people (or automated tools) determine how far to backport

I beg pardon if I'm rehearsing an old debate, but it seems to me it would be better and worthwhile to bring more of git to bear by adding `reference` links as follows from considering this proposed sequence:

    #  ...G---B---...    history-with-bug-at-B

    Gprime=`git commit-tree --reference G`
    Bprime=`git commit-tree --reference B -p $Gprime`

    #   ...G---B---...   history-with-bug-at-B
    #      :   :         # <-- `:`'s are `reference` links
    #      G'--B'        $Bprime is a mergeable cherry-pick for B

`reference` links have no enforced semantics. Teach all current logic to ignore them (fetch doesn't fetch through them, fsck doesn't care, etc.). Elaborating some of the good parts:

* If the author and committer data are left untouched when `commit-tree`'s tree and message arguments are defaulted, as above, to the referenced commit's tree and message, the resulting commit is unique.

* Bullet-proof cherry-pick creation becomes easy and idempotent:

        git-make-cherry-pick() {
            local picked=$1
            set -- `git rev-list --parents $picked^!`
            shift
            local parents
            local parent
            local p2
            for parent; do
                    p2="$p2 -p `git commit-tree --reference $parent`"
            done
            git commit-tree --reference $picked $parents`
        }

* Which makes the created commit id a fully-implemented _change-id_ for the referenced commit:

        git merge $(git-make-cherry-pick $B)

can be done from anywhere, merge won't have to rely on patch-id's to detect cherry-picks done this way.

* A bugged commit gets fixed by fixing its reference commit and merging normally, worry-free:

        ...G---B ... -F   Merge fix X for a bug in B
           :   :     /
           G'--B'---X     X's commit message is the `Fixes:` equivalent

Bugfix commit X can be safely merged anywhere. Worst case, `git merge -s ours --no-commit X` and do whatever you would have done otherwise.

`merge` might usefully be updated to warn about merging from a commit with only a reference parent, I think merging from `G'` would probably be a mistake.

---
So, this is as far as I've gotten with this, is there reason to think it should or shouldn't be pursued?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]