Skip to content
This repository has been archived by the owner on May 21, 2024. It is now read-only.

Use git porcelain for git commands where applicable #49

Merged
merged 5 commits into from
Aug 28, 2013
Merged

Use git porcelain for git commands where applicable #49

merged 5 commits into from
Aug 28, 2013

Conversation

mjc
Copy link
Contributor

@mjc mjc commented Aug 28, 2013

  • Use git symbolic-ref --short --quiet HEAD to get the name of the current branch to avoid parsing text and dealing with colors.
  • Use git rev-parse --verify --quiet @{upstream} to get the remote tracking branch.
  • Use git status --porcelain to get the list of changed files for dirty check.
  • Use git rev-list --left-right --count @{upstream}...HEAD (note the triple-dots instead of double-dots) to get behind/ahead counts, and thus avoid regexp parsing.

git symbolic-ref --quiet --short will print the short branch name
without color codes.  It will return exit code 1 in the case of being in
a detached HEAD state.
Git 1.6.6.1 and later support this notation for finding the upstream
branch.

This is useful because one might not be tracking origin/branchname.
git rev-list --left-right --count @{upstream}...HEAD outputs:
X   Y
where X is the number of commits the left side has ('behind,')
and Y is the number of commits the right side has ('ahead.')

This lets us get a precise count of aheads and behinds easily,
doing away with pattern matching and also letting us be a bit
more intelligent about when automatic updating is a good idea.
@lad1337
Copy link
Owner

lad1337 commented Aug 28, 2013

this is beautiful !

lad1337 added a commit that referenced this pull request Aug 28, 2013
…ere-applicable

Use git porcelain for git commands where applicable
@lad1337 lad1337 merged commit c82156f into lad1337:master Aug 28, 2013
@mjc
Copy link
Contributor Author

mjc commented Aug 28, 2013

Happy to help :)

A thought occurred to me a moment after you merged this - was the intent of git rev-parse origin/%s to always update from origin, or were you wanting to use the remote tracking branch?

In my case, upstream/master is actually the remote for your repo, and origin is my fork - if the goal is to make sure that the updater pulls from your repo perhaps it would be wise to have the updater add its own remote... ?

@lad1337
Copy link
Owner

lad1337 commented Aug 28, 2013

i am fine with leaving it at "origin" since git sets it to the repo it came from it would only make sense to update from there.

if i ever stop working on it and someone else is the main developer there is no issue at all ... i mean i could start using your fork without the need to change the code.

and in the case of the developer that has its own fork but whats to run from my repo he can change the remote ... i believe someone with a fork is capable of changing a remote.

but this is all just for a git installation. at some point (hopefully) the binaries will be me much more popular and the current solution is far from optimal :/

@mjc
Copy link
Contributor Author

mjc commented Aug 28, 2013

Right, now git branch --set-upstream-to=another_remote/awesome current_branch would change which remote and branch it updates from. This is what I initially thought you'd wanted. :)

@lad1337
Copy link
Owner

lad1337 commented Aug 28, 2013

i don't see a reason to hardcode my repo into it ... if you get it from here fine if you get it from somewhere else also fine ^^

ps your help is very much appreciated ! :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants