On Saturday, April 23, 2011, Peter Baumann <waste.manager@xxxxxx> wrote: > On Sat, Apr 23, 2011 at 05:22:29PM +1000, Jon Seymour > Âgit checkout master > Âgit merge debug topic1 topic2 topic3 > Â... compile ... deploy ... test > >        . - Âq - q -.    <- topic3 >       Â/       \ >      . -s - s - s ---. \   <- topic2 >     Â/         \| >     /  Ât - t - t - - -\   <- topic1 >    Â/  /         m  Â<- master >    /  /        Â/ | >  o - o - o - o - o - o - o Â|  Â<- remotes/trunk >        Â\      Â/ >         Âd Â- d - -    <- debug > > Having fond a small error, I can't commit it directly on the merge m, because > It is actually a fix a topic branch. Running git checkout topicX before doing > any change is also not an option, because I often forget to checkout the topic > before commiting. And rebasing afterwards is also not that easy, because there > is merge m in between. ÂSo this isn't what I actually use, but would be *iff* > there where some sort of tool support to help me. > > What I end up doing is the following: > > - o - o  <- remotes/trunk >    \ >     d - d  <- debug >       Â\ >        Ât - t -t Â<- topic1 >            Â\ >             Âs - s -s Â<- topic2 >                 Â\ >                  q - q  <- topic3, master > > > The topic branches are just there for illustration, I normally do not track > those explicitly with git branches, as master is rebase often on top of trunk, > thanks to git-svn. Now if I do want to commit a topic branch to SVN, I rebase > so that my history is now  trunk - topic1 - debug - topic2 - topic3, master > and then run git checkout topic1; git svn dcommit to make sure only the commits > in topic1 are commited. > > All in all, this workflow is not perfect, but at least it sort of works. > > Now back to my initial question: > Could your new "git work" command help me to adjust my workflow and ease the pain? > > > Peter > Hi Peter, Yes, git work is good for this use case. You would tend to manage you master branch as in your first diagram above. Suppose you found a problem on topicX. So, you fix the issue inplace on the top of your master that includes all 5 dependencies. Call this commit m'. You have decided that the fix really belongs on topic2. So what you do is: git work update topic2 HEAD~1 This will move that commit onto the tip of topic2 (producing topic2'), merge that into m (producing m''), and reset master to m''. One thing to note is that you never share master. It will be a merge hell. You only ever share topics when they become stable. As the trunk gets updated you do: git work merge remotes/trunk It will merge remotes/trunk into the base of your unpublished work, then rebase your unpublished work onto that merge. git work is also excellent for keeping your debug branch available in your working tree but isolated from your topics. Things get little tricker when you have a commit that spans multiple topics. However, there is a straight forward methodology for managing such issues. There are also techniques for dealing with conflicts with any dependency, especially remotes/trunk which I can explain in another note if there is interest. Jon. -- 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