From: Igor Djordjevic <email@example.com>
To: Josef Wolf <firstname.lastname@example.org>, email@example.com
Subject: Re: Need help migrating workflow from svn to git.
Date: Fri, 15 Dec 2017 19:24:03 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Thank you for your patient answers. From what you said here and in
that other reply, it looks like you know what you`re doing, you`re
aware of circumstances, and you still prefer doing it that way.
So, here it goes... :)
On 15/12/2017 13:47, Josef Wolf wrote:
> > 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?
Nope :) Here`s a script you can test to see if it works for you,
simulating `svn update` (at least how I perceived it).
Feel free to adapt as you feel like it (I used local "master" branch
and remote "origin/master", for example), or to speak up if any
additional info is needed.
git checkout -b temp && #1
git fetch && #2
git branch -f master origin/master && #3
git checkout -m master && #4
git add -u && #5
git reset && #6
git branch -d temp #7
1. Create temporary branch where we are, switching to it, so we can
update "master" without local modifications
2. Fetch latest updates
3. Update "master" to fetched "origin/master"
4. Switch to updated "master", merging local modifications
5. Mark any pending merge conflicts as resolved by staging them...
6. ... and unstage them right away
7. Delete temporary branch
Step (4) is what merges your local modifications with remote updates
(leaving conflicts, if any), where steps (5) and (6) are not needed
for a single run, but in case you don`t resolve conflicts before next
cron job executes this script again, step (1) will now fail without
them because of (still) unresolved merge conflicts.
So, as you seem to be pretty at ease with your flow, you might prefer
leaving those two steps (5, 6) in.
This does seem ugly and hacky, but if it works for you, I don`t judge :)
Please note that there might be better ways to accomplish this, I
repeat, I`m not an expert, but hopefully this could do the job.
Also, if I missed something, I hope someone will correct me.
next prev parent reply other threads:[~2017-12-15 18:24 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
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 [this message]
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).