Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitButler now supports first class conflicts, making rebasing less annoying

blog.gitbutler.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: GitButler now supports first class conflicts, making rebasing less annoying

#111

Post by imiric »

lmm wrote: post #101
imiric wrote: post #79

Earlier quoted context omitted.

> The fears are legitimate. They're really not. First of all, no data is really lost with Git. Commits can be recovered from the reflog if they haven't been garbage collected, and there are ways of recovering anything on GitHub as well[1], even if it technically shouldn't be the case. But this aside, data loss is circumstantial, like you say. I've heard the idea that force-pushing in general is harmful, when it's rea…

> First of all, no data is really lost with Git. Commits can be recovered from the reflog if they haven't been garbage collected So no data is really lost except when it is. > I've heard the idea that force-pushing in general is harmful, when it's really not if you're working solo or on an isolated branch. Rebasing and force-pushing are just different tools in the toolbox. Like I said, there are specific circumstance…

> So no data is really lost except when it is.

The period before inaccessible objects are pruned automatically is quite relaxed by default (between 2 weeks and 90 days, depending on the object), and it is configurable. So the scenario we're discussing here where data is lost by a force-push is just not a practical concern.

> Like I said, there are specific circumstances where you can do it safely. But that's very different from being safe in general.

No, force-push is safe _in general_. It is a bit inconvenient to recover the inaccessible commits if someone makes a mistake, but this doesn't make rebasing or force-pushing unsafe.

> Users can't and won't learn the full details of everything they use, especially "secondary" tools that they use to support their main workflow

Huh? How is Git a "secondary" tool for a programmer? It is an essential part of the programmer's toolkit as much as an editor is, and understanding and being proficient with both is equally important. Users in this case should be expected to learn the tools they will be relying on for a large part of their career. Compared to the complexity of programming environments, stacks and languages we deal with on a daily basis, this tooling is fairly simple to grasp.

I'm not saying that Git doesn't have issues that can't be improved—it certainly does—but in the grand scheme of things it is a simple, reliable and well-engineered piece of software.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#112

Post by keybored »

kazinator wrote: post #60
keybored wrote: post #17

Earlier quoted context omitted.

It isn’t always harder than doing a merge. > really paid off in engineering terms? When you want your changes accepted by upstream and they either 1. Won’t accept a merge-filled history 2. Indirectly won’t because they accept changes by email (can’t send merges by email)

The main reason they should not accept merges is that they don't care about you and your repo . In order for an upstream repo to accept your work as a git merge, they would have to fetch all your objects so that they have enough of your repo in order to represent your original branch, where the parent pointers of the merge are aimed. Nobody who is anywhere near sane wants that kind of cruft.

I don’t understand the distinction you’re making compared to what I wrote.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#113

Post by keybored »

_ugfj wrote: post #23

I must admit I usually immediately disregard any fancy new git tools, they come and go and often don't work right and create a gigantic mess. But... have you seen who wrote this article? Scott Chacon. If there's anyone in this world whose article would make me try a new git tool, it's him. He wrote the Pro Git book, Git Internals. Oh and cofounded GitHub. This is not argument from authority fallacy. This is "hey! thi…

It’s precisely that which makes me skeptical of it.

> For better or worse, my experience as a GitHub cofounder and author of several Git books (Pro Git, etc) is that the Git commit message is a unique vector for code documentation that is highly sub-optimal.

> ...

> I don't know exactly what the answer is, but the sad truth of Git is that writing amazing documentation via commit message, for most communities, is almost entirely a waste of time. It's just too difficult to find them.

https://news.ycombinator.com/item?id=39218538

Re: GitButler now supports first class conflicts, making rebasing less annoying

#114

Post by hughesjj »

hinkley wrote: post #70
hughesjj wrote: post #67

Earlier quoted context omitted.

This argument seems weird to me because even without rerere I found myself doing a lot more work managing merge conflicts with git merge instead of git rebase As a git merge fan, are there any tips or tricks you suggest beyond the stock git experience when doing git merge to minimize the amount of merge conflicts you get? I found it was especially bad when doing a git merge on a refactor, but I admit it could just be…

Most of the time I've encountered two engineers pointing fingers about who is responsible for a bug, it turns out that someone's bad merge transferred the git annotation from one engineer to another. The first time this happened (that I caught) I had two engineers who were sniping at each other. One was older "Max" and not great at data structure algorithms. The other "Stan" was a decent coder but had a bad attitude…

That sounds like Stan was rebasing someone else's work though?

And wait was Stan rebasing main?

I mean yeah, in that case it's definitely, definitely wrong to use rebase. In general though I always rebase my feature branch and only then merge it into main. Because it's rebased onto the head of main and thus a linear series of commits, there's no merge conflicts to fix.

Re: GitButler now supports first class conflicts, making rebasing less annoying

#115

Post by Arelius »

kazinator wrote: post #58
Arelius wrote: post #42

Earlier quoted context omitted.

Did you ever try bisection without the linear history to compare? Or was this just conjecture?

I have. It was a complete fucking shitshow. In a kernel tree, doing a git bisect with the messy merge history will take you on a wild goose chase, where you land in some branch developed by an entirely different team somewhere, working on totally different hardware from you, with a different kernel version, which you have no hope of building and booting.

Hmm, as I think about this, I'm unconvincing it's specifically a problem with merges specifically.

If you were bisecting a rebase workflow and hit a block of commits that were unbuildable and unbootable close to your breakage, I'm unsure how you would progress.

But the case is likely better in the merge workflow, since in all likelihood you could mark the entire tree as good, and it could stop searching all ancestors. Which is far more likely to be correct in a merge workflow.

I feel like it's most likely that bisecting the linux kernel was in-fact the shotshow.

Edit: upon further research, it appears that git bisect is a commonly used and useful tool in the kernel, and the correct response to landing in that branch would be `git bisect skip` which should be far more informative to the algorithm then a skip in a linear history https://nathanchance.dev/posts/working-with-git-bisect/

Re: GitButler now supports first class conflicts, making rebasing less annoying

#116

Post by kazinator »

wakawaka28 wrote: post #30
hinkley wrote: post #21

Earlier quoted context omitted.

I spend a lot of time cleaning up after people who insist there are no b problems in their code despite all evidence to the contrary. That work is easier when they haven’t squashed their changes. Because I can see how they got there and if it was a mistake or a misunderstanding. People who prefer squash are an automatic red flag because they usually don’t like asking Why, which is a very important skill on products t…

>That work is easier when they haven’t squashed their changes. Because I can see how they got there and if it was a mistake or a misunderstanding. That sounds like a problem with the people you work with, not with squashing in general. >People who prefer squash are an automatic red flag because they usually don’t like asking Why, which is a very important skill on products that are shipping and making money. This is…

Nope. Jamming together related changes is bad also.

Now, of course, someone who makes a new commit every time they make a minor change, like three commits to fix three spelling errors in a comment, should be squashing that. That's a strawman.

Changes that serve a different logical purpose in a related change set should be separate.

Post reply on HN