introduction: topgit (tg) is a tool keeping track of patches on top of branches so that you can work on those patches before comitting them upstream. So you can do tg create dep1 dep2 to make your new topic branch depend on the two branches dep1, dep2. tg first merges dep1 dep2 into a base. On top of this base you start comitting your changes. when following upstream a new base is created by merging the old base with dep1, then dep2 again. The new base is merged into your topic branch. This requires keeping track of the base. That has been done by adding an extra references to .git/refs/top-bases/TG_NAME. problems: You have to push the branch and the base to the remote location. If you clone a top git related branch you have to get the bases as well (tg remote --populate does this for you). Uwe Kleine-König (current maintainer?) has proposed no longer tracking the topgit branch base using a ref but adding antoher .top* file .topbase containing the hash of the base. Neither pushing nor pulling causes trouble because the base is always contained in the topic branch. So no need to extra push/ pull contents of that branch. Another benefit of this change is that you can easily make a top git branch out of an ordinary branch by adding those 3 files (.topbase, .topmsg, .topdeps). I don't see any problems implementing this except one. I'm not sure in which way this has been adressed in the past by topgit: Have a look at the following illustration: http://mawercer.de/~marc/tg.svg (32kb). Imagine two independant clones of a topgit branch (red, green). Now users run tg update at slightly different points in time. So both will get a different new base (B2 and B3) of the clone topgit branch. Now red merges the topic branch (merge 1). Then a third user (blue) merges that merge (merge 2). If a merge strategy "ours" is used the way its done for the other .top* files the blue user's base won't know about B3. First merge we have a conflict: If B3 and B2 are different a merge conflict occurs: .topbase: <<<< hash1 ==== hash2 >>>> Now the two bases should be merged to a new base (Bnew). That new base should be written to .topbase and everything is fine again? Is there a way to specify such a merge action: extract both hashes (easy) merge them and put the resulting hash back into .topbase. Of course this merge action must handle merge conflicts in a way which is similar to what tg already does. tg starts a subshell and asking the user to fix the conflicts. Even if there is a nice way to implement this merge action this doesn't seem to solve all trouble? The Bnew base is neither part of the red nor the green topic branch. Thus it can't be pushed somewhere by pushing red or green only containing the ref in .topbase? So in the end: Have I missed a point ? So are there more advantages having a self contained top git branch compared to beeing able to merge bases? Maybe merging bases doesn't occur that often in practise? So if we don't want to give up beeing able to merge bases I till want to see a git push branch command also pushing the base. Currently you can do $git push which will push *all* bases and branches. Probably I've missed some small details while explaining this idea and talking about its issues. So please do ask. Sincerly Marc Weber -- To unsubscribe from this list: 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
