Finding a patch's kernel version with git
Posted Jun 18, 2010 9:53 UTC (Fri) by marcH
In reply to: Finding a patch's kernel version with git
Parent article: Finding a patch's kernel version with git
In a centralized system you can easily *order* commits in time and then use this order as a much user-friendlier commit ID than a checksum (this is exactly what subversion does).
> Could you provide an example?
238 release_4 tag
345 bugfix commit
525 release_5 tag
From the above it is obvious that release 5 is fixed while release 4 is not.
> To the extent that, with a centralized system, developers can't do any development that would make the naive method wrong, that's true.
I guess this is more or less what I meant: by making branching and merging expensive, you prevent yourself from going into a complicated situation where you cannot easily track commits any more.
> A decentralized system makes it feasible to use a process which prevents bugs from affecting releases that one would expect them to affect. Even aside from getting the analysis right, it's hard to say that, when it looks like a bug affects several releases, you'd rather it actually affect all of them than turn out to have been excluded from them.
Now you lost me.
to post comments)