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

91–100 of 248 posts

Re: Git rebase in depth

#91

Post by gwright »

rusk wrote: post #76
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…

I'd suggest creating the branch before the rebase: $ git co feature-branch $ git branch before-rebase-feature-branch $ git rebase develop

Worthwhile if you anticipate something going wrong, but usually things are just fine or a `git rebase --abort` will get you back to a safe place (if you are using an interactive rebase).

Re: Git rebase in depth

#92

Post by chris_mc »

Sir_Cmpwn wrote: post #28
dbaupp wrote: post #19

The 'push -f' suggestion could instead recommend 'push --force-with-lease' to be less error prone in case one is accidentally pushing to a concurrently modified branch. Also, unless the diagram is confusing with the alignment, the "rebase to rebase" example seems to be implicitly assuming --onto, because the last common ancestor of 'master' and 'feature-2' includes 2 commits on that branch: the first of 'feature-1' a…

I've heard this before, but I felt that `--force-with-lease` requires a lengthier explanation in an an already intimidating article, is harder to type, and generally isn't useful for users of the Sourcehut workflow. It's definitely a useful tool, though. Maybe I should add a footnote.

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.

Re: Git rebase in depth

#93

Post by ergothus »

pjc50 wrote: post #85
ergothus wrote: post #41

Earlier quoted context omitted.

This is probably where I foul up. My last few workplaces were either not git, or relied on git pull w/o rebase. My current workplace has rebase as part of their flow, and I find that, like, 60% of my PRs require force push, which bothers me greatly. Everyone else just shrugs and considers it part of business, but I know what I WANT to do should be nicely aligned and not encounter that problem. Unfortunately, every ex…

That does sound like they're doing it wrong. Could you give an example?

> Could you give an example?

To the degree I understand it, sure:

We have master branch A

I create a feature branch B

Both get updates. Someone will do a rebase of B to the most-recent A and push that. (In my previous workplaces they would have just pulled the most recent A)

Here's where the confusion comes in: If I get the updated B but A has updated again, I cannot pull A nor rebase to A and successfully push the result without forcing. IIRC, on push it complains that my local branch is not up to date, but if I pull it will tell me I am up to date.

At least, that's what I think is the timing - since this involves multiple people I'm uncertain of what exactly occurs and the order, nor why problems are inconsistent. We don't have that many feature branches that have multiple people contributing AND requiring updates from the master branch, but it happens often enough.

Re: Git rebase in depth

#94

Post by thanatos_dem »

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

Once I learned about the reflog I got a lot more adventurous with git. Now I’m the “git expert” in my team.

Re: Git rebase in depth

#95

Post by zemo »

mixmastamyk wrote: post #67
nothrabannosir wrote: post #33

Earlier quoted context omitted.

Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful for debugging, but it does require your commits to be as healthy as possible. If you fix a bug 10 commits after it was introduced , now the 10 commits between them are harder to work with; you always have to keep in mind that unrelated bug. And cherry picking…

Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time. As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure. This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average dev…

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 authorship of commits, not the utilization of the project's history. I've found a rebase-oriented workflow to result in a significantly more usable repository inasmuch as the history is significantly easier to understand.

Re: Git rebase in depth

#96

Post by AlexTWithBeard »

dahart wrote: post #74
AlexTWithBeard wrote: post #70

Earlier quoted context omitted.

The main problem with git is that it tries to be two things at once: a change management system and a version control system. For the former you want flexible history, distributed repos and freedom to do whatever you want. For the latter the history should be sacrosanct and the repository is better be more or less centralized. git tries to sit on both chairs and therefore has to adapt a quite awkward position.

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 destroy this history no matter what I do. The history should be backed up in a remote location.

With git every once in a while these two come into conflict: I'm using my branch as a change management system and then someone else pulls that branch and makes a couple of changes on it. Then I force push and the mess begins.

Regarding centralized repository: say, I have two working copies. In goode olde subversion there was the "master" version in trunk and two local versions, one per working copy. Three versions altogether. Pretty clear which is which.

Now in git I have:

- master in origin repo

- origin/master in wc1

- master in wc1

- actual file in wc1

- all the same in wc2

Seven potentially different versions of the same exact file. That's even without mentioning a stash.

Re: Git rebase in depth

#97

Post by rgoulter »

rich-tea wrote: post #36
jaequery wrote: post #23

FWIW i've never really needed rebase. i am pretty happy with seeing all the commits that ever happened.

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.

While I like the idea of rearranging commits to convey a nice (but "not how it originally happened") development sequence, I think in practice this matters less than (say) good commit messages, or the difference between merging and rebasing.

(--fixup type commits aside).

Practical benefits from not squashing history:

- Can bisect to find bug introduction.

- Can annotate/praise/blame to find who/when some change was made.

- Adam Tornhill's "Code as a Crime Scene" argues that it'd be beneficial to consume VCS history to provide health metrics on the codebase. (e.g. use VCS to check which sources have many contributors (thus potentially high defects), or check for "lost knowledge" from developers who have left).

- Can build/run an older version of the software.

But is there really a big advantage from putting time into maintaining a sequence of commits? EDIT: Ah, I see another comment point out that "maintaining a nice history" tends to mean fixing very borked commits. That makes sense. :-)

Re: Git rebase in depth

#98

Post by mixmastamyk »

Sir_Cmpwn wrote: post #89
mixmastamyk wrote: post #71

Earlier quoted context omitted.

Most shops don't follow good software design practices, so how likely is it to get a practice one-step-removed from that, with a difficult UI to boot, adopted?

So you're saying we shouldn't argue for the adoption of good software design practices? There are a lot of software teams that do care, you know.

But this isn't that. It's one step removed. Maybe if the UI gets better. Even then an uphill battle.

Re: Git rebase in depth

#99

Post by mixmastamyk »

zemo wrote: post #95
mixmastamyk wrote: post #67

Earlier quoted context omitted.

Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time. As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure. This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average dev…

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.

Re: Git rebase in depth

#100

Post by recursive »

chris_mc wrote: post #92
Sir_Cmpwn wrote: post #28

Earlier quoted context omitted.

I've heard this before, but I felt that `--force-with-lease` requires a lengthier explanation in an an already intimidating article, is harder to type, and generally isn't useful for users of the Sourcehut workflow. It's definitely a useful tool, though. Maybe I should add a footnote.

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".
Post reply on HN