Re: [RFC] git commit --branch

[Martin Waitz <tali@admingilde.org>]

[-- Attachment #1: Type: text/plain, Size: 3667 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]