git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
To: Josef Wolf <jw@raven.inka.de>, git@vger.kernel.org
Subject: Re: Need help migrating workflow from svn to git.
Date: Fri, 15 Dec 2017 19:24:03 +0100	[thread overview]
Message-ID: <0c0867d8-73d7-3577-be26-2a9a7691d58b@gmail.com> (raw)
In-Reply-To: <20171215124739.GC18542@raven.inka.de>

Hi Josef,

Thank you for your patient answers. From what you said here and in 
that other reply[1], 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

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

Regards, Buga

[1] https://public-inbox.org/git/20171215130645.GD18542@raven.inka.de/

  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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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 \
    --in-reply-to=0c0867d8-73d7-3577-be26-2a9a7691d58b@gmail.com \
    --to=igor.d.djordjevic@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jw@raven.inka.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://80x24.org/mirrors/git.git

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