Re: [RFC] git commit --branch

[Junio C Hamano <junkio@cox.net>]

Martin Waitz <tali@admingilde.org> writes:

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

Funny you mention this.  I had exactly the same arrangement for
hacking on gitweb.  One "localconf" branch to tell it where the
repositories are, "origin" to track upstream, "master" to use
for deployment, and other topic branches.  I used git-fetch to
keep updating "origin" (not git-pull), grew and rebased topics
based on "origin".  "master" was rebuilt from "origin" by
merging "localconf" and topics.  Some of the stuff I did in my
topics involved changing the way local configuration is done, so
I had an extra topic "newconf" which branched from "localconf"
but merged from the topic branch.

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

When I re-read his suggestion, literally he talks about creating
a new topic, but I assumed he just meant "you could _even_
create a new branch if you wanted to" -- you can switch to
another existing topic branch do with "git checkout", perhaps
with the -m flag.  While I was on the "master" to figure out why
gitweb was not behaving for me, and figured out a mis-
configuration that should be fixed in "newconf" topic, I
switched to that topic and committed the fix there, after
testing the change there.  Then either merging it back to
"master" or rebuilding "master" from scratch based on "origin"
and merging my topics got me a working gitweb back.

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

That is something you cannot.  The merged test branch contains
other unrelated changes.  As you describe, the test branch in
your (and mine) workflow is throw-away in nature, so a proper
fix should go to the relevant topic, and while working on a
single topic, I do not want to see what other topics introduced
to the file -- I may accidentally depend on them, creating
unnecessary interdependencies between topics.

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

I often find myself spending too much time fixing what I
committed without thinking and testing -- assuming something is
"trivial" which turns out to be not so -- so I try to stay away
from the idea of having a "trivial" branch.  But if you want to
do things that way, you could trivially do so by having a
wrapper around git commit.  By building something into
git-commit command, you are actively encouraging one workflow,
and commit without testing is one thing I do not particularly
want to encourage people to do.  We have selective commit with
"git commit [-i] <paths>..." which is already bad enough.

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

I am not sure what you want to say here.  You realize some
breakage, do initial/preliminary fix while on the test branch,
take the change to the relevant topic branch to do the real
fix.  You can merge the result back to the test branch when your
changes on the topic is ready.  I do not see where conflicting
change makes a difference.