5 ms·

The issue is not one of memory holing: non-merge commit reverts work as people expect (and leave a historical record). I think the right way handle this in git

• lmm 6y ago
  > The issue is not one of memory holing: non-merge commit reverts work as people expect (and leave a historical record). I think the right way handle this in git, in most cases, is to just avoid merging altogether. Do work on feature branches and rebase those into master (possibly adding some meta-info like Feature: 123 to the individual commits as you do the rebase). Apart from not having to explain the semantics of merge reverts to everyone in your team this saves a lot of other conceptual overhead as well. That's a non-answer and sacrifices most of the benefits of using a DVCS at all; if you're going to do that you might as well just use SVN. What are the semantics you would want/expect reverting a merge to have? As far as I'm concerned, other than having to pointlessly pass "-m 1" every time, reverting a merge does exactly what I'd expect it to. > I disagree that git deals well with non linear history, everything about dealing with non-linear history in git is pretty painful, from bisecting to querying (compare to revsets in mercurial, for example) or logging. Bisect works fine. Could you be more specific? > Unless your org is large enough to hit scalability problems monorepo seems the way to go with git -- it makes it easy for everyone to find stuff and use a consistent shared "timeline". IMO the repo is the unit of versioning; things that are released together should go in the same repo, while things with separate lifecycles should have their own repositories. That way your tags and history work the way you'd expect, but you avoid showing a misleading global timeline if that doesn't actually exist (e.g. 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). > However, other than submodules and co in git being a tire fire, I see no reason why the same purpose could not be served by subrepos in many cases; what makes you think they are inherently problematic? I see them as inherently problematic because they hugely complicate the model. I don't want to think about different parts of the checkout being on different revisions, branches, or tags.
  • 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).