Hi Joshua, On Wed, 12 Oct 2016, Joshua N Pritikin wrote:
> On Tue, Oct 11, 2016 at 01:55:22PM -0700, Stefan Beller wrote: > > On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin <jpriti...@pobox.com> > > wrote: > > > I assume somebody familiar with GIT's code base could make this > > > change in about 10 minutes. > > > > Can you elaborate how you come to that estimate? > > Hm, a false belief in the general awesomeness of GIT developers? No, a false belief in your own shortcomings, as you thought it would be easier to address your wishes for somebody else than you. > On Tue, Oct 11, 2016 at 02:25:19PM -0700, Stefan Beller wrote: > > On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin <jpriti...@pobox.com> > > wrote: > > > As of GIT 2.8.1, if you do an interactive rebase and get some conflict > > > in the stack of patches then the commit with the conflict is buried in > > > 4-5 lines of output. It is visually difficult to immediately pick out > > > which commit did not apply cleanly. I suggest highlighting the 1 line > > > commit summary in red or green or some color to help it stand out from > > > all the other output. > > > > > > I decided to suggest this change after I realized that I probably > > > skipped a commit during an interactive rebase instead of resolving the > > > conflict. I knew I had to skip some commit so I assumed that I just need > > > to skip without reading the commit summary carefully. Now it is 7-15 > > > days after I did the erroneous rebase. I had to spend a few hours today > > > with GIT's archaeology tools to find the lost code. > > > > Looking at the actual code, this is not as easy as one might assume, > > because rebase is written in shell. (One of the last remaining large > > commands in shell), and there is no color support in the die(..) > > function. > > I'm sorry to hear that. > > > However IIUC currently rebase is completely rewritten/ported to C > > where it is easier to add color support as we do have some color > > support in there already. > > Sounds great. Is there a beta release that I can try out? There is no release as such, unless you count Git for Windows v2.10.0. But you can try the `interactive-rebase` branch of https://github.com/dscho/git; please note, though, that my main aim was to be as faithful as possible in the conversion (modulo speed, of course). > Also, I have another wishlist item for (interactive) rebase. Hmm. You know, I cannot say that I am a fan of wishlists for Git, unless the originator of said wishlist takes on their responsibility as an Open Source user to make their wishes come true. But maybe I read it all wrong and you do want to make this happen yourself, and you simply want a little advice how to go about it? > Sometimes I do a rebase to fix some tiny thing 10-15 commits from HEAD. > Maybe only 1 file is affected and there are no merge conflicts, but when > rebase reapplies all the commits, the timestamps of lots of unmodified > files change even though they are unmodified compared to before the > rebase. Well, they *were* modified, right? A workaround would be to create a new worktree using the awesome `git worktree` command, perform the rebase there (on an unnamed branch -- AKA "detached HEAD", no relation to Helloween), and then come back to the original worktree and reset --hard to the new revision. That reset would detect that there are actually no changes required to said files. > Since the modification times are used by 'make' to compute dependencies, > this creates a lot of useless recompilation that slows things down. It > would be great if rebase only changed the timestamps of files that were > actually modified. Rebase will always have to change those timestamps. Because it really changes those files. So the mtimes *need* to be updated. As far as rebase is concerned, it does not matter that the final contents are identical to *some* previous version... Ciao, Johannes
