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.
Even if you try to do this twice to identical copies of the git repo you will get different IDs:
-> rm -fr foo -> tar zxf foo.tgz ; cd foo ; echo x >xxx ; git-add xxx; git-commit -m test Created commit 8c934ae: test 1 files changed, 1 insertions(+), 1 deletions(-) -> cd .. -> rm -fr foo -> tar zxf foo.tgz ; cd foo ; echo x >xxx ; git-add xxx; git-commit -m test Created commit b5ae18e: test 1 files changed, 1 insertions(+), 1 deletions(-) -> cd .. -> rm -fr foo -> tar zxf foo.tgz ; cd foo ; echo x >xxx ; git-add xxx; git-commit -m test Created commit 56eb723: test 1 files changed, 1 insertions(+), 1 deletions(-)
You see? Three identical commits, three different commit IDs.
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.
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.
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.
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.
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 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 ;-)
Best regards,
Wolfgang Denk