Hacker News Reader

Comment by ajross | Hacker News Reader

It's not an interface problem at all. "git rebase", with no arguments, does almost exactly what a typical user wants almost all the time. Probably 80% of the remaining cases are handled by "git rebase $BRANCH".

But once outside that world, the user if faced with the problem that "rebase" is just a special case of "merge" and shared all the complexities and edge cases. And that's hard for fundamental reasons. Git has tools for this too, but their interface shares the complexity of the problem domain.

View on HN

"git rebase" does exactly what you want, except when it's totally unrelated to what you want because what you actually want is "git rebase -i HEAD~3" which does something basically completely different (from a users point of view).

This is probably where I foul up.

My last few workplaces were either not git, or relied on git pull w/o rebase. My current workplace has rebase as part of their flow, and I find that, like, 60% of my PRs require force push, which bothers me greatly. Everyone else just shrugs and considers it part of business, but I know what I WANT to do should be nicely aligned and not encounter that problem.

Unfortunately, every explanation I'm like "yes, yes, branching trees, I get it..." and then I'm suddenly in the "...and it says things are different and I don't know why". And because this always happens when I'm trying to get some fix in, I never have the time to study it to figure out what is really happening. It's just "--force and promise myself the next time will be different".

> My current workplace has rebase as part of their flow

Not really sure what that means as rebase can be used in multiple ways, but you might want to try using:

`--force-with-lease` instead of `--force`

> This option allows one to force push without the risk of unintentionally overwriting someone else’s work

https://thoughtbot.com/blog/git-push-force-with-lease

That does sound like they're doing it wrong. Could you give an example?

> Could you give an example?

To the degree I understand it, sure:

We have master branch A

I create a feature branch B

Both get updates. Someone will do a rebase of B to the most-recent A and push that. (In my previous workplaces they would have just pulled the most recent A)

Here's where the confusion comes in: If I get the updated B but A has updated again, I cannot pull A nor rebase to A and successfully push the result without forcing. IIRC, on push it complains that my local branch is not up to date, but if I pull it will tell me I am up to date.

At least, that's what I think is the timing - since this involves multiple people I'm uncertain of what exactly occurs and the order, nor why problems are inconsistent. We don't have that many feature branches that have multiple people contributing AND requiring updates from the master branch, but it happens often enough.

> which does something basically completely different (from a users point of view).

The only difference is that one's interactive and the other isn't. If you use `-i` and simply exit out of the editor, the effect is completely the same as not having used `-i`, isn't it? I think moving `rebase -i` to a completely new command could potentially make things more confusing. That new command would be an extension of `rebase` and so could be used interchangeably.

The other difference is that I'm "rebasing" onto an ancestor of the current head, as in I'm not really changing base at all.

A hypothetical new command would be a simpler version of "rebase" that comes with the restriction described above, that it's not actually changing base.

> The other difference is that I'm "rebasing" onto an ancestor of the current head, as in I'm not really changing base at all.

`rebase -i` doesn't restrict that, does it? There may be people whose workflow includes things like `git rebase -i --onto foo bar baz`. That you don't use it is another matter.

> A hypothetical new command would be a simpler version of "rebase" that comes with the restriction described above, that it's not actually changing base.

You want to remove features from git? Why?

If you didn't mean to say that instead of having `rebase -i` we should only have this hypothetical command, then you can do:

  git config --global alias.edit-history 'rebase -i'

Though you may want to add to that to make it impossible to use edit-history to rebase, too. I mean, you did say you wanted the restriction, right?

No, rebase -i doesn't, that's why I said `rebase -i HEAD~x` in my original comment and not just `rebase -i`. `rebase -i` should of course continue to exist.

Your right when you say I don't "just" want to introduce an alias because I want to restrict the arguments.

The other issue with that solution is I don't just want a solution for me. I know how this works now, I've already memorized the magic incantation to edit history and later spent the time to understand why the command does what it does (the same goes for basically all the other common git commands). What I want is a solution that works for everyone, out of the box, so we can stop wasting time teaching git internals.

OK... And what is your suggestion for a proper and obvious interface choice for that?

FWIW: the line noise you typed means "Make a list of the changes since three commits ago, let the user edit the list, then apply them". Other than -i step and the length of the list, this is basically a noop -- you're rebasing on an ancestor of HEAD! I mean, yeah, git lets you do that, but I don't know why you expect the syntax for irrelevant nonsense to be simple.

But let's humor you and try to use that syntax for something real. If you typed "my_version_tag~3" it might make sense -- you want to back up to the commit before whatever automation might have added for a release and put your current work on top of the earlier tree as if they had been developed as part of the release. And you have some junk in your current tree you don't want to expose to the customer to whom you are going to hand this test tree, so you want to remove it interactively.

That... sounds like a useful trick. But it's complicated. And the syntax is complicated. So what's a good syntax for the previous paragraph's action?

How about, `git edit-history 3`? Just stop calling it rebase.

The "line noise" I typed is an extremely common command that is used to clean up commit history, e.g. squash all your "WIP" commits into a few nice ones. Yes the idea of rebasing onto the same branch is just weird, that's kinda my point, since it's the only way to edit history that git supports (as far as I, or anyone I've ever seen answer a question about how to do this knows).

You mean like mercurial histedit <revision>?

Also, emacs magit makes this even easier, if you don't mind a more GUI-like interface.

So... your whole complaint is that people use "rebase" as a trick for "edit history". You'd be fine if they just put a wrapper into the project for that? Seems like not much of a complaint to me. Why not just submit it yourself?

Git doesn't have "reorder patches" feature. Maybe it should. But the fact that its rebase tool can be abused to do this doesn't say anything about the interface value of "git rebase".

Honestly, it seems like the root cause here is that you don't actually do branch rebasing very often, don't see the value of having a rebase tool in the tree, and are just complaining that the trick you do need isn't well supported by the rebase tool you don't use or understand.

No, I use rebase for "branch rebasing" (i.e. actual rebasing) too. I have no clue how you got that out of my comments.

My complaint is that git's UI is terrible to teach people, to understand it you have to understand way too many internal details of git.

Yes, making a wrapper for `git rebase -i HEAD~x` (and `git rebase -i <other thing that refers to a commit above head>`) would satisfy this UI nit. It wouldn't satisfy all UI nits, this is just a relevant example.

As for why not submit it myself, I'm sure I'm not the first person to complain about this, drive-by UI changes to a project are the absolute best way to get a ridiculous inconsistent UI. I don't submit it myself because I'm not willing to commit the time to become a core maintainer of git, and without being a core maintainer I don't feel right trying to push UI changes in.

> Git doesn't have "reorder patches" feature.

Huh? That is exactly what git rebase -i is. This isn't some kind of "abuse" or "trick", this is precisely what interactive rebase was designed for. What is making you think that rebase is only to be used when merging two different branches?

Reply on news.ycombinator.com