Auto Notify Git Pull

[hemanth]

Fixes issue #6

[sindresorhus]

why? what does it do? we're already in zsh

[sindresorhus]

Shouldn't this be async like the one in your blog post?

Can you fix merge conflict?

[hemanth]

@sindresorhus chpwd seems to be faster than bash, so async is not needed? will fix the conflicts soon!

[hemanth]

@sindresorhus Was speaking to few git experts they says (( $(git rev-list HEAD..@{u} --count) > 0 )) && echo "There are new things to merge" is a better way and a better message. Also it's only slow with cold cache.

There was also a suggestion to use backdoor, what do you suggest?

[sindresorhus]

(( $(git rev-list HEAD..@{u} --count) > 0 )) && echo "There are new things to merge" is a better way

Go for it.

HEAD..@{u}

What does this mean?

There was also a suggestion to use backdoor, what do you suggest?

Can you explain what it does and why it's needed?

[hemanth]

HEAD..@{u}

Is better than using HEAD...origin/master as it looks for all other branches and the .. and ... is commint-range . It can be even simpler git rev-list ..@{u} --count :)

Backdoor was suggested to emulate async process, but it was also clear that in this case async is not needed for zsh as it's only slow with cold cache.

[sindresorhus]

Backdoor was suggested to emulate async process, but it was also clear that in this case async is not needed for zsh as it's only slow with cold cache.

Interesting. Since it's async, how does it add the message when it returns? Like, what if i write something before it's shown. Not important here, but the git branch and dirty check can be slow in large repos. Wonder if it would be possible to use it there? Like, can it dynamically update the prompt?

[hemanth]

It just uses FD hack to simulate async, it does not have a callback as such, but /me needs to explore it more to see if it can dynamically update the prompt.

[sindresorhus]

ping

[hemanth]

Sorry for the delay! For something like dynamic update of the prompt, we could use this function with setopt PROMPT_SUBST

[sindresorhus]

k, can you fix the merge conflict?

[hemanth]

@sindresorhus It must be 🍏 now :)

[sindresorhus]

Tried it now. It only works after I do git fetch, which kinda destroys it all. Can you fix?

[hemanth]

@sindresorhus Fine now?

[sindresorhus]

@hemanth look at the diff here, no change.

I also discovered another bug. If the repo doesn't have a remote it will throw up:

fatal: ambiguous argument 'HEAD...origin/master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'

[hemanth]

@sindresorhus fix is to add the remote origin and do a rebase again?

[sindresorhus]

I don't understand the question?

[hemanth]

@sindresorhus Ha ok, I misunderstood it as an issue with merging, will work on it!

[willdurand]

👍

[sindresorhus]

Can we get this finished too? I have 🐫

[hemanth]

Sure!

Working on :

If the repo doesn't have a remote....

[sindresorhus]

ping

[hemanth]

@sindresorhus This shall be closed at any cost today! Sorry for this great delay!

[hemanth]

@sindresorhus Done, used a simple redirection, branch --set-upstream could also be used.

[sindresorhus]

Tried it now. It only works after I do git fetch, which kinda destroys it all.

[hemanth]

@sindresorhus Was wondering the same, git rev will assume a git fetch and does not go online, will that be fine for this scenario ? Or maybe should we stick to git ls-remote or git pull --dry-run or similar?

[sindresorhus]

@hemanth having to do git fetch first makes it pretty useless.

So, it's possible to use git ls-remote to do the same?

git pull --dry-run

git pull doesn't have a dry run.

Another solution would be to just do a git fetch, then run the current code, though I would prefer git ls-remote if it's possible to use it.

@pbrisbin thoughts?

[pbrisbin]

Hmm, I think it's a non-starter. This can't be done without somehow reaching out to the remote, and I don't want my prompt doing that all day long. If it were implemented, I'd quickly make a PR to add a disabling option ;).

I'm just one datapoint, but that's my 2c.

[sindresorhus]

What's wrong with reaching out to the remote if it happens transparently in the background?

Option ofc.

[pbrisbin]

If it's not done async (and this PR is not), then the delay is not transparent.

If it is done async, then there is very good likelihood of this:

~/Code/foo master
> vim src/maYou have stuff to pull..
in.c

[sindresorhus]

Isn't it possible to manipulate readline or something to get this:

~/Code/foo master  You have stuff to pull..
> vim src/main.c

[pbrisbin]

Isn't it possible to...

I like this prompt because it's minimal, fast, and cleanly implemented (tabs and comments not withstanding ;)). In my opinion, this feature is not worth the impact it'd have on those three things.

Again, just my 2c though.

[hemanth]

@sindresorhus I'm pawing at git ls-remote

@pbrisbin There was also a suggestion to use backdoor for async, if you scroll up. But this was not blocking the shell in any way with precmd, in case it does, any other suggestions for async?

[sindresorhus]

Closing in favor of #18.

@hemanth Thanks for the awesome idea :)

[hemanth]

@sindresorhus 👍