[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] A vision on rebase
|
I like this approach, +1 from me. From the time when I started working
on JGit thought that a nice support for interactive rebase could be
one of the features which could make me use EGit instead of
command-line git for daily work. Using Drag-and-Drop on commit nodes
to shape the history like I want would be really cool. I suggest to
support the delete Button on commits (to skip certain commits on the
new planned branch) and the insert button (to insert new commits
between those which I drag&drop
On Mon, Sep 24, 2012 at 7:55 AM, Robin Rosenberg
<robin.rosenberg@xxxxxxxxxx> wrote:
>
> Now the user drags "fix c" to HEAD, signifying that he wants to reorder
> the commits. EGit rewires the graph after checking for branches
How do you think to represent "git rebase -i --onto branchX HEAD~2" if
you want to move the last two commits onto a new branch? Select "fix
b" and drag it onto branchX, or?
> A new planned branch appears in the history view.
>
> Øpick fix c'
> Øpick fix a'
> o fix a |
> | Øpick fix b'
> o fix b |
> o fix c |
> o fix d ----´
> |
I think there is a formatting problem in this ascii-art. In you mail
'Øpick fix a'' started in the same column as 'fix a' but I guess it
should be rendered horizontally aligned to the other commits on the
planned branch, right?
> In addition the user should be able to copy-paste (i.e. cherry-pick) any
> commit into the planned branch, delete, edit and so on.
Drag&Drop also allowed, or? Maybe even dragging-and-dropping of
multiple commits. Multi-Select the last 10 commits of branch XYZ and
move them into my new planned branch.
> The user would also be able to immediately get feedback on conflict that
> would appear from the proposed edits.
I am not sure about this feature. You describe later how conflict
resolutions can influence whether there are conflicts on subsequent
commits. That makes this feature not so reliable. For me it would be
no problem if this feature is not in the first version of the
graphical interactive rebase.
> During rebase the view would be updated so the user sees how much of the
> work has actually been performed.
That's a feature I really like. My biggest problem with command-line
interactive rebase is to find out in which state the current process
is.
> The visual effect of this related to EGit, but I think JGit would be the
> logical place for some of the logic beyonds the traditional rebase. E.g.
+1
Ciao
Chris
