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 I
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 $SITE-le-ssl
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 no
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 for
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
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
I think we converged substantially in this round!
Benjamin Franksen writes:
> On 04/10/2018 08:34 AM, Stephen J. Turnbull wrote:
> > Any user who understands what a ref is will say "a Darcs tag is
> > too a ref!" I think.
>
> Perhaps (but you won't, rig
Ben Franksen writes:
> Am 29.03.2018 um 10:08 schrieb Stephen J. Turnbull:
> Internally we do use references, similar to git (we refer to patches,
> inventories, and trees via content hash). But in contrast to git, these
> are not exposed as a user visible concept. Tags are some
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 example
Wolfgang Jeltsch writes:
> What about double-clicks, which mark the word (in this case, the SHA1
> hash) under the cursor?
The discoverability problem (git repositories normally will have
several dangling heads, and if rebase is used, there would be many)
still means that real people (as oppose
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
12 matches
Mail list logo
