Thanks for your input, Igor!

On Thu, Dec 14, 2017 at 11:27:09PM +0100, Igor Djordjevic wrote:
> 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.

In theory, you're right. In practice, problems are almost non-existent because
of:

1. Scripts are independant from each other. Would there be a problem with one
   script, the other several hundred scripts will still continue to work.
2. Most changes to existing scripts are just minor tweaks. Not much room to
   wind up.
3. When new scripts/features are introduced, it is usually to some aspect that
   were non-existing before. Breaking something that did not work before is
   not a big issue.
4. Even IF cron happens to execute something half-baked, most of the time it
   will give a syntax error. The effect is as if the cron job would have been
   stopped entirely
5. When there's a major refactoring to be done where some problems are to
   expected, then the cron entry is disabled.

So, in practice, it's pretty much a non-issue.

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

Oh, you're right! I don't know where I catched the idea that ANY modification
would stop "git pull" from working...

> Now, having in mind you said conflicts are extremely rare in your 
> flow anyway, would this be enough for you?

No. There's still the issue with "git pop", even if no modifications are
coming from upstream.

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

It's both. With the conflict having the highest probability.

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

Yeah. That's the difference with svn: Svn won't touch the files unless there
are changes coming from upstream. In contrast, git-stash WILL touch ALL
locally modified files, even the files which were not touched at all upstream.

So with svn, only files are at risk which are locally modified AND which have
been changed upstream. With git-stash, EVERY locally modified file is at risk.

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

But this would require local modifications to be committed?

-- 
Josef Wolf
j...@raven.inka.de

Reply via email to