Hi!
On Fri, May 24, 2013 at 12:56:50AM +0200, Thomas Rast wrote:
It is not --ignore-changes bit, and has never been.
Indeed, it has been my lack of imagination regarding what can go
wrong. I am fine with the changes not being shown in `git diff` and even
not so worried about them being
Linus Torvalds torva...@linux-foundation.org writes:
It would be a *horrible* mistake to make rebase the default, because
it's so much easier to screw things up that way.
That said, making no-ff the default, and then if that fails, saying
The pull was not a fast-forward pull, please say
On Thu, May 23, 2013 at 6:47 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
If the change in HEAD^ in the above example were to copy the whole A
and C from a different file, then your !found_guilty logic would
kick in and say all lines of A
On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano gits...@pobox.com wrote:
I would assume that no-ff above was meant to be --ff-only from
the first part of the message.
Yeah, I may need more coffee..
I also would assume that I can rephrase that setting pull.merge
(which does not exist) as
On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote:
Linus Torvalds torva...@linux-foundation.org writes:
It would be a *horrible* mistake to make rebase the default, because
it's so much easier to screw things up that way.
That said, making no-ff the default, and then if
On Thu, May 23, 2013 at 7:25 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote:
Linus Torvalds torva...@linux-foundation.org writes:
It would be a *horrible* mistake to make rebase the default, because
it's so much
101 - 106 of 106 matches
Mail list logo
