[darcs-users] some darcs comments from Johan Tibell

Alberto Bertogli albertito at blitiri.com.ar
Wed Jan 6 04:43:26 UTC 2010

On Mon, Dec 28, 2009 at 06:29:10PM +0000, Eric Kow wrote:
> Hi,
> One question which came up: what's the different between staging commits
> with an index, and staging with darcs amend-record?

I haven't seen this one answered yet, so I thought I should give it a try.

While for some workflows using the index can be somehow equivalent to
commit/record+amend (UI issues aside), there are others that are not quite so.

For example, when there is a conflict during a merge, you're left with a tree
that has all the files that merged without conflict in the index. A
status/diff will only show you only the conflicted paths.

If you want to change a non-conflicted path, you can easily ask for a diff
between the version from your working directory and the version that the merge
has prepared.

It is also very useful when splitting big patches or rebasing a long list of
commits, but I don't know how well it applies to darcs, because it handles
those scenarios in a different way.

While I'm at it, I've included a couple of comments trying not to repeat what
others just said, I hope you don't mind.

> I just had a thought on one principle we could adopt that could help
> us preserve this simplicity.  Johan: since you're an active user of
> branches, could you comment on the following idea?
>   Darcs should never implement 'remote' branches.
> Branches should be strictly a personal affair, something a hacker would
> use to work on multiple features at the same time, or a maintainer to
> keep track of a bunch different patch sets; but NOT for a project that
> wants to publish multiple branches (they'd have to do it the old
> fashioned way).
> Perhaps this sort of simplifying principle will help.  Basically the
> idea is that we should consider making a point of not EVER implementing
> (a) copying of branches and (b) pushing to and pulling from branches in
> other repos.  That branches be tied to a single directory may allow us
> to make life more convenient for the most common use cases while keeping
> Darcs simple to use and think about.

Something I think would be useful to darcs in any case is aliases for remote
URLs. I know it defaults to the last one, but sometimes you have several
different remotes and you want to operate with them without typing the full
URLs (tab completion helps, but it is not easy or good enough: I have to
remember what the different URLs are for, and might not always be so easy).

Sorry if darcs already has this, it's been a while since I've used it
seriously and I might have missed some features or forgot about some things.

> > > fs runs Fedora Core 3 and has two SATA disks in a software RAID 1 array.
> > > I can only assume that when people complain about slow branch creation
> > >
> > >     - they're *really* impatient;

When using darcs, I almost never used branches. One of the reasons was that
after some time forgot what was in them and was a bit of a pain to find out.

There was (is?) no easy way to compare many branches. With git, I just run
gitk/tig --all and I can see _very_ fast where my branches are, where they
differ, and all that.

But the main reason was that with git, I create a branch in 0.007s, using one
command. With darcs, I have to cd out of the repository, do a get, and then cd
back (either to the original or to the new one).

So for me it was not only the speed of the operation itself, is the way it
gets in the way of doing things. And not only for the creation (more on this

> > What about when I'm on a plane?
> Well you lose the ability to consult the patches that are far back in
> history... if you're on a plane.

I use my repositories in many different places, not all of them have internet
access, and some of them do but don't allow ssh. I wouldn't use --lazy for
remote repositories because I never know when I'll need to look at the
history, and it won't be there. I'm not talking about plane scenarios, I'm
talking about day to day activities.

Besides, I look up things in past commits all the time. Annotates, greps,
bisects, merges; a lot of frequent commands in my workflows depend on history
being there.

> > >> Johan Tibell writes:
> > >
> > >>> $ git diff master..integration  # All changes taken together to get an
> > >>> overview
> > >>> $ git diff integration~2..integration~3  # Patch 3 (newest)
> > >
> > > Isn't the latter equivalent to the simpler "git show integration~3"?
> > 
> > I use an external diff tool.
> To diff across branches in the current setup, you'd just use that
> external diff tool without any darcs commands.

That covers only the case for comparing the heads of both branches. And
doesn't take into account the ignored files, which have to be fed manually to
the diff tool.

I find myself frequently comparing two branches as they were at different
points in history, and I can't do that with darcs without a sizable number of
commands.  To clarify the scenario, imagine having two branches: 1.5 and 1.6.
The former has tags 1.5.0, 1.5.1, and so on; the latter 1.6.0, 1.6.1, you get
the idea. I may want to compare 1.5.18 with 1.6.3.

I hope you find it useful!


More information about the darcs-users mailing list