4 ms·

>Mercurial wants you to use a lightweight clone.... You can make a named branch and make it private so that it wont be pushed automatically or you can create a

>Mercurial wants you to use a lightweight clone.... You can make a named branch and make it private so that it wont be pushed automatically or you can create a bookmark and mark the changeset as private, so that it wont get pushed automatically OR you can create a local clone, completely isolated from the origin repo. The difference between git branches and Mercurial branches is a bit of a conceptual one. Git has 'user' branches, where a branch corresponds to the work of a user. Mercurial has 'feature' branches, where each named branch (is supposed to) correspond to a feature. I think This is the one of the reasons some Git users are sometimes so turned off when they see Mercurial branching model. And to me, I would like a project as a sum of its feature branches. But I can imagine why this might not be optimal for a something like Linux kernel. But for most projects, I think feature branches are more valuable than the user branchs of git. >Mercurial, without extensions, doesn't have the git shelf. Shelve extension is bundled, enabling is just a matter of turning on a flag in the .hgrc configuration file...

stormbrew 12y ago
> Git has 'user' branches, where a branch corresponds to the work of a user. Er. Not really, no. Git is simply agnostic about how you use branches, and allows you to separate how published branches and your local branches are used implicitly. I've rarely worked on a multi-user git project where published branches corresponded to a user's work. Almost always they are feature branches worked on alone or with someone else. Even in linux development, where the repositories are directly tied to users usually, the actual branches generally represent a work-unit of some sort, so I'm not sure where you got this idea.
- acveilleux 12y ago
  It's probably pervasive because of github and pull requests where, at least for open-source projects and external contributors, it's true in practice though not enforced.
  - stormbrew 12y ago
    I'm confused as to what "it" means here? If you mean the idea in the GGP's post that branches represent a user's work, again I think that conflates repositories with branches. It's not exactly impossible to find people doing work on master of their fork against an OSS project, but best practices (and common practice among most regular contributors I've seen) seem to angle towards using feature branches even then (and asking with a PR to merge eg. stormbrew/blah:fix-the-thing to upstream/blah:master).
  - johnmaguire2013 12y ago
    Even in that case, you're talking about a clone of the repository, not a "user's branch." That would be the "user's repository", which has branches corresponding to features, and bugfixes (unless they are a user on Github who isn't too familiar with Git, in which case they'll just commit to their "master" branch probably). If each user has their own fork, as is typical on Github, then it makes even less sense to have a "user" branch.
- imakesnowflakes 12y ago
  This is where I got the idea, http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki Please see the Table on the top and the 'Branches' section.
  - stormbrew 12y ago
    Ok. I think that is a relatively accurate description of some normal git processes, but I don't think that's saying what you're getting from it. You may be taking too strong a meaning of the 'ownership' concepts described there (and I think they're stated too strongly). No one owns a branch name in git, not even the person who first makes it. You own the branches in your own local repository, and you can choose how and if you share them, but it is perfectly possible to do shared work on a branch if you have a shared repo to work from (and even, with some extra work, without one). This is basically a Zooko's triangle[1] problem, where git has chosen decentralized and meaningful, which necessarily implies a rejection of ownership (even to the extent that Fossil wiki page implies). But in the end, most branches in git are focused on a piece of work and not who made them (it's mostly the 'lieutenants' in the linux model who would have personal branches). Single-author branches may be more common in git because it definitely does make those easier than other possibilities, but there is nothing stopping collaboration on a shared branch in git. [1] http://en.wikipedia.org/wiki/Zooko%27s_triangle http://en.wikipedia.org/wiki/Zooko%27s_triangle

stormbrew 12y ago

> Git has 'user' branches, where a branch corresponds to the work of a user. Er. Not really, no. Git is simply agnostic about how you use branches, and allows you to separate how published branches and your local branches are used implicitly. I've rarely worked on a multi-user git project where published branches corresponded to a user's work. Almost always they are feature branches worked on alone or with someone else. Even in linux development, where the repositories are directly tied to users usually, the actual branches generally represent a work-unit of some sort, so I'm not sure where you got this idea.

acveilleux 12y ago
It's probably pervasive because of github and pull requests where, at least for open-source projects and external contributors, it's true in practice though not enforced.
- stormbrew 12y ago
  I'm confused as to what "it" means here? If you mean the idea in the GGP's post that branches represent a user's work, again I think that conflates repositories with branches. It's not exactly impossible to find people doing work on master of their fork against an OSS project, but best practices (and common practice among most regular contributors I've seen) seem to angle towards using feature branches even then (and asking with a PR to merge eg. stormbrew/blah:fix-the-thing to upstream/blah:master).
- johnmaguire2013 12y ago
  Even in that case, you're talking about a clone of the repository, not a "user's branch." That would be the "user's repository", which has branches corresponding to features, and bugfixes (unless they are a user on Github who isn't too familiar with Git, in which case they'll just commit to their "master" branch probably). If each user has their own fork, as is typical on Github, then it makes even less sense to have a "user" branch.
imakesnowflakes 12y ago
This is where I got the idea, http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki Please see the Table on the top and the 'Branches' section.
- stormbrew 12y ago
  Ok. I think that is a relatively accurate description of some normal git processes, but I don't think that's saying what you're getting from it. You may be taking too strong a meaning of the 'ownership' concepts described there (and I think they're stated too strongly). No one owns a branch name in git, not even the person who first makes it. You own the branches in your own local repository, and you can choose how and if you share them, but it is perfectly possible to do shared work on a branch if you have a shared repo to work from (and even, with some extra work, without one). This is basically a Zooko's triangle[1] problem, where git has chosen decentralized and meaningful, which necessarily implies a rejection of ownership (even to the extent that Fossil wiki page implies). But in the end, most branches in git are focused on a piece of work and not who made them (it's mostly the 'lieutenants' in the linux model who would have personal branches). Single-author branches may be more common in git because it definitely does make those easier than other possibilities, but there is nothing stopping collaboration on a shared branch in git. [1] http://en.wikipedia.org/wiki/Zooko%27s_triangle http://en.wikipedia.org/wiki/Zooko%27s_triangle