Re: [leaf-devel] Question about the kernel
On 06/10/12 23:05, KP Kirchdoerfer wrote: > Am 06.10.2012 19:02, schrieb Yves Blusseau: >> Hi all, >> >> just for my information, why do we use the 3.2 kernel for BuC ? >> >> Why not using the 3.4 or 3.5 stable versions ? >> Or the upcoming 3.6 branch that will have good optimizations for network >> like TCP Small Queues or TCP Fast Open ? > Hello Yves; > > the reason ist that the 3.2 kernel is a kernel with long time support. > 3.2 has been chossen by Debian and Ubuntu for their stable/LTS, which > means that it will be supported for 5 years. So it's a good and stable > base to develop 5.0. > > Once we have 5.0 finished we may decide to move to a newer kernel, until > then I'll prefer to go with a kernel supported that long time. > > kp Also dont forget that now LEAF isn't heavily dependent of kernel version - we can provide different kernels (with corresponding initmod, moddb and modules.tgz) that will work with same userland. Earlier userland initrd was dependent of kernel because it had included modules. -- 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
Re: [leaf-devel] BuC 4.3 interface naming
on 06.10.2012 18:27, Yves Blusseau wrote: > Erich this is for example some of the whitespace errors you have in your > patches: > http://dl.dropbox.com/u/112112/Screenshots/0zl_w0uz~4l7.png Nice, but why would GIT care. > > Also before merging a topic branch into an integration branch it's better to > squash several commits into one or two. > Your nameif integration take 4 commits: > > * 3461de4 Small fix on the nameif start script > * 0ff5054 Added a little bit of comment to the mactab files > * 41dfb90 Added new code to enable and use the Busybox name if applet > which enables control for network interface naming > * b83efa6 enabled nameif applet I was under the impression that many commits were desirable. I could have done without. > > So before merging the branch do a: > > git rebase -i maint M... if only I could understand that concept/word I wanted a 4.3 because I have a 4.3 and I wanted to work for what I have. Looking at http://git-scm.com/book/en/Git-Branching-Rebasing It appears that those 2 concepts have only cosmetic differences. e.g. Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot — it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together. > > And squash your commits, so it will result into only one or two commit(s). > It's better to have git history not clutter with some small fixes that was > done during development in the topic branch. I will try to remember. cheers 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
Re: [leaf-devel] BuC 4.3 interface naming
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 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-uclib
Re: [leaf-devel] Question about the kernel
Am 06.10.2012 19:02, schrieb Yves Blusseau: > Hi all, > > just for my information, why do we use the 3.2 kernel for BuC ? > > Why not using the 3.4 or 3.5 stable versions ? > Or the upcoming 3.6 branch that will have good optimizations for network like > TCP Small Queues or TCP Fast Open ? Hello Yves; the reason ist that the 3.2 kernel is a kernel with long time support. 3.2 has been chossen by Debian and Ubuntu for their stable/LTS, which means that it will be supported for 5 years. So it's a good and stable base to develop 5.0. Once we have 5.0 finished we may decide to move to a newer kernel, until then I'll prefer to go with a kernel supported that long time. kp -- 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
[leaf-devel] Question about the kernel
Hi all, just for my information, why do we use the 3.2 kernel for BuC ? Why not using the 3.4 or 3.5 stable versions ? Or the upcoming 3.6 branch that will have good optimizations for network like TCP Small Queues or TCP Fast Open ? Regards, Yves -- 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
Re: [leaf-devel] BuC 4.3 interface naming
Erich this is for example some of the whitespace errors you have in your patches: http://dl.dropbox.com/u/112112/Screenshots/0zl_w0uz~4l7.png Also before merging a topic branch into an integration branch it's better to squash several commits into one or two. Your nameif integration take 4 commits: * 3461de4 Small fix on the nameif start script * 0ff5054 Added a little bit of comment to the mactab files * 41dfb90 Added new code to enable and use the Busybox name if applet which enables control for network interface naming * b83efa6 enabled nameif applet So before merging the branch do a: git rebase -i maint And squash your commits, so it will result into only one or two commit(s). It's better to have git history not clutter with some small fixes that was done during development in the topic branch. Regards, Yves -- 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
Re: [leaf-devel] BuC 4.3 interface naming
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 >>> 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. > >> >> 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. > > > /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. > > war
Re: [leaf-devel] Multi-WAN
On 10/05/2012 09:32 PM, Andrew wrote: > On 05/10/12 17:14, Mike Noyes wrote: >> Everyone, >> Is Bering-uClibc capable of Multi-WAN like: >> >> Peplink - Dual-WAN, Multi-WAN Internet Link Load Balancing Routers >> http://www.peplink.com/ >> -or- >> Cisco RV Series Multi-WAN VPN Router >> http://www.cisco.com/en/US/products/ps9924/index.html >> > I'm not sure about shorewall, Shorewall and Multiple Internet Connections http://www.shorewall.net/MultiISP.html > but for Linux there is no problem to > handle multiple channels with NAT on each - in many variations, from > simple multi-target route (ip route add default nexthop ... nexthop ... > ) to complex routing table to route each host/subnet to it's own > outgoing iface. Andrew, Thanks for verifying this is still possible. I recall discussions of multiple dial-up ppp links on our lists in the past. However, we lack Multi-WAN documentation. Other project pages: http://wiki.openwrt.org/doc/uci/multiwan https://www.youtube.com/watch?v=xTMiAAw0kHo http://www.darkhawk.net/dd-wrt/scripts/ ClearOS and pfSense seem to dominate this particular niche at the moment. http://www.clearcenter.com/support/documentation/clearos_enterprise_5.1/user_guide/multi-wan http://doc.pfsense.org/index.php/Multi-WAN_2.0 -- Mike Noyes http://sourceforge.net/users/mhnoyes https://plus.google.com/u/0/113364780158082152468 -- 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
Re: [leaf-devel] BuC 4.3 interface naming
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 >> 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 > > First reset the maint branch: > git checkout maint That is where I am now > git fetch Why? I thought GIT was clever whatever. > 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 > > 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. 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. /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. 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? > > And resolv conflicts. Jz... I hate conflicts, that is why I liked lockable mods. > > 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 conf/sources.cfg| 11 ++ repo/bbnameif/buildtool.cfg | 75 +++ repo/bbnameif/buildtool.mk | 31 ++ repo/bbnameif/mactab|6 +++ repo/bbna
Re: [leaf-devel] BuC 4.3 interface naming
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 > 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. First reset the maint branch: git checkout maint git fetch git reset --hard origin/maint Then you must rebase your nameif branch from maint: git checkout nameif git rebase maint And resolv conflicts. 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 Yves -- 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
