Re: Storing additional information in commit headers

also sprach Jeff King [off-list ref] [2011.08.02.2051 +0200]:

I agree that is an annoyance, but it is one we can deal with. In the
near term, I wonder if a "tg clone" would be appropriate to add the
extra fetch refspecs when cloning (or even a "tg init" inside an
existing git repo -- I don't actually use topgit, so I'm not sure what
the usual initialization process, if any, is).

Hey Jeff, thanks for your response.

TopGit does come with these commands to do the setup for you, but
that does not ensure that a new contributor without any idea about
TopGit won't forget to run them.

The argument against tg-clone is mainly that I really do not want to
encapsulate/abstract functionality, but rather stay as close as
possible to pure Git, and never to mandate anyone to use anything
else.

In the longer term, it might be nice if git was better at sharing
third-party refs. The problem is that we don't know what the refs
mean, so we don't know which ones are appropriate for sharing.
Maybe we could do something like "refs/shared/topgit/*", and git
by default would push and pull items under refs/shared?

This could be an interesting and viable approach.

quoted

Therefore I thought it would be sensible to store these data in
commit. When the data change, there will always be a new commit to
store these data, and we do *not* want to update the data in
previous commits. Finding the data then becomes backtracking the
branch history until a commit is found containing them.

That seems to me like you are sticking information in a commit that is
not actually about the commit, but about the ref that happens to point
to the commit. What if I have two refs that point to the same commit,
but with two different topgit bases?

I don't think this can happen, but the point is valid.

What about years later, when that information isn't interesting
anymore? You're still carrying the cruft inside your commit
objects.

[…]

I'm still not 100% convinced you want per-commit storage, though,
and not per-ref storage.

Yes, I do want per-ref storage. Your arguments against my orphan
parent pointer approach (which could later be a x-*-ref approach)
are valid.

It just seems to me that per-ref storage is a lot further away than
per-commit storage, and I'd really like to move forward with TopGit…

Thank you,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"one should never trust a woman who tells her real age.
 if she tells that, she will tell anything."
                                                        -- oscar wilde
 
spamtraps: madduck.bogus@madduck.net