Pieter Praet <[email protected]> writes: >> [...] Rewriting >> must start below the commit over which magit-rewrite-start is >> invoked, otherwise you can't directly include the first unpushed >> commit in the commits to be rewritten. > > Correct me if I'm wrong, but (as of commit 2d29228a) absolutely nothing > is preventing you from rewriting the first unpushed commit (unless it's > commit 0, which was prevented pre-14fdc8dc as well). > > This does however require a little change of habit, i.e. using the last > pushed commit (as opposed to the first unpushed commit) as base, thus > treating the term "base" according to its correct semantic meaning.
> Exactly the way rebasing works. Nothing ultimately prevents me from doing that, but this change makes it so difficult (simple point and shoot in the status buffer is not enough, I have to write the base (with completion, but still) or open the log buffer, move over the base and then hit 'r b RET') that it is not acceptable. This is on a critical path in my Magit use every day.[1] Consistency comes second in my view and if documentation erroneously talks about a base when base is not the right word, then I'd rather fix the documentation instead of changing the behaviour which has existed a long time and which has not been complained about (at least not vocally enough for me to notice). Of course, if there are ideas on how to nail your problem without this consequence, I'm all ears (which doesn't necessarily mean that I won't propose reverting your changes until someone implements such an idea). I have considered stuff like having a small log section of pushed commits below the unpushed ones or making magit-rewrite-start default to the last pushed commit when not over any commit but I wouldn't be happy with at least the latter one (even if such defaulting made sense, I'd nevertheless like to make it possible for users to actually point at the relevants commits, just like before). I find the idea of pushed commits log section tempting because it could be useful for other purposes as well but I don't know how others feel about adding more stuff to the status buffer. [1] In fact, even before this change rewriting is not as convenient as it could be and I'm contemplating features such as amending commits other than the last, reordering and squashing commits by simply cut and pasting lines in the status buffer (without having to explicitly start rewriting), editing commit messages and maybe even commit diffs directly in status and commit buffers in the spirit of wdired. PJ Weisberg <[email protected]> writes: > On Mon, May 2, 2011 at 7:32 AM, Pieter Praet <[email protected]> wrote: > > Depends on the bug, really. There's a problem on Windows that I'm > aware of, which I meant to look into, but since I don't run into it > often it's slipped my mind. It would have been better to keep it in > the bug tracker on the website instead of the one in my head. :-/ I try to report bugs for which I don't have commits staring at me in the unpushed commits section in my magit repository. -- Hannu
