[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi All,

I've asked Wolfgang the following, but it looks like he's just too snowed
under at the moment...

Somehow I've managed to do something 'interesting' to the u-boot-x86
repository - It has duplicate patches.

He's the sequence of events leading up to the problem

$ git fetch u-boot
remote: Counting objects: 2330, done.
remote: Compressing objects: 100% (483/483), done.
remote: Total 1820 (delta 1383), reused 1735 (delta 1305)
Receiving objects: 100% (1820/1820), 450.98 KiB | 32 KiB/s, done.
Resolving deltas: 100% (1383/1383), completed with 390 local objects.

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
> error: refs/tags/2009.01-rc2 does not point to a valid object!

this tag seems to have bled into some people's repos ... i'd suggest you punt 
it locally:
	git tag -d 2009.01-rc2
and then punt it remotely:
	git push <remote_uri> :2009.01-rc2

> $ git fetch u-boot
> ...
> $ git rebase u-boot/master
> ...
> $ git push ssh://gu-x86 at git.denx.de/u-boot-x86
> ...
> To ssh://gu-x86 at git.denx.de/u-boot-x86
>  ! [rejected]        master -> master (non-fast-forward)

well, you did a rebase, so this is kind of par for the course.  use --force to 
rewrite the published branch.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111128/93290bca/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
>> error: refs/tags/2009.01-rc2 does not point to a valid object!
>
> this tag seems to have bled into some people's repos ... i'd suggest you punt
> it locally:
> ? ? ? ?git tag -d 2009.01-rc2
> and then punt it remotely:
> ? ? ? ?git push <remote_uri> :2009.01-rc2

Ah, thanks

>
>> $ git fetch u-boot
>> ...
>> $ git rebase u-boot/master
>> ...
>> $ git push ssh://gu-x86 at git.denx.de/u-boot-x86
>> ...
>> To ssh://gu-x86 at git.denx.de/u-boot-x86
>> ?! [rejected] ? ? ? ?master -> master (non-fast-forward)
>
> well, you did a rebase, so this is kind of par for the course. ?use --force to
> rewrite the published branch.

So how do you keep the sub-repo up-to-date with u-boot/master without
doing forced pushes?

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Monday 28 November 2011 18:05:00 Graeme Russ wrote:
> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote:
> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
> >> $ git fetch u-boot
> >> ...
> >> $ git rebase u-boot/master
> >> ...
> >> $ git push ssh://gu-x86 at git.denx.de/u-boot-x86
> >> ...
> >> To ssh://gu-x86 at git.denx.de/u-boot-x86
> >>  ! [rejected]        master -> master (non-fast-forward)
> > 
> > well, you did a rebase, so this is kind of par for the course.  use
> > --force to rewrite the published branch.
> 
> So how do you keep the sub-repo up-to-date with u-boot/master without
> doing forced pushes?

you don't :).  the way *i* work is to keep my changes in my own branch that i 
rewrite, and then once i want to send that to Wolfgang, i publish the updated 
master branch for him to pull from.

i think the u-boot wiki has a "suggested maintainer workflow", but i haven't 
looked too hard at that as i like (logically) how i do things now.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111128/247ea350/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Andy Fleming]

On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 28 November 2011 18:05:00 Graeme Russ wrote:
>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote:
>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
>> >> $ git fetch u-boot
>> >> ...
>> >> $ git rebase u-boot/master
>> >> ...
>> >> $ git push ssh://gu-x86 at git.denx.de/u-boot-x86
>> >> ...
>> >> To ssh://gu-x86 at git.denx.de/u-boot-x86
>> >> ?! [rejected] ? ? ? ?master -> master (non-fast-forward)
>> >
>> > well, you did a rebase, so this is kind of par for the course. ?use
>> > --force to rewrite the published branch.
>>
>> So how do you keep the sub-repo up-to-date with u-boot/master without
>> doing forced pushes?
>
> you don't :). ?the way *i* work is to keep my changes in my own branch that i
> rewrite, and then once i want to send that to Wolfgang, i publish the updated
> master branch for him to pull from.
>
> i think the u-boot wiki has a "suggested maintainer workflow", but i haven't
> looked too hard at that as i like (logically) how i do things now.

Yes, I only push up changes that I don't intend will ever be changed.

Unless I forget.

If your tree contains changes that aren't yet in Wolfgang's tree, but
*are* published in your upstream tree, then you can try:

git merge u-boot/master.

It should work, as long as your patches can still be pulled into his
tree, cleanly.

Andy

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

On Tue, Nov 29, 2011 at 10:16 AM, Andy Fleming <afleming@gmail.com> wrote:
> On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Monday 28 November 2011 18:05:00 Graeme Russ wrote:
>>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote:
>>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
>>> >> $ git fetch u-boot
>>> >> ...
>>> >> $ git rebase u-boot/master
>>> >> ...
>>> >> $ git push ssh://gu-x86 at git.denx.de/u-boot-x86
>>> >> ...
>>> >> To ssh://gu-x86 at git.denx.de/u-boot-x86
>>> >> ?! [rejected] ? ? ? ?master -> master (non-fast-forward)
>>> >
>>> > well, you did a rebase, so this is kind of par for the course. ?use
>>> > --force to rewrite the published branch.
>>>
>>> So how do you keep the sub-repo up-to-date with u-boot/master without
>>> doing forced pushes?
>>
>> you don't :). ?the way *i* work is to keep my changes in my own branch that i
>> rewrite, and then once i want to send that to Wolfgang, i publish the updated
>> master branch for him to pull from.
>>
>> i think the u-boot wiki has a "suggested maintainer workflow", but i haven't
>> looked too hard at that as i like (logically) how i do things now.
>
> Yes, I only push up changes that I don't intend will ever be changed.

Well, that is my intent too :)

> Unless I forget.
>
> If your tree contains changes that aren't yet in Wolfgang's tree, but
> *are* published in your upstream tree, then you can try:
>
> git merge u-boot/master.

So is that in lieu of rebase?

> It should work, as long as your patches can still be pulled into his
> tree, cleanly.

Well they should (this time) - They are all very isolated to x86, and
nobody else has touch that recently

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Monday 28 November 2011 18:20:51 Graeme Russ wrote:
> On Tue, Nov 29, 2011 at 10:16 AM, Andy Fleming wrote:
> > On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger wrote:
> >> On Monday 28 November 2011 18:05:00 Graeme Russ wrote:
> >>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote:
> >>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
> >>> >> $ git fetch u-boot
> >>> >> ...
> >>> >> $ git rebase u-boot/master
> >>> >> ...
> >>> >> $ git push ssh://gu-x86 at git.denx.de/u-boot-x86
> >>> >> ...
> >>> >> To ssh://gu-x86 at git.denx.de/u-boot-x86
> >>> >>  ! [rejected]        master -> master (non-fast-forward)
> >>> > 
> >>> > well, you did a rebase, so this is kind of par for the course.  use
> >>> > --force to rewrite the published branch.
> >>> 
> >>> So how do you keep the sub-repo up-to-date with u-boot/master without
> >>> doing forced pushes?
> >> 
> >> you don't :).  the way *i* work is to keep my changes in my own branch
> >> that i rewrite, and then once i want to send that to Wolfgang, i
> >> publish the updated master branch for him to pull from.
> >> 
> >> i think the u-boot wiki has a "suggested maintainer workflow", but i
> >> haven't looked too hard at that as i like (logically) how i do things
> >> now.
> > 
> > Yes, I only push up changes that I don't intend will ever be changed.
> 
> Well, that is my intent too :)

you can never rebase+publish that branch then

> > Unless I forget.
> > 
> > If your tree contains changes that aren't yet in Wolfgang's tree, but
> > *are* published in your upstream tree, then you can try:
> > 
> > git merge u-boot/master.
> 
> So is that in lieu of rebase?

yes, if you want to get updates from mainline before asking Wolfgang to do a 
pull request on your branch

note: you don't have to publish the merge/rebasing work.  let's say you have 3 
patches in your x86 master (published).  locally, you get Wolfgang's updated 
master, verify things still work, and then send a pull request for the already 
published branch (not for your local work which includes a merge commit).  
once Wolfgang pulls & pushes that update, you can fetch Wolfgang's master and 
then rebase on top of that.  in this case, the only thing being thrown away is 
your local merge commits because Wolfgang included your other changes.

this can be a bit confusing as it delves deeply into distributed scm 
subtleties, so if you want, i can clarify points from above ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111128/efb14f02/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Tue, Nov 29, 2011 at 10:43 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 28 November 2011 18:20:51 Graeme Russ wrote:
>> On Tue, Nov 29, 2011 at 10:16 AM, Andy Fleming wrote:
>> > On Mon, Nov 28, 2011 at 5:13 PM, Mike Frysinger wrote:
>> >> On Monday 28 November 2011 18:05:00 Graeme Russ wrote:
>> >>> On Tue, Nov 29, 2011 at 10:02 AM, Mike Frysinger wrote:
>> >>> > On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
>> >>> >> $ git fetch u-boot
>> >>> >> ...
>> >>> >> $ git rebase u-boot/master
>> >>> >> ...
>> >>> >> $ git push ssh://gu-x86 at git.denx.de/u-boot-x86
>> >>> >> ...
>> >>> >> To ssh://gu-x86 at git.denx.de/u-boot-x86
>> >>> >>  ! [rejected]        master -> master (non-fast-forward)
>> >>> >
>> >>> > well, you did a rebase, so this is kind of par for the course.  use
>> >>> > --force to rewrite the published branch.
>> >>>
>> >>> So how do you keep the sub-repo up-to-date with u-boot/master without
>> >>> doing forced pushes?
>> >>
>> >> you don't :).  the way *i* work is to keep my changes in my own branch
>> >> that i rewrite, and then once i want to send that to Wolfgang, i
>> >> publish the updated master branch for him to pull from.
>> >>
>> >> i think the u-boot wiki has a "suggested maintainer workflow", but i
>> >> haven't looked too hard at that as i like (logically) how i do things
>> >> now.
>> >
>> > Yes, I only push up changes that I don't intend will ever be changed.
>>
>> Well, that is my intent too :)
>
> you can never rebase+publish that branch then
>
>> > Unless I forget.
>> >
>> > If your tree contains changes that aren't yet in Wolfgang's tree, but
>> > *are* published in your upstream tree, then you can try:
>> >
>> > git merge u-boot/master.
>>
>> So is that in lieu of rebase?
>
> yes, if you want to get updates from mainline before asking Wolfgang to do a
> pull request on your branch
>
> note: you don't have to publish the merge/rebasing work.  let's say you have 3
> patches in your x86 master (published).  locally, you get Wolfgang's updated
> master, verify things still work, and then send a pull request for the already
> published branch (not for your local work which includes a merge commit).
> once Wolfgang pulls & pushes that update, you can fetch Wolfgang's master and
> then rebase on top of that.  in this case, the only thing being thrown away is
> your local merge commits because Wolfgang included your other changes.
>
> this can be a bit confusing as it delves deeply into distributed scm

You are correct - I am totally confused by all of this :(

> subtleties, so if you want, i can clarify points from above ...

Yes, that would be nice :)

I think a few concrete examples with git commands to illustrate would be
helpful. What I am thinking of doing is something along the lines of:

> cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo)
> git fetch u-boot (as per the 'new' methodology of not having a seperate
u-boot branch)
> git checkout master
> git rebase u-boot/master
> git push ssh://gu-x86 at git.denx.de/u-boot-x86
> git checkout next
> git rebase master
> git push ssh://gu-x86 at git.denx.de/u-boot-x86

Do the above periodically so anyone working off u-boot-x86 can keep
up-to-date

And when I'm happy with a patchwork patch, do the above and then:

> git am <patches downloaded from patchwork only>
> git push ssh://gu-x86 at git.denx.de/u-boot-x86

My local u-boot-x86/master branch will only ever contains patches that
are ready to be pulled by Wolfgang

And for my day-to-day development:

> git checkout dev
> git rebase master
> stg new/pop/push/delete/squash etc...

My local u-boot-x86/dev branch has lots of rubbish - usually an stg stack
a mile long of various experimental stuff - I actually have multiple dev
branches. I like to pull the patches ready for upstreaming into those
branches first just to see what I am up against when the new patches go
live.

But this seems to cause the 'must force the push' problem...

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Monday 28 November 2011 19:02:20 Graeme Russ wrote:
> > cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo)
> > git fetch u-boot (as per the 'new' methodology of not having a seperate
> > u-boot branch)
> > git checkout master
> > git rebase u-boot/master
> > git push ssh://gu-x86 at git.denx.de/u-boot-x86
> > git checkout next
> > git rebase master
> > git push ssh://gu-x86 at git.denx.de/u-boot-x86

ok, i've read the official recommended workflow [1].  it seems to contradict 
itself.  for example, it starts with:
	Philosophy of custodian trees
	... it is the custodian's responsibility to provide a permanently
	accessible, consistent view of his repository to users.

i read that as saying "no rewriting of published history".  but later on it 
says to do just that:
	Tips for maintaining custodian trees
	- Keep in sync with the upstream repository by pulling it.
	- Rebase the master, testing and any "work in progress" branches to the
	${upstream}/master remote branch.
	- Push the appropriate branch(es) to the denx.de repo:
		- Pushing the testing and/or rebased master branches often requires
		the -f force flag. This is because the state/content/order of the
		patches in the branch changed due to the rebase operations.

so i guess your example workflow is fine, you just need to use the --force flag.  
and you should specify the branches to push rather than leaving that to be 
implicit.  so change:
	git push ssh://gu-x86 at git.denx.de/u-boot-x86
to:
	git push --force ssh://gu-x86 at git.denx.de/u-boot-x86 next
	git push --force ssh://gu-x86 at git.denx.de/u-boot-x86 master

> Do the above periodically so anyone working off u-boot-x86 can keep
> up-to-date

the expected behavior of downstream users is apparently to always fetch+rebase 
rather than fetch+merge (what "pull" normally does).  this is pretty unusual 
(and in most git circles, unforgivable as the "default" workflow).  but as i'm 
not a consumer of any of these trees except Wolfgang's, i'm not going to argue 
over it.  so your x86 users have to do (assuming they've cloned your tree):
	git fetch
	git rebase origin/master

instead of the more normal:
	git pull
-mike

[1] http://www.denx.de/wiki/U-Boot/CustodianGitTrees
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111128/165980f9/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Tue, Nov 29, 2011 at 2:31 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 28 November 2011 19:02:20 Graeme Russ wrote:
>> > cd Source/U-Boot/x86 (my local version of the u-boot-x86 repo)
>> > git fetch u-boot (as per the 'new' methodology of not having a seperate
>> > u-boot branch)
>> > git checkout master
>> > git rebase u-boot/master
>> > git push ssh://gu-x86 at git.denx.de/u-boot-x86
>> > git checkout next
>> > git rebase master
>> > git push ssh://gu-x86 at git.denx.de/u-boot-x86
>
> ok, i've read the official recommended workflow [1].  it seems to contradict
> itself.  for example, it starts with:
>        Philosophy of custodian trees
>        ... it is the custodian's responsibility to provide a permanently
>        accessible, consistent view of his repository to users.
>
> i read that as saying "no rewriting of published history".  but later on it
> says to do just that:
>        Tips for maintaining custodian trees
>        - Keep in sync with the upstream repository by pulling it.
>        - Rebase the master, testing and any "work in progress" branches to the
>        ${upstream}/master remote branch.
>        - Push the appropriate branch(es) to the denx.de repo:
>                - Pushing the testing and/or rebased master branches often requires
>                the -f force flag. This is because the state/content/order of the
>                patches in the branch changed due to the rebase operations.
>
> so i guess your example workflow is fine, you just need to use the --force flag.
> and you should specify the branches to push rather than leaving that to be
> implicit.  so change:
>        git push ssh://gu-x86 at git.denx.de/u-boot-x86
> to:
>        git push --force ssh://gu-x86 at git.denx.de/u-boot-x86 next
>        git push --force ssh://gu-x86 at git.denx.de/u-boot-x86 master
>
>> Do the above periodically so anyone working off u-boot-x86 can keep
>> up-to-date
>
> the expected behavior of downstream users is apparently to always fetch+rebase
> rather than fetch+merge (what "pull" normally does).  this is pretty unusual
> (and in most git circles, unforgivable as the "default" workflow).  but as i'm

OK, so what would be a more acceptable workflow?

> not a consumer of any of these trees except Wolfgang's, i'm not going to argue
> over it.  so your x86 users have to do (assuming they've cloned your tree):
>        git fetch
>        git rebase origin/master
>
> instead of the more normal:
>        git pull

Ah, actually I think git pull is preferable...

And just quickly back to the problem at hand - How do I fix the 'duplicate
commits' problem I already have?

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Monday 28 November 2011 22:35:24 Graeme Russ wrote:
> On Tue, Nov 29, 2011 at 2:31 PM, Mike Frysinger wrote:
> > the expected behavior of downstream users is apparently to always
> > fetch+rebase rather than fetch+merge (what "pull" normally does).  this
> > is pretty unusual (and in most git circles, unforgivable as the
> > "default" workflow).  but as i'm
> 
> OK, so what would be a more acceptable workflow?

never rebase anything you want other people to be working off of :).  the 
downside is that any commit you've published cannot be modified.

one way around this is to have three branches:
 - one that tracks mainline, and you only add stuff when you're going to send a 
pull request to Wolfgang
 - one that keeps all your "clean" patches and gets rewritten constantly (and 
needs --force to publish)
 - one that gets all the incremental fixes that people can pull from and always 
have a consistent history, and gets merge commits

it's more work to be sure, so it's up to you how you want to develop

> And just quickly back to the problem at hand - How do I fix the 'duplicate
> commits' problem I already have?

you can either use the --force flag to push your rewritten history (in which 
case everyone downstream from you also needs to rewrite their history), or fix 
your history locally before pushing the update:
 - fetch *your* current remote master, *not* Wolfgang's master
	- normally your repo is listed as "origin" ... but you'd have to read
	.git/config to find out exactly what it is ...
 - save any patches you care about (git format-patch/etc...)
 - reset your local master to your current remote master
	$ git checkout master
	$ git reset --hard origin/master
 - apply any new changes you wanted to publish
	$ git cherry-pick <sha1>
	$ git am -3 *.patch
	...whatever...
 - push out your new local master branch that only has new changes compared to 
the already published version
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111128/f0177992/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Tue, Nov 29, 2011 at 3:01 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 28 November 2011 22:35:24 Graeme Russ wrote:
>> On Tue, Nov 29, 2011 at 2:31 PM, Mike Frysinger wrote:
>> > the expected behavior of downstream users is apparently to always
>> > fetch+rebase rather than fetch+merge (what "pull" normally does).  this
>> > is pretty unusual (and in most git circles, unforgivable as the
>> > "default" workflow).  but as i'm
>>
>> OK, so what would be a more acceptable workflow?
>
> never rebase anything you want other people to be working off of :).  the
> downside is that any commit you've published cannot be modified.

I don't see this as a downside - I always wanted to simply:

 - Sync u-boot-x86/master with u-boot/master
 - Apply patches which a 'good to go'
 - Send a pull request

I've never (intentionally) wanted to meddle with the history of u-boot-x86
(neither master or next) - I did it once deliberately to tweak a commit
message that I messed up and I have to do it now that I've fouled it up

> one way around this is to have three branches:
>  - one that tracks mainline, and you only add stuff when you're going to send a
> pull request to Wolfgang
>  - one that keeps all your "clean" patches and gets rewritten constantly (and
> needs --force to publish)
>  - one that gets all the incremental fixes that people can pull from and always
> have a consistent history, and gets merge commits
>
> it's more work to be sure, so it's up to you how you want to develop

It's not so much how I want to 'develop' but how a want to 'maintain'
u-boot-x86.

My development is done using stacked git on development branches (I'm even
considering using an entirely independent local git repo 'just in case')

With respect to u-boot-x86 - I simply want to keep it up-to-date with
mainline and 'git am' patches I've saved from patchwork

So how do I do this - Sorry, but I'm just not getting it - To me, it looks
like your assuming I want to stick to my existing (flawed) workflow. I
actually want to go back to square one and 'get it right'

>> And just quickly back to the problem at hand - How do I fix the 'duplicate
>> commits' problem I already have?
>
> you can either use the --force flag to push your rewritten history (in which
> case everyone downstream from you also needs to rewrite their history), or fix
> your history locally before pushing the update:
>  - fetch *your* current remote master, *not* Wolfgang's master
>        - normally your repo is listed as "origin" ... but you'd have to read
>        .git/config to find out exactly what it is ...
>  - save any patches you care about (git format-patch/etc...)
>  - reset your local master to your current remote master
>        $ git checkout master
>        $ git reset --hard origin/master

I don't think this will work - The remote master (i.e. u-boot-x86/master
on the denx server) has the duplicate commits already...

>  - apply any new changes you wanted to publish
>        $ git cherry-pick <sha1>
>        $ git am -3 *.patch
>        ...whatever...
>  - push out your new local master branch that only has new changes compared to
> the already published version

I think I need to, as I had in my earlier post:

$ git reset --hard <parent of first duplicat commit>
$ git push (using --force)

At this point, I want to sync the remote u-boot-x86/master to mainline,
apply the dozen or so patches and push back into the remote
u-boot-x86/master

But I'm getting lost around the whole 'how do I keep u-boot-x86/master
in sync with u-boot/master' and I'm beginning to think the answer is
closer to 'you don't - there's git magic which does wonderful things that I
as a mere mortal do not need to know' ;)

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Monday 28 November 2011 23:17:47 Graeme Russ wrote:
> My development is done using stacked git on development branches (I'm even
> considering using an entirely independent local git repo 'just in case')

that's fine.  it's just a matter of how often you want to publish patches to 
the wider world.  i publish all my bleeding edge stuff, but it's in a "next" 
style branch.

> With respect to u-boot-x86 - I simply want to keep it up-to-date with
> mainline and 'git am' patches I've saved from patchwork
> 
> So how do I do this - Sorry, but I'm just not getting it - To me, it looks
> like your assuming I want to stick to my existing (flawed) workflow. I
> actually want to go back to square one and 'get it right'

for the published branch, you'll have to have merge commits in it.  some 
people don't want any merge commits (keep everything linear), while others 
don't think really any are bad.  i'm kind of in between ... i don't mind 
merging of "good" branches.

any ways, if you want to publish your local changes with Wolfgang's latest 
changes without having Wolfgang pull it first, then you'd do:
	$ git checkout master
	$ git fetch <upstream uri>
	$ git merge u-boot/master
	$ git push <x86 uri> master
you shouldn't do this too often though otherwise you'll get a whole lot of 
merge commits cluttering up your history.  look at Wolfgang's tree starting 
around commit f9342e2c3e81d62.  that's fine for Wolfgang (since he's merging 
many trees), but imo, custodian trees shouldn't be gathering merge commits 
which are then sent to Wolfgang for merging.

i'd draw some ascii diagrams of the commit history, but i'm not sure it would 
help.  instead, run `gitk` and look at the tree on the left around the merge 
commits.  hopefully that'll clear things up.

> >  - reset your local master to your current remote master
> >        $ git checkout master
> >        $ git reset --hard origin/master
> 
> I don't think this will work - The remote master (i.e. u-boot-x86/master
> on the denx server) has the duplicate commits already...

oh, you've already published the bum history ?  i thought it was only local.  
then you'll have to do:
	$ git checkout master
	$ git rebase u-boot/master
	$ git push --force <remote uri> master
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111128/232ec7a1/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Tue, Nov 29, 2011 at 3:49 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 28 November 2011 23:17:47 Graeme Russ wrote:
>> My development is done using stacked git on development branches (I'm even
>> considering using an entirely independent local git repo 'just in case')
>
> that's fine.  it's just a matter of how often you want to publish patches to
> the wider world.  i publish all my bleeding edge stuff, but it's in a "next"
> style branch.
>
>> With respect to u-boot-x86 - I simply want to keep it up-to-date with
>> mainline and 'git am' patches I've saved from patchwork
>>
>> So how do I do this - Sorry, but I'm just not getting it - To me, it looks
>> like your assuming I want to stick to my existing (flawed) workflow. I
>> actually want to go back to square one and 'get it right'
>
> for the published branch, you'll have to have merge commits in it.  some
> people don't want any merge commits (keep everything linear), while others
> don't think really any are bad.  i'm kind of in between ... i don't mind
> merging of "good" branches.
>
> any ways, if you want to publish your local changes with Wolfgang's latest
> changes without having Wolfgang pull it first, then you'd do:
>        $ git checkout master
>        $ git fetch <upstream uri>
>        $ git merge u-boot/master
>        $ git push <x86 uri> master
> you shouldn't do this too often though otherwise you'll get a whole lot of
> merge commits cluttering up your history.  look at Wolfgang's tree starting
> around commit f9342e2c3e81d62.  that's fine for Wolfgang (since he's merging
> many trees), but imo, custodian trees shouldn't be gathering merge commits
> which are then sent to Wolfgang for merging.

Ah, now I get it - Perhaps the wiki should be changed (it has a rebase
instead of a merge). And I think this is where it all went pear-shaped for
me - I had been rebasing, but then I threw a merge into the mix

I think I need to do some reading up on 'rebase' versus 'merge' in git

So then the question becomes - what about developers doing x86 work - I
may have patches published in u-boot-x86/master which have not been pulled
by Wolfgang, but u-boot/master may also contain patches that are needed

Can you merge a local repo with multiple remotes? So could developer 'x':

$ git checkout local_dev_branch_for_feature_x
$ git fetch u-boot
$ git fetch u-boot-x86
$ git merge u-boot/master
$ git merge u-boot-x86/master
$ code...code...code
$ git format-patch
$ git send-email


> i'd draw some ascii diagrams of the commit history, but i'm not sure it would
> help.  instead, run `gitk` and look at the tree on the left around the merge
> commits.  hopefully that'll clear things up.
>
>> >  - reset your local master to your current remote master
>> >        $ git checkout master
>> >        $ git reset --hard origin/master
>>
>> I don't think this will work - The remote master (i.e. u-boot-x86/master
>> on the denx server) has the duplicate commits already...
>
> oh, you've already published the bum history ?  i thought it was only local.
> then you'll have to do:
>        $ git checkout master
>        $ git rebase u-boot/master
>        $ git push --force <remote uri> master

Hmm, I don't think this will, in and of itself, help - The duplicate
commits are all local to u-boot-x86/master (they are all x86 patches, not
u-boot patches) but I'll give it a go first...

Failing that:

$ git checkout master
$ git reset --hard <parent of initial instance of first duplicate commit>
$ git push --force <remote uri> master
$ git fetch u-boot
$ git merge u-boot/master
$ git am <patchwork patches>
$ git push <remote uri> master

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Andy Fleming]

Ignoring most of the context for the moment, I think fixing your
problem requires:

Start in your current, broken branch:
1) git branch save_broken_branch #just in case
2) git rebase -i u-boot/master

Interactive rebase will show you a long list of commits that aren't
yet in the mainline, even the duplicates.
Delete all the commits which are duplicates.

Hopefully, it completes without conflicts.

3) git diff save_broken_branch..HEAD # Should return nothing

Hope this helps. If there is a difference, then there's a chance that
somehow the merging ran into issues which it resolved in odd ways.
It's possible some of those commits are empty?  Try git log -p to see
what's actually in all of those commits.

Andy

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Tuesday 29 November 2011 00:04:12 Graeme Russ wrote:
> I think I need to do some reading up on 'rebase' versus 'merge' in git

rebase: rewrites the history by taking all of your local changes and placing 
them on top of the commit you've specified.  this ultimately produces a much 
more linear and "clean" history for people to review, but can lose information 
(the exact code base a patch was written against) and be hard to work with 
downstream.

merge: stitches together two related trees that have diverged.  adds a "merge 
commit" to the point where the two histories get stitched together.  things 
are not linear at all :).

> So then the question becomes - what about developers doing x86 work - I
> may have patches published in u-boot-x86/master which have not been pulled
> by Wolfgang, but u-boot/master may also contain patches that are needed

if that's the case, then i think doing a merge with Wolfgang's is acceptable 
if you don't just want to have Wolfgang pull your tree as is

> Can you merge a local repo with multiple remotes? So could developer 'x':

certainly.  that's the great thing about git -- every single git repo is on 
"equal" footing in terms of what can be done regardless of who it is (you, me, 
Wolfgang, random-person-who-has-never-posted-to-the-u-boot-list).  the *only* 
thing preventing changes being published on denx.de are ssh credentials.

> > then you'll have to do:
> >        $ git checkout master
> >        $ git rebase u-boot/master
> >        $ git push --force <remote uri> master
> 
> Hmm, I don't think this will, in and of itself, help - The duplicate
> commits are all local to u-boot-x86/master (they are all x86 patches, not
> u-boot patches) but I'll give it a go first...

rebase should automatically discard changesets that are empty/already applied.  
if it doesn't, use the interactive flag:
	$ git rebase -i u-boot/master
then delete any duplicate lines in the text file that pops up
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/58aec911/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

On 29/11/11 16:36, Mike Frysinger wrote:
> On Tuesday 29 November 2011 00:04:12 Graeme Russ wrote:
>> I think I need to do some reading up on 'rebase' versus 'merge' in git

[snip]

>>> then you'll have to do:
>>>        $ git checkout master
>>>        $ git rebase u-boot/master
>>>        $ git push --force <remote uri> master
>>
>> Hmm, I don't think this will, in and of itself, help - The duplicate
>> commits are all local to u-boot-x86/master (they are all x86 patches, not
>> u-boot patches) but I'll give it a go first...
> 
> rebase should automatically discard changesets that are empty/already applied.  
> if it doesn't, use the interactive flag:
> 	$ git rebase -i u-boot/master
> then delete any duplicate lines in the text file that pops up

Well, I had already done a git reset --hard back to a point where there
were no x86 patches applied since last pull anyway, so the rebase threw
them all out

I went back into patchwork and downloaded all the patches and git am'd them
all. I was tempted to fix up a few that broke the build and had to be fixed
with a little fixup patch but I decided that I had tempted fate enough
already :)

So it's all fixed - Thanks for your help

However, I still get:

error: refs/tags/2009.01-rc2 does not point to a valid object!

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Tuesday 29 November 2011 05:51:52 Graeme Russ wrote:
> However, I still get:
> 
> error: refs/tags/2009.01-rc2 does not point to a valid object!

if `git tag -d 2009.01-rc2` doesn't fix things, then try:
	rm .git/refs/tags/2009.01-rc2
	sed -i /tags.2009.01-rc2/d .git/packed-refs
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/8c84d8be/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Andy, Mike,

Thanks for all your help. I've managed to clean-up the x86 repo, but I
still have a few lingering thoughts if you can spare a few more moments...

I understand why a published (i.e. pushed onto the denx server) branch
should never be altered and should, therefore, never require a forced push.

But I can think of two (probably the same) problematic scenarios:

 1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
    and the order that they get pulled results in a conflict
 2) ${sub-repo}/master has been published but not pulled before more
    patches have been added to ${upstream}/master - If ${sub-repo}/master
    does a fetch/pull of ${upstream}/master, there will be a conflict

Now ${upstream}/master is always the 'gold standard', so what does the
conflicted sub-repo dpo with the already published patches?

Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
with ${upstream}/master - I understand how that works when nothing in
that you are responsible for ever changes in ${upstream}/master without
going through your ${sub-repo}/master, but what about when that is not the
case. For example, with some of the major architectural changes being made
to create more common code, how to you ensure the patches in your
${sub-repo}/master do not conflict?

I had a look at u-boot-blackfin and I noticed that there are non-blackfin
patches. u-boot-x86 also has the latest u-boot patches but there is no
merge commit in u-boot-x86 - So how do the u-boot patches get into
${sub-repo}/master without a merge?

Lastly, is there any real difference between a sub-repo and a branch? It
seems to me the principles of pull, merge, rebase etc are about the same
between the two.

Sorry if these questions are 'assumed knowledge' but I really don't want
to get x86 messed up again

Also, I know there are some good git tutorials out there (and I've read
a few) but I find it so much easier when referencing the U-Boot dev
cycle because a) it's what I'm working on and b) as an example, it seems
to be a good balance between 'fairly simple git workflow' and 'insanely
complicated git workflow'

Thanks and Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
>  1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
>     and the order that they get pulled results in a conflict

when a merge is done and a conflict is thrown up, it's up to the guy doing the 
merge to resolve that conflict and commit the result.  this is considered 
"normal" in the git workflow.  just search the git log for "Conflicts:" to see 
this in action.

>  2) ${sub-repo}/master has been published but not pulled before more
>     patches have been added to ${upstream}/master - If ${sub-repo}/master
>     does a fetch/pull of ${upstream}/master, there will be a conflict

there will only be a conflict, if there's a conflict (i.e. two patches changing 
the same file in the same place).  simply having different changesets in the 
repos is normal git workflow.  this is why we have "merge commits" in the git 
log.  these show up all the time when Wolfgang merges branches.

> Now ${upstream}/master is always the 'gold standard', so what does the
> conflicted sub-repo dpo with the already published patches?

there are merge commits and sometimes conflicts in those merges.  it depends on 
the conflict type as to what Wolfgang will do: tell you to rebase onto his 
master and thus it's your problem to resolve the conflict, or he'll fix it up 
locally.

> Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
> with ${upstream}/master - I understand how that works when nothing in
> that you are responsible for ever changes in ${upstream}/master without
> going through your ${sub-repo}/master, but what about when that is not the
> case. For example, with some of the major architectural changes being made
> to create more common code, how to you ensure the patches in your
> ${sub-repo}/master do not conflict?

i keep them in a topic branch and ask Wolfgang to pull those, and i rewrite 
those branches since they're "development" ones

most common example with my repo i think is the "sf" branch where i merge spi 
flash related changes

> I had a look at u-boot-blackfin and I noticed that there are non-blackfin
> patches. u-boot-x86 also has the latest u-boot patches but there is no
> merge commit in u-boot-x86 - So how do the u-boot patches get into
> ${sub-repo}/master without a merge?

i pull Wolfgang's master, put my Blackfin patches on top, and then publish it 
and ask for a pull request.  i don't pull newer updates from Wolfgang until 
he's merged my changes.  or at least, i don't publish the updates.

> Lastly, is there any real difference between a sub-repo and a branch?

from git's pov, not really.  a sub-repo is just to keep things more cleanly 
separated and to grants ACLs on a simpler basis.  we could just as easily have 
all sub-repos be in Wolfgang's tree in namespaced branches:
	master
	x86/master
	blackfin/master
	arm/master
	arm/ti/master
	arm/tegra/master
	..........

but then things can get "noisy" as you see all the pushes/changes made by 
other people.  *shrug*.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/4aa9052e/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
>>  1) ${upstream}/master merges in multiple conflicting ${sub-repo}/master
>>     and the order that they get pulled results in a conflict
>
> when a merge is done and a conflict is thrown up, it's up to the guy doing the
> merge to resolve that conflict and commit the result.  this is considered
> "normal" in the git workflow.  just search the git log for "Conflicts:" to see
> this in action.
>
>>  2) ${sub-repo}/master has been published but not pulled before more
>>     patches have been added to ${upstream}/master - If ${sub-repo}/master
>>     does a fetch/pull of ${upstream}/master, there will be a conflict
>
> there will only be a conflict, if there's a conflict (i.e. two patches changing
> the same file in the same place).  simply having different changesets in the

Ah yes, that's what I meant

> repos is normal git workflow.  this is why we have "merge commits" in the git
> log.  these show up all the time when Wolfgang merges branches.

>> Now ${upstream}/master is always the 'gold standard', so what does the
>> conflicted sub-repo dpo with the already published patches?
>
> there are merge commits and sometimes conflicts in those merges.  it depends on
> the conflict type as to what Wolfgang will do: tell you to rebase onto his
> master and thus it's your problem to resolve the conflict, or he'll fix it up
> locally.

At this point, how do you make the merge 'conflict free' without re-writing
the sub-repo? Or is this one of those rare occassions where you have to do
what you have to do?

>> Mike, you were saying that you don't keep your ${sub-repo}/master sync'd
>> with ${upstream}/master - I understand how that works when nothing in
>> that you are responsible for ever changes in ${upstream}/master without
>> going through your ${sub-repo}/master, but what about when that is not the
>> case. For example, with some of the major architectural changes being made
>> to create more common code, how to you ensure the patches in your
>> ${sub-repo}/master do not conflict?
>
> i keep them in a topic branch and ask Wolfgang to pull those, and i rewrite
> those branches since they're "development" ones
>
> most common example with my repo i think is the "sf" branch where i merge spi
> flash related changes
>
>> I had a look at u-boot-blackfin and I noticed that there are non-blackfin
>> patches. u-boot-x86 also has the latest u-boot patches but there is no
>> merge commit in u-boot-x86 - So how do the u-boot patches get into
>> ${sub-repo}/master without a merge?
>
> i pull Wolfgang's master, put my Blackfin patches on top, and then publish it
> and ask for a pull request.  i don't pull newer updates from Wolfgang until
> he's merged my changes.  or at least, i don't publish the updates.

So you pull u-boot/master straight into u-boot-blackfin/master? From what
I gather, this is the same as fetch/merge. So if you merge branch 'A' into
branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there
is no second merge commit because the merge is already done?

>> Lastly, is there any real difference between a sub-repo and a branch?
>
> from git's pov, not really.  a sub-repo is just to keep things more cleanly
> separated and to grants ACLs on a simpler basis.  we could just as easily have
> all sub-repos be in Wolfgang's tree in namespaced branches:
>        master
>        x86/master
>        blackfin/master
>        arm/master
>        arm/ti/master
>        arm/tegra/master
>        ..........
>
> but then things can get "noisy" as you see all the pushes/changes made by
> other people.  *shrug*.

I thought that was the case

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote:
> On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote:
> > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
> >> Now ${upstream}/master is always the 'gold standard', so what does the
> >> conflicted sub-repo dpo with the already published patches?
> > 
> > there are merge commits and sometimes conflicts in those merges.  it
> > depends on the conflict type as to what Wolfgang will do: tell you to
> > rebase onto his master and thus it's your problem to resolve the
> > conflict, or he'll fix it up locally.
> 
> At this point, how do you make the merge 'conflict free' without re-writing
> the sub-repo?

you can't.  but the counter point is: why is this a problem ?  if one patch is 
tweaking the style, but other is deleting the code block altogether, you get a 
conflict, but it's easy to resolve and commit the result.  not the best 
example, but many conflicts are trivial to resolve.  this is considered part of 
the git workflow as well -- people working in parallel on the same tree are 
bound to touch the same code.  rather than rebasing, do a merge, get a 
conflict, and then fix the conflict and commit it as part of the merge commit.

it's happened at least 65 times since we switched to git:
$ git log | grep -c Conflicts:
65

> >> I had a look at u-boot-blackfin and I noticed that there are
> >> non-blackfin patches. u-boot-x86 also has the latest u-boot patches but
> >> there is no merge commit in u-boot-x86 - So how do the u-boot patches
> >> get into ${sub-repo}/master without a merge?
> > 
> > i pull Wolfgang's master, put my Blackfin patches on top, and then
> > publish it and ask for a pull request.  i don't pull newer updates from
> > Wolfgang until he's merged my changes.  or at least, i don't publish the
> > updates.
> 
> So you pull u-boot/master straight into u-boot-blackfin/master? From what
> I gather, this is the same as fetch/merge. So if you merge branch 'A' into
> branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there
> is no second merge commit because the merge is already done?

correct.  so when Wolfgang pulls my branch, he either fast forwards because he 
hasn't done any new work, or he gets a merge commit.  in either case, when i 
pull his branch, mine is always a fast forward (since his tree has everything 
mine does already).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111129/98f8c0c5/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

Hi Mike,

On Wed, Nov 30, 2011 at 2:52 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote:
>> On Wed, Nov 30, 2011 at 10:35 AM, Mike Frysinger wrote:
>> > On Tuesday 29 November 2011 17:57:39 Graeme Russ wrote:
>> >> Now ${upstream}/master is always the 'gold standard', so what does the
>> >> conflicted sub-repo dpo with the already published patches?
>> >
>> > there are merge commits and sometimes conflicts in those merges.  it
>> > depends on the conflict type as to what Wolfgang will do: tell you to
>> > rebase onto his master and thus it's your problem to resolve the
>> > conflict, or he'll fix it up locally.
>>
>> At this point, how do you make the merge 'conflict free' without re-writing
>> the sub-repo?
>
> you can't.  but the counter point is: why is this a problem ?  if one patch is
> tweaking the style, but other is deleting the code block altogether, you get a
> conflict, but it's easy to resolve and commit the result.  not the best
> example, but many conflicts are trivial to resolve.  this is considered part of
> the git workflow as well -- people working in parallel on the same tree are
> bound to touch the same code.  rather than rebasing, do a merge, get a
> conflict, and then fix the conflict and commit it as part of the merge commit.
>
> it's happened at least 65 times since we switched to git:
> $ git log | grep -c Conflicts:
> 65

Not that many, all things considered. I think one of the big positive side-
effects of using a distributed SCM is that the more structure you apply
to your code, grouping code components together in logical groups, the
less likely you will get conflicts when two people work on two different
features. And such a design facilitates maintaining multiple 'stable'
branches and appliying the same bug fix across each branch - So a good
distributed SCM actively promotes good software design and actively causes
distress when you start hitting those 'less-than-perfect' parts of the code
which encourages (forces) us to refactor and improve.

>
>> >> I had a look at u-boot-blackfin and I noticed that there are
>> >> non-blackfin patches. u-boot-x86 also has the latest u-boot patches but
>> >> there is no merge commit in u-boot-x86 - So how do the u-boot patches
>> >> get into ${sub-repo}/master without a merge?
>> >
>> > i pull Wolfgang's master, put my Blackfin patches on top, and then
>> > publish it and ask for a pull request.  i don't pull newer updates from
>> > Wolfgang until he's merged my changes.  or at least, i don't publish the
>> > updates.
>>
>> So you pull u-boot/master straight into u-boot-blackfin/master? From what
>> I gather, this is the same as fetch/merge. So if you merge branch 'A' into
>> branch 'B' you get a merge commit, and if you then merge 'B' into 'A' there
>> is no second merge commit because the merge is already done?
>
> correct.  so when Wolfgang pulls my branch, he either fast forwards because he
> hasn't done any new work, or he gets a merge commit.  in either case, when i
> pull his branch, mine is always a fast forward (since his tree has everything
> mine does already).

OK, it sounds like I have it figured out now - I think I can say to anyone
wanting a 'cutting edge' local x86 repo to pull u-boot/master and then
fetch/merge u-boot-x86/master if they need x86 patches that have not yet
been pulled. If they want 'bleeding edge' they can additionally fetch/merge
u-boot-x86/next as well

Thanks for taking the time to explain

Regards,

Graeme

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Mike Frysinger]

On Tuesday 29 November 2011 23:12:02 Graeme Russ wrote:
> On Wed, Nov 30, 2011 at 2:52 PM, Mike Frysinger wrote:
> > On Tuesday 29 November 2011 18:48:08 Graeme Russ wrote:
> >> At this point, how do you make the merge 'conflict free' without
> >> re-writing the sub-repo?
> > 
> > you can't.  but the counter point is: why is this a problem ?  if one
> > patch is tweaking the style, but other is deleting the code block
> > altogether, you get a conflict, but it's easy to resolve and commit the
> > result.  not the best example, but many conflicts are trivial to
> > resolve.  this is considered part of the git workflow as well -- people
> > working in parallel on the same tree are bound to touch the same code. 
> > rather than rebasing, do a merge, get a conflict, and then fix the
> > conflict and commit it as part of the merge commit.
> > 
> > it's happened at least 65 times since we switched to git:
> > $ git log | grep -c Conflicts:
> > 65
> 
> Not that many, all things considered. I think one of the big positive side-
> effects of using a distributed SCM is that the more structure you apply
> to your code, grouping code components together in logical groups, the
> less likely you will get conflicts when two people work on two different
> features. And such a design facilitates maintaining multiple 'stable'
> branches and appliying the same bug fix across each branch - So a good
> distributed SCM actively promotes good software design and actively causes
> distress when you start hitting those 'less-than-perfect' parts of the code
> which encourages (forces) us to refactor and improve.

right ... i think our current development style contributes to the low number 
of conflicts.  we've got maintainers for specific subdirs, and cross commits are 
uncommon.  add to that Wolfgang's normal route of applying patches from the ml 
with `git am`, so when a conflict occurs, he just tells the person to 
rebase/resubmit that one patch.  but the ml gates the "downstream" aspect for 
the most part so that person's local rebase doesn't propagate.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111130/9f560f21/attachment.pgp>

[U-Boot] Attn Maintainers: git advise needed (how to fix messed up repo)

[Graeme Russ]

On 29/11/11 10:02, Mike Frysinger wrote:
> On Monday 28 November 2011 17:31:19 Graeme Russ wrote:
>> error: refs/tags/2009.01-rc2 does not point to a valid object!
> 
> this tag seems to have bled into some people's repos ... i'd suggest you punt 
> it locally:
> 	git tag -d 2009.01-rc2
> and then punt it remotely:
> 	git push <remote_uri> :2009.01-rc2
> 

graeme at helios:~/Source/U-Boot/x86$ git tag -d 2009.01-rc2
error: tag '2009.01-rc2' not found.
graeme at helios:~/Source/U-Boot/x86$ git push
ssh://gu-x86 at git.denx.de/u-boot-x86/master :2009.01-rc2
error: refs/tags/2009.01-rc2 does not point to a valid object!
error: unable to push to unqualified destination: 2009.01-rc2
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'ssh://gu-x86 at git.denx.de/u-boot-x86/master'

Expected?

Regards,

Graeme