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

121–130 of 248 posts

Re: Git rebase in depth

#121

Post by gwright »

nacho_weekend wrote: post #114
gwright wrote: post #32

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…

Yes, I agree. Rebase has the ability to obfuscate and rewrite commits if you so choose . Rebasing to just re-order commits is totally viable and perhaps encouraged. We did this at a previous company and it made the commit history very clean to read. However, with great power comes great responsibility in a rebase, and a junior dev can easily mess things up if you don’t educate them properly.

Nope. It doesn't 'rewrite' commits. You are using the language I was calling out as confusing.

It creates new commits and moves the branch to the tip of the new sequence of commits. No existing commits are changed or deleted.

Re: Git rebase in depth

#122

Post by jolmg »

gpm wrote: post #60
jolmg wrote: post #53

Earlier quoted context omitted.

> 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 `rebas…

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?

Re: Git rebase in depth

#123

Post by paulddraper »

zemo wrote: post #118

Git rebase is great. Honestly I think the argument that "if you have to push -f that means rebase is wrong" is making a huge assumption about how people use branches and why people are force pushing branches. Force pushing branches is what you do when you have pushed a branch that you expect to modify. Why would you do that? Because that's how Github and Bitbucket have taught people to conduct PR's. If your immediate…

I should add that `rebase` in no way requires `push -f`, if these are private, unpublished changes.

Re: Git rebase in depth

#124

Post by malingo »

My eyes were opened on git-rebase when I read https://matthew-brett.github.io/pydagogue/rebase_without_tea...

The full version of the command as

    $ git rebase --onto new-base start end
takes the commit range (start,end] and re-commits them on top of the new-base commit. The commit range doesn't have to be a full branch and you don't even need to be on the branch to run the command this way. It's very intuitive and I nearly always use the full version now.

I've also gotten into the habit of "pinning" my branch before I rebase so that I have it in its original form. If the branch name is my-branch, then the command

    $ git branch my-branch{-hold,}
which is a handy (bash-specific?) shortcut of

    $ git branch my-branch-hold my-branch
leaves you on my-branch and creates a new branch label called my-branch-hold that points to the same place.

EDIT: clarification of pre-rebase branching

Re: Git rebase in depth

#125

Post by eterm »

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…

This isn't HTML & CSS vs squarespace, and to butcher the analogy this is more like CSS vs Sass/SCSS. CSS is the internal API which does everything but Sass is an API which exposes that in a much more beautiful way.

I don't need to know how postgres does paging, indexing, tree diffs, etc to be able to write good SQL.

I don't need to know how typescript compiles to javascript to use typescipt.

I don't need to know how my engine works to drive my car.

I use all of those every day.

But the suggestion here is that as every day users of git should learn git internals to be able to use the tool better.

That's a tooling failure. It's not a failure of the git design or git fundamentals, it's a failure of the git cli.

Re: Git rebase in depth

#126

Post by uryga »

Espressosaurus wrote: post #25
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…

Mercurial's interface is just fine, and these days it's just as powerful as Git. Things could be better. There's an existence proof. It just lost the mindshare war and so now we're stuck with Git, which I still have to look up basic syntax for because its command set is contradictory and makes no sense. (Is it git ? git --x? git ? Something else entirely? Who knows!)

nitpick, but I think "existence proof" is the opposite of what you meant (that Mercurial is a living proof that things can be better):

> a constructive proof is a method of proof that demonstrates the existence of a mathematical object by creating [...] the object.

> This is in contrast to [an existence proof], which proves the existence of a particular kind of object without providing an example.

https://en.m.wikipedia.org/wiki/Constructive_proof

Re: Git rebase in depth

#127

Post by gshulegaard »

Sir_Cmpwn wrote: post #27
jaequery wrote: post #23

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

I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."

My biggest issue with that argument though is what constitutes "good" is subjective. For me a good commit history is one that faithfully chronicles what happened.

With this in mind, acceptable curation of the history for me is squashing or separating commits and neither of these require rebase. But I wouldn't object if a colleague chose to use rebase to accomplish this.

I would, however, object to reordering commits or rebasing since this alters the chronicle.

Which I guess leaves me with my opinion on rebase:

You can, but you don't need to. If you are going to, be sure you understand what you are doing and don't alter the chronicle.

Re: Git rebase in depth

#128

Post by [deleted] »

gwright wrote: post #32

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…

[deleted]

Re: Git rebase in depth

#129

Post by umvi »

jaequery wrote: post #23

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

Do you use feature branches? Interactive rebases are super nice for cleaning up feature branches before submitting a PR because no one wants to see your broken, non-atomic commits that have swear words in the commit message.

If you submit a PR to my project on GitHub and it consists of 20+ broken, non-atomic commits leading up to the final one, I'm going to ask you to clean them up and squash into one.

Post reply on HN