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

141–150 of 248 posts

Re: Git rebase in depth

#141

Post by u801e »

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…

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

I thought that Github and Bitbucket encouraged people to push up additional commits to fix issues in their PR. So, a typical PR will end up with a commit history like:

  Implement a feature method
  Add calls to new feature method
  Update to version 1.2.3
  fixing missing semi-colon
  addressed comments
  one more thing
  now its working
People who force-push are the ones who are trying to keep a clean commit history (meaning you don't have those extra 4 commits). So, your point about a PR being bad UX versus a rebase is correct, but not for the reason you state.

Re: Git rebase in depth

#142

Post by gpm »

jolmg wrote: post #122
gpm wrote: post #60

Earlier quoted context omitted.

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,…

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.

Re: Git rebase in depth

#143

Post by umvi »

Sir_Cmpwn wrote: post #28
dbaupp wrote: post #19

The 'push -f' suggestion could instead recommend 'push --force-with-lease' to be less error prone in case one is accidentally pushing to a concurrently modified branch. Also, unless the diagram is confusing with the alignment, the "rebase to rebase" example seems to be implicitly assuming --onto, because the last common ancestor of 'master' and 'feature-2' includes 2 commits on that branch: the first of 'feature-1' a…

I've heard this before, but I felt that `--force-with-lease` requires a lengthier explanation in an an already intimidating article, is harder to type, and generally isn't useful for users of the Sourcehut workflow. It's definitely a useful tool, though. Maybe I should add a footnote.

I just made a git alias `fpush` that does --force-with-lease

Re: Git rebase in depth

#144

Post by mixmastamyk »

irrational wrote: post #140
mixmastamyk wrote: post #77

Earlier quoted context omitted.

Yep, it was designed by and for linux kernel development, that average users are using it is an accident of history.

So what are the chances that a version of Git, or something like Git, will be developed that is suitable for the average user? Someone above made a comment about how easy it is to do X in Git, and then preceded to write lines of Git commands that are as arcane as anything an alchemist could come up with. If that is easy Git, I'd hate to see what hard Git looks like.

Making it could be done, Mercurial already exists for example. Perhaps a next-gen version introduced with all the lessons learned over the last decade.

Getting folks to use it would be very difficult due to network effects however.

Re: Git rebase in depth

#145

Post by eridius »

brandmeyer wrote: post #110
jrockway wrote: post #80

Earlier quoted context omitted.

There is the reflog for that. https://www.atlassian.com/git/tutorials/rewriting-history/gi...

This is technically true, and a common reposte when talking about preservation of history edits. Unfortunately, the reflog is confusing and hard to use correctly in the case of an interactive rebase with multiple steps. It is hard to figure out exactly how far back you need to go in the reflog to get to moment before the rebase started if you want to start over. It also just so happens that its when an interactive re…

HEAD and the branch have separate reflogs. Each step of an interactive rebase adds a separate entry to HEAD's reflog, but the branch's reflog only ever gets a single new entry when the rebase is complete. So you can run e.g. `git log -g master` and skip the rebase intermediate steps.

It is rather unfortunate that there is no convenient documented shorthand for "show me the reflog of the current branch" (`git log -g` gives you HEAD's reflog). That said, after a bunch of experimentation, it seems like `git log -g '@{0}'` will give you the reflog for the current branch. Apparently this works because e.g. `git log -g '@{2}'` gives you the reflog for the current branch skipping the first 2 elements.

Re: Git rebase in depth

#146

Post by shandor »

Buttons840 wrote: post #102
Chazprime wrote: post #58

Earlier quoted context omitted.

This really should be the top comment here. Learning about the non-destructive nature of Git really helped me overcome the unease around using some of Git's more advanced features (especially in a team environment).

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.

This is also why commiting very often is a very good idea.

I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.".

I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they can't trash the origin even if they try.

Re: Git rebase in depth

#147

Post by [deleted] »

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.

[deleted]

Re: Git rebase in depth

#148

Post by zemo »

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?

Most people's aversion to rebase is an aversion to altering history. Since squashing alters history anyway, I'd argue that you might as well just use rebase when you do it.

In a rebase-oriented workflow, every commit has exactly one parent, and the commit history is entirely linearized. Merge commits have more than one parent, which means going backwards through the history means that you have to essentially navigate the branching structure to navigate the history. That makes it pretty hard to do!

A linear history is comparatively easier to reason about than a history with all of its branches. It's also, in a sense, less "true"! So it depends what you care about. Do you care about telling the exact story of everything that happened to everyone on the project, or do you care about the history of changes to the one shared copy?

Linear histories also make it easy to step backwards through the history one commit at a time. I personally just do `get checkout HEAD^` over and over, walking through the history in reverse, since most breakages are noticed within a few commits of their occurrence. I really like being able to do that. A lot of people think that's useless!

If you have one copy of the project that is considered authoritative, and all developers are synchronizing via that single authoritative copy, creating a clean and linear history is possible.

Re: Git rebase in depth

#149

Post by kohtatsu »

shandor wrote: post #146
Buttons840 wrote: post #102

Earlier quoted context omitted.

Yep. Specifically, git will never delete a commit, unless it is old (like 30 days old or older I think?) and is not part of a branch. I suppose there may be some arcane commands to force a deletion, but it wont happen by accident or by normal usage. Like you, I felt much more comfortable using git after learning this.

This is also why commiting very often is a very good idea. I often try to reassure people new to git that "if you'll just commit often, there's basically no way you can lose work so that I can't help you get it back. Apart from deleting the whole repo folder. Don't delete the repo folder.". I also have the habit of preventing non-fast-forward pushes on origin/master, which also helps when I can tell my team that they…

Which merge strategy do you recommend?

    # Merge commit
    git merge --no-ff -m  
    # Squash and merge
    git merge --no-commit --squash 
    git commit -m 
    # Rebase and merge
    git rebase --force-rebase
From https://stackoverflow.com/a/52301456

Re: Git rebase in depth

#150

Post by AlexTWithBeard »

dahart wrote: post #109
AlexTWithBeard wrote: post #96

Earlier quoted context omitted.

For me "change management" is akin to IntelliJ's shelf: you can have a bunch of changes, you can combine them in lists, you can shuffle the changes between these lists and selectively apply them. Editing is the king. I should totally be able to destroy five years of my work without a way to recover. "Version control" is a log. I should be able to return to any point in history at any time. I should not be able to des…

Rebase is a way to provide what you're calling "change management", and so is git stash. The rest of git is what you're calling "version control". I don't see any conflict. I don't love trying to differentiate those terms either, FWIW. Managing changes and controlling versions are "literally" the same thing. > Then I force push and the mess begins. That is your problem right there. Force pushing over published histor…

That is your problem right there. Force pushing over published history should always be avoided.

That is my problem right here.

There is no way to tell the difference between "I push to make something public" and "I push to back up my data in some safe location".

Post reply on HN