[U-Boot] problem doing rebase in fresh git.denx.de/u-boot.git clone
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
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
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
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
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
Dear "Peter Vollmer",
In message op.ul1xayil2rocvy@tomo.bln.innominate.local you wrote:
- 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
- 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
- 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'
- 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
participants (2)
-
Peter Vollmer -
Wolfgang Denk