Re: [RFC] git commit --branch

Martin Waitz [off-list ref] writes:

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).

hoi :)

On Tue, May 30, 2006 at 02:12:02AM -0700, Junio C Hamano wrote:

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.

yes. I was doing this after working on gitweb a bit.
In order to test gitweb, I need some local adaptations.
I commited these to one branch and put all improvements to
another branch.  Then I merged both branches to one production
path which is then used by the webserver.

While I think that is _one_ valid workflow, I am not convinced
that is _the_ best workflow.

Me neigther.
That's why I labeled it RFC and published it before doing too much
testing and polishing ;-)

What Johannes suggested would
equally work fine, and honestly speaking probably is a better
discipline.

He suggested to create a new branch (based on current HEAD) for the
new commit.  Unfortunately that doesn't solve my problem.

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.

Of course you can do this also while you are still on the test branch.

While looking at code I often see unrelated stuff which can be cleaned
up.  With something like commit --branch it would be possible to stuff
these changes to a "trivial" branch without having to change branches
explicitly.

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.

But if your commit to the topic is really different to previous
commit on the test branch then you may have merge problems later.
If you merge immediately, you even get the merged tree for free ;-).
The testing branch is more like a throwaway-branch for me.
I can recreate it anytime if I want and I don't care about extra
merge commits here.

 - A topic branch should be testable alone;

That would be best, yes.
Unfortunately it didn't work for me.
Well I guess I could have put more effort on changing gitweb to
be more general so that I don't need local adaptations.
But I guess there are situations where this is not possible, too.
Of course, now we have to answer the question whether GIT should
support these situations.  I don't know.

-- 
Martin Waitz