feat(git-bulk): Add compatibility to match workspaces using environnement variable#1191
feat(git-bulk): Add compatibility to match workspaces using environnement variable#1191
Conversation
|
I stumbled upon one difference of behavior between my PR and your upstream implementation. DemonstrationAssuming we have this in the Assume we run the following commands: cd ~/myworkspace && git bulk status
cd ~/myworkspace/inner && git bulk status
cd ~/myworkspace/inner/git-repo && git bulk status
PropositionMy current implementation is most intuitive for me... but I'm not the only one to use this. What do you think? While I'm suppose it is not a good idea to change the default of a command which is long used, maybe it would be great to add a flag to switch between the two behavior? It is a matter of changing only one test conditional. Sticking to default behaviorAnyway, to stick to the default previous behavior of the command, I just have to change in |
| # use combination of `eval` and `realpath` to: | ||
| # 1. dereference possible environment variable contained in $rwsdir | ||
| # 2. match workspaces even across different symlinks | ||
| rwsdir_rp=$(eval realpath $rwsdir 2>/dev/null) |
There was a problem hiding this comment.
| rwsdir_rp=$(eval realpath $rwsdir 2>/dev/null) | |
| rwsdir_rp=$(eval "$(realpath "$rwsdir")" 2>/dev/null) |
Adding this makes the eval a bit easier to read for me.
|
This is useful! Like you mention, this does change the default behavior of the comment. I'd support this if the new, intuitive workspace checking was behind a flag |
Problem
With the current implementation of
git-bulk(df53711at the time of writing), using environment variables inside the~/.gitconfigfile to specify abulkworkspace works partially.For example, let's say that
$MYWORKSPACEis set to~/myworkspace.Let's say we use the following configuration in
~/.gitconfig:[bulkworkspaces] myworkspace = $MYWORKSPACENext, what currently is working is the following command, using
statusas a demo command to testgit-bulk:But what is not working is the following:
However, it is expected to either work or not work in the both situations.
Rationale
I think it would be a good feature to have it working in both situations.
In this way, it would allow to easily use the same workspace name with different paths for different hosts, for example.
Solution
In the function that test whether our shell
$PWDis in a workspace or not, I simply dereference variable values if there is any and I use therealpathof both$PWDand the workspace directory.In addition to enabling full usage of environnement variable, this allows to match a workspace directory even if there is a mismatch between our
$PWDand the workspace directory because of a symlink.