On Thu, Apr 28, 2011 at 8:08 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Junio C Hamano wrote:
> Or is the idea to blindly install (a symlink to) git-work to $(git
> --exec-path)/ rather than a place on the $PATH? ÂIn this case, I would
> be a little worried. ÂHow will the helper deal with uninstallation and
> with namespace conflicts? Â(On the $PATH, these are expected problems
> and I'd expect each user has some way of dealing with them already.)
I see 'git pm activate' managing symbolic links in a directory
dedicated to the purpose (.e.g. ~/.git-pm/activated).
One thing 'git pm activate' could do is check that the commands
exported by the 'gitwork' descriptor do not conflict with what is
already activated.
If the user has done something like:
git clone https://repo/gitwork.git ~/hub/gitwork
and then:
git activate pm ~/hub/gitwork
the symbolic links would be established to ~/hub/gitwork, wherever
that happens to be.
If the user has done:
apt-get install gitwork
then given a package-manager adapter for apt-get, it could extract the
.gpm file from the list of installed files, and resume activation from
there. Ultimately, the end result is the same ~/.git-pm/activated is
updated, it has always been on the paths it needs to be.
If the descriptor did have a list of exported commands (e.g. git-work,
git-base, git-atomic, git-test), then a global registry could use this
list of exported commands to detect conflicts early - at package
registration time which might help avoid grief down the track.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html