Re: interactive rebase should better highlight the not-applying commit

[Joshua N Pritikin <jpritikin@pobox.com>]

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 <jpritikin@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?

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 <jpritikin@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?

Also, I have another wishlist item for (interactive) rebase. 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. 
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.

Thank you.

-- 
Joshua N. Pritikin, Ph.D.
Virginia Institute for Psychiatric and Behavioral Genetics
Virginia Commonwealth University
PO Box 980126
800 E Leigh St, Biotech One, Suite 1-133
Richmond, VA 23219
http://people.virginia.edu/~jnp3bc