Local only repository - Mac OS X support
s-celles opened this issue · 19 comments
Hello,
gws doesn't seems to work correctly with Mac OS X 10.10
$ brew install bash
$ brew install gnu-sed
doesn't seems to fix it.
All repository inside my workspace are marked as
Clean [Local only repository]
or
Dirty (Uncached changes) [Local only repository]
These repositories are not only local!
Any idea ?
Are you sure you are running bash > 4
?
You can check with
bash --version
Thanks for reporting. I confirm last version is using some GNU-sed
specific flags.
I'm thinking about either:
- Updating the README to ask for GNU-sed installation; or
- Updating the code to avoid the usage of problematic flags.
Concerning the last problem, it's probably related to few cut
commands using GNU-cut specific flags like --complement
. Same concern here.
I'll investigate and think about all this.
$ bash --version
GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin14.1.0)
Copyright (C) 2013 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou ultérieure <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ brew install coreutils
==> Downloading https://homebrew.bintray.com/bottles/coreutils-8.24.yosemite.bottle.tar.gz
######################################################################## 100,0%
==> Pouring coreutils-8.24.yosemite.bottle.tar.gz
==> Caveats
All commands have been installed with the prefix 'g'.
If you really need to use these commands with their normal names, you
can add a "gnubin" directory to your PATH from your bashrc like:
PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"
Additionally, you can access their man pages with normal names if you add
the "gnuman" directory to your MANPATH from your bashrc as well:
MANPATH="/usr/local/opt/coreutils/libexec/gnuman:$MANPATH"
I don't want to change default tools (sed, cut...) but that's probably possible to use GNU tools without affecting PATH.
Solutions so far:
- Updating the
README
to ask for installingcoreutils
and changing the$PATH
accordingly - Updating the
README
to ask for installingcoreutils
, modifying the code to switch tog
-prefixed tools on OS X. - Modifying the code to avoid using problematic
coreutils
options
@scls19fr: can you confirm the script is working with coreutils
' version of sed
and cut
?
Yes after changing PATH it don't display "Local only repository" anymore
export PATH=$PATH:$HOME/gws
export PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"
export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"
but I'd prefer a less intrusive solution
Ok thanks.
but I'd prefer a less intrusive solution
I can understand.
In the meantime you can define an alias in your .bashrc
or .zshrc
:
alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH gws"
which should do the work without requiring a system-wide update of $PATH
.
I think it's
alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"
For many repo I get
"Dirty (Untracked files)"
How to cleanup this ?
I think it's
alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"
Ok, I was thinking coreutils
path was enough.
"Dirty (Untracked files)"
How to cleanup this ?
This appears when there are files which are not followed by git, nor ignored by it. When you do a git status
they are showed under "Untracked files:"
- If the files are needed for your project, they should be versionned by git
- If they are generated by your code, or not needed like local configuration files or whatever, they should be ignored to avoid being committed by mistake. To be ignored they needs to be listed in the
.gitignore
file. Look here for some language-specific starting point.gitignore
.
Ok I will correct my .gitignore
accordingly.
Thanks
Could you try the version in the develop
branch without GNU-coreutils?
Issues with OS X sed
and cut
should have been resolved.
I still need some git lessons.
$ git branch
* master
How to change to develop
branch ?
Running:
$ git checkout develop
should be enough :-)
[Edit] Output should be something like:
Branch develop set up to track remote branch develop from origin.
Switched to a new branch 'develop'
I removed alias
alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"
First run
$ gws
The URL at position 3 for "OneOfRepository" is missing a name.
Running again
$ gws
returns nothing
Something odd happened...
After
$ git checkout master
and setting again alias
alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"
when I do:
$ gws
it doesn't returns anything anymore.
I also tried to remove .projects.gws
$ gws init
Workspace file «.projects.gws» created.
$ gws
returns nothing
Any idea ?
Hum, depressing 😑
But trying to be positive: There are no more version-specific's errors.
To solve your problem: I implemented a cache system to speedup the execution by avoiding parsing every time the .projects.gws
file. Cache is stored in the .cache.gws
file. Just remove it and everything will get back to a working state.
On the feat/cross-platform branch the cut
commands no longer use the GNU-specific --complement
option. I don't have a Mac/BSD machine to try it on, though - would anyone (ping @JohanSpaedtke) mind testing if this now works on those platforms with default PATH
?
Well I don't know if it works better than before but at least it's different :)
On master you'll get the following with default PATH
cut: illegal option -- -
usage: cut -b list [-n] [file ...]
cut -c list [file ...]
cut -f list [-s] [-d delim] [file ...]
On this feature branch you get the following instead
repo1:
Clean [Local only repository]
repo2:
Dirty (Uncached changes) [Local only repository]
repo3:
Clean [Local only repository]
But on master
with a modified PATH
you get
repo1:
master : Clean
repo2:
master : Dirty (Uncached changes)
repo3:
local-branch : No remote branch origin/local-branch
master : Clean
That's strange... I was hoping getting rid of --complement
would solve it, but I guess there's more to it. I'm afraid I'll have to defer further investigation into this until I have a Mac/BSD box to test on.