Re: Reference help

[Ævar Arnfjörð Bjarmason]

On Tue, May 2, 2017 at 9:33 PM, Desjardin, Donald
 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.

Reference help

[Desjardin, Donald]

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).

Thanks,

Don Desjardin