public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Revised custodian git writeup
Date: Wed, 23 Jan 2008 13:47:42 +0100	[thread overview]
Message-ID: <20080123124742.6EAC42430C@gemini.denx.de> (raw)
In-Reply-To: Your message of "Wed, 23 Jan 2008 13:04:34 +0100." <47F3F98010FF784EBEE6526EAAB078D10635DDB0@tq-mailsrv.tq-net.de>

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
e-credibility: the non-guaranteeable likelihood that  the  electronic
data you're seeing is genuine rather than somebody's made-up crap.
- Karl Lehenbauer

  reply	other threads:[~2008-01-23 12:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-22  1:44 [U-Boot-Users] Revised custodian git writeup gvb.uboot
2008-01-22  7:52 ` Markus Klotzbücher
2008-01-22  8:55 ` Wolfgang Denk
2008-01-22  9:50   ` Haavard Skinnemoen
2008-01-22 13:45     ` Wolfgang Denk
2008-01-22 14:20       ` Haavard Skinnemoen
2008-01-22 14:42         ` Mike Frysinger
2008-01-22 16:34         ` Wolfgang Denk
2008-01-22 18:23           ` Joakim Tjernlund
2008-01-22 18:39           ` Haavard Skinnemoen
2008-01-22 13:50     ` Jerry Van Baren
2008-01-22 14:10       ` Wolfgang Denk
2008-01-22 13:32   ` Jerry Van Baren
2008-01-22 14:03     ` Wolfgang Denk
2008-01-22 14:26       ` Markus Klotzbücher
2008-01-22 16:36         ` Wolfgang Denk
2008-01-22 22:47           ` Jerry Van Baren
2008-01-22 23:32             ` Wolfgang Denk
2008-01-23  3:15               ` gvb.uboot
2008-01-23 12:04               ` Martin Krause
2008-01-23 12:47                 ` Wolfgang Denk [this message]
2008-01-23 17:27                   ` Martin Krause
2008-01-23 17:30                     ` Haavard Skinnemoen
2008-01-22 14:38       ` Haavard Skinnemoen
2008-01-22 14:35     ` Jerry Van Baren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080123124742.6EAC42430C@gemini.denx.de \
    --to=wd@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox