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

Git Rebase for the Terrified

brethorsting.com

Post reply on HN
Print view View original

51–60 of 305 posts

Re: Git Rebase for the Terrified

#51

Post by cdmckay »

tomaytotomato wrote: post #41

Github is not Git but I find the Squash and Merge functionality on Github's Pull Request system means I no longer need to worry about rebasing or squashing my commits locally before rebasing. At work though it is still encouraged to rebase, and I have sometimes forgotten to squash and then had to abort, or just suck it up and resolve conflicts from my many local commits.

This

Rebase only makes sense if you making huge PRs where you need to break it down into smaller commits to have them make sense.

If you keep your PRs small, squashing it works well enough, and is far less work and more consistent in teams.

Expecting your team to carefully group their commits and have good commit messages for each is a lot of unnecessary extra work.

Re: Git Rebase for the Terrified

#52

Post by thunderbong »

embedding-shape wrote: post #17

> The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help. The best method for stop being terrified of destructive operations in git when I first learned it, was literally "cp -r $original-repo $new-test-repo && go-to-town". Don't know what will happen when you run `git checkout -- $file` or whatever? Copy the entire director…

One of the many things I like about fossil is the 'undo' command [0].

Also, since you can choose to keep the fossil repo in a separate directory, that's an additional space saver.

[0] https://www3.fossil-scm.org/home/help/undo

Re: Git Rebase for the Terrified

#53

Post by fc417fc802 »

jameshush wrote: post #9
echelon wrote: post #5

Earlier quoted context omitted.

git rebase squash as a single commit on a single main branch is the one true way. I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS. You should always be able to roll back main to a real state. Having incremental commits between two working stages creates more confusion during incidents. If you need to consult the work history of transient commits, that can live in your…

This is one of the few hills I will die on. After working on a team that used Phabricator for a few years and going back to GitHub when I joined a new company, it really does make life so much nicer to just rebase -> squash -> commit a single PR to `main`

What was stopping you from squash -> merge -> push two new changesets to `main`? Isn't your objection actually to the specifics of the workflow that was mandated by your employer as opposed to anything inherent to merge itself?

Re: Git Rebase for the Terrified

#54

Post by hhjinks »

ratchetclank wrote: post #23

I never understood why rebase is such a staple in the git world. For me "loosing" historical data, like on which branch my work was done is a real issue. In the same class, for commit to not have on which branch they were created as a metadata is a rel painpoint. It always a mess to find what commit were done for what global feature/bugfix in a global gitflow process... I'll probably be looking into adding an commit…

Which branch your work was done on is noise, not signal. There is absolutely zero signal lost by rebasing, and it prunes a lot of noise. If your branch somehow carries information, that information should be in your commit message.

Re: Git Rebase for the Terrified

#55

Post by fc417fc802 »

smartmic wrote: post #40
chungy wrote: post #27

Earlier quoted context omitted.

Sounds like you'd be a fan of Fossil ( https://fossil-scm.org ). See for instance: https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...

Let me expand on this with a link to the article "Rebase Considered Harmful" [0]. I also prefer Fossil to Git whenever possible, especially for small or personal projects. [0] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying

From your link. The actual issue that people ought to be discussing in this comment section imo.

Re: Git Rebase for the Terrified

#56

Post by CJefferson »

coffeebeqn wrote: post #2

I wish rebase was taught as the default - I blame the older inferior version control software. It’s honestly easier to reason about a rebase than a merge since it’s so linear. Understanding of local versus origin branch is also missing or mystical to a lot of people and it’s what gives you confidence to mess around and find things out

I don't mind rebasing a single commit, but I hate it when people rebase a list of commits, because that makes commits which never existed before, have probably never been tested, and generally never will be.

I've had failures while git bisecting, hitting commits that clearly never compiled, because I'm probably the first person to ever check them out.

Re: Git Rebase for the Terrified

#57

Post by aeinbu »

> I always use VS Code for this step. Its merge conflict UI is the clearest I’ve found: it shows “Accept Current Change,” “Accept Incoming Change,” “Accept Both Changes,” and “Compare Changes” buttons right above each conflict.

I still get confused by vscode’s changing the terms used by Git. «Current» vs «incoming» are not clear, and can be understood to mean two different things.

- Is “current” what is on the branch I am rebasing on? Or is it my code? (It’s my code)

- Is “incoming” the code I’m adding to the repo? Or is it what i am rebasing on to? (Again, the latter is correct)

I find that many tools are trying to make Git easier to understand, but changing the terms is not so helpful. Since different tools seldom change to the same words, it just clutters any attempts to search for coherent information.

Re: Git Rebase for the Terrified

#58

Post by afiori »

aeinbu wrote: post #57

> I always use VS Code for this step. Its merge conflict UI is the clearest I’ve found: it shows “Accept Current Change,” “Accept Incoming Change,” “Accept Both Changes,” and “Compare Changes” buttons right above each conflict. I still get confused by vscode’s changing the terms used by Git. «Current» vs «incoming» are not clear, and can be understood to mean two different things. - Is “current” what is on the branch…

For merges current is the branch you are on, for rebases it helps to see them as a serie of cherry picks, so current would be the branch you would be on while doing the cherry pick equivalent to this step of the rebase.

Re: Git Rebase for the Terrified

#59

Post by afiori »

psychoslave wrote: post #29
embedding-shape wrote: post #17

> The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help. The best method for stop being terrified of destructive operations in git when I first learned it, was literally "cp -r $original-repo $new-test-repo && go-to-town". Don't know what will happen when you run `git checkout -- $file` or whatever? Copy the entire director…

One step further which is in-scope-of-the-tool spirit will be git clone locally your repository. And still one step further, just create a new branch to deal with the rebase/merge. Yes there are may UX pain points in using git, but it also has the great benefits of extremely cheap and fast branching to experiment.

in my experience some of the trickiest situations are around gitignore file updates, crlf conversion, case [in]sentivity, etc. where clones and branches are less useful as a testing ground.

Re: Git Rebase for the Terrified

#60

Post by fc417fc802 »

ngruhn wrote: post #13

Maintaining linear history is arguably more work. But excessively non-linear history can be so confusing to reason over. Linear history is like reality: One past and many potential futures. With non-linear history, your past depends on "where you are". ----- M -----+--- P / ----- D ---+ Say I'm at commit P (for present). I got married at commit M and got a dog at commit D. So I got married first and got a Dog later,…

You omitted the merge commit. M is taken so let's go with R. You jump back to M to confirm that the symptoms really don't predate the marriage. Then you jump to R to reproduce and track down the underlying cause of the bad interaction.

Had you simply rebased you would have lost the ability to separate the initial working implementation of D from the modifications required to reconcile it with M (and possibly others that predate it). At least, unless you still happen to have a copy of your pre-rebase history lying around but I prefer not to depend on happenstance.

Post reply on HN