Messages in this thread | | | Date | Sun, 27 Oct 2013 17:49:24 -0700 | From | Jim Hill <> | Subject | Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes: line |
| |
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?
| |