Re: History messup

["Sean" <seanlkml@sympatico.ca>]

On Mon, May 9, 2005 3:34 pm, H. Peter Anvin said:
> I'm particularly thinking of when you copy and clone directories, you
> have to define your semantics more specifically.  When do you want to
> *copy* this ID, and when do you want to make sure a new one is created?

What question will a repoid let you answer?

Isn't the real problem, where to store "repoid"?  Obviously it would be
stored in each commit created in a repo, but that's not really the
problem.   The problem is identifying which repo each branch belongs to as
you traverse the history.  This lets you ask questions like, "was this
commit created on this branch, or is it just a copy".

But just as the committer information in each object doesn't help you
identify the branch, nor will having a repoid inside each commit.   The
problem is labelling the branch, not the commits found in it.  And there
is no place to store the repoid for each branch.

Using the repoid of the first commit found on a branch is pretty close,
but fails because it might be a fast-forward HEAD rather than a genuine
local commit of the source repository.  So there is no way to know as you
embark down a branch its repoid, so you have nothing to compare against
the repoid inside each commit you find along its path.

Seems the only solution is a full search of the history, unless there is
some clever way to label branches or detect fast forward heads.

> One possible answer to that is to have .git/repoid and have it
> auto-created (from /dev/urandom) if it doesn't exist, but I also observe
> that at least two people (davem and pavel) have managed to clone "Linus'
> kernel tree" as their description on http://www.kernel.org/git/ ...

:o)

sean