User: Password:
|
|
Subscribe / Log in / New account

Finding a patch's kernel version with git

Finding a patch's kernel version with git

Posted Jun 21, 2010 19:45 UTC (Mon) by chad.netzer (subscriber, #4257)
In reply to: Finding a patch's kernel version with git by iabervon
Parent article: Finding a patch's kernel version with git

Ah, this also explains marcH's points a bit better. I still contend that this is not a "centralized vs. distributed" issue, then, but really a matter of linear vs. non-linear history, and branch management between releases. Certainly the "centralized repo" tools that I'm familiar with have gained better branch and merge support over the years, and more easily support long lived branches and feature branches, without rebasing after each release.

Here is an informative workflow example, demonstrating marcH's "strict ordering" principle:
http://lsimons.wordpress.com/2010/02/19/using-long-lived-...

It works in this case because trunk has no other branches than stable, and stable is (obviously) never merged back into trunk. That same workflow works even with a distributed system (by rebasing before pushing to the main repo, for example). It blends history among developers, however, which can be a disadvantage at times, especially with many developers and features in active development.


(Log in to post comments)

Finding a patch's kernel version with git

Posted Jun 29, 2010 14:58 UTC (Tue) by marcH (subscriber, #57642) [Link]

> I still contend that this is not a "centralized vs. distributed" issue, then, but really a matter of linear vs. non-linear history, and branch management between releases.

Agreed I guess, except you conveniently omit the huge influence that a centralized system has on branching policies (the "workflow").

> Certainly the "centralized repo" tools that I'm familiar with have gained better branch and merge support over the years,

As long a system is centralized, you will neither be able to permanently erase branches nor to re-organize the past in any way. And you will need some human-level protocol to avoid collisions. These, and probably others reasons I miss will always have a chilling effect on branching. Why do you think git-svn is so popular?

I am pretty sure that the main reason why most decentralized systems were invented is because their authors wanted to increase the branching and merging freedom.

My point here is that the tool has a huge influence on the way it is used. Sure you can often hammer down a nail with a screwdriver, but do people do that routinely?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds