Re: [darcs-users] String encoding issue

[Ben Franksen]

Am 22.03.2018 um 12:40 schrieb Stephane Bortzmeyer:
> On Thu, Mar 22, 2018 at 11:29:54AM +,
>  Eric Kow  wrote 
>  a message of 157 lines which said:
> 
>> Does setting DARCS_DONT_ESCAPE_8BIT to 1 help?
> 
> Ah yes, thanks. I then discovered
>  (at the end). Now,
> everything is fine.
> 
> IMHO, it could be in the FAQ. 

FWIW, this particular wart will be removed in the next release.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] Resurrecting a file?

[Ben Franksen]

Am 22.03.2018 um 11:13 schrieb Stephane Bortzmeyer:
> I am wondering if there is a simply way to ressurect a file which has
> been deleted some times ago. Today, I do a darcs changes (if I
> remember the file name) or a darcs test (if I don't), find the last
> patch where the file existed, then do a darcs clone, copy the file to
> my working copy and darcs add + darcs record.
> 
> It works but it creates a new file, losing the previous history. Is
> there a better way?

Yes and no.

Yes, there is a better way: I would use 'darcs rollback', select the
patch that removes the file, then select the change in that patch that
removes the file (and probably the changes that removed its content,
too). Then record the resulting changes.

But no, the result of doing it like that is the same as with your
method: the removal and re-addition of the file and its content destroy
the "connection" between changes before and after the remove/re-add.

As an alternative, you can "rewrite history" by obliterating the patch
that removed the file. Whether this is approach is practical depends on
the circumstances. First, obliterating the remove-patch may not work if
other patches depend on it. Second, obliterate is usually frowned upon
in repos that are shared with others. This is a question of established
work-flow and how changes are communicated between co-workers, so it may
be an okay solution in your project.

As an aside: Darcs could, in principle, see that you have made a change
that is the exact inverse of an earlier change and use that fact in some
way when displaying changes. I am thinking about an option
--squash-inverses, but it is not clear to me what the exact effect
should be.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Hi Steve

sorry for (again) responding at length. You gave me yet more ideas...

Am 22.03.2018 um 01:15 schrieb Stephen J. Turnbull:
> Ben Franksen writes:
>> My experience with git tells me that when I make a clone what I get
>> is /not/ identical to upstream.
> 
> I may have miswritten. What is identical is the object database.
Okay.

> 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. The content of a ref is
globally valid and thus can be (and is) copied between repos, but the
name of that file (including the directory in which it is located) is a
purely local property. Correct?

If yes, then I begin to understand why as a Darcs user I found it so
difficult to become familiar with git. Because this concept of a "ref"
has no (user visible) counterpart in Darcs. It doesn't exist because it
is not needed (for the user). We /could/ add something like it so we can
refer to patches symbolically, but AFAIK nobody has ever found it useful
enough to request it as a feature.

Whereas in git the concept is essential because many of the high-level
features that make git usable as a tool for day-to-day work are built on
it. The core of git is sound, simple, and elegant; but the high-level
features that build on it have been developed in an ad-hoc manner
without an over-arching and similarly elegant abstraction to guide the
design, so it remains necessary to understand the mechanism behind them
in order to use (and appreciate) them appropriately. I think /this/ is
the deeper reason behind git's "bad UI" reputation.

> but only the currently checked out one at remote is linked to a local
> branch, and checked out locally. Configuration ("core" options in 
> .git/config) comes from your local template, I believe.
Okay. I would expect that all local branches are initially linked to
their remote counterpart.

>> And clones of a clone are definitely second class, at least not
>> out of the box.
> 
> If you want an identical clone of a clone, rsync is your friend. But 
> I don't know what you mean by "second class". (I'm curious; I don't 
> doubt that it fails to work as expected.)
Unfortunately I can't remember the details. It may be that I just failed
to understand how to setup the second clone appropriately. Because...
see above.

>>> You've already admitted that it's necessary because of name 
>>> collisions. You just don't like it. :-)
>> 
>> I did not admit anything like that. There are no name collisions
>> if branch names are always relative to a repo URL. No need for 
>> namespacing branches.
> 
> "Relative to a repo URL" *is* a namespace.
Exactly. No need for any naming convention, since a perfectly natural
namespace already exists. Except that git allows to arbitrarily rename
remote branches, circumventing "qualification" with the remote URL, so
they look like local ones. This should not be allowed (IMHO).

>>> People used to do things like name their tracking branches 
>>> -, but that had two disadvantages. One, many 
>>> people did what you seem to find natural, and omit the 
>>> "-" part. After all, it's not my branch, so I won't work 
>>> on it, right?
>> 
>> No, this is not what I find natural. What I find natural is that in
>> my clone the beasts have the same name as in the remote repo from
>> which I cloned, at least by default.
> 
> I don't understand.
You seem to associate branches with an owner ("it's not my branch"). An
interesting aspect I haven't considered yet. So there is a person at the
remote repo who controls (or likes to control) the history of this
branch. He or she is upset if I push a commit to this branch? I should
rather have created my own branch and committed there, so the remote
owner of the branch can integrate my changes with a merge?

> AIUI, that's exactly what I said was natural: many users set up the
> tracking branch as a normal branch with the same name as in the
> source repo.
This would be perfectly okay /if/ this name could never be confused with
a remote branch of the same name, which would require that it is
impossible to give a remote branch a "plain", unqualified name.

>>> Turns out that for various reasons people *do* unintentially 
>>> commit to those branches.
>> 
>> So what? I don't see how this is a problem.
> 
> You don't see how anyone would commit to a branch they didn't intend 
> to, or you don't see how unintentional commits are a problem?
I don't see how a commit can be problematic even if it was made
unintentional. You commit explicitly by issuing a command, presumable
after making some changes. This creates a new version (commit object).
If this was indeed unintentional, what's the problem?

However, I see that if you accidentally push these changes, this can be
problematic (if you do not "own" the branch). Because apparently in git
if you push, then the remote branch ref is updated to where it points to
locally. Right?

(Sigh. Push