[lkml]   [2013]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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^!`
local parents
local parent
local p2
for parent; do
p2="$p2 -p `git commit-tree --reference $parent`"
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?

 \ /
  Last update: 2013-10-28 02:01    [W:0.138 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site