Create Changelog when performing BundleInstall! #162

Merged
merged 6 commits into from Apr 19, 2012

Conversation

Projects
None yet
3 participants
@zolrath
Contributor

zolrath commented Apr 5, 2012

Keeps track of the current commit before performing an update and adds all commits pulled in the update to a Changelog, accessible via pressing 'u' after BundleInstall! completes.

Found myself going to github to see what was changed every time I saw a + next to a bundle name when updating.
This eliminates that need by making all the changes a keystroke away.

@zolrath

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 5, 2012

Contributor

Discovered an issue with Bundles that don't exist yet, will reopen when resolved.

Contributor

zolrath commented Apr 5, 2012

Discovered an issue with Bundles that don't exist yet, will reopen when resolved.

@zolrath zolrath closed this Apr 5, 2012

@zolrath zolrath reopened this Apr 5, 2012

@zolrath

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 5, 2012

Contributor

Resolved the issue with Bundles that lacked a .git directory.

Contributor

zolrath commented Apr 5, 2012

Resolved the issue with Bundles that lacked a .git directory.

@gmarik

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 5, 2012

Contributor

Hey @zolrath
Interesting idea!
I'll play with it and get back to you...

Contributor

gmarik commented Apr 5, 2012

Hey @zolrath
Interesting idea!
I'll play with it and get back to you...

@zolrath

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 6, 2012

Contributor

I just went through in an attempt to make my code fit better with yours, single quoted strings instead of double quoted and whatnot. I noticed you use if..endif most of the time but there are a few instances of if...end.

I'll only push the changes related to the Changelog for now but if you'd like I can submit the if...endif standardization as a separate pull request?

Contributor

zolrath commented Apr 6, 2012

I just went through in an attempt to make my code fit better with yours, single quoted strings instead of double quoted and whatnot. I noticed you use if..endif most of the time but there are a few instances of if...end.

I'll only push the changes related to the Changelog for now but if you'd like I can submit the if...endif standardization as a separate pull request?

Create Changelog when performing BundleInstall!
Keeps track of the current commit with a vundle_update tag before
perfoming an update and adds all commits pulled in the update to a
Changelog accessible via pressing 'u' after BundleInstall! completes.
@StanAngeloff

This comment has been minimized.

Show comment Hide comment
@StanAngeloff

StanAngeloff Apr 17, 2012

Love the idea, I was going to suggest doing it only for GitHub repos by using the /compare facility. I would normally go into the 'Log' view after :BundleInstall!<CR>, git rid of all Current branch... then for each remaining update I have recorded a macro to transform into something like this.

Looking forward to what comes out of this.

Love the idea, I was going to suggest doing it only for GitHub repos by using the /compare facility. I would normally go into the 'Log' view after :BundleInstall!<CR>, git rid of all Current branch... then for each remaining update I have recorded a macro to transform into something like this.

Looking forward to what comes out of this.

@zolrath

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 17, 2012

Contributor

How does this work for you @StanAngeloff ?

Updated Bundle: ctrlp.vim
Compare at: https://github.com/kien/ctrlp.vim/compare/863996ce26...master
  * Update help   Kien N, 12 hours ago
  * Tweak mru and buffer sorting   Kien N, 18 hours ago
  * Don't need to check pathmode   Kien N, 28 hours ago
  * Save bookmarks before exiting   Kien N, 29 hours ago
  * Use a few curly braces variables   Kien N, 29 hours ago

@gmarik, Have you had a chance to try out the newer delayed implementation?

Contributor

zolrath commented Apr 17, 2012

How does this work for you @StanAngeloff ?

Updated Bundle: ctrlp.vim
Compare at: https://github.com/kien/ctrlp.vim/compare/863996ce26...master
  * Update help   Kien N, 12 hours ago
  * Tweak mru and buffer sorting   Kien N, 18 hours ago
  * Don't need to check pathmode   Kien N, 28 hours ago
  * Save bookmarks before exiting   Kien N, 29 hours ago
  * Use a few curly braces variables   Kien N, 29 hours ago

@gmarik, Have you had a chance to try out the newer delayed implementation?

@StanAngeloff

This comment has been minimized.

Show comment Hide comment
@StanAngeloff

StanAngeloff Apr 17, 2012

I would find that very helpful, yes. Only concern is having to diff against master which may not be the default repo branch?

Perhaps storing git rev-parse HEAD before and after the update to obtain the SHA of the commits?

I would find that very helpful, yes. Only concern is having to diff against master which may not be the default repo branch?

Perhaps storing git rev-parse HEAD before and after the update to obtain the SHA of the commits?

Add GitHub Compare link to Changelog.
If the Bundle is hosted on GitHub include link to compare the commit range
visually on GitHub.
@gmarik

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 17, 2012

i don't think the above 3 lines are needed here , as return 'updated'(:227) means that there were changes made.
You can probably just add it tog:updated_bundles

i don't think the above 3 lines are needed here , as return 'updated'(:227) means that there were changes made.
You can probably just add it tog:updated_bundles

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 17, 2012

Owner

The only problem with return 'updated' is that both new Bundles and Updated Bundles return 'updated'
The check for git rev-list vundle_update returning a v:shell_error makes sure that we don't get garbage output with new bundles, though comparing the two commits is entirely unnecessary.

Without checking for v:shell_error:

Updated Bundle: ZoomWin
Compare at: https://github.com/vim-scripts/ZoomWin/compare/fatal: amb...HEAD
  fatal: ambiguous argument 'vundle_update..HEAD': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions
Owner

zolrath replied Apr 17, 2012

The only problem with return 'updated' is that both new Bundles and Updated Bundles return 'updated'
The check for git rev-list vundle_update returning a v:shell_error makes sure that we don't get garbage output with new bundles, though comparing the two commits is entirely unnecessary.

Without checking for v:shell_error:

Updated Bundle: ZoomWin
Compare at: https://github.com/vim-scripts/ZoomWin/compare/fatal: amb...HEAD
  fatal: ambiguous argument 'vundle_update..HEAD': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 17, 2012

I see, maybe we need to add new status then, so we can distinguish betwen new/updates

I see, maybe we need to add new status then, so we can distinguish betwen new/updates

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 17, 2012

Owner

Added a new status in the newest commit.

Owner

zolrath replied Apr 17, 2012

Added a new status in the newest commit.

@gmarik

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 17, 2012

Can we also have :ChangeLog not depend on g:vundle_changelog?
Since we have tags :ChangeLog may be generated any time (therefore do not depend on :BundleInstall)

Can we also have :ChangeLog not depend on g:vundle_changelog?
Since we have tags :ChangeLog may be generated any time (therefore do not depend on :BundleInstall)

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 17, 2012

Owner

My first pass simply went through and compared all the vundle_update tags to HEAD and built a Changelog for the modified Bundles but it took significantly longer to build the Changelog. I thought it had frozen the first time I ran that version, which doesn't seem like a good user experience.
Thoughts?

Owner

zolrath replied Apr 17, 2012

My first pass simply went through and compared all the vundle_update tags to HEAD and built a Changelog for the modified Bundles but it took significantly longer to build the Changelog. I thought it had frozen the first time I ran that version, which doesn't seem like a good user experience.
Thoughts?

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 17, 2012

yeah, this will require making it unbuffered (write updates to the window itself instead of array).
Can't be 100% positive if it's possible tho )

yeah, this will require making it unbuffered (write updates to the window itself instead of array).
Can't be 100% positive if it's possible tho )

@gmarik

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 17, 2012

Nothing else I guess.

Let me know what you think!
Thank you!

gmarik commented on 0956084 Apr 17, 2012

Nothing else I guess.

Let me know what you think!
Thank you!

This comment has been minimized.

Show comment Hide comment
@zolrath

zolrath Apr 17, 2012

Owner

I implemented the new and updated status changes in the newest commit!
If you'd like to look at the previous implementation that iterated over each Bundle looking for updates with the tags I've included both versions in a gist: https://gist.github.com/2409649

As is I would prefer to go with the version that builds an updated_bundle list as we update Bundles so the user has a fluid experience.

Owner

zolrath replied Apr 17, 2012

I implemented the new and updated status changes in the newest commit!
If you'd like to look at the previous implementation that iterated over each Bundle looking for updates with the tags I've included both versions in a gist: https://gist.github.com/2409649

As is I would prefer to go with the version that builds an updated_bundle list as we update Bundles so the user has a fluid experience.

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 18, 2012

Please merge latest Vundle and let me know what you think!

Please merge latest Vundle and let me know what you think!

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 18, 2012

As for gist, i'm ok going with updated_bundles as initial version, since we've minimized extra work down to tag creation during installation process...

As for gist, i'm ok going with updated_bundles as initial version, since we've minimized extra work down to tag creation during installation process...

gmarik and others added some commits Apr 18, 2012

Use 'new' & 'updated' to build updated_bundle list
Distinction between `new` and `updated` simplifies the process
of adding a bundle to the updated_bundle list.
Get initial/updated shas from `git pull` output.
Instead of creating a vundle_update tag to compare changes between update
and HEAD we now use the output from `git pull` to get initial/updated shas.
Add message on how to view changelog after Update.
If no errors exist, the status-line will inform users how to view the
Changelog after BundleUpdate! is completed.

gmarik added a commit that referenced this pull request Apr 19, 2012

Merge pull request #162 from zolrath/master
Create Changelog when performing BundleInstall!

@gmarik gmarik merged commit eb9eba2 into VundleVim:master Apr 19, 2012

@gmarik

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 19, 2012

Contributor

Thank you! )

Contributor

gmarik commented Apr 19, 2012

Thank you! )

@StanAngeloff

This comment has been minimized.

Show comment Hide comment
@StanAngeloff

StanAngeloff Apr 20, 2012

I just updated to master and on BundleInstall! I get a lot of these:

Processing 'XXX/YYY'

Error detected while processing function vundle#installer#new..<SNR>100_process..vundle#installer#run..vundle#installer#install..<SNR>100_sync..<SNR>10
0_add_to_updated_bundles:
line    2:
E684: list index out of range: 1
E15: Invalid expression: git_pull_shas[1]
Error detected while processing function vundle#installer#new..<SNR>100_process:
line   13:
E121: Undefined variable: g:vundle_last_status
E15: Invalid expression: 'error' == g:vundle_last_status
line   17:
E121: Undefined variable: g:vundle_last_status
E15: Invalid expression: 'updated' == g:vundle_last_status && empty(msg)

" Then a lot, lot of these for each bundle.

Processing 'XXX/YYY'
E684: list index out of range: 1
E15: Invalid expression: git_pull_shas[1]

When I print the result of the git pull command, it is:

Current branch master is up to date.

whereas the code is looking for up-to-date. I don't have additional locales (other than British English) installed on my machine, but it seems like using something like LANG=fr LC_ALL=fr vim -c 'BundleInstall!' would also break as all messages would be printed in French.

I've never done much VimScripting, but will submit a patch as a follow-up reply.

I just updated to master and on BundleInstall! I get a lot of these:

Processing 'XXX/YYY'

Error detected while processing function vundle#installer#new..<SNR>100_process..vundle#installer#run..vundle#installer#install..<SNR>100_sync..<SNR>10
0_add_to_updated_bundles:
line    2:
E684: list index out of range: 1
E15: Invalid expression: git_pull_shas[1]
Error detected while processing function vundle#installer#new..<SNR>100_process:
line   13:
E121: Undefined variable: g:vundle_last_status
E15: Invalid expression: 'error' == g:vundle_last_status
line   17:
E121: Undefined variable: g:vundle_last_status
E15: Invalid expression: 'updated' == g:vundle_last_status && empty(msg)

" Then a lot, lot of these for each bundle.

Processing 'XXX/YYY'
E684: list index out of range: 1
E15: Invalid expression: git_pull_shas[1]

When I print the result of the git pull command, it is:

Current branch master is up to date.

whereas the code is looking for up-to-date. I don't have additional locales (other than British English) installed on my machine, but it seems like using something like LANG=fr LC_ALL=fr vim -c 'BundleInstall!' would also break as all messages would be printed in French.

I've never done much VimScripting, but will submit a patch as a follow-up reply.

gmarik added a commit that referenced this pull request Apr 20, 2012

Safeguard when no matches
- addresses #162 issues
@gmarik

This comment has been minimized.

Show comment Hide comment
@gmarik

gmarik Apr 20, 2012

Contributor

just pushed fix.

Before changing to ref-list solution, would like to know how git pull output differs.

@StanAngeloff, what git version you have?

This goes beyond :ChangeLog issue, as Vundle relies on output heavily.

UPD:
ok, understand the whole thing now after rereading your msg...
@StanAngeloff thanks for bringing it up.

Contributor

gmarik commented Apr 20, 2012

just pushed fix.

Before changing to ref-list solution, would like to know how git pull output differs.

@StanAngeloff, what git version you have?

This goes beyond :ChangeLog issue, as Vundle relies on output heavily.

UPD:
ok, understand the whole thing now after rereading your msg...
@StanAngeloff thanks for bringing it up.

@StanAngeloff

This comment has been minimized.

Show comment Hide comment
@StanAngeloff

StanAngeloff Apr 20, 2012

Using a blank Vagrant Ubuntu 10.04-x86-64 box here are some details about the environment and output:

$ sudo apt-get install git-core
$ uname -a
Linux lucid64 2.6.32-33-server #70-Ubuntu SMP Thu Jul 7 22:28:30 UTC 2011 x86_64 GNU/Linux
$ git --version
git version 1.7.0.4
$ git clone git://github.com/gmarik/vundle.git
$ cd vundle
$ git pull
Already up-to-date.

Here is the same on my base Ubuntu 11.10 machine:

$ uname -a
Linux stan-inspiron 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ git --version
git version 1.7.5.4
$ git clone git://github.com/gmarik/vundle.git
$ cd vundle
$ git pull
Current branch master is up to date.

Let me know if I can help any further.

EDIT: I believe in my case it's also down to ~/.gitconfig where I have branch.autosetuprebase = always which means all git pulls would be rebases.

I wasn't able to force git to change command output by changing LANG or LC_ALL.

Using a blank Vagrant Ubuntu 10.04-x86-64 box here are some details about the environment and output:

$ sudo apt-get install git-core
$ uname -a
Linux lucid64 2.6.32-33-server #70-Ubuntu SMP Thu Jul 7 22:28:30 UTC 2011 x86_64 GNU/Linux
$ git --version
git version 1.7.0.4
$ git clone git://github.com/gmarik/vundle.git
$ cd vundle
$ git pull
Already up-to-date.

Here is the same on my base Ubuntu 11.10 machine:

$ uname -a
Linux stan-inspiron 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$ git --version
git version 1.7.5.4
$ git clone git://github.com/gmarik/vundle.git
$ cd vundle
$ git pull
Current branch master is up to date.

Let me know if I can help any further.

EDIT: I believe in my case it's also down to ~/.gitconfig where I have branch.autosetuprebase = always which means all git pulls would be rebases.

I wasn't able to force git to change command output by changing LANG or LC_ALL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment