Re: [RFC] git commit --branch

From: Junio C Hamano <junkio@cox.net>
Date: May 30, 2006, 09:12 UTC
Message-ID: <7vr72b27x9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060529202851.GE14325@admingilde.org>

Martin Waitz <tali@admingilde.org> writes:

Show 19 quoted lines

> Allow to commit to another branch and creating a merge in the current branch.
>
> Sometimes it is neccessary to have some local modifications in the tree
> in order to test it and work with it.  With this patch you can have
> one working tree which combines several topic branches in order to
> develop and test your changes.  When your changes are ready, you can
> commit them to the appropriate topic branch.
>
> With the --branch option, the commit will automatically be rebased to
> that branch.  The original tree will then be commited to your working
> branch as a merge.
>
> ---
>
> Perhaps something like this can even be integrated into the extended
> branch configuration which is currently under discussion.
> It may make sense to have one branch which always contains a merge
> of a selected set of other branches and having a default branch
> for new commits.

I think this was discussed in the past and I appreciate what you are trying to do. My understanding of the situation your patch is trying to improve is this:

 - you have done a few topics and you are ready to test;

 - you pulled the topics into your test branch and have found
   problems;

 - you made changes while still on the test branch (otherwise
   you wouldn't be able to test the "fix") and it seems to work
   OK;

 - what now?

And your approach is to backport the fix to its original topic and then re-pull the topic onto the test branch.

While I think that is _one_ valid workflow, I am not convinced that is _the_ best workflow. What Johannes suggested would equally work fine, and honestly speaking probably is a better discipline. You carry the fix in your working tree back to its original topic and make a commit, without pulling the topic onto the test branch immediately. This has two advantages:

 - With your workflow, you will have a merge commit onto the
   testing branch immediately when you commit this fix to the
   original topic.  But often when I encounter this situation,
   after moving to the topic to backport the fix to it, I find
   myself reviewing what is in the topic and making other
   changes to the topic.  Johannes's workflow feels more natural
   to me from this aspect -- I take the fix I discovered while
   on the testing branch to the relevant topic to fix it.  I may
   or may not make the commit only with that fix (the first
   commit I make after switching the branches from testing to
   the topic may contain more than that fix), and after I make
   one commit, I may keep working on the topic a bit more before
   I decide it is a good time to test the whole thing again (to
   pull the topic into testing).  I do not necessarily want that
   extra merge immediately in the test branch.

 - A topic branch should be testable alone; if the changes near
   the tip of your topic depends on other topic (or more recent
   mainline than where the topic forked), then I think you
   shouldn't hesitate to pull in the other branch into the topic
   to keep it buildable and testable.  And your commit should be
   made after testing your changes; with your workflow, you have
   only tested the change in the context of the testing branch,
   not the topic branch your "primary" commit is on, even though
   that commit will be the source of eventual graduation to the
   mainline.  With Johannes's workflow, you first carry the
   change to the topic, so you have a chance to test it before
   making the commit (if you are not disciplined, you can make
   the commit without testing after switching branches, but the
   point is it gives people an option to test things before they
   make a commit if they wanted to).