On Mon, Oct 21, 2013 at 9:38 AM, Ondřej Bílka <nel...@seznam.cz> wrote:
> On Mon, Oct 21, 2013 at 09:35:07AM -0700, Shawn Pearce wrote:
>> On Mon, Oct 21, 2013 at 8:41 AM,  <james.mo...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to