Hi Josef, I`m not a Git expert, and I know less of Subversion, but following your explanation, I might try to help, at least until more experienced people join.
On 14/12/2017 14:09, Josef Wolf wrote: > > Every machine has a working copy of the repository in a specific > directory. A cron job (running every 15 minutes) executes "svn > update" and executes the scripts which are contained in this working > copy. > ... > Sometimes, I need to fix a problem on some host or need to implement > a new feature. For this, I go to the working copy of a host where the > change needs to be done and start haking. With svn, I don't need to > stop the cron job. "svn update" will happily merge any in-coming > changes and leave alone the files which were not modified upstream. > Conflicts with my local modifications which I am currently hacking on > are extremely rare, because the scripts are pretty much independent. > So I'm pretty much happy with this mode of operation. Aside "update and merge" working copy while you`re hacking on it, what happens with "execute" part? It seems really strange that you don`t mind cron job running the same scripts which you are actively working on, thus being in an inconsistent state, if not broken, even. > With git, by contrast, this won't work. Git will refuse to pull > anything as long as there are ANY local modifications. Not sure what`s happening at your end, but "ANY" part shouldn`t be true - you can have local modifications and still execute `git pull` successfully. Only if you have local modifications in files that _also_ changed on the remote end, `git pull` aborts (fetch of the remote branch succeeds, actually, just merge with local branch is aborted). Now, having in mind you said conflicts are extremely rare in your flow anyway, would this be enough for you? Of course, provided that issue you`re having with being unable to `git pull` with ANY local modifications, as you wrote, is resolved first. > The cron job would need to > > git stash > git pull > git stash pop > > But this will temporarily remove my local modifications. If I happen > to do a test run at this time, the test run would NOT contain the > local modifications which I was about to test. Even worse: if I > happen to save one of the modified files while the modifications are > in the stash, the "git stash pop" will definitely cause a conflict, > although nothing really changed. Is `git stash pop` causing conflicts your only concern here? How about a situation where you save one of the modified files _after_ `git stash pop` was successful, effectively discarding any updates introduced by `git pull` from remote end...? As you basically have a flow where two users (you and cron job) can edit same files at the same time, desired outcome might be a bit ambiguous, especially when scheduled execution of those files is added to the mix. > So, how would I get this workflow with git? Is it possible to emulate > the behavior of "svn update"? > > Any ideas? I`m thinking of a workflow involving (scripted) creation of a temporary branch at fetched remote branch position, and using something like `git checkout --merge <temp_branch>` to merge your local modifications to latest changes fetched from remote (ending up with conflicts inside working tree, if any), which would seem to simulate `svn update` as desired (if I understand it correctly), but it might be good to address some of the concerns I raised above first. Regards, Buga