I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
Unfortunately, git rebase has a very very annoying limitation that git merge doesn't. If you have a branch with, say, masterX + 10 commits, and commit 1 from your branch is in conflict with masterX+1, then when you rebase your branch onto masterX+1, you will have to resolve the conflict 10 times (assuming all 10 commits happen in the same area that had the original conflict). If instead you merge masterX+1 onto your…
Extremely Linear Git History
301–310 of 366 posts
Re: Extremely Linear Git History
#302Github-style rebase-only PRs have revealed the best compromise between 'preserve history' and 'linear history' strategies: All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you've tested each commit independently), otherwise squash. If you want more detail about the development of the PR…
I wholeheartedly agree! With this, you can also push people towards smaller PRs which are easier to review and integrate. The downside is that if you és o work on feature 2 based on feature 1,either you wait for the PR to be merged in main (easiest approach) or you fork from your feature branch directly and will need to rebase later (this can get messier, especially if you need to fix errors in feature 1).
Second part explains exactly what I'm juggling with right now.
Re: Extremely Linear Git History
#303Earlier quoted context omitted.
Can I asked how they converted you (or do you mean by dictate, as opposed to becoming convinced it was better)? I find myself loving merges and never using rebases. It's not that I cannot describe technically what's happening, but I just don't understand the love.
(Not the person you replied to, but a passionate rebase-preferred) For me there are two reasons - one aesthetic, one practical. The aesthetic reason is that it tells a more coherent story. The codebase is a single entity, with a linear history. If I asked you "how old were you last year", and you asked "which me are you asking about?", I'd be confused. Similarly, if I want the answer to the question "what was the cod…
> what was the codebase like at this point in time // immediately prior to some point?", you shouldn't need to ask clarifying questions
I would assume that such a question would talk only about the main branch. However, I will point out that "what was the state of feature X" is only answerable with a non-linear story.
> The practical reason is that it discourages a bad-practice - long-lived branches.
Wait, long-lived branches are bad? Merging in partially done features is good? That seem insane.
First, if the feature is small enough to knock out in an hour, that's great. But sometimes it can take a couple of days. I should hope you have enough activity that the main branch will move in that time.
But committing partial features is crazy. Sometimes you realize the way you are implementing it (or the whole feature) is a bad idea and all the work should be orphaned. Other times, a feature requires changing something (e.g. an API) where a partial change cannot really work - and sometimes where you need to have a meeting before you do it. Consider the feature to be "update dependency X", which means you now have some number of bugs to track down due to the new verison.
Heck, sometimes a feature might need to be mothballed. Sometimes you have to wait for an external dependency to be fixed. And you can chuck your work, commit something broken, mothball it and come back when the external dependency is fixed or switch your dependency.
Re: Extremely Linear Git History
#304Earlier quoted context omitted.
Can I asked how they converted you (or do you mean by dictate, as opposed to becoming convinced it was better)? I find myself loving merges and never using rebases. It's not that I cannot describe technically what's happening, but I just don't understand the love.
In my case, I switched rapidly to git-rebase because it produces history that is much cleaner and easier to understand. I only do merge if there is a good reason to preserve history (e.g. some other branches depend on it, or some test reports refer to a given commit).
I guess I find it easier to parse with feature branches than all on main.
Re: Extremely Linear Git History
#305Earlier quoted context omitted.
To me that seems messier than a new branch. For one, how are others to know my files are test/scratch/feature branch files? I'd have to use a naming scheme, and some kind of other signal to make sure nobody imports them before they're ready or mistakes them for deployable files - and at that point I'm just replicating a branch!
> and at that point I'm just replicating a branch! Yes. My entire point is that you can always replicate branches with actual, explicit files, and that this is a good thing to do because files are (very often) better than branches. Files plus some editor discipline are essentially equivalent to branches. Files+discipline are better than branches, according to standard unix philosophy: (1) everything is a file, (2) pr…
Discipline is policy, not protocol.
Re: Extremely Linear Git History
#306Re: Extremely Linear Git History
#307Earlier quoted context omitted.
if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.
Totally on board (except the forbidden -a switch). The last command is: cp .git/refs/heads/feature .git/refs/heads/main No merge needed.
git reset --hard main featureRe: Extremely Linear Git History
#308Github-style rebase-only PRs have revealed the best compromise between 'preserve history' and 'linear history' strategies: All PRs are rebased and merged in a linear history of merge commits that reference the PR#. If you intentionally crafted a logical series of commits, merge them as a series (ideally you've tested each commit independently), otherwise squash. If you want more detail about the development of the PR…
Did you even read the article? This article is about perversely forcing the commit hashes to come out a certain way for lulz.
Re: Extremely Linear Git History
#309Proof of work git hashes. This is nuts and I love it.
Re: Extremely Linear Git History
#310Earlier quoted context omitted.
In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine. It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.
> It seems like a very contrived example to me. I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase…
> arguably I shouldn't have all these long-lived branches in the first place (but it works well for me, so...)
Given that this scenario is common for you but sounds contrived to others, I would argue that this doesn't work well for you. It's just familiar enough that you're willing to deal with some pain.
Short-lived feature branches sidestep this hell. Longer-lived projects can almost always be partitioned into a series of shorter mergeable steps. You may need support/buy-in from your manager, I hope you get it.