[Kde-scm-interest] Re: Usage of pull rebasing and merges

John Tapsell johnflux at gmail.com
Wed Feb 9 08:16:44 CET 2011


2011/2/9 Michael Pyne <mpyne at kde.org>:
> On Tuesday, February 08, 2011 14:04:14 John Tapsell wrote:
>> On 8 February 2011 18:27, Ian Monroe <ian at monroe.nu> wrote:
>> > On Tue, Feb 8, 2011 at 10:55, Alexander Neundorf <neundorf at kde.org> wrote:
>> >> On Tuesday 08 February 2011, Boudewijn Rempt wrote:
>> >>> On Tuesday 08 February 2011, Oswald Buddenhagen wrote:
>> >>> > > - just throw away the merge with git reset --hard HEAD~1 and redo
>> >>> > > it after git pull-ing. preferably, you should have git rerere
>> >>> > > enabled, so you won't have to repeat resolving any possible
>> >>> > > conflicts.
>> >>>
>> >>> Excuse my ignorance... But what is "git rerere"?
>> >>
>> >> These emails are a clear sign to me that we need recommended workflows
>> >> of how to do things...
>>
>> Of course it looks complicated if you start looking at the possible
>> ways it can go wrong, and the advanced features.
>>
>> But I have used git for more than two years now, and I still haven't
>> ever needed to merge.  Yes, you will make mistakes with git, but it's
>> extremely forgiving.  You can roll back to previous state at any
>> point.  You can't break your repository.
>
> On the contrary, after only a few weeks at most of using git routinely, I've
> already merged quite a few times. I didn't *have* to (I chould have cherry-
> picked instead), but part of the recommended git workflow of doing feature
> development in separate branches from master or other release branches kind of
> implies you should be merging more frequently than would have occurred with
> svn.

Or you could have just "git pull --rebase".  You chose to merge, and
that's great, but I'm saying that you can do perfectly fine with the
three commands I gave.

> I would have kept on developing in the same branch (master) if it weren't for
> the fact that XML support is highly likely to break something in kdesrc-build
> but at the same time my software can't be the only one that undergoes that
> kind of dangerous-ish development every so often. :)

Why does that require you to have a separate branch locally?  Just
don't push upstream until you're ready.  Or only push to your clone.

John


More information about the Kde-scm-interest mailing list