Just do a normal merge, then squash all your commits in into one, using rebase, then a rebase onto a branch is easy.
Git Rebase for the Terrified
71–80 of 305 posts
Re: Git Rebase for the Terrified
#72Allow me (today) to be that person to propose checking out Jujutsu instead [0]. Not only it has a superpower of atomic commits (reviewers will love you, peers will hate 8 small PRs that are chained together ;-)) but it's also more consistent than git and works perfectly well as a drop-in replacement. In fact, I've been using Jujutsu for ~2 years as a drop-in and nobody complained (outside of the 8 small PRs chained t…
And `jj undo`, so nothing is terrifying.
Re: Git Rebase for the Terrified
#73> 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.
Yeah, works for normal "lets try out what happens when I do this" but it can get messy, depending on what you're trying out. That's why I always recommended beginners to literally "cp -r" the entire directory instead, together with the git repository, so they can feel freer to completely experiment and not be afraid of loosing anything.
I guess it's actually more of a mental "divider" than anything, it tends to relax people more when they can literally see that their old stuff is still there, and I think git branches can "scare" people in that way.
Granted, this is about people very new to git, not people who understands what is/isn't destructive, and just because a file isn't on disk doesn't mean git doesn't know exactly what it is.
Re: Git Rebase for the Terrified
#74Earlier 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…
Merging merge requests as merge commits (rather than fast-forwarding them) gives the same granularity in the main branch, while preserving the option to have bisect dive inside the original MR to actually find the change that made the interesting change in behavior.
I wish github created automation for this flow like they have for other variants.
Re: Git Rebase for the Terrified
#75> 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…
whoa. well, if it really works for you. The thing is, git has practically zero "destructive" commands, you almost always (unless you called garbage collector aggressively) return to the previous state of anything committed to it. `git reflog` is a good starting point. I think i've seen someone coded user-friendlier `git undo` front for it.
I expanded on it more here: https://news.ycombinator.com/item?id=46601600
TDLR is: people feel safer when they can see that their original work is safe, while just making a new branch and playing around there is safe in 99% of the cases, people are more willing to experiment when you isolate what they want to keep.
Re: Git Rebase for the Terrified
#76Earlier quoted context omitted.
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.
I disagree, without this info, I can't easily tell if any commit is part of a feature or is a simple hotfix. I need to rely on the commiter to include the info in the commit message, which is almost always not the case.
Nothing stops you from doing both renade and merge commits.
Except perhaps crappy gui options in GitHub. I really wish they added that option as a button.
Re: Git Rebase for the Terrified
#77Earlier quoted context omitted.
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.
THIS is the hill I will die on.
Why do we advocate destroying information/data about the dev process when in reality we need to solve a UI/display issue?
The amount of times in the last 15ish years I've solved something by looking back at the history and piecing together what happened (eg. refactor from A to B as part of a PR, then tweak B to eventually become C before getting it merged, but where there are important details that only resulted because of B, and you don't realize they are important until 2 years later) is high enough that I consider it very poor practice to remove the intermediate commits that actually track the software development process.
Re: Git Rebase for the Terrified
#78I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not.
Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff.
Can someone tell me when they were fixing a problem and they were glad that they rebased? Bc I can't.
Re: Git Rebase for the Terrified
#79I 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
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…
> I know a lot of people want to maintain the history of each PR, but you won't need it in your VCS.
Having worked on a maintenance team for years, this is just wrong. You don't know what someone will or won't need in the future. Those individual commits have had extra context that have been a massive help for me all sorts of times.
I'm fine with manually squashing individual "fix typo"-style commits, but just squashing the entire branch removes too much.
Re: Git Rebase for the Terrified
#80I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…
The main benefit I've found is when there is work happening concurrently in multiple feature branches at once (e.g. by different people). Rebase-merging greatly simplifies dealing with merge conflicts as you only have a simple diff against a single branch to deal with. The more work you have in progress at once the more important this becomes.