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
next prev parent 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