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

211–220 of 248 posts

Re: Git rebase in depth

#211

Post by mikekchar »

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.

Something like Darcs is probably going to be the next generation. The nice thing about Darcs is that it records patches in an order independent fashion. This means that you can reorder your commits without penalty. This allows you to remove pretty much all problems requiring ninja-like skills to fix in Git. Darcs, has performance problems on merges, though (as a result of its approach). However, I remember a while ago about someone saying they found a solution to the problem. I think they meant to write a new system, but I can't for the life of me remember what it was called.

Anyway, once you get rid of the actual complexity in git, it's an easy step to work on the added complexity to the UI.

Re: Git rebase in depth

#212

Post by alkonaut »

Nullabillity wrote: post #167
gwright wrote: post #166

Earlier quoted context omitted.

It isn't lying. Advocates of rebase are always talking about a work flow where you are curating a set of proposed changes before merging into your "public" branches (.e.g, development or master). No one is advocating that you use rebase on your public branches or basically any branch that has been "published". We are talking about feature branches or spikes or branches that exist just on one developer's machine.

You're lying about the path that you took to get to that point, and you're creating a lot of (public) nonsense commits on the way there (unless you're very careful, and/or overly squash-happy). Whether you've published the true history earlier is irrelevant to that discussion.

I have a very simple solution to this: your feature is at most 1 or 2 commits (after squash) and they can be ff merge when your branch is done. Or it’s too big.

The exception to this is when a feature becomes more involved and has several logical steps, or any kind of history worth providing. This should be rare and when it happens, use merge commits to preserve history.

Not polluting the history with N trivial branches for every 1 branch that needs historical context, is a benefit of this.

Re: Git rebase in depth

#213

Post by sampo »

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…

> All the commits you had in the repo before the rebase are still in the repo.

In your local repo yes, for next 30 days. Then git will garbage collect them. But when you force push new pointers to GitHub, the GitHub repo will lose access to the unreferenced commits right away.

But of course those 30 days will give you plenty of time to go back, if you changed your mind about the rebase.

Re: Git rebase in depth

#214

Post by aldanor »

baddox wrote: post #177
Nullabillity wrote: post #173

Earlier quoted context omitted.

Yes, it is lying. You can mitigate most of the damage if it is convincing enough (for example, go through B' and C' and make sure everything still makes sense at each point), but realistically nobody is going to do that, because it's pretty inefficient way to spend your time. And even then, you're still removing context (unless you're just fixing a typo). > I'm advocating that you use rebase to improve the quality of…

Maybe "lying" isn't the best term to use here, because it seems like you're using it to mean "not providing all information in a way that is morally bad." Of course you're not providing literally all information. Heck, I conceal a lot of information about my development process by testing and changing code before I even make a commit. But I think that's preferable to, for instance, providing a video screen capture of…

Yea. Moreover, I would often ask my coworkers to rebase their code if there’s commits like “oops, missed a comma” because it distracts from the main point when you read the commit history.

Re: Git rebase in depth

#215

Post by fulafel »

Nullabillity wrote: post #160
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…

It's not 'editing' the raw history files, but you're still presenting a false history to your coworkers. To me there are essentially two kinds of rebases: - Summarizing history: squashing "implemented subfeature A.A" and "implemented subfeature A.B" into "implemented feature A" - Rewriting history: moving commits around, changing the base commit, and so on In my opinion summarizing history is acceptable, you're makin…

Yes, good explanation of the problem.

And the cherry on top is that you can't easily tell later if you are looking at rewritten history. So if the above kind of rewriting might have happened in your project, you will essentially not be able to trust git history anymore as a record of engineering decisions.

Re: Git rebase in depth

#216

Post by [deleted] »

pizzapill wrote: post #107

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!"* ]]…

[deleted]

Re: Git rebase in depth

#217

Post by fulafel »

war1025 wrote: post #164
rich-tea wrote: post #36

Earlier quoted context omitted.

What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge. But maybe you use your history for something else that I haven't considered.

History is the cleaned-up story we tell after the fact. The fact that I had a bunch of stupid typos and broken tests that I didn't realize were broken before I committed doesn't need to be in the final history. What I really want for the preserved history is the conceptual chunks of changes I made along the way.

Is this really good for your team and the project?

If you have a safe work atmosphere, and yor teammates reviewing the work can discover pitfalls in your project's workflow, you as a team can have discussions about it can improve your test stuff. And you can maybe go back through the history and see how many times this kind of normal human mistake with other branches and developers.

You can still diff through the PR as a unit before merging, without getting bogged down in low level commits.

Re: Git rebase in depth

#219

Post by pdobsan »

mikekchar wrote: post #211
irrational wrote: post #140

Earlier quoted context omitted.

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.

Something like Darcs is probably going to be the next generation. The nice thing about Darcs is that it records patches in an order independent fashion. This means that you can reorder your commits without penalty. This allows you to remove pretty much all problems requiring ninja-like skills to fix in Git. Darcs, has performance problems on merges, though (as a result of its approach). However, I remember a while ag…

Pijul (https://pijul.org/) is based on a categorical theory of patches (https://arxiv.org/abs/1311.3903). It is similar to Darcs but written in Rust. They claim that Pijul has solved the exponential merge problem. The docs, FAQ, and blogs, in particular the last one, are interesting readings.

Re: Git rebase in depth

#220

Post by kkarakk »

palunon wrote: post #163
lisper wrote: post #155

Earlier quoted context omitted.

Or until you accidentally check in a file that contains a secret. Then the non-destructiveness becomes a serious problem.

Two possibilities there: either your secret was published to others, and it's not a secret anymore, or it wasn't, and you can easily remove it. (Even from your local repo, if necessary remove the relevant blob hash)

Easy to say but a chinese dev went to prison for pushing DJi's secret crypto key to github
Post reply on HN