merge errors on 'everything'

merge errors on 'everything'

[bruno randolf]

hi!

many times when i do a 'git pull' to update the wireless-2.6 'everything' 
branch i run into unexplicable merge errors.

i created the branch with 'git co --track -b everything origin/everything' and 
i don't work on this branch so all files are un-modified.

what am i doing wrong?

bruno

Re: merge errors on 'everything'

[John W. Linville]

On Wed, Jan 09, 2008 at 10:43:01AM +0900, bruno randolf wrote:
> hi!
> 
> many times when i do a 'git pull' to update the wireless-2.6 'everything' 
> branch i run into unexplicable merge errors.
> 
> i created the branch with 'git co --track -b everything origin/everything' and 
> i don't work on this branch so all files are un-modified.
> 
> what am i doing wrong?

You'll need to get a fresh clone of the repository -- sorry.

-- 
John W. Linville
linville@tuxdriver.com

Re: merge errors on 'everything'

[Pavel Roskin]

On Wed, 2008-01-09 at 10:43 +0900, bruno randolf wrote:
> hi!
> 
> many times when i do a 'git pull' to update the wireless-2.6 'everything' 
> branch i run into unexplicable merge errors.

I think the explanation is that the changes in the branch are rebased,
rather than merged, when the wireless-2.6 repository is updated from the
upstream Linux repository.

git views changes on top of the old tree in your repository as
independent from those that appear in wireless-2.6, so it tries to merge
them.  But since it's actually the same patches, git sees that as a
conflict.

You can clean up the consequences of the failed merge by running
"git-reset --hard origin/everything" where "origin" is the name of the
remote.

> i created the branch with 'git co --track -b everything origin/everything' and 
> i don't work on this branch so all files are un-modified.
> 
> what am i doing wrong?

I'm not sure you are doing anything wrong.  It's quite possible that git
should be changed to handle this problem better.  Or maybe the
wireless-2.6 repository should be managed differently.

-- 
Regards,
Pavel Roskin

Re: merge errors on 'everything'

[Pavel Roskin]

On Tue, 2008-01-08 at 20:51 -0500, John W. Linville wrote:
> On Wed, Jan 09, 2008 at 10:43:01AM +0900, bruno randolf wrote:
> > hi!
> > 
> > many times when i do a 'git pull' to update the wireless-2.6 'everything' 
> > branch i run into unexplicable merge errors.
> > 
> > i created the branch with 'git co --track -b everything origin/everything' and 
> > i don't work on this branch so all files are un-modified.
> > 
> > what am i doing wrong?
> 
> You'll need to get a fresh clone of the repository -- sorry.

While it's reassuring to see that I'm not missing some elegant solution,
I think cloning the repository is a major overkill.

"git-reset --hard origin/everything" does the trick for me, while using
much less bandwidth and time.  It even works with StGIT because it
unapplies the patches before pulling and doesn't apply them in case of
conflicts.  I can apply the StGIT patches after "git-reset".

-- 
Regards,
Pavel Roskin

Re: merge errors on 'everything'

[Kalle Valo]

Pavel Roskin <proski@gnu.org> writes:

>> You'll need to get a fresh clone of the repository -- sorry.
>
> While it's reassuring to see that I'm not missing some elegant solution,
> I think cloning the repository is a major overkill.

I agree. 

> "git-reset --hard origin/everything" does the trick for me, while using
> much less bandwidth and time.

I do the same and it has worked for me, at least.

It would be nice if git would somehow do this automatically with
rebased trees. Or maybe it already supports it and I'm not just aware
of it?

-- 
Kalle Valo

Re: merge errors on 'everything'

[Andreas Schwab]

Pavel Roskin <proski@gnu.org> writes:

> You can clean up the consequences of the failed merge by running
> "git-reset --hard origin/everything" where "origin" is the name of th=
e
> remote.

A failed merge leaves the head of the tree to be merged in MERGE_HEAD,
so you can use "git reset --hard MERGE_HEAD" generically.

Andreas.

--=20
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: merge errors on 'everything'

[bruno randolf]

On Wednesday 09 January 2008 18:05:26 Kalle Valo wrote:
> Pavel Roskin <proski@gnu.org> writes:
> >> You'll need to get a fresh clone of the repository -- sorry.
> >
> > While it's reassuring to see that I'm not missing some elegant solution,
> > I think cloning the repository is a major overkill.
>
> I agree.
>
> > "git-reset --hard origin/everything" does the trick for me, while using
> > much less bandwidth and time.
>
> I do the same and it has worked for me, at least.

thanks for that hint, but still, that sucks if you want to rebase your local 
work against an updated 'everything'...

how do you guys manage your pending patches and local work then?

thanks,
bruno

Re: merge errors on 'everything'

[Andreas Schwab]

bruno randolf <bruno@thinktube.com> writes:

> how do you guys manage your pending patches and local work then?

Try StGIT.

Andreas.

--=20
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4=
ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: merge errors on 'everything'

[Kalle Valo]

bruno randolf <bruno@thinktube.com> writes:

>> > "git-reset --hard origin/everything" does the trick for me, while using
>> > much less bandwidth and time.
>>
>> I do the same and it has worked for me, at least.
>
> thanks for that hint, but still, that sucks if you want to rebase your local 
> work against an updated 'everything'...
>
> how do you guys manage your pending patches and local work then?

What I have done is that I follow upstream development in master
branch and create separate branch for my stuff. And after master
changes I'll do 'git rebase master' on my branch.

But as Andreas already mentioned, stgit is the better way to do this.

-- 
Kalle Valo

Re: merge errors on 'everything'

[John W. Linville]

[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]

On Thu, Jan 10, 2008 at 10:29:44AM +0900, bruno randolf wrote:
> On Wednesday 09 January 2008 18:05:26 Kalle Valo wrote:
> > Pavel Roskin <proski@gnu.org> writes:
> > >> You'll need to get a fresh clone of the repository -- sorry.
> > >
> > > While it's reassuring to see that I'm not missing some elegant solution,
> > > I think cloning the repository is a major overkill.
> >
> > I agree.
> >
> > > "git-reset --hard origin/everything" does the trick for me, while using
> > > much less bandwidth and time.
> >
> > I do the same and it has worked for me, at least.
> 
> thanks for that hint, but still, that sucks if you want to rebase your local 
> work against an updated 'everything'...
> 
> how do you guys manage your pending patches and local work then?

What I recommend is that you start with your own branch from
'everything':

	git checkout -b work everything

And for convenience, create another branch representing where you
started:

	git branch work-start

Now do whatever work you want to do on that branch.  You can continue
to pull into everything as you like (remember to 'git checkout
everything' first) -- I generally try to preserve a continuous
everything branch between -rc releases.  So long as the pull is clean,
you can rebase your work branch quite easily:

	git checkout work
	git rebase everything

	# don't forget to move work-start as well
	git branch -D work-start
	git branch work-start everything

After a rebase of wireless-2.6#everything, you won't have a clean pull
(as you have observed).  In that case you can reclone (be sure to
save the old clone!) or use git-reset as described above.  Then you
can use some simple commands to rebase the patches:

	git checkout -b new-work everything
	git branch new-work-start

	git format-patch --stdout work-start..work > work.mbox
	git am work.mbox

An alternative to the git-format-patch/git-am combination would be
to use the attached 'rangepick' script.

Hth!

John

P.S.  I have no experience with StGit -- some have said it is
functionaly similar to what I describe above yet perhaps simpler
to use...YMMV.
-- 
John W. Linville
linville@tuxdriver.com

[-- Attachment #2: rangepick --]
[-- Type: text/plain, Size: 201 bytes --]

#!/bin/sh

git log --no-merges $1 | grep ^commit | awk '{ print $2 }' | tac | \
while read commit
do
	if ! git cherry-pick $commit
	then
		echo Failed to cherry-pick commit ${commit}!
		break
	fi
done

Re: merge errors on 'everything'

[David Woodhouse]

On Wed, 2008-01-09 at 11:05 +0200, Kalle Valo wrote:
> 
> I do the same and it has worked for me, at least.
> 
> It would be nice if git would somehow do this automatically with
> rebased trees. Or maybe it already supports it and I'm not just aware
> of it?

Why would it? Git isn't designed to handle rebasing nicely -- rebasing
is something that should only ever happen if you screw up and have to
start again. If you rebase you throw away most of what makes git so
useful.

-- 
dwmw2

Re: merge errors on 'everything'

[Kalle Valo]

David Woodhouse <dwmw2@infradead.org> writes:

>> It would be nice if git would somehow do this automatically with
>> rebased trees. Or maybe it already supports it and I'm not just aware
>> of it?
>
> Why would it? Git isn't designed to handle rebasing nicely -- rebasing
> is something that should only ever happen if you screw up and have to
> start again.

Maybe in theory, but in practise maintainers rebase a lot. And I, as a
git user, have to deal with that and do git reset trickery etc.

-- 
Kalle Valo

Re: merge errors on 'everything'

[bruno randolf]

On Friday 11 January 2008 00:34:35 John W. Linville wrote:
> On Thu, Jan 10, 2008 at 10:29:44AM +0900, bruno randolf wrote:
> > On Wednesday 09 January 2008 18:05:26 Kalle Valo wrote:
> > > Pavel Roskin <proski@gnu.org> writes:
> > > >> You'll need to get a fresh clone of the repository -- sorry.
> > > >
> > > > While it's reassuring to see that I'm not missing some elegant
> > > > solution, I think cloning the repository is a major overkill.
> > >
> > > I agree.
> > >
> > > > "git-reset --hard origin/everything" does the trick for me, while
> > > > using much less bandwidth and time.
> > >
> > > I do the same and it has worked for me, at least.
> >
> > thanks for that hint, but still, that sucks if you want to rebase your
> > local work against an updated 'everything'...
> >
> > how do you guys manage your pending patches and local work then?
>
> What I recommend is that you start with your own branch from
> 'everything':
>
> 	git checkout -b work everything
>
> And for convenience, create another branch representing where you
> started:
>
> 	git branch work-start
>
> Now do whatever work you want to do on that branch.  You can continue
> to pull into everything as you like (remember to 'git checkout
> everything' first) -- I generally try to preserve a continuous
> everything branch between -rc releases.  So long as the pull is clean,
> you can rebase your work branch quite easily:
>
> 	git checkout work
> 	git rebase everything
>
> 	# don't forget to move work-start as well
> 	git branch -D work-start
> 	git branch work-start everything
>
> After a rebase of wireless-2.6#everything, you won't have a clean pull
> (as you have observed).  In that case you can reclone (be sure to
> save the old clone!) or use git-reset as described above.  Then you
> can use some simple commands to rebase the patches:
>
> 	git checkout -b new-work everything
> 	git branch new-work-start
>
> 	git format-patch --stdout work-start..work > work.mbox
> 	git am work.mbox
>
> An alternative to the git-format-patch/git-am combination would be
> to use the attached 'rangepick' script.
>
> Hth!
>
> John
>
> P.S.  I have no experience with StGit -- some have said it is
> functionaly similar to what I describe above yet perhaps simpler
> to use...YMMV.

thanks for that! i tried StGIT and it works fine for me, also since i usually 
have to fixup my patches several times before i send them and it can do that 
nicely too.

bruno