<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 10:19 PM, Sean Farley <span dir="ltr"><<a href="mailto:sean@mcs.anl.gov" target="_blank">sean@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> This does not appear to namespace the branches and it looks like you have<br>
> to edit .hg/hgrc for each remote that you want to track. It is quite<br>
> different from namespaced branches/bookmarks.<br>
<br>
</div>Sure, but only the person wanting to pull has to add a path to their<br>
.hgrc which is extremely easy to understand and do.<br></blockquote><div><br></div><div style>It's two places in a file, compared to 'git remote add my-remote-name the.url:repo'.</div><div style><br></div><div style>
The remote bookmarks are still not namespaced so I still can't safely fetch from all remotes before going offline (and even if I'm online, many operations are relatively slow). After 'hg pull somewhere' (rather than pulling a specific branch/bookmark), I don't have a way to keep track of which bookmarks came from where. At least divergent conflicts give warnings "divergent bookmark yyy stored as yyy@default", but other bookmarks are automatically fast-forwarded and new bookmarks are added (I can't find an option to treat everything as a "divergent" bookmark even when it could fast-forward. I'd much prefer that.)</div>
<div style><br></div><div style>This is much "too global" management of bookmarks if you ask me.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"></div><div><div class="im">
<br>
</div></div>You misunderstand me. I think branches/bookmarks are pretty cool and<br>
useful. I also think using changeset evolution (to achieve the shared<br>
garbage-collection of git's unrefed heads) is cool, too. But those workflows<br>
are advanced and require each user of the repo to conform, without<br>
buying all *that* much more than the fork / pull-request model.<br></blockquote><div><br></div><div style>With a git repository, those branches really do not affect the user. Try this</div><div style><br></div><div style>
$ git clone <a href="https://github.com/gitster/git">https://github.com/gitster/git</a></div><div style>$ cd git</div><div style>$ git log --graph --pretty=oneline<br></div><div style><div>* 7799588faa2a8071da8ef047c87f9a1520fb8903 Merge git://<a href="http://github.com/git-l10n/git-po">github.com/git-l10n/git-po</a></div>
<div>|\ </div><div>| * 5e93cd307bdb98809bb0aa3bfb2c0306131f3654 l10n: de.po: correct translation of "bisect" messages</div><div>| * a295fe616f162de5f1640fe95d0060554e12e12a l10n: de.po: translate 5 new messages</div>
<div>| * 48cc7c1b24ea5c9bf59ad98bd308b5fd5b3802d1 l10n: de.po: translate 35 new messages</div><div>* | 4d0d0c3c59800e07d899e53121902833e3fd0cc7 Git 1.8.2-rc2</div><div>* | 06d67b876642822828596b0b38cda2f61d438335 Sync with 1.8.1.5</div>
<div>|\ \ </div><div>| * | e6363a4992637267ef212d7c709ede17d4122e0d Git 1.8.1.5</div><div>| * | 8b1bd024154f0ee0d71a6befe9bbd96462e76abc Make !pattern in .gitattributes non-fatal</div><div>| * | 1d38c6971dd1a4b054d90b7ae4c9de5400b9d818 Merge branch 'wk/user-manual' into maint</div>
<div>| |\ \ </div><div>| * | | 5e2485846dacb5acd3b6cd084e246c7c9a6d5a13 Documentation/githooks: Fix linkgit</div><div>* | | | 443d803e0dacd0a1c6700503689f3cd95751aba1 Merge branch 'maint'</div><div>|\ \ \ \ </div>
<div>| |/ / / </div><div>| * | | 8d44277d91989ad2b37d4908096bd5256d6390c4 Update draft release notes to 1.8.1.5</div><div>| * | | 6f0c33666300ccf95eb4b4e723e07a3c588d12db Merge branch 'ef/non-ascii-parse-options-error-diag' into maint</div>
</div><div style>[...]</div><div style><div>$ git branch</div><div>* master<br></div><div><br></div><div style>I'm oblivious to the presence of other branches, but there are over 300 that I can find by</div><div style>
<div><br></div><div>$ git branch -a | head</div><div style>* master</div><div> remotes/gitster/ab/gitweb-use-same-scheme</div><div> remotes/gitster/al/mergetool-printf-fix</div><div> remotes/gitster/ap/log-mailmap</div>
<div> remotes/gitster/ap/maint-diff-rename-avoid-overlap</div><div> remotes/gitster/ap/maint-update-index-h-is-for-help</div><div> remotes/gitster/ap/merge-stop-at-prepare-commit-msg-failure</div><div> remotes/gitster/ap/status-ignored-in-ignored-directory</div>
<div> remotes/gitster/as/api-allocation-doc</div><div> remotes/gitster/as/check-ignore</div><div><br></div><div style>So I can easily browse ongoing projects ('git log gitster/ap/log-mailmap') and I can work on them ('git checkout ap/log-mailmap', hack away...) but unless I'm directly interacting with a branch, I'm totally unaffected by those ongoing projects and never see them in my normal workflow ('git log', 'git branch', etc).</div>
<div style><br></div><div style>If we are going to consider allowing topic branches to "cook in next" for a while (to get tested in interaction with the rest of the system) before being merged to a stable branch, then we need to keep these bookmarks around somehow, yet it's unacceptable for them to intrude on normal workflow. I still haven't heard of a viable plan in Hg's roadmap.</div>
</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Instead, what I am suggesting is taking incremental steps in that<br>
direction. The fork / pull-request model is pretty darn simple and<br>
allows each developer to work with either workflow (or even some<br>
hybrid). If Barry doesn't want to ever change his habits, then it's<br>
fine. Others could pull, clean-up, and merge his work.<br>
<br>
On top of that, new developers (including people more comfortable with<br>
subversion / cvs / centralized development) won't be bombarded with too<br>
much and can work in their own fork as they please.</blockquote></div><br>In all cases, the contributor workflow is (a) create topic branch, (b) hack away, (c) push to personal repo and submit pull request OR (c') email patch series to list. The distinction in all these possibilities is how we as maintainers manage review, testing, and release of those contributions.</div>
</div>