Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git rebase in depth

git-rebase.io

Post reply on HN
Print view View original

31–40 of 248 posts

Re: Git rebase in depth

#31

Post by gpm »

ajross wrote: post #20
Sahhaese wrote: post #9

When you have a command so confusing that you need an entire website dedicated to a single command, and still need to warn against using it, then perhaps you've got the UX wrong.

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…

"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).

Re: Git rebase in depth

#32

Post by gwright »

About 99.9% of the time when people talk about rebase they talk about ‘editing’ history or ‘rewriting’ history as in the first sentence of the article.

I find that terminology terribly misleading and when I was learning git and rebase it confused the heck out of me.

No commits are harmed in the operation of `git rebase`. All the commits you had in the repo before the rebase are still in the repo. Git rebase creates a new sequence of commits and after doing its work relocates the branch name to the tip of the new sequence but you can easily access the previous commits if need be:

    $ git co feature-branch
    $ git rebase develop
    $ git co -b before-rebase-feature-branch feature-branch@{1}

Re: Git rebase in depth

#33

Post by nothrabannosir »

jaequery wrote: post #23

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful for debugging, but it does require your commits to be as healthy as possible. If you fix a bug 10 commits after it was introduced , now the 10 commits between them are harder to work with; you always have to keep in mind that unrelated bug. And cherry picking is lovely between branches , but if a commit introduced a bug and another fixes it, now you always have to cherry pick them together. Easier to fix it and keep them atomic.

A clean git history is not a vanity project. It can be used as a tool in further code building.

Re: Git rebase in depth

#34

Post by rich-tea »

What I really like to do is make actual fixup (or squash) commits during a code review and just push these to the branch normally. That way reviewers can easily keep up with the changes. Right at the end, the maintainer requests that the original developer does a rebase --autosquash before the branch is actually merged.

This works really well but I rarely see people talk about it. It means you don't have to use something complicated like github or gitlab to keep up with rebases. It works for everyone.

Re: Git rebase in depth

#35

Post by Espressosaurus »

Sir_Cmpwn wrote: post #21
Sahhaese wrote: post #18

Earlier quoted context omitted.

But those high level tasks could also be exposed directly. There's nothing to stop there being more commands which more directly accomplish the desired tasks. The idea that git is good because it is difficult to use is just "git snobbery", as is the idea that it must be difficult because it's a DVCS. There's nothing to stop git having two levels of the API, one exposed for tools to build off of with the full complexi…

This is the same argument that suggests Squarespace is better than HTML & CSS. Maybe true for some people - but not the typical HN audience, I imagine. You use git all day, every day. It's worth it to learn it inside and out, and the design assumes users who are willing to make that investment. If you assume everyone learns the primitives, then the rest of git's design makes sense as an organic evolution of that. And…

Nah. It's a UI issue. Even when you know the primitives, the counterintuitive randomness of what is a command vs. what is a switch on a different command vs. something that can be done in three different ways using different combinations of commands and switches makes it a clusterfuck to interface with until you memorize everything. Contrast to something like mercurial where once you know the concept, you either know how to do it, or you know the command that will give you the help for how to do it. It's generally not going to be some switch on an unrelated command because the UI was actually designed and not simply cobbled together.

Re: Git rebase in depth

#36

Post by rich-tea »

jaequery wrote: post #23

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge.

But maybe you use your history for something else that I haven't considered.

Re: Git rebase in depth

#38

Post by jaequery »

rich-tea wrote: post #36
jaequery wrote: post #23

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge. But maybe you use your history for something else that I haven't considered.

can't you do similar by tagging? and then later just diffing against them?

Re: Git rebase in depth

#39

Post by Amorymeltzer »

V-2 wrote: post #30
Amorymeltzer wrote: post #24

The warning regarding "public, shared, or stable branches" is always warranted, but I think those warnings end up reverberating where they needn't. Before interacting with anything public or shared — when working solo or locally — `rebase` can be hugely helpful. When starting out with something complicated, I often make separate commits for different files or steps; using rebase to reorder commits or amend can make t…

I'd use rebase --interactive quite aggressively on a public branch when it's a feature branch that's not yet been merged. As I'm the only owner of it, the way I see it I owe no guarantees to anyone. You're welcome to watch it, but it's work in progress in every aspect.

Github and refined-github[1] make it easier, by keeping track of changes from a `push -f` and having merge/squash/rebase options on merging, but I know of large projects with an explicit "no rebasing" rule as it can get confusing for reviewers. I'd say it depends on the project, maintainers, and general workflow. Which is good!

1: https://github.com/sindresorhus/refined-github

Re: Git rebase in depth

#40

Post by Sir_Cmpwn »

madlynormal wrote: post #37

Is there a benefit to rebasing vs merging, specifically if your flow is to squash commits before merging back into base?

Rebasing picks commits, merging merges. Unless you're actually trying to merge two histories, I don't recommend using merge. Just think about what you're logically trying to accomplish and choose that tool.
Post reply on HN