On Tue, 03 May 2011 19:19:48 +0300, Hannu Koivisto <[email protected]> wrote: > 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 explains alot. I can totally relate to your irritation now. This was way off my radar since I always start rewrite/rebase ops from the log buffer (with -al option) as it provides a more expansive overview, but I definitely see the merit in doing this from the status buffer. > [...] 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). Since my pull request was accepted, I assumed the community agreed on the issue. Judging by the sudden attention this discussion has attracted, it appears that that wasn't entirely the case. How about if we first push patches (or links to the relevant commits on github) to the mailing list for public scrutiny, and merges are postponed until eg. two or more "old-timers" sign off on it ? > 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). [...] Well, I'd like to think it shouldn't be an either-or story. Sane defaults + Insane customizability = great UX (if done right). I'll be attaching a patch shortly, which makes magit default to the previous behaviour but provides a little leg-room as well. > [...] 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. It could indeed be very useful to show the last n pushed commit(s) in the status buffer. No need to do it by default though. customize-mode (horrid as it is) still has its raison d'être. > [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. Although it's already a great pleasure to work with, there is indeed always room for improvement in regards of UI friction. But... since some of the ops you mention can be pretty invasive (with potentially disastrous results), it would be more than desirable to (optionally :) require explicitly starting a rewrite, if only to trigger a mental context switch. Freedom should always predominate security, but convenience? Convenience more often than not leads to landfills :( > 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 > Peace -- Pieter
