|
This is a grouping of three related proposals
(1) Creating a common codepath for the git resource
(2) Adding developer_mode
(3) Adding a local_changes parameter.
Git Resource Change 1: Robustification
The idea here is to put checkout and update onto a common codepath, ensuring that anything that checkout sets up, sync updates (and vice versa). This gives us greater confidence that the code works in both cases, and reduces the test burden. It also makes it easier to add features like developer_mode which would have to be put into both codepaths.
Presently, the git resource works like this:
This model puts setup in the else branch, and maintenance in the if branch. What may not be obvious is that some things that get set in the else branch, don’t get updated in the if branch. For example, the branch doesn’t get updated (if it gets out of sync, it won’t get fixed).
Proposal: One Thing At A Time
The way to think about the resource is, it declares the state it wants to move to. It should be in branch X, it should be at revision Y, it should come from repository Z ...
The proposed flow takes it one piece at a time, first cloning from the repository, then getting on the right branch, then getting on the right revision, then getting the right remotes ...
This model has the general pattern: if <thing is not what it should be> <make it so>. By breaking it up into fine-grained increments, any individual thing that goes wrong gets fixed, even if other things are in their proper state. (i.e. if the branch changes but nothing else, the branch gets smacked back into shape without changing anything else.)
This model also allows us to have exactly one codepath, so that checkout and sync are both (largely) tested simultaneously.
Git Resource Change 2: developer_mode
When setting up git repositories for use by a developer, the current detached “deploy” branch is less than ideal. This proposal adds “developer_mode” to the git resource, which does not create “deploy” branch and instead leaves the user in whatever branch they wanted to use. This would change the above process like so:
This is still suboptimal due to the “git reset --hard”, but it gets us a little closer to where we want to be. We address that issue in the third change.
Git Resource Change 3: update_method
One issue with the git resource at present is that the policy regarding files that get modified in-place is inflexible, and does not work well for developer mode because the default policy is to overwrite changes. This proposal adds an update_method attribute to the git resource, which allows you to specify what should happen with any modified files on your drive. The possible values are:
| Value |
Git command |
Local Modifications |
New Untracked Files |
Local Commits |
In Case Of Conflict |
Notes |
| :reset_merge |
git reset --merge |
Keeps changes |
Keeps new files |
Loses commits |
Fails update |
| :reset_hard |
git reset --hard |
Overwrites changes |
Keeps new files |
Loses commits |
Overwrites local changes |
Default |
| :reset_clean |
git reset --hard
git clean -d |
Overwrites changes |
Deletes new files |
Loses commits |
Overwrites local changes |
| :rebase |
git rebase |
Keeps changes |
Keeps new files |
Keeps (rebases) commits |
Fails update |
Default for developer_mode. Does not work with revision or tag. |
Unresolved
When do local_changes get updated?
If you have chosen git reset --hard (the default), there is another policy decision that needs to be made. If a file gets modified in-place, when should it get overwritten? Currently we wait until a revision happens on the server. One can imagine people who want their state to converge to the server’s state sooner than that. Perhaps a value like local_changes_update=:immediate or :on_version_change
|