rethinking patch management with GIT / topgit

[martin f krafft]

also sprach martin f krafft <madduck at debian.org> [2010.03.27.0801 +0100]:
> I would love to hear more about what you propose. Have you
> considered writing this up as a paper or website with graphs to
> help us get a better idea of who you'd implement this, and how
> users are supposed to use this solution?

Thomas, I have now had a bit of time to read through the entire
thread and the document you wrote up at

  http://www.koch.ro/blog/index.php?/archives/138-Design-document-for-a-patch-management-system-on-a-DVCS.html

Before I forget: if you have not yet done so, could you please
create a vcs-pkg tag on your blog and aggregate it on
http://vcs-pkg.org/planet/? Thanks!

Now to the solution you propose: I have multiple, mixed reactions to
it:

1. I am excited that you are tossing about a new idea. I am looking
   forward to playing with it.

2. I have always disliked .topdeps, which feels like it's doing
   something that should and could be better done by Git itself. As
   a result, .topdeps feels brittle to me. Your proposal to use
   merge commits may be usable to replace .topdeps, but I'll need to
   explore it a bit more. A reference implementation would be really
   useful.

2b. How would your implementation represent a tree with three
    feature branches, where B and C both depend on A, e.g.

                 B
                /
    upstream — A
                \
                 C

3. It seems to me that you are proposing to store meta information
   in plain files in meta branches (cf. .topdeps). If at all
   possible, I'd say we should avoid touching the worktree
   altogether, but to design a protocol by which all the information
   we need is kept in the Git DAG and its objects.

4. Rather than a meta branch, if we had a means to store and update
   information for each branch, we could solve the problem and store
   .topmsg, as well as the top-bases/* pointer in there.
   A rudimentary implementation might be using Git notes, e.g.: walk
   up the ancestry until you find a specially-formatted Git note,
   and use that as branch meta data store. If the data change, then
   write a new note to the top-most commit.

5. It occurs to me that what we want to implement somehow should get
   rid of .top* files and top-bases/*, and instead allow us to track
   "commits" at a much higher level. E.g. a branch creation is
   a commit, updating feature branches is a commit (I see no reason
   to allow updating of single feature branches independently, but
   would say either all or none), integrating feature branches is
   a commit. The way to represent that might be using a meta
   hierarchy with the merge commits you suggest, but which also keep
   ancestry.

6. One of the main issues I have with TopGit is that it's not really
   possible to consistently tag a release with all its branches.
   E.g. you need to tag all branches, and all top-bases at the time
   of the TopGit tag, which appears brittle itself. If indeed we can
   find a method where a single commit represents the entire state
   of a tree+feature branches at a time, and one could generate all
   kinds of patch formats from it, and even fork the tree with all
   feature branches from this point, then that would be splendid.

-- 
 .''`.   martin f. krafft <madduck at d.o>      Related projects:
: :'  :  proud Debian developer               http://debiansystem.info
`. `'`   http://people.debian.org/~madduck    http://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems
 
"no work of art ever puts forward views.
 views belong to people
 who are not artists."
                                                        -- oscar wilde
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: <http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20100412/7a139c05/attachment.pgp>