[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone

[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone

[Peter Vollmer]

Hi all,

I just tried to do a git bisect in my clone of the u-boot git repo
to trace some commits in the past, but I noticed there
is a problem doing a rebase in an unchanged fresh
clone of git.denx.de/u-boot.git. Thats what I did:

~$ git --version
git version 1.5.6.5

~$ git clone git://git.denx.de/u-boot.git
Initialized empty Git repository in /home/pvollmer/u-boot/.git/
remote: Counting objects: 80730, done.
remote: Compressing objects: 100% (16904/16904), done.
remote: Total 80730 (delta 66116), reused 77805 (delta 63347)
Receiving objects: 100% (80730/80730), 26.96 MiB | 5812 KiB/s, done.
Resolving deltas: 100% (66116/66116), done.

~/uboot$ git rebase v1.3.3
First, rewinding head to replay your work on top of it...
Applying ppc4xx: Add the Harris QUAD100HD AMCC 405EP-based board
Applying Fix @ -> <at> substitution
error: patch failed: board/atmel/at91cap9adk/Makefile:1
error: board/atmel/at91cap9adk/Makefile: patch does not apply
error: patch failed: board/atmel/at91cap9adk/at91cap9adk.c:1
error: board/atmel/at91cap9adk/at91cap9adk.c: patch does not apply
error: patch failed: board/atmel/at91cap9adk/led.c:1
error: board/atmel/at91cap9adk/led.c: patch does not apply
<snip>
... lots of errors
<\snip>
Applying Socrates: Added USB support.
error: patch failed: include/configs/socrates.h:236
error: include/configs/socrates.h: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merged include/configs/socrates.h
CONFLICT (content): Merge conflict in include/configs/socrates.h
Failed to merge in the changes.
Patch failed at 0058.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
~/uboot$ git rebase --abort

I also tried git version 1.6.0.3 with the same result.
Any idea what the problem might be ?

Thanks
Peter


-- 
Peter Vollmer

[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone

[Wolfgang Denk]

Dear "Peter Vollmer",

In message <op.ulz4uzsg2rocvy@tomo.bln.innominate.local> you wrote:
> Hi all,
> 
> I just tried to do a git bisect in my clone of the u-boot git repo
> to trace some commits in the past, but I noticed there
> is a problem doing a rebase in an unchanged fresh
> clone of git.denx.de/u-boot.git. Thats what I did:
...
> ~$ git clone git://git.denx.de/u-boot.git
...
> ~/uboot$ git rebase v1.3.3

What exactly do you expect this command to do?

You mentioned you were tyng to bisect... Any chance you confused
git-rebase with git-checkout ?

> Any idea what the problem might be ?

Wrong use?

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
While money can't buy happiness, it certainly lets  you  choose  your
own form of misery.

[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone

[Peter Vollmer]

On Thu, 11 Dec 2008 17:01:57 +0100, Wolfgang Denk <wd@denx.de> wrote:

>> ~$ git clone git://git.denx.de/u-boot.git
> ...
>> ~/uboot$ git rebase v1.3.3
>
> What exactly do you expect this command to do?

I have some patches that apply against v1.3.3 and work fine. Moving
them to v2008.10 did not work so far, so I try to find a relevant change
somewhere in between v1.3.3 and v2008.10 by bisecting, and I wanted to fit
in a couple of needed changes to my patches (renamed #defines etc.) at the
right place in the timeline using "git rebase -i" and replacing my commits,
so that at least the compilation will run through at any given point in  
time
when bisecting it.

"git rebase -i v1.3.3" did not work, and then doing "git rebase v1.3.3" in  
an
untouched fresh repository (i.e just branching of at tag v1.3.3, and  
reapplying
all the patches between v1.3.3 and HEAD) didn't work either.
I'm not sure if thats the normal behaviour of git-rebase, usually it  
worked for
me like that. But then I never tried it with a complete upstream repository
before.

I guess I try without the rebase and just use "git merge" into a new  
branch, which
should work without a problem.

Thanks

-- 
Peter Vollmer
Software Engineer

Innominate Security Technologies AG
protecting industrial networks
Albert-Einstein-Str. 14
D-12489 Berlin
www.innominate.com

[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone

[Wolfgang Denk]

Dear Peter,

In message <op.ul0bvrx72rocvy@tomo.bln.innominate.local> you wrote:
> 
> >> ~$ git clone git://git.denx.de/u-boot.git
> > ...
> >> ~/uboot$ git rebase v1.3.3
> >
> > What exactly do you expect this command to do?
> 
> I have some patches that apply against v1.3.3 and work fine. Moving
> them to v2008.10 did not work so far, so I try to find a relevant change
> somewhere in between v1.3.3 and v2008.10 by bisecting, and I wanted to fit

You did not answer my question.

You showed us a sequence  of  two  commands:  git-clone  followed  by
git-rebase, and complain that it doesn't wor as expected.

You are missing something - either, you miss to describe some
additional steps you did between these two commands (in which case we
have no chance to comment at all), or you miss how git works.


If you have a patchset against v1.3.3, my approach would be to create
a branch, for example like this:

	git-checkout -b my-test-branch v1.3.3

then apply the patches, commit these, and then (with "my-test-branch"
checked out), you could try a "git-rebase -i master".


But  you  don't  mention  any  branch  creation  or  similar,  and  a
git-rebase  immediately  after a git-clone just doesn't make sense to
me.

> "git rebase -i v1.3.3" did not work, and then doing "git rebase v1.3.3" in  
> an
> untouched fresh repository (i.e just branching of at tag v1.3.3, and  
> reapplying
> all the patches between v1.3.3 and HEAD) didn't work either.

Again - what exactly do you expect this command to do? It makes no
sense to me, at least as you describe it.

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
How come everyone's going so slow if it's called rush hour?

[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone

[Peter Vollmer]

Dear Wolfgang,
On Thu, 11 Dec 2008 21:54:13 +0100, Wolfgang Denk <wd@denx.de> wrote:
> In message <op.ul0bvrx72rocvy@tomo.bln.innominate.local> you wrote:
>> > What exactly do you expect this command to do?
> You showed us a sequence  of  two  commands:  git-clone  followed  by
> git-rebase, and complain that it doesn't wor as expected.
>
> You are missing something - either, you miss to describe some
> additional steps you did between these two commands (in which case we
> have no chance to comment at all), or you miss how git works.

Sorry if I failed to give a clear explanation, I'll try again.

1) Lets say this is a simplified part of the commit log after I cloned the  
repo and created my branch with "git checkout -b bisect v2008.10"

tag_v1.3.3
commitA
commitB
commitC
tag_v2008.10

2) then I commit my own patches at the top with "git am  
0001-myPatch1.patch 0002-myPatch2.patch"

tag_v1.3.3
commitA
commitB
commitC
tag_v2008.10
myPatch1
myPatch2

3) then I try to "git rebase -i v1.3.3" to reorder the commits in my  
branch in the following way (which failed):

tag_v1.3.3
commitA
myPatch1
commitB
myPatch2
commitC
tag_v2008.10

4) After that I wanted to do a git bisect between tag_v1.3.3 and  
tag_v2008.10 to find the commit when my port stops working.

> If you have a patchset against v1.3.3, my approach would be to create
> a branch, for example like this:
>
> 	git-checkout -b my-test-branch v1.3.3
>
> then apply the patches, commit these, and then (with "my-test-branch"
> checked out), you could try a "git-rebase -i master".

I see, this would move my patches from after tag_v1.3.3 up to HEAD, but  
what I tried to accomplish was to distribute them back in the timeline to  
make bisect work at each point between v1.3.3 and v2008.10.

Lets say there is the commit

commit 0e8d158664a913392cb01fb11a948d83f72e105e
Author: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date:   Wed Sep 10 22:48:06 2008 +0200

     rename CFG_ENV macros to CONFIG_ENV

     Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

and I have a patch "rename_CFG_ENV_to_CONFIG_ENV_myBoard.patch", so I  
would like to put it directly after above commit, so u-boot compiles  
before and after these two patches during the bisect process.

But I already managed to do it using git merge. Thanks for your help and  
sorry for the confusion :)

Best Regards

-- 
Peter Vollmer
Software Engineer

Innominate Security Technologies AG
protecting industrial networks
Albert-Einstein-Str. 14
D-12489 Berlin
www.innominate.com

[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone

[Wolfgang Denk]

Dear "Peter Vollmer",

In message <op.ul1xayil2rocvy@tomo.bln.innominate.local> you wrote:
>
> 1) Lets say this is a simplified part of the commit log after I cloned the  
> repo and created my branch with "git checkout -b bisect v2008.10"

But that's wrong. You said, you patches were based on v1.3.3 - then you must branch off v1.3.3:

	git-checkout -b your_branch v1.3.3


> tag_v1.3.3
> commitA
> commitB
> commitC
> tag_v2008.10

Will give:


tag_v1.3.3  x-- your_branch---+
commitA
commitB
commitC
tag_v2008.10

> 2) then I commit my own patches at the top with "git am  
> 0001-myPatch1.patch 0002-myPatch2.patch"
> 
> tag_v1.3.3
> commitA
> commitB
> commitC
> tag_v2008.10
> myPatch1
> myPatch2

That makes no sense, if your  patches  are  based  on  1.3.3  -  most
probably, they will not even apply correctly on top of v2008.10; what
you need is this:

tag_v1.3.3 x-- your_branch---+
commitA                   myPatch1
commitB                   myPatch2
commitC
tag_v2008.10


> 3) then I try to "git rebase -i v1.3.3" to reorder the commits in my  
> branch in the following way (which failed):

That's wrong again. Here you need to do a  "git  rebase  -i  master",
which  will  move  the point where you branched off the master branch
(marked in the pictures above with 'x') to the top of tree commit; if
successful, the result will then look like this:

> tag_v1.3.3
> commitA
> myPatch1
> commitB
> myPatch2
> commitC
> tag_v2008.10

tag_v1.3.3
commitA
commitB
commitC
tag_v2008.10 x-- your_branch---+
                          myPatch1'
                          myPatch2'


> 4) After that I wanted to do a git bisect between tag_v1.3.3 and  
> tag_v2008.10 to find the commit when my port stops working.

Using bisect makes absolutely no sense to me in this context.


> I see, this would move my patches from after tag_v1.3.3 up to HEAD, but  
> what I tried to accomplish was to distribute them back in the timeline to  
> make bisect work at each point between v1.3.3 and v2008.10.

You cannot go backward. You could only start  your  own  branch,  and
then  git-cherry-pick  one  patch  after  the  other  from the master
branch, and after each step clean up / add fixes as needed.

Then you can git-rebase -i your branch to consolidate patches.

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 human mind  ordinarily  operates  at  only  ten  percent  of  its
capacity. The rest is overhead for the operating system.