Feature/gitsegment

[mwetterw]

Hello,
This branch enhances the git segment with detailed "git status" overview in the prompt.

• Number of commits behind remote tracking branch
• Number of commits ahead remote tracking branch
• Number of untracked files
• Number of files staged for commit
• Number of files modified but not staged for commit
• Number of conflicted files
• I've improved the detached head mode: currently, when in detached head mode, if there is a tag which describe this commit, the name of the tag is display instead of the sha1. Otherwise, if there is no tag describing HEAD, the sha1 is displayed.
• I've chosen UTF-8 characters for each info.

For the prompt to still be fast, I tried my best to minimize the number of shell commands launched.
In your version, 2 git processes are launched, in my version, I succeed to keep the same number: I only launch 2 git subprocesses, but there is much more info displayed.

I still don't like the default color I chose for "modified but not staged for commit". Do you have a better idea?

This is the longest prompt possible:

• The HEAD is detached, and since no tag describes this commit, the sha1 is printed, along with an anchor UTF8 character.
• There are 2 files staged for commit
• The are 3 files modified but not stagged for commit
• There is 1 untracked file
• There is 1 conflicted file (unmerged).

[mwetterw]

This screenshot is with attached head on branch master, and

• 1 commit ahead remote tracking branch
• 3 commits behind remote tracking branch
  and the same git status as the previous picture.

[mwetterw]

My version also supports unborn branch (if you just ran "git init", and there is no master branch yet).

[Anarky]

There is a better way to do this:
branch = '%c %s' % (u'\u2693', detached_ref)
It's easier to read and it prevents to have a unicode character in the code (also I guess it's a little bit faster since it doesn't call any functions).

[Anarky]

@MartinWetterwald : I made a few comments on this PR, do you prefer that I fork your repo, make a PR on it, so you can do a new PR with everything integrated? I hope it will be merged!

[marcioAlmada]

this looks so great! will it be merged?

[mwetterw]

@marcioAlmada I have no idea... I hope it will be merged too!
I still have some ideas like adding info on current rebasing & current bisecting, but I don't know if it's worth because it would need new sub-processes to be launched.

[Anarky]

@MartinWetterwald I forgot to say, your updated regex works fine now :)
What do you think about my other comments? Do you prefer that I make a PR on your fork?

[dserodio]

Great work, thanks! What font are you using for your screenshots? The unicode characters look a little funky with the Sauce Code Pro font I'm using.

[mwetterw]

@Anarky Sorry for the late answer! Yes, could you make a PR?

[mwetterw]

@Anarky Actually I've just committed the changes you suggested but I've defined a "symbols" variable instead so that all changes will be able to be done at one place.

[mwetterw]

@b-ryan I would like to know if you may be interested in merging this pull request. Can you test it out and tell me how do you think about it? I use it for 1,5 year and I really find it useful.
I extract much more info from git with the same number of shell processes than the existing git segment (2).
I attached a shell below script to help you generate quickly a dirty git repo with 2 untracked files, 2 staged files, 2 modified files and 2 conflicts. After the execution, cd gittest.

You may also test detached HEAD mode (after executing my script, run git reset --hard HEAD && git clean -f && git checkout HEAD~
After that create a tag to test detached HEAD with tag git tag MyTest.

#!/bin/bash
mkdir gittest
cd gittest
git init
echo test1 > test1
echo test1 > test2
echo test1 > test3
echo test1 > test4
git add test3 test4
git commit -m "Test"
git checkout -b testing
echo test2 > test3
echo test2 > test4
git commit -am "Test 2"
git checkout master
echo test1 > test5
echo test1 > test6
git add test5 test6
echo test3 > test3
echo test3 > test4
git commit -am "Test 2"
echo test2 > test5
echo test2 > test6
touch test7 test8
git merge testing
git add test7 test8

[b-ryan]

Hey @MartinWetterwald, sorry for not responding sooner. I have looked through this PR a few times and been unsure what I think. My biggest concern is just over adding too many symbols where it's hard to understand what they mean. In general I am unsure of how to handle dramatic changes like this. I would worry about the majority of people disliking it. There isn't really a great way to know whether that would be the case.

There are definitely some things is here I like a lot though, like the unborn branch and showing the tag or sha1 in detached mode.

What would you think of not using separate colors for each of the indicators?

[mwetterw]

@b-ryan I understand your concern about adding too many symbols and about people disliking it.

If the main concern is you fear people may find hard to understand all of the symbols meaning, don't you think that removing the color on the icons would make it worse? Color adds meaning. I've tried to use intuitive icons and colors. The colors reflects more or less the default colors shown by git status (the green for example means stagged for commit).

I agree it's hard to know how many people would like it. This is because only a minority of powerline-shell users is involved here in the discussions. If you like it yourself we could merge the PR and if later there is too many people disliking it, we could

• add a config value like GIT_ADVANCED_PROMPT to allow people to get the simple one
• or revert my pull request altogether.
  I think this would be the only way to know how people think.

How do you think?

[phatblat]

It would be nice if this could be refactored so that each unique "segment" in your screenshot is actually a separate segment in segments/git_*.py. That way, users could enable and rearrange them in config.py depending on those they wanted to see on their prompt.

[b-ryan]

@phatblat it is a nice idea, but at the moment one of the largest problems with that is that each segment would need to shell out to git separately, which could make the prompt pretty slow. There could be ways around this, but to do it properly would likely require a larger change to the whole framework.

@MartinWetterwald what you said makes sense. I will give this code a run and come back with any issues. Assuming there are none, I'd like to merge this maybe tonight to keep if from being delayed further.

[b-ryan]

pdata is not great name. Maybe status_data instead?

[b-ryan]

Or maybe just move the git status call back into this function. Doesn't look like pdata is being used elsewhere.

[b-ryan]

From what I can see and from the testing I have done, everything looks good. There are a few refactorings that I think this change could benefit from, but I won't hold things up. I was just playing around in the code and can push up my own branch with those refactors.

I think the only thing that should be added before merging is something to the README to describe the symbols. I will look into doing that right now.

[b-ryan]

Comments welcome on #207

[b-ryan]

Thanks @MartinWetterwald

[phatblat]

This is so nice. I ❤️ the icons! Nice work everyone!

[mwetterw]

I'm really happy you decided to merge it. :)