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 18, 2010 13:26 UTC (Fri) by marcH (subscriber, #57642)
In reply to: Finding a patch's kernel version with git by farnz
Parent article: Finding a patch's kernel version with git

You did not read the rest of my post.


(Log in to post comments)

Finding a patch's kernel version with git

Posted Jun 18, 2010 13:34 UTC (Fri) by farnz (subscriber, #17727) [Link]

No, I read it, but I thought you were completely and utterly out of touch with reality. Everyone I know who uses source control has multiple branches; if nothing else, you branch when you tag so that you have somewhere to work on maintenance fixes separately from your feature improvements. All that the difficulty in merging that SVN and CVS impose (but other centralised systems don't - this isn't a natural advantage of DVCSes) does is ensure that I'm more likely to make the sort of human error that I mention in my post.

Clearly, you did not bother to read my post; you just saw a counterexample to your point, and decided to play hurt.

Finding a patch's kernel version with git

Posted Jun 20, 2010 7:23 UTC (Sun) by chad.netzer (subscriber, #4257) [Link]

And perhaps you didn't read the LKML thread linked to in the article, which says the buggy patches were created in December (thus "ordered in time" like your SVN revisions). However, they were not actually merged into the stable branch at all, only into the development branch much later. An analogous situation with SVN could just as easily occur, as it was a really a matter of making an incorrect assumption based on the "ordering in time" of the commit.

Finding a patch's kernel version with git

Posted Jun 20, 2010 21:00 UTC (Sun) by marcH (subscriber, #57642) [Link]

> An analogous situation with SVN could just as easily occur,

Please demonstrate it in more detail, thanks. Warning: you're not allowed completely artificial commands or workflows that a regular SVN user would never use in pratice.

Finding a patch's kernel version with git

Posted Jun 21, 2010 8:11 UTC (Mon) by chad.netzer (subscriber, #4257) [Link]

I'm intrigued by your warning; I'm not sure I want to take on the responsibility of not disappointing you.

Any system of development with feature branches, release branches, and a trunk can allow this situation to occur, since not all features need be merged into trunk before a release. farnz's example was adequate; rev numbers themselves aren't an indicator of when and where a bug might have been merged into trunk. That's why nearly all modern systems have history visualization.

You were discussing "centralized systems", and made the claim "by making branching and merging expensive, you prevent yourself from going into a complicated situation where you cannot easily track commits any more." However, I was discussing SVN, and one of the features of SVN is that branches are cheap:

http://en.wikipedia.org/wiki/Apache_Subversion#Features

So, does your claim apply to SVN? If so, perhaps you can suggest a change to the example SVN workflow on Wikipedia, demonstrating "many branches", so that it can be improved.

http://en.wikipedia.org/wiki/Apache_Subversion#Branching_...

Finding a patch's kernel version with git

Posted Jun 21, 2010 16:18 UTC (Mon) by marcH (subscriber, #57642) [Link]

> one of the features of SVN is that branches are cheap

This is about the implementation while I am talking about the workflow.

Please have a look at one of Linus' rants about centralized systems where he typically complains about the inconvenience of branching *and merging* in such systems.

Finding a patch's kernel version with git

Posted Jun 21, 2010 18:40 UTC (Mon) by chad.netzer (subscriber, #4257) [Link]

It's not clear *what* you are talking about. You stated "here is at last a feature centralized systems make much easier", but I don't see that supported, unless you are implying that centralized systems force an inherently linear history or short lived branches. It certainly is not the case that "because you can easily order commits in time and use that order as a commit ID", that you can know without inspection that a bug fix commit is included in a release or not. That requires checking the merge history. Certainly that's not unique to distributed systems.

If you mean that the common workflow in centralized systems does not allow long lived branches, and certainly not across releases, well I suppose I can accept that, but it is more a matter of discipline than central vs. distributed. Basically it means keeping non-mergeable feature branches out of the repository, or always rebasing them after a new release, so that branch rev ids are contained strictly between two releases. Neither option seems pleasant.


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