{"thread":{"id":"55759","subject":"fast forward merge overwriting my code","startedAt":"2021-05-22T15:55:28Z","lastAt":"2021-05-30T11:01:02Z","messageCount":23,"participants":["Andre Ulrich","Philip Oakley","Johannes Sixt","Junio C Hamano","brian m. carlson","Bagas Sanjaya","Igor Djordjevic","Felipe Contreras","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425335","messageId":"20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@webmail.th-koeln.de","threadId":"55759","inReplyTo":null,"subject":"fast forward merge overwriting my code","fromName":"Andre Ulrich","fromEmail":"andre.ulrich@smail.fh-koeln.de","sentAt":"2021-05-22T15:48:15Z","receivedAt":"2021-05-22T15:55:28Z","isPatch":false,"sender":{"key":"andre.ulrich@smail.fh-koeln.de","avatar":null},"body":"\nHello community,\n\nI am new to git, and at the moment I am learning the basics. There are \nloads of good videos on the internet, but I have one specific \nquestion, I haven't found the answer yet:\n\nLet's say I have a .txt file on my master branch. I used\n\ngit add .\n\nand\n\ngit commit -m \"blabla\"\n\nso everything is staged and in the history. Now I check out a new branch\n\ngit checkout -b testing\n\nand edit the .txt file. I add some new lines at the end, but I also \nchange some of the already existing lines. Then again I add and commit \neverything. Then I use\n\ngit checkout master\n\nand\n\ngit merge testing\n\nI would expect git to tell me \"hey, wait, you have changed some of the \nfirst lines in the .txt file. When you merge, your code on master will \nbe altered\". But git just merges everything in.\nJust imagine this was working code, and changing some of the first \nlines breaks everything in the following lines.\nI think I have found out what is the problem: git considers this a \nfast forward merge (since there were no commits on master between the \ncreation and the merging of the test branch).\nBut this is annoying. I want to be able to choose, what changes I want \nto keep, when I do the merge (just as in case of a 3way merge, when \nyou can call a graphical merge tool to decide what lines to keep).\nI know, I could git diff the latest commits hashes of both branches \nand then fix the file on testing branch accordingly. But those are two \nseparate steps, and I want everything to happen in one convenient step.\n\nIs there any possibility to do so?\n\nMany thanks for any help in advance!\nMany greetings\nAndré Ulrich\n-- \n**********************************************************************\n** Fachhochschule Koeln / Cologne University of Applied Sciences\n**\n** Andre Ulrich\n** E-Mail: andre.ulrich@smail.fh-koeln.de\n**********************************************************************\n\n"},{"id":"425337","messageId":"8f3d4d1e-18f4-ccb2-9439-80a5812c2f36@iee.email","threadId":"55759","inReplyTo":"20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@webmail.th-koeln.de","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-22T17:12:49Z","receivedAt":"2021-05-22T17:12:52Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 22/05/2021 16:48, Andre Ulrich wrote:\n>\n> Hello community,\n>\n> I am new to git, and at the moment I am learning the basics. There are\n> loads of good videos on the internet, but I have one specific\n> question, I haven't found the answer yet:\n>\n> Let's say I have a .txt file on my master branch. I used\n>\n> git add .\n>\n> and\n>\n> git commit -m \"blabla\"\n>\n> so everything is staged and in the history. Now I check out a new branch\n>\n> git checkout -b testing\n>\n> and edit the .txt file. I add some new lines at the end, but I also\n> change some of the already existing lines. Then again I add and commit\n> everything. Then I use\n>\n> git checkout master\n>\n> and\n>\n> git merge testing\n>\n> I would expect git to tell me \"hey, wait, you have changed some of the\n> first lines in the .txt file. When you merge, your code on master will\n> be altered\". But git just merges everything in.\n> Just imagine this was working code, and changing some of the first\n> lines breaks everything in the following lines.\n> I think I have found out what is the problem: git considers this a\n> fast forward merge (since there were no commits on master between the\n> creation and the merging of the test branch).\n\nmaybe `git merge --no-ff testing` for use of a command line option\n\nor setup your .gitconfig e.g. `git config --global merge.ff no`,\nbut also `git config --global pull.ff yes` if you are using `git pull`\n(=fetch + merge)\n\nAs always, check the manual to ensure understanding.\n\n> But this is annoying. I want to be able to choose, what changes I want\n> to keep, when I do the merge (just as in case of a 3way merge, when\n> you can call a graphical merge tool to decide what lines to keep).\n> I know, I could git diff the latest commits hashes of both branches\n> and then fix the file on testing branch accordingly. But those are two\n> separate steps, and I want everything to happen in one convenient step.\n>\n> Is there any possibility to do so?\n>\n> Many thanks for any help in advance!\n> Many greetings\n> André Ulrich\nPhilip\n"},{"id":"425371","messageId":"4c1c3dbc-7a89-02db-3883-b7eea644cd83@kdbg.org","threadId":"55759","inReplyTo":"20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@webmail.th-koeln.de","subject":"Re: fast forward merge overwriting my code","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2021-05-23T09:48:55Z","receivedAt":"2021-05-23T09:49:00Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"[resending, as I forgot to include git@vger]\n\nAm 22.05.21 um 17:48 schrieb Andre Ulrich:\n> Let's say I have a .txt file on my master branch. I used\n> \n> git add .\n> \n> and\n> \n> git commit -m \"blabla\"\n> \n> so everything is staged and in the history. Now I check out a new branch\n> \n> git checkout -b testing\n> \n> and edit the .txt file. I add some new lines at the end, but I also\n> change some of the already existing lines. Then again I add and commit\n> everything. Then I use\n> \n> git checkout master\n> \n> and\n> \n> git merge testing\n> \n> I would expect git to tell me \"hey, wait, you have changed some of the\n> first lines in the .txt file. When you merge, your code on master will\n> be altered\". But git just merges everything in.\n> Just imagine this was working code, and changing some of the first lines\n> breaks everything in the following lines.\n> I think I have found out what is the problem: git considers this a fast\n> forward merge (since there were no commits on master between the\n> creation and the merging of the test branch).\n> But this is annoying. I want to be able to choose, what changes I want\n> to keep, when I do the merge (just as in case of a 3way merge, when you\n> can call a graphical merge tool to decide what lines to keep).\n\nBut in a 3-way merge, you only get to choose which changes you take if\nthere is a conflict. If, in your example, you had committed a change to\na different file on master before the merge, you would get a\nnon-fast-forward (3-way) merge, and still no opportunity to choose which\nchanges you take because there would be no conflict.\n\nAnd why do you think we need a general warning \"when you merge, your\ncode on master will be altered\"? Why would I want to make a merge into\nmaster if not to change the code on master?\n\n> I know, I could git diff the latest commits hashes of both branches and\n> then fix the file on testing branch accordingly. But those are two\n> separate steps, and I want everything to happen in one convenient step.\n\nGit encourages good practice, which is to make sure that all commits do\nnot have known bugs. Your desired workflow is bad practice. If you want\nto follow bad practices, then *you* have to do the extra work, e.g., to\nfix up a merge that introduced a known-bad commit.\n\n-- Hannes\n"},{"id":"425381","messageId":"xmqqo8d1o5ni.fsf@gitster.g","threadId":"55759","inReplyTo":"8f3d4d1e-18f4-ccb2-9439-80a5812c2f36@iee.email","subject":"Re: fast forward merge overwriting my code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-23T15:01:53Z","receivedAt":"2021-05-23T15:02:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> On 22/05/2021 16:48, Andre Ulrich wrote:\n>> .... Then I use\n>>\n>> git checkout master\n>>\n>> and\n>>\n>> git merge testing\n>>\n>> I would expect git to tell me \"hey, wait, you have changed some of the\n>> first lines in the .txt file. When you merge, your code on master will\n>> be altered\". But git just merges everything in.\n> ...\n> maybe `git merge --no-ff testing` for use of a command line option\n>\n> or setup your .gitconfig e.g. `git config --global merge.ff no`,\n> but also `git config --global pull.ff yes` if you are using `git pull`\n> (=fetch + merge)\n\nI didn't get an impression that this has anything to do with\nfast-forwarding, though. The file in question has changes on the\n\"testing\" branch since it forked from \"master\", and the user is\nmerging, i.e. the user _assumes_ that the tip of each branch suits\nhis/her purpose better than the tip of the other branch, hence wants\nto take improvements on both branches incorporated into a single\nhistory--- which is the point of \"merging\" the testing branch into\nthe master branch. The result of merging might reveal that the tip\nof the other branch wasn't as great as s/he earlier thought, in\nwhich case s/he may want to undo the merge. But if the result of\nmerging better suites his/her purpose, it would be an improvement\nover where 'master' used to be (and it would also be an improvement\nover where 'testing' used to be), and the world makes a progress.\n\nIn this particular case, the \"master\" side did not move since the\ntwo branches forked, so the merge was to take improvements made on\n\"testing\" into \"master\", and if the edit to the file in question\nmade on \"testing\" were bogus, the merging operation of course will\nbring that breakage in, together with all the other changes. Since\nthe lack of any progress on the \"master\" side does not change this\npicture, I do not think fast-forwardness has anything to do with\nwhat Andre is complaining about.\n\n\"git merge\" cannot be expected to inspect the file and point out\n\"no, the edit they made on the testing branch is totally bogus,\ndon't merge it\". That is left for humans and tools other than Git\n(like test suite) may help them.\n\n\n"},{"id":"425390","messageId":"YKrsC9CaG/KDvDBi@camp.crustytoothpaste.net","threadId":"55759","inReplyTo":"4c1c3dbc-7a89-02db-3883-b7eea644cd83@kdbg.org","subject":"Re: fast forward merge overwriting my code","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-23T23:58:03Z","receivedAt":"2021-05-23T23:58:41Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-23 at 09:48:55, Johannes Sixt wrote:\n> [resending, as I forgot to include git@vger]\n> \n> Am 22.05.21 um 17:48 schrieb Andre Ulrich:\n> > Let's say I have a .txt file on my master branch. I used\n> > \n> > git add .\n> > \n> > and\n> > \n> > git commit -m \"blabla\"\n> > \n> > so everything is staged and in the history. Now I check out a new branch\n> > \n> > git checkout -b testing\n> > \n> > and edit the .txt file. I add some new lines at the end, but I also\n> > change some of the already existing lines. Then again I add and commit\n> > everything. Then I use\n> > \n> > git checkout master\n> > \n> > and\n> > \n> > git merge testing\n> > \n> > I would expect git to tell me \"hey, wait, you have changed some of the\n> > first lines in the .txt file. When you merge, your code on master will\n> > be altered\". But git just merges everything in.\n> > Just imagine this was working code, and changing some of the first lines\n> > breaks everything in the following lines.\n> > I think I have found out what is the problem: git considers this a fast\n> > forward merge (since there were no commits on master between the\n> > creation and the merging of the test branch).\n\nYes. However, if Git did an actual merge, the result would be the same.\nIn a three-way merge, if one side changes, and the other does not, the\nchange is adopted. A fast-forward merge just avoids the merge commit.\n\n> > But this is annoying. I want to be able to choose, what changes I want\n> > to keep, when I do the merge (just as in case of a 3way merge, when you\n> > can call a graphical merge tool to decide what lines to keep).\n> \n> But in a 3-way merge, you only get to choose which changes you take if\n> there is a conflict. If, in your example, you had committed a change to\n> a different file on master before the merge, you would get a\n> non-fast-forward (3-way) merge, and still no opportunity to choose which\n> changes you take because there would be no conflict.\n> \n> And why do you think we need a general warning \"when you merge, your\n> code on master will be altered\"? Why would I want to make a merge into\n> master if not to change the code on master?\n\nI suspect Andre has a goal here or a specific use case that we're not\nunderstanding. If we got some more explanation about what's going on,\nwe could probably offer a more useful response addressing that specific\nuse case or goal. It might not be a use case we support, but at least\nwe could address it directly.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"425397","messageId":"20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de","threadId":"55759","inReplyTo":"YKrsC9CaG/KDvDBi@camp.crustytoothpaste.net","subject":"Re: fast forward merge overwriting my code","fromName":"Andre Ulrich","fromEmail":"andre.ulrich@smail.fh-koeln.de","sentAt":"2021-05-24T06:13:55Z","receivedAt":"2021-05-24T06:14:00Z","isPatch":false,"sender":{"key":"andre.ulrich@smail.fh-koeln.de","avatar":null},"body":"Hello everybody, thanks for your help, I really appreciate it!\n\nWhat I have described was only an abstract example, because I did not \nwant to bother you with the whole story. I will try to explain my \nactual situation:\n- first: there is no txt. file, it is jupyter notebooks (.ipynb) and \nthey are not only about programming, there are also lots of markdown\n- second: I am working with my professor over GitLab and I look for \noptions to further improve these notebooks\n- third: I have to develope a nice GitLab workflow\n\nI know, diffing and merging of notebooks is another story (but we can \nhandle that with nbdime).\nAnd I know, there are lots of guides on git workflows on the internet \n(and that is pretty much just what I have adopted).\n\nSo this is how we proceed:\n- my prof has a repo on GitHub\n- I have forked the repo\n- I have cloned the forked repo\n- I have created a branch 'update' in my local clone\n- I edit a notebook on the branch 'update' and commit\n- I push 'update' to my forked repo on GitHub\n- I create a merge request\n- my prof reviews the changes and accepts them (if I have done \nacceptable work)\n\nSo the last point is where we still want to do some fine tuning. Right \nnow this looks about: my prof fetches my edits and locally checks out \na branch to compare the changes with git diff.\nBut in this diff view you can't edit the files. So you have to \nseparately open up another window to edit the changes (lets say my \nprof only wants to keep some of my changes, but not all).\n\nSo my Question is: is there any possibility, to be able to view (and \neven edit, if necessary) the changed notebook in the merging process \n(as in my example with the 3way merge)?\nOr is the only option to separately view the diff and edit the \nnotebook (two seperate steps instead of one)?\n\nThe latter would also be acceptable, if it really is the only way. Bu \nit would be nice, if viewing and editing could be done in one \nconvenient step during merging.\n\nMany greetings\nAndré Ulrich\n\n\nZitat von \"brian m. carlson\" :\n\n> On 2021-05-23 at 09:48:55, Johannes Sixt wrote:\n>> [resending, as I forgot to include git@vger]\n>>\n>> Am 22.05.21 um 17:48 schrieb Andre Ulrich:\n>> > Let's say I have a .txt file on my master branch. I used\n>> >\n>> > git add .\n>> >\n>> > and\n>> >\n>> > git commit -m \"blabla\"\n>> >\n>> > so everything is staged and in the history. Now I check out a new branch\n>> >\n>> > git checkout -b testing\n>> >\n>> > and edit the .txt file. I add some new lines at the end, but I also\n>> > change some of the already existing lines. Then again I add and commit\n>> > everything. Then I use\n>> >\n>> > git checkout master\n>> >\n>> > and\n>> >\n>> > git merge testing\n>> >\n>> > I would expect git to tell me \"hey, wait, you have changed some of the\n>> > first lines in the .txt file. When you merge, your code on master will\n>> > be altered\". But git just merges everything in.\n>> > Just imagine this was working code, and changing some of the first lines\n>> > breaks everything in the following lines.\n>> > I think I have found out what is the problem: git considers this a fast\n>> > forward merge (since there were no commits on master between the\n>> > creation and the merging of the test branch).\n>\n> Yes. However, if Git did an actual merge, the result would be the same.\n> In a three-way merge, if one side changes, and the other does not, the\n> change is adopted. A fast-forward merge just avoids the merge commit.\n>\n>> > But this is annoying. I want to be able to choose, what changes I want\n>> > to keep, when I do the merge (just as in case of a 3way merge, when you\n>> > can call a graphical merge tool to decide what lines to keep).\n>>\n>> But in a 3-way merge, you only get to choose which changes you take if\n>> there is a conflict. If, in your example, you had committed a change to\n>> a different file on master before the merge, you would get a\n>> non-fast-forward (3-way) merge, and still no opportunity to choose which\n>> changes you take because there would be no conflict.\n>>\n>> And why do you think we need a general warning \"when you merge, your\n>> code on master will be altered\"? Why would I want to make a merge into\n>> master if not to change the code on master?\n>\n> I suspect Andre has a goal here or a specific use case that we're not\n> understanding. If we got some more explanation about what's going on,\n> we could probably offer a more useful response addressing that specific\n> use case or goal. It might not be a use case we support, but at least\n> we could address it directly.\n> --\n> brian m. carlson (he/him or they/them)\n> Houston, Texas, US\n\n\n-- \n**********************************************************************\n** Fachhochschule Koeln / Cologne University of Applied Sciences\n**\n** Andre Ulrich\n** E-Mail: andre.ulrich@smail.fh-koeln.de\n**********************************************************************\n\n"},{"id":"425421","messageId":"f3f8927f-75af-c3bd-07af-5fd4b64987e9@iee.email","threadId":"55759","inReplyTo":"xmqqo8d1o5ni.fsf@gitster.g","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-24T09:50:50Z","receivedAt":"2021-05-24T09:50:54Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 23/05/2021 16:01, Junio C Hamano wrote:\n> Philip Oakley writes:\n>\n>> On 22/05/2021 16:48, Andre Ulrich wrote:\n>>> .... Then I use\n>>>\n>>> git checkout master\n>>>\n>>> and\n>>>\n>>> git merge testing\n>>>\n>>> I would expect git to tell me \"hey, wait, you have changed some of the\n>>> first lines in the .txt file. When you merge, your code on master will\n>>> be altered\". But git just merges everything in.\n>> ...\n>> maybe `git merge --no-ff testing` for use of a command line option\n>>\n>> or setup your .gitconfig e.g. `git config --global merge.ff no`,\n>> but also `git config --global pull.ff yes` if you are using `git pull`\n>> (=fetch + merge)\n> I didn't get an impression that this has anything to do with\n> fast-forwarding, though. \n\nAndre had (in the body of the text) explicitly said that it was the fast\nforward that was the problem for him.\n\nI suspect he had a mental model / world view / weltanshauung that was\nmore aligned to a swim lane model of branches (named lines of\ndevelopment) and that, possibly in a GUI, the loss two lanes was rather\nconfusing.\n\n> The file in question has changes on the\n> \"testing\" branch since it forked from \"master\", and the user is\n> merging, i.e. the user _assumes_ that the tip of each branch suits\n> his/her purpose better than the tip of the other branch, hence wants\n> to take improvements on both branches incorporated into a single\n> history--- which is the point of \"merging\" the testing branch into\n> the master branch. \n\nIn his description it's not always clear \"also change some of the\nalready existing lines\" what happened elsewhere that could lead to the\nconfusion. It will have been tricky for Andre, as someone new to git, to\nreally know what was going on. We can't assume the new user knows what\nGit will do.\n\n> The result of merging might reveal that the tip\n> of the other branch wasn't as great as s/he earlier thought, in\n> which case s/he may want to undo the merge. But if the result of\n> merging better suites his/her purpose, it would be an improvement\n> over where 'master' used to be (and it would also be an improvement\n> over where 'testing' used to be), and the world makes a progress.\n>\n> In this particular case, the \"master\" side did not move since the\n> two branches forked, so the merge was to take improvements made on\n> \"testing\" into \"master\", and if the edit to the file in question\n> made on \"testing\" were bogus, the merging operation of course will\n> bring that breakage in, together with all the other changes. Since\n> the lack of any progress on the \"master\" side does not change this\n> picture, I do not think fast-forwardness has anything to do with\n> what Andre is complaining about.\n>\n> \"git merge\" cannot be expected to inspect the file and point out\n> \"no, the edit they made on the testing branch is totally bogus,\n> don't merge it\". That is left for humans and tools other than Git\n> (like test suite) may help them.\n>\n>\nThe changes to mental models that are needed to understand Git can take\nsome time, especially for those who haven't grown up with it.\n\nPhilip\n"},{"id":"425427","messageId":"3b5ecbcb-5d94-e7c4-e73b-2e00acdd0232@gmail.com","threadId":"55759","inReplyTo":"20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de","subject":"Re: fast forward merge overwriting my code","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-05-24T11:13:53Z","receivedAt":"2021-05-24T11:14:05Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"Hi Andre,\n\nOn 24/05/21 13.13, Andre Ulrich wrote:\n> So the last point is where we still want to do some fine tuning. Right now this looks about: my prof fetches my edits and locally checks out a branch to compare the changes with git diff.\n> But in this diff view you can't edit the files. So you have to separately open up another window to edit the changes (lets say my prof only wants to keep some of my changes, but not all).\n> \n> So my Question is: is there any possibility, to be able to view (and even edit, if necessary) the changed notebook in the merging process (as in my example with the 3way merge)?\n> Or is the only option to separately view the diff and edit the notebook (two seperate steps instead of one)?\n> \n> The latter would also be acceptable, if it really is the only way. Bu it would be nice, if viewing and editing could be done in one convenient step during merging.\n\nWhen you run git merge, when Git decided that automerging with 3-way\nmerge can be done without conflicts, the editor will be fired up for\nyou to enter commit message. Delete or comment all the message lines\nto abort the commit by \"empty message\" mechanism.\n\nNow you can view diff (git diff) or edit the merged files as you\nwish. Of course, you can coordinate with author of branch you're\nmerging from to get consensus. After then, git commit.\n\nSimilar steps can be done for merge conflicts. Git will pause merging\nprocess when conflicts occur, and you need to edit to resolve them.\nAgain, coordinating with original branch author is helpful to decide\nthe resolution.\n\nThanks.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"425432","messageId":"e02cabf0-adb6-49bb-b379-b12f37ca6e1a@iee.email","threadId":"55759","inReplyTo":"20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-24T13:16:50Z","receivedAt":"2021-05-24T13:16:53Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi André, In-line and bottom posting is preferred.\n\nOn 24/05/2021 07:13, Andre Ulrich wrote:\n> Hello everybody, thanks for your help, I really appreciate it!\n>\n> What I have described was only an abstract example, because I did not\n> want to bother you with the whole story. I will try to explain my\n> actual situation:\n> - first: there is no txt. file, it is jupyter notebooks (.ipynb) and\n> they are not only about programming, there are also lots of markdown\nI've not used jupyter notebooks so below is more about the general process..\n\n> - second: I am working with my professor over GitLab and I look for\n> options to further improve these notebooks\n> - third: I have to develope a nice GitLab workflow\nGiLab noted here\n>\n> I know, diffing and merging of notebooks is another story (but we can\n> handle that with nbdime).\n> And I know, there are lots of guides on git workflows on the internet\n> (and that is pretty much just what I have adopted).\n>\n> So this is how we proceed:\n> - my prof has a repo on GitHub\nbut GitHub here..\n> - I have forked the repo\n> - I have cloned the forked repo\n> - I have created a branch 'update' in my local clone\n> - I edit a notebook on the branch 'update' and commit\n> - I push 'update' to my forked repo on GitHub\n> - I create a merge request\n\nSo this is using the on-line web UI?\n\nThere is some contention between the GitHub/GitLab pull/merge request\nprocess (on-line) and the local command line (cli) approach to merging\nas they can be at cross-purposes...\n\nMost earlier responses have been about using the command line rather\nthan the web-UI.\n\nThe Git-for-Windows (GfW) development does use the GitHub PR approach,\nleveraging the email notifications, and the ability (of the developer,\nin response to maintainer comments) to force push an updated branch\n(i.e. using the same branch name) to re-run the approval and on-line\nmerging.\n\n> - my prof reviews the changes and accepts them (if I have done\n> acceptable work)\ni.e. the PR was/will be taken verbatim, (or with minor amendments if the\nprof is the maintainer and you've allowed that), at least on GitHub..\n>\n> So the last point is where we still want to do some fine tuning. Right\n> now this looks about: my prof fetches my edits and locally checks out\n> a branch to compare the changes with git diff.\n> But in this diff view you can't edit the files. \nHmm, do you mean the prof is viewing your changes in the diff-view of\nthe web-UI? (likely as that's the notification link;-).\nYou/The prof can switch to views with more context if needed.\n\nIf the prof has truly fetched the branch from your remote e.g.\n\"Ulrich/testing\" it can be checked out locally as a detached head for\ntesting, local changes made, etc, and then the prof can either create a\nfresh branch to hold those comments, and push them to a place you can\nsee, or directly make the edits on the web-UI.\n\nOften in the GfW PR reviews the comments are made via the web-UI, with\ncode suggestions, and the developer than updates & tests their local\nbranch, and force pushes the update for a follow up review.\n\n> So you have to separately open up another window to edit the changes\n> (lets say my prof only wants to keep some of my changes, but not all).\n>\n> So my Question is: is there any possibility, to be able to view (and\n> even edit, if necessary) the changed notebook in the merging process\n> (as in my example with the 3way merge)?\n\nI'm not aware of such a mechanism (as simply described) but I'm sure\nthere are ways to use the \"staging area\" view (e.g. via the Git-gui) to\nselectively pick out hunks and lines that are staged (and non-selected\nhunk/lines stashed) to give a testable worktree during the 'merge'.\nMerge is commonly seen/discussed as a single continuous step, rather\nthan being a fully uninterruptible process.\n\n> Or is the only option to separately view the diff and edit the\n> notebook (two seperate steps instead of one)?\n>\n> The latter would also be acceptable, if it really is the only way. Bu\n> it would be nice, if viewing and editing could be done in one\n> convenient step during merging.\n\nThe key here is probably to clarify which parts are being done on the\nserver's web-UI, and which parts are from a local fetch/checkout viewpoint.\n\nPhilip\n\n>\n> Many greetings\n> André Ulrich\n>\n>\n> Zitat von \"brian m. carlson\" :\n>\n>> On 2021-05-23 at 09:48:55, Johannes Sixt wrote:\n>>> [resending, as I forgot to include git@vger]\n>>>\n>>> Am 22.05.21 um 17:48 schrieb Andre Ulrich:\n>>> > Let's say I have a .txt file on my master branch. I used\n>>> >\n>>> > git add .\n>>> >\n>>> > and\n>>> >\n>>> > git commit -m \"blabla\"\n>>> >\n>>> > so everything is staged and in the history. Now I check out a new\n>>> branch\n>>> >\n>>> > git checkout -b testing\n>>> >\n>>> > and edit the .txt file. I add some new lines at the end, but I also\n>>> > change some of the already existing lines. Then again I add and\n>>> commit\n>>> > everything. Then I use\n>>> >\n>>> > git checkout master\n>>> >\n>>> > and\n>>> >\n>>> > git merge testing\n>>> >\n>>> > I would expect git to tell me \"hey, wait, you have changed some of\n>>> the\n>>> > first lines in the .txt file. When you merge, your code on master\n>>> will\n>>> > be altered\". But git just merges everything in.\n>>> > Just imagine this was working code, and changing some of the first\n>>> lines\n>>> > breaks everything in the following lines.\n>>> > I think I have found out what is the problem: git considers this a\n>>> fast\n>>> > forward merge (since there were no commits on master between the\n>>> > creation and the merging of the test branch).\n>>\n>> Yes.  However, if Git did an actual merge, the result would be the same.\n>> In a three-way merge, if one side changes, and the other does not, the\n>> change is adopted.  A fast-forward merge just avoids the merge commit.\n>>\n>>> > But this is annoying. I want to be able to choose, what changes I\n>>> want\n>>> > to keep, when I do the merge (just as in case of a 3way merge,\n>>> when you\n>>> > can call a graphical merge tool to decide what lines to keep).\n>>>\n>>> But in a 3-way merge, you only get to choose which changes you take if\n>>> there is a conflict. If, in your example, you had committed a change to\n>>> a different file on master before the merge, you would get a\n>>> non-fast-forward (3-way) merge, and still no opportunity to choose\n>>> which\n>>> changes you take because there would be no conflict.\n>>>\n>>> And why do you think we need a general warning \"when you merge, your\n>>> code on master will be altered\"? Why would I want to make a merge into\n>>> master if not to change the code on master?\n>>\n>> I suspect Andre has a goal here or a specific use case that we're not\n>> understanding.  If we got some more explanation about what's going on,\n>> we could probably offer a more useful response addressing that specific\n>> use case or goal.  It might not be a use case we support, but at least\n>> we could address it directly.\n>> -- \n>> brian m. carlson (he/him or they/them)\n>> Houston, Texas, US\n>\n>\n\n"},{"id":"425433","messageId":"20210524150653.Horde.3GnmG8mUdIOZDFHiOKtoxAe@webmail.th-koeln.de","threadId":"55759","inReplyTo":"e02cabf0-adb6-49bb-b379-b12f37ca6e1a@iee.email","subject":"Re: fast forward merge overwriting my code","fromName":"Andre Ulrich","fromEmail":"andre.ulrich@smail.fh-koeln.de","sentAt":"2021-05-24T15:06:53Z","receivedAt":"2021-05-24T15:14:11Z","isPatch":false,"sender":{"key":"andre.ulrich@smail.fh-koeln.de","avatar":null},"body":"Hi Philip, thanks for your detailed answer!\nZitat von Philip Oakley :\n\n> Hi André, In-line and bottom posting is preferred.\n>\n\nOh ok, thanks for the tip.\n\n> On 24/05/2021 07:13, Andre Ulrich wrote:\n>> Hello everybody, thanks for your help, I really appreciate it!\n>>\n>> What I have described was only an abstract example, because I did not\n>> want to bother you with the whole story. I will try to explain my\n>> actual situation:\n>> - first: there is no txt. file, it is jupyter notebooks (.ipynb) and\n>> they are not only about programming, there are also lots of markdown\n> I've not used jupyter notebooks so below is more about the general process..\n>\n>> - second: I am working with my professor over GitLab and I look for\n>> options to further improve these notebooks\n>> - third: I have to develope a nice GitLab workflow\n> GiLab noted here\n>>\n>> I know, diffing and merging of notebooks is another story (but we can\n>> handle that with nbdime).\n>> And I know, there are lots of guides on git workflows on the internet\n>> (and that is pretty much just what I have adopted).\n>>\n>> So this is how we proceed:\n>> - my prof has a repo on GitHub\n> but GitHub here..\n\nsorry, I have mixed it up. It meant GitLab\n\n>> - I have forked the repo\n>> - I have cloned the forked repo\n>> - I have created a branch 'update' in my local clone\n>> - I edit a notebook on the branch 'update' and commit\n>> - I push 'update' to my forked repo on GitHub\n>> - I create a merge request\n>\n> So this is using the on-line web UI?\n\nYes, I press the button \"Create merge request\" (it autmatically \nappears, as soon as I have pushed a new branch into the forked repo). \nBut all the other steps (besides the forking)\nare done in the Git-for-Windows bash command line.\nThen my prof receives a notification (also UI button in GitLab). At \nthis point, my prof could even view the changes on GitLab, BUT... \n(GOTO1)\n\n>\n> There is some contention between the GitHub/GitLab pull/merge request\n> process (on-line) and the local command line (cli) approach to merging\n> as they can be at cross-purposes...\n>\n> Most earlier responses have been about using the command line rather\n> than the web-UI.\n>\n\nYes, the merging is done locally via command line. After locally \nmergin, the resulting master is pushed back to GitLab\n\n> The Git-for-Windows (GfW) development does use the GitHub PR approach,\n> leveraging the email notifications, and the ability (of the developer,\n> in response to maintainer comments) to force push an updated branch\n> (i.e. using the same branch name) to re-run the approval and on-line\n> merging.\n>\n>> - my prof reviews the changes and accepts them (if I have done\n>> acceptable work)\n> i.e. the PR was/will be taken verbatim, (or with minor amendments if the\n> prof is the maintainer and you've allowed that), at least on GitHub..\n>>\n>> So the last point is where we still want to do some fine tuning. Right\n>> now this looks about: my prof fetches my edits and locally checks out\n>> a branch to compare the changes with git diff.\n>> But in this diff view you can't edit the files.\n> Hmm, do you mean the prof is viewing your changes in the diff-view of\n> the web-UI? (likely as that's the notification link;-).\n> You/The prof can switch to views with more context if needed.\n\n(FROM1) ... diffing jupyter notebooks in the GitLab web UI looks \nhorrible (because common diff tools can't really handle the notebooks \nunderlying json structure).\nThats why my prof diffs the notebooks locally via command line. And \nthen also the merging happens locally via command line. After mergin, \nthe master is beeing pushed back to GitLab\n\n>\n> If the prof has truly fetched the branch from your remote e.g.\n> \"Ulrich/testing\" it can be checked out locally as a detached head for\n> testing, local changes made, etc, and then the prof can either create a\n> fresh branch to hold those comments, and push them to a place you can\n> see, or directly make the edits on the web-UI.\n>\n\nYes, that fetching and checking out is exactly what's happening. \nThat's how my prof locally reviews my changes to decide whether they \nare good or not.\n\n> Often in the GfW PR reviews the comments are made via the web-UI, with\n> code suggestions, and the developer than updates & tests their local\n> branch, and force pushes the update for a follow up review.\n>\n>> So you have to separately open up another window to edit the changes\n>> (lets say my prof only wants to keep some of my changes, but not all).\n>>\n>> So my Question is: is there any possibility, to be able to view (and\n>> even edit, if necessary) the changed notebook in the merging process\n>> (as in my example with the 3way merge)?\n>\n> I'm not aware of such a mechanism (as simply described) but I'm sure\n> there are ways to use the \"staging area\" view (e.g. via the Git-gui) to\n> selectively pick out hunks and lines that are staged (and non-selected\n> hunk/lines stashed) to give a testable worktree during the 'merge'.\n\nAh ok, this could be an idea (it would requiere some more research, as \nI haven't used the git gui before (I want to learn everything from the \nscratch using the command line))\nBut to be honest, I think even this approach might already be too \ncumbersome (as this selectively picking and stashing sounds like a lot \nof work itself).\nBut maybe I'm looking for a workflow too simple (that doesn't even \nexist like that), and my prof just has to accept a little more effort \nfor diffing and merging?\n\n> Merge is commonly seen/discussed as a single continuous step, rather\n> than being a fully uninterruptible process.\n>\n>> Or is the only option to separately view the diff and edit the\n>> notebook (two seperate steps instead of one)?\n>>\n>> The latter would also be acceptable, if it really is the only way. Bu\n>> it would be nice, if viewing and editing could be done in one\n>> convenient step during merging.\n>\n> The key here is probably to clarify which parts are being done on the\n> server's web-UI, and which parts are from a local fetch/checkout viewpoint.\n>\n\nboth the viewing (diff) and the editing (separate editor) are beeing \ndone locally\n\nAnyway, Philip, thanks again for the detailed answer and your time!\n\nMany Greetings\nAndré Ulrich\n\n> Philip\n>\n>>\n>> Many greetings\n>> André Ulrich\n>>\n>>\n>> Zitat von \"brian m. carlson\" :\n>>\n>>> On 2021-05-23 at 09:48:55, Johannes Sixt wrote:\n>>>> [resending, as I forgot to include git@vger]\n>>>>\n>>>> Am 22.05.21 um 17:48 schrieb Andre Ulrich:\n>>>> > Let's say I have a .txt file on my master branch. I used\n>>>> >\n>>>> > git add .\n>>>> >\n>>>> > and\n>>>> >\n>>>> > git commit -m \"blabla\"\n>>>> >\n>>>> > so everything is staged and in the history. Now I check out a new\n>>>> branch\n>>>> >\n>>>> > git checkout -b testing\n>>>> >\n>>>> > and edit the .txt file. I add some new lines at the end, but I also\n>>>> > change some of the already existing lines. Then again I add and\n>>>> commit\n>>>> > everything. Then I use\n>>>> >\n>>>> > git checkout master\n>>>> >\n>>>> > and\n>>>> >\n>>>> > git merge testing\n>>>> >\n>>>> > I would expect git to tell me \"hey, wait, you have changed some of\n>>>> the\n>>>> > first lines in the .txt file. When you merge, your code on master\n>>>> will\n>>>> > be altered\". But git just merges everything in.\n>>>> > Just imagine this was working code, and changing some of the first\n>>>> lines\n>>>> > breaks everything in the following lines.\n>>>> > I think I have found out what is the problem: git considers this a\n>>>> fast\n>>>> > forward merge (since there were no commits on master between the\n>>>> > creation and the merging of the test branch).\n>>>\n>>> Yes.  However, if Git did an actual merge, the result would be the same.\n>>> In a three-way merge, if one side changes, and the other does not, the\n>>> change is adopted.  A fast-forward merge just avoids the merge commit.\n>>>\n>>>> > But this is annoying. I want to be able to choose, what changes I\n>>>> want\n>>>> > to keep, when I do the merge (just as in case of a 3way merge,\n>>>> when you\n>>>> > can call a graphical merge tool to decide what lines to keep).\n>>>>\n>>>> But in a 3-way merge, you only get to choose which changes you take if\n>>>> there is a conflict. If, in your example, you had committed a change to\n>>>> a different file on master before the merge, you would get a\n>>>> non-fast-forward (3-way) merge, and still no opportunity to choose\n>>>> which\n>>>> changes you take because there would be no conflict.\n>>>>\n>>>> And why do you think we need a general warning \"when you merge, your\n>>>> code on master will be altered\"? Why would I want to make a merge into\n>>>> master if not to change the code on master?\n>>>\n>>> I suspect Andre has a goal here or a specific use case that we're not\n>>> understanding.  If we got some more explanation about what's going on,\n>>> we could probably offer a more useful response addressing that specific\n>>> use case or goal.  It might not be a use case we support, but at least\n>>> we could address it directly.\n>>> --\n>>> brian m. carlson (he/him or they/them)\n>>> Houston, Texas, US\n>>\n>>\n\n\n-- \n**********************************************************************\n** Fachhochschule Koeln / Cologne University of Applied Sciences\n**\n** Andre Ulrich\n** E-Mail: andre.ulrich@smail.fh-koeln.de\n**********************************************************************\n\n"},{"id":"425441","messageId":"009aa860-7ffa-7105-b2fd-cf5996639a3a@gmail.com","threadId":"55759","inReplyTo":"20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de","subject":"Re: fast forward merge overwriting my code","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-05-24T17:47:06Z","receivedAt":"2021-05-24T17:47:19Z","isPatch":false,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"\nOn 24/05/2021 08:13, Andre Ulrich wrote:\n> \n> So this is how we proceed:\n> - my prof has a repo on GitHub\n> - I have forked the repo\n> - I have cloned the forked repo\n> - I have created a branch 'update' in my local clone\n> - I edit a notebook on the branch 'update' and commit\n> - I push 'update' to my forked repo on GitHub\n> - I create a merge request\n> - my prof reviews the changes and accepts them (if I have done \n> acceptable work)\n> \n> So the last point is where we still want to do some fine tuning. \n> Right now this looks about: my prof fetches my edits and locally \n> checks out a branch to compare the changes with git diff. But in this \n> diff view you can't edit the files. So you have to separately open up \n> another window to edit the changes (lets say my prof only wants to \n> keep some of my changes, but not all).\n\nI think that last point highlights the issue you guys are having - \nusing `merge` for doing both (1) actual merge, but also (2) review and \nedit at the same time, which is wrong (or very unconventional, to say \nthe least).\n\nIn ideal case (meaning no conflicts, no matter if 3-way merge or a \nfast-forward one), merge should accept all the changes being merged \nin from the side branch and incorporate them into the main branch. \n\nFrom this basic and the most common scenario alone it is visible that \nmerge should not \"keep some changes, but not all\" - the very point of \na merge is to (try to) keep _all the changes_, period.\n\nNow, as for the \"try to\" part - in some cases not all changes can be \nkept as they are, like when both branches changed same files and same \nlines (or close to), so that's when Git hands over the resolution to \nthe user, to determine what is the desired outcome of a conflicting \nmerge.\n\nStill, even in this case, the final outcome should be considered a \nsum of all the changes, even though some might have been altered or \nrearranged in order to better work with each other (as different \nbranches might have done the same thing in a different way).\n\nIn any case, it should not be up to the merge (process nor commit) to \ndiscard (nor add!) some of the non-conflicting changes you have made on \nyour 'update' branch - it is possible to do (something usually called \nan \"evil merge\", and for a reason), yet is not a good practice.\n\nAs an example, imagine you have commits 1, 2 and 3 on your 'update' \nbranch, and upon merging your professor decides to accept changes \nfrom commit 2 only, completely discarding changes from commits 1 and 3. \nYour history will end up looking something like this:\n\n(1) ---X-----------M 'master'\n \\ /\n 1---2---3 'update'\n\n... where M is the merge commit, merging branch 'update' into 'master'. \nAs it is, it's reasonable to expect of M to contain all the changes \nbrought in by 1, 2 and 3 - yet it is not the case, which could be \nrather confusing (on later history review).\n\nWhat would be a more common/usual scenario is, after trying a local \nmerge M and seeing some changes should not be accepted (like commits \n1 and 3), have your professor communicate the problem with you so you \ncan fix the issues yourself, inside 'update' branch, and iteratively \nrepeat this process as long as 'update' branch is not \"perfect\" - at \nwhich point it can be accepted _as a whole_, that is.\n\nYou professor should not accept to merge your changes as long as they \nare not all correct, and he specifically should not be using the \nmerge to correct the issues himself.\n\nDepending on your preference, he _could_ be doing the changes himself, \ntoo - but again doing so through standalone commits (on your 'update' \nbranch, for example), _not_ through a merge commit.\n\nBased on example (1) above, the finally merged changes history could \ninstead look like this:\n\n(2) ---X-------------------M1 'master'\n \\ /\n 1---2---3---4---5 'update'\n\n..., where commits 4 and 5 are fixes made on 'update' after your \nprofessor's comments on commits 1, 2 and 3, and M1 is the merge which \nfinally accepts all the changes from 'update'.\n\nAlternatively, if you use rebase, you can alter problematic commits 1 \nand 3 directly instead, so the history would look something like this:\n\n(3) ---X-----------M2 'master'\n \\ /\n 1'--2'--3' 'update'\n\n..., where original commits 1 and 3 are changed in order to be \nacceptable for the merge, becoming commits 1' and 3', while commit 2' \nwould stay the same as original commit 2. Again, merge commit M2 \naccepts all the changes as they now are (all correct).\n\nAlso, if commits 1 and 3 are completely wrong and not required in the \nfirst place, yet another alternative (using rebase) would be to drop \nthem altogether, ending up with a history like this:\n\n(4) ---X----M3 'master'\n \\ /\n 2\" 'update'\n\n..., where commit 2\" would be exactly the same as original commit 2, \nand commits 1 and 3 are dropped from the history completely - and \ntransparently, _not_ using the merge to do so, as in original example (1)\n(and your explained scenario).\n\nI hope these examples somewhat help, the main point remaining that \nmerge should not be used to discard/disapprove certain (especially \nnon-conflicting) changes, but only to finally accept/approve _all_ \nthe changes, possibly modified in the meantime as a result of an \niterative review and additional work.\n\nNote that there's nothing wrong in having your professor do his own \nlocal merges as part of this review process, but those should be only \ntemporary, to be discarded and not accepted until everything can be \nmerged (and accepted) as-is.\n\nRegards, Buga\n"},{"id":"425450","messageId":"9e6772ba-fee6-7a7f-2ff3-246e82f96ee3@iee.email","threadId":"55759","inReplyTo":"20210524150653.Horde.3GnmG8mUdIOZDFHiOKtoxAe@webmail.th-koeln.de","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-24T18:48:44Z","receivedAt":"2021-05-24T18:48:48Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"adding Pratyush for the Git Gui stash suggestion..\n\nOn 24/05/2021 16:06, Andre Ulrich wrote:\n> Hi Philip, thanks for your detailed answer!\n> Zitat von Philip Oakley :\n>\n>> Hi André, In-line and bottom posting is preferred.\n>>\n>\n> Oh ok, thanks for the tip.\n>\n>> On 24/05/2021 07:13, Andre Ulrich wrote:\n>>> Hello everybody, thanks for your help, I really appreciate it!\n>>>\n>>> What I have described was only an abstract example, because I did not\n>>> want to bother you with the whole story. I will try to explain my\n>>> actual situation:\n>>> - first: there is no txt. file, it is jupyter notebooks (.ipynb) and\n>>> they are not only about programming, there are also lots of markdown\n>> I've not used jupyter notebooks so below is more about the general\n>> process..\n>>\n>>> - second: I am working with my professor over GitLab and I look for\n>>> options to further improve these notebooks\n>>> - third: I have to develope a nice GitLab workflow\n>> GiLab noted here\n>>>\n>>> I know, diffing and merging of notebooks is another story (but we can\n>>> handle that with nbdime).\n>>> And I know, there are lots of guides on git workflows on the internet\n>>> (and that is pretty much just what I have adopted).\n>>>\n>>> So this is how we proceed:\n>>> - my prof has a repo on GitHub\n>> but GitHub here..\n>\n> sorry, I have mixed it up. It meant GitLab\n>\n>>> - I have forked the repo\n>>> - I have cloned the forked repo\n>>> - I have created a branch 'update' in my local clone\n>>> - I edit a notebook on the branch 'update' and commit\n>>> - I push 'update' to my forked repo on GitHub\n>>> - I create a merge request\n>>\n>> So this is using the on-line web UI?\n>\n> Yes, I press the button \"Create merge request\" (it autmatically\n> appears, as soon as I have pushed a new branch into the forked repo).\n> But all the other steps (besides the forking)\n> are done in the Git-for-Windows bash command line.\n> Then my prof receives a notification (also UI button in GitLab). At\n> this point, my prof could even view the changes on GitLab, BUT... (GOTO1)\n-> (FROM1)..\n>\n>>\n>> There is some contention between the GitHub/GitLab pull/merge request\n>> process (on-line) and the local command line (cli) approach to merging\n>> as they can be at cross-purposes...\n>>\n>> Most earlier responses have been about using the command line rather\n>> than the web-UI.\n>>\n>\n> Yes, the merging is done locally via command line. After locally\n> mergin, the resulting master is pushed back to GitLab\n\nYou could use --no-commit, so that the merge can be inspected and the\nrelevant parts picked or updated, but beware losing the second parent\nlink, and that you could be creating an \"evil merge\" (in Git terminology\nthat's content that was in neither parent.., rather than an automated\nconflict free merge..)\n\nFor your pushing (as opposed to the professor's) look ate the\nremote.pushDefault config setting allowing you to have the prof's repo\nas your upstream, but your own fork as the place you naturally push to\n(see\nhttps://lore.kernel.org/git/?q=%3C20191031154217.GA30187%40sigill.intra.peff.net%3E).\n\nAre others also doing development in the same notebook or on the same\nrepo during this review cycle? This can affect how any overlaps in the\nchanges affect each other\n\n>\n>> The Git-for-Windows (GfW) development does use the GitHub PR approach,\n>> leveraging the email notifications, and the ability (of the developer,\n>> in response to maintainer comments) to force push an updated branch\n>> (i.e. using the same branch name) to re-run the approval and on-line\n>> merging.\n>>\n>>> - my prof reviews the changes and accepts them (if I have done\n>>> acceptable work)\n>> i.e. the PR was/will be taken verbatim, (or with minor amendments if the\n>> prof is the maintainer and you've allowed that), at least on GitHub..\n>>>\n>>> So the last point is where we still want to do some fine tuning. Right\n>>> now this looks about: my prof fetches my edits and locally checks out\n>>> a branch to compare the changes with git diff.\n>>> But in this diff view you can't edit the files.\n>> Hmm, do you mean the prof is viewing your changes in the diff-view of\n>> the web-UI? (likely as that's the notification link;-).\n>> You/The prof can switch to views with more context if needed.\n>\n> (FROM1) ... diffing jupyter notebooks in the GitLab web UI looks\n> horrible (because common diff tools can't really handle the notebooks\n> underlying json structure).\n> Thats why my prof diffs the notebooks locally via command line. \nAre these 'large' a commit/changeset, or many smaller commits? And does\nyour project need good fine detail history (so you can reason about\nsmall changes from months ago)? Some projects benefit from the fine\ndetail, while for others it's a waste. It will depend on whether it will\nhelp the prof for selecting which commits to accept and which to reject\n(rather than having to pick apart a large commit)\n\n> And then also the merging happens locally via command line. After\n> mergin, the master is beeing pushed back to GitLab\n\nThe --no-commit may be useful here to enable that early inspection\nbefore the actual commit.\n\n>\n>>\n>> If the prof has truly fetched the branch from your remote e.g.\n>> \"Ulrich/testing\" it can be checked out locally as a detached head for\n>> testing, local changes made, etc, and then the prof can either create a\n>> fresh branch to hold those comments, and push them to a place you can\n>> see, or directly make the edits on the web-UI.\n>>\n>\n> Yes, that fetching and checking out is exactly what's happening.\n> That's how my prof locally reviews my changes to decide whether they\n> are good or not.\n\nIt's worth ensuring that the `rtb` (branch that tracks a remote's branch\n- remote tracking branch) concept manages to stick in your head (and the\nprofs) - you don't need a local branch of the same name as the remote\n;-) It took me a few years to get that into my head!\n\n>\n>> Often in the GfW PR reviews the comments are made via the web-UI, with\n>> code suggestions, and the developer than updates & tests their local\n>> branch, and force pushes the update for a follow up review.\n>>\n>>> So you have to separately open up another window to edit the changes\n>>> (lets say my prof only wants to keep some of my changes, but not all).\n>>>\n>>> So my Question is: is there any possibility, to be able to view (and\n>>> even edit, if necessary) the changed notebook in the merging process\n>>> (as in my example with the 3way merge)?\n>>\n>> I'm not aware of such a mechanism (as simply described) but I'm sure\n>> there are ways to use the \"staging area\" view (e.g. via the Git-gui) to\n>> selectively pick out hunks and lines that are staged (and non-selected\n>> hunk/lines stashed) to give a testable worktree during the 'merge'.\n>\n> Ah ok, this could be an idea (it would requiere some more research, as\n> I haven't used the git gui before (I want to learn everything from the\n> scratch using the command line))\n\nI commonly use the Gui when picking apart a large commit into smaller\nones when I'm happy that there's no overlaps. Small patches make for\neasier merging and fault finding, and better commit messages (good\nthesis practice)\n\n> But to be honest, I think even this approach might already be too\n> cumbersome (as this selectively picking and stashing sounds like a lot\n> of work itself).\n\nUnfortunately the Git Gui doesn't have a menu for stashing remaining\nchanges, but it's simple to flip over to the terminal to stash from\nthere to do the testing, and un-stash the remainder afterwards - I'll\nmaybe suggest the gui could include that capability for these types of\nworkflows (cc Pratyush Yadav ).\n> But maybe I'm looking for a workflow too simple (that doesn't even\n> exist like that), and my prof just has to accept a little more effort\n> for diffing and merging?\n\nOften it is a case of tweaking the workflow to use a capability\nyou/she/he wasn't aware of to give you that improved review process. It\ndoesn't help that I'm ignorant of how the jupyter notebooks are\ninternally formatted and how your diffing tool shows it (have you set up\nthe difftool options for command line use?\n\n>\n>> Merge is commonly seen/discussed as a single continuous step, rather\n>> than being a fully uninterruptible process.\n>>\n>>> Or is the only option to separately view the diff and edit the\n>>> notebook (two seperate steps instead of one)?\n>>>\n>>> The latter would also be acceptable, if it really is the only way. Bu\n>>> it would be nice, if viewing and editing could be done in one\n>>> convenient step during merging.\n>>\n>> The key here is probably to clarify which parts are being done on the\n>> server's web-UI, and which parts are from a local fetch/checkout\n>> viewpoint.\n>>\n>\n> both the viewing (diff) and the editing (separate editor) are beeing\n> done locally\n>\n> Anyway, Philip, thanks again for the detailed answer and your time!\n\nNo problem. As an engineer, real world workflows are an interest;-)\n\nPhilip\n>\n> Many Greetings\n> André Ulrich\n>\n>> Philip\n>>\n>>>\n>>> Many greetings\n>>> André Ulrich\n>>>\n>>>\n>>> Zitat von \"brian m. carlson\" :\n>>>\n>>>> On 2021-05-23 at 09:48:55, Johannes Sixt wrote:\n>>>>> [resending, as I forgot to include git@vger]\n>>>>>\n>>>>> Am 22.05.21 um 17:48 schrieb Andre Ulrich:\n>>>>> > Let's say I have a .txt file on my master branch. I used\n>>>>> >\n>>>>> > git add .\n>>>>> >\n>>>>> > and\n>>>>> >\n>>>>> > git commit -m \"blabla\"\n>>>>> >\n>>>>> > so everything is staged and in the history. Now I check out a new\n>>>>> branch\n>>>>> >\n>>>>> > git checkout -b testing\n>>>>> >\n>>>>> > and edit the .txt file. I add some new lines at the end, but I also\n>>>>> > change some of the already existing lines. Then again I add and\n>>>>> commit\n>>>>> > everything. Then I use\n>>>>> >\n>>>>> > git checkout master\n>>>>> >\n>>>>> > and\n>>>>> >\n>>>>> > git merge testing\n>>>>> >\n>>>>> > I would expect git to tell me \"hey, wait, you have changed some of\n>>>>> the\n>>>>> > first lines in the .txt file. When you merge, your code on master\n>>>>> will\n>>>>> > be altered\". But git just merges everything in.\n>>>>> > Just imagine this was working code, and changing some of the first\n>>>>> lines\n>>>>> > breaks everything in the following lines.\n>>>>> > I think I have found out what is the problem: git considers this a\n>>>>> fast\n>>>>> > forward merge (since there were no commits on master between the\n>>>>> > creation and the merging of the test branch).\n>>>>\n>>>> Yes.  However, if Git did an actual merge, the result would be the\n>>>> same.\n>>>> In a three-way merge, if one side changes, and the other does not, the\n>>>> change is adopted.  A fast-forward merge just avoids the merge commit.\n>>>>\n>>>>> > But this is annoying. I want to be able to choose, what changes I\n>>>>> want\n>>>>> > to keep, when I do the merge (just as in case of a 3way merge,\n>>>>> when you\n>>>>> > can call a graphical merge tool to decide what lines to keep).\n>>>>>\n>>>>> But in a 3-way merge, you only get to choose which changes you\n>>>>> take if\n>>>>> there is a conflict. If, in your example, you had committed a\n>>>>> change to\n>>>>> a different file on master before the merge, you would get a\n>>>>> non-fast-forward (3-way) merge, and still no opportunity to choose\n>>>>> which\n>>>>> changes you take because there would be no conflict.\n>>>>>\n>>>>> And why do you think we need a general warning \"when you merge, your\n>>>>> code on master will be altered\"? Why would I want to make a merge\n>>>>> into\n>>>>> master if not to change the code on master?\n>>>>\n>>>> I suspect Andre has a goal here or a specific use case that we're not\n>>>> understanding.  If we got some more explanation about what's going on,\n>>>> we could probably offer a more useful response addressing that\n>>>> specific\n>>>> use case or goal.  It might not be a use case we support, but at least\n>>>> we could address it directly.\n>>>> -- \n>>>> brian m. carlson (he/him or they/them)\n>>>> Houston, Texas, US\n>>>\n>>>\n>\n>\n\n"},{"id":"425527","messageId":"3b1a214a-d48a-d7f3-a506-66de34d3ada1@iee.email","threadId":"55759","inReplyTo":"9e6772ba-fee6-7a7f-2ff3-246e82f96ee3@iee.email","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-25T15:14:42Z","receivedAt":"2021-05-25T15:23:12Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 24/05/2021 19:48, Philip Oakley wrote:\n> adding Pratyush for the Git Gui stash suggestion..\nUltimately it's what is described at the end of the stash man page [1]\n\nHowever that didn't work as expected, having a conflict when doing the\nstash pop step, which I hadn't expected.\n> On 24/05/2021 16:06, Andre Ulrich wrote:\n>> Hi Philip, thanks for your detailed answer!\n>> Zitat von Philip Oakley :\n>>\n>>> Hi André, In-line and bottom posting is preferred.\n>>>\n>> Oh ok, thanks for the tip.\n>>\n>>> On 24/05/2021 07:13, Andre Ulrich wrote:\n>>>> Hello everybody, thanks for your help, I really appreciate it!\n>>>>\n>>>> What I have described was only an abstract example, because I did not\n>>>> want to bother you with the whole story. I will try to explain my\n>>>> actual situation:\n>>>> - first: there is no txt. file, it is jupyter notebooks (.ipynb) and\n>>>> they are not only about programming, there are also lots of markdown\n>>> I've not used jupyter notebooks so below is more about the general\n>>> process..\n>>>\n>>>> - second: I am working with my professor over GitLab and I look for\n>>>> options to further improve these notebooks\n>>>> - third: I have to develope a nice GitLab workflow\n>>> GiLab noted here\n>>>> I know, diffing and merging of notebooks is another story (but we can\n>>>> handle that with nbdime).\n>>>> And I know, there are lots of guides on git workflows on the internet\n>>>> (and that is pretty much just what I have adopted).\n>>>>\n>>>> So this is how we proceed:\n>>>> - my prof has a repo on GitHub\n>>> but GitHub here..\n>> sorry, I have mixed it up. It meant GitLab\n>>\n>>>> - I have forked the repo\n>>>> - I have cloned the forked repo\n>>>> - I have created a branch 'update' in my local clone\n>>>> - I edit a notebook on the branch 'update' and commit\n>>>> - I push 'update' to my forked repo on GitHub\n>>>> - I create a merge request\n>>> So this is using the on-line web UI?\n>> Yes, I press the button \"Create merge request\" (it autmatically\n>> appears, as soon as I have pushed a new branch into the forked repo).\n>> But all the other steps (besides the forking)\n>> are done in the Git-for-Windows bash command line.\n>> Then my prof receives a notification (also UI button in GitLab). At\n>> this point, my prof could even view the changes on GitLab, BUT... (GOTO1)\n> -> (FROM1)..\n>>> There is some contention between the GitHub/GitLab pull/merge request\n>>> process (on-line) and the local command line (cli) approach to merging\n>>> as they can be at cross-purposes...\n>>>\n>>> Most earlier responses have been about using the command line rather\n>>> than the web-UI.\n>>>\n>> Yes, the merging is done locally via command line. After locally\n>> mergin, the resulting master is pushed back to GitLab\n> You could use --no-commit, so that the merge can be inspected and the\n> relevant parts picked or updated, but beware losing the second parent\n> link, and that you could be creating an \"evil merge\" (in Git terminology\n> that's content that was in neither parent.., rather than an automated\n> conflict free merge..)\n>\n> For your pushing (as opposed to the professor's) look ate the\n> remote.pushDefault config setting allowing you to have the prof's repo\n> as your upstream, but your own fork as the place you naturally push to\n> (see\n> https://lore.kernel.org/git/?q=%3C20191031154217.GA30187%40sigill.intra.peff.net%3E).\n>\n> Are others also doing development in the same notebook or on the same\n> repo during this review cycle? This can affect how any overlaps in the\n> changes affect each other\n>\n>>> The Git-for-Windows (GfW) development does use the GitHub PR approach,\n>>> leveraging the email notifications, and the ability (of the developer,\n>>> in response to maintainer comments) to force push an updated branch\n>>> (i.e. using the same branch name) to re-run the approval and on-line\n>>> merging.\n>>>\n>>>> - my prof reviews the changes and accepts them (if I have done\n>>>> acceptable work)\n>>> i.e. the PR was/will be taken verbatim, (or with minor amendments if the\n>>> prof is the maintainer and you've allowed that), at least on GitHub..\n>>>> So the last point is where we still want to do some fine tuning. Right\n>>>> now this looks about: my prof fetches my edits and locally checks out\n>>>> a branch to compare the changes with git diff.\n>>>> But in this diff view you can't edit the files.\n>>> Hmm, do you mean the prof is viewing your changes in the diff-view of\n>>> the web-UI? (likely as that's the notification link;-).\n>>> You/The prof can switch to views with more context if needed.\n>> (FROM1) ... diffing jupyter notebooks in the GitLab web UI looks\n>> horrible (because common diff tools can't really handle the notebooks\n>> underlying json structure).\n>> Thats why my prof diffs the notebooks locally via command line. \n> Are these 'large' a commit/changeset, or many smaller commits? And does\n> your project need good fine detail history (so you can reason about\n> small changes from months ago)? Some projects benefit from the fine\n> detail, while for others it's a waste. It will depend on whether it will\n> help the prof for selecting which commits to accept and which to reject\n> (rather than having to pick apart a large commit)\n>\n>> And then also the merging happens locally via command line. After\n>> mergin, the master is beeing pushed back to GitLab\n> The --no-commit may be useful here to enable that early inspection\n> before the actual commit.\n>\n>>> If the prof has truly fetched the branch from your remote e.g.\n>>> \"Ulrich/testing\" it can be checked out locally as a detached head for\n>>> testing, local changes made, etc, and then the prof can either create a\n>>> fresh branch to hold those comments, and push them to a place you can\n>>> see, or directly make the edits on the web-UI.\n>>>\n>> Yes, that fetching and checking out is exactly what's happening.\n>> That's how my prof locally reviews my changes to decide whether they\n>> are good or not.\n> It's worth ensuring that the `rtb` (branch that tracks a remote's branch\n> - remote tracking branch) concept manages to stick in your head (and the\n> profs) - you don't need a local branch of the same name as the remote\n> ;-) It took me a few years to get that into my head!\n>\n>>> Often in the GfW PR reviews the comments are made via the web-UI, with\n>>> code suggestions, and the developer than updates & tests their local\n>>> branch, and force pushes the update for a follow up review.\n>>>\n>>>> So you have to separately open up another window to edit the changes\n>>>> (lets say my prof only wants to keep some of my changes, but not all).\n>>>>\n>>>> So my Question is: is there any possibility, to be able to view (and\n>>>> even edit, if necessary) the changed notebook in the merging process\n>>>> (as in my example with the 3way merge)?\n>>> I'm not aware of such a mechanism (as simply described) but I'm sure\n>>> there are ways to use the \"staging area\" view (e.g. via the Git-gui) to\n>>> selectively pick out hunks and lines that are staged (and non-selected\n>>> hunk/lines stashed) to give a testable worktree during the 'merge'.\n>> Ah ok, this could be an idea (it would requiere some more research, as\n>> I haven't used the git gui before (I want to learn everything from the\n>> scratch using the command line))\n> I commonly use the Gui when picking apart a large commit into smaller\n> ones when I'm happy that there's no overlaps. Small patches make for\n> easier merging and fault finding, and better commit messages (good\n> thesis practice)\n>\n>> But to be honest, I think even this approach might already be too\n>> cumbersome (as this selectively picking and stashing sounds like a lot\n>> of work itself).\n> Unfortunately the Git Gui doesn't have a menu for stashing remaining\n> changes, but it's simple to flip over to the terminal to stash from\n> there to do the testing, and un-stash the remainder afterwards\n\nas described in [1], though perhaps imperfectly.\n> - I'll\n> maybe suggest the gui could include that capability for these types of\n> workflows (cc Pratyush Yadav ).\n>> But maybe I'm looking for a workflow too simple (that doesn't even\n>> exist like that), and my prof just has to accept a little more effort\n>> for diffing and merging?\n> Often it is a case of tweaking the workflow to use a capability\n> you/she/he wasn't aware of to give you that improved review process. It\n> doesn't help that I'm ignorant of how the jupyter notebooks are\n> internally formatted and how your diffing tool shows it (have you set up\n> the difftool options for command line use?\n>\n>>> Merge is commonly seen/discussed as a single continuous step, rather\n>>> than being a fully uninterruptible process.\n>>>\n>>>> Or is the only option to separately view the diff and edit the\n>>>> notebook (two seperate steps instead of one)?\n>>>>\n>>>> The latter would also be acceptable, if it really is the only way. Bu\n>>>> it would be nice, if viewing and editing could be done in one\n>>>> convenient step during merging.\n>>> The key here is probably to clarify which parts are being done on the\n>>> server's web-UI, and which parts are from a local fetch/checkout\n>>> viewpoint.\n>>>\n>> both the viewing (diff) and the editing (separate editor) are beeing\n>> done locally\n>>\n>> Anyway, Philip, thanks again for the detailed answer and your time!\n> No problem. As an engineer, real world workflows are an interest;-)\n>\n> Philip\n>> Many Greetings\n>> André Ulrich\n>>\n>>> Philip\n>>>\n>>>> Many greetings\n>>>> André Ulrich\n>>>>\n>>>>\n>>>> Zitat von \"brian m. carlson\" :\n>>>>\n>>>>> On 2021-05-23 at 09:48:55, Johannes Sixt wrote:\n>>>>>> [resending, as I forgot to include git@vger]\n>>>>>>\n>>>>>> Am 22.05.21 um 17:48 schrieb Andre Ulrich:\n>>>>>>> Let's say I have a .txt file on my master branch. I used\n>>>>>>>\n>>>>>>> git add .\n>>>>>>>\n>>>>>>> and\n>>>>>>>\n>>>>>>> git commit -m \"blabla\"\n>>>>>>>\n>>>>>>> so everything is staged and in the history. Now I check out a new\n>>>>>> branch\n>>>>>>> git checkout -b testing\n>>>>>>>\n>>>>>>> and edit the .txt file. I add some new lines at the end, but I also\n>>>>>>> change some of the already existing lines. Then again I add and\n>>>>>> commit\n>>>>>>> everything. Then I use\n>>>>>>>\n>>>>>>> git checkout master\n>>>>>>>\n>>>>>>> and\n>>>>>>>\n>>>>>>> git merge testing\n>>>>>>>\n>>>>>>> I would expect git to tell me \"hey, wait, you have changed some of\n>>>>>> the\n>>>>>>> first lines in the .txt file. When you merge, your code on master\n>>>>>> will\n>>>>>>> be altered\". But git just merges everything in.\n>>>>>>> Just imagine this was working code, and changing some of the first\n>>>>>> lines\n>>>>>>> breaks everything in the following lines.\n>>>>>>> I think I have found out what is the problem: git considers this a\n>>>>>> fast\n>>>>>>> forward merge (since there were no commits on master between the\n>>>>>>> creation and the merging of the test branch).\n>>>>> Yes.  However, if Git did an actual merge, the result would be the\n>>>>> same.\n>>>>> In a three-way merge, if one side changes, and the other does not, the\n>>>>> change is adopted.  A fast-forward merge just avoids the merge commit.\n>>>>>\n>>>>>>> But this is annoying. I want to be able to choose, what changes I\n>>>>>> want\n>>>>>>> to keep, when I do the merge (just as in case of a 3way merge,\n>>>>>> when you\n>>>>>>> can call a graphical merge tool to decide what lines to keep).\n>>>>>> But in a 3-way merge, you only get to choose which changes you\n>>>>>> take if\n>>>>>> there is a conflict. If, in your example, you had committed a\n>>>>>> change to\n>>>>>> a different file on master before the merge, you would get a\n>>>>>> non-fast-forward (3-way) merge, and still no opportunity to choose\n>>>>>> which\n>>>>>> changes you take because there would be no conflict.\n>>>>>>\n>>>>>> And why do you think we need a general warning \"when you merge, your\n>>>>>> code on master will be altered\"? Why would I want to make a merge\n>>>>>> into\n>>>>>> master if not to change the code on master?\n>>>>> I suspect Andre has a goal here or a specific use case that we're not\n>>>>> understanding.  If we got some more explanation about what's going on,\n>>>>> we could probably offer a more useful response addressing that\n>>>>> specific\n>>>>> use case or goal.  It might not be a use case we support, but at least\n>>>>> we could address it directly.\n>>>>> -- \n>>>>> brian m. carlson (he/him or they/them)\n>>>>> Houston, Texas, US\n>>>>\n>>\n[1]\nhttps://git-scm.com/docs/git-stash#Documentation/git-stash.txt-Testingpartialcommits\n\n"},{"id":"425545","messageId":"60adb824bac10_2c7f620844@natae.notmuch","threadId":"55759","inReplyTo":"20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de","subject":"Re: fast forward merge overwriting my code","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-26T02:53:24Z","receivedAt":"2021-05-26T02:53:28Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andre Ulrich wrote:\n> So the last point is where we still want to do some fine tuning. Right \n> now this looks about: my prof fetches my edits and locally checks out \n> a branch to compare the changes with git diff.\n> But in this diff view you can't edit the files. So you have to \n> separately open up another window to edit the changes (lets say my \n> prof only wants to keep some of my changes, but not all).\n\nSo for example after fetching your changes your professor sees this:\n\n % git diff --cached\n --- a/README\n +++ b/README\n @@ -1,5 +1,7 @@\n This is an example document. Lot's of things to fill in.\n \n -[[ insert formula]]\n +The fromula is:\n +\n + y[1], mu * (1 - y[0] ** 2) * y[1] - y[0]\n \n This will help students jump straight in with simple examples.\n\nThe professor can then open the file, fix the typo, do some other\nchanges, type `git add --update`, then do `git diff --cached` again to\nsee if that's the output she wants:\n\n --- a/README\n +++ b/README\n @@ -1,5 +1,7 @@\n This is an example document. Lot's of things to fill in.\n \n -[[ insert formula]]\n +The formula is:\n +\n + x[1], mu * (1 - x[0] ** 2) * x[1] - x[0]\n \n This will help students jump straight in with simple examples.\n\n\nWhat you are saying is that it would be better to do `git $cmd` and in\nthat command you would be able to view the staged diff, edit the diff,\nand after quitting the editor the diff is applied to the stage.\n\nEssentially leaving everything ready for a commit.\n\nSort of like a combination of: `git diff --cached`,\n`vim $problematic_file`, `git add $problematic_file`, `git diff --cached`.\n\nCorrect?\n\n> So my Question is: is there any possibility, to be able to view (and \n> even edit, if necessary) the changed notebook in the merging process \n> (as in my example with the 3way merge)?\n> Or is the only option to separately view the diff and edit the \n> notebook (two seperate steps instead of one)?\n> \n> The latter would also be acceptable, if it really is the only way. Bu \n> it would be nice, if viewing and editing could be done in one \n> convenient step during merging.\n\nYou are describing `git stage edit`, a subcommand I suggested back in\n2014 and went completely ignored [1].\n\nYour professor just types `git stage edit`, fixes any problems she sees,\nquits the editor, `git commit`.\n\nDone.\n\nI just rebased the patches from 2016 and they seem to work fine. If you\nare interested let me know.\n\nCheers.\n\n[1] https://lore.kernel.org/git/1398449567-16314-3-git-send-email-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"425562","messageId":"da77d0a0-7fdb-e4c8-6510-87ea0294dac4@iee.email","threadId":"55759","inReplyTo":"60adb824bac10_2c7f620844@natae.notmuch","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-26T11:06:27Z","receivedAt":"2021-05-26T11:06:32Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 26/05/2021 03:53, Felipe Contreras wrote:\n> Andre Ulrich wrote:\n>> So the last point is where we still want to do some fine tuning. Right \n>> now this looks about: my prof fetches my edits and locally checks out \n>> a branch to compare the changes with git diff.\n>> But in this diff view you can't edit the files. So you have to \n>> separately open up another window to edit the changes (lets say my \n>> prof only wants to keep some of my changes, but not all).\n> So for example after fetching your changes your professor sees this:\n\nPart of Andre's problem was that this diff wasn't stable because the\nunderlying file format is said to be json so items can move around\nwithout issue (e.g. key value pairs swapping position) and that they\naren't really working on the json file (it may as well be binary..) but\non the jupytper notebook display view, so one step removed from the 'diff'.\n>\n> % git diff --cached\n> --- a/README\n> +++ b/README\n> @@ -1,5 +1,7 @@\n> This is an example document. Lot's of things to fill in.\n> \n> -[[ insert formula]]\n> +The fromula is:\n> +\n> + y[1], mu * (1 - y[0] ** 2) * y[1] - y[0]\n> \n> This will help students jump straight in with simple examples.\n>\n> The professor can then open the file, fix the typo, do some other\n> changes, type `git add --update`, \n\n type `git add --update`,\nUseful suggestion. Maybe need a corresponding `stash --update --keep-index` command \n(https://git-scm.com/docs/git-stash#Documentation/git-stash.txt-Testingpartialcommits)\n\n> then do `git diff --cached` again to\n> see if that's the output she wants:\n>\n> --- a/README\n> +++ b/README\n> @@ -1,5 +1,7 @@\n> This is an example document. Lot's of things to fill in.\n> \n> -[[ insert formula]]\n> +The formula is:\n> +\n> + x[1], mu * (1 - x[0] ** 2) * x[1] - x[0]\n> \n> This will help students jump straight in with simple examples.\n>\n>\n> What you are saying is that it would be better to do `git $cmd` and in\n> that command you would be able to view the staged diff, edit the diff,\n> and after quitting the editor the diff is applied to the stage.\n>\n> Essentially leaving everything ready for a commit.\nI see it as a two part problem - diff isn't an appropriate tool (the\nfiles are binary-like) but also that it's a review not a resolution of\nthe issues, which has to pick apart, and comment on, the proposed changes.\n\nI also suspect that it's part of the small commit - large commit\ndisparity (patches to be as small as possible but no smaller, so most\npatches end up too big..)\n>\n> Sort of like a combination of: `git diff --cached`,\n> `vim $problematic_file`, `git add $problematic_file`, `git diff --cached`.\n>\n> Correct?\nI think they have a need for a `git stash` that works when there is an\nintervening commit of the staged files (i.e. clean wrt the stash's\nstaged files).\n>\n>> So my Question is: is there any possibility, to be able to view (and \n>> even edit, if necessary) the changed notebook in the merging process \n>> (as in my example with the 3way merge)?\n>> Or is the only option to separately view the diff and edit the \n>> notebook (two seperate steps instead of one)?\n>>\n>> The latter would also be acceptable, if it really is the only way. Bu \n>> it would be nice, if viewing and editing could be done in one \n>> convenient step during merging.\n> You are describing `git stage edit`, a subcommand I suggested back in\n> 2014 and went completely ignored [1].\n>\n> Your professor just types `git stage edit`, fixes any problems she sees,\n> quits the editor, `git commit`.\n>\n> Done.\n>\n> I just rebased the patches from 2016 and they seem to work fine. If you\n> are interested let me know.\n>\n> Cheers.\n>\n> [1] https://lore.kernel.org/git/1398449567-16314-3-git-send-email-felipe.contreras@gmail.com/\n>\n\n"},{"id":"425580","messageId":"60ae947797deb_25ba2089c@natae.notmuch","threadId":"55759","inReplyTo":"da77d0a0-7fdb-e4c8-6510-87ea0294dac4@iee.email","subject":"Re: fast forward merge overwriting my code","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-26T18:33:27Z","receivedAt":"2021-05-26T18:33:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> On 26/05/2021 03:53, Felipe Contreras wrote:\n> > Andre Ulrich wrote:\n> >> So the last point is where we still want to do some fine tuning. Right \n> >> now this looks about: my prof fetches my edits and locally checks out \n> >> a branch to compare the changes with git diff.\n> >> But in this diff view you can't edit the files. So you have to \n> >> separately open up another window to edit the changes (lets say my \n> >> prof only wants to keep some of my changes, but not all).\n> > So for example after fetching your changes your professor sees this:\n> \n> Part of Andre's problem was that this diff wasn't stable because the\n> underlying file format is said to be json so items can move around\n> without issue (e.g. key value pairs swapping position) and that they\n> aren't really working on the json file (it may as well be binary..) but\n> on the jupytper notebook display view, so one step removed from the 'diff'.\n\nAndre said they use the diff view, and he wants to be able to edit it.\nNot sure how else would you interpret \"But in this diff view you can't\nedit the files\".\n\n-- \nFelipe Contreras\n"},{"id":"425586","messageId":"6dcc8557-9df4-9ea2-c348-f4ebf76ff446@iee.email","threadId":"55759","inReplyTo":"60ae947797deb_25ba2089c@natae.notmuch","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-26T20:35:42Z","receivedAt":"2021-05-26T20:35:46Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 26/05/2021 19:33, Felipe Contreras wrote:\n> Philip Oakley wrote:\n>> On 26/05/2021 03:53, Felipe Contreras wrote:\n>>> Andre Ulrich wrote:\n>>>> So the last point is where we still want to do some fine tuning. Right \n>>>> now this looks about: my prof fetches my edits and locally checks out \n>>>> a branch to compare the changes with git diff.\n>>>> But in this diff view you can't edit the files. So you have to \n>>>> separately open up another window to edit the changes (lets say my \n>>>> prof only wants to keep some of my changes, but not all).\n>>> So for example after fetching your changes your professor sees this:\n>> Part of Andre's problem was that this diff wasn't stable because the\n>> underlying file format is said to be json so items can move around\n>> without issue (e.g. key value pairs swapping position) and that they\n>> aren't really working on the json file (it may as well be binary..) but\n>> on the jupytper notebook display view, so one step removed from the 'diff'.\n> Andre said they use the diff view, and he wants to be able to edit it.\n> Not sure how else would you interpret \"But in this diff view you can't\n> edit the files\".\n>\nIn\nhttps://lore.kernel.org/git/20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de/\nAbdre did say they used the special jupyter notebook diff viewer.\n\n> ..diffing and merging of notebooks is another story (but we can handle\nthat with nbdime)\n\n[...]\n\n> - my prof reviews the changes and accepts them (if I have done\nacceptable work) So the last point is where we still want to do some\nfine tuning. Right now this looks about: my prof fetches my edits and\nlocally checks out a branch to compare the changes with git diff.\n\n> But in this diff view you can't edit the files. So you have to\nseparately open up another window to edit the changes (lets say my prof\nonly wants to keep some of my changes, but not all).\n\nSo while the notebook format is internally text based json, it's not\nsuitable for real review and editing *in context*, so a different diff\nmechanism is used.\n\nTheir other problem is the splitting apart of the changes, so the\nworktree needs to hold only the staged part of the changes, but with the\nother unstaged changes being restorable.\n\nI'm rather interested in this are as it is a common engineering tool\nworkflow problem.\n\nPhilip\n"},{"id":"425595","messageId":"60aedb22c075e_4bd420896@natae.notmuch","threadId":"55759","inReplyTo":"6dcc8557-9df4-9ea2-c348-f4ebf76ff446@iee.email","subject":"Re: fast forward merge overwriting my code","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-26T23:34:58Z","receivedAt":"2021-05-26T23:35:03Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> On 26/05/2021 19:33, Felipe Contreras wrote:\n> > Philip Oakley wrote:\n> >> On 26/05/2021 03:53, Felipe Contreras wrote:\n> >>> Andre Ulrich wrote:\n> >>>> So the last point is where we still want to do some fine tuning. Right \n> >>>> now this looks about: my prof fetches my edits and locally checks out \n> >>>> a branch to compare the changes with git diff.\n> >>>> But in this diff view you can't edit the files. So you have to \n> >>>> separately open up another window to edit the changes (lets say my \n> >>>> prof only wants to keep some of my changes, but not all).\n> >>> So for example after fetching your changes your professor sees this:\n> >> Part of Andre's problem was that this diff wasn't stable because the\n> >> underlying file format is said to be json so items can move around\n> >> without issue (e.g. key value pairs swapping position) and that they\n> >> aren't really working on the json file (it may as well be binary..) but\n> >> on the jupytper notebook display view, so one step removed from the 'diff'.\n> > Andre said they use the diff view, and he wants to be able to edit it.\n> > Not sure how else would you interpret \"But in this diff view you can't\n> > edit the files\".\n> >\n> In\n> https://lore.kernel.org/git/20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de/\n> Abdre did say they used the special jupyter notebook diff viewer.\n\nYes, but that is a separate issue.\n\nRight now they are able to resolve conflicts with a jupyter mergetool.\nThe tool gets rid of all the extra noise so the user is able to focus\nonly on the actual important changes. When they exit the tool, their\nchanges are properly staged.\n\nThe problem Andre described in [1] appears when mergetool does *not*\nrun. In that case the user is forced to run `git diff` (jupyter difftool\nwill be used), edit the file manually with some viewer, `git add\n--update`, and then run `git diff --cached` to verify the changes.\n\nIn case an unwanted change sneaks by, the user would have to edit the\nfile again, or do `git checkout --patch` to selectively remove chunks\n(and since this tools presents the diffs in reverse, it's\ncounterintuitive and error-prone).\n\nThis is far from ideal.\n\n\nThe problem is that there is no `git stage edit`, in order to launch the\nmergetool.\n\nI just wrote an example `git stage-edit` [2] that does launch the\nmergetool even if there are no merge conflicts, allowing the user to\nmodify the stage directly and with no hassle.\n\nCheers.\n\n[1] https://lore.kernel.org/git/20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@webmail.th-koeln.de/\n[2] https://dpaste.com/62XS8TTXP\n\n-- \nFelipe Contreras\n"},{"id":"425669","messageId":"02bbe080-cd8a-cc7d-5dbc-9231b51c4baf@iee.email","threadId":"55759","inReplyTo":"60aedb22c075e_4bd420896@natae.notmuch","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-27T12:05:12Z","receivedAt":"2021-05-27T12:05:24Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 27/05/2021 00:34, Felipe Contreras wrote:\n> Philip Oakley wrote:\n>> On 26/05/2021 19:33, Felipe Contreras wrote:\n>>> Philip Oakley wrote:\n>>>> On 26/05/2021 03:53, Felipe Contreras wrote:\n>>>>> Andre Ulrich wrote:\n>>>>>> So the last point is where we still want to do some fine tuning. Right \n>>>>>> now this looks about: my prof fetches my edits and locally checks out \n>>>>>> a branch to compare the changes with git diff.\n>>>>>> But in this diff view you can't edit the files. So you have to \n>>>>>> separately open up another window to edit the changes (lets say my \n>>>>>> prof only wants to keep some of my changes, but not all).\n>>>>> So for example after fetching your changes your professor sees this:\n>>>> Part of Andre's problem was that this diff wasn't stable because the\n>>>> underlying file format is said to be json so items can move around\n>>>> without issue (e.g. key value pairs swapping position) and that they\n>>>> aren't really working on the json file (it may as well be binary..) but\n>>>> on the jupytper notebook display view, so one step removed from the 'diff'.\n>>> Andre said they use the diff view, and he wants to be able to edit it.\n>>> Not sure how else would you interpret \"But in this diff view you can't\n>>> edit the files\".\n>>>\n>> In\n>> https://lore.kernel.org/git/20210524061355.Horde.I7EpK9A1l-KtI_TwFo97eNd@webmail.th-koeln.de/\n>> Abdre did say they used the special jupyter notebook diff viewer.\n> Yes, but that is a separate issue.\n>\n> Right now they are able to resolve conflicts with a jupyter mergetool.\n\nI don't believe that (\"resolve\") is true in the sense they would like. I\ndon't think they are really 'merging' in an all-in-one `git merge`\nsense, rather they are [trying to] splitting and patching and commenting\nthe changes.\n\nAside: In my previous employment it just wasn't possible to diff a\ntool's save output (MathCAD, a graphic maths whiteboard) because the\nstructure of their XML file was not conventionally 'linear' -\nrearranging object position on the canvas did not move them in the file,\nyou had to 'guess' (try and visualise) the objects movement and effect\non computational order. It just wasn't worth the effort as the supplier\ndidn't have useful diff tool. I Feel that Jupyter is better than that,\nbut still awkward.\n\n> The tool gets rid of all the extra noise so the user is able to focus\n> only on the actual important changes. When they exit the tool, their\n> changes are properly staged.\n>\n> The problem Andre described in [1] appears when mergetool does *not*\n> run. \n\nHere they are (in my mind) highlighting the GitLab server side merge\nprocess, which only (IIUC) showing the git diff, and not the jupyter\ndiff, meaning they have to fetch and then work in the jupyter tool, not Git.\n\n> In that case the user is forced to run `git diff` (jupyter difftool\n> will be used), edit the file manually with some viewer, `git add\n> --update`, and then run `git diff --cached` to verify the changes.\n\nI'd misremembered the --update option, and it possibly doesn't do what\nthe user expects if they expect just the staged files (rather than all\nthe tracked index files) updated to take on-board their tweaks (i.e. mid\nreview)\n>\n> In case an unwanted change sneaks by, the user would have to edit the\n> file again, or do `git checkout --patch` to selectively remove chunks\n> (and since this tools presents the diffs in reverse, it's\n> counterintuitive and error-prone).\nI'd agree that the whole process for such tools (because they break\nlinear code conventions) is, as you say, \"counter-intuitive and error-prone\"\n>\n> This is far from ideal.\n>\n>\n> The problem is that there is no `git stage edit`, in order to launch the\n> mergetool.\n\nI see it the other way around (I think). I see it as Git getting out of\nthe way for a period and supporting that other tool's review process,\nrather than assuming that the git-way is the-right-way.\n\n> I just wrote an example `git stage-edit` [2] that does launch the\n> mergetool even if there are no merge conflicts, allowing the user to\n> modify the stage directly and with no hassle.\n>\n> Cheers.\n>\n> [1] https://lore.kernel.org/git/20210522154815.Horde.rqiNSyIc3CGJECACotWLO1T@webmail.th-koeln.de/\n> [2] https://dpaste.com/62XS8TTXP\n>\nHopefully, Andre can put a little information about just how the mid\n'merge/review' process actually happens, and the pain points, to avoid\nthe discussion talking in thin air...\n\nThere may be terminology confusion because of the way that *server based\ncooperation* goes via _Pull/Merge Requests_, when really they are\n*Review Requests*, and no one (in that situation) actually expects them\nto be accepted as-is anyway, rather they are 'returned with comments for\nrework' or 'reworked before merge'.\n\nPhilip\n"},{"id":"425675","messageId":"60afa5e07bcd9_2056d2084d@natae.notmuch","threadId":"55759","inReplyTo":"02bbe080-cd8a-cc7d-5dbc-9231b51c4baf@iee.email","subject":"Re: fast forward merge overwriting my code","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-27T14:00:00Z","receivedAt":"2021-05-27T14:00:09Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> On 27/05/2021 00:34, Felipe Contreras wrote:\n> > Yes, but that is a separate issue.\n> >\n> > Right now they are able to resolve conflicts with a jupyter mergetool.\n> \n> I don't believe that (\"resolve\") is true in the sense they would like. I\n> don't think they are really 'merging' in an all-in-one `git merge`\n> sense, rather they are [trying to] splitting and patching and commenting\n> the changes.\n\nHe explicitly mentioned a merge, but ultimately it doesn't matter, the\nmergetool can be used in other scenarios, like `git am`.\n\nI did try to setup those tools, nbdime does setup a merge tool [1].\n\nCheers.\n\n[1] https://nbdime.readthedocs.io/en/latest/\n\n-- \nFelipe Contreras\n"},{"id":"425685","messageId":"90579aaf-2fa6-4641-29e2-43711ccafb86@iee.email","threadId":"55759","inReplyTo":"60afa5e07bcd9_2056d2084d@natae.notmuch","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-27T15:12:41Z","receivedAt":"2021-05-27T15:12:51Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 27/05/2021 15:00, Felipe Contreras wrote:\n> Philip Oakley wrote:\n>> On 27/05/2021 00:34, Felipe Contreras wrote:\n>>> Yes, but that is a separate issue.\n>>>\n>>> Right now they are able to resolve conflicts with a jupyter mergetool.\n>> I don't believe that (\"resolve\") is true in the sense they would like. I\n>> don't think they are really 'merging' in an all-in-one `git merge`\n>> sense, rather they are [trying to] splitting and patching and commenting\n>> the changes.\n> He explicitly mentioned a merge, but ultimately it doesn't matter, the\n> mergetool can be used in other scenarios, like `git am`.\n\nTrue, though I see the server side aspects as also an important part of\nthe process pain.\n>\n> I did try to setup those tools, nbdime does setup a merge tool [1].\n>\n> Cheers.\n>\n> [1] https://nbdime.readthedocs.io/en/latest/\n>\nThanks for that reference. I did like that the picture of the 'problem'\nexample was the same as the nbdime diff's solution ;-) [1]\n\nThe article does give a good start for thinking about the wider diffing\n& merging problems for tools with more complex conceptual 'abstract\nsyntax trees'  and file representations.\n\nPhilip\n[1] https://nbdime.readthedocs.io/en/latest/_images/nbdiff-web.png\n"},{"id":"425899","messageId":"CAJDDKr4GFcV4MSUP+Ku=B1JjZieKwwwuGgsb8yssc0vg0thFQA@mail.gmail.com","threadId":"55759","inReplyTo":"9e6772ba-fee6-7a7f-2ff3-246e82f96ee3@iee.email","subject":"Re: fast forward merge overwriting my code","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2021-05-30T05:31:33Z","receivedAt":"2021-05-30T05:32:15Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, May 24, 2021 at 11:51 AM Philip Oakley wrote:\n>\n> adding Pratyush for the Git Gui stash suggestion..\n> [...]\n> >>> So my Question is: is there any possibility, to be able to view (and\n> >>> even edit, if necessary) the changed notebook in the merging process\n> >>> (as in my example with the 3way merge)?\n> >>\n> >> I'm not aware of such a mechanism (as simply described) but I'm sure\n> >> there are ways to use the \"staging area\" view (e.g. via the Git-gui) to\n> >> selectively pick out hunks and lines that are staged (and non-selected\n> >> hunk/lines stashed) to give a testable worktree during the 'merge'.\n> >\n> > Ah ok, this could be an idea (it would requiere some more research, as\n> > I haven't used the git gui before (I want to learn everything from the\n> > scratch using the command line))\n>\n> I commonly use the Gui when picking apart a large commit into smaller\n> ones when I'm happy that there's no overlaps. Small patches make for\n> easier merging and fault finding, and better commit messages (good\n> thesis practice)\n>\n> > But to be honest, I think even this approach might already be too\n> > cumbersome (as this selectively picking and stashing sounds like a lot\n> > of work itself).\n>\n> Unfortunately the Git Gui doesn't have a menu for stashing remaining\n> changes, but it's simple to flip over to the terminal to stash from\n> there to do the testing, and un-stash the remainder afterwards - I'll\n> maybe suggest the gui could include that capability for these types of\n> workflows (cc Pratyush Yadav ).\n\nTangential, and doesn't apply in this use case, but I should mention\nthat Git Cola[1] has had this feature for a while now.\n\nCola's Stash dialog allows you to do a regular stash and the \"keep\nindex\" stash alluded to here. \"keep index\" retains whatever has\nalready been staged.\n\nOne feature unique to cola is its \"stash the index\" feature, which\nwill only stash stuff that you've selectively staged. That's for the\ncases where you just want to stash away a small bit, and selectively\nchoosing the inverse is a lot of work, so instead you can select just\nthe bits you want to be stashed away and stash 'em.\n\nThere's no shame in using a GUI for interactive editing. Cola is\ndesigned to be driven through keyboard interactions so it's easy to\ninteractively edit the index without having to use a mouse.\n\nCola also has affordances that can make learning core Git easier\n(enable its GIT_COLA_TRACE=1 mode in the environment and it'll print\nout every git command it runs).\n\n[1] https://git-cola.github.io/\n[1] https://github.com/git-cola/git-cola\n\ncheers,\n-- \nDavid\n"},{"id":"425912","messageId":"75d301b3-3cbe-da2e-6611-1bf32a187284@iee.email","threadId":"55759","inReplyTo":"CAJDDKr4GFcV4MSUP+Ku=B1JjZieKwwwuGgsb8yssc0vg0thFQA@mail.gmail.com","subject":"Re: fast forward merge overwriting my code","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2021-05-30T11:00:58Z","receivedAt":"2021-05-30T11:01:02Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 30/05/2021 06:31, David Aguilar wrote:\n> On Mon, May 24, 2021 at 11:51 AM Philip Oakley wrote:\n>> adding Pratyush for the Git Gui stash suggestion..\n>> [...]\n>>>>> So my Question is: is there any possibility, to be able to view (and\n>>>>> even edit, if necessary) the changed notebook in the merging process\n>>>>> (as in my example with the 3way merge)?\n>>>> I'm not aware of such a mechanism (as simply described) but I'm sure\n>>>> there are ways to use the \"staging area\" view (e.g. via the Git-gui) to\n>>>> selectively pick out hunks and lines that are staged (and non-selected\n>>>> hunk/lines stashed) to give a testable worktree during the 'merge'.\n>>> Ah ok, this could be an idea (it would requiere some more research, as\n>>> I haven't used the git gui before (I want to learn everything from the\n>>> scratch using the command line))\n>> I commonly use the Gui when picking apart a large commit into smaller\n>> ones when I'm happy that there's no overlaps. Small patches make for\n>> easier merging and fault finding, and better commit messages (good\n>> thesis practice)\n>>\n>>> But to be honest, I think even this approach might already be too\n>>> cumbersome (as this selectively picking and stashing sounds like a lot\n>>> of work itself).\n>> Unfortunately the Git Gui doesn't have a menu for stashing remaining\n>> changes, but it's simple to flip over to the terminal to stash from\n>> there to do the testing, and un-stash the remainder afterwards - I'll\n>> maybe suggest the gui could include that capability for these types of\n>> workflows (cc Pratyush Yadav ).\n> Tangential, and doesn't apply in this use case, but I should mention\n> that Git Cola[1] has had this feature for a while now.\n\n+1. I haven't used/tried Cola myself, so..\n\n>\n> Cola's Stash dialog allows you to do a regular stash and the \"keep\n> index\" stash alluded to here. \"keep index\" retains whatever has\n> already been staged.\n>\n> One feature unique to cola is its \"stash the index\" feature, which\n> will only stash stuff that you've selectively staged. That's for the\n> cases where you just want to stash away a small bit, and selectively\n> choosing the inverse is a lot of work, so instead you can select just\n> the bits you want to be stashed away and stash 'em.\n\nSounds good.\nWhen I did a quick test (Git-Gui & cli) with staging one line of a two\nline change and then stashing, I found that the stash pop failed with a\nconflict (your 'lot of work') which I hadn't expected, which to me is\ntotally wrong (against the spirit of the stash command).\n\n>\n> There's no shame in using a GUI for interactive editing. Cola is\n> designed to be driven through keyboard interactions so it's easy to\n> interactively edit the index without having to use a mouse.\n>\n> Cola also has affordances that can make learning core Git easier\n> (enable its GIT_COLA_TRACE=1 mode in the environment and it'll print\n> out every git command it runs).\n>\n> [1] https://git-cola.github.io/\n> [1] https://github.com/git-cola/git-cola\n>\n> cheers,\nThanks\n"}]}