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
Pavel Roskin <[email protected]> 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
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 <[email protected]> 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
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
Pavel Roskin <[email protected]> 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, [email protected]
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."
On Wednesday 09 January 2008 18:05:26 Kalle Valo wrote:
> Pavel Roskin <[email protected]> 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
bruno randolf <[email protected]> writes:
> how do you guys manage your pending patches and local work then?
Try StGIT.
Andreas.
--=20
Andreas Schwab, SuSE Labs, [email protected]
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."
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 <[email protected]> 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
[email protected]
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
David Woodhouse <[email protected]> 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
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
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
[email protected]
bruno randolf <[email protected]> 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