Junio C Hamano wrote:
>A "bind commit" proposal was made to support subprojects living
>in their own subdirectories. The picture to describe the commit
>ancestry chain would be almost the same as the above picture,
>except that it did not uncap and recap, but would have built its
>own ancestry chain.
>
>
I had considered that this would make directory subprojects possible,
but didn't want to draw attention to it.
Actually I'm now of the thinking that the problem is that we are using
'parent' for two things;
1. the merge bases for this merge, if a merge
(or the base for this change for a patch)
2. the historical precedent(s) for this commit.
In the single line of history case these are always the same. For an
actual merge they are also the same. However, when you are superceding a
merge with a newer merge, or mucking with history they are different.
So, I think all we need to make this all work smashingly well is to have
a new field called "prior" or perhaps "previous".
As well as being mostly backwards compatible and supporting grouping
your commits into topics in a single checkout, this would also have the
side effect of:
- directly supporting stgit / pg style patchset evolution, without
needing to use seperate branches for each release of your patchset. This
would not replace the need for stgit etc to wind the head - while
revising a patchset you really don't want the system to record
intermediate changes, just the ones you want to publish
- supporting tree subprojects (as it is a more specific use case)
- rewriting history! Without losing the old commits. Unless you wanted
to - say, for archiving old commits by rebasing the whole project off a
new revision.
It also does not suffer from the 'problem' in Andreas' "dual head
commit" approach that one commit will thenceforth be known by two commit
IDs.
>It had two different kinds of commit relationships: parenthood
>and directory structure binding. The component subprojects
>lived in their own subdirectories (so if you are maintaining an
>embedded Linux along with matching toolchain, you would have linux/
>subdirectory that has the kernel hierarchy, gcc/, libc/, ...),
>and commit objects had "bind commit-sha1 subdirectory-name"
>lines to express how the components are bundled together. A
>commit object would have looked like this:
>
> tree fc9957b0052df6a8248420395bc9febd66194252
> parent 052df6a8248420395bc9febd66194252fc9957b0
> bind f6a8248420395bc9febd66194252fc9957b0052d linux/
> bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/
> author A U Thor <author@xxxxxxxxxxx> 1144111304 -0700
>
>The "parent" line is the commit ancestry as usual, and each
>"bind" line names a commit object of component project and where
>in the directory hierarchy the tree for that commit object would
>be checked out. The "tree" line records the result of grafting
>the subprojects together. So, for example, ls-tree -d fc9957
>linux in the above example would have shown the tree object
>f6a824^{tree}.
>
>
While the approach I outlined supports this in a way, it is subtly
different.
Firstly, the above approach makes it a hard requirement that the
independent series of commits are in seperate paths, you mention a fix
for this -
>The structure forbid you from binding two separate projects at
>the same directory in order to enforce clean separation of
>subprojects, but if you allow multiple commits to be bound at
>the root level, that could be used as a hydra cap.
>
>
- but this means you are not storing the 'merged' tree in the commit,
which I think is a mistake. While we've been talking mostly about
dealing with managing changes simple enough to merge plainly for
simplicity of operations, this would *force* it to be so because you
need to allow anyone to check it out.
On the other hand - these bind commits enables tracking a sub-project in
a sub-directory whilst retaining the same commit IDs, to make tracking
easier.
Even this works using "prior", too - though you'd have to use surrogate
commits that link to the sub-project commit and wrapper tree object.
How does that sound?
Sam.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html