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

241–248 of 248 posts

Re: Git rebase in depth

#241

Post by guitarbill »

hnthrowaway919 wrote: post #237
guitarbill wrote: post #65

Earlier quoted context omitted.

I used to agree with this, now I've stopped worrying. Because if git is the worst part of your workflow, that's a great problem to have. But at many places, git is the best part. (I've also had to work with various IBM CVS, and they are universally garbage. When I get frustrated at git, all I have to do is think back to those.) So yes, Mercurial is better, but is it worth the effort? Not in my experience.

I know it's popular to shit on anything that isn't git these days, but you mentioned IBM CVS. I've used a couple of them, but primarily RTC (Rational Team Concert). I know that was an IBM acquisition and not a home-grown solution (what wasn't?). I personally prefer some features of RTC over how to do the equivalent in git. Namely, being able to move change sets (think commits) around freely, not having to deal with r…

There was one before RTC, called CMVC, which was truly awful, especially using after 2010 felt like an insult to developer productivity.

I forget all the reasons why RTC isn't great, but the main one: if the server goes down, you're screwed. This happened several times, and we basically went to the pub instead of working. Slow to check out. Streams sucked compared to branches (especially when the server admin restricted creation of streams, meaning you simply could not branch at all if I'm remembering), and the capability to stash changes/switch branches to work on different work items if one was blocked was also more cumbersome. Code review was terrible.

A centralised paradigm does simplify things a lot mentally, but the workflow suffers IMO.

Re: Git rebase in depth

#242

Post by Myrmornis »

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…

Yes, came here to say the same thing.

> If you've made a mistake and in so doing lost commits which you needed, then git reflog is here to save the day.

Seeing that sentence in the article immediately makes me think the author has poor git practices or even understanding. reflog is useful at times, yes. But it is not what saves beginners from losing work while practicing their rebasing skills. What saves them is that they didn't rebase an important branch. They made a temp branch, pointing at the HEAD of their important branch perhaps, and they screwed up the temp branch.

If people would just make this one thing clearer to beginners, it would help a lot of people learn git more easily and with less fear.

Re: Git rebase in depth

#243

Post by gwright »

jojo14 wrote: post #238
Nullabillity wrote: post #167

Earlier quoted context omitted.

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 agree with you, yet I don't understand why you were downvoted. I think git-rebase proponents haven't really ever worked in a professional environment particularly with several co-workers. I as a project manager would not trust a "rebaser" and I would question the time he spent to rewrite the git history. It is granted Merge and rebase need the same amount of reading the code and merging the differences. However wit…

I can't help but feel like you don't understand a work flow that utilizes rebase in a responsible way. In particular you seem to think that the rebase is going to affect the history of a released version of your software (When did the bug happen?).

Nobody is suggesting that rebase be used to change the history of a released or published branch (master, develop etc.). If that is your concern and the reason for you not trusting a "rebaser" then you are simply mistaken, you are arguing against an imaginary workflow for which no one is advocating.

Rebase should be used only to curate the commits on a feature branch and to keep the feature branch synchronized with the upstream branch.

Re: Git rebase in depth

#244

Post by falsedan »

kadoban wrote: post #83
falsedan wrote: post #26

> One of Git's core value-adds is the ability to edit history I didn't make it past this line. git is extremely good at keeping history immutable; it's also good at creating new, alternative histories and moving between them.

Editing history in git is also well supported and very commonly used, and git does it well. It's just not for absolute beginners, and the UI is occasionally not great. If git did not want you to ever change history, filter-branch, rebase, rebase -i, fixups, squashes and a bunch of other inclusions are odd, to say the least.

My point is, git doesn't let you edit history; it lets you make branches easily & the original history remains unaltered. It's trivially easy to detect altered history, and talking about 'editing history' gives the impression that repos are vulnerable to attack.

Re: Git rebase in depth

#245

Post by Dayshine »

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 literally what I was referring to with:

"Pretending the average user will know how to get things back to how they are is silly."

The reflog is faaar more complicated to use that any of the day-to-day git commands.

Re: Git rebase in depth

#246

Post by kadoban »

falsedan wrote: post #244
kadoban wrote: post #83

Earlier quoted context omitted.

Editing history in git is also well supported and very commonly used, and git does it well. It's just not for absolute beginners, and the UI is occasionally not great. If git did not want you to ever change history, filter-branch, rebase, rebase -i, fixups, squashes and a bunch of other inclusions are odd, to say the least.

My point is, git doesn't let you edit history; it lets you make branches easily & the original history remains unaltered. It's trivially easy to detect altered history, and talking about 'editing history' gives the impression that repos are vulnerable to attack.

What wording would you suggest to refer to these kinds of operations? Replacing history?

You mentioned "altered" history, which to me isn't much different from "edited" or "modified", though maybe that was just a slip and not your preference?

There does need to be some term for it. If I push a reordered branch, I clearly did more than nothing, even if we don't want to call that modifying history.

I do question if any term will work perfectly, or if there is any full solution other than one learning git to an intermediate level before discussing it. The problem, as I see it, is that there are (at least) two concepts of history, there is the DAG of commits, where ancestors are older, and there are branch-heads where you can change what they point to in unrestricted ways (pretty much the reflog). I'm not sure English has a really good metaphor that's going to capture everything.

Re: Git rebase in depth

#247

Post by hnthrowaway919 »

guitarbill wrote: post #241
hnthrowaway919 wrote: post #237

Earlier quoted context omitted.

I know it's popular to shit on anything that isn't git these days, but you mentioned IBM CVS. I've used a couple of them, but primarily RTC (Rational Team Concert). I know that was an IBM acquisition and not a home-grown solution (what wasn't?). I personally prefer some features of RTC over how to do the equivalent in git. Namely, being able to move change sets (think commits) around freely, not having to deal with r…

There was one before RTC, called CMVC, which was truly awful, especially using after 2010 felt like an insult to developer productivity. I forget all the reasons why RTC isn't great, but the main one: if the server goes down, you're screwed. This happened several times, and we basically went to the pub instead of working. Slow to check out. Streams sucked compared to branches (especially when the server admin restric…

You certainly make some good points about the downsides of RTC. RTC's streams are often compared to git's branches because they're the closest construct, but they are definitely very different and have pretty minimal overlap, considering they're basically the parallel construct. IMO stashing changes was not bad (suspending change sets, I believe it was called), but perhaps I was mostly doing that within 1 stream and not between streams. I agree that code review was not great, though I'm not a _huge_ fan of GitHub's comment/PR review mechanism either. I'm not aware of code reviewing built in to git itself, though I could be totally missing it.

Re: Git rebase in depth

#248

Post by guitarbill »

hnthrowaway919 wrote: post #247
guitarbill wrote: post #241

Earlier quoted context omitted.

There was one before RTC, called CMVC, which was truly awful, especially using after 2010 felt like an insult to developer productivity. I forget all the reasons why RTC isn't great, but the main one: if the server goes down, you're screwed. This happened several times, and we basically went to the pub instead of working. Slow to check out. Streams sucked compared to branches (especially when the server admin restric…

You certainly make some good points about the downsides of RTC. RTC's streams are often compared to git's branches because they're the closest construct, but they are definitely very different and have pretty minimal overlap, considering they're basically the parallel construct. IMO stashing changes was not bad (suspending change sets, I believe it was called), but perhaps I was mostly doing that within 1 stream and…

> I'm not aware of code reviewing built in to git itself

I guess you can pull a branch or email a patch and diff it with the diff tool of your choice.

There's a few options for gir review UIs, e.g. Gerrit or GitLab. Kind of unix-y, just have the VCS be a good VCS.

Post reply on HN