Re: History messup

Hi,

I wrote a git repository tracker, which can track and coordinate multiple git repositories. Before it goes public, I want to clarify a problem which I encountered

The commit bfd4bda097f8758d28e632ff2035e25577f6b060 by David Woodhouse (Thu May 5 12:59:37 2005 +100) Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

breaks the history.

David merged from Linus repository . Linus synced later with David. Linus did not create a new commit for this update and just pointed his "HEAD" to Davids "HEAD", which means he forked Davids repository at this point.

Due to that the parent->parent history is not longer unique. This makes it impossible to do file revision graphs over the various repositories in the correct order.

Is this a unique problem or is the omission of a commit in cases like that usual practice ? In the latter case proper history tracking is almost impossible.

tglx

Hello, if merging with a repository just means to bring the head forward (e.g. no local development since the fork) there is no seperate commit object, just an update of the HEAD. Linus did explain this behaviour and the thoughts behind this decission on the ML:

If two repositories pull alternating from each other one has never the exact state the other has. They would play ping-pong and this is a bad thing. That was AFAIK the reason there is no COMMIT object introduced on 'head forward' merges.

	Thomas

On Mon, 2005-05-09 at 19:06 +0200, Thomas Glanzmann wrote:

That makes totaly sense, but for history tracking it is a horror scenario, unless you dont have head history lists per repository or an unique repository identifier in the commit blob itself.

tglx

On Mon, 2005-05-09 at 16:59 +0000, Thomas Gleixner wrote:

It's normal practice, and it _has_ to be the case. Otherwise the trees would never stabilise -- every time Linus pulled from my tree he would create a merge-commit which I don't yet have, and vice versa.

Unless a commit also carries a unique repo-id identifying the repository in which it originally occurred, you'll only ever be able to track history in the way people want by means of heuristics.

On Mon, 2005-05-09 at 18:27 +0100, David Woodhouse wrote:

Sure

That would be really great. A line after "parents" like

repoid "username/reponame" 

would be sufficient

tglx

Thomas Gleixner wrote:

Seems like a UUID or a SHA-1 identifier would be better.

However, one can definitely argue that even the meaning of "a repository" isn't well-defined in the context of git.

	-hpa

On Mon, 2005-05-09 at 12:01 -0700, H. Peter Anvin wrote:

Of course it isn't. But neither is the meaning "a committer" or "an author" or even "a date".

Including some kind of repo-specific identifier with each commit would help us to make sense of the history, just as those other fields do.

David Woodhouse wrote:

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?

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/ ...

	-hpa

On Mon, May 9, 2005 3:34 pm, H. Peter Anvin said:

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.

:o)

sean

On Mon, 2005-05-09 at 18:08 -0400, Sean wrote:

You can apply some heuristic guessing to detect fast forward heads, but at the very end you will end up with manual selection puzzles.

On one hand we keep care to track the source of a change in the kernel code by adding signed,acked but on the other hand we don't care about history correctness. If you look at some file revisions, which you read from the tree history then you just have patches applied in the wrong order.

Maybe nobody cares, but for maintaining customer trees with a bugfix, stable and experimental branch it's necessary to keep track of information in a consistent way especially if you have to deal with the QA department.

I know that there is no simple and fool proof solution for this problem, but some band-aid to make the reconstruction of history simpler would be not too bad.

tglx

Dear diary, on Mon, May 09, 2005 at 09:06:38PM CEST, I got a letter where David Woodhouse <dwmw2@infradead.org> told me that...

FWIW, I recently added .git/branch-name to Cogito, since I needed some identifier through which to differentiate between the branches (repositories - it's all blurred in Cogito view) when sending commits to CIA.

It is strictly per-branch (never to be shared by multiple repositories), optional, informative and more of a temporary solution for now I had to cook together in a minute.