From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
Date: Thu, 01 Sep 2011 21:20:30 +0200 [thread overview]
Message-ID: <4E5FDAFE.6050004@drmicha.warpmail.net> (raw)
In-Reply-To: <7vliu8w25g.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 01.09.2011 20:25:
> Suggested reading:
>
> http://git-blame.blogspot.com/2011/08/how-to-inject-malicious-commit-to-git.html
>
> I am wondering if we are better off applying something along the lines of
> this patch, so that with the default configuration, users can notice if
> their upstream unexpectedly rewound their branches.
>
> It would produce
>
> [remote]
> url = git://.../git.git/
> fetch = refs/heads/*:refs/remotes/origin/*
>
> upon cloning from my repository, and your "git fetch" will fail because
> the pu (proposed updates) branch is constantly unwinding, but that can be
> easily fixed with
>
>
> [remote]
> url = git://.../git.git/
> fetch = refs/heads/*:refs/remotes/origin/*
> fetch = +refs/heads/pu:refs/remotes/origin/pu
>
> as the explicit refspec trumps the wildcard one.
>
> builtin/remote.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
My first thought was "Oh no", even though I saw it coming since I read
your blog entry. But I realized that it was probably due to the usual
inertia when habits have to change.
Thinking more about it, we try to encourage a workflow where locally
history may be rewritten a lot, and distribution points fast-forward
only. We have defaults and settings to discourage (pushes to checked out
branches and) non-ff pushes, for example. So I think the above change is
pretty much in line with that reasoning.
The kernel.org problems gave git some pretty good PR even without that
change, but with it we have an even stronger stop put in. On the other
hand, adding "+" to the config for "pu" (and peff...) isn't that much of
an issue, though we might also want "fetch -f" as an override - I guess
we have that already.
Plus fetch with fsck, yes.
To
"I don't need backups, I let others clone."
add
"I don't need intrusion detection, I let others fetch."
;)
Michael
next prev parent reply other threads:[~2011-09-01 19:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 18:25 Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*? Junio C Hamano
2011-09-01 18:39 ` Junio C Hamano
2011-09-01 19:14 ` Shawn Pearce
2011-09-01 19:20 ` Michael J Gruber [this message]
2011-09-01 19:35 ` Matthieu Moy
2011-09-01 19:50 ` Shawn Pearce
2011-09-02 5:55 ` Matthieu Moy
2011-09-02 0:00 ` Jeff King
2011-09-02 7:00 ` Johannes Sixt
2011-09-02 15:26 ` Jeff King
2011-09-02 7:42 ` Michael J Gruber
2011-09-02 15:29 ` Jeff King
2011-09-02 16:14 ` Junio C Hamano
2011-09-02 16:25 ` Jeff King
2011-09-02 16:47 ` Junio C Hamano
2011-09-05 18:15 ` Shawn Pearce
2011-09-05 20:47 ` Jeff King
2011-09-05 20:53 ` Shawn Pearce
2011-09-05 20:57 ` Jeff King
2011-09-05 21:14 ` Shawn Pearce
2011-09-07 21:20 ` [RFC/PATCH] fetch: bigger forced-update warnings Jeff King
2011-09-07 21:39 ` Shawn Pearce
2011-09-07 21:53 ` Junio C Hamano
2011-09-07 21:57 ` Jeff King
2011-09-07 22:42 ` Thomas Rast
2011-09-06 7:39 ` Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*? Matthieu Moy
2011-09-06 7:51 ` Michael J Gruber
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=4E5FDAFE.6050004@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).