Re: RFE: support change-id generation natively
- From
Shawn Pearce <spearce@spearce.org>
- Date
- Oct 21, 2013, 23:07 UTC
- Message-ID
- <CAJo=hJudnWqCTG=j_hQjZMzYarDTH5THZOEbftLjpwKUNusrEQ@mail.gmail.com>
- In-Reply-To
- <20131021163812.GA27125@domone.podge>
On Mon, Oct 21, 2013 at 9:38 AM, Ondřej Bílka <neleai@seznam.cz> wrote:
Show 27 quoted lines
> On Mon, Oct 21, 2013 at 09:35:07AM -0700, Shawn Pearce wrote: >> On Mon, Oct 21, 2013 at 8:41 AM, <james.moger@gitblit.com> 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. >> >> https://gerrit-review.googlesource.com/Documentation/user-changeid.html >> goes into more detail about these. >> >> > Commit-ids change all the time because of amend; change-ids are constant >> > and they are the key that links commit revisions to a discussion. >> >> In a mailing list based workflow, when an author revises a patch >> series and resends the new patches aren't linked to the old patches in >> a MUA, because the Message-Ids of the original versions were not >> preserved. Imagine if Git saved that original Message-Id somewhere and >> could properly write In-Reply-To headers so that attempt #2 for each >> patch replies to the end of the thread discussing attempt #1 of the >> same patch. In a 30 patch series. Gerrit does this with Change-Id. >> >> >> We briefly considered putting the Change-Id into the commit headers >> (e.g. below the optional encoding) but could not because `git commit` >> doesn't support this. So it went into the footer along with >> Signed-off-by provenance data, which is also not expressible in >> headers. > > What about adding that as Note?
If it was a note, the note would need to be updated every time the user updated their commit locally. So `git commit --amend` and `git rebase` (all forms) would be required to update the note with the new commit SHA-1 so the value isn't lost.
If it was a note, the author would also have to push their notes branch to the Gerrit server when they push their commits. This is likely to be forgotten, since its a different branch than the branch the user is working on. The server only needs notes for the new incoming commits, but the notes branch will probably bring all activity the author has been doing. So maybe the author should have one notes branch per topic branch. And clean up the notes branches after they delete their local topic branches. Etc.
notes are great, but they get messy. And back when Gerrit introduced support for Change-Id (more than 4 years ago) I don't think note support even existed. Or if it did, it was no where near as complete as it is today.