[U-Boot-Users] Revised custodian git writeup

[U-Boot-Users] Revised custodian git writeup

[gvb.uboot]

<http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t>

I've rewritten the "Tips for maintaining custodian trees" section to 
reflect Wolfgang's request that the "master" branch be used for patches 
for him to pull.

Conceptually, this is very different from my previous recommendation / 
methodology writeup.  In practice, however, it is a trivial change.  The 
fundamental difference is to create a separate branch ("uboot") to track 
the master repo and rebase the "master" branch against that, instead of 
vice versa.

Best regards,
gvb

[U-Boot-Users] Revised custodian git writeup

[Markus Klotzbücher]

Hi Jerry,

"gvb.uboot" <gvb.uboot@gmail.com> writes:

> <http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t>
>
> I've rewritten the "Tips for maintaining custodian trees" section to 
> reflect Wolfgang's request that the "master" branch be used for patches 
> for him to pull.
>
> Conceptually, this is very different from my previous recommendation / 
> methodology writeup.  In practice, however, it is a trivial change.  The 
> fundamental difference is to create a separate branch ("uboot") to track 
> the master repo and rebase the "master" branch against that, instead of 
> vice versa.

This is helpful, thanks for sharing!

Best regards

Markus Klotzbuecher

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

Hello,

in message <47954A7D.4070507@gmail.com> you wrote:
> 
> I've rewritten the "Tips for maintaining custodian trees" section to 
> reflect Wolfgang's request that the "master" branch be used for patches 
> for him to pull.
> 
> Conceptually, this is very different from my previous recommendation / 
> methodology writeup.  In practice, however, it is a trivial change.  The 
> fundamental difference is to create a separate branch ("uboot") to track 
> the master repo and rebase the "master" branch against that, instead of 
> vice versa.

Rebasing the master branch, i. e. the one I'll be pullung from?

Are you sure that is a good idea? Note that I (and probably others)
will be pulling from that branch, and not only once!

Quote from the git-rebase man page:

...
NOTES
       When you rebase a branch, you are changing its history in a
       way that will cause problems for anyone who already has a copy
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       of the branch in their repository and tries to pull updates
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       from you. You should understand the implications of using git
       ^^^^^^^^^
       rebase on a repository that you share.
...



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

[U-Boot-Users] Revised custodian git writeup

[Haavard Skinnemoen]

On Tue, 22 Jan 2008 09:55:33 +0100
Wolfgang Denk <wd@denx.de> wrote:

> Rebasing the master branch, i. e. the one I'll be pullung from?
> 
> Are you sure that is a good idea? Note that I (and probably others)
> will be pulling from that branch, and not only once!

That depends on whether or not you want your commit history filled with
"merge with upstream/master" crap or not.

You should only pull when explicitly requested to do so. In that case,
if the branch was newly rebased, there will be a clean, linear history
from the tip of your master branch to the tip of the one being pulled.

If there are conflicting changes and the merge needs manual
intervention, you abort the merge and tell the one sending the pull
request that it didn't merge cleanly, please rebase.

>        When you rebase a branch, you are changing its history in a
>        way that will cause problems for anyone who already has a copy
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        of the branch in their repository and tries to pull updates
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        from you. You should understand the implications of using git
>        ^^^^^^^^^
>        rebase on a repository that you share.

And that is, IMO, exactly why you shouldn't be pulling from the master
branch in the first place. People who pull regularly to test stuff that
is in progress will run into this problem, and they are most likely to
pull the master branch because that's the default.

There are two different kinds of users involved here: You (and other
maintainers that are "upstream" from someone), and regular users who
want to test stuff. Upstream maintainers should receive a clean
history, i.e. from a branch that is frequently rebased. At the same
time, we should avoid exposing testers to the problems of dealing with
a branch that is rebased all the time.

So we need (at least) two different branches that are maintained in
different ways, and I think it's easier to tell you, Wolfgang and other
upstream maintainers, to pull from a non-master branch than to tell
everyone else in the world.

Just my two cents.

Haavard

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

In message <20080122105016.313d8f88@dhcp-252-066.norway.atmel.com> you wrote:
>
> > Are you sure that is a good idea? Note that I (and probably others)
> > will be pulling from that branch, and not only once!
> 
> That depends on whether or not you want your commit history filled with
> "merge with upstream/master" crap or not.

...which in turn depends on whether  or  not  you  consider  a  merge
commit as crap or not. IMHO it's sometimes valuable information about
the history of a project, but YMMV.


My point is a different one, and it seems I never explicitly stated it
before:

My idea of a custodian repository is that it  is  more  than  just  a
working  tool  for  collecting  patches and preparing these for merge
into  mainline.  My  idea  is  instea  that  these  are  pretty  much
independent  incarnations  of  U-Boot source trees which users (note:
users, not only developers) with  specific  needs  or  interests  can
refer to.

For example, in my set of mind somebody interested in the latest 85xx
code would clone the 85xx custodian  repository,  expecting  that  he
finds  there  the  most  current  code for this family of processors.
Probably he will never sync himself  against  mainline,  but  instead
continue update (pull) from the 85xx custodian repository.

That means, that my idea is that it is the custodian's responsibility
to  provide  a  permanently  accessable,  consistent  view   of   his
repository  to  users.  When  he  collects  patches,  he will - after
sufficient review and testing - decide that these are good enough  to
go  into  his  repository. And at certain points we will pull all the
stuff that has been collected there into mainline.

> You should only pull when explicitly requested to do so. In that case,

Actually I fetch from all custodian repos quite frequently. But I do
only pull (merge into mainline) when I'm explicitely told.

But note that my idea  is  that  other  users  may  have  cloned  the
custodian  repository,  and  continue  to  pull  from  it.  For their
convenience (and my own) I want to have the current code collected in
the master branch, and I think we agree that the master  branch  must
not be rebased.

> If there are conflicting changes and the merge needs manual
> intervention, you abort the merge and tell the one sending the pull
> request that it didn't merge cleanly, please rebase.

Right - but this does not depend on how the custodian repos are set up
or which branch I'm pulling from.

> >        way that will cause problems for anyone who already has a copy
> >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        of the branch in their repository and tries to pull updates
> >        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        from you. You should understand the implications of using git
> >        ^^^^^^^^^
> >        rebase on a repository that you share.
> 
> And that is, IMO, exactly why you shouldn't be pulling from the master
> branch in the first place. People who pull regularly to test stuff that
> is in progress will run into this problem, and they are most likely to
> pull the master branch because that's the default.

People pulling the master branch have (IMHO) the right  to  expect  a
consisten  history.  It is the custodians responsibility not to merge
stuff into the master branch that causes conflicts.

> There are two different kinds of users involved here: You (and other
> maintainers that are "upstream" from someone), and regular users who
> want to test stuff. Upstream maintainers should receive a clean

I don't think that we are different types of users - maybe  from  the
kind  of  work  we  do,  but  I  don't  see  why we should access the
custodian's repository differently. Actually I think  it's  a  pretty
good idea if others test the very same code I will be pulling later.

> history, i.e. from a branch that is frequently rebased. At the same

I think only "small" topic branches should be rebased - this  is  the
part of the custodian's work that is needed to clean up the stuff and
to  make it ready for mainline merge. The he prepares a branch for me
and ofr other users to pull from.

> time, we should avoid exposing testers to the problems of dealing with
> a branch that is rebased all the time.

ACK.

> So we need (at least) two different branches that are maintained in
> different ways, and I think it's easier to tell you, Wolfgang and other
> upstream maintainers, to pull from a non-master branch than to tell
> everyone else in the world.

I still fail to see why separate branches would be  needed.  I  think
using  the  same  one  makes more sense, as it allows me to pull from
tested code.

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
God may be subtle, but He isn't plain mean.         - Albert Einstein

[U-Boot-Users] Revised custodian git writeup

[Haavard Skinnemoen]

On Tue, 22 Jan 2008 14:45:48 +0100
Wolfgang Denk <wd@denx.de> wrote:

> In message <20080122105016.313d8f88@dhcp-252-066.norway.atmel.com> you wrote:
> >
> > > Are you sure that is a good idea? Note that I (and probably others)
> > > will be pulling from that branch, and not only once!
> > 
> > That depends on whether or not you want your commit history filled with
> > "merge with upstream/master" crap or not.
> 
> ...which in turn depends on whether  or  not  you  consider  a  merge
> commit as crap or not. IMHO it's sometimes valuable information about
> the history of a project, but YMMV.

So you _do_ want that crap in the commit history ;-)

Other people (Linus, for example) do not. I guess I'll just have to use
different workflows for my u-boot and Linux work then...but I'm not
quite done arguing yet ;-)

> My point is a different one, and it seems I never explicitly stated it
> before:
> 
> My idea of a custodian repository is that it  is  more  than  just  a
> working  tool  for  collecting  patches and preparing these for merge
> into  mainline.  My  idea  is  instea  that  these  are  pretty  much
> independent  incarnations  of  U-Boot source trees which users (note:
> users, not only developers) with  specific  needs  or  interests  can
> refer to.
> 
> For example, in my set of mind somebody interested in the latest 85xx
> code would clone the 85xx custodian  repository,  expecting  that  he
> finds  there  the  most  current  code for this family of processors.
> Probably he will never sync himself  against  mainline,  but  instead
> continue update (pull) from the 85xx custodian repository.
> 
> That means, that my idea is that it is the custodian's responsibility
> to  provide  a  permanently  accessable,  consistent  view   of   his
> repository  to  users.  When  he  collects  patches,  he will - after
> sufficient review and testing - decide that these are good enough  to
> go  into  his  repository. And at certain points we will pull all the
> stuff that has been collected there into mainline.

But the stuff that has been collected may be in completely different
states of development. Some patches may have pending review comments
(which showed up after they were committed to the repository.) Some
patches may need more testing (which they are much more likely to get
after they have been committed to the repository.)

When the merge window comes up, the custodian should submit a merge
request for all the patches that are considered complete and fully
tested, and this usually involves cherry-picking patches into a freshly
created branch, making the history non-linear.

Also, if a bug shows up during testing, it should be folded into the
original patch before it's merged upstream, or it will break "git
bisect". This is just not possible if you only want to pull from a
linear master branch.

> > You should only pull when explicitly requested to do so. In that case,
> 
> Actually I fetch from all custodian repos quite frequently. But I do
> only pull (merge into mainline) when I'm explicitely told.

How about you do those out-of-band pulls from the master branch (which
is not to be rebased and may contain stuff that requires more testing)
and only pull into mainline from the branch specified by the custodian?

> But note that my idea  is  that  other  users  may  have  cloned  the
> custodian  repository,  and  continue  to  pull  from  it.  For their
> convenience (and my own) I want to have the current code collected in
> the master branch, and I think we agree that the master  branch  must
> not be rebased.

I have no problem with that. I just think that custodians should be
allowed to specify a different branch than "master" when sending a pull
request.

> > If there are conflicting changes and the merge needs manual
> > intervention, you abort the merge and tell the one sending the pull
> > request that it didn't merge cleanly, please rebase.
> 
> Right - but this does not depend on how the custodian repos are set up
> or which branch I'm pulling from.

If you only ever want to pull from the master branch, and the master
branch can't be rebased, how are we supposed to rebase?

> > >        way that will cause problems for anyone who already has a copy
> > >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >        of the branch in their repository and tries to pull updates
> > >        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >        from you. You should understand the implications of using git
> > >        ^^^^^^^^^
> > >        rebase on a repository that you share.
> > 
> > And that is, IMO, exactly why you shouldn't be pulling from the master
> > branch in the first place. People who pull regularly to test stuff that
> > is in progress will run into this problem, and they are most likely to
> > pull the master branch because that's the default.
> 
> People pulling the master branch have (IMHO) the right  to  expect  a
> consisten  history.  It is the custodians responsibility not to merge
> stuff into the master branch that causes conflicts.

Agreed.

> > There are two different kinds of users involved here: You (and other
> > maintainers that are "upstream" from someone), and regular users who
> > want to test stuff. Upstream maintainers should receive a clean
> 
> I don't think that we are different types of users - maybe  from  the
> kind  of  work  we  do,  but  I  don't  see  why we should access the
> custodian's repository differently. Actually I think  it's  a  pretty
> good idea if others test the very same code I will be pulling later.

Sure, but some patches may require more testing than others.

> > history, i.e. from a branch that is frequently rebased. At the same
> 
> I think only "small" topic branches should be rebased - this  is  the
> part of the custodian's work that is needed to clean up the stuff and
> to  make it ready for mainline merge. The he prepares a branch for me
> and ofr other users to pull from.

I think your argument is inconsistent. How is "preparing a branch for
you to pull" any different from rebasing?

> > So we need (at least) two different branches that are maintained in
> > different ways, and I think it's easier to tell you, Wolfgang and other
> > upstream maintainers, to pull from a non-master branch than to tell
> > everyone else in the world.
> 
> I still fail to see why separate branches would be  needed.  I  think
> using  the  same  one  makes more sense, as it allows me to pull from
> tested code.

I think you'll receive more well-tested code if you allow custodians to
commit patches to "master" earlier. But this necessarily means either
being allowed to rebase the "master" branch or using a different branch
for merging (which only contains code that has spent a fair amount of
time in the master branch.)

IOW, one branch is for stuff that is ready to merge, the other is for
the same _plus_ stuff that needs testing. I think using "master" for
the latter will give the to-be-tested code much more exposure before it
hits mainline, and that's IMO a good thing.

Haavard

[U-Boot-Users] Revised custodian git writeup

[Mike Frysinger]

On Tuesday 22 January 2008, Haavard Skinnemoen wrote:
> I think you'll receive more well-tested code if you allow custodians to
> commit patches to "master" earlier. But this necessarily means either
> being allowed to rebase the "master" branch or using a different branch
> for merging (which only contains code that has spent a fair amount of
> time in the master branch.)
>
> IOW, one branch is for stuff that is ready to merge, the other is for
> the same _plus_ stuff that needs testing. I think using "master" for
> the latter will give the to-be-tested code much more exposure before it
> hits mainline, and that's IMO a good thing.

while i havent gotten into the game just yet, Haavard's scheme makes more 
sense to me and seems to address Wolfgang's desire for usable processor 
trees.  the master branch is never rebased and contains all the latest and 
greatest (and stuff not ready for mainline).  when a custodian wants Wolfgang 
to pull something, they prepare a non-master branch with cleaned up patches 
and all that and asks Wolfgang to pull on that branch.  otherwise there's no 
way to get users to test out patches that should be ok but not ready just yet 
for mainline while at the sametime giving Wolfgang something sane to pull 
from.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080122/b067f90c/attachment.pgp 

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

In message <20080122152035.22f1dffd@dhcp-252-066.norway.atmel.com> you wrote:
>
> Other people (Linus, for example) do not. I guess I'll just have to use
> different workflows for my u-boot and Linux work then...but I'm not
> quite done arguing yet ;-)

I appreciate your comments, really. I don't claim to be  perfect,  on
contrary  -  git is still new to me and I'm trying to find my way. If
it turns out that my ideas are  wong,  or  that  following  my  style
imposes  a  high  and  avoidable  burden to many others I will try to
adapt.

> But the stuff that has been collected may be in completely different
> states of development. Some patches may have pending review comments
> (which showed up after they were committed to the repository.) Some
> patches may need more testing (which they are much more likely to get
> after they have been committed to the repository.)
> 
> When the merge window comes up, the custodian should submit a merge
> request for all the patches that are considered complete and fully
> tested, and this usually involves cherry-picking patches into a freshly
> created branch, making the history non-linear.

I agree, except that my idea would be not to use  a  freshly  created
branch, but master.

> Also, if a bug shows up during testing, it should be folded into the
> original patch before it's merged upstream, or it will break "git
> bisect". This is just not possible if you only want to pull from a
> linear master branch.

When the custodian's repo continues to use  the  master  branch,  and
checks in a commit to fix the bug there, git-bisect should still work
fine.  The difference is that there will be not a single commit for a
"perfect", bug-free patch, but a buggy one plus a fix for the bug.

> How about you do those out-of-band pulls from the master branch (which
> is not to be rebased and may contain stuff that requires more testing)
> and only pull into mainline from the branch specified by the custodian?

I can do this if really needed, but  I  see  trouble  ahead.  I  know
myself.  I  will  see  a  pull  request for repo XXX and pull without
specifying a branch. Only when I will reply to the message after  I'm
done  to  ACK  it  I  will  notice that somewhere near the end of the
message there is a note saying "please pull from  branch  YYY".  This
already happened, so I know what I'm talking about ;-)

> I have no problem with that. I just think that custodians should be
> allowed to specify a different branch than "master" when sending a pull
> request.

If really necessary I will have to adjust to this, but I'd rather
avoid it.

> If you only ever want to pull from the master branch, and the master
> branch can't be rebased, how are we supposed to rebase?

Consider merging into your master branch as the  first  step  of  the
pull  request  - this is the point where you give up control over the
patch. Assume I would pull the very same moment. How  do  you  rebase
after I have pulled from your branch?

> > I don't think that we are different types of users - maybe  from  the
> > kind  of  work  we  do,  but  I  don't  see  why we should access the
> > custodian's repository differently. Actually I think  it's  a  pretty
> > good idea if others test the very same code I will be pulling later.
> 
> Sure, but some patches may require more testing than others.

Agreed. Hold them in testing branches as long  as  testingis  needed.
When they are ready to be merged into mainline, they can go into your
master branch, too. And from there I willpick them up.

> > I think only "small" topic branches should be rebased - this  is  the
> > part of the custodian's work that is needed to clean up the stuff and
> > to  make it ready for mainline merge. The he prepares a branch for me
> > and ofr other users to pull from.
> 
> I think your argument is inconsistent. How is "preparing a branch for
> you to pull" any different from rebasing?

It means rebasing of your working branches so that  they  are  up  to
date  and  don't cause conflicts before merging them into your master
branch.

> I think you'll receive more well-tested code if you allow custodians to
> commit patches to "master" earlier. But this necessarily means either
> being allowed to rebase the "master" branch or using a different branch
> for merging (which only contains code that has spent a fair amount of
> time in the master branch.)

To me, your master branch is your "stable" code. Code that needs more
testing should use a different branch name. Especially  if  you  have
different pots on the fire at the same time.

> IOW, one branch is for stuff that is ready to merge, the other is for
> the same _plus_ stuff that needs testing. I think using "master" for

You may want several independet "testing"  branches,  not  only  one.
master  seems not the best choice to me. I think we should use master
== stable.

> the latter will give the to-be-tested code much more exposure before it
> hits mainline, and that's IMO a good thing.

I understand your position, too. As mentioned above,  I  don't  claim
that my suggestion is perfect or optimal. I developed my own style of
working, others developed theirs. This discussion helps to figure out
how to make co-operation easier. Thanks!

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
I often quote myself; it adds spice to my conversation.  - G. B. Shaw

[U-Boot-Users] Revised custodian git writeup

[Joakim Tjernlund]

> -----Ursprungligt meddelande-----
> Fr?n: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net]
> F?r Wolfgang Denk
> Skickat: den 22 januari 2008 17:35
> Till: Haavard Skinnemoen
> Kopia: U-Boot Users
> ?mne: Re: [U-Boot-Users] Revised custodian git writeup
> 
> In message <20080122152035.22f1dffd@dhcp-252-066.norway.atmel.com> you wrote:
> >
> > Other people (Linus, for example) do not. I guess I'll just have to use
> > different workflows for my u-boot and Linux work then...but I'm not
> > quite done arguing yet ;-)
> 
> I appreciate your comments, really. I don't claim to be  perfect,  on
> contrary  -  git is still new to me and I'm trying to find my way. If
> it turns out that my ideas are  wong,  or  that  following  my  style
> imposes  a  high  and  avoidable  burden to many others I will try to
> adapt.
[SNIP]

This discussion is interesting, but I really would like to see some
new code in u-boot's master branch :)

  Jocke

[U-Boot-Users] Revised custodian git writeup

[Haavard Skinnemoen]

On Tue, 22 Jan 2008 17:34:49 +0100
Wolfgang Denk <wd@denx.de> wrote:

> In message <20080122152035.22f1dffd@dhcp-252-066.norway.atmel.com>
> you wrote:
> >
> > Other people (Linus, for example) do not. I guess I'll just have to
> > use different workflows for my u-boot and Linux work then...but I'm
> > not quite done arguing yet ;-)
> 
> I appreciate your comments, really. I don't claim to be  perfect,  on
> contrary  -  git is still new to me and I'm trying to find my way. If
> it turns out that my ideas are  wong,  or  that  following  my  style
> imposes  a  high  and  avoidable  burden to many others I will try to
> adapt.

Good. I think I understand your position better now, and I think we
actually agree on the fundamental goals.

> I can do this if really needed, but  I  see  trouble  ahead.  I  know
> myself.  I  will  see  a  pull  request for repo XXX and pull without
> specifying a branch. Only when I will reply to the message after
> I'm done  to  ACK  it  I  will  notice that somewhere near the end of
> the message there is a note saying "please pull from  branch  YYY".
> This already happened, so I know what I'm talking about ;-)

Just triple-click on the line containing the repository URL followed by
the branch name and paste it into your terminal after "git pull".

IIRC, this is why Linus insists that people always put the repository
URL and the branch on the same line in pull requests, and why
git-request-pull does this automatically.

> > If you only ever want to pull from the master branch, and the master
> > branch can't be rebased, how are we supposed to rebase?
> 
> Consider merging into your master branch as the  first  step  of  the
> pull  request  - this is the point where you give up control over the
> patch. Assume I would pull the very same moment. How  do  you  rebase
> after I have pulled from your branch?

Right. This is the way I usually do it, except that I create a fresh
branch from the latest upstream master, and that I consider giving up
control over the patches the moment I send the pull request, not
necessarily when I push.

But these are just details. Your way seems workable too, now that I
understand it fully. Thanks for explaining.

> > > I don't think that we are different types of users - maybe  from
> > > the kind  of  work  we  do,  but  I  don't  see  why we should
> > > access the custodian's repository differently. Actually I think
> > > it's  a  pretty good idea if others test the very same code I
> > > will be pulling later.
> > 
> > Sure, but some patches may require more testing than others.
> 
> Agreed. Hold them in testing branches as long  as  testingis  needed.
> When they are ready to be merged into mainline, they can go into your
> master branch, too. And from there I willpick them up.

Ok. The only issue I have with this approach is that people may be less
likely to test them when they're not in "master". But I guess
announcing things clearly might help -- perhaps by creating a new
"testing" branch when submitting a patch series for review and mention
this in the introductory email.

> > I think you'll receive more well-tested code if you allow
> > custodians to commit patches to "master" earlier. But this
> > necessarily means either being allowed to rebase the "master"
> > branch or using a different branch for merging (which only contains
> > code that has spent a fair amount of time in the master branch.)
> 
> To me, your master branch is your "stable" code. Code that needs more
> testing should use a different branch name. Especially  if  you  have
> different pots on the fire at the same time.
> 
> > IOW, one branch is for stuff that is ready to merge, the other is
> > for the same _plus_ stuff that needs testing. I think using
> > "master" for
> 
> You may want several independet "testing"  branches,  not  only  one.
> master  seems not the best choice to me. I think we should use master
> == stable.

Good point.

> > the latter will give the to-be-tested code much more exposure
> > before it hits mainline, and that's IMO a good thing.
> 
> I understand your position, too. As mentioned above,  I  don't  claim
> that my suggestion is perfect or optimal. I developed my own style of
> working, others developed theirs. This discussion helps to figure out
> how to make co-operation easier. Thanks!

Yes, I think I understand now how I can make this work with only a
couple of minor adjustments to my workflow. Thanks!

Haavard

[U-Boot-Users] Revised custodian git writeup

[Jerry Van Baren]

Haavard Skinnemoen wrote:
> On Tue, 22 Jan 2008 09:55:33 +0100
> Wolfgang Denk <wd@denx.de> wrote:
> 
>> Rebasing the master branch, i. e. the one I'll be pullung from?
>>
>> Are you sure that is a good idea? Note that I (and probably others)
>> will be pulling from that branch, and not only once!
> 
> That depends on whether or not you want your commit history filled with
> "merge with upstream/master" crap or not.
> 
> You should only pull when explicitly requested to do so. In that case,
> if the branch was newly rebased, there will be a clean, linear history
> from the tip of your master branch to the tip of the one being pulled.
> 
> If there are conflicting changes and the merge needs manual
> intervention, you abort the merge and tell the one sending the pull
> request that it didn't merge cleanly, please rebase.
> 
>>        When you rebase a branch, you are changing its history in a
>>        way that will cause problems for anyone who already has a copy
>>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        of the branch in their repository and tries to pull updates
>>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        from you. You should understand the implications of using git
>>        ^^^^^^^^^
>>        rebase on a repository that you share.
> 
> And that is, IMO, exactly why you shouldn't be pulling from the master
> branch in the first place. People who pull regularly to test stuff that
> is in progress will run into this problem, and they are most likely to
> pull the master branch because that's the default.
> 
> There are two different kinds of users involved here: You (and other
> maintainers that are "upstream" from someone), and regular users who
> want to test stuff. Upstream maintainers should receive a clean
> history, i.e. from a branch that is frequently rebased. At the same
> time, we should avoid exposing testers to the problems of dealing with
> a branch that is rebased all the time.

I don't see this as a big deal because my methodology (and the proper 
one, IMHO) is to create a branch in my local repo, pull the current 
state of the target repo into the branch, and then either merge or 
cherrypick the "foreign" subrepo changes into my working branch in my 
repo.  At that point, I discard the foreign repo branch because it has 
served its purpose.  Because I discard the foreign repo branch, I don't 
care of the foreign repo gets rebased and its history is rewritten, I've 
already discarded that history.

If more things change in the foreign repo, I do the same thing over, 
starting with creating a new branch.

I'm sure that is how Wolfgang pulls subrepos to - not directly, but into 
a testing branch and then, if it is OK, into the main u-boot.git repo.

Here are my Cliff Notes(R) for a real example of this interaction with 
u-boot.git and between myself and Kumar, pulling his libfdt updates into 
my u-boot-fdt.git repo:
<http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#All_Your_Base_are_Belong_to_Us>

This ultimately was merged by Wolfgang into u-boot.git with no problems 
(yet ;-).

> So we need (at least) two different branches that are maintained in
> different ways, and I think it's easier to tell you, Wolfgang and other
> upstream maintainers, to pull from a non-master branch than to tell
> everyone else in the world.
> 
> Just my two cents.
> 
> Haavard

+ my 2c,
gvb

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

In message <4795F495.70101@ge.com> you wrote:
>
> I'm sure that is how Wolfgang pulls subrepos to - not directly, but into 
> a testing branch and then, if it is OK, into the main u-boot.git repo.

Not exactly - insteadof or ratherin addition to brnaches I also use
several copies of repositories which I can throw away if needed.

In one such copy I follow all custodian repos using  remote  tracking
branches.  This  is  also  used  to  pull from such a remote tracking
branch if I'm ordered to pull from a custodian's repo. If this causes
problems, I'll shout on the ML and either clean up or even throw away
the whole repo. If it works, I'll pull  this  repo  into  the  mailin
repo.

The reason for using additional copies of repos  instead  of  branche
scomes  from  the fact that (1) I used to use cogito for a long time,
which handled branches differently, and (2) I have seen a  copule  of
situations (with earlier versions of git and cogito) that corrupted a
repository  such  that  I was not able to repair it. So I try to make
sure I can always throw away everything...


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
Pig: An animal (Porcus omnivorous) closely allied to the  human  race
by  the splendor and vivacity of its appetite, which, however, is in-
ferior in scope, for it balks at pig.                - Ambrose Bierce

[U-Boot-Users] Revised custodian git writeup

[Jerry Van Baren]

Wolfgang Denk wrote:
> Hello,
> 
> in message <47954A7D.4070507@gmail.com> you wrote:
>> I've rewritten the "Tips for maintaining custodian trees" section to 
>> reflect Wolfgang's request that the "master" branch be used for patches 
>> for him to pull.
>>
>> Conceptually, this is very different from my previous recommendation / 
>> methodology writeup.  In practice, however, it is a trivial change.  The 
>> fundamental difference is to create a separate branch ("uboot") to track 
>> the master repo and rebase the "master" branch against that, instead of 
>> vice versa.
> 
> Rebasing the master branch, i. e. the one I'll be pullung from?
> 
> Are you sure that is a good idea? Note that I (and probably others)
> will be pulling from that branch, and not only once!
> 
> Quote from the git-rebase man page:
> 
> ...
> NOTES
>        When you rebase a branch, you are changing its history in a
>        way that will cause problems for anyone who already has a copy
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        of the branch in their repository and tries to pull updates
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        from you. You should understand the implications of using git
>        ^^^^^^^^^
>        rebase on a repository that you share.
> ...
> 
> Best regards,
> Wolfgang Denk

Well, that is what I understood you to be asking for, and it worked this 
past merge window.  That could have been luck, but I suspect not.

The conflicting requirements are:
1) Wolfgang wishes to pull from the subrepo "master" branch
2) Subrepository custodians must rebase to pull the latest changes and 
fix any merge conflicts so that Wolfgang's pulls don't have merge conflicts.

I don't believe the rebasing will cause problems because the rebasing is 
pulling from the u-boot.git master repository (or possibly 
u-boot-testing.git) which is rebuilding the subrepo "uboot" branch to 
match the u-boot.git master, and then rebasing the subrepo "master" 
based on the u-boot.git master.  This will make the subrepo "master" 
*match* the u-boot.git master *plus* append the new patches to be pulled.

I think the difference with our use vs. the general case that the 
warning applies to is that the custodians are making their "master" 
branch conform exactly to the u-boot.git master branch and then adding 
on the patches to be pulled.

Disclaimer: The following is my reasoning, *not* experience, and could 
be full of "stuff."

In the general (problematic) case, I think the problem is that someone 
snapshots a branch (clones / pulls), that branch gets rewritten in a way 
that doesn't match the snapshot, and then a follow-on pull will fail. 
The easiest solution in that case is to use the -f force flag, which 
will rewrite the local branch to match the rebased master.

The two differences, as I see it, are:
1) Wolfgang's u-boot.git is The Master, the custodian repos conform to 
that.  (If things get messed up, with a -f force, but that shouldn't 
happen I don't think.)
2) We are interested in feeding patches to u-boot.git, not with 
preserving the history of our custodian repos.

Illustration:

|<--- tracks u-boot.git, changes -->|<--- subrepo patches --->|
---o----o----o----o---o---o----o----o----o---o----o---o---o---o

Since Wolfgang pulls the new patches into u-boot.git and the subrepo 
"merge" branch tracks u-boot.git, he will get (should get | has gotten) 
the new patches with no problems.

The eye opening thing about git for me has been its changeset 
methodology (suh-weet, as jdl would say ;-) and its hash identification 
of the changesets so it can track what it has already applied and Do The 
Right Thing[tm].

Best regards,
gvb

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

Dear Jerry,

in message <4795F081.5050204@ge.com> you wrote:
>
> The conflicting requirements are:
> 1) Wolfgang wishes to pull from the subrepo "master" branch

...and others will do that, too, at unknown points of time.

> 2) Subrepository custodians must rebase to pull the latest changes and 
> fix any merge conflicts so that Wolfgang's pulls don't have merge conflicts.

...must rebase their working branch(es), but there is no need that
I'll be pulling from exactly this/these branches.

As explained before, my idea is that the custodians will merge  their
code  into the master branch (a) for others to test it and (b) for me
to pull from. 

> I don't believe the rebasing will cause problems because the rebasing is 
> pulling from the u-boot.git master repository (or possibly 
> u-boot-testing.git) which is rebuilding the subrepo "uboot" branch to 
> match the u-boot.git master, and then rebasing the subrepo "master" 
> based on the u-boot.git master.  This will make the subrepo "master" 
> *match* the u-boot.git master *plus* append the new patches to be pulled.

The idea of rebasing the master branch is something that find
frightening.

> I think the difference with our use vs. the general case that the 
> warning applies to is that the custodians are making their "master" 
> branch conform exactly to the u-boot.git master branch and then adding 
> on the patches to be pulled.

I'm ot sure if I want to have such a requirement.

> Disclaimer: The following is my reasoning, *not* experience, and could 
> be full of "stuff."
> 
> In the general (problematic) case, I think the problem is that someone 
> snapshots a branch (clones / pulls), that branch gets rewritten in a way 
> that doesn't match the snapshot, and then a follow-on pull will fail. 

This is why I think that master should never be rebased. "master" is
(IMO) supposed to always provide a consistent history.

> The two differences, as I see it, are:
> 1) Wolfgang's u-boot.git is The Master, the custodian repos conform to 
> that.  (If things get messed up, with a -f force, but that shouldn't 
> happen I don't think.)
> 2) We are interested in feeding patches to u-boot.git, not with 
> preserving the history of our custodian repos.

Wrong. I *am* interested in preserving the history of  the  custodian
repos.  Somebody mostly interested in ARM processors shall be able to
use the ARM custodian's repo for all his daily work exactly the  same
way as he could use the main repo.

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
The only way you could make a happy  marriage  is  by  cuttin'  their
heads  off  as  soon  as  they say `I do', yes? You can't make happi-
ness...                           - Terry Pratchett, _Witches Abroad_

[U-Boot-Users] Revised custodian git writeup

[Markus Klotzbücher]

Dear Wolfgang,

Wolfgang Denk <wd@denx.de> writes:

> in message <4795F081.5050204@ge.com> you wrote:

>> I think the difference with our use vs. the general case that the 
>> warning applies to is that the custodians are making their "master" 
>> branch conform exactly to the u-boot.git master branch and then adding 
>> on the patches to be pulled.
>
> I'm ot sure if I want to have such a requirement.

Not doing this makes it hard to use git-request-pull to generate these
cute summaries in case you repeatedly update->merge-a-patch.

Best regards

     Markus

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

In message <87myqyx7fp.fsf@denx.de> you wrote:
> 
> Not doing this makes it hard to use git-request-pull to generate these
> cute summaries in case you repeatedly update->merge-a-patch.

You're suppoed to merge it only when you're done with it - see my
previous message: consider merging into your master branch as the
first step of my pulling from your tree.

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
The biggest difference between time and space is that you can't reuse
time.                                                 - Merrick Furst

[U-Boot-Users] Revised custodian git writeup

[Jerry Van Baren]

Wolfgang Denk wrote:
> In message <87myqyx7fp.fsf@denx.de> you wrote:
>> Not doing this makes it hard to use git-request-pull to generate these
>> cute summaries in case you repeatedly update->merge-a-patch.
> 
> You're suppoed to merge it only when you're done with it - see my
> previous message: consider merging into your master branch as the
> first step of my pulling from your tree.
> 
> Best regards,
> Wolfgang Denk

...but this is a contradiction again.  Quoting from different WD emails:

> As explained before, my idea is that the custodians will merge  their
> code  into the master branch (a) for others to test it and (b) for me
> to pull from. 

> You're suppoed to merge it only when you're done with it - see my
> previous message: consider merging into your master branch as the
> first step of my pulling from your tree.

> To me, your master branch is your "stable" code. Code that needs more
> testing should use a different branch name. Especially  if  you  have
> different pots on the fire at the same time.

1) Master branch is for others to actively base from
2) Master branch is updated just before a pull request
3) No merge conflicts with the u-boot.git repo when Wolfgang pulls it

These appear to be contradictory goals.  #1 and #2 could be argued to 
not be contradictory, but I'm not buying into that theory.  The point of 
people pulling and testing is to find problem, which should be fixed 
*before* a pull request.  If the master branch has broken code in it, 
the broken patch will have to be replaced with a fixed patch (rewriting 
history - oh-oh) or the fix will have to be added as another patch (ugly 
and potentially breaking git-bisect).

I'm not sure what happens (how git handles it) if patches are applied in 
different orders.  What I'm thinking about is if custodians #1 and #2 
both issue a pull request.  Wolfgang pulls #1 and then #2.  What happens 
to #2 when he does a merge with the master u-boot.git?  Does git insert 
custodian #1 patches ahead of his existing (#2) patches, or do the 
patches end up in a different order in the repos?

Then there is the merge conflict, which will be a result of the order 
that Wolfgang pulls from the custodian repos.  How does a custodian 
resolve a merge conflict without changing his branch's history?

In my mind, custodian repos should be (must be?) faithful slaves of the 
master u-boot.git repo - always the current u-boot.git + "value added" 
(to the best of the custodian's ability to keep up with Wolfgang ;-). 
The custodian always keeps the "value added" patches at the tip of the 
tree so that they are clearly identified.

Third party developers can clone u-boot.git, create a branch and pull 
the custodian's "value added" branch (master or otherwise), and merge or 
cherry-pick the "value added" patches.  While we have not poked into the 
dark corners of this technique, Kim, Kumar, myself, and Wolfgang 
(unwittingly for Wolfgang) have done this and it has Just Worked[tm].

-------

FWIIW, my repo seems to have worked fine in this merge window.  I 
actually have two u-boot-fdt repos: a "mirror" copy I synchronize 
against git://www.denx.de/git/u-boot-fdt.git nightly and a working repo 
(with local branches).  This allows me to watch what is officially 
advertised, allows me to recover if I shit my working repo.

1) I rebased my working repo against u-boot.git, pushed my "master" 
branch to denx.de, then issued a pull request.
  * My "to pull" patches were at the tip of the tree

2) Wolfgang pulled my changes into u-boot.git

3) I did the rebase of my working repo using a "uboot" branch to pull 
the lastest u-boot.git changes and then rebasing my working repo's 
"mster" branch.  I did that just now, so it has all of everybody's changes.

4) I pushed my working repo's master branch back to denx.de - my 
custodian repo now matches the master u-boot.git repo (not verified 
bit-for-bit, but it appears to be done right).

5) I pulled git://www.denx.de/git/u-boot-fdt.git into my "mirror" copy.

All of this Just Worked[tm] with no errors.  While it could be argued 
that I rewrote history with my rebasing, I believe this is a good thing 
- all of our repos should match (at least on the master branches) and 
IMHO all of our histories should match at the point that the merge 
window closes.  Emperically, git handled this "history rewriting" with 
no (apparent) errors.

-------

I've added a link "Intro to Distributed Version Control (Illustrated)" 
to the Custodian page:
<http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/>

This is somewhat helpful, but doesn't talk about what happens to the 
custodian repositories after the patches are pulled into the master 
repository.

Best regards,
gvb
(going home to soak my brain in ethanol)

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

In message <4796726E.9030501@ge.com> you wrote:
>
> 1) Master branch is for others to actively base from

others = mostly users aka non-developers

> 2) Master branch is updated just before a pull request

not necessarily only then, but updates should contain code that is
considered to be "good" from the custodian's point of view

> 3) No merge conflicts with the u-boot.git repo when Wolfgang pulls it

Ideally, yes.

> These appear to be contradictory goals.  #1 and #2 could be argued to 
> not be contradictory, but I'm not buying into that theory.  The point of 
> people pulling and testing is to find problem, which should be fixed 
> *before* a pull request.  If the master branch has broken code in it, 

Agreed. Please see previous messages.  My  idea  is  that  the  maste
rbranch  can  be  consider as kind of a "stable" branch - it is ahead
compared to the main repo in regards to the the  custodian's  special
topic,  but  considered stable. For testing, other branches should be
used (probably with an explicit "-testing" in their name).

> I'm not sure what happens (how git handles it) if patches are applied in 
> different orders.  What I'm thinking about is if custodians #1 and #2 

git has no notation of order or sequence. It is storing content only.
If you apply  N  independent,  non-overlapping  patches  in  arbitray
order,  the result will be the same. The individual commits will have
different ID's, but who cares?

> both issue a pull request.  Wolfgang pulls #1 and then #2.  What happens 
> to #2 when he does a merge with the master u-boot.git?  Does git insert 
> custodian #1 patches ahead of his existing (#2) patches, or do the 
> patches end up in a different order in the repos?

It doesn't matter as long as there are no conflicts.

> Then there is the merge conflict, which will be a result of the order 
> that Wolfgang pulls from the custodian repos.  How does a custodian 
> resolve a merge conflict without changing his branch's history?

That's a good point. I have to think about that one...

> (going home to soak my brain in ethanol)

The brain or the liver?

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
"Deliver yesterday, code today, think tomorrow."

[U-Boot-Users] Revised custodian git writeup

[gvb.uboot]

Wolfgang Denk wrote:
> In message <4796726E.9030501@ge.com> you wrote:

[snip]

>> I'm not sure what happens (how git handles it) if patches are applied in 
>> different orders.  What I'm thinking about is if custodians #1 and #2 
> 
> git has no notation of order or sequence. It is storing content only.
> If you apply  N  independent,  non-overlapping  patches  in  arbitray
> order,  the result will be the same. The individual commits will have
> different ID's, but who cares?
> 
>> both issue a pull request.  Wolfgang pulls #1 and then #2.  What happens 
>> to #2 when he does a merge with the master u-boot.git?  Does git insert 
>> custodian #1 patches ahead of his existing (#2) patches, or do the 
>> patches end up in a different order in the repos?
> 
> It doesn't matter as long as there are no conflicts.

I haven't played with git to see what it does with patches in different 
orders, but I'm not happy if my history doesn't match your history, it 
makes it tremendously harder to do comparisons of a custodian vs. the 
master repo.  If the two are the same, not a big deal.  If I need to 
figure out why they are different... OUCH.

>> Then there is the merge conflict, which will be a result of the order 
>> that Wolfgang pulls from the custodian repos.  How does a custodian 
>> resolve a merge conflict without changing his branch's history?
> 
> That's a good point. I have to think about that one...

OK, I probably should confess that that was mostly a strawman.

>> (going home to soak my brain in ethanol)
> 
> The brain or the liver?

The brain, the liver is unfortunate collateral damage.  Wish I could 
change history on that!  ;-)

> Best regards,
> 
> Wolfgang Denk

Best regards,
gvb

[U-Boot-Users] Revised custodian git writeup

[Martin Krause]

u-boot-users-bounces at lists.sourceforge.net wrote on :
> > I'm not sure what happens (how git handles it) if patches are
> > applied in different orders.  What I'm thinking about is if
> > custodians #1 and #2 
> 
> git has no notation of order or sequence. It is storing content only.
> If you apply  N  independent,  non-overlapping  patches  in  arbitray
> order,  the result will be the same. The individual commits will have
> different ID's, but who cares?

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
the same commit ID as a patch in the other repository i know for sure,
that my and the other repository are exactly the same (from the
beginnig till the compared patch). If the commit IDs in my repository
have no correspondent in the other repository (because the order of
the patches is different), I know nothing. Even if I find a patch 
with the same commit message, I don't know for sure if the patches 
are the same. Maybe in the other repository is the original patch and
in my repository is an updated version (with the same commit message).
I don't know. 

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
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?

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
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
to know from wich git repository the U-Boot was built, to identify
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. 

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.

Best Regards,
Martin Krause

[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

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

[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@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

[U-Boot-Users] Revised custodian git writeup

[Haavard Skinnemoen]

On Wed, 23 Jan 2008 18:27:11 +0100
"Martin Krause" <Martin.Krause@tqs.de> wrote:

> > > 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?

Use the SHA1 of the top-level tree instead of the commit. Or just use
git diff.

Haavard

[U-Boot-Users] Revised custodian git writeup

[Haavard Skinnemoen]

On Tue, 22 Jan 2008 15:03:45 +0100
Wolfgang Denk <wd@denx.de> wrote:

> As explained before, my idea is that the custodians will merge  their
> code  into the master branch (a) for others to test it and (b) for me
> to pull from. 

And as I've tried to explain, I think those two purposes are
conflicting since having a single branch for everything means either
(a) only code that has already been tested goes into the master branch,
or (b) you get to pull untested code.

Haavard

[U-Boot-Users] Revised custodian git writeup

[Jerry Van Baren]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>> Hello,
>>
>> in message <47954A7D.4070507@gmail.com> you wrote:
>>> I've rewritten the "Tips for maintaining custodian trees" section to 
>>> reflect Wolfgang's request that the "master" branch be used for patches 
>>> for him to pull.
>>>
>>> Conceptually, this is very different from my previous recommendation / 
>>> methodology writeup.  In practice, however, it is a trivial change.  The 
>>> fundamental difference is to create a separate branch ("uboot") to track 
>>> the master repo and rebase the "master" branch against that, instead of 
>>> vice versa.
>> Rebasing the master branch, i. e. the one I'll be pullung from?
>>
>> Are you sure that is a good idea? Note that I (and probably others)
>> will be pulling from that branch, and not only once!
>>
>> Quote from the git-rebase man page:
>>
>> ...
>> NOTES
>>        When you rebase a branch, you are changing its history in a
>>        way that will cause problems for anyone who already has a copy
>>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        of the branch in their repository and tries to pull updates
>>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>        from you. You should understand the implications of using git
>>        ^^^^^^^^^
>>        rebase on a repository that you share.
>> ...
>>
>> Best regards,
>> Wolfgang Denk
> 
> Well, that is what I understood you to be asking for, and it worked this 
> past merge window.  That could have been luck, but I suspect not.
> 
> The conflicting requirements are:
> 1) Wolfgang wishes to pull from the subrepo "master" branch
> 2) Subrepository custodians must rebase to pull the latest changes and 
> fix any merge conflicts so that Wolfgang's pulls don't have merge conflicts.
> 
> I don't believe the rebasing will cause problems because the rebasing is 
> pulling from the u-boot.git master repository (or possibly 
> u-boot-testing.git) which is rebuilding the subrepo "uboot" branch to 
> match the u-boot.git master, and then rebasing the subrepo "master" 
> based on the u-boot.git master.  This will make the subrepo "master" 
> *match* the u-boot.git master *plus* append the new patches to be pulled.
> 
> I think the difference with our use vs. the general case that the 
> warning applies to is that the custodians are making their "master" 
> branch conform exactly to the u-boot.git master branch and then adding 
> on the patches to be pulled.

Adding to this thought, rebasing a custodian repo rewrites its history 
*to match the master u-boot.git repo* (and then add to it).  Based on my 
limited knowledge and experience, I think that is a *good* thing.

If we don't "rewrite" our custodian histories to match the master 
u-boot.git repo history, very quickly it will be impossible to compare 
the custodian repo to the master because the patches will be in 
different order.

We are your slaves,
gvb