From: Igor Djordjevic <firstname.lastname@example.org>
To: Josef Wolf <email@example.com>
Subject: Re: Need help migrating workflow from svn to git.
Date: Thu, 14 Dec 2017 23:27:09 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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
> 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`
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.
next prev parent reply other threads:[~2017-12-14 22:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 13:09 Need help migrating workflow from svn to git Josef Wolf
2017-12-14 21:07 ` Randall S. Becker
2017-12-15 10:27 ` Josef Wolf
2017-12-14 22:27 ` Igor Djordjevic [this message]
2017-12-15 1:17 ` Igor Djordjevic
2017-12-15 13:06 ` Josef Wolf
2017-12-15 12:47 ` Josef Wolf
2017-12-15 18:24 ` Igor Djordjevic
2017-12-15 16:33 ` Junio C Hamano
2017-12-15 18:58 ` Igor Djordjevic
2017-12-15 19:09 ` Junio C Hamano
2017-12-15 19:20 ` Igor Djordjevic
2017-12-20 11:52 ` Josef Wolf
2017-12-20 11:43 ` Josef Wolf
2017-12-20 12:19 ` Josef Wolf
2017-12-21 22:04 ` Igor Djordjevic
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).