Resolves an issue cause by a syntax error and a removed executable bit
introduced by dracula/tmux#153.
The syntax/permissions issue stops the plugin from running properly when
I ran into the issue earlier today.
The missing executable bit is likely what's causing dracula/tmux#178
given that `man bash` has the following excerpt:
> If a command is found but is not executable, the return status is 126.
With this new option, we get information about which remote branch we're
tracking. On top of this, we'll get information about ahead/behind
commits when we diverged from remote. The output format will be in the
form:
'local...remote +ahead -behind',
where ahead and behind are the number of commits ahead and behind.
This functionality is controlled by a new option called
'@dracula-git-show-remote-status'.
Note that for this to be properly displayed, we need to increase the
size of the right status bar when the git plugin is enabled.
In order to be easier to introduce the change, getMessage() was also a
bit changed in order to be easier to append the remote info.
Signed-off-by: Nuno Sá <noname.nuno@gmail.com>
As stated in 'git status --help':
"By default, git status will automatically refresh the index, updating
the cached stat information from the working tree and writing out the
result. Writing out the updated index is an optimization that isn’t
strictly necessary (status computes the values for itself, but writing
them out is just to save subsequent programs from repeating our
computation). When status is run in the background, the lock held during
the write may conflict with other simultaneous processes, causing them to
fail. Scripts running status in the background should consider using git
--no-optional-locks status (see git(1) for details)."
This was actually happen during rebasing whith the following error:
"error: Unable to create '/home/nsa/work/linux/.git/index.lock': File
exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue."
This change fixes the above...
Signed-off-by: Nuno Sá <noname.nuno@gmail.com>
By default 'git status' will look for untracked files and the script will
always detect that the local tree has changes if untracked files are
present. That is not always optimal since sometimes we might have, for
example, some custom build scripts (for some project) that is always
present and we don't want the status bar to always indicate changes.
Hence, add an option to disable this behavior by adding the '-uno' flag
to 'git status'. The default behavior is still maintained.
Signed-off-by: Nuno Sá <noname.nuno@gmail.com>
