[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: question about git workflow
- From: Dan Nicholson <dbn lists gmail com>
- To: Development discussions related to Fedora <fedora-devel-list redhat com>
- Subject: Re: question about git workflow
- Date: Tue, 31 Mar 2009 16:51:51 -0700
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]