threads / rfc / 4344

[RFC] git commit --branch

Subject: [RFC] git commit --branch

## tl;dr

15 messages between May 29, 2006 and Jun 5, 2006.

replies: 14people: 6as markdown or json

Martin Waitz· May 29, 2006, 20:28 UTC · lore
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
Shawn Pearce· May 29, 2006, 20:41 UTC · re: Martin Waitz · lore

Re: [RFC] git commit --branch

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.
Martin Waitz· May 29, 2006, 21:22 UTC · re: Shawn Pearce · lore

Re: [RFC] git commit --branch

hoi :)
On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:
Show 8 quoted lines
> 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 :)

Show 6 quoted lines
> > +		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
Shawn Pearce· May 29, 2006, 21:35 UTC · re: Martin Waitz · lore

Re: [RFC] git commit --branch

Martin Waitz <tali@admingilde.org> wrote:
Show 12 quoted lines
> 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.
Martin Waitz· May 29, 2006, 21:55 UTC · re: Shawn Pearce · lore

Re: [RFC] git commit --branch

hoi :)
On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:
Show 5 quoted lines
> 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.

Show 8 quoted lines
> > 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
Shawn Pearce· May 29, 2006, 22:16 UTC · re: Martin Waitz · lore

Re: [RFC] git commit --branch

Martin Waitz <tali@admingilde.org> wrote:
Show 13 quoted lines
> 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.

Show 11 quoted lines
> > > 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.
Johannes Schindelin· May 29, 2006, 21:14 UTC · re: Martin Waitz · lore

Re: [RFC] git commit --branch

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

Jakub Narebski· May 29, 2006, 21:27 UTC · re: Johannes Schindelin · lore

Re: [RFC] git commit --branch

Johannes Schindelin wrote:
Show 12 quoted lines
> 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
Martin Waitz· May 29, 2006, 21:37 UTC · re: Johannes Schindelin · lore

Re: [RFC] git commit --branch

hoi :)
On Mon, May 29, 2006 at 11:14:32PM +0200, Johannes Schindelin wrote:
Show 9 quoted lines
> 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
Johannes Schindelin· May 29, 2006, 21:58 UTC · re: Martin Waitz · lore

Re: [RFC] git commit --branch

Hi,
On Mon, 29 May 2006, Martin Waitz wrote:
Show 8 quoted lines
> 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

Junio C Hamano· May 30, 2006, 09:12 UTC · re: Martin Waitz · lore

Re: [RFC] git commit --branch

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).
Martin Waitz· May 30, 2006, 21:05 UTC · re: Junio C Hamano · lore

Re: [RFC] git commit --branch

hoi :)
On Tue, May 30, 2006 at 02:12:02AM -0700, Junio C Hamano wrote:
Show 17 quoted lines
> 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.

Show 10 quoted lines
> 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.

Show 10 quoted lines
> 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
Junio C Hamano· May 30, 2006, 22:52 UTC · re: Martin Waitz · lore

Re: [RFC] git commit --branch

Martin Waitz <tali@admingilde.org> writes:
Show 5 quoted lines
>> 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.

Show 6 quoted lines
>> 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.

Show 12 quoted lines
>> 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.

Show 13 quoted lines
>> 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.

Martin Waitz· May 31, 2006, 15:21 UTC · re: Junio C Hamano · lore

Re: [RFC] git commit --branch

hoi :)
On Tue, May 30, 2006 at 03:52:21PM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> 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
Jon Loeliger· Jun 5, 2006, 18:22 UTC · re: Junio C Hamano · lore

Re: [RFC] git commit --branch

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

← back to recent threads