rethinking patch management with GIT / topgit

[Thomas Koch]

martin f krafft: 
> > 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.
Well, I consider as benefits:
- no pollution of the patch branches with meta files and therefor no need for 
special hooks or merge policies to ignore them
- since there's nothing special about a patch branch, it can happily be shared 
by multiple patch sets.
- since there's one file with all informations from .topdeps, it should get a 
little faster
 
> I'd really prefer to find a way to encode the information we need
> for packaging in the tool itself, if at all possible.
From my perspective, the workflow is a smoothly integrated in GIT as possible. 
If I sent you a patchset meta branch, without any other branch, all you need 
to do is (in pseudo shellscript):

$BRANCHES=$(git show $PATCHSETMETABRANCH:branches|grep "^BRANCH:")
for $BRANCH in $BRANCHES;do
   # Parse the BRANCH: line into $BRANCHNAME $COMMITSHA1
   git update-ref refs/heads/$BRANCHNAME $COMMITSHA1
done

And you've recreated the patchset as I had it on my machine.
Since all top-commits of all patch branches have at some time been merged into 
the patchset's meta branch, you've all got them with only one pull of the 
patchset meta branch.
That's IMHO the whole beauty of my approach: Push/Pull one branch and you've 
got a whole patchset.

> > > 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.
The data we need to store somewhere and that you dislike to be stored in a 
meta branch, is:
- branch name to commit mapping
- roots (dependencies) of the branches
- branch messages
- as sugar: whether a branch is enabled for export or not

And of course these informations are worth tracking and sharing between 
maintainers. 
Git notes do not seem to be intended for sharing, at least there're apparently 
no obvious toolchain and semantics for sharing them:
http://comments.gmane.org/gmane.comp.version-control.git/141780

> Are you suggesting that the fork of a patchset becomes its own
> patchset without shared ancestry of the original?
There are 3 different ways to fork a patchset, which could all be usable in my 
workflow and used on a case by case base:

- checkout new patch branches from the top of the old patch branches and merge 
upstream into each of them

- recreate (like rebase) the full history of the patch branches on top of the 
new upstream

- collapse the branch history and create one commit per patch branch on top of 
the new upstream

Gruß,

Thomas Koch, http://www.koch.ro