Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 26, 2006, 12:01 UTC
Message-ID: <e2nne7$4sp$1@sea.gmane.org>
In-Reply-To: <444F58B0.6090603@op5.se>

Andreas Ericsson wrote:

Show 17 quoted lines

> I've suggested before that arbitrary headers could be added to git
> commits by prefixing them with X- (preferrably followed by an abbrev of
> the porcelain name adding the note). This way it's easy to filter, you
> get the free ride, and porcelains can do whatever they want while core
> git can strip everything following the sequence "\nX-" up to and
> including the next newline.
> 
> This way you have only one special byte-sequence with special meaning
> that the plumbing has to know it should ignore, which is a lot more
> extensible (not to mention easier to code).
> 
> In addition, if those X- lines aren't included in the sha1 computation
> they can easily be removed and added to without affecting the ancestry
> chain. This would probably have quite a performance impact though.
> 
> That said, I don't think even "X-" headers is a very good idea. Perhaps
> i've just got poor imagination but I can't think of a good use for them.

Well, the "note" headers are just that, but instead of prefixing 'extra' headers with "X-" you prefix them with "note ".

I think that the "note" (or X-) headers should be included in calculating sha1, as the free-form of commit (the comment) is.

As to use: for now 'git cherry-pick' and 'git revert' records the commit picked or commit reverted in free form. It could be recorded in "note" header, or additionally as "note" header. 'git rebase' could also record the original commit e.g. as "note original <branchname> <sha1-of-commit>".

And it would be the place for Porcelain to record simple information which is of use to them, but usualy not interesting to user, so it would be better if it wouldn't pollute free-form/comment area.

The "prior" (for saving "pu"-like branches previous state) and "bind" (for managing subprojects) I think should be rather of "related"/"link" kind.

-- 
Jakub Narebski
Warsaw, Poland