Le 7 oct. 2012 à 00:50, Erich Titl a écrit :

> 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.

Because patches can be hard to be applied if you change only whitespaces. Also 
it's better for the one that will be edit the file later.

> 
>> 
>> 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.
> 
Yes small commits are better than one big for comprehension. But for example in 
the 3461de4 you only replace () with {}. It doesn't add any value for your 
topic branch that is enable nameif busybox applet. So for this example the 
3461de4 and 41dfb90 can be squash together. Also the 0ff5054 and 41dfb90 can be 
squash together (you can add a comment in the commit message to said that you 
add a little bit of comment to the mactab files).


>> 
>> So before merging the branch do a:
>> 
>> git rebase -i maint
> 
> Mhhhh... if only I could understand that concept/word….
> 
git rebase -i allow to managed your patches: squash, delete, amend commits.

> 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.
> 
The problem is that we don't maintain minor version of a bering-uClibc series: 
4.2, 4.3, etc…
So for you problem you are invite to upgrade to 4.3.1 to have the new 
functionality :D


>> 
>> 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.
> 
:P

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

Reply via email to