Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

feature request: changed flag in statusline #206

Open
stardiviner opened this Issue · 17 comments

6 participants

stardiviner Richo Healey Tim Pope Tom Link Colin Sullivan Stuart Grimshaw
stardiviner

I hope fugitive can give out a flag in statusline indicates that this file in Git or any VCS else is changed (different with file in Vim buffer or Disk).
I always use fugitive to modify config file, etc, sometimes the file is long, I do not know where I modified.
So a statusline flag will notice me. I do not always go to see git diff. It waste time very much. Because usually I just modify, then commit.

Richo Healey

Maybe you'd be better off committing with either

:Gcommit -v (in fugitive)
or
git commit -v (in the shell)

Which shows you the diff you're committing

stardiviner
stardiviner

And this :Gcommit -v is after :Gwrite, I do not want to write before I am sure what I'm doing. and the diff is at the bottom of -v. so this is not a good option.

Richo Healey

Until you write to either the index or the work tree git can't tell you whether or not you've changed anything. In that instance you're interested in whether or not you've changed the buffer, which vim supports.

stardiviner

I'm wrong on this. But there is a similar script called "quickfixsigns", it can do similar work.

Tim Pope
Owner

I've thought about this. In addition to the unpersisted buffer issue you guys have already discussed, there are a couple of caveats:

  1. It requires spawning an external process, so it's potentially slow. This will be an absolute dealbreaker on Windows, and even on *NIX, it'll require us to be diligent about caching (and you know what they say about expiring caches.)

  2. There are a lot of different ways to ask "has this file changed?" What if the changes have already been staged? What about untracked files? Renames and deletions? I started assigning different punctuation marks to different states, and it just got confusing.

Richo Healey

The best idea I could come up with is a :Gstatus buffer that keeps itself out of the way for the most part (similar to NERDtree in it's default config) and post- hooks on most :G* actions to update it, but I think you'd run into the same issues with latency.

stardiviner

Can reference quickfixsigns script, it can show changed signs ahead of linenumber. So similar things can archived in statusline. That's why I post this issus here. I do not know very much on this. I should ask the author of quickfixsigns about this.

Tom Link

quickfixsigns simply displays signs at modified lines according to git diff.

stardiviner
Colin Sullivan

I would like this as well. Ideally, I would like to see the first few characters of:

git status --porcelain ${FILENAME}

(where ${FILENAME} is the filename of the current buffer), in my Powerline.

From Vim with fugitive:

:Git status --porcelain %

For example, on a modified file, this command prints M ${FILENAME} and on an untracked file, ?? ${FILENAME}. It would be sweet to have the M or ?? characters in my Powerline to remind me that the file has un-committed changes, or is untracked, etc.

Personally I'd find this more useful in my editor than which branch I'm on. Showing the branch is a useful reminder, but typically I want to be reminded more frequently that I haven't committed changes.

Thanks for all the awesome tools :)

stardiviner
Stuart Grimshaw

I've recently switched to using zsh as my default shell, and some of the themes that you get with it make really nice usage of different characters to express the current state of a repo.

https://github.com/robbyrussell/oh-my-zsh/blob/master/themes/muse.zsh-theme shows the various characters used in the theme I'm using right now.

It would be good if fugitive by default used the output of porcelain as Colin suggested, but also provided a way to display other characters if the user wants to.

Tim Pope
Owner

In git status --porcelain, a file with unstaged changes is shown as _M while a file with staged changes is shown as M_ (using _ for space since markdown is screwing it up). This looks fine in the linewise output but would look pretty dumb in a statusline, no? And if we collapse to just M we lose information.

@Stubbs, that's kind of orthogonal as it shows you the status of the entire repo rather than an individual file (although obviously there are some parallels). As far as customization goes, I don't know what I can do that will make things any simpler than "write your own statusline function."

stardiviner

There are many different states.
On Vim: modified, saved(unmodified).
In Git(fugitive):
tracked,
untracked,
committed,
modified(changes to be commited)
-> M
-> MM (some changes is been added, still part of changes in vim file not been staged)

And there is a workflow:
open a new file (untracked in repo) (statusline sign U)
-> then do some modify, (now the file is modified, in Vim, statusline sign is "+")
-> use fugitive command :Gwrite to add into repo track (statusline sign is "✔")
-> do some modify again, and :w to save. (now the statusline sign changed into "∓" means changes)
-> now use command :Gdiff and diffput to only add part of changes into repo. (statusline sign
change into "need commit" and "partial staged") depend on those two states, fugitive
should give out two or more file states on statusline.

Maybe there are some other states about file. welcome complete this.
I'm not a smart guy and do not know much about Git and Vim.
But I know git know those different states. so fugitive can achieve those function too.
And, I think those signs is very meaningful.

And, I think if a person work much on :Gstatus instead of command line, those repo states about "merged", "unmerged", "dirty", "clean" is meaningful too.

Richo Healey

In my opinion it would get unmanagable pretty fast. Particularly because 9 times out of 10 Vim telling me that I have staged part of a file is not helpful until I git diff --cached to work out which parts I've staged.

it's also worth noting that the statusline is only redrawn when you focus that pane (afaik?) so if you manipulate git externally you may see out of date info in vim.

stardiviner

About out of date into in vim. yes, this is a problem if somebody manipulate git in external command line. But we should notice that we use fugitive because it is simple and easy to do git things in Vim. So we will reduce the time do work in command line, and I think there are many other functional features plugins will be developed about git in vim. So this is not a big problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.