231–240 of 305 posts
Earlier quoted context omitted.
I manage a maintained fork and periodically rebase our changes on top of upstream. In this case, rebasing is nice because our changes stay in a contiguous block at the top (vs merging which would interleave them), so it's easy for me and others to see exactly where our fork diverges.
Doesn’t that mean you have to fix all the merge conflicts introduced by your commits on every rebase though?
Earlier quoted context omitted.
I don't mind rebasing a single commit, but I hate it when people rebase a list of commits, because that makes commits which never existed before, have probably never been tested, and generally never will be. I've had failures while git bisecting, hitting commits that clearly never compiled, because I'm probably the first person to ever check them out.
Sometimes it feels like the least-bad alternative. e.g. I'm currently working on a substantial framework upgrade to a project - I've pulled every dependency/blocker out that could be done on its own and made separate PRs for them, but I'm still left with a number of logically independent commits that by their nature will not compile on their own. I could squash e.g. "Update core framework", "Fix for new syntax rules"…
Earlier quoted context omitted.
1) because git rerere remembers the resolutions to the .. 2) small conflicts when rebasing the long lived branch on the main branch if instead I delayed any rebasing until the long lived branch was done, I'd have no idea of the scale of the conflicts, and the task could be very, very different. Granted, in some cases there would be no or very few conflicts, and then both approaches (long-lived branch with or without…
If you do a single rebase at the end, there is nothing to remember, you just get the same accumulated conflicts you also collectively get with frequent rebases. Hence I don’t understand the benefit of the latter in terms of avoiding conflicts.
Earlier quoted context omitted.
Using SmartSVN which makes life a fair bit better but still keeps this confusing terminology. We'll be migrating to Git this year though so. For reference, the codebase is over 20 years old, and includes binary dependencies like libraries. Makes it easy to compile old versions when needed, not so easy on the repository size...
That terminology is identical in git, likely inspired by cvs and svn, so that bit probably won't improve. It's inherently confusing to juggle different trees, and clearly you need some terminology for it. At least this one has become a bit of a standard.
Earlier quoted context omitted.
Submodules are cursed. I feel bad for you that you have to work in a repo that uses them.
What is the problem with submodules? I like to use them because it means the code I need from another repo remains the same until I update it. No unexpected breaking changes.
This comment sums up the issues better than I could: https://news.ycombinator.com/item?id=31792396
I see no need to ever rebase manually, just merge on your branch and always fast-forward squash merge (only sane default) with GitHub/GitLab/whatever.
Squash merges are a hacky solution to the git bisect problem that was solved correctly by --first-parent 20 years ago. There are fully employed software developers working on important stuff that literally were never alive in a world where squash merges were needed. Don't erase history. Branch to a feature branch, develop in as many commits as you need, then merge to main, always creating a merge commit. Oftentimes,…
And if I'm using GitHub/Gitlab, I have pull requests that I can look back on which basically retain everything I want from a feature branch and more (like peer review discussion, links to passing CI tests, etc). Using the Github squash merge approach, every commit in the main branch refers back to a pull request, which makes this super nice.
I have been contributing code for 10+ years, and I have worked on teams that did rebase and others that did not. Not once have a ever debugged a problem that benefited from rebase vs merge. Fundamentally, I do not debug off git history. Not once has git history helped debug outside of looking at the blame + offending PR and diff. Can someone tell me when they were fixing a problem and they were glad that they rebased…
Earlier quoted context omitted.
>each commit nominally should work Except it can be the result of 10 squashed commits.
Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.
Earlier quoted context omitted.
> Debugging from git history is a separate question from merge vs rebase. But the main benefit proponents or rebase say its for keeping the history clean which also makes it easier to pinpoint and offending commit. Personally, a clean commit history was never something that made my job easier. > Other than that this workflow allows you to create a history of very small, easily testable, easily reviewable, easily reve…
> Personally, a clean commit history was never something that made my job easier. How do you define "clean"? I've certainly been aided by commit messages that help me identify likely places to investigate further, and hindered by commit messages that lack utility.
In the context of merge vs rebase, I think "clean" means linear, without visible parallel lines. Quality of commit messages is orthogonal. I agree with the poster that this particular flavor of "clean" (linear) has never ever helped me one bit.
Earlier quoted context omitted.
> Debugging from git history is a separate question from merge vs rebase. But the main benefit proponents or rebase say its for keeping the history clean which also makes it easier to pinpoint and offending commit. Personally, a clean commit history was never something that made my job easier. > Other than that this workflow allows you to create a history of very small, easily testable, easily reviewable, easily reve…
we're in the minority I think. I always find it easier to just debug a problem from first principles instead of assuming that it worked at some point and then someone broke it. often times that assumption is wrong, and often times the search for bad commit is more lengthy and less informative than doing the normal experimental process. I certainly admit that there are ases where the test is easily reproducible and bi…
Me neither, for what is worth. But even if the idea is "when in order to figure out this issue, you have to go to the history", a linear history and a linear log never helped me either. For example, to find where a certain change happened to try to understand what was the intent, what I need is the commit and its neighbors, which works just as well with linear vs branching history because the neighbors are going to still be nearby up and down, not found via visual search.