{"thread":{"id":"4344","subject":"[RFC] git commit --branch","startedAt":"2006-05-29T20:28:55Z","lastAt":"2006-06-05T18:22:15Z","messageCount":15,"participants":["Martin Waitz","Shawn Pearce","Johannes Schindelin","Jakub Narebski","Junio C Hamano","Jon Loeliger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20910","messageId":"20060529202851.GE14325@admingilde.org","threadId":"4344","inReplyTo":null,"subject":"[RFC] git commit --branch","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-29T20:28:55Z","receivedAt":"2006-05-29T20:28:55Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"Allow to commit to another branch and creating a merge in the current branch.\n\nSometimes it is neccessary to have some local modifications in the tree\nin order to test it and work with it.  With this patch you can have\none working tree which combines several topic branches in order to\ndevelop and test your changes.  When your changes are ready, you can\ncommit them to the appropriate topic branch.\n\nWith the --branch option, the commit will automatically be rebased to\nthat branch.  The original tree will then be commited to your working\nbranch as a merge.\n\n---\n\nPerhaps something like this can even be integrated into the extended\nbranch configuration which is currently under discussion.\nIt may make sense to have one branch which always contains a merge\nof a selected set of other branches and having a default branch\nfor new commits.\n\n Documentation/git-commit.txt        |    6 +++\n git-commit.sh                       |   62 ++++++++++++++++++++++++++++++++++-\n t/t3800-commit-onto-other-branch.sh |   32 ++++++++++++++++++\n 3 files changed, 99 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 38df59c..8111ba4 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -49,6 +49,12 @@ OPTIONS\n \tOverride the author name used in the commit.  Use\n \t`A U Thor <author@example.com>` format.\n \n+--branch <branch>::\n+\tActually commit the changes to another branch.\n+\tAfterwards it will be merged into the current branch.\n+\tThis is useful if you work on a branch with local modifications\n+\tbut want to keep one clean branch without those.\n+\n -m <msg>::\n \tUse the given <msg> as the commit message.\n \ndiff --git a/git-commit.sh b/git-commit.sh\nindex 1983d45..9ed0050 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -3,7 +3,7 @@ #\n # Copyright (c) 2005 Linus Torvalds\n # Copyright (c) 2006 Junio C Hamano\n \n-USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [[-i | -o] <path>...]'\n+USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [--branch <branch>] [[-i | -o] <path>...]'\n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n \n@@ -245,6 +245,12 @@ do\n       force_author=\"$1\"\n       shift\n       ;;\n+  -b|--b|--br|--bra|--bran|--branc|--branch)\n+      case \"$#\" in 1) usage ;; esac\n+      shift\n+      onto_branch=\"$1\"\n+      shift\n+      ;;\n   -e|--e|--ed|--edi|--edit)\n       no_edit=\n       shift\n@@ -405,6 +411,7 @@ t,,[1-9]*)\n \tdie \"No paths with -i does not make sense.\" ;;\n esac\n \n+\n ################################################################\n # Prepare index to have a tree to be committed\n \n@@ -623,6 +630,32 @@ else\n \tcurrent=\n fi\n \n+if test -n \"$onto_branch\"\n+then\n+\tonto_branch_commit=$(git-rev-parse --verify \"$onto_branch\") ||\n+\t\tdie \"Branch $onto_branch does not exist.\"\n+\ttest $(git merge-base \"$onto_branch\" HEAD) = $onto_branch_commit ||\n+\t\tdie \"Branch \"$onto_branch\" already contains unmerged commits.\"\n+\tcase \"$PARENTS\" in\n+\t-p*-p*)\tdie \"Cannot commit a merge to another branch.\" ;;\n+\tesac\n+\tif test $(git-rev-parse --verify HEAD) = $onto_branch_commit\n+\tthen\n+\t\t# no merge neccessary, branches identically\n+\t\tforward_onto_branch=\"$onto_branch\"\n+\t\tonto_branch=\"\"\n+\tfi\n+\tif test \"$amend\" = t\n+\tthen\n+\t\t# test that the tip of HEAD really came from the tip of\n+\t\t# $onto_branch and that we can amend both of them\n+\t\ttest $(git merge-base \"$onto_branch\" HEAD^) != $onto_branch_commit &&\n+\t\ttest $(git merge-base \"$onto_branch\"^ HEAD^) = $(git rev-parse --verify \"$onto_branch\"^) ||\n+\t\t\tdie \"commits on $onto_branch and HEAD differ, cannot amend.\"\n+\t\tonto_branch_commit=$(git rev-parse --verify \"$onto_branch\"^)\n+\tfi\n+fi\n+\n if test -z \"$no_edit\"\n then\n \t{\n@@ -689,8 +722,35 @@ then\n \t\ttree=$(GIT_INDEX_FILE=\"$TMP_INDEX\" git-write-tree) &&\n \t\trm -f \"$TMP_INDEX\"\n \tfi &&\n+\tif test -n \"$onto_branch\"\n+\tthen\n+\t\t# create temporary index\n+\t\tONTO_INDEX=\"$GIT_DIR/onto-index\"\n+\t\tcp \"$USE_INDEX\" \"$ONTO_INDEX\" &&\n+\t\tGIT_INDEX_FILE=\"$ONTO_INDEX\" \\\n+\t\tgit-read-tree -i -m \"$onto_branch_commit\"\n+\t\t# merge new changes into the branch\n+\t\tGIT_INDEX_FILE=\"$ONTO_INDEX\" \\\n+\t\tgit-read-tree -i --aggressive -m \\\n+\t\t\tHEAD \"$onto_branch_commit\" \"$tree\" &&\n+\t\tGIT_INDEX_FILE=\"$ONTO_INDEX\" \\\n+\t\tgit-merge-index git-merge-one-file -a || {\n+\t\t\techo >&2 \"Cannot rebase your commit to $onto_branch.\"\n+\t\t\techo >&2 \"Please merge and commit manually.\"\n+\t\t\tfalse\n+\t\t} &&\n+\t\ttree2=$(GIT_INDEX_FILE=\"$ONTO_INDEX\" git-write-tree) &&\n+\t\tcommit2=$(cat \"$GIT_DIR\"/COMMIT_MSG | git-commit-tree $tree2 -p $onto_branch_commit) &&\n+\t\tgit update-ref \"$onto_branch\" $commit2 &&\n+\t\trm -f \"$ONTO_INDEX\" &&\n+\t\tPARENTS=\"$PARENTS -p $commit2\"\n+\tfi &&\n \tcommit=$(cat \"$GIT_DIR\"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&\n \tgit-update-ref HEAD $commit $current &&\n+\tif test -n \"$forward_onto_branch\"\n+\tthen\n+\t\tgit-update-ref \"$forward_onto_branch\" $commit $current\n+\tfi &&\n \trm -f -- \"$GIT_DIR/MERGE_HEAD\" &&\n \tif test -f \"$NEXT_INDEX\"\n \tthen\ndiff --git a/t/t3800-commit-onto-other-branch.sh b/t/t3800-commit-onto-other-branch.sh\nnew file mode 100755\nindex 0000000..f4f6410\n--- /dev/null\n+++ b/t/t3800-commit-onto-other-branch.sh\n@@ -0,0 +1,32 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2006 Martin Waitz\n+#\n+\n+test_description='Test a commit to another branch'\n+\n+. ./test-lib.sh\n+\n+echo AAA > A\n+echo BBB > B\n+\n+test_expect_success 'Initial commit' \\\n+'git add A B &&\n+ git commit -m \"Initial commit\" &&\n+ git branch topic'\n+\n+test_expect_success 'Modify HEAD' \\\n+'echo A2 > A &&\n+ git commit -m \"modify A\" A'\n+\n+test_expect_success 'Commit to branch' \\\n+'echo B2 > B &&\n+ git commit -m \"modify B\" --branch topic B'\n+\n+# now test that HEAD and topic only differs in A\n+test_expect_success 'Verify trees' \\\n+'echo \":100644 100644 43d5a8e... 3ce238a... M\tA\" > expected &&\n+ git diff-tree --abbrev topic HEAD > current &&\n+ diff expected current'\n+\n+test_done\n-- \n1.3.3.ged90\n\n\n-- \nMartin Waitz\n"},{"id":"20911","messageId":"20060529204158.GC28538@spearce.org","threadId":"4344","inReplyTo":"20060529202851.GE14325@admingilde.org","subject":"Re: [RFC] git commit --branch","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-29T20:41:58Z","receivedAt":"2006-05-29T20:41:58Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Martin Waitz <tali@admingilde.org> wrote:\n> Allow to commit to another branch and creating a merge in the current branch.\n\nInteresting.  I have been kicking around doing the very same\nthing myself but just have not gotten around to it.  Its complex,\nespecially if the current HEAD isn't strictly the merge commit\nbetween the topic branch and the previous value of HEAD; in that\ncase you may want to replay the commits which are on HEAD but are\npost the merge commit using a form of git-rebase.  Except you would\nwant to preserve any merges which happened by remerging them rather\nthan simply exporting a massive patch and reapplying it.\n \n> +\t\ttest $(git merge-base \"$onto_branch\" HEAD^) != $onto_branch_commit &&\n> +\t\ttest $(git merge-base \"$onto_branch\"^ HEAD^) = $(git rev-parse --verify \"$onto_branch\"^) ||\n> +\t\t\tdie \"commits on $onto_branch and HEAD differ, cannot amend.\"\n> +\t\tonto_branch_commit=$(git rev-parse --verify \"$onto_branch\"^)\n\nShouldn't these be 'git-merge-base' and 'git-rev-parse' ?\n\n> +\t\tgit update-ref \"$onto_branch\" $commit2 &&\n\nIf this is going into next perhaps you would like to considering adding\nthe -m flag to your git-update-ref calls and include a log message\nin the reflog (if the user has it enabled for the current branch and\nthe topic branch)?\n\nAlso shouldn't this be 'git-update-ref'?\n\n-- \nShawn.\n"},{"id":"20915","messageId":"Pine.LNX.4.63.0605292310280.17412@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4344","inReplyTo":"20060529202851.GE14325@admingilde.org","subject":"Re: [RFC] git commit --branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-29T21:14:32Z","receivedAt":"2006-05-29T21:14:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 29 May 2006, Martin Waitz wrote:\n\n> Sometimes it is neccessary to have some local modifications in the tree\n> in order to test it and work with it.\n\nDoesn't\n\n$ git-update-index $(git-ls-files --modified)\n$ git-checkout -b tempBranch\n$ git-commit -m \"to test\"\n\nwork? It also avoids totally bogus parents (if I read your patch \ncorrectly, you take the current HEAD as the true parent, but record the \ncurrent HEAD of the other branch as parent nevertheless).\n\nCiao,\nDscho\n"},{"id":"20916","messageId":"20060529212249.GF14325@admingilde.org","threadId":"4344","inReplyTo":"20060529204158.GC28538@spearce.org","subject":"Re: [RFC] git commit --branch","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-29T21:22:50Z","receivedAt":"2006-05-29T21:22:50Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:\n> Interesting.  I have been kicking around doing the very same\n> thing myself but just have not gotten around to it.  Its complex,\n> especially if the current HEAD isn't strictly the merge commit\n> between the topic branch and the previous value of HEAD; in that\n> case you may want to replay the commits which are on HEAD but are\n> post the merge commit using a form of git-rebase.  Except you would\n> want to preserve any merges which happened by remerging them rather\n> than simply exporting a massive patch and reapplying it.\n\nPerhaps something like merge-recursive makes sense, except that\nI have no clue how it works ;-)\n\nBut then an operation as important as commit has to be bullet-proof\nand I don't like to do anything complex in there.\n\nIn any case, this functionality needs a lot of testing.\nAny contributions to the test case are welcome :)\n\n> > +\t\tgit update-ref \"$onto_branch\" $commit2 &&\n> \n> If this is going into next perhaps you would like to considering adding\n> the -m flag to your git-update-ref calls and include a log message\n> in the reflog (if the user has it enabled for the current branch and\n> the topic branch)?\n\nMakes sense.\n\n> Also shouldn't this be 'git-update-ref'?\n\nYes, all the rest uses git-*, too.\nIf the move to buildin commands continues at the same speed we\nmay soon be able to remove some \"-\"s, but it's not time for that yet.\n\n-- \nMartin Waitz\n"},{"id":"20918","messageId":"e5fovc$vqf$1@sea.gmane.org","threadId":"4344","inReplyTo":"Pine.LNX.4.63.0605292310280.17412@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] git commit --branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-05-29T21:27:04Z","receivedAt":"2006-05-29T21:27:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> On Mon, 29 May 2006, Martin Waitz wrote:\n> \n>> Sometimes it is neccessary to have some local modifications in the tree\n>> in order to test it and work with it.\n> \n> Doesn't\n> \n> $ git-update-index $(git-ls-files --modified)\n> $ git-checkout -b tempBranch\n> $ git-commit -m \"to test\"\n> \n> work? \n\nAdded to GitFaq page on GitWiki, under\n\n  \"How do I save some local modifications?\"\n  http://git.or.cz/gitwiki/GitFaq#saving-draft\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"20919","messageId":"20060529213543.GA29054@spearce.org","threadId":"4344","inReplyTo":"20060529212249.GF14325@admingilde.org","subject":"Re: [RFC] git commit --branch","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-29T21:35:43Z","receivedAt":"2006-05-29T21:35:43Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Martin Waitz <tali@admingilde.org> wrote:\n> On Mon, May 29, 2006 at 04:41:58PM -0400, Shawn Pearce wrote:\n> > Interesting.  I have been kicking around doing the very same\n> > thing myself but just have not gotten around to it.  Its complex,\n> > especially if the current HEAD isn't strictly the merge commit\n> > between the topic branch and the previous value of HEAD; in that\n> > case you may want to replay the commits which are on HEAD but are\n> > post the merge commit using a form of git-rebase.  Except you would\n> > want to preserve any merges which happened by remerging them rather\n> > than simply exporting a massive patch and reapplying it.\n> \n> Perhaps something like merge-recursive makes sense, except that\n> I have no clue how it works ;-)\n\nmerge-recursive isn't the right tool here. Its job is to perform a\n3 way merge \"quickly\" by dealing with file adds, deletes, renames\nand patch application when a file was modified by both parents.\n\nNow that diff+apply is probably faster than a 3 way merge in\nread-tree precisely because it doesn't need to run merge-recursive\nI'm starting to look at how we can use apply to do partial\napplication of a patch and use RCS' diff3 or just drop a reject\nfile out when a hunk doesn't apply cleanly.\n \n> But then an operation as important as commit has to be bullet-proof\n> and I don't like to do anything complex in there.\n\nI agree.  But I'd like to see some sort of functionality to\nautomatically handle some common topic branche cases in commit.\nOf course I consider the current commit tool to already be too\ncomplex (like being able to pull the commit message from any\nrandom commit).\n\n-- \nShawn.\n"},{"id":"20920","messageId":"20060529213704.GG14325@admingilde.org","threadId":"4344","inReplyTo":"Pine.LNX.4.63.0605292310280.17412@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] git commit --branch","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-29T21:37:04Z","receivedAt":"2006-05-29T21:37:04Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, May 29, 2006 at 11:14:32PM +0200, Johannes Schindelin wrote:\n> Doesn't\n> \n> $ git-update-index $(git-ls-files --modified)\n> $ git-checkout -b tempBranch\n> $ git-commit -m \"to test\"\n> \n> work? It also avoids totally bogus parents (if I read your patch \n> correctly, you take the current HEAD as the true parent, but record the \n> current HEAD of the other branch as parent nevertheless).\n\nI'm doing two commits, one to HEAD and one to the other branch.\nIt is more like:\n\n\tgit commit\n\tgit checkout otherbranch\n\tgit rebase --onto otherbranch master^ master   <-- first\n\tgit checkout master\n\tgit merge msg master otherbranch               <-- second\n\nNow your current HEAD is still a merge of your topic branches,\nand you commited your changes to one clean topic branch.\n\n-- \nMartin Waitz\n"},{"id":"20923","messageId":"20060529215537.GH14325@admingilde.org","threadId":"4344","inReplyTo":"20060529213543.GA29054@spearce.org","subject":"Re: [RFC] git commit --branch","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-29T21:55:37Z","receivedAt":"2006-05-29T21:55:37Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:\n> Now that diff+apply is probably faster than a 3 way merge in\n> read-tree precisely because it doesn't need to run merge-recursive\n> I'm starting to look at how we can use apply to do partial\n> application of a patch and use RCS' diff3 or just drop a reject\n> file out when a hunk doesn't apply cleanly.\n\nbut when applying patches, we have to be careful not to overwrite\nany changes in the working tree which have not yet been committed.\nWith read-tree it should operate entirely in its temporary index without\ntouching the working tree.\n\n> > But then an operation as important as commit has to be bullet-proof\n> > and I don't like to do anything complex in there.\n> \n> I agree.  But I'd like to see some sort of functionality to\n> automatically handle some common topic branche cases in commit.\n> Of course I consider the current commit tool to already be too\n> complex (like being able to pull the commit message from any\n> random commit).\n\nAnd I really feel guilt for trying to add even more.\nIs there some other way to add such a feature?\n\nI have been dreaming of such a system for years now, and with GIT\nit really feels feasible at last.\nGraphics programs could compose an image out of different layers for\nages, now it is time for version control software to do the same :-)\n\n-- \nMartin Waitz\n"},{"id":"20924","messageId":"Pine.LNX.4.63.0605292357260.18328@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4344","inReplyTo":"20060529213704.GG14325@admingilde.org","subject":"Re: [RFC] git commit --branch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-05-29T21:58:10Z","receivedAt":"2006-05-29T21:58:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 29 May 2006, Martin Waitz wrote:\n\n> I'm doing two commits, one to HEAD and one to the other branch.\n> It is more like:\n> \n> \tgit commit\n> \tgit checkout otherbranch\n> \tgit rebase --onto otherbranch master^ master   <-- first\n> \tgit checkout master\n> \tgit merge msg master otherbranch               <-- second\n\nWouldn't this merit a different option name, such as \"--also-onto\" instead \nof \"--branch\"?\n\nCiao,\nDscho\n"},{"id":"20928","messageId":"20060529221629.GB29054@spearce.org","threadId":"4344","inReplyTo":"20060529215537.GH14325@admingilde.org","subject":"Re: [RFC] git commit --branch","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-05-29T22:16:29Z","receivedAt":"2006-05-29T22:16:29Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Martin Waitz <tali@admingilde.org> wrote:\n> hoi :)\n> \n> On Mon, May 29, 2006 at 05:35:43PM -0400, Shawn Pearce wrote:\n> > Now that diff+apply is probably faster than a 3 way merge in\n> > read-tree precisely because it doesn't need to run merge-recursive\n> > I'm starting to look at how we can use apply to do partial\n> > application of a patch and use RCS' diff3 or just drop a reject\n> > file out when a hunk doesn't apply cleanly.\n> \n> but when applying patches, we have to be careful not to overwrite\n> any changes in the working tree which have not yet been committed.\n> With read-tree it should operate entirely in its temporary index without\n> touching the working tree.\n\nAgreed.  But that's not always what you want.  There's two cases of\napplying a patch:\n\n\t1) Apply this patch but only affect my working tree if everything\n\tis going to patch clean.  If anything goes wrong fail without\n\ttouching anything.  git-apply already does this.\n\n\t2) I know that not all hunks in this patch will apply cleanly. So\n\tdo the best you can by applying what you can and leave me the\n\tremainder for manual merging.  git-merge-recursive does this\n\tthrough RCS' diff3.\n\nBut I think I want #2 built into git-apply where it can handle\nadd/rename/delete cases without the expense of git-merge-recursive.\nI also want it to apply what it can and leave me reject files _NOT_\na messy RCS style conflict in the file.  Some people just prefer\nreject files.  I know someone has asked about this in the past as\nEmacs has a good merge tool based on reject files.\n\nBut in the case of #2 we get a mess in our working directory and in\nour index as the patch didn't go in cleanly.  That's OK.  I want\nthe unmerged stages in the index and I want the working directory\nto contain the conflicts as I want to fix that all up before commit.\n\n> > > But then an operation as important as commit has to be bullet-proof\n> > > and I don't like to do anything complex in there.\n> > \n> > I agree.  But I'd like to see some sort of functionality to\n> > automatically handle some common topic branche cases in commit.\n> > Of course I consider the current commit tool to already be too\n> > complex (like being able to pull the commit message from any\n> > random commit).\n> \n> And I really feel guilt for trying to add even more.\n> Is there some other way to add such a feature?\n\nNot really.  Short of adding a new command which is a variant of\ngit-commit specialized for this type of work.  Which may be what I\nwind up doing to get what I want.\n \n> I have been dreaming of such a system for years now, and with GIT\n> it really feels feasible at last.\n> Graphics programs could compose an image out of different layers for\n> ages, now it is time for version control software to do the same :-)\n\nHeh.  Its not quite as simple as it is in an image editor.  But yes,\nI agree.  Darcs can sort of do this I believe.  StGIT and pg both\nattempt to do some basic operations but don't really get everything\nright.\n\n-- \nShawn.\n"},{"id":"20967","messageId":"7vr72b27x9.fsf@assigned-by-dhcp.cox.net","threadId":"4344","inReplyTo":"20060529202851.GE14325@admingilde.org","subject":"Re: [RFC] git commit --branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-30T09:12:02Z","receivedAt":"2006-05-30T09:12:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Waitz <tali@admingilde.org> writes:\n\n> Allow to commit to another branch and creating a merge in the current branch.\n>\n> Sometimes it is neccessary to have some local modifications in the tree\n> in order to test it and work with it.  With this patch you can have\n> one working tree which combines several topic branches in order to\n> develop and test your changes.  When your changes are ready, you can\n> commit them to the appropriate topic branch.\n>\n> With the --branch option, the commit will automatically be rebased to\n> that branch.  The original tree will then be commited to your working\n> branch as a merge.\n>\n> ---\n>\n> Perhaps something like this can even be integrated into the extended\n> branch configuration which is currently under discussion.\n> It may make sense to have one branch which always contains a merge\n> of a selected set of other branches and having a default branch\n> for new commits.\n\nI think this was discussed in the past and I appreciate what you\nare trying to do.  My understanding of the situation your patch\nis trying to improve is this:\n\n - you have done a few topics and you are ready to test;\n\n - you pulled the topics into your test branch and have found\n   problems;\n\n - you made changes while still on the test branch (otherwise\n   you wouldn't be able to test the \"fix\") and it seems to work\n   OK;\n\n - what now?  \n\nAnd your approach is to backport the fix to its original topic\nand then re-pull the topic onto the test branch.\n\nWhile I think that is _one_ valid workflow, I am not convinced\nthat is _the_ best workflow.  What Johannes suggested would\nequally work fine, and honestly speaking probably is a better\ndiscipline.  You carry the fix in your working tree back to its\noriginal topic and make a commit, without pulling the topic onto\nthe test branch immediately.  This has two advantages:\n\n - With your workflow, you will have a merge commit onto the\n   testing branch immediately when you commit this fix to the\n   original topic.  But often when I encounter this situation,\n   after moving to the topic to backport the fix to it, I find\n   myself reviewing what is in the topic and making other\n   changes to the topic.  Johannes's workflow feels more natural\n   to me from this aspect -- I take the fix I discovered while\n   on the testing branch to the relevant topic to fix it.  I may\n   or may not make the commit only with that fix (the first\n   commit I make after switching the branches from testing to\n   the topic may contain more than that fix), and after I make\n   one commit, I may keep working on the topic a bit more before\n   I decide it is a good time to test the whole thing again (to\n   pull the topic into testing).  I do not necessarily want that\n   extra merge immediately in the test branch.\n\n - A topic branch should be testable alone; if the changes near\n   the tip of your topic depends on other topic (or more recent\n   mainline than where the topic forked), then I think you\n   shouldn't hesitate to pull in the other branch into the topic\n   to keep it buildable and testable.  And your commit should be\n   made after testing your changes; with your workflow, you have\n   only tested the change in the context of the testing branch,\n   not the topic branch your \"primary\" commit is on, even though\n   that commit will be the source of eventual graduation to the\n   mainline.  With Johannes's workflow, you first carry the\n   change to the topic, so you have a chance to test it before\n   making the commit (if you are not disciplined, you can make\n   the commit without testing after switching branches, but the\n   point is it gives people an option to test things before they\n   make a commit if they wanted to).\n"},{"id":"20985","messageId":"20060530210551.GI14325@admingilde.org","threadId":"4344","inReplyTo":"7vr72b27x9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git commit --branch","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-30T21:05:52Z","receivedAt":"2006-05-30T21:05:52Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Tue, May 30, 2006 at 02:12:02AM -0700, Junio C Hamano wrote:\n> I think this was discussed in the past and I appreciate what you\n> are trying to do.  My understanding of the situation your patch\n> is trying to improve is this:\n> \n>  - you have done a few topics and you are ready to test;\n> \n>  - you pulled the topics into your test branch and have found\n>    problems;\n> \n>  - you made changes while still on the test branch (otherwise\n>    you wouldn't be able to test the \"fix\") and it seems to work\n>    OK;\n> \n>  - what now?  \n> \n> And your approach is to backport the fix to its original topic\n> and then re-pull the topic onto the test branch.\n\nyes. I was doing this after working on gitweb a bit.\nIn order to test gitweb, I need some local adaptations.\nI commited these to one branch and put all improvements to\nanother branch.  Then I merged both branches to one production\npath which is then used by the webserver.\n\n> While I think that is _one_ valid workflow, I am not convinced\n> that is _the_ best workflow.\n\nMe neigther.\nThat's why I labeled it RFC and published it before doing too much\ntesting and polishing ;-)\n\n> What Johannes suggested would\n> equally work fine, and honestly speaking probably is a better\n> discipline.\n\nHe suggested to create a new branch (based on current HEAD) for the\nnew commit.  Unfortunately that doesn't solve my problem.\n\n> You carry the fix in your working tree back to its\n> original topic and make a commit, without pulling the topic onto\n> the test branch immediately.  This has two advantages:\n> \n>  - With your workflow, you will have a merge commit onto the\n>    testing branch immediately when you commit this fix to the\n>    original topic.  But often when I encounter this situation,\n>    after moving to the topic to backport the fix to it, I find\n>    myself reviewing what is in the topic and making other\n>    changes to the topic.\n\nOf course you can do this also while you are still on the test branch.\n\nWhile looking at code I often see unrelated stuff which can be cleaned\nup.  With something like commit --branch it would be possible to stuff\nthese changes to a \"trivial\" branch without having to change branches\nexplicitly.\n\n> Johannes's workflow feels more natural\n>    to me from this aspect -- I take the fix I discovered while\n>    on the testing branch to the relevant topic to fix it.  I may\n>    or may not make the commit only with that fix (the first\n>    commit I make after switching the branches from testing to\n>    the topic may contain more than that fix), and after I make\n>    one commit, I may keep working on the topic a bit more before\n>    I decide it is a good time to test the whole thing again (to\n>    pull the topic into testing).  I do not necessarily want that\n>    extra merge immediately in the test branch.\n\nBut if your commit to the topic is really different to previous\ncommit on the test branch then you may have merge problems later.\nIf you merge immediately, you even get the merged tree for free ;-).\nThe testing branch is more like a throwaway-branch for me.\nI can recreate it anytime if I want and I don't care about extra\nmerge commits here.\n\n>  - A topic branch should be testable alone;\n\nThat would be best, yes.\nUnfortunately it didn't work for me.\nWell I guess I could have put more effort on changing gitweb to\nbe more general so that I don't need local adaptations.\nBut I guess there are situations where this is not possible, too.\nOf course, now we have to answer the question whether GIT should\nsupport these situations.  I don't know.\n\n-- \nMartin Waitz\n"},{"id":"20989","messageId":"7vd5dvyvkq.fsf@assigned-by-dhcp.cox.net","threadId":"4344","inReplyTo":"20060530210551.GI14325@admingilde.org","subject":"Re: [RFC] git commit --branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-05-30T22:52:21Z","receivedAt":"2006-05-30T22:52:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Waitz <tali@admingilde.org> writes:\n\n>> And your approach is to backport the fix to its original topic\n>> and then re-pull the topic onto the test branch.\n>\n> yes. I was doing this after working on gitweb a bit.\n> In order to test gitweb, I need some local adaptations.\n\nFunny you mention this.  I had exactly the same arrangement for\nhacking on gitweb.  One \"localconf\" branch to tell it where the\nrepositories are, \"origin\" to track upstream, \"master\" to use\nfor deployment, and other topic branches.  I used git-fetch to\nkeep updating \"origin\" (not git-pull), grew and rebased topics\nbased on \"origin\".  \"master\" was rebuilt from \"origin\" by\nmerging \"localconf\" and topics.  Some of the stuff I did in my\ntopics involved changing the way local configuration is done, so\nI had an extra topic \"newconf\" which branched from \"localconf\"\nbut merged from the topic branch.\n\n>> What Johannes suggested would\n>> equally work fine, and honestly speaking probably is a better\n>> discipline.\n>\n> He suggested to create a new branch (based on current HEAD) for the\n> new commit.  Unfortunately that doesn't solve my problem.\n\nWhen I re-read his suggestion, literally he talks about creating\na new topic, but I assumed he just meant \"you could _even_\ncreate a new branch if you wanted to\" -- you can switch to\nanother existing topic branch do with \"git checkout\", perhaps\nwith the -m flag.  While I was on the \"master\" to figure out why\ngitweb was not behaving for me, and figured out a mis-\nconfiguration that should be fixed in \"newconf\" topic, I\nswitched to that topic and committed the fix there, after\ntesting the change there.  Then either merging it back to\n\"master\" or rebuilding \"master\" from scratch based on \"origin\"\nand merging my topics got me a working gitweb back.\n\n>> You carry the fix in your working tree back to its\n>> original topic and make a commit, without pulling the topic onto\n>> the test branch immediately.  This has two advantages:\n>> \n>>  - With your workflow, you will have a merge commit onto the\n>>    testing branch immediately when you commit this fix to the\n>>    original topic.  But often when I encounter this situation,\n>>    after moving to the topic to backport the fix to it, I find\n>>    myself reviewing what is in the topic and making other\n>>    changes to the topic.\n>\n> Of course you can do this also while you are still on the test branch.\n\nThat is something you cannot.  The merged test branch contains\nother unrelated changes.  As you describe, the test branch in\nyour (and mine) workflow is throw-away in nature, so a proper\nfix should go to the relevant topic, and while working on a\nsingle topic, I do not want to see what other topics introduced\nto the file -- I may accidentally depend on them, creating\nunnecessary interdependencies between topics.\n\n> While looking at code I often see unrelated stuff which can be cleaned\n> up.  With something like commit --branch it would be possible to stuff\n> these changes to a \"trivial\" branch without having to change branches\n> explicitly.\n\nI often find myself spending too much time fixing what I\ncommitted without thinking and testing -- assuming something is\n\"trivial\" which turns out to be not so -- so I try to stay away\nfrom the idea of having a \"trivial\" branch.  But if you want to\ndo things that way, you could trivially do so by having a\nwrapper around git commit.  By building something into\ngit-commit command, you are actively encouraging one workflow,\nand commit without testing is one thing I do not particularly\nwant to encourage people to do.  We have selective commit with\n\"git commit [-i] <paths>...\" which is already bad enough.\n\n>> Johannes's workflow feels more natural\n>>    to me from this aspect -- I take the fix I discovered while\n>>    on the testing branch to the relevant topic to fix it.  I may\n>>    or may not make the commit only with that fix (the first\n>>    commit I make after switching the branches from testing to\n>>    the topic may contain more than that fix), and after I make\n>>    one commit, I may keep working on the topic a bit more before\n>>    I decide it is a good time to test the whole thing again (to\n>>    pull the topic into testing).  I do not necessarily want that\n>>    extra merge immediately in the test branch.\n>\n> But if your commit to the topic is really different to previous\n> commit on the test branch then you may have merge problems later.\n\nI am not sure what you want to say here.  You realize some\nbreakage, do initial/preliminary fix while on the test branch,\ntake the change to the relevant topic branch to do the real\nfix.  You can merge the result back to the test branch when your\nchanges on the topic is ready.  I do not see where conflicting\nchange makes a difference. \n"},{"id":"21009","messageId":"20060531152129.GJ14325@admingilde.org","threadId":"4344","inReplyTo":"7vd5dvyvkq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git commit --branch","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2006-05-31T15:21:29Z","receivedAt":"2006-05-31T15:21:29Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Tue, May 30, 2006 at 03:52:21PM -0700, Junio C Hamano wrote:\n> you can switch to another existing topic branch do with \"git\n> checkout\", perhaps with the -m flag.  While I was on the \"master\" to\n> figure out why gitweb was not behaving for me, and figured out a mis-\n> configuration that should be fixed in \"newconf\" topic, I switched to\n> that topic and committed the fix there, after testing the change\n> there.  Then either merging it back to \"master\" or rebuilding \"master\"\n> from scratch based on \"origin\" and merging my topics got me a working\n> gitweb back.\n\nSo perhaps my real problem was that I did not know about checkout -m.\nYour description of the workflow is of course much saver then\nautomatically committing to an other branch.\n\n-- \nMartin Waitz\n"},{"id":"21268","messageId":"1149531734.23938.22.camel@cashmere.sps.mot.com","threadId":"4344","inReplyTo":"7vd5dvyvkq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git commit --branch","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-06-05T18:22:15Z","receivedAt":"2006-06-05T18:22:15Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Tue, 2006-05-30 at 17:52, Junio C Hamano wrote:\n> Martin Waitz <tali@admingilde.org> writes:\n> \n> >> And your approach is to backport the fix to its original topic\n> >> and then re-pull the topic onto the test branch.\n> >\n> > yes. I was doing this after working on gitweb a bit.\n> > In order to test gitweb, I need some local adaptations.\n> \n> Funny you mention this.  I had exactly the same arrangement for\n> hacking on gitweb.  One \"localconf\" branch to tell it where the\n> repositories are, \"origin\" to track upstream, \"master\" to use\n> for deployment, and other topic branches.\n\nWe all do. :-)\n\nBTW, did you (anyone?) see my patch to help the local\nconfiguration issue some?  It basically separates out the\nconfig bits into a separate hash table in a separate file that\ncan be updated quite independently without even modifying\nthe original gitweb.cgi.  That allows the gitweb.cgi \nproper to be slammed down and updated much more readily.\n\n    http://marc.theaimsgroup.com/?l=git&m=114308224922372&w=2\n\njdl\n"}]}