The dangers of Git on lsst-dev

Data Management DM Notifications
,
#1

Everyone, I wanted to throw up a quick post, in hopes that it can prevent someone from making the some dumb mistake as I did. Like many of you, I am used to working on branches and pushing changes to remote branches (see github). Yesterday I was doing some work on LSST-dev (where normally I use my laptop) and force pushed my branch, as I wanted to overwrite the older work done on the branch. To my horror, git force pushed all the branches that I had checked out, including master. This forced master to be reverted back to the state it was the last time I had pulled, erasing peoples changes. Why did this happen? We I am so used to the default behavior of git 2.x where it will only push based on the current branch you are working on. LSST-Dev has git version 1.9.(3/4) from 2014. Git versions prior to 2.x synchronize all branches when you push by default. This behavior can be changed by putting

[push]
      default = simple

into your .gitconfig file. Other people may have different workflows, but I just wanted to give people a heads up, lest this happen to them, especially for anyone new to get who may be used to the behavior they see on their personal systems.

1 Like
DM Weekly Highlights 2016-10-05 to 2016-10-11
#2

Neither lsst-dev nor lsst-dev7 have upstream git afaik unless it is stack provided. If moving up in version would be beneficial, start a RFC and let’s upgrade git on those systems. I would prefer to have it updated on lsst-dev7 only and incentive people to transition over from lsst-dev; there’s really no reason at this point to not use lsst-dev7 aside from free of users trusting gpfs which is not yet providing disaster recovery. The official transition is coming.

#3

The shared stack on lsst-dev (or -dev7) doesn’t include git. However:

[swinbank@lsst-dev ~]$ rpm -q git
git-1.7.1-4.el6_7.1.x86_64
[swinbank@lsst-dev ~]$ /usr/bin/git --version
git version 1.7.1
[swinbank@lsst-dev ~]$ /opt/rh/devtoolset-3/root/usr/bin/git --version
git version 1.9.3

On -dev7, git 1.8.3.1 is installed by RPM.

#4

The Developer Toolset includes git 1.9.3, or one can set up 1.9.4 as described in the Developer Guide. This blog is helpful about what has changed in git v2 (thanks @srp!). If one always specifies what and where to push, then the changes do not affect. As our development workflow includes force-push, would it be safer to recommend specifying what/where when force-pushing, as opposed to relying on the default which may change from version to version? (git push --force is here in the Developer Guide),

#5

I think our developer guide needs to very prominently declare that all developers should have @natelust’s snippet above in their .gitconfig, so they get consistent behavior no matter what git version they have.

We did have that recommendation in our old git docs on trac, though it wasn’t terribly prominent there - probably because it didn’t have to be, because we disallowed force-pushes and hence this came up as a “why can’t I push” problem rather than a “I’ve just rewritten master” problem.

1 Like
#6

Github can disable force push to master and I’m pretty sure we agreed that this feature should be enabled in all our repos.

1 Like
#7

Yes, I think we agreed upon this in RFC-121 and there’s a ticket to implement it: DM-5051.

We could prioritize this automation (or do it manually; I’m doing this with my own repos as I work on them).

I’ll add this text to the Developer Guide.

1 Like
#8

Seconding this. Even with the config settings, it’s a behavior that could change without the user knowing about it (if e.g. they push from a new computer for the first time).

#9

For Firefly, we disable force pushes to key branches.