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

101–110 of 248 posts

Re: Git rebase in depth

#101

Post by np_tedious »

Hello71 wrote: post #22
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…

http://man7.org/linux/man-pages/man1/git.1.html GIT COMMANDS We divide Git into high level ("porcelain") commands and low level ("plumbing") commands.

Being that rebase is under "porcelain", would you agree the UI ought to be improved?

I'm not sure if I do, but that's the conclusion the man page + your comment would seem to support.

Re: Git rebase in depth

#102

Post by Buttons840 »

Chazprime wrote: post #58
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…

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.

Re: Git rebase in depth

#103

Post by gitzen »

limxto0 wrote: post #69

All the git-rebase-fu I have ever needed while working with pull requests, I have found in this well written guide: https://github.com/susam/gitpr Quoting from this document below. # Rebase topic branch on the main development branch (optional). git checkout TOPIC-BRANCH git rebase master # Edit commits, e.g., last 3 commits in topic branch (optional). git checkout TOPIC-BRANCH git rebase -i HEAD~3 # Force push rebas…

Thank you for sharing this link. Until now, I never understood properly how rebase and fast-forward merges work. This simple note in this document made it all clear.

"Beginners to this workflow should always remember that a Git branch is not a container of commits, but rather a lightweight moving pointer that points to a commit in the commit history.

    A---B---C
            ↑
         (master)
When a new commit is made in a branch, its branch pointer simply moves to point to the last commit in the branch.

    A---B---C---D
                ↑
             (master)
A branch is merely a pointer to the tip of a series of commits. With this little thing in mind, seemingly complex operations like rebase and fast-forward merges become easy to understand and use."

Suddenly everything makes sense now!

Re: Git rebase in depth

#104

Post by AlexTWithBeard »

pmiller2 wrote: post #86
dahart wrote: post #82

Earlier quoted context omitted.

Comparing lost commits to rm isn’t a good analogy. Git has a very good safety net when you know how to use it. The problem is knowing how to use it, not that it’s not there. It’s a legitimate point that git’s UI sucks, that’s what’s wrong, and everyone agrees. But learn how to use the reflog and you will see the light!

Git has very good safety even if you don’t know how to use it, provided you commit when you want something to be saved and you don’t rm the whole repo at the first sign of trouble.

I think my issue is that most people should not even know how this safety net works. But every other question about git on stack exchange seems to be "how do I recover from a failed rebase".

Re: Git rebase in depth

#105

Post by chris_mc »

recursive wrote: post #100
chris_mc wrote: post #92

Earlier quoted context omitted.

I don't get the "extra letters" argument as a Computer Scientist. Most of my time is spent figuring out what I'm going to do before I type anything, whether that's research, staring at code for hours to see how it works, or something else. I could type 3x as many characters each day and would probably only work an extra 10 minutes per day. Maybe I'm the exception, but I don't like brevity for brevity sake.

You could also consider it "harder to remember".

I normally use "git push --fo" or "git push --fo" in zsh, but after seeing the switch option "--force-with-lease" pop up each time I've memorized it now. I let my CLI do the work for me most of the time, but when I can't there's always "man COMMAND". After doing anything a bunch of times, you remember it.

Re: Git rebase in depth

#106

Post by zemo »

mixmastamyk wrote: post #99
zemo wrote: post #95

Earlier quoted context omitted.

You're talking about a UI failure but you're not actually considering the entire experience. Reading the history of the project is a big part of the experience, especially for people in team lead roles. How much of your experience is writing code versus reading code? A merge-oriented workflow often results in a history that is deeply confusing to read. The only part of the experience that you're considering is the au…

History has been useful to me at a high level, inspecting grains of sand at the beach, not so much. I can imagine it might be useful to some like linux kernel devs, but nowhere I've ever worked over a long career.

it's not "inspecting grains of sand". If you have any number of developers worth talking about, merge-oriented workflows can create incredibly unwieldly git histories very quickly. I'm talking about, at a very high level, just understanding the history of the project. If you have five feature branches going on, and your developers are all committing on a regular basis, understanding the history and cadence of your project work based on the git history is incredibly difficult when the events of the separate feature branches are all intermingled.

Your comparison is not apt in many ways. For one thing, open-source governance is extremely different than managing private codebases maintained by a single company. Nobody in open-source governance is reading git histories to figure out whether employees are struggling, who is performing, who is not performing, who is overworking, where the project is, whether or not people are duplicating their efforts, how to report progress to clients, etc. And besides, the Linux kernel uses an email-based, merge-oriented workflow anyway. Kernel patches are submitted via email. That's not at all representative of any company that I have ever worked for or any company that I know of. The Linux kernel history also has a network graph that is literally unviewable on Github because it's so complex. Again, not representative of 95% of the work for 95% of users on 95% of projects.

Re: Git rebase in depth

#107

Post by pizzapill »

I've you use rebase to rewrite history a lot I have found/developed a couple helpful commands (tested & working on Linux bash).

Put those in your ~/.gitconfig:

  [alias]
   fu = "!f() { local msg=\"fixup! $(git log --oneline -n1 | cut -d ' ' -f2-)\"; git commit -am \"${msg}\" && git rebase -i --autosquash HEAD~2; }; f"
   fuc = "!f() { local msg=\"$(git log --oneline -n1 | cut -d ' ' -f2-)\"; if [[ \"${msg}\" != "fixup!"* ]]; then msg=\"fixup! ${msg}\"; fi; git commit -am \"${msg}\"; }; f"
   xx = "!f() { git reset --hard && git clean -f -d; }; f"
From now on:

git fu = (git fix up) combines last commit and all staged changes into one commit with the last commit message

git fuc = (git fix up comment) commits all staged changes as a new commit with the last commit message, but prefixed with "fixup!". Except if the last commit message is already prefixed with "fixup!". Now you can work on the same thing but commit incremental steps. In the end you just do: git rebase -i master (or similar) and they will be all in one commit.

git xx = get rid off all unstaged/uncommited changes in current directory. Very destructive, very useful.

Last but not least. If you have a lot of "fixup!" or "squash!" commits and need to interactively rebase without autosquashing them do:

git rebase --no-autosquash -i master

Re: Git rebase in depth

#108

Post by kradroy »

Chazprime wrote: post #58
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…

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

I had to do a git history rewrite via "git filter-branch" and one other method. I can attest that you really have to go out of your way to actually permanently get rid of anything in a git repo. It's always funny to me when I see an engineer have a panic attack the first time they think they've trashed the repo and lost important code. They always have that same look as relief washes over them when I show them how to recover from the mistake.

Re: Git rebase in depth

#109

Post by dahart »

AlexTWithBeard wrote: post #96
dahart wrote: post #74

Earlier quoted context omitted.

I totally don’t understand your implied semantic difference between “change management” and “version control”. Those sound like exactly the same thing to me. ;) I also don’t understand your larger point about git and what the problem is. For almost everyone using git, the pushed history is sacrosanct, and the main repo is centralized. The main workflow for rebase is to clean up before making commits public.

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 history should always be avoided. Don't do that, it is very unfriendly to others you work with. Just always pull, resolve any conflicts, then push your changes without forcing them. If you need to force in order to fix a serious mistake, then notify everyone first and have people hold their changes, then pull everything, resolve the problem, force push, and notify everyone again to "force pull" by first fetching, then reset their branch to what's in the origin verison; using reset --hard will let them avoid having any conflicts after you force pushed. Consider carefully whether the mistake even warrants a force push, or if you can make do with new commits on top that fix the bad ones.

> Regarding centralized repository [...] Seven potentially different versions of the same exact file.

You're conflating multiple different topics. The existence of multiple copies of a file isn't related to which repo is the central one, nor is it some kind of problem.

The origin repo is your central repo. Your downstream repo has to copy from the upstream/central repo if you even want to work on the code. What you called "copies" in origin/master and master are branches, not copies of the file. The only single copy on your machine from your point of view is your local workspace, which expanded from your "master". stash is something that happens behind the scenes to your git database, it's not making more working copies. wc2 is another repo or computer, it's not even relevant. None of these copies you're talking about are visible to a user except the one working copy.

Re: Git rebase in depth

#110

Post by brandmeyer »

jrockway wrote: post #80
Dayshine wrote: post #72

Earlier quoted context omitted.

I really don't understand why git doesn't create a tag when you rebase in case things go wrong, or more generally when doing potentially gc-able actions. Pretending the average user will know how to get things back to how they are is silly.

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 rebase goes awry that I really want to reach for the reflog to fix the damage.

Post reply on HN