Re: History messup
- From
Sean <seanlkml@sympatico.ca>
- Date
- May 9, 2005, 22:08 UTC
- Message-ID
- <3772.10.10.10.24.1115676539.squirrel@linux1>
- In-Reply-To
- <427FBB53.1000801@zytor.com>
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