Re: Merge with git-pasky II.

These notions that one can always best answer questions by looking at the content, and that "Individual files DO NOT EXIST" seem over stated, to me.

Granted, overstated for a good reason. A couple sticks of dynamite are needed to shake loose some old SCM thinking habits.

===

Ingo has a point when he states:

He too overstates - it's not _the_ (as in one and only) thing. But it's useful. Given the traditional terseness of many engineers, it's certainly not the _only_ thing. The code speaks too.

===

The above two are related in this way. Traditional SCM uses per file (versioned controlled file, as in s.* or *,v files) metadata to track 'developer intent'.

I'm afraid we are at risk for confusing baby (developer intent) and bathwater (version controlled file structure of classic SCM's).

===

But we already have a pretty damn good way of tracking developer intent that needs to fit naturally with whatever we build on top of git.

     Mr. McGuire: I just want to say one word to you - just one word.
     Ben: Yes sir.
     Mr. McGuire: Are you listening?
     Ben: Yes I am.
     Mr. McGuire: 'Patches.'
     # the original word was 'Plastics' - The Graduate (1967)

Andrew and the other maintainers do a pretty good job of 'encouraging' developers to provide useful statements of 'intent' in their patch headers.

The patch series in something like *-mm, including per-patch commentary, are a valuable part of this project.

===

I have not looked closely at what is being done here, on top of git, for SCM like capabilities. Hopefully the next two questions are not too stupid:

 1) How do we track the patch header commentary?

 2) Why can't we have a quilt like SCM, not bk/rcs/cvs/sccs/... like?

For (2), anyone publishing a Linux source would periodically announce an <sha1> value, attached to some name suitable for public consumption.

For example, sometime in the next month or so, Linus would announce that the <sha1> of 2.6.12 is so-and-so. That would identify the result of applying a specific set of patches, resulting in a specific source tree contents. He would announce a few 2.6.12-rc* <sha1>'s between now and then.

Between now and then, Andrew would (if using these tools) have published several <sha1> values, one each for various 2.6.12-rc*-mm* versions.

If you explode such a <sha1> all out into a working directory, you get both the source contents in the appropriately named files, and the quilt-style patches subdirectory, of the patch series that gets you here, starting from some Time Zero for that series of published kernel versions.