{"thread":{"id":"11278","subject":"git merge --no-commit ; does commit","startedAt":"2007-12-13T21:01:41Z","lastAt":"2007-12-16T10:53:11Z","messageCount":14,"participants":["Michael Dressel","Alex Riesen","Björn Steinbrink","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"63052","messageId":"alpine.LSU.0.99999.0712132151080.5326@castor.milkiway.cos","threadId":"11278","inReplyTo":null,"subject":"git merge --no-commit ; does commit","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-12-13T21:01:41Z","receivedAt":"2007-12-13T21:01:41Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"Hi,\n\ngit merge --no-commit does \"create\" a commit. At lesat the \nhead and index are moved to the new commit fetched from . Maybe \nthat is because git was able to do a fast forward?\n\nCheers,\nMichael\n"},{"id":"63053","messageId":"81b0412b0712131319h63609810m593f0e552d02a83c@mail.gmail.com","threadId":"11278","inReplyTo":"alpine.LSU.0.99999.0712132151080.5326@castor.milkiway.cos","subject":"Re: git merge --no-commit ; does commit","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-13T21:19:08Z","receivedAt":"2007-12-13T21:19:08Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 13/12/2007, Michael Dressel wrote:\n> git merge --no-commit does \"create\" a commit. At lesat the\n> head and index are moved to the new commit fetched from . Maybe\n> that is because git was able to do a fast forward?\n\nYes. Because fast-forward is what it called: fast-forward.\nIt does not do any commits at all.\n"},{"id":"63055","messageId":"81b0412b0712131323p7cbba402hbfe8105eb356bdc2@mail.gmail.com","threadId":"11278","inReplyTo":"81b0412b0712131319h63609810m593f0e552d02a83c@mail.gmail.com","subject":"Re: git merge --no-commit ; does commit","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-13T21:23:21Z","receivedAt":"2007-12-13T21:23:21Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 13/12/2007, Alex Riesen wrote:\n> On 13/12/2007, Michael Dressel wrote:\n> > git merge --no-commit does \"create\" a commit. At lesat the\n> > head and index are moved to the new commit fetched from . Maybe\n> > that is because git was able to do a fast forward?\n>\n> Yes. Because fast-forward is what it called: fast-forward.\n> It does not do any commits at all.\n>\n\nIf you have a very recent git, you can avoid fast-forward when merging\nby running with --no-ff. It has it's problems in general case, so it is not\ndefault (see the git ml archive for \"fast-forward does not commit\").\n"},{"id":"63056","messageId":"alpine.LSU.0.99999.0712132224280.5606@castor.milkiway.cos","threadId":"11278","inReplyTo":"81b0412b0712131319h63609810m593f0e552d02a83c@mail.gmail.com","subject":"Re: git merge --no-commit ; does commit","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-12-13T21:28:30Z","receivedAt":"2007-12-13T21:28:30Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"\n\nOn Thu, 13 Dec 2007, Alex Riesen wrote:\n\n> On 13/12/2007, Michael Dressel wrote:\n>> git merge --no-commit does \"create\" a commit. At lesat the\n>> head and index are moved to the new commit fetched from . Maybe\n>> that is because git was able to do a fast forward?\n>\n> Yes. Because fast-forward is what it called: fast-forward.\n> It does not do any commits at all.\n>\n\nIt looks like I misunderstood the meaning of --no-commit. I have \nto use --squash in this case.\n\nCheers,\nMichael\n"},{"id":"63119","messageId":"20071214074925.GA3525@steel.home","threadId":"11278","inReplyTo":"alpine.LSU.0.99999.0712132224280.5606@castor.milkiway.cos","subject":"Re: git merge --no-commit ; does commit","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-14T07:49:25Z","receivedAt":"2007-12-14T07:49:25Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:\n> On Thu, 13 Dec 2007, Alex Riesen wrote:\n>> On 13/12/2007, Michael Dressel wrote:\n>>> git merge --no-commit does \"create\" a commit. At lesat the\n>>> head and index are moved to the new commit fetched from . Maybe\n>>> that is because git was able to do a fast forward?\n>>\n>> Yes. Because fast-forward is what it called: fast-forward.\n>> It does not do any commits at all.\n>>\n>\n> It looks like I misunderstood the meaning of --no-commit. I have to use \n> --squash in this case.\n>\n\nMaybe. Or maybe you misunderstood the meaning of --squash, which also\nis not a merge.\n"},{"id":"63264","messageId":"alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos","threadId":"11278","inReplyTo":"20071214074925.GA3525@steel.home","subject":"Re: git merge --no-commit ; does commit","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-12-15T18:14:48Z","receivedAt":"2007-12-15T18:14:48Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"\n\nOn Fri, 14 Dec 2007, Alex Riesen wrote:\n\n> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:\n>> On Thu, 13 Dec 2007, Alex Riesen wrote:\n>>> On 13/12/2007, Michael Dressel wrote:\n>>>> git merge --no-commit does \"create\" a commit. At lesat the\n>>>> head and index are moved to the new commit fetched from . Maybe\n>>>> that is because git was able to do a fast forward?\n>>>\n>>> Yes. Because fast-forward is what it called: fast-forward.\n>>> It does not do any commits at all.\n>>>\n>>\n>> It looks like I misunderstood the meaning of --no-commit. I have to use\n>> --squash in this case.\n>>\n>\n> Maybe. Or maybe you misunderstood the meaning of --squash, which also\n> is not a merge.\n\nSince \"git merge --squash \" does a merge of into the \nworking tree why would you not call it a merge?\nAnyway that was what I wanted. Merging (a topic branch) into my \ncurrent branch (the main branch) but being able to create commits that are\nmore suitable for keeping in the history of the current branch than the\ncommits I created during developing on .\nWould you recommend a different way of doing this?\n\nThank you,\nMichael\n"},{"id":"63265","messageId":"20071215182653.GB22485@atjola.homenet","threadId":"11278","inReplyTo":"alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos","subject":"Re: git merge --no-commit ; does commit","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-12-15T18:26:53Z","receivedAt":"2007-12-15T18:26:53Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2007.12.15 19:14:48 +0100, Michael Dressel wrote:\n>\n>\n> On Fri, 14 Dec 2007, Alex Riesen wrote:\n>\n>> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:\n>>> On Thu, 13 Dec 2007, Alex Riesen wrote:\n>>>> On 13/12/2007, Michael Dressel wrote:\n>>>>> git merge --no-commit does \"create\" a commit. At lesat the\n>>>>> head and index are moved to the new commit fetched from . Maybe\n>>>>> that is because git was able to do a fast forward?\n>>>>\n>>>> Yes. Because fast-forward is what it called: fast-forward.\n>>>> It does not do any commits at all.\n>>>>\n>>>\n>>> It looks like I misunderstood the meaning of --no-commit. I have to use\n>>> --squash in this case.\n>>>\n>>\n>> Maybe. Or maybe you misunderstood the meaning of --squash, which also\n>> is not a merge.\n>\n> Since \"git merge --squash \" does a merge of into the \n> working tree why would you not call it a merge?\n\nA \"real\" merge commit has at least two parents, and retains the\nindividual commits of each branch in the history. It just connects two\nlines of history. --squash just takes all changes and produces a\nsingle-parented commit, destroying the individual commits that\noriginally introduced the changes.\n\n> Anyway that was what I wanted. Merging (a topic branch) into my \n> current branch (the main branch) but being able to create commits that are\n> more suitable for keeping in the history of the current branch than the\n> commits I created during developing on .\n> Would you recommend a different way of doing this?\n\nIf you didn't publish your topic branch, use interactive rebasing to\nre-order/edit your commits.\n\nBjörn\n"},{"id":"63267","messageId":"m37ijfrcm5.fsf@roke.D-201","threadId":"11278","inReplyTo":"alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos","subject":"Re: git merge --no-commit ; does commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-15T19:18:07Z","receivedAt":"2007-12-15T19:18:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael Dressel writes:\n\n> On Fri, 14 Dec 2007, Alex Riesen wrote:\n> \n>> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:\n>>> On Thu, 13 Dec 2007, Alex Riesen wrote:\n>>>> On 13/12/2007, Michael Dressel wrote:\n>>>>> git merge --no-commit does \"create\" a commit. At lesat the\n>>>>> head and index are moved to the new commit fetched from . Maybe\n>>>>> that is because git was able to do a fast forward?\n>>>>\n>>>> Yes. Because fast-forward is what it called: fast-forward.\n>>>> It does not do any commits at all.\n>>>>\n>>>\n>>> It looks like I misunderstood the meaning of --no-commit. I have to use\n>>> --squash in this case.\n>>>\n>>\n>> Maybe. Or maybe you misunderstood the meaning of --squash, which also\n>> is not a merge.\n> \n> Since \"git merge --squash \" does a merge of into the\n> working tree why would you not call it a merge?\n\nA few illustrations. Commits A, B, C were made on 'trunk', commits\na, b, c were made on 'branch'. You are on 'trunk', running \n\"git merge branch\". We assume that there are no conflicts.\n\n1. A non fast-forward case\n\n 1---2---3---A---B---C <-- trunk <-- HEAD\n \\\n \\-a---b---c <-- branch\n\n1.1. \"git merge branch\"\n\n 1---2---3---A---B---C--M <-- trunk <-- HEAD\n \\ /\n \\-a---b---c/ <-- branch\n\nM is _merge_ commits, with two parents: C and c. It was created\nby \"git merge branch\".\n\n1.2. \"git merge --no-commit branch\"\n\n /-------- trunk <-- HEAD\n v\n 1---2---3---A---B---C--*\n \\ /\n \\-a---b---c/ <-- branch\n ^ \n \\-------- MERGE_HEAD\n\nThe merge commit '*' is prepared, but not yet committed, just\nas if there were merge conflict during merge. \"git commit\"\nwould commit a merge (and would tell you that it does a merge\ncommit).\n\n1.3. \"git merge --no-commit --no-ff branch\"\n\nLike in 1.2, because it is non fast-forward case.\n\n1.4. \"git merge --squash branch\"\n\n 1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD\n \\\n \\-a---b---c <-- branch\n\n\"[abc]'\" is a _single parent_ commit (it is not a merge commit!)\nwhich incorporates changes made on branch as if it were made in\na single, large (!) commit.\n\n1.5. \"git rebase trunk branch\" (or \"git pull --rebase branch\")\n\n 1---2---3---A---B---C <-- trunk \n \\\n \\-a'--b'--c' <-- branch <-- HEAD\n\nRebase is step-by-step process, replying commits a, b, c on top\nof trunk, trying for the same _changes_. a', b', c' are newly\ncreated commits, introducing the same changes as a, b, c if there\nwere no rebase conflicts.\n\nI think that \"git pull --rebase branch\" goes a step further and\nactually does after-rebase fast-forward merge, and does not change\nbranch, but I might be mistaken.\n\n 1---2---3---A---B---C---a'--b'--c' <-- trunk <-- HEAD\n \\\n \\-a---b---c <-- branch\n\n\n2. Fast forward case; there are no commits A, B, C, and we\nstart from the following situation:\n\n 1---2---3 <-- trunk <-- HEAD\n \\\n \\-a---b---c <-- branch\n\n2.1. \"git merge branch\"\n\n 1---2---3 /----- trunk <-- HEAD\n \\ v\n \\-a---b---c <-- branch\n\nFast forward results in simply moving the head of trunk.\nIt does not create a commit, hence:\n\n2.2. \"git merge --no-commit branch\"\n\nLike in 2.1, because fast-forwarding does not create a commit.\n\n2.3. \"git merge --no-commit --no-ff branch\"\n\n 1---2---3 <-- trunk <-- HEAD\n \\\n \\-a---b---c <-- branch\n\n(probably with some error message).\n\n\nTest of understanding the concepts: what does \n\"git merge --squash --no-commit\" does?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"63271","messageId":"20071215193741.GB3021@steel.home","threadId":"11278","inReplyTo":"alpine.LSU.0.99999.0712151905280.4341@castor.milkiway.cos","subject":"Re: git merge --no-commit ; does commit","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-15T19:37:41Z","receivedAt":"2007-12-15T19:37:41Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Michael Dressel, Sat, Dec 15, 2007 19:14:48 +0100:\n>> Maybe. Or maybe you misunderstood the meaning of --squash, which also\n>> is not a merge.\n>\n> Since \"git merge --squash \" does a merge of into the \n> working tree why would you not call it a merge?\n\nBecause merge, in Git language, means connection histories. That one\njust mixes the text. That's different operation, kind of editing a\nfile.\n\n> Anyway that was what I wanted. Merging (a topic branch) into my \n> current branch (the main branch) but being able to create commits that are\n> more suitable for keeping in the history of the current branch than the\n> commits I created during developing on .\n> Would you recommend a different way of doing this?\n\nI would not recommend doing it at all. If I must, I'd rather use\ngit-rebase -i (interactive rebase).\n"},{"id":"63273","messageId":"alpine.LSU.0.99999.0712152117060.5151@castor.milkiway.cos","threadId":"11278","inReplyTo":"m37ijfrcm5.fsf@roke.D-201","subject":"Re: git merge --no-commit ; does commit","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-12-15T20:22:27Z","receivedAt":"2007-12-15T20:22:27Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"\n\nOn Sat, 15 Dec 2007, Jakub Narebski wrote:\n\n> Michael Dressel writes:\n>\n>> On Fri, 14 Dec 2007, Alex Riesen wrote:\n>>\n>>> Michael Dressel, Thu, Dec 13, 2007 22:28:30 +0100:\n>>>> On Thu, 13 Dec 2007, Alex Riesen wrote:\n>>>>> On 13/12/2007, Michael Dressel wrote:\n>>>>>> git merge --no-commit does \"create\" a commit. At lesat the\n>>>>>> head and index are moved to the new commit fetched from . Maybe\n>>>>>> that is because git was able to do a fast forward?\n>>>>>\n>>>>> Yes. Because fast-forward is what it called: fast-forward.\n>>>>> It does not do any commits at all.\n>>>>>\n>>>>\n>>>> It looks like I misunderstood the meaning of --no-commit. I have to use\n>>>> --squash in this case.\n>>>>\n>>>\n>>> Maybe. Or maybe you misunderstood the meaning of --squash, which also\n>>> is not a merge.\n>>\n>> Since \"git merge --squash \" does a merge of into the\n>> working tree why would you not call it a merge?\n>\n> A few illustrations. Commits A, B, C were made on 'trunk', commits\n> a, b, c were made on 'branch'. You are on 'trunk', running\n> \"git merge branch\". We assume that there are no conflicts.\n>\n> 1. A non fast-forward case\n>\n> 1---2---3---A---B---C <-- trunk <-- HEAD\n> \\\n> \\-a---b---c <-- branch\n>\n> 1.1. \"git merge branch\"\n>\n> 1---2---3---A---B---C--M <-- trunk <-- HEAD\n> \\ /\n> \\-a---b---c/ <-- branch\n>\n> M is _merge_ commits, with two parents: C and c. It was created\n> by \"git merge branch\".\n>\n> 1.2. \"git merge --no-commit branch\"\n>\n> /-------- trunk <-- HEAD\n> v\n> 1---2---3---A---B---C--*\n> \\ /\n> \\-a---b---c/ <-- branch\n> ^\n> \\-------- MERGE_HEAD\n>\n> The merge commit '*' is prepared, but not yet committed, just\n> as if there were merge conflict during merge. \"git commit\"\n> would commit a merge (and would tell you that it does a merge\n> commit).\n>\n> 1.3. \"git merge --no-commit --no-ff branch\"\n>\n> Like in 1.2, because it is non fast-forward case.\n>\n> 1.4. \"git merge --squash branch\"\n>\n> 1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD\n> \\\n> \\-a---b---c <-- branch\n>\n> \"[abc]'\" is a _single parent_ commit (it is not a merge commit!)\n> which incorporates changes made on branch as if it were made in\n> a single, large (!) commit.\n>\n> 1.5. \"git rebase trunk branch\" (or \"git pull --rebase branch\")\n>\n> 1---2---3---A---B---C <-- trunk\n> \\\n> \\-a'--b'--c' <-- branch <-- HEAD\n>\n> Rebase is step-by-step process, replying commits a, b, c on top\n> of trunk, trying for the same _changes_. a', b', c' are newly\n> created commits, introducing the same changes as a, b, c if there\n> were no rebase conflicts.\n>\n> I think that \"git pull --rebase branch\" goes a step further and\n> actually does after-rebase fast-forward merge, and does not change\n> branch, but I might be mistaken.\n>\n> 1---2---3---A---B---C---a'--b'--c' <-- trunk <-- HEAD\n> \\\n> \\-a---b---c <-- branch\n>\n>\n> 2. Fast forward case; there are no commits A, B, C, and we\n> start from the following situation:\n>\n> 1---2---3 <-- trunk <-- HEAD\n> \\\n> \\-a---b---c <-- branch\n>\n> 2.1. \"git merge branch\"\n>\n> 1---2---3 /----- trunk <-- HEAD\n> \\ v\n> \\-a---b---c <-- branch\n>\n> Fast forward results in simply moving the head of trunk.\n> It does not create a commit, hence:\n>\n> 2.2. \"git merge --no-commit branch\"\n>\n> Like in 2.1, because fast-forwarding does not create a commit.\n>\n> 2.3. \"git merge --no-commit --no-ff branch\"\n>\n> 1---2---3 <-- trunk <-- HEAD\n> \\\n> \\-a---b---c <-- branch\n>\n> (probably with some error message).\n>\n\nThanks alot for the elaborate explanations.\n\n>\n> Test of understanding the concepts: what does\n> \"git merge --squash --no-commit\" does?\n>\n\n>From the man page it sounds \"git merge --squash --no-commit\" would do the \nsame as \"git merge --squash\". So in the example 1.4 [abc] should not be a \ncommit.\n\nCheers,\nMichael\n"},{"id":"63275","messageId":"alpine.LSU.0.99999.0712152124220.5151@castor.milkiway.cos","threadId":"11278","inReplyTo":"20071215193741.GB3021@steel.home","subject":"Re: git merge --no-commit ; does commit","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-12-15T20:33:20Z","receivedAt":"2007-12-15T20:33:20Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"\n\nOn Sat, 15 Dec 2007, Alex Riesen wrote:\n\n> Michael Dressel, Sat, Dec 15, 2007 19:14:48 +0100:\n>>> Maybe. Or maybe you misunderstood the meaning of --squash, which also\n>>> is not a merge.\n>>\n>> Since \"git merge --squash \" does a merge of into the\n>> working tree why would you not call it a merge?\n>\n> Because merge, in Git language, means connection histories. That one\n> just mixes the text. That's different operation, kind of editing a\n> file.\n\nThat's a nice clarification. In my case I wanted that \"just mixes the \ntext\" thing because I did aggressively do commits during development \ntrying out slightly different approaches and being able to go back to compare \nthem. These different games are not interesting to keep in the history \nonce a good solution has been found.\n\n>\n>> Anyway that was what I wanted. Merging (a topic branch) into my\n>> current branch (the main branch) but being able to create commits that are\n>> more suitable for keeping in the history of the current branch than the\n>> commits I created during developing on .\n>> Would you recommend a different way of doing this?\n>\n> I would not recommend doing it at all. If I must, I'd rather use\n> git-rebase -i (interactive rebase).\n>\n>\n\nYes I didn't use rebase sofar. I should consider it sometimes.\n\nCheers,\nMichael\n"},{"id":"63277","messageId":"m33au3r7zf.fsf@roke.D-201","threadId":"11278","inReplyTo":"alpine.LSU.0.99999.0712152117060.5151@castor.milkiway.cos","subject":"Re: git merge --no-commit ; does commit","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-15T20:57:58Z","receivedAt":"2007-12-15T20:57:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael Dressel writes:\n> On Sat, 15 Dec 2007, Jakub Narebski wrote:\n>> Michael Dressel writes:\n>>>\n>>> Since \"git merge --squash \" does a merge of into the\n>>> working tree why would you not call it a merge?\n>>\n>> A few illustrations. Commits A, B, C were made on 'trunk', commits\n>> a, b, c were made on 'branch'. You are on 'trunk', running\n>> \"git merge branch\". We assume that there are no conflicts.\n>>\n>> 1. A non fast-forward case\n>>\n>> 1---2---3---A---B---C <-- trunk <-- HEAD\n>> \\\n>> \\-a---b---c <-- branch\n\n>> 1.2. \"git merge --no-commit branch\"\n>>\n>> /-------- trunk <-- HEAD\n>> v\n>> 1---2---3---A---B---C--*\n>> \\ /\n>> \\-a---b---c/ <-- branch\n>> ^\n>> \\-------- MERGE_HEAD\n>>\n>> The merge commit '*' is prepared, but not yet committed, just\n>> as if there were merge conflict during merge. \"git commit\"\n>> would commit a merge (and would tell you that it does a merge\n>> commit).\n\n>> 1.4. \"git merge --squash branch\"\n>>\n>> 1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD\n>> \\\n>> \\-a---b---c <-- branch\n>>\n>> \"[abc]'\" is a _single parent_ commit (it is not a merge commit!)\n>> which incorporates changes made on branch as if it were made in\n>> a single, large (!) commit.\n> \n> Thanks alot for the elaborate explanations.\n\nYou are welcome\n \n>> Test of understanding the concepts: what does\n>> \"git merge --squash --no-commit\" does?\n>>\n> \n> From the man page it sounds \"git merge --squash --no-commit\" would do\n> the same as \"git merge --squash\". So in the example 1.4 [abc] should\n> not be a commit.\n\n /---------\\\n v \\\n 1---2---3---A---B---C--*[abc]' \\-- trunk <-- HEAD\n \\\n \\-a---b---c <-- branch\n\nwhere *[abc]' is prepared state (staged but not committed changes)\nsquashing achanges into commits a, b, c into trunk.\n\nNote that using \"git rebase --interactive\" you can squash, reorder\nand edit commits; if you rather work in this way, reordering, editing\netc. \"on the go\" you perhaps should consider patch-management\ninterfaces like StGIT (Stacked GIT) or Guilt (formerly gq).\n\nBTW. in practice [abc]' in squash case is the same as M in normal\ncase, only M has two parents recorded, and [abc]' does not.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"63279","messageId":"alpine.LSU.0.99999.0712152212030.5326@castor.milkiway.cos","threadId":"11278","inReplyTo":"m33au3r7zf.fsf@roke.D-201","subject":"Re: git merge --no-commit ; does commit","fromName":"Michael Dressel","fromEmail":"michaeltilodressel@t-online.de","sentAt":"2007-12-15T21:15:22Z","receivedAt":"2007-12-15T21:15:22Z","isPatch":false,"sender":{"key":"michaeltilodressel@t-online.de","avatar":null},"body":"\n\nOn Sat, 15 Dec 2007, Jakub Narebski wrote:\n\n> Michael Dressel writes:\n>> On Sat, 15 Dec 2007, Jakub Narebski wrote:\n>>> Michael Dressel writes:\n>>>>\n>>>> Since \"git merge --squash \" does a merge of into the\n>>>> working tree why would you not call it a merge?\n>>>\n>>> A few illustrations. Commits A, B, C were made on 'trunk', commits\n>>> a, b, c were made on 'branch'. You are on 'trunk', running\n>>> \"git merge branch\". We assume that there are no conflicts.\n>>>\n>>> 1. A non fast-forward case\n>>>\n>>> 1---2---3---A---B---C <-- trunk <-- HEAD\n>>> \\\n>>> \\-a---b---c <-- branch\n>\n>>> 1.2. \"git merge --no-commit branch\"\n>>>\n>>> /-------- trunk <-- HEAD\n>>> v\n>>> 1---2---3---A---B---C--*\n>>> \\ /\n>>> \\-a---b---c/ <-- branch\n>>> ^\n>>> \\-------- MERGE_HEAD\n>>>\n>>> The merge commit '*' is prepared, but not yet committed, just\n>>> as if there were merge conflict during merge. \"git commit\"\n>>> would commit a merge (and would tell you that it does a merge\n>>> commit).\n>\n>>> 1.4. \"git merge --squash branch\"\n>>>\n>>> 1---2---3---A---B---C--[abc]' <-- trunk <-- HEAD\n>>> \\\n>>> \\-a---b---c <-- branch\n>>>\n>>> \"[abc]'\" is a _single parent_ commit (it is not a merge commit!)\n>>> which incorporates changes made on branch as if it were made in\n>>> a single, large (!) commit.\n>>\n>> Thanks alot for the elaborate explanations.\n>\n> You are welcome\n>\n>>> Test of understanding the concepts: what does\n>>> \"git merge --squash --no-commit\" does?\n>>>\n>>\n>> From the man page it sounds \"git merge --squash --no-commit\" would do\n>> the same as \"git merge --squash\". So in the example 1.4 [abc] should\n>> not be a commit.\n>\n> /---------\\\n> v \\\n> 1---2---3---A---B---C--*[abc]' \\-- trunk <-- HEAD\n> \\\n> \\-a---b---c <-- branch\n>\n> where *[abc]' is prepared state (staged but not committed changes)\n> squashing achanges into commits a, b, c into trunk.\n>\n> Note that using \"git rebase --interactive\" you can squash, reorder\n> and edit commits; if you rather work in this way, reordering, editing\n> etc. \"on the go\" you perhaps should consider patch-management\n> interfaces like StGIT (Stacked GIT) or Guilt (formerly gq).\n>\n> BTW. in practice [abc]' in squash case is the same as M in normal\n> case, only M has two parents recorded, and [abc]' does not.\n\nThanks again. There is a lot for me to practice now.\n\nCheers,\nMichael\n"},{"id":"63316","messageId":"20071216105311.GA2937@steel.home","threadId":"11278","inReplyTo":"alpine.LSU.0.99999.0712152124220.5151@castor.milkiway.cos","subject":"Re: git merge --no-commit ; does commit","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-12-16T10:53:11Z","receivedAt":"2007-12-16T10:53:11Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Michael Dressel, Sat, Dec 15, 2007 21:33:20 +0100:\n> On Sat, 15 Dec 2007, Alex Riesen wrote:\n>> Michael Dressel, Sat, Dec 15, 2007 19:14:48 +0100:\n>>>> Maybe. Or maybe you misunderstood the meaning of --squash, which also\n>>>> is not a merge.\n>>>\n>>> Since \"git merge --squash \" does a merge of into the\n>>> working tree why would you not call it a merge?\n>>\n>> Because merge, in Git language, means connection histories. That one\n>> just mixes the text. That's different operation, kind of editing a\n>> file.\n>\n> That's a nice clarification. In my case I wanted that \"just mixes the text\" \n> thing because I did aggressively do commits during development trying out \n> slightly different approaches and being able to go back to compare them. \n> These different games are not interesting to keep in the history once a \n> good solution has been found.\n\nIn this case --squash is almost right. \"rebase -i\" (interactive rebase)\nstill better: it'll allow you rebuild the development history in a\nmore fine-grained way. It can reorder commits, \"mix\" them together,\nedit commit messages or just delete them altogether.\nTry it, by the look of your situation you'll like it. Actually, it is\nexactly why Johannes wrote it.\n"}]}