[Ksummit-discuss] [TOPIC] Metadata addendum to git commit

[Christian Couder]

From: Takashi Iwai <tiwai at suse.de>
>
> At Tue, 20 May 2014 08:37:18 +0200 (CEST),
> Christian Couder wrote:
>> 
>> From: Takashi Iwai <tiwai at suse.de>
>> 
>> > We don't want to change the history at all.
>> 
>> What I understood is that you want to be able to bisect on a history
>> where many bugs that prevent testing can easily be fixed.
> 
> Well, the bisection is just an example where the extra metadata would
> help.  It's not the purpose itself.
> 
>> 
>> Using git replace, it can go like this:
>> 
>> - a developer learns that some part of the history can be fixed to
>>   bisect more easily by applying a patch,
>> 
>> - the developer recreates a part of the history where the patch has
>>   been applied (using git cherry-pick or git rebase -i for example)
>> 
>> - the developer uses git replace to create a replace ref so that the
>>   new part of the history is used instead of the old one
>> 
>> - the developer pushes this new replace ref to a common repo where
>>   replace refs are shared (this pushes the new part of the history
>>   too)
>> 
>> - other developers fetch the replace refs from the common repo before
>>   they bisect
>> 
>> - when these other developers bisect, the new parts of the history are
>>   automatically used, so bisecting is faster, easier and maybe safer
>>   too
>> 
>> I think that it is better than when everyone changes the history
>> manually by applying patches in the middle of a bisection.
> 
> This is nice, but I'm not sure whether it'll work / suit well with a
> tree like kernel, which is the results of tons of merges from various
> maintainers.  I guess little maintainers would publish the corrected
> repo.  I hope my guess is wrong.

Yeah, I don't know if it's easy enough to redo many merges with
current Git. On the other hand, I don't see why it couldn't be made
easy if it isn't already.

About maintainers publishing the corrected/improved repo, I think if a
few developers publish one that provide some benefits, and come up
with a way/workflow to do so quite easily, then other will follow.

>> > A preferred option is
>> > just addendum on top of the existing commits, and the way to easily
>> > share the change (at best with the normal git pull).  If git-replace
>> > provides such a good integration, I'd love to see it in our use case.
>> 
>> git notes is probably better if what you want is only addendum on top
>> of the existing commits. git notes creates notes refs that you can
>> easily share.
> 
> IMO, it's not that easy to share git notes.  At least, it's not in the
> same level as sharing tags.  If it were as easy as tags, I see no
> reason to avoid using git-notes.  That said, having a separate refs
> that requires the extra non-standard step looks like a big obstacle.

I don't see why it is not easy to share git notes.

Basically I think that you just need to add refspecs like

	  push = +refs/notes/*:refs/notes/*

or

	  fetch = +refs/notes/*:refs/notes/*

in your config file, in the sections of the remotes you want to push
or fetch notes.

But we should probably CC Johan Herland <johan at herland.net> or Junio
when discussing this as I don't know notes well.

Best,
Christian.