Always rebase interactively with rebase-origin #136

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
5 participants
Owner

croaky commented Apr 14, 2013

There are two use cases for rebase-origin during our normal workflow:

  1. Rebase frequently to incorporate upstream changes:
g rebase-origin
  1. Pre-merge, squash commits like "Fix whitespace" into a small number of
    valuable commit(s). Edit commit messages to reveal intent.
g rebase-origin

rake

Owner

gylaz commented Apr 15, 2013

Is the only consequence of this that it will open vim to allow review and accept of the rebase? I remember us talking about this, and some kind of issue/comment came up with this approach, but can't remember what.

Owner

croaky commented Apr 15, 2013

Is the only consequence of this that it will open vim to allow review and accept of the rebase?

I believe that's accurate, yes.

I remember us talking about this, and some kind of issue/comment came up with this approach, but can't remember what.

There might be a temptation to squash more often while working on a topic branch, which may not be healthy. I haven't been able to come up with other downsides.

Owner

croaky commented Apr 23, 2013

Could I get another review of this? /cc @jferris

Owner

jferris commented Apr 23, 2013

I'd have to try it to be sure, but I think this would have the opposite problem.

  • Without this change, before every merge, you need to add the -i.
  • With this change, every time you rebase to sync up with master, you need to :q.

I think I sync up more often than I merge, so it seems like this is optimizing for the less-common use. Have you been trying this out locally?

Owner

croaky commented Apr 24, 2013

Have you been trying this out locally?

A decent amount, yeah.

Without this change, before every merge, you need to add the -i.

I think it's a little bit more than that. Without this change, before every merge, I need to git fetch origin && git rebase -i origin/master. I have a tendency to forget the git fetch origin, which is one of the more important reasons I think rebase-origin is a nice alias.

With this change, every time you rebase to sync up with master, you need to :q.

Yup, but I don't see that as a drawback. It's another time to see the commits I've created so far. If I'm syncing up before opening a pull request, I might squash the commits at this time.

Owner

gylaz commented Apr 24, 2013

You can pass -i after rebase-origin and it will behave as desired.

What about adding this as a new alias?

squash = !git fetch origin && git rebase -i origin/master

Owner

croaky commented Apr 24, 2013

You can pass -i after rebase-origin and it will behave as desired.

Cheeky! I like it. Could be the best of all worlds.

What about adding squash as a new alias?

That could be interesting. Just pushed eb0e57a, will give the different names a trial run for a few days/weeks.

Owner

jferris commented Apr 24, 2013

I have had rbi as my "rebase interactively on top of origin/master" for a long time. Makes me feel like I'm scoring runs!

Owner

joshuaclayton commented Apr 24, 2013

I've been using git from for a while now and love it:

[alias]
  from = !git fetch && git rebase origin/master

@jferris jferris commented on an outdated diff Jun 10, 2013

st = status
+ sync = !git fetch origin && git rebase origin/master
@jferris

jferris Jun 10, 2013

Owner

I have git up for this alias. I'm guessing that's a hold out from the svn days.

Anybody else use an alias like this?

Owner

jferris commented Jun 10, 2013

This pull request is starting to get stale. Any updates here?

Owner

croaky commented Jun 10, 2013

@jferris I just rebased and made the two aliases squash and up. I think the discussion here shows that people like having an alias for both cases. The naming is a little different for everyone so picking one is a little tricky but I personally have no strong preference.

@gylaz gylaz and 1 other commented on an outdated diff Jun 10, 2013

st = status
+ up = !git fetch origin && git rebase origin/master
@gylaz

gylaz Jun 10, 2013

Owner

I don't see a need to have both squash and up commands that are almost the same. Why not just have one up then if you want to make it interactive just pass -i?

git up -i

I feel like otherwise there's unnecessary abstraction of what is actually happening. But this is just, like, my opinion, man. 😄

@croaky

croaky Jun 10, 2013

Owner

That seems pretty clean, too. d8c49f1

Owner

jferris commented Jun 11, 2013

I am in favor of merging this pull request as it currently stands.

Owner

croaky commented Jun 11, 2013

Cool, merged.

Owner

croaky commented Jun 11, 2013

And used the new alias!

croaky closed this Jun 11, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment