<meta http-equiv="content-type" content="text/html; charset=utf-8"><div>i see, you are of course right. lets tackle it stepwise thought.</div><div><br></div><div>currently gar is syncronised manually on git and hg. lets assume we would extend this experiment a little bit, deciding for the moment onto git. what i would miss currently are two things:</div>

<div><br></div><div>1.  a short description how i set up my environment so i can deliver, say mercurial. currently i do check out the whole mgar tree, the externals are replaced with symbolic links. what would be the best approach if gar is in git?</div>

<div><br></div><div>cd ~</div><div>pkg=mercurial</div><div>mkdir git-experiment</div><div>cd git-experiment</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>git clone <a href="https://rthurner">https://rthurner</a>@<a href="http://github.com/opencsw/gar.git">github.com/opencsw/gar.git</a> gar</div>

<div>git svn clone <a href="https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg}">https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg}</a> ${pkg}</div><div>ln -s ${pkg}/trunk/gar gar</div><div><br></div>

<div>2. how would i create a new package stub using git?<br></div><div><br></div><div><br></div><div>rupert</div><div><br></div><br><div class="gmail_quote">On Mon, Jun 20, 2011 at 03:27, Ben Walton <span dir="ltr"><<a href="mailto:bwalton@opencsw.org">bwalton@opencsw.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011:<br>
<br>
Hi Rupert,<br>
<div class="im"><br>
> as an experiment, i tried to convert the subversion gar repository to git<br>
> and mercurial:<br>
>  * <a href="http://code.google.com/p/gar/" target="_blank">http://code.google.com/p/gar/</a> (hg)<br>
>  * <a href="https://github.com/opencsw/gar" target="_blank">https://github.com/opencsw/gar</a> (git)<br>
<br>
</div>I like this! :)  I'm not keen on mercurial given my exposure to it,<br>
but anything distributed would be a step up.<br>
<div class="im"><br>
> what i am not sure is how to handle externals and patches onto them,<br>
> but i saw posts like:<br>
> *<br>
> <a href="http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment" target="_blank">http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment</a><br>
<br>
> what do you think, in general about a conversion, and in special,<br>
> how to do this patching?<br>
<br>
</div>I'm not sure what you mean by 'patches onto them' but basically,<br>
submodules suck for our use case, in my estimation.  They're excellent<br>
in projects where you're pulling in external code as a source library.<br>
The most common example I see is that many projects have gnulib as a<br>
submodule.  When they're polishing a new release, they update the<br>
gnulib submodule to current as part of that process.  They won't work<br>
nicely in our pkg/$foo/trunk setup though as we'd be constantly<br>
required to update the sha1 reference to the submodule for every<br>
recipe change.<br>
<br>
As Sebastian mentioned, we can (and should!) do away with externals<br>
and, if they're still in use, the old garlinks in favour of the new<br>
mgar wrapper.<br>
<br>
If we did this, we could (as long as Sebastian is on board), merge<br>
mgar directly into the gar/v2 git repository and release an actual<br>
package for it.  mgar is packaged now, but it could be extended to<br>
deliver the rest of the gar code with it.<br>
<br>
The impact of this would be that people would be forced to use mgar to<br>
interact with gar (or create their own new frankenstein) and people<br>
would need to learn/use git.  Many of us are already using git where<br>
possible, so that's not likely a big hurdle.  Using mgar is a positive<br>
experience and doesn't change workflow much beyond s/(svn|gmake)/mgar/<br>
now.<br>
<br>
Gar would have a package and we could still have a devel mode for gar<br>
where the local git (or hg) repo is tracked against the head of the<br>
main branch.  Good for users, good for devs.<br>
<br>
This might be a nice test of the waters for a move away from svn<br>
instead of attempting to move gar and all of the recipes in one shot.<br>
<br>
Is anyone else excited by this idea?<br>
<br>
Thanks<br>
<font color="#888888">-Ben<br>
</font><div><div></div><div class="h5">--<br>
Ben Walton<br>
Systems Programmer - CHASS<br>
University of Toronto<br>
C:<a href="tel:416.407.5610" value="+14164075610">416.407.5610</a> | W:<a href="tel:416.978.4302" value="+14169784302">416.978.4302</a><br>
<br>
_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@lists.opencsw.org">maintainers@lists.opencsw.org</a><br>
<a href="https://lists.opencsw.org/mailman/listinfo/maintainers" target="_blank">https://lists.opencsw.org/mailman/listinfo/maintainers</a><br>
.:: This mailing list's archive is public. ::.<br>
</div></div></blockquote></div><br>