Re: [PATCH] rebase -i -p: use rerere to resolve conflicts if enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Kilzer <ddkilzer@xxxxxxxxxx> writes:

> + Johannes Schindelin  [sorry, should have added you at the beginning of the thread]

Side note: Dscho, I do not mind hearing from you from time to time,
but if the only reason David summoned you is because I mentioned
t4200 and your name appears at the beginning of that file, and
unless you are interested in rerere.autoupdate yourself, I am fine
if you to treat this thread as low priority.  Your code in t4200
does not have much to do with rerere.autoupdate which this
discussion thread is about.

I vaguely recall doing the 5-patch series that ends with 121c813
(rerere.autoupdate, 2008-06-22) after somebody asked if there is a
way to tell paths that have been resolved by rerere already and
paths that still need to be sorted out manually (back then I think
we had "rerere status" but not "rerere remaining"), so that "git
ls-files -u" can be a more useful command to find out which paths
need further work, but I do not seem to be able to find the thread.
I also think that somebody was a regular in the kernel mailing list,
but I do not remember the details.  Hopefully somebody with better
research skills (or better memory) than I have can help digging the
context up for us ;-).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]