Hi Joshua, On Wed, 12 Oct 2016, Joshua N Pritikin wrote:
> On Wed, Oct 12, 2016 at 06:24:37PM +0200, Johannes Schindelin wrote: > > > 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? > > Ugh, if you insist. I don't. If you want that feature to see the light of day, you should insist yourself ;-) > > > 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: > > > > 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. > > Nope, that doesn't count. ;-) Sometimes honesty goes too far. You basically told me that what I work on does not count. That does not exactly curry my favor. > > 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). > > Hm OK > > > > 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? > > Were they? Isn't that just an artefact of the implementation? Yes, they were modified, as the todo script you saved for the interactive rebase to perform told it to cherry-pick those changes. That is a worktree operation, performing on files, not a repository operation working on objects in Git's database. > > 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. > > What would be the problem with doing this by default? Or could it be a > configuration option that can be enabled? It could definitely be a new feature that is triggered by a new (opt-in) configuration option. It cannot be on by default, at least not in the short run, because those cherry-picks can fail with merge conflicts and power users of the interactive rebase expect those conflicts to show in the current worktree. Ciao, Johannes
