Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: changed flag in statusline #206

Closed
stardiviner opened this issue May 26, 2012 · 22 comments
Closed

feature request: changed flag in statusline #206

stardiviner opened this issue May 26, 2012 · 22 comments

Comments

@stardiviner
Copy link

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
Copy link

richo commented May 26, 2012

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
Copy link
Author

=> On [2012-05-26 01:15:36 -0700]:
Rich Healey Said:

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
this command shows the that which files are changed in the whole repo.
I just want to indicates that current file is changed (different with revision)


Reply to this email directly or view it on GitHub:
#206 (comment)

[ stardiviner ] ^^&^^ {I hate all of you ! Leave me alone}
IRC(freeenode): stardiviner \ Twitter: @numbchild
GnuPG Key fingerprint
>>> 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433

@stardiviner
Copy link
Author

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
Copy link

richo commented May 26, 2012

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
Copy link
Author

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

@tpope
Copy link
Owner

tpope commented May 28, 2012

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
Copy link

richo commented May 28, 2012

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
Copy link
Author

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.

@tomtom
Copy link

tomtom commented May 29, 2012

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

@stardiviner
Copy link
Author

=> On [2012-05-29 11:30:00 -0700]:
Tom Link Said:

quickfixsigns simply displays signs at modified lines according to git diff.
Yeah, that's what I want, a flag indicates whether has diff between hard disk
version and HEAD version.
It is not so hard, right ?
Maybe this feature is not so important, but just like Vim's change flag, it is
useful.


Reply to this email directly or view it on GitHub:
#206 (comment)

[ stardiviner ] ^^&^^ {I hate all of you ! Leave me alone}
IRC(freeenode): stardiviner \ Twitter: @numbchild
GnuPG Key fingerprint
>>> 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433

@colinsullivan
Copy link

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
Copy link
Author

=> On [2012-06-03 11:57:13 -0700]:
Colin Sullivan Said:

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.
Yes, this is what I think, awesome.

Thanks for all the awesome tools :)


Reply to this email directly or view it on GitHub:
#206 (comment)

[ stardiviner ] ^^&^^ {I hate all of you ! Leave me alone}
IRC(freenode): stardiviner \ Twitter: @numbchild
GnuPG Key fingerprint
>>> 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433

@Stubbs
Copy link

Stubbs commented Jun 11, 2012

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.

@tpope
Copy link
Owner

tpope commented Jun 11, 2012

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
Copy link
Author

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
Copy link

richo commented Jun 12, 2012

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
Copy link
Author

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.

@xanderdunn
Copy link

An awesome extension of this would be the option to show flags for lines that have been changed within the past x days. This would be super helpful for debugging. I know a bug was introduced within the past x days, so now I need to figure out which lines of code caused it. Having a gutter indicator on the lines that were changed would be amazingly helpful.

@blueyed
Copy link
Contributor

blueyed commented Jun 21, 2015

See #219 for an older PR in this regard.

@stardiviner
Why have you closed the issue?

@stardiviner
Copy link
Author

@blueyed sorry, I thought this feature was implemented.

@zhiyuanzhai
Copy link

Is there any update?

@tpope
Copy link
Owner

tpope commented Dec 24, 2020

My update is that if people are going to nag me about dormant but not abandoned feature requests in the issue tracker then I guess I will have to close them.

@tpope tpope closed this as completed Dec 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants