43
What were your misconceptions about Git when you first started? (programming.dev)
submitted 2 years ago* by [M] to c/git@programming.dev
77 comments fedilink hide all child comments
 

I used CVS and ClearCase before moving into Git, and it took me some time to adjust to the fact that the cost of branching in Git is much much less than ClearCase. And getting into the "distributed" mindset didn't happen overnight.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 2 years ago (6 children)

I guess it’s dependent on project, but IMO if a commit is important enough to be in the main branch, then that should have its own merge request. I like it when all commits in the main branch have gone through all the build pipelines and verification processes.

But if having separate MRs is undesirable, then you could always overrule the squash policy. I know it’s possible on Gitlab at least.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 3 points 2 years ago (5 children)

    Commits should be reasonably small, logical, and atomic. MRs represent a larger body of work than a commit in many cases. My average number of (intentionally crafted) commits is like 3-5 in an MR. I do not want these commits squashed. If they should be squashed, I would have done so before making the MR.

    People should actually just give a damn and craft a quality history for their MRs. It makes reviewing way easier, makes stuff like git blame and git bisect way more useful, makes it possible to actually make targeted revert commits if necessary, makes cherry picking a lot more useful, and so much more.

    Merge squashing everything is just a shitty band-aid on poor commit hygiene. You just get a history of huge, inscrutable commits and actively make it harder for people to understand the history of the repo.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 2 years ago (4 children)

    Well the MRs in the teams I’ve been working in have been small and mostly atomic. They’re focused on solving only one thing.

    The team I’m currently working now in was bad at this before and often bundled way too many things in a single MR. It lead to overly long review processes and was error prone. It was too tough for the reviewer to get an understanding of what was going on.

    Since we made the habit to make smaller MRs we have had much less of those issues.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 3 points 2 years ago* (3 children)

    If the MR is anything bigger than a completely trivial change in a file or 2, it most likely should be broken into multiple commits.

    A feature is not atomic. It has many parts that comprise the whole.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 0 points 2 years ago (2 children)

    In that case the feature is multiple MRs.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 2 years ago (1 child)

    That's excessively bureaucratic to the point of being useless in most cases.

    Hard and fast rules are generally bad and "squash everything" is pretty much a by definition hard and fast rule with the result being "I'm just not going to care that much about my commit messages."

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •