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

301–305 of 305 posts

Re: Git Rebase for the Terrified

#301

Post by cluckindan »

tsimionescu wrote: post #277
cluckindan wrote: post #266

Earlier quoted context omitted.

So use --merges when browsing main.

You'll still get interleaved commits. If I work on a branch for a week, committing daily and merging daily from main, when I merge to main, git log will show one commit of mine, then 3 from someone else, then another of mine, etc. The real history of the main branch is that all my commits went in at the same time, after seven days, even if some of them were much older. Rebase tells the real story in this case, merge…

  git log --oneline --graph --first-parent

Re: Git Rebase for the Terrified

#302

Post by agumonkey »

fc417fc802 wrote: post #50
agumonkey wrote: post #24

Earlier quoted context omitted.

there are others tricky time issues with staging/prod parallel branching models too, the most recent merge (to prod) contains older content, so time slips .. maybe for most people it's obvious but it caused me confusion a few times to compare various docker images

> the most recent merge (to prod) contains older content Can't that also happen with a rebase? Isn't it an (all too easy to make) error any time you have conflicting changes from two different branches that you have to resolve? Or have I misunderstood your scenario?

hmm my experience didn't even require rebase to cause me troubles (but again, it was 90% pebcak). it's possible rebasing can cause time confusion, maybe you can describe in more detail what you had in mind, i cannot guess on my own but i'm curious

Re: Git Rebase for the Terrified

#303

Post by Groxx »

Akranazon wrote: post #3
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

The end result of a git rebase is arguably superior. However, I don't do it, because the process of running git rebase is a complete hassle. git merge is one-shot, whereas git rebase replays commits one-by-one. Replaying commits one-by-one is like a history quiz. It forces me to remember what was going on a week ago when I did commit #23 out of 45. I'm grateful that git stores that history for me when I need it, but…

>Replaying commits one-by-one is like a history quiz. It forces me to remember what was going on a week ago when I did commit #23 out of 45.

While I agree this is a rather severe downside of rebase... if you structure your commits into isolated goals, this can actually be a very good thing. Which is (unsurprisingly) what many rebasers recommend doing - make your history describe your changes as the story you want to tell, not how you actually got there.

You don't have to remember commit #23 out of 45 if your commit is "renamed X to Y and updated callers" - it's in the commit message. And your conflict set now only contains things that you have to rename, not all renames and reorders and value changes everything else that might happen to be nearby. Rebase conflicts can sometimes be significantly smaller and clearer than merge conflicts, though you have to deal with multiple instead of just one.

Re: Git Rebase for the Terrified

#304

Post by Groxx »

Liskni_si wrote: post #286
Groxx wrote: post #271

Earlier quoted context omitted.

I've seen that you can read one commit at a time, but never anything for reviewing (or diffing between them if they change) - is there a UI beyond just clicking on the list of commits? Though I forget if you can even comment in the individual commits in that view. Complex multi-commit PRs have generally been a nightmare on GitHub in my experience.

You can comment on the individual commits' changes, but you can't comment on the commit (e.g. its message) itself. I believe you can do this in Gerrit.

Which means it's probably all I have seen - so you can't approve commits either, or track file-reading progress through commits (I think? i.e. "viewed file X at commit Y, but not at commit Z"), or diff changes to a commit (e.g. by order/message) after a rebase, just "you can see the current commit history". Not sure I'd consider that "can review one commit at a time", just "can read one commit at a time". "Review" means "there is support for this thing as a first class entity" imo, and that ain't what github is offering, nor anything even close to it.

Re: Git Rebase for the Terrified

#305

Post by mathstuf »

Why does it always feel so black-and-white? On our projects we do rebases all the time so that topic history is clean. But we merge into the target branch(es) (our merge bot supports merging to old release branches from a single MR). This gives us:

- clean integration branch histories (series of merge commits) - merge commits can contain metadata (topic-level descriptions, trailers for who reviewed, merge request links, test results, etc.) - you can be (pretty) sure that `git bisect --first-parent` will not run into any compilation problems (logical conflicts occur, but are fairly rare; use merge queues to be sure) - none of the "you merged main into your topic" "backwards merges" to deal with too

Merging and rebasing each have their pros and cons, so why not use the pros of each and mitigate a lot of the cons at the same time.

Post reply on HN