5 ms·

> you might as well just use SVN I've got a feeling you are not being fully serious, so on that assumption instead of me explaining why this really not at all

by patrec 6y ago

> you might as well just use SVN I've got a feeling you are not being fully serious, so on that assumption instead of me explaining why this really not at all the case, how about you provide an example of a workflow that you think crucially depends on merging rather than rebasing, and we can discuss that? > Bisect works fine. Could you be more specific? Sure: given a test command, show me a simple git bisect invocation that finds the merge commit that broke master. > things that are released together should go in the same repo, while things with separate lifecycles should have their own repositories. I think this is a useful criterion, but one that tends to be only clear-cut for things like shrinkwrapped software (and it's not the only thing that matters). If you run a service of any complexity and with any sort of uptime requirements, you will not ship everything together, even if its part of a single feature and often you will have different versions of the same service in production in parallel as well. Al > if a project depends on a previous release of an internal library, it's misleading to have that internal library in the same repository as that project, because you'd see the "current" version rather than the code you were actually using A strange objection. Surely the point of having a super-repo would be that the subrepos at any one commit in the super repo would form a consistent state of the world, rather than you pinning inconsistent versions of different repos in the same commit of your super-repo? > I don't want to think about different parts of the checkout being on different revisions, branches, or tags At the most basic level you could think about the sup-repos like a pinned (yarn, poetry, budler, ...) dependencies and the super-repo as a lockfile with extra benefits (such as 'git diff HEAD^' presumably showing you all the source changes in the sub repos since the last time you committed their versions in the super-repo). If you are not directly working on code in any of the sub repos, you simply don't have to care about their different revisions, branches or tags. If you do want to make a change in one of the subrepos with a view to landing this change in the super-repo as well, it is true that you will probably create a new branch in first the subrepo, have that merged and then create a branch in the super-repo that switches it to the new version. But presumably the reason you don't just have a mono-repo to start with is because there is some degree of indepdendence (such as your proprietary app depending on an open source lib you also maintain). One realistic example from the open source world might be something like OpenBSD which is (if I remember right, apologies if I got something wrong) developed in one big (csv?) mono repo and that also includes all the bits that have made it into the wider unix eco system like OpenSSH or libreSSL. The cross platform versions of these are developed out of stream by people periodically pulling the whole OpenBSD repo as canonical upstream, copying the relevant subset of stuff across, updating their compatibility layers and pushing it to separate repos that contain just OpenSSH (or whatever). Presumably depending on goals and priorities, having OpenSSH be a sub-repo instead would offer benefits to at least some of the people involved (assuming a well designed sub-repo mechanism).

user-the-name 6y ago
> I've got a feeling you are not being fully serious, so on that assumption instead of me explaining why this really not at all the case, how about you provide an example of a workflow that you think crucially depends on merging rather than rebasing, and we can discuss that? Well, any workflow that wants to actually keep history, and that doesn't want to be littered with strange, possibly broken commits?
- patrec 6y ago
  If you are genuinely worried that rebasing a feature branch into master will somehow corrupt the precious bodily fluids of your commits, reading a book on git will probably be the most immediately effective means to avoid littering everything with strange, possibly broken commits. We all want to actually keep history, but unless you have set your IDE up to do a commit on every keypress there probably is also some subset of history you do not in fact wish to keep. So the question becomes what history should one preserve, and here opinions can legitimately differ. What I would suggest, at minimum, is not allowing force pushes to master or any other branches that you consider as "published" (internally or externally) -- easy to enforce on basically any git hosting solution or via a server hook. However this is a completely orthogonal question to choosing a rebase or merge based workflow. If master moved from my local branch, and I do a merge of a feature branch and force push, upstream history will get lost (baring a copy in the reflog or elsewhere).
  - user-the-name 6y ago
    What I believe is that rebase creates entirely new and untested code states, that have zero guarantees of working or building, and that can in fact quite easily be entirely invalid.
    - patrec 6y ago
      You may believe so, but it's not true. Let me explain. There are two somewhat different use cases for rebasing: 1. You want to do the equivalent of a merge without creating a merge commit, which is what I was mostly talking about when I was contrasting a merge based with a rebase based workflow. There is precisely zero difference in guarantees of things working or building or whatever between you rebasing or merging a branch into master. In fact, funnily enough, if you actually do testing/CI correctly, issuing a "git merge feature-branch" command to land things in master will, with high likelihood do a rebase rather than creating a merge commit. This is because you will have pre-merged (or equivalently, as far as testing the right thins is concerned, rebased) master into your feature branch first. Because that's the only way to actually test the right thing (the state of the code as it will be once it lands it master). 2. You can use rebase to (potentially wildly) rewrite individual commits (splitting them up, re-arranging or melding or editing them etc.) on your feature branch. This is not what I'm talking about, but, I have the feeling, the thing you are actually objecting to. And yes, you can indeed mess up previously working commits this way. If you feel uncomfortable doing this, just don't -- you can still use (and profit from) a purely rebase based workflow.[+] [+] As an aside: there are ways of doing this type of rewriting that give you guarantees of working and building -- e.g. just run git rebase --exec "make clean && make test" ... (each individual commit in the rebase is tested before landing and the rebase stops on anything that errors out)[++]. But as I mentioned, you can still get all the benefits of a rebase-based workflow without ever engaging in this type of rebasing, and similarly you can have a fully merge-based workflow (for landing things in master) and people might still wildly rebase-to-rewrite their commits on their feature branches (and if they are not even pushed, who's gonna stop them?). These things are really orthogonal. Also, whilst I agree that undisciplined rewriting of commits is a bad idea, and can mess up previously working non-HEAD commits, it should never mess up the final commit on a feature branch undetected. Because you're running CI, right?. And at the end of the day almost no workflow will run full tests/CI on every commit (too expensive for anything but small projects), so broken "intermediate" commits can even happen without rebasing and if you do in fact run CI on every commit, well even undisciplined rebasing is perfectly safe. [++] Also: I'd recommend preferring git commit --fixup to wildy messing about with git rebase -i on the fly.

by patrec 6y ago

user-the-name 6y ago

> I've got a feeling you are not being fully serious, so on that assumption instead of me explaining why this really not at all the case, how about you provide an example of a workflow that you think crucially depends on merging rather than rebasing, and we can discuss that? Well, any workflow that wants to actually keep history, and that doesn't want to be littered with strange, possibly broken commits?

patrec 6y ago
If you are genuinely worried that rebasing a feature branch into master will somehow corrupt the precious bodily fluids of your commits, reading a book on git will probably be the most immediately effective means to avoid littering everything with strange, possibly broken commits. We all want to actually keep history, but unless you have set your IDE up to do a commit on every keypress there probably is also some subset of history you do not in fact wish to keep. So the question becomes what history should one preserve, and here opinions can legitimately differ. What I would suggest, at minimum, is not allowing force pushes to master or any other branches that you consider as "published" (internally or externally) -- easy to enforce on basically any git hosting solution or via a server hook. However this is a completely orthogonal question to choosing a rebase or merge based workflow. If master moved from my local branch, and I do a merge of a feature branch and force push, upstream history will get lost (baring a copy in the reflog or elsewhere).
- user-the-name 6y ago
  What I believe is that rebase creates entirely new and untested code states, that have zero guarantees of working or building, and that can in fact quite easily be entirely invalid.
  - patrec 6y ago
    You may believe so, but it's not true. Let me explain. There are two somewhat different use cases for rebasing: 1. You want to do the equivalent of a merge without creating a merge commit, which is what I was mostly talking about when I was contrasting a merge based with a rebase based workflow. There is precisely zero difference in guarantees of things working or building or whatever between you rebasing or merging a branch into master. In fact, funnily enough, if you actually do testing/CI correctly, issuing a "git merge feature-branch" command to land things in master will, with high likelihood do a rebase rather than creating a merge commit. This is because you will have pre-merged (or equivalently, as far as testing the right thins is concerned, rebased) master into your feature branch first. Because that's the only way to actually test the right thing (the state of the code as it will be once it lands it master). 2. You can use rebase to (potentially wildly) rewrite individual commits (splitting them up, re-arranging or melding or editing them etc.) on your feature branch. This is not what I'm talking about, but, I have the feeling, the thing you are actually objecting to. And yes, you can indeed mess up previously working commits this way. If you feel uncomfortable doing this, just don't -- you can still use (and profit from) a purely rebase based workflow.[+] [+] As an aside: there are ways of doing this type of rewriting that give you guarantees of working and building -- e.g. just run git rebase --exec "make clean && make test" ... (each individual commit in the rebase is tested before landing and the rebase stops on anything that errors out)[++]. But as I mentioned, you can still get all the benefits of a rebase-based workflow without ever engaging in this type of rebasing, and similarly you can have a fully merge-based workflow (for landing things in master) and people might still wildly rebase-to-rewrite their commits on their feature branches (and if they are not even pushed, who's gonna stop them?). These things are really orthogonal. Also, whilst I agree that undisciplined rewriting of commits is a bad idea, and can mess up previously working non-HEAD commits, it should never mess up the final commit on a feature branch undetected. Because you're running CI, right?. And at the end of the day almost no workflow will run full tests/CI on every commit (too expensive for anything but small projects), so broken "intermediate" commits can even happen without rebasing and if you do in fact run CI on every commit, well even undisciplined rebasing is perfectly safe. [++] Also: I'd recommend preferring git commit --fixup to wildy messing about with git rebase -i on the fly.