wd@denx.de wrote on Wednesday, January 23, 2008 1:48 PM:
In message 47F3F98010FF784EBEE6526EAAB078D10635DDB0@tq-mailsrv.tq-net.de you wrote:
Huh? Normally the commit IDs are the most important thing I care about when working with other git repositories. If I try to compare my git repositroy with another one (mostly the u-boot master branch at denx) then the commit ID is the only way (I know) to make sure that my respository contains the exactly same patches than the other repository. If the topmost patch (or any other) in my respository has
But this does not work.
Assume you and me start with absolutely identical copies of the same git repository - say we copied a disk.
Now we both check in the very same patch from the mailing list using for example git-am. You will see that we get two different commit IDs.
Agreed
Even if you try to do this twice to identical copies of the git repo you will get different IDs:
Agreed
You see? Three identical commits, three different commit IDs.
But if I rebase my repository with yours, my patch will go away (or at least stay on top of my repository as an empty commit, I'm not sure about that) and our repositories are identical again (= identical history). But if I merge my repository with yours they are not identical afterwards. Content yes, history no. And worse, I have no chance to ever get history identical again (without rebasing).
As far as I understand the git philosophy, using SHA1 signatures as commit IDs was one of the most important things on git. IMO the goal
Yes, of course. And the SHA1's of the *objects* are of course the same. But the commit IDs may be different - they include for example the commiter's name and time etc., so they will be different even when you do the very same action again in the very same copy of a repository. See above.
Note that git is tracking content, not history.
As far as I know every commit has an parent. And this parent (its ID) is part of the commit. So history is been tracked as a list of successive commits. Another order of the commits leads to another history and to another commit IDs.
Excerpt from the git README:
Furthermore, since the SHA1 signature of a commit refers to the SHA1 signatures of the tree it is associated with and the signatures of the parent, a single named commit specifies uniquely a whole set of history, with full contents. You can't later fake any step of the way once you have the name of a commit.
behind that was to be able to refere to one particular state in a git repository by one single commit ID. If I have two git repositories with de facto the same content, but with different commit IDs, what's the worth of the SHA1 commit ID?
You can still compare the commits. Just not the commit IDs.
How can I do that?
I often use for example the (partial) commit ID in the U-Boot boot message to identify from wich particular source state a U-Boot was
This is OK, as long as you are referring to some repository for which you have a guarantee that the history will not be rewritten.
No, it does not matter, if the history was rewritten. If I find a repository which contains this commit ID, I can be sure that I could restore the exact soucre code the U-Boot was built from (this does not work for sure, because the commit ID in the U-Boot boot message is only a partial commit ID, but it will work if I would have the complete commit ID). The chance, that a repository with a rewritten history will contain this commit ID is lower, admitted.
built. This only works, if the order of patches is the same in all git repositories resulting in the same commit IDs. Otherwise I need
No, this has nothing to do with that.
to know from wich git repository the U-Boot was built, to identify
Yes, of course you need to know that. As soon as you are working n your own tree it may have commits that are present nowhere else. Only as long as you are referring to a known common history you can make references to another repo.
If I rebase my tree with the public tree my commits will always stay on top of the "known common history". The differences between my and the public repository are easily recognizeable (e. g. with qgit). If I merge my tree with the public tree I get a mixture of history. I don't know a way, how I could get the differences then (but this does not necceseraly mean, that there is no way).
the source state it was built from. And then I can't compare this repository to another (e. g. the denx master), because the same patches could have different commit IDs.
But they will result in the very same content (objcts in the git repo), and git is tracking the content, not the commit ID.
I disagree, see above.
I tried this already some time ago (merging my u-boot-tq-group master branch, instead of rebasing) and get totally lost in a screwed up history. But maybe I did something wrong.
Most probably (or this was with older versions of the tools - as mentioned before, I screwed up more than one repo before ;-)
I'm using git 1.5.3.rc6.
Best regards, Martin Krause