Re: RFE: support change-id generation natively

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

 



On Monday, October 21, 2013 05:41:59 PM james.moger@xxxxxxxxxxx wrote:
> The change-id is exactly like a commit-id, it is an SHA-1 value, but it
> is a constant embedded in the commit message.

As I understand, a UUID could also be used for the same purbose as the change-
id. How is the change-id generated by the way? Would it be a good english name 
to call it enduring commit identifier?

I had an usage example for such identifiers last week while helping to rebase 
and merge a few too long standing feature branches. After a while we noticed, 
that a few commits where already cherry-picked in a slightly different form and 
with different commit message to the integration branch. If those commit had 
enduring identifiers, it would have been easier to spot this.

Git already has functionality to identify commits that have already been 
cherry-picked or merged in a branch and thus skips them in a rebase. Could 
this functionality benefit from an enduring commit identifier?

Best regards, Thomas Koch
--
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]