Re: [PATCH 00/23] RFC: Introducing git-test, git-atomic, git-base and git-work

[Jon Seymour <jon.seymour@gmail.com>]

On Saturday, April 23, 2011, Peter Baumann <waste.manager@gmx.de> 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.