Does it do shallow clones?

[p00f]

Because of this:https://github.com/hardcoreplayers/dashboard-nvim/issues/14, I had to revert to an earlier commit but I couldn't. git log -1, git log -2, git log -3 all show only the latest commit

[clason]

Yes, just like vim-plug it defaults to a shallow clone (--depth 1), but this is configurable (see the config in the README). You can always convert a shallow clone to a full one via git fetch --unshallow.

In fact, this raises a related point: would it make sense to (optionally) keep the shallow clone shallow when updating (using, e.g., the method in https://stackoverflow.com/a/27844773)?

Conversely, is there a way to support rolling back updates? (Clearly, at some point it's better to just jump into a terminal and just get your hands dirty with git, but vim-plug allows reverting updates from the summary screen with a keybinding in case you don't like the look of that commit message...)

[p00f]

Thanks, this was just a question (shallow clone or bug?). I don't know if I want full clone, so I'm closing this

You can always convert a shallow clone to a full one via git fetch --unshallow.

Damn git always surprises me with new commands/options

[wbthomason]

@clason Update rollback is something I would like to add but haven't gotten around to, yeah. I should look at how vim-plug does it; it probably won't be too involved.

[clason]

@wbthomason It doesn't look like it; just do git reset --hard and checkout if asked: https://github.com/junegunn/vim-plug/blob/13ea184015c30be5160ae285aedc0eaec0c72e6c/plug.vim#L2635

(Although that seems a bit simple -- what if you pull multiple commits? Better probably to save the current commit before pulling and then reverting to that.)

[wbthomason]

packer already has knowledge of the last "good" commit (used to compute the commit log of the diff), so it should be even easier - just check that revision out.

[wbthomason]

Hmm though shallow cloning may make what you suggest necessary... I'll try to look into this early next week.

[clason]

Hmm though shallow cloning may make what you suggest necessary... I'll try to look into this early next week.

Oh? I'd assumed that is only a problem if you want to go back past the first checkout -- which isn't really relevant for rolling back an update (to an already checked out repo)?

[wbthomason]

Ah, sorry, I was not at all clear - I was thinking about the case with the "maintain a shallow clone" technique from the StackOverflow post you linked. There, we would need to allow a reversion before "cleaning up" the repo after an update.

[clason]

Oh, right, yes, I forgot about that part -- I didn't think one could have both, and rollback is more useful than saving a few Kb in the long run.

But what you could do is shallow to the previous last known good commit, so the repo always has all commits between the previous and the current update, but not arbitrarily back? (Could be configurable to the last X updates back, but I'm not sure that's worth the added complexity.)

[wbthomason]

Added this in 83d1115. You can now press 'r' on an updated plugin in the results window to revert its update.

I should really also add something to display the keybindings for the results window/optionally configure them.

[clason]

I should really also add something to display the keybindings for the results window/optionally configure them.

Ooh, and if you do, maybe add something like <shift-cr> to show all details at once? (I usually want to do see all of them anyway.)

[wbthomason]

Good idea!