[RFC] git commit --branch

[RFC] git commit --branch

[Martin Waitz]

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.

 Documentation/git-commit.txt        |    6 +++
 git-commit.sh                       |   62 ++++++++++++++++++++++++++++++++++-
 t/t3800-commit-onto-other-branch.sh |   32 ++++++++++++++++++
 3 files changed, 99 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 38df59c..8111ba4 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -49,6 +49,12 @@ OPTIONS
 	Override the author name used in the commit.  Use
 	`A U Thor <author@example.com>` format.
 
+--branch <branch>::
+	Actually commit the changes to another branch.
+	Afterwards it will be merged into the current branch.
+	This is useful if you work on a branch with local modifications
+	but want to keep one clean branch without those.
+
 -m <msg>::
 	Use the given <msg> as the commit message.
 
diff --git a/git-commit.sh b/git-commit.sh
index 1983d45..9ed0050 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,7 +3,7 @@ #
 # Copyright (c) 2005 Linus Torvalds
 # Copyright (c) 2006 Junio C Hamano
 
-USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [[-i | -o] <path>...]'
+USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [--branch <branch>] [[-i | -o] <path>...]'
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
 
@@ -245,6 +245,12 @@ do
       force_author="$1"
       shift
       ;;
+  -b|--b|--br|--bra|--bran|--branc|--branch)
+      case "$#" in 1) usage ;; esac
+      shift
+      onto_branch="$1"
+      shift
+      ;;
   -e|--e|--ed|--edi|--edit)
       no_edit=
       shift
@@ -405,6 +411,7 @@ t,,[1-9]*)
 	die "No paths with -i does not make sense." ;;
 esac
 
+
 ################################################################
 # Prepare index to have a tree to be committed
 
@@ -623,6 +630,32 @@ else
 	current=
 fi
 
+if test -n "$onto_branch"
+then
+	onto_branch_commit=$(git-rev-parse --verify "$onto_branch") ||
+		die "Branch $onto_branch does not exist."
+	test $(git merge-base "$onto_branch" HEAD) = $onto_branch_commit ||
+		die "Branch "$onto_branch" already contains unmerged commits."
+	case "$PARENTS" in
+	-p*-p*)	die "Cannot commit a merge to another branch." ;;
+	esac
+	if test $(git-rev-parse --verify HEAD) = $onto_branch_commit
+	then
+		# no merge neccessary, branches identically
+		forward_onto_branch="$onto_branch"
+		onto_branch=""
+	fi
+	if test "$amend" = t
+	then
+		# test that the tip of HEAD really came from the tip of
+		# $onto_branch and that we can amend both of them
+		test $(git merge-base "$onto_branch" HEAD^) != $onto_branch_commit &&
+		test $(git merge-base "$onto_branch"^ HEAD^) = $(git rev-parse --verify "$onto_branch"^) ||
+			die "commits on $onto_branch and HEAD differ, cannot amend."
+		onto_branch_commit=$(git rev-parse --verify "$onto_branch"^)
+	fi
+fi
+
 if test -z "$no_edit"
 then
 	{
@@ -689,8 +722,35 @@ then
 		tree=$(GIT_INDEX_FILE="$TMP_INDEX" git-write-tree) &&
 		rm -f "$TMP_INDEX"
 	fi &&
+	if test -n "$onto_branch"
+	then
+		# create temporary index
+		ONTO_INDEX="$GIT_DIR/onto-index"
+		cp "$USE_INDEX" "$ONTO_INDEX" &&
+		GIT_INDEX_FILE="$ONTO_INDEX" \
+		git-read-tree -i -m "$onto_branch_commit"
+		# merge new changes into the branch
+		GIT_INDEX_FILE="$ONTO_INDEX" \
+		git-read-tree -i --aggressive -m \
+			HEAD "$onto_branch_commit" "$tree" &&
+		GIT_INDEX_FILE="$ONTO_INDEX" \
+		git-merge-index git-merge-one-file -a || {
+			echo >&2 "Cannot rebase your commit to $onto_branch."
+			echo >&2 "Please merge and commit manually."
+			false
+		} &&
+		tree2=$(GIT_INDEX_FILE="$ONTO_INDEX" git-write-tree) &&
+		commit2=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree2 -p $onto_branch_commit) &&
+		git update-ref "$onto_branch" $commit2 &&
+		rm -f "$ONTO_INDEX" &&
+		PARENTS="$PARENTS -p $commit2"
+	fi &&
 	commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
 	git-update-ref HEAD $commit $current &&
+	if test -n "$forward_onto_branch"
+	then
+		git-update-ref "$forward_onto_branch" $commit $current
+	fi &&
 	rm -f -- "$GIT_DIR/MERGE_HEAD" &&
 	if test -f "$NEXT_INDEX"
 	then
diff --git a/t/t3800-commit-onto-other-branch.sh b/t/t3800-commit-onto-other-branch.sh
new file mode 100755
index 0000000..f4f6410
--- /dev/null
+++ b/t/t3800-commit-onto-other-branch.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Martin Waitz
+#
+
+test_description='Test a commit to another branch'
+
+. ./test-lib.sh
+
+echo AAA > A
+echo BBB > B
+
+test_expect_success 'Initial commit' \
+'git add A B &&
+ git commit -m "Initial commit" &&
+ git branch topic'
+
+test_expect_success 'Modify HEAD' \
+'echo A2 > A &&
+ git commit -m "modify A" A'
+
+test_expect_success 'Commit to branch' \
+'echo B2 > B &&
+ git commit -m "modify B" --branch topic B'
+
+# now test that HEAD and topic only differs in A
+test_expect_success 'Verify trees' \
+'echo ":100644 100644 43d5a8e... 3ce238a... M	A" > expected &&
+ git diff-tree --abbrev topic HEAD > current &&
+ diff expected current'
+
+test_done
-- 
1.3.3.ged90


-- 
Martin Waitz

Re: [RFC] git commit --branch

[Shawn Pearce]

Martin Waitz <tali@admingilde.org> wrote:
> Allow to commit to another branch and creating a merge in the current branch.

Interesting.  I have been kicking around doing the very same
thing myself but just have not gotten around to it.  Its complex,
especially if the current HEAD isn't strictly the merge commit
between the topic branch and the previous value of HEAD; in that
case you may want to replay the commits which are on HEAD but are
post the merge commit using a form of git-rebase.  Except you would
want to preserve any merges which happened by remerging them rather
than simply exporting a massive patch and reapplying it.
 
> +		test $(git merge-base "$onto_branch" HEAD^) != $onto_branch_commit &&
> +		test $(git merge-base "$onto_branch"^ HEAD^) = $(git rev-parse --verify "$onto_branch"^) ||
> +			die "commits on $onto_branch and HEAD differ, cannot amend."
> +		onto_branch_commit=$(git rev-parse --verify "$onto_branch"^)

Shouldn't these be 'git-merge-base' and 'git-rev-parse' ?

> +		git update-ref "$onto_branch" $commit2 &&

If this is going into next perhaps you would like to considering adding
the -m flag to your git-update-ref calls and include a log message
in the reflog (if the user has it enabled for the current branch and
the topic branch)?

Also shouldn't this be 'git-update-ref'?

-- 
Shawn.

Re: [RFC] git commit --branch

[Martin Waitz]

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

hoi :)

On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:
> Interesting.  I have been kicking around doing the very same
> thing myself but just have not gotten around to it.  Its complex,
> especially if the current HEAD isn't strictly the merge commit
> between the topic branch and the previous value of HEAD; in that
> case you may want to replay the commits which are on HEAD but are
> post the merge commit using a form of git-rebase.  Except you would
> want to preserve any merges which happened by remerging them rather
> than simply exporting a massive patch and reapplying it.

Perhaps something like merge-recursive makes sense, except that
I have no clue how it works ;-)

But then an operation as important as commit has to be bullet-proof
and I don't like to do anything complex in there.

In any case, this functionality needs a lot of testing.
Any contributions to the test case are welcome :)

> > +		git update-ref "$onto_branch" $commit2 &&
> 
> If this is going into next perhaps you would like to considering adding
> the -m flag to your git-update-ref calls and include a log message
> in the reflog (if the user has it enabled for the current branch and
> the topic branch)?

Makes sense.

> Also shouldn't this be 'git-update-ref'?

Yes, all the rest uses git-*, too.
If the move to buildin commands continues at the same speed we
may soon be able to remove some "-"s, but it's not time for that yet.

-- 
Martin Waitz

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

Re: [RFC] git commit --branch

[Shawn Pearce]

Martin Waitz <tali@admingilde.org> wrote:
> On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:
> > Interesting.  I have been kicking around doing the very same
> > thing myself but just have not gotten around to it.  Its complex,
> > especially if the current HEAD isn't strictly the merge commit
> > between the topic branch and the previous value of HEAD; in that
> > case you may want to replay the commits which are on HEAD but are
> > post the merge commit using a form of git-rebase.  Except you would
> > want to preserve any merges which happened by remerging them rather
> > than simply exporting a massive patch and reapplying it.
> 
> Perhaps something like merge-recursive makes sense, except that
> I have no clue how it works ;-)

merge-recursive isn't the right tool here. Its job is to perform a
3 way merge "quickly" by dealing with file adds, deletes, renames
and patch application when a file was modified by both parents.

Now that diff+apply is probably faster than a 3 way merge in
read-tree precisely because it doesn't need to run merge-recursive
I'm starting to look at how we can use apply to do partial
application of a patch and use RCS' diff3 or just drop a reject
file out when a hunk doesn't apply cleanly.
 
> But then an operation as important as commit has to be bullet-proof
> and I don't like to do anything complex in there.

I agree.  But I'd like to see some sort of functionality to
automatically handle some common topic branche cases in commit.
Of course I consider the current commit tool to already be too
complex (like being able to pull the commit message from any
random commit).

-- 
Shawn.

Re: [RFC] git commit --branch

[Martin Waitz]

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

hoi :)

On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:
> Now that diff+apply is probably faster than a 3 way merge in
> read-tree precisely because it doesn't need to run merge-recursive
> I'm starting to look at how we can use apply to do partial
> application of a patch and use RCS' diff3 or just drop a reject
> file out when a hunk doesn't apply cleanly.

but when applying patches, we have to be careful not to overwrite
any changes in the working tree which have not yet been committed.
With read-tree it should operate entirely in its temporary index without
touching the working tree.

> > But then an operation as important as commit has to be bullet-proof
> > and I don't like to do anything complex in there.
> 
> I agree.  But I'd like to see some sort of functionality to
> automatically handle some common topic branche cases in commit.
> Of course I consider the current commit tool to already be too
> complex (like being able to pull the commit message from any
> random commit).

And I really feel guilt for trying to add even more.
Is there some other way to add such a feature?

I have been dreaming of such a system for years now, and with GIT
it really feels feasible at last.
Graphics programs could compose an image out of different layers for
ages, now it is time for version control software to do the same :-)

-- 
Martin Waitz

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

Re: [RFC] git commit --branch

[Shawn Pearce]

Martin Waitz <tali@admingilde.org> wrote:
> hoi :)
> 
> On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:
> > Now that diff+apply is probably faster than a 3 way merge in
> > read-tree precisely because it doesn't need to run merge-recursive
> > I'm starting to look at how we can use apply to do partial
> > application of a patch and use RCS' diff3 or just drop a reject
> > file out when a hunk doesn't apply cleanly.
> 
> but when applying patches, we have to be careful not to overwrite
> any changes in the working tree which have not yet been committed.
> With read-tree it should operate entirely in its temporary index without
> touching the working tree.

Agreed.  But that's not always what you want.  There's two cases of
applying a patch:

	1) Apply this patch but only affect my working tree if everything
	is going to patch clean.  If anything goes wrong fail without
	touching anything.  git-apply already does this.

	2) I know that not all hunks in this patch will apply cleanly. So
	do the best you can by applying what you can and leave me the
	remainder for manual merging.  git-merge-recursive does this
	through RCS' diff3.

But I think I want #2 built into git-apply where it can handle
add/rename/delete cases without the expense of git-merge-recursive.
I also want it to apply what it can and leave me reject files _NOT_
a messy RCS style conflict in the file.  Some people just prefer
reject files.  I know someone has asked about this in the past as
Emacs has a good merge tool based on reject files.

But in the case of #2 we get a mess in our working directory and in
our index as the patch didn't go in cleanly.  That's OK.  I want
the unmerged stages in the index and I want the working directory
to contain the conflicts as I want to fix that all up before commit.

> > > But then an operation as important as commit has to be bullet-proof
> > > and I don't like to do anything complex in there.
> > 
> > I agree.  But I'd like to see some sort of functionality to
> > automatically handle some common topic branche cases in commit.
> > Of course I consider the current commit tool to already be too
> > complex (like being able to pull the commit message from any
> > random commit).
> 
> And I really feel guilt for trying to add even more.
> Is there some other way to add such a feature?

Not really.  Short of adding a new command which is a variant of
git-commit specialized for this type of work.  Which may be what I
wind up doing to get what I want.
 
> I have been dreaming of such a system for years now, and with GIT
> it really feels feasible at last.
> Graphics programs could compose an image out of different layers for
> ages, now it is time for version control software to do the same :-)

Heh.  Its not quite as simple as it is in an image editor.  But yes,
I agree.  Darcs can sort of do this I believe.  StGIT and pg both
attempt to do some basic operations but don't really get everything
right.

-- 
Shawn.

Re: [RFC] git commit --branch

[Johannes Schindelin]

Hi,

On Mon, 29 May 2006, Martin Waitz wrote:

> Sometimes it is neccessary to have some local modifications in the tree
> in order to test it and work with it.

Doesn't

$ git-update-index $(git-ls-files --modified)
$ git-checkout -b tempBranch
$ git-commit -m "to test"

work? It also avoids totally bogus parents (if I read your patch 
correctly, you take the current HEAD as the true parent, but record the 
current HEAD of the other branch as parent nevertheless).

Ciao,
Dscho

Re: [RFC] git commit --branch

[Jakub Narebski]

Johannes Schindelin wrote:

> On Mon, 29 May 2006, Martin Waitz wrote:
> 
>> Sometimes it is neccessary to have some local modifications in the tree
>> in order to test it and work with it.
> 
> Doesn't
> 
> $ git-update-index $(git-ls-files --modified)
> $ git-checkout -b tempBranch
> $ git-commit -m "to test"
> 
> work? 

Added to GitFaq page on GitWiki, under

  "How do I save some local modifications?"
  http://git.or.cz/gitwiki/GitFaq#saving-draft

-- 
Jakub Narebski
Warsaw, Poland

Re: [RFC] git commit --branch

[Martin Waitz]

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

hoi :)

On Mon, May 29, 2006 at 11:14:32PM +0200, Johannes Schindelin wrote:
> Doesn't
> 
> $ git-update-index $(git-ls-files --modified)
> $ git-checkout -b tempBranch
> $ git-commit -m "to test"
> 
> work? It also avoids totally bogus parents (if I read your patch 
> correctly, you take the current HEAD as the true parent, but record the 
> current HEAD of the other branch as parent nevertheless).

I'm doing two commits, one to HEAD and one to the other branch.
It is more like:

	git commit
	git checkout otherbranch
	git rebase --onto otherbranch master^ master   <-- first
	git checkout master
	git merge msg master otherbranch               <-- second

Now your current HEAD is still a merge of your topic branches,
and you commited your changes to one clean topic branch.

-- 
Martin Waitz

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

Re: [RFC] git commit --branch

[Johannes Schindelin]

Hi,

On Mon, 29 May 2006, Martin Waitz wrote:

> I'm doing two commits, one to HEAD and one to the other branch.
> It is more like:
> 
> 	git commit
> 	git checkout otherbranch
> 	git rebase --onto otherbranch master^ master   <-- first
> 	git checkout master
> 	git merge msg master otherbranch               <-- second

Wouldn't this merit a different option name, such as "--also-onto" instead 
of "--branch"?

Ciao,
Dscho

Re: [RFC] git commit --branch

[Junio C Hamano]

Martin Waitz <tali@admingilde.org> 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).

Re: [RFC] git commit --branch

[Martin Waitz]

[-- 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 --]

Re: [RFC] git commit --branch

[Junio C Hamano]

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. 

Re: [RFC] git commit --branch

[Martin Waitz]

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

hoi :)

On Tue, May 30, 2006 at 03:52:21PM -0700, Junio C Hamano wrote:
> 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.

So perhaps my real problem was that I did not know about checkout -m.
Your description of the workflow is of course much saver then
automatically committing to an other branch.

-- 
Martin Waitz

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

Re: [RFC] git commit --branch

[Jon Loeliger]

On Tue, 2006-05-30 at 17:52, Junio C Hamano wrote:
> 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.

We all do. :-)

BTW, did you (anyone?) see my patch to help the local
configuration issue some?  It basically separates out the
config bits into a separate hash table in a separate file that
can be updated quite independently without even modifying
the original gitweb.cgi.  That allows the gitweb.cgi 
proper to be slammed down and updated much more readily.

    http://marc.theaimsgroup.com/?l=git&m=114308224922372&w=2

jdl