On Dienstag 08 Februar 2011, Christoph Feck wrote:
> I don't want to. Not yet. But the more I read here, the more
> confused I get.
the book "Pro Git" was/is very helpful for me and easy to
read. However my copy from 2009 does not mention rerere yet
http://progit.org/2010/03/08/rerere.html
--
W
> > oh, well. i give up.
I don't want to. Not yet. But the more I read here, the more confused I get.
Christoph Feck (kdepepo)
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
On Tue, Feb 8, 2011 at 13:45, David Faure wrote:
> While I very much agree with you on the very steep learning curve, I have to
> say that every time I use "svn blame" and I end up on a "merged branch foo"
> huge commit, I curse at svn's inability to preserve branch history.
>
> This is one of the
On Tuesday 08 February 2011, Arnold Krille wrote:
> On Tuesday 08 February 2011 17:55:03 Alexander Neundorf 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
- Original Message -
> why not just use a central
> repository system
> that just doesn't allow all these ugly things? And maybe doesn't have
> such a
> steep learning curve?
+1!
Best,
--
Tom Albers
KDE Sysadmin
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscri
On Tuesday 08 February 2011 17:55:03 Alexander Neundorf 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. prefera
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 res
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 w
On Tue, Feb 08, 2011 at 09:20:55PM +1300, Ben Cooksley wrote:
> Do not run "git pull --rebase" after performing the merge, under any
> circumstances.
>
ding ding ding - bingo!
On Wed, Feb 02, 2011 at 10:27:02AM +0100, Oswald Buddenhagen wrote:
> and remember that following receipes does *not* wor
On Tuesday, 8 de February de 2011 21:20:55 Ben Cooksley wrote:
> Just a word of warning, if you are going to merge two branches
> together, make sure to run "git pull --rebase" before you conduct the
> merge. Once you have conducted the merge, use "git pull" if you
> encounter a non-fast forward er
Hi all,
Just a word of warning, if you are going to merge two branches
together, make sure to run "git pull --rebase" before you conduct the
merge. Once you have conducted the merge, use "git pull" if you
encounter a non-fast forward error. Do not run "git pull --rebase"
after performing the merge
11 matches
Mail list logo
