Re: [egit-dev] Editing a file several revisions back

[Alex Blewitt <alex.blewitt@xxxxxxxxx>]

For reordering commits, I agree that using the history view and supporting a drag-and-drop between nodes would be the most intuitive from a user’s perspective. (I seem to remember making the same suggestion but having others disagree on that last time it came around).

If the drag-and-drop approach was there, then a commit to the end (possibly with ‘squash’) and then a drag-to-the-right-place would probably be very easy to do the process below. The only additional thing would be to find out what the original line/where the bug was introduced but if the quick diff view is on then it would be fairly simple (though you’d have to recall the commit and then find it in the history).

Being able to right-click on the quick diff annotation might be a way of short-circuiting that.

Alex

On 23 Nov 2013, at 21:20, Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote:

> There was a discussion a while ago in some forum (can't recall where) with different opinions.
> 
> My vision is to reuse the history view and allow the user to just drag the revisions to the
> order s?he wants. Egit can calculate expected conflict even before the rebase starts. 
> Seeing ungit make me even more convinced that direct manipulation is the right approach rather 
> than introducing another view. It might be that the history view need to be
> redesigned completely for the integration to work. That said, I don't have a patch,
> so the honor goes to the one that actually does something about it.
> 
> Other than that I'm not very happy with EGit in the current incarnation. Git operations are spread 
> out all over the place and almost everything is called something non-gitish so it does not work well as a
> learning tool using it is slower than using the command line. That's not becuase EGit itself
> is slower, which it is, but only very little. The overhead is in navigating to the operations
> and remembering there the operation is. Compare this with pressing the up-arrow to recall a
> previous command and editing it slightly. Most git operations are like this.
> 
> A Gui should be much _easier_ to use than the CLI. There is a thread on the GitML list about Git gui's. 
> That's where I learned about ungit btw from Junio's post.
> 
> -- robin
> 
> ----- Ursprungligt meddelande -----
>> Från: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
>> Till: "EGit developer discussion" <egit-dev@xxxxxxxxxxx>
>> Skickat: lördag, 23 nov 2013 20:12:40
>> Ämne: [egit-dev] Editing a file several revisions back
>> 
>> I’ve been finding I’ve been needing to do a certain set of actions recently
>> and a pattern is beginning to emerge.
>> 
>> When I’m working locally (or proposing a set of changes to Gerrit) I often
>> find that I need to make a change two or three commits back.
>> 
>> Right now this involves:
>> 
>> - stashing any changes
>> - interactive rebase to the commit where the fix needs to be made
>> - editing the file to make the fix
>> - commit amending
>> - rebase continuing
>> - unstashing any changes
>> 
>> All of the times I’ve needed to do this, the file I’m editing is in the
>> workspace/current git history.
>> 
>> Although the EGit interactive rebase will allow me to do this in the IDE
>> instead of the command line, I can’t help but think this operation may be
>> fairly common and an option to allow an edit to a single file in history
>> would be useful to others. In particular, when I do this I’m fixing a bug on
>> one line, and invariably that line is the one that introduced the problem.
>> 
>> So I envisage an option where you can right-click on a line in the IDE and do
>> ‘Edit past version’, where it prompts with a set of revisions from git log
>> for that file (defaulting to the last commit for that line as shown by ‘git
>> blame’), followed by an editing window that allows that file to be edited,
>> and upon ‘save’ performs the rebase. Although this might be best done by
>> resetting the project as a whole, in fact this operation might be so self
>> contained that the workspace doesn’t need to be updated until the operation
>> is complete.
>> 
>> Recovery for this could drop into the standard rebase workflow or throw an
>> error.
>> 
>> What do others think?
>> 
>> Alex
>> _______________________________________________
>> egit-dev mailing list
>> egit-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/egit-dev
>>