Yves thanks for your answer
on 06.10.2012 18:12, Yves Blusseau wrote: > > Le 6 oct. 2012 à 14:22, Erich Titl a écrit : > >> Hi Yves >> >> on 06.10.2012 10:07, Yves Blusseau wrote: >>>:$ >>> Le 5 oct. 2012 à 19:07, Erich Titl a écrit : >>> >>>> Hi Folks >>>> >>>> I have gotten at a point where I want to push my stuff. >>>> >>>> @Yves could you have a look at my merge output to just _guess_ if it >>>> looks OK >>>> >>>> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git branch >>>> maint >>>> master >>>> * nameif >>>> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git checkout maint >>>> M conf/.gitignore >>>> M conf/buildtool.conf >>>> Switched to branch "maint" >>>> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git merge nameif >>>> Auto-merged conf/sources.cfg >>>> Merge made by recursive. >>>> conf/sources.cfg | 11 ++++++ >>>> repo/bbnameif/buildtool.cfg | 75 >>>> +++++++++++++++++++++++++++++++++++++++++++ >>>> repo/bbnameif/buildtool.mk | 31 ++++++++++++++++++ >>>> repo/bbnameif/mactab | 6 +++ >>>> repo/bbnameif/mactab.tmp | 8 ++++ >>>> repo/bbnameif/nameif | 38 ++++++++++++++++++++++ >>>> repo/busybox/.config | 4 +- >>>> 7 files changed, 171 insertions(+), 2 deletions(-) >>>> create mode 100644 repo/bbnameif/buildtool.cfg >>>> create mode 100644 repo/bbnameif/buildtool.mk >>>> create mode 100644 repo/bbnameif/mactab >>>> create mode 100644 repo/bbnameif/mactab.tmp >>>> create mode 100644 repo/bbnameif/nameif >>>> >>>> This is how the log looks >>>> >>>> commit a9ab81c9ea572139a01649b33989ef0e2624497f >>>> Merge: 5424f54... 4cbad44... >>>> Author: mega <erich.t...@think.ch> >>>> Date: Fri Oct 5 19:02:13 2012 +0200 >>>> >>>> Merge branch 'nameif' into maint >>> >>> Hi Erich, >>> No it's not good because the merge must result into a fast forward and not >>> a merge commit. >> >> That is the point where I have my doubts in GIT, >> >> What exactly is the ploblem? I based nameif off maint tag v4.3 and meged >> it back in my local maint. From my point of view a commit > > This is the problem. You fork off your name if branch from the v4.3 tag and > not from the maint. > This is why your merge result into a merge commit instead of a fast forward: > You are trying to apply patchs from 4.3 into the current maint which is 4.3.1. > Like as wrote in the git workflows (http://tinyurl.com/TopicBranches): Fork > it off at the oldest integration branch that you will eventually want to > merge it into. For example for a bugfix in maint fork off your topic branch > from maint. Yes, but I needed a fork off of 4.3, not 4.3.1 I hope this is possible, here a bit of ascii art o--o--o--o / \ o--o--o--o--o--o--o--o It should be possible to to fork off in the past if needed. Of course inserting in the past does not make sense. This brings me to one question, how to port this modification to master? > >> >>> >>> First reset the maint branch: >>> git checkout maint >> >> That is where I am now >> >>> git fetch >> >> Why? I thought GIT was clever.... whatever. >> > To get the last updates from the repository > >>> git reset --hard origin/maint >> >> Why do I neet to reset GIT, I thought it was not designed by Microsoft :-) >> >> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git branch >> * maint >> master >> nameif >> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git fetch >> Password: >> Password: >> remote: Counting objects: 23, done. >> remote: Compressing objects: 100% (19/19), done. >> remote: Total 19 (delta 8), reused 0 (delta 0) >> Unpacking objects: 100% (19/19), done. >> From ssh://et...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc >> efa5d63..8d62d9f master -> origin/master >> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git reset --hard origin/maint >> HEAD is now at 5424f54 squid depends on openssl >> > With this your local maint branch we'll be the same as the public maint branch > >>> >>> Then you must rebase your nameif branch from maint: >>> git checkout nameif >>> git rebase maint >> >> Why do I have to rebase? Looking at all docs floating around in the net >> especially at >> http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging >> this was not the way they explained. >> > You need to do this because you fork off your nameif branch from the v4.3 tag > and not from maint. > With this you will apply your patches above the maint branch. So after that > the merge will result into a fast forward. > Like as wrote in the git workflows (http://tinyurl.com/TopicBranches): If > you find you forked off the wrong branch and want to move it "back in time", > use git-rebase(1). > >> NOw here it gets cryptic >> >> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git rebase maint >> First, rewinding head to replay your work on top of it... >> Applying: enabled nameif applet >> Applying: Added new code to enable and use the Busybox nameif applet >> /home/mega/leaf/devel/leaf.new/bering-uclibc/.git/rebase-apply/patch:72: >> trailing whitespace. >> >> /home/mega/leaf/devel/leaf.new/bering-uclibc/.git/rebase-apply/patch:75: >> trailing whitespace. >> LEAF package by __PACKAGER__, __BUILDDATE__ >> /home/mega/leaf/devel/leaf.new/bering-uclibc/.git/rebase-apply/patch:77: >> trailing whitespace. >> <Permissions> >> >> /home/mega/leaf/devel/leaf.new/bering-uclibc/.git/rebase-apply/patch:86: >> trailing whitespace. >> >> /home/mega/leaf/devel/leaf.new/bering-uclibc/.git/rebase-apply/patch:103: >> trailing >> whitespace. >> </File> >> warning: squelched 10 whitespace errors >> warning: 15 lines add whitespace errors. >> Applying: Added a little bit of comment to the mactab files >> /home/mega/leaf/devel/leaf.new/bering-uclibc/.git/rebase-apply/patch:26: >> trailing whitespace. >> # To use this file enter your desired interface name >> /home/mega/leaf/devel/leaf.new/bering-uclibc/.git/rebase-apply/patch:27: >> trailing whitespace. >> # followed by it's MAC address >> warning: 2 lines add whitespace errors. >> Applying: Small fix on the nameif start script >> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> >> Is the above a GIT problem? > No but your patches are not very clean: warning: 15 lines add whitespace > errors. > Before committing patch check there no trailing space, etc… > The best is to use the git diff command with the colors enabled and you'll > see the whitespace errors in red (http://tinyurl.com/GitAddColors) What is the notion of being clean here? >> >>> >>> And resolv conflicts. >> >> Jeeeez... I hate conflicts, that is why I liked lockable mods. >> > You have no conflicts, it's good. >> >> >>> >>> After that go to the maint branch: >>> git checkout maint >> >> >>> >>> and do a >>> git diff nameif >>> to see if what you want to add is good >>> >>> after that you can merge your branch into maint and it will result to a >>> fast-forward: >>> git merge nameif >>> >> >> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git merge nameif >> Updating 5424f54..3461de4 >> Fast forward > Fast Forward: it's good > >> conf/sources.cfg | 11 ++++++ >> repo/bbnameif/buildtool.cfg | 75 >> +++++++++++++++++++++++++++++++++++++++++++ >> repo/bbnameif/buildtool.mk | 31 ++++++++++++++++++ >> repo/bbnameif/mactab | 6 +++ >> repo/bbnameif/mactab.tmp | 8 ++++ >> repo/bbnameif/nameif | 38 ++++++++++++++++++++++ >> repo/busybox/.config | 4 +- >> 7 files changed, 171 insertions(+), 2 deletions(-) >> create mode 100644 repo/bbnameif/buildtool.cfg >> create mode 100644 repo/bbnameif/buildtool.mk >> create mode 100644 repo/bbnameif/mactab >> create mode 100644 repo/bbnameif/mactab.tmp >> create mode 100644 repo/bbnameif/nameif >> >> Well it looks quite a bit the same as I had when I merged before. >> > No before you've done a true merge (look there a commit merge: a9ab8 > >> What of the above steps made the big difference and where is the gotcha >> one can run into? It looks to me just like another entrance into the >> same building. >> > The result in the work tree is the same, but not from the git point of view. > >> But then >> >> mega@luna:~/leaf/devel/leaf.new/bering-uclibc> git push >> Password: >> Counting objects: 33, done. >> Compressing objects: 100% (27/27), done. >> Writing objects: 100% (27/27), 3.53 KiB, done. >> Total 27 (delta 17), reused 0 (delta 0) >> To ssh://et...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc >> 5424f54..3461de4 maint -> maint >> ! [rejected] master -> master (non-fast forward) >> error: failed to push some refs to >> 'ssh://et...@leaf.git.sourceforge.net/gitroot/leaf/bering-uclibc' >> >> Whoooow, lost another battle. This is just like in the hall of mirrors. >> Why was there anything on master rejected, I did not even touch it. >> > Because your master is too old, and your git push try to push ALL the > branches that is a bad thing !! Oh I see, but where is that big fuzz now. So even GIT requires youi to keep a current branch, just the same as any old other versioning tool. I was not aware of that, but under the impression that GIT would take care of that underneath the hood. > I think you have an older version of git. Please upgrade to git > v.1.7.10 > and if you can v.1.7.12 I do, I made the mistake to use a packaged GIT and not the source, so I have to find out what the packager thought to be good, before I can replace it. > > If you are on fedora i have built the last version of git if you want it. Naaahhhh .... OpenSuSE something 10ish as a virtual machine. > > Regards, > Yves > Thanks again, makes everything a bit more clear. Erich
smime.p7s
Description: S/MIME Kryptografische Unterschrift
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel