Hi

I'm sending for consideration a patch that implements repository aliases. This was at some time proposed  in darcs-users [1]  but I couldn't find a ticket for it. The new behavior is described in the patch, but essentially, it means that one can add a _darcs/prefs/aliases file that contains entries of the form alias:repo_url, and then use (a short) "alias" instead of (a long) repo_url.

To me, this feature would be specially handy since I often use darcs in a truly distributed way, i.e., without a designated central repository. In this setting, each member has a public repository to which to push changes (typically via ssh), and has to pull from the public repositories of the others (via http), so setting a default repository doesn't help (in my case,  "darcs send" doesn't help either because there is no central maintainer and, more importantly,  because not everyone is willing to spend time configuring sendmail and/or darcs properly….).

In any case, comments are welcome!

Thanks,
Daniel

[1] http://lists.osuosl.org/pipermail/darcs-users/2009-September/021182.html

Attachments

• repo_aliases.dpatch

Hi Daniel,

Thanks for the patch!

A few comments -

- Yes, I think you should warn if the alias entry is malformed. 

- It'd be good to update the help text somewhere, to let users known
about aliases - they are cool, we want people to know about them!

- It'd be good to add some shell tests to make sure things are doing
what you think they should (it doesn't have to be too complicated!)

- It might be nice to output a message similar to "using repo location
FULL_LOCATION having expanded alias ALIAS", so users understand why a
given location is being used.

So, if you could make a followup patch
(http://darcs.net/Development/PatchReview#submitting-patches) that'd be
great!

Thanks again,

Owen.

I guess the other thing this needs is to start a discussion on whether the 
feature is definitely worth having: http://darcs.net/Development/NewFeature

In the previous discussion on darcs-users one alternative suggested was to 
use bash completion. 

Personally I can see myself wanting to use this feature but I have a slight 
worry about user confusion between aliases and concrete repository locations. 
On the other hand I guess you don't do 'darcs push foo' because that would 
imply pushing to a subdirectory of the current directory.

Thanks Owen and Ganesh for the comments!

I'd be happy to polish the patch with the suggestions that were put forward, but I'd like to wait to see if there is consensus before putting more time in it (the implementation as it is already serves as proof-of-concept). So I'll comment next on the the concerns raised by Ganesh.

* I don't think bash-completion is a suitable alternative for a number of reasons:
    
   1) bash is not ubiquitous (e.g. Windows) and is not a requirement for using darcs. Moreover, even on systems that come with bash, bash-completion is not provided by default.
   2) This alternative depends, IIUC, on the user pressing <tab> _every time_ a repository alias is given on the command line.
   3) If you have two different projects, you will probably want 'master' to stand for different things in each case, so the completion script needs to take the current directory into account. Now, since you shouldn't modify the bash-completion script for darcs for each new project, you will want the script to read an 'aliases' file somewhere in your project to determine what 'master' stands for (a centralized file seems like a much worse alternative to me).

So summing up, with bash-completion you get the same burden on the user (namely, the need to define alias files in order to use it), with a worse interface (<tab> is mandatory) and on fewer platforms. (Btw, if some form of repository aliases were adopted, the darcs bash-completion script could be extended to take the info in the aliases files into account).

* If one wanted to avoid ambiguity in general, aliases could be forced to start/end with some character unusual in file names. I don't favor this alternative, but to me it it shows that question of handling ambiguity is more or less orthogonal to the question of having aliases in the first place.

Regarding ambiguity, as of this patch you only get an alias expanded if you created an aliases file in the first place, so I don't anticipate surprised users. As a connected but *independent* proposal one could consider adding an aliasesfile preference, in analogy to boringfile. I would actually use this feature (e.g., it makes migrating repository locations almost transparent), but of course, this could potentially puzzle users unaware of aliases.

Just as a "I'd like this" note:

I'd use this to make pushing reviewed/screened patches that little bit
easier; I'd rather not type out the full path/username when pushing,
like so:

    darcs push [...] user@domain:path_to_repo

instead I'd have a pair of aliases:

rev: user@darcs.net:reviewed
scr: user@darcs.net:screened

then I lazily do:
    
    darcs push [...] scr
    darcs push [...] rev

I tried doing this with a ssh config entry, but I couldn't get it to
work (I seem to recall you can't set a path in an ssh config file).

So, I am in favour of this. I also like Florent's suggestion of a UI
message "Pushing to FULL_LOCATION (aka ALIAS)". 

It would probably be nice to include some extra output if the user
passes --verbose, to help debugging why an alias isn't picked up ("ALIAS
not found in LIST_OF_ALIASES" or somesuch).

It might be nice to trim leading/trailing whitespace before checking for
an alias to catch typos like:
   darcs push -a 'oops '

My apologies for leaving this stalled for quite a while.

My view is that this makes sense to add: several people have wanted it 
for a long time, and shell completion is inadequate for reasons given.

Any objections, please shout. Otherwise we should just go ahead and do 
this.

I meant to prepare a follow-up patch, but got diverted in the process. Thanks for reminder, I will try to come with one soon

On Feb 15, 2013, at 3:06 PM, Ganesh Sittampalam wrote:

> 
> Ganesh Sittampalam <ganesh@earth.li> added the comment:
> 
> My apologies for leaving this stalled for quite a while.
> 
> My view is that this makes sense to add: several people have wanted it 
> for a long time, and shell completion is inadequate for reasons given.
> 
> Any objections, please shout. Otherwise we should just go ahead and do 
> this.
> 
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/patch948>
> __________________________________

+1. Depending on workflow this can be an extremely useful feature.