`git: rebase` about gitsavvy HOT 32 CLOSED

@baer - you're a heavy rebase user, yes? Would you mind describing your workflow? I'd like to see if I could support it in GitSavvy.

from gitsavvy.

Sure! My typical workflow is the following

// make sure I'm on my edge branch
git checkout develop
// create a feature branch
git checkout -b feature/my-shiny-new-thing
// make a bunch of commits
...
git rebase -i develop
git checkout develop
git merge feature/my-shiny-new-thing

I rebase nearly every time I sit down to do new work (unless the branch is shared) in place of merging develop back into my branch.

When I rebase I do one of the following things. Lets start with this as an example of some changes on a feature

pick 3093c0f Play snake game from the 404 page
pick dfgdfggf progress
pick 2dewdfg some other thing
pick 34fdvfdb get the tests working again
pick 9umgnh update dependency

Squash 'em all

Sometimes preserving individual commits doesn't make sense. They are not discrete enough or are all progress commits. In this case I'd do the following:

pick 3093c0f Play snake game from the 404 page
f dfgdfggf progress
f 2dewdfg some other thing
f 34fdvfdb get the tests working again
f 9umgnh update dependency

Squash Selectively

Sometimes I am just iterating quickly and use commits as a save state. In this case I'd have a ton of progress commits that just need to be rolled up but I may not want to squash them all

pick 3093c0f Play snake game from the 404 page
f dfgdfggf progress
f 2dewdfg some other thing
pick 34fdvfdb get the tests working again
pick 9umgnh update dependency

Combo Move

The most frequent is that I want to get rid of progress commits, preserve some things and move other things around. In this case, In this example there is no reason to keep a dependency update which went stale during dev in it's own commit. It's actually confusing as it looks in the logs like there was a dep update after the feature was finished which is the first thing I always try to roll back when there is a bug. In the below I moved the commit 9umgnh to a different location in the log AND squashed it. I also squashed with the s flag rather than f so I could edit my final commit message rather than have it roll up automatically. Using the s flag pops a new VIM instance so you can edit in much the same way git commit --amend would do.

pick 3093c0f Play snake game from the 404 page
s 9umgnh update dependency
f dfgdfggf progress
f 2dewdfg some other thing
pick 34fdvfdb get the tests working again

from gitsavvy.

Updated description with new requirements.

from gitsavvy.

Looks great. Fantastic workflow description, @baer. Looking forward to this.

from gitsavvy.

Is this going to use git rebase to drive the process or try and rebuild all that ourselves? My workflow is typically:

• git rebase -i master
• lots of squashing
• lots of re-ordering
• a little renaming
• GO
• resolve conflicts
• git rebase --continue
• resolve conflicts
• git rebase --continue
• etc..
• DONE.

Seeing where I'm at in the latter part of the process would be a killer feature as it's one of the things I think git does very poorly. Sometimes I end up starting all over because I re-ordered some complex commits incorrectly and the conflicts are getting overwhelming.

from gitsavvy.

Oh, and --skip comes up periodically also if things have made there way into the master branch via a different route. (or were cherry-picked out, so I'm rebating but forget to do a skip at the first step)

from gitsavvy.

@yyyc514, I've started working on this but I haven't hammered out all the details yet. However, after talking to @baer, I plan to try consecutive rebases - the first will focus on addressing any conflicts. Status of each commit will be reflected by the check marks and X marks at the left of the commits in the interface. Once all the commits show as check marks, that means there are no conflicts and the other commands (squash, move, etc) will be enabled.

Much of this will be implemented with git rebase, and normally it would be a lot of overhead because you're typing all the commands at the terminal, and some of it is a bit redundant. However, this isn't really a constraint with GitSavvy and the UX of a rebase might be improved.

Anyway, I'll do this on a branch and ask for feedback from folks on UX etc before merging into master.

from gitsavvy.

I plan to try consecutive rebases - the first will focus on addressing any conflicts.

That seems limited to me as the entire point of squashing in some cases might be to avoid rebasing conflicts (or simplify them greatly). What I'm most curious about is how do you kick off the rebase and get the initial workplace? The git tool doesn't seem to have any hooks for doing this that I can see.

from gitsavvy.

Actually I'm not 100% sure what consecutive rebases means to you. I mean the rebase itself is nothing more than a very light-weight process on top of the regular git reset, commit, etc...

from gitsavvy.

I'd love to work on this some but I'd like to understand the flow (at least how it begins). The best way to get git to hand-off to you is to pass it an editor that messes up the first line of the interactive rebase... say replacing "pick" with "pause"... then git will stop and suggest you use --edit-todo (leaving the system in the rebase state, with .git/rebase-merge available, etc). Obviously only any *nix system it'd be easy to have a simple script (even sh, bash, grep) that did this... then left everything in a predictable state for starting to drive the process a bit more manually from an interface.

I have no idea what the equivalent might be on Windows though.

I think it's important the regular rebase process be used so that if you wanted to do something strange you could just jump to a console and do so (like you can now with all the other gitSavvy stuff)... and then jump back into Sublime and pick up where you left off... (plus that allows all the usual git stuff to work without getting confused about some non-git-rebase style rebase).

• How are we planning to select what to rebase against?
• How are we planning to boot the process?
• Is the view shown above the view for editing the todolist or just for walking the process?

from gitsavvy.

I'm working on this one, myself. Thanks for offering, though!

from gitsavvy.

FWIW: not sure what you're planning, but I think a key-based action (a la [c] checkout, etc.) to rebase against a chosen branch from the git: branch dashboard would be a good jumping-off point.

One of the few actions I drop out of Sublime/GitSavvy to do in a terminal is an occasional rebase against the remote tracking branch, to keep up with what others on my team are pushing to the origin.

Just a thought. This will be pretty cool! 😎👍

from gitsavvy.

Making some progress... so far looks promising! Squashing commits:

Once I have all the difficult bits done, I'll reach out to those interested to polish the workflow and make sure it works in a sane way. Also, the key bindings menu at the bottom will almost definitely change. As I'm learning more about how this will work, I'm re-evaluating the options that are presented to the user and the workflow that should result.

from gitsavvy.

I have squash, squash-all, and commit message editing working. Actual rebase still to go - that may be a bit tedious but probably a good bit more straightforward. Squashing and commit message editing will work before or after a rebase, just not during. The "during" will be only for resolving merge conflicts.

Anybody interested in taking an early look at this? Mostly looking for sanity check as I move forward, with the understanding that much is still undone and there are still a handful of decisions to be made.

from gitsavvy.

@benmosher @yyyc514, the rebase dashboard has landed in master. If possible, I'd like a handful of people to try it out before it is released via Package Control. So if you'd have some time, would appreciate your eyes.

Docs can be found by typing GitSavvy: help within the rebase dashboard or on GitHub.

Also @baer, if you have some time, would love to get your feedback.

from gitsavvy.

@p3lim, not sure if you use rebase regularly, but if you do and you have the time, would appreciate getting eyes on this.

from gitsavvy.

I'll give it a whirl later today.

from gitsavvy.

Trying it out now.

A few superficial comments:

• s to squash and g to stage feels a little risky; I'd be inclined to try s without thinking, a la the status page. I'd be inclined to use Q/q or some other as-yet-unused command letter.
• It was not immediately obvious to me that a conflict-free rebase had succeeded, as IIRC it stayed as Status: Ready.
• I think it'd be cool to have a rebase active onto selected command on the branch dashboard, to kick off a rebase with a base other than master/the git default.

That said, very effective overall. These are just a few nitpicks.

from gitsavvy.

Good feedback, thank you!

from gitsavvy.

Additional ideas: since many of the steps taken in the dashboard are single-keypress operations, and relatively minimal in terms of the output, consider adding a log of some sort, or at least a "previous action:" line in the header section.

from gitsavvy.

One thought I had, along those lines: what if you could "queue up" squashes, reorders, amend messages, etc. and then apply them all at once?

SourceTree's "interactive rebase" has a similar mode; you can modify commit messages and squash commits until you are pleased, then execute all changes at once*.

*no idea how that works under the covers, may just be executing queued git CLI commands.

I don't want to creep your scope, as it's already very usable. Just a thought.

from gitsavvy.

@benmosher - I got similar feedback from someone I was showing this to yesterday. The reason I went this direction is that is vastly simplifies the implementation. And, as someone for whom git rebase has never been a central part of their workflow, immediate action didn't break any of my expectations and seemed handy. However, I don't want the rebase dashboard to be a jarring experience for someone that actually uses rebase regularly.

How about this as an alternative:

• Add undo/redo capability, like the inline-diff mode.
• Display the most recent action taken in the header.

This would 1) provide visual indication to the user that an action they took succeeded, and 2) provide for the use case of someone trying to do something and realizing they hit the wrong button or didn't want to do that.

I've thought through the implementation and it should be relatively straightforward to accomplish.

from gitsavvy.

👍 sounds good to me. Again, great functionality already!

from gitsavvy.

@benmosher, I got sidetracked but these changes are now in master. Please give them a try and let me know if you run into any issues (especially wrt the undo/redo feature). Thanks!

from gitsavvy.

Thanks for the heads up, will do.

from gitsavvy.

I like the updated messaging + command keys.

I was playing with undo/redo; when I redo the graph doesn't seem to revert? After the move I have

STATUS:  Successfully moved bc84ec3 down. Undo available.

and when I undo it changes to

STATUS:  Redo available.

but when I redo, the STATUS changes back to the success message, but the commit sequence stays at the original shas/order. A look from an external git client seems to indicate that the redo did not get executed?

from gitsavvy.

Oh strange. Thanks, I'll take a look.

from gitsavvy.

Fixed @benmosher.

from gitsavvy.

The biggest complaint I have with the Rebase Dashboard is that operations that could be completed by rewriting just a couple of commits (e.g. squashing the last two commits on a branch into one) cause every commit in the branch to be rewritten.

This is a problem for me because often I will be working on a branch that has been pushed to origin, but to which I’ve added a number of additional commits in my local copy. I want to be able to re-write these local commits freely without re-writing the commits that have already been pushed to origin.

Additionally, all the extra commit rewriting really slows down operations on branches with many commits. Every little tweak requires every commit on the branch to be re-hashed, which really kills the responsiveness of the UI.

from gitsavvy.

@sentience, I agree 100%. This is something I've been meaning to come back to. Opened #208 to address. Closing this issue (as it should have been closed already).

from gitsavvy.

@sentience, I'll be revisiting this soon. But wanted to add that in your particular case, you can press f to define base ref for dashboard, and select your branch on origin. This will allow you to perform all operations in rebase dashboard without having to force-push at the end.

from gitsavvy.

from gitsavvy.