Add branch information to short status

[rcdailey]

When running 'git number -s', the branch is now shown. This is the same as running:

$ git status --short --branch

The only change that has been made here is that the '--branch' option is now passed to git status.

Note that this is simpler than my first pull request a few weeks ago. Less duplicated code and I'm hoping the tests don't need to change. If you can tell me how to run the perl unit tests that you have, I am happy to verify they still work afterwards.

[holygeek]

You can run the perl unit tests by running prove from the top level directory:

$ prove
t/000_setup.t ................ 1/2 # Using git version 1.9.0
t/000_setup.t ................ ok
t/001_git-number.t ........... ok
t/002_git-list.t ............. ok
t/003_git-id.t ............... ok
t/004_submodule.t ............ Cloning into 'b'...
done.
t/004_submodule.t ............ ok
t/005_short_status.t ......... ok
t/006_custom_status_color.t .. ok
t/007_git-id-column.t ........ ok
All tests successful.
Files=8, Tests=31,  1 wallclock secs ( 0.04 usr  0.02 sys +  0.97 cusr  0.53 csys =  1.56 CPU)
Result: PASS

Running this on your branchoption branch breaks 2 tests since the changes "breaks" the -s functionality.

It's better to support a distinct option -b, just like git status does, for showing the branch name in short status mode.

[rcdailey]

Is there any way to make GIT status a passthrough like the other commands? Example:

$ git number status -s -b

You could then just use a simple set of regular expressions to determine what kind of status text you are parsing (long vs short, branch vs no branch).

This will give you a more extensible implementation without requiring special code to handle commands. On Feb 27, 2014 6:39 AM, "holygeek" notifications@github.com wrote:

You can run the perl unit tests by running prove from the top level directory:

$ prove t/000_setup.t ................ 1/2 # Using git version 1.9.0 t/000_setup.t ................ ok t/001_git-number.t ........... ok t/002_git-list.t ............. ok t/003_git-id.t ............... ok t/004_submodule.t ............ Cloning into 'b'... done. t/004_submodule.t ............ ok t/005_short_status.t ......... ok t/006_custom_status_color.t .. ok t/007_git-id-column.t ........ ok All tests successful. Files=8, Tests=31, 1 wallclock secs ( 0.04 usr 0.02 sys + 0.97 cusr 0.53 csys = 1.56 CPU) Result: PASS

Running this on your branchoption branch breaks 2 tests since the changes "breaks" the -s functionality.

It's better to support a distinct option -b, just like git status does, for showing the branch name in short status mode.

Reply to this email directly or view it on GitHubhttps://github.com/holygeek/git-number/pull/11#issuecomment-36237639 .

[holygeek]

That's not a bad idea.

The options that matter for git-number is the -c <cmd>, and the -h which shows the help text. The while loop that processes the option in git-number can simplified such that it only looks for -c or -h options, and as soon as it found any other option it breaks out of the loop and pass those other options to git-id, which in turn can check if the arguments passed to it matches the pattern \b(-s|--short)\b and act accordingly.

The tricky part is to do the above without breaking the unit tests ;)

The most I can do now is to make git-number pass anything given after -- to git status - commit coming soon on master.

[rcdailey]

The regex I was suggesting wouldn't check the parameters passed in. You would blindly execute the 'git status ' passed in without checking for --short, --branch, or anything. You would perform a regex on the first 1-2 lines of the status output to determine from the actual output text what kind of status format you need to parse. For example:

If the first line is "On branch..." then you know neither --short or --branch was specified.

If the first line contains '##' then you can assume --short --branch was specified.

If neither of the above match, then only --short was specified.

There might be other edge cases to check but by checking only the first line with a simple regex, you can parse that data in a specialized way without needing to care about what git options map to which output format. The benefit you get by doing this is that you just do a strict passthrough of the parameters to GIT, without needing to intercept them. It makes git-number more extensible.

---

Robert Dailey

On Thu, Feb 27, 2014 at 9:38 AM, holygeek notifications@github.com wrote:

That's not a bad idea.

The options that matter for git-number is the -c , and the -h which shows the help text. The while loop that processes the option in git-number can simplified such that it only looks for -c or -h options, and as soon as it found any other option it breaks out of the loop and pass those other options to git-id, which in turn can check if the arguments passed to it matches the pattern \b(-s|--short)\b and act accordingly.

The tricky part is to do the above without breaking the unit tests ;)

The most I can do now is to make git-number pass anything given after --to git status - commit coming soon on master.

Reply to this email directly or view it on GitHubhttps://github.com/holygeek/git-number/pull/11#issuecomment-36254476 .

[holygeek]

Checking against English words will fail when git is run in another locale - so it's better if we use command line options instead. Perhaps what I've just pushed to master (SHA1: cc85661be0546d2e5fce3f188c04ac0725f55f3c) is enough for handling arbitrary options needed to pass to git status at the moment. I do admit that the command line parsing code is becoming more convoluted :)

[rcdailey]

Good point about locale, I hadn't considered that. Your solution looks great though. Feel free to close my pull request. On Feb 27, 2014 10:53 AM, "holygeek" notifications@github.com wrote:

Checking against English words will fail when git is run in another locale

• so it's better if we use command line options instead. Perhaps what I've just pushed to master (SHA1: cc85661https://github.com/holygeek/git-number/commit/cc85661be0546d2e5fce3f188c04ac0725f55f3c) is enough for handling arbitrary options needed to pass to git status at the moment. I do admit that the command line parsing code is becoming more convoluted :)

Reply to this email directly or view it on GitHubhttps://github.com/holygeek/git-number/pull/11#issuecomment-36263467 .

[jarinudom]

[alias]
  st = number -s -- -b

totally works :)

[rcdailey]

Closing pull request, as I no longer use these scripts and I will not be maintaining this PR anymore.