From: David Kastrup <dak@gnu•org>
To: Felipe Contreras <felipe.contreras@gmail•com>
Cc: Jeremy Morton <admin@game-point•net>,
Johan Herland <johan@herland•net>,
Git mailing list <git@vger•kernel.org>
Subject: Re: Recording the current branch on each commit?
Date: Mon, 28 Apr 2014 11:39:55 +0200 [thread overview]
Message-ID: <87bnvl6bdg.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <535e18cdc7bce_338911e930c72@nysa.notmuch> (Felipe Contreras's message of "Mon, 28 Apr 2014 04:01:01 -0500")
Felipe Contreras <felipe.contreras@gmail•com> writes:
> Jeremy Morton wrote:
>>
>> Sounds like the default behaviour of "git pull" might not be ideal if
>> it easily causes these problems.
>
> It's not idea. Virtually everyone agrees with that, even Linus
> Torvalds, and we have the patches to fix it, but it's not going to
> change.
>
> The Git project doesn't welcome change.
I can think of a few other things that "the Git project" or actually
pretty much everybody doesn't welcome.
It becomes easier to actually change things when communicating in a less
abrasive and destructive manner.
At any rate, releases involve time plans and testing periods.
Personally I think that the automerging behavior of "git pull" is one of
the most stupid traps Git has available for beginning contributors to
make a royal mess of their contributions. It's unbelievable that this
has not been defused a decade ago already.
But it hasn't, and such a change is no longer in a useful time frame for
a 2.0 release. Unless one wants to push back the 2.0 release
considerably for this alone. But then everybody will have a favorite
pet peeve, some likely more justified, some less, that he wants to get
into 2.0. I mean, I just sped up git-blame for serious use cases by a
factor of 3 or so at least, and there will be _no_ API changes and
user-visible consequences with that change.
So what?
If the thing has been important enough to get into 2.0, it has been
important enough to push for it _timely_ so that it had a chance at
considerable testing exposure.
That's what has been done with the "git push" changes. They were put in
timely, with quite a bit of warning about what will change and what
people are supposed to be doing about it. Again: bad enough that it
took as long as that to fix this insanely reckless default. The scale
of the git-pull problem is small in comparison as it only messes up a
single local branch instead of a whole set of upstream branches.
--
David Kastrup
next prev parent reply other threads:[~2014-04-28 12:05 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-26 23:56 Recording the current branch on each commit? Jeremy Morton
2014-04-27 8:51 ` Robin Rosenberg
2014-04-27 17:27 ` Jeremy Morton
2014-04-27 21:40 ` James Denholm
2014-04-27 22:12 ` Jeremy Morton
2014-04-27 22:31 ` James Denholm
2014-04-28 8:32 ` Felipe Contreras
2014-04-28 8:49 ` Jeremy Morton
2014-04-28 9:02 ` David Kastrup
2014-04-28 9:10 ` Jeremy Morton
2014-04-28 9:23 ` David Kastrup
2014-04-29 21:58 ` David Lang
2014-04-28 17:31 ` Junio C Hamano
2014-04-27 9:09 ` Johan Herland
2014-04-27 17:38 ` Jeremy Morton
2014-04-27 19:33 ` Johan Herland
2014-04-27 20:55 ` Jeremy Morton
2014-04-27 23:39 ` Johan Herland
2014-04-28 6:45 ` Christian Couder
2014-04-28 9:01 ` Jeremy Morton
2014-04-28 9:09 ` Johan Herland
2014-04-28 9:16 ` Jeremy Morton
2014-04-29 22:14 ` David Lang
2014-04-28 9:01 ` Felipe Contreras
2014-04-28 9:17 ` Jeremy Morton
2014-04-28 9:17 ` Felipe Contreras
2014-04-28 9:35 ` Jeremy Morton
2014-04-28 17:10 ` Felipe Contreras
2014-04-28 9:39 ` David Kastrup [this message]
2014-04-28 17:22 ` Felipe Contreras
2014-04-28 23:03 ` James Denholm
2014-04-28 23:09 ` Felipe Contreras
2014-04-28 23:40 ` Junio C Hamano
2014-04-28 23:50 ` Felipe Contreras
2014-04-29 0:10 ` Junio C Hamano
2014-04-29 0:59 ` Felipe Contreras
2014-04-29 1:29 ` James Denholm
2014-04-29 3:32 ` Felipe Contreras
2014-04-29 6:53 ` James Denholm
2014-04-29 8:28 ` Felipe Contreras
2014-04-29 9:00 ` David Kastrup
2014-04-29 9:25 ` Felipe Contreras
2014-04-29 9:47 ` David Kastrup
2014-04-29 9:54 ` Felipe Contreras
2014-04-29 10:14 ` David Kastrup
2014-04-29 10:17 ` Felipe Contreras
2014-04-29 10:37 ` David Kastrup
2014-04-29 11:46 ` Felipe Contreras
2014-04-29 10:59 ` James Denholm
2014-04-29 11:47 ` Felipe Contreras
2014-04-29 12:25 ` James Denholm
2014-04-29 13:31 ` Felipe Contreras
2014-04-29 21:04 ` James Denholm
2014-04-29 21:45 ` Felipe Contreras
2014-04-29 22:25 ` James Denholm
2014-04-29 23:05 ` Felipe Contreras
2014-04-30 0:22 ` James Denholm
2014-04-30 0:44 ` Felipe Contreras
2014-04-30 1:11 ` James Denholm
2014-04-29 21:48 ` Piotr Krukowiecki
2014-04-29 8:34 ` Robin Rosenberg
2014-04-28 2:30 ` Sitaram Chamarty
2014-04-28 8:52 ` Jeremy Morton
2014-04-28 10:03 ` Sitaram Chamarty
2014-04-28 6:07 ` David Kastrup
2014-04-28 10:03 ` Sitaram Chamarty
2014-04-28 16:38 ` Johan Herland
2014-04-28 8:57 ` Felipe Contreras
2014-04-28 8:50 ` Felipe Contreras
-- strict thread matches above, loose matches on Subject: below --
2014-04-28 6:36 Max Kirillov
2014-04-28 18:15 ` Junio C Hamano
2014-04-30 4:04 ` Max Kirillov
2014-04-28 6:42 Max Kirillov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bnvl6bdg.fsf@fencepost.gnu.org \
--to=dak@gnu$(echo .)org \
--cc=admin@game-point$(echo .)net \
--cc=felipe.contreras@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=johan@herland$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox