[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: question about git workflow
From:       Dan Nicholson <dbn.lists () gmail ! com>
Date:       2009-03-31 23:51:51
Message-ID: 91705d080903311651m64a8728and12137e13a3d080c () mail ! gmail ! com
[Download RAW message or body]

On Tue, Mar 31, 2009 at 4:40 PM, Pete Zaitcev <zaitcev@redhat.com> wrote:
> On Tue, 31 Mar 2009 18:42:02 +0200, Christoph Höger <choeger@cs.tu-berlin.de> wrote:
>
>> And the final question: When I got to the point of sending one single
>> patch and upstream merges it, how can I resync with upstream without
>> having to clone again?
>
> Sure, I always do  git pull.  If a conflict occurs, I do this
>  - Edit conflicts so the code looks good (using git status to remind
>   what's left, and then vi, /, >>> Enter ).
>  - make check  # just see how I'm doing
>  - git commit -a
>   This thing posts this scary message "oh you're committing a MERGE,
>   the sky is falling!" inside the commit template. Just do :wq
>   and let it commit
> In my experience, git merges pretty well. However, I need to watch
> out for an occasional double-patch when upstream rearranges chunks.
> In C, all functions look the same with 3-line context.

FYI, newer git added a --rebase switch to pull. So, you can do "git
pull --rebase origin", and it will just rebase whatever local commits
you have on top. Of course, you may still have conflicts, and that's
not a good idea if your repo is public.

--
Dan

-- 
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]