3 ms·

I am a bit lost. Most of the discussions seem to focus on micromanagement of commits in your local HEAD branch. I agree that the Git commands are pretty primit

by lolive 4y ago

I am a bit lost. Most of the discussions seem to focus on micromanagement of commits in your local HEAD branch. I agree that the Git commands are pretty primitive (aka low-level). But eventually you can learn the good patterns and deal with that. For me, the big question is how to manage a monorepo (with zillion of branches) so you can express which set of branches are relevant to your current concern at time T: - focusing on the dev of a given set of features, - frozing them into a delivery, - pushing a stable monorepo+that frozen delivery to your validation platform, - once validated, integrating that frozen delivery to one of the master branches of the monorepo, - management of the many master branches corresponding to each subparts of the monorepo into a supermaster branch Does this tool (or Mercurial in general) help with all that mono-repository branch management ?

neandrake 4y ago
I've worked with Mercurial repos for 10+ years and only recently we've been migrating some of the smaller repos to Git primarily due to better supported tooling. Mercurial has done a great job in specific workflows especially with phases (which not everyone adopts) -- by default they disallow modifying public commits but allow modifying draft commits. I don't believe Git really has a similar concept, or at least not integrated at the same level. I recently read about `git push --force-if-includes` which seems like it's trying to address similar situations but mostly guessing based on comparing changesets present between two repos. To your question about what/how Mercurial helps I'm guessing it's related to this, or other workflows enabled by Mercurial's Evolve/Topic features. It sounds like Sapling has adopted Evolve/Topics and making them functional on Git repositories though I'm not sure what it's doing under the hood.
arxanas 4y ago
Generally speaking, they simply don't use multiple branches on the central server. See https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/

by lolive 4y ago

neandrake 4y ago

I've worked with Mercurial repos for 10+ years and only recently we've been migrating some of the smaller repos to Git primarily due to better supported tooling. Mercurial has done a great job in specific workflows especially with phases (which not everyone adopts) -- by default they disallow modifying public commits but allow modifying draft commits. I don't believe Git really has a similar concept, or at least not integrated at the same level. I recently read about `git push --force-if-includes` which seems like it's trying to address similar situations but mostly guessing based on comparing changesets present between two repos. To your question about what/how Mercurial helps I'm guessing it's related to this, or other workflows enabled by Mercurial's Evolve/Topic features. It sounds like Sapling has adopted Evolve/Topics and making them functional on Git repositories though I'm not sure what it's doing under the hood.

arxanas 4y ago

Generally speaking, they simply don't use multiple branches on the central server. See https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/