On Tue, May 2, 2017 at 9:33 PM, Desjardin, Donald <Donald.Desjardin@xxxxxxxxxxx> wrote: > Sorry if this is not the place for this. > > I'm looking for any reference to potential problems when updating a git client (say from 1.7.N to 1.8.N) with old workspaces. > > The scenario is this: > Lots of developers use a single machine for work > They have lots of workspaces created using the old client > We want to upgrade to the new client > > Are there any potential problems just upgrading the client and NOT re-cloning their workspaces (or stashing or committing or pushing)? > > Subversion had/has some feature that could tell that the workspace was created using an older client and you could magically run something to update the workspace. > > I'm not above telling all my developers to commit/push to a feature branch, remove the workspaces and re-clone as needed on a flag-day, but I'd like to know if I have to. > > If there is any documentation that talks about this (I know 1.7 is old). Git, unlike Subversion has used the same stable underlying storage format for all of its history. So you certainly don't need to migrate these checkouts when you upgrade git, they'll just work. There are several things that changed in the UI, some in incompatible ways, most prominently the behavior of "git push", but it's unlikely anyone will be affected by that beyond some minor annoyance. You can see announcements of major changes in git's release notes, which you can browse here: https://github.com/git/git/tree/master/Documentation/RelNotes E.g. 1.8.0.txt in that directory will have notes for upgrading from 1.7.x to 1.8.0. Note that both 1.7.0 and 1.8.0 are really old, from 2010 & 2012 respectively. Although it'll be a bigger jump you might want to consider updating to the most recent release directly, currently 2.12.2, this'll be more changes at once, but you won't have to go from 1.7 to 1.8, 1.8 to 1.9 etc.