Ben Franksen writes:
> It depends on what you mean with "patches". From a user perspective, it
> is indeed true that a branch is a set of patches. My response was about
> the implementation which has a different view.
This is very generous of you. I did indeed mean the implementation,
and
Karl O. Pinc writes:
> On Mon, 13 Sep 2021 13:14:12 +0200
> Ben Franksen wrote:
>
> > (BTW we should really add TLS/SSL to the website and tracker.)
>
> FWIW, I find letsencrypt.org and certbot useful.
I did too. For Apache, I forget whether there's a script that creates
the
James Cook writes:
> I've used git with multiple working directories, and it is nice.
>
> darcs uses hard links to save space, so having multiple clones should
> be relatively cheap.
Right, but that's talking about physical resources. I think those are
quite plentiful for most developers
James Cook writes:
> For short-lived branches, I just use one clone per branch. I think this
> should work well for long-lived branches too, but I haven't tried.
What's nice about the git storage model is that you can have a
"warehouse" repository with dozens of more or less active branches in
Harald Geyer writes:
> Has anybody tried to get the patch theory work with xml files in a
> way, that uses DOM semantics. How difficult would it be to
> implement this?
I thought briefly about this, but this was a couple of years before
Camp, when Darcs was unacceptably slow and too clumsy
Ben Franksen writes:
> Hi Stephen
>
> Am 08.03.2018 um 09:52 schrieb Stephen J. Turnbull:
> > Another long one. But we're converging!
>
> Indeed. I think we agree on almost every point,
I think so, at this point. You added some stuff that I don't disagree
with but
Another long one. But we're converging!
Ben Franksen writes:
> Am 05.03.2018 um 04:40 schrieb Stephen J. Turnbull:
> > Although git and Mercurial (and Bazaar) share a repository model that
> > is somewhat more complex (DAG of versions), only git's implementation
Ben Franksen writes:
> > The refs are supposed to all be copied to refs/remotes/origin,
> Hm, that may clarify a few things for me. So a "ref" is a file which
> contains a hash that references an object.
That's how it's made persistent. However, there are older methods
(symlinks, for
Ben Franksen writes:
> Am 19.03.2018 um 09:12 schrieb Stephen J. Turnbull:
> > I don't think this is possible with raw git on a remote repository. I
> > believe you need to fetch all the remote refs, and query locally.
>
> In Darcs we have to query the remote repo a