rethinking patch management with GIT / topgit

Mon Apr 12 13:59:54 UTC 2010

also sprach Thomas Koch <thomas at koch.ro> [2010.04.12.1538 +0200]:
> I started a prototype in perl yesterday, but it still needs some hours. I'm 
> also new to perl so I could need a hand of a perl expert. If you've time, I'd 
> also be glad to meet for a hacking session.
> Do you propose a more suitable language for this tool?

I'd use a language you know. If Perl is new to you, then you're in
for a very rough ride.

I also think Perl is for text-processing, but that's just me.

> The merge commits do not intend to replace .topdeps. The intend of the merges 
> is solely to not loose commits. .topdeps is replaced by the file "branches" 
> shown in my blogpost.

Okay, so no real benefit because to me it doesn't matter where the
file is stored. I was hoping that you'd encode this information into
the DAG.

> > 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.
> The worktree won't be touched by my proposal. What makes you think
> that? All changes to the patchset's meta branches are done by the
> toolchain in the background without touching the worktree.

I was thinking the worktree of the meta branch, i.e. the branches
file.

> I've actually started my prototype by copying code from
> pristine-tar. All changes to the pristine-tar branch are made in
> a temporary directory outside the worktree.

Okay, but pristine-tar needs to store non-VCS information, so it
makes sense for that tool.

I'd really prefer to find a way to encode the information we need
for packaging in the tool itself, if at all possible.

> > 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.
> I'm not up to date about GIT notes. Could you point me to a description? As 
> far as I've seen, GIT notes is still experimental? Are GIT notes of existing 
> commits immutable? That would be required to make sure history won't get lost 
> or modified.

man git-notes

No, the notes are not immutable, it seems. The question is whether
the data to be stored therein are worth tracking.

> > 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.
> Sorry, but I believe you think way to abstract. What I like about
> my proposal is, that it only stores a few bytes of meta
> informations additional to a plain, regular, unspectacular GIT
> repository.

I see the benefit in that, but I am not sure we couldn't take this
further. I'll have to wait for your reference implementation though.

> > 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.
> I guess so. This is one of the main design goals beside the
> ability to have multiple independent patchsets in the same
> repository.

Are you suggesting that the fork of a patchset becomes its own
patchset without shared ancestry of the original?

-- 
 .''`.   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

"never attribute to malice what can be
 adequately explained by incompetence."
                                                       -- mark twain
-------------- 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/e1b5274d/attachment.pgp>