[U-Boot-Users] Revised custodian git writeup

[Martin Krause]

wd at denx.de wrote on Wednesday, January 23, 2008 1:48 PM:
> In message
> <47F3F98010FF784EBEE6526EAAB078D10635DDB0 at 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