{"thread":{"id":"44278","subject":"interactive rebase should better highlight the not-applying commit","startedAt":"2016-10-11T19:25:21Z","lastAt":"2016-10-13T10:40:23Z","messageCount":8,"participants":["Joshua N Pritikin","Stefan Beller","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"303912","messageId":"20161011190745.w2asu6eoromkrccu@droplet","threadId":"44278","inReplyTo":null,"subject":"interactive rebase should better highlight the not-applying commit","fromName":"Joshua N Pritikin","fromEmail":"jpritikin@pobox.com","sentAt":"2016-10-11T19:07:45Z","receivedAt":"2016-10-11T19:25:21Z","isPatch":false,"sender":{"key":"jpritikin@pobox.com","avatar":"https://gravatar.com/avatar/3f2561fdd7efac4e127dc65ac7e06f044069c115dcc94d0ac540f4126d47759d?d=mp&s=160"},"body":"As of GIT 2.8.1, if you do an interactive rebase and get some conflict \nin the stack of patches then the commit with the conflict is buried in \n4-5 lines of output. It is visually difficult to immediately pick out \nwhich commit did not apply cleanly. I suggest highlighting the 1 line \ncommit summary in red or green or some color to help it stand out from \nall the other output.\n\nI decided to suggest this change after I realized that I probably \nskipped a commit during an interactive rebase instead of resolving the \nconflict. I knew I had to skip some commit so I assumed that I just need \nto skip without reading the commit summary carefully. Now it is 7-15 \ndays after I did the erroneous rebase. I had to spend a few hours today \nwith GIT's archaeology tools to find the lost code.\n\nI assume somebody familiar with GIT's code base could make this change \nin about 10 minutes.\n\n-- \nJoshua N. Pritikin, Ph.D.\nVirginia Institute for Psychiatric and Behavioral Genetics\nVirginia Commonwealth University\nPO Box 980126\n800 E Leigh St, Biotech One, Suite 1-133\nRichmond, VA 23219\nhttp://people.virginia.edu/~jnp3bc\n"},{"id":"303926","messageId":"CAGZ79kYg3sZ42W-PEE7MgCDvt_h7hEQ7KWZsVKMb3DY=x5VK+w@mail.gmail.com","threadId":"44278","inReplyTo":"20161011190745.w2asu6eoromkrccu@droplet","subject":"Re: interactive rebase should better highlight the not-applying commit","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-11T20:55:22Z","receivedAt":"2016-10-11T21:02:47Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> I assume somebody familiar with GIT's code base could make this change\n> in about 10 minutes.\n\nCan you elaborate how you come to that estimate?\n"},{"id":"303930","messageId":"CAGZ79kZSQx7aOCgQ2dwzJeCLX-k-+x1SKabEBG7CktNfeXAbvg@mail.gmail.com","threadId":"44278","inReplyTo":"20161011190745.w2asu6eoromkrccu@droplet","subject":"Re: interactive rebase should better highlight the not-applying commit","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-10-11T21:25:19Z","receivedAt":"2016-10-11T21:26:30Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> As of GIT 2.8.1, if you do an interactive rebase and get some conflict\n> in the stack of patches then the commit with the conflict is buried in\n> 4-5 lines of output. It is visually difficult to immediately pick out\n> which commit did not apply cleanly. I suggest highlighting the 1 line\n> commit summary in red or green or some color to help it stand out from\n> all the other output.\n>\n> I decided to suggest this change after I realized that I probably\n> skipped a commit during an interactive rebase instead of resolving the\n> conflict. I knew I had to skip some commit so I assumed that I just need\n> to skip without reading the commit summary carefully. Now it is 7-15\n> days after I did the erroneous rebase. I had to spend a few hours today\n> with GIT's archaeology tools to find the lost code.\n>\n\nLooking at the actual code, this is not as easy as one might assume,\nbecause rebase is written in shell. (One of the last remaining large commands\nin shell), and there is no color support in the die(..) function.\n\nHowever IIUC currently rebase is completely rewritten/ported to C where it is\neasier to add color support as we do have some color support in there already.\n"},{"id":"303986","messageId":"20161012132740.dvyofl36qtualxgk@droplet","threadId":"44278","inReplyTo":"CAGZ79kZSQx7aOCgQ2dwzJeCLX-k-+x1SKabEBG7CktNfeXAbvg@mail.gmail.com","subject":"Re: interactive rebase should better highlight the not-applying commit","fromName":"Joshua N Pritikin","fromEmail":"jpritikin@pobox.com","sentAt":"2016-10-12T13:27:40Z","receivedAt":"2016-10-12T13:27:49Z","isPatch":false,"sender":{"key":"jpritikin@pobox.com","avatar":"https://gravatar.com/avatar/3f2561fdd7efac4e127dc65ac7e06f044069c115dcc94d0ac540f4126d47759d?d=mp&s=160"},"body":"On Tue, Oct 11, 2016 at 01:55:22PM -0700, Stefan Beller wrote:\n> On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> > I assume somebody familiar with GIT's code base could make this change\n> > in about 10 minutes.\n>\n> Can you elaborate how you come to that estimate?\n\nHm, a false belief in the general awesomeness of GIT developers?\n\nOn Tue, Oct 11, 2016 at 02:25:19PM -0700, Stefan Beller wrote:\n> On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> > As of GIT 2.8.1, if you do an interactive rebase and get some conflict\n> > in the stack of patches then the commit with the conflict is buried in\n> > 4-5 lines of output. It is visually difficult to immediately pick out\n> > which commit did not apply cleanly. I suggest highlighting the 1 line\n> > commit summary in red or green or some color to help it stand out from\n> > all the other output.\n> >\n> > I decided to suggest this change after I realized that I probably\n> > skipped a commit during an interactive rebase instead of resolving the\n> > conflict. I knew I had to skip some commit so I assumed that I just need\n> > to skip without reading the commit summary carefully. Now it is 7-15\n> > days after I did the erroneous rebase. I had to spend a few hours today\n> > with GIT's archaeology tools to find the lost code.\n> \n> Looking at the actual code, this is not as easy as one might assume, \n> because rebase is written in shell. (One of the last remaining large \n> commands in shell), and there is no color support in the die(..) \n> function.\n\nI'm sorry to hear that.\n\n> However IIUC currently rebase is completely rewritten/ported to C \n> where it is easier to add color support as we do have some color \n> support in there already.\n\nSounds great. Is there a beta release that I can try out?\n\nAlso, I have another wishlist item for (interactive) rebase. Sometimes I \ndo a rebase to fix some tiny thing 10-15 commits from HEAD. Maybe only 1 \nfile is affected and there are no merge conflicts, but when rebase \nreapplies all the commits, the timestamps of lots of unmodified files \nchange even though they are unmodified compared to before the rebase. \nSince the modification times are used by 'make' to compute dependencies, \nthis creates a lot of useless recompilation that slows things down. It \nwould be great if rebase only changed the timestamps of files that were \nactually modified.\n\nThank you.\n\n-- \nJoshua N. Pritikin, Ph.D.\nVirginia Institute for Psychiatric and Behavioral Genetics\nVirginia Commonwealth University\nPO Box 980126\n800 E Leigh St, Biotech One, Suite 1-133\nRichmond, VA 23219\nhttp://people.virginia.edu/~jnp3bc\n"},{"id":"304003","messageId":"alpine.DEB.2.20.1610121811250.197091@virtualbox","threadId":"44278","inReplyTo":"CAGZ79kYg3sZ42W-PEE7MgCDvt_h7hEQ7KWZsVKMb3DY=x5VK+w@mail.gmail.com","subject":"Re: interactive rebase should better highlight the not-applying commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-10-12T16:14:18Z","receivedAt":"2016-10-12T16:14:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Stefan,\n\nOn Tue, 11 Oct 2016, Stefan Beller wrote:\n\n> On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> > I assume somebody familiar with GIT's code base could make this change\n> > in about 10 minutes.\n> \n> Can you elaborate how you come to that estimate?\n\nWhy do you ask? He obviously has \"a very good brain\" ;-)\n\nSeriously again, Git's source code is not that hard to read, and the Git\ndeveloper community is pretty helpful when anybody asks for pointers what\ncode to change.\n\nHaving said that, I did reimplement some parts of the shell script that is\ngit-rebase--interactive.sh [*1*] in C and am in the process of getting\nthose integrated into the next (or hopefully not a *much* later) version\nof Git.\n\nSo what I'd like to see is an *exact* copy-paste of a message in question,\nand a *concrete* proposal how it should look like instead.\n\nCiao,\nJohannes\n\nFootnote *1*:\nhttps://github.com/git/git/blob/master/git-rebase--interactive.sh\n"},{"id":"304006","messageId":"alpine.DEB.2.20.1610121815160.197091@virtualbox","threadId":"44278","inReplyTo":"20161012132740.dvyofl36qtualxgk@droplet","subject":"Re: interactive rebase should better highlight the not-applying commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-10-12T16:24:37Z","receivedAt":"2016-10-12T16:24:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Joshua,\n\nOn Wed, 12 Oct 2016, Joshua N Pritikin wrote:\n\n> On Tue, Oct 11, 2016 at 01:55:22PM -0700, Stefan Beller wrote:\n> > On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> > > I assume somebody familiar with GIT's code base could make this\n> > > change in about 10 minutes.\n> >\n> > Can you elaborate how you come to that estimate?\n> \n> Hm, a false belief in the general awesomeness of GIT developers?\n\nNo, a false belief in your own shortcomings, as you thought it would be\neasier to address your wishes for somebody else than you.\n\n> On Tue, Oct 11, 2016 at 02:25:19PM -0700, Stefan Beller wrote:\n> > On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> > > As of GIT 2.8.1, if you do an interactive rebase and get some conflict\n> > > in the stack of patches then the commit with the conflict is buried in\n> > > 4-5 lines of output. It is visually difficult to immediately pick out\n> > > which commit did not apply cleanly. I suggest highlighting the 1 line\n> > > commit summary in red or green or some color to help it stand out from\n> > > all the other output.\n> > >\n> > > I decided to suggest this change after I realized that I probably\n> > > skipped a commit during an interactive rebase instead of resolving the\n> > > conflict. I knew I had to skip some commit so I assumed that I just need\n> > > to skip without reading the commit summary carefully. Now it is 7-15\n> > > days after I did the erroneous rebase. I had to spend a few hours today\n> > > with GIT's archaeology tools to find the lost code.\n> > \n> > Looking at the actual code, this is not as easy as one might assume, \n> > because rebase is written in shell. (One of the last remaining large \n> > commands in shell), and there is no color support in the die(..) \n> > function.\n> \n> I'm sorry to hear that.\n> \n> > However IIUC currently rebase is completely rewritten/ported to C \n> > where it is easier to add color support as we do have some color \n> > support in there already.\n> \n> Sounds great. Is there a beta release that I can try out?\n\nThere is no release as such, unless you count Git for Windows v2.10.0.\n\nBut you can try the `interactive-rebase` branch of\nhttps://github.com/dscho/git; please note, though, that my main aim was to\nbe as faithful as possible in the conversion (modulo speed, of course).\n\n> Also, I have another wishlist item for (interactive) rebase.\n\nHmm. You know, I cannot say that I am a fan of wishlists for Git, unless\nthe originator of said wishlist takes on their responsibility as an Open\nSource user to make their wishes come true.\n\nBut maybe I read it all wrong and you do want to make this happen\nyourself, and you simply want a little advice how to go about it?\n\n> Sometimes I do a rebase to fix some tiny thing 10-15 commits from HEAD.\n> Maybe only 1 file is affected and there are no merge conflicts, but when\n> rebase reapplies all the commits, the timestamps of lots of unmodified\n> files change even though they are unmodified compared to before the\n> rebase.\n\nWell, they *were* modified, right?\n\nA workaround would be to create a new worktree using the awesome `git\nworktree` command, perform the rebase there (on an unnamed branch -- AKA\n\"detached HEAD\", no relation to Helloween), and then come back to the\noriginal worktree and reset --hard to the new revision. That reset would\ndetect that there are actually no changes required to said files.\n\n> Since the modification times are used by 'make' to compute dependencies, \n> this creates a lot of useless recompilation that slows things down. It \n> would be great if rebase only changed the timestamps of files that were \n> actually modified.\n\nRebase will always have to change those timestamps. Because it really\nchanges those files. So the mtimes *need* to be updated. As far as rebase\nis concerned, it does not matter that the final contents are identical to\n*some* previous version...\n\nCiao,\nJohannes\n"},{"id":"304012","messageId":"20161012170207.lapdv5h5aws4k4pw@droplet","threadId":"44278","inReplyTo":"alpine.DEB.2.20.1610121815160.197091@virtualbox","subject":"Re: interactive rebase should better highlight the not-applying commit","fromName":"Joshua N Pritikin","fromEmail":"jpritikin@pobox.com","sentAt":"2016-10-12T17:02:07Z","receivedAt":"2016-10-12T17:06:10Z","isPatch":false,"sender":{"key":"jpritikin@pobox.com","avatar":"https://gravatar.com/avatar/3f2561fdd7efac4e127dc65ac7e06f044069c115dcc94d0ac540f4126d47759d?d=mp&s=160"},"body":"On Wed, Oct 12, 2016 at 06:24:37PM +0200, Johannes Schindelin wrote:\n> No, a false belief in your own shortcomings, as you thought it would be\n> easier to address your wishes for somebody else than you.\n\nAh, shucks, I guess I could jump in.\n\n> But maybe I read it all wrong and you do want to make this happen\n> yourself, and you simply want a little advice how to go about it?\n\nUgh, if you insist. You really know how to hold someone's feet to the \nfire, eh?\n\n> > On Tue, Oct 11, 2016 at 02:25:19PM -0700, Stefan Beller wrote:\n> > > On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> > > However IIUC currently rebase is completely rewritten/ported to C \n> > > where it is easier to add color support as we do have some color \n> > > support in there already.\n> > \n> > Sounds great. Is there a beta release that I can try out?\n> \n> There is no release as such, unless you count Git for Windows v2.10.0.\n\nNope, that doesn't count. ;-)\n\n> But you can try the `interactive-rebase` branch of\n> https://github.com/dscho/git; please note, though, that my main aim was to\n> be as faithful as possible in the conversion (modulo speed, of course).\n\nHm OK\n\n> > Sometimes I do a rebase to fix some tiny thing 10-15 commits from HEAD.\n> > Maybe only 1 file is affected and there are no merge conflicts, but when\n> > rebase reapplies all the commits, the timestamps of lots of unmodified\n> > files change even though they are unmodified compared to before the\n> > rebase.\n> \n> Well, they *were* modified, right?\n\nWere they? Isn't that just an artefact of the implementation?\n\n> A workaround would be to create a new worktree using the awesome `git\n> worktree` command, perform the rebase there (on an unnamed branch -- AKA\n> \"detached HEAD\", no relation to Helloween), and then come back to the\n> original worktree and reset --hard to the new revision. That reset would\n> detect that there are actually no changes required to said files.\n\nWhat would be the problem with doing this by default? Or could it be a \nconfiguration option that can be enabled?\n\n-- \nJoshua N. Pritikin, Ph.D.\nVirginia Institute for Psychiatric and Behavioral Genetics\nVirginia Commonwealth University\nPO Box 980126\n800 E Leigh St, Biotech One, Suite 1-133\nRichmond, VA 23219\nhttp://people.virginia.edu/~jnp3bc\n"},{"id":"304069","messageId":"alpine.DEB.2.20.1610131230370.197091@virtualbox","threadId":"44278","inReplyTo":"20161012170207.lapdv5h5aws4k4pw@droplet","subject":"Re: interactive rebase should better highlight the not-applying commit","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-10-13T10:40:05Z","receivedAt":"2016-10-13T10:40:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Joshua,\n\nOn Wed, 12 Oct 2016, Joshua N Pritikin wrote:\n\n> On Wed, Oct 12, 2016 at 06:24:37PM +0200, Johannes Schindelin wrote:\n> \n> > But maybe I read it all wrong and you do want to make this happen\n> > yourself, and you simply want a little advice how to go about it?\n> \n> Ugh, if you insist.\n\nI don't. If you want that feature to see the light of day, you should\ninsist yourself ;-)\n\n> > > On Tue, Oct 11, 2016 at 02:25:19PM -0700, Stefan Beller wrote:\n> > > > On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:\n> > > > However IIUC currently rebase is completely rewritten/ported to C \n> > > > where it is easier to add color support as we do have some color \n> > > > support in there already.\n> > > \n> > > Sounds great. Is there a beta release that I can try out?\n> > \n> > There is no release as such, unless you count Git for Windows v2.10.0.\n> \n> Nope, that doesn't count. ;-)\n\nSometimes honesty goes too far. You basically told me that what I work on\ndoes not count. That does not exactly curry my favor.\n\n> > But you can try the `interactive-rebase` branch of\n> > https://github.com/dscho/git; please note, though, that my main aim\n> > was to be as faithful as possible in the conversion (modulo speed, of\n> > course).\n> \n> Hm OK\n> \n> > > Sometimes I do a rebase to fix some tiny thing 10-15 commits from HEAD.\n> > > Maybe only 1 file is affected and there are no merge conflicts, but when\n> > > rebase reapplies all the commits, the timestamps of lots of unmodified\n> > > files change even though they are unmodified compared to before the\n> > > rebase.\n> > \n> > Well, they *were* modified, right?\n> \n> Were they? Isn't that just an artefact of the implementation?\n\nYes, they were modified, as the todo script you saved for the interactive\nrebase to perform told it to cherry-pick those changes. That is a worktree\noperation, performing on files, not a repository operation working on\nobjects in Git's database.\n\n> > A workaround would be to create a new worktree using the awesome `git\n> > worktree` command, perform the rebase there (on an unnamed branch --\n> > AKA \"detached HEAD\", no relation to Helloween), and then come back to\n> > the original worktree and reset --hard to the new revision. That reset\n> > would detect that there are actually no changes required to said\n> > files.\n> \n> What would be the problem with doing this by default? Or could it be a\n> configuration option that can be enabled?\n\nIt could definitely be a new feature that is triggered by a new (opt-in)\nconfiguration option.\n\nIt cannot be on by default, at least not in the short run, because those\ncherry-picks can fail with merge conflicts and power users of the\ninteractive rebase expect those conflicts to show in the current worktree.\n\nCiao,\nJohannes\n"}]}