From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
To: Nanako Shiraishi <nanako3@lavabit.com>
Cc: git@vger.kernel.org, Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
Subject: Re: Question about 'branch -d' safety
Date: Tue, 29 Dec 2009 23:31:23 +0100 [thread overview]
Message-ID: <20091229223123.GA12965@vidovic> (raw)
In-Reply-To: <20091230065442.6117@nanako3.lavabit.com>
The 30/12/09, Nanako Shiraishi wrote:
> I think the safety feature should check if the branch to be deleted is merged to the remote tracking branch it was forked from, instead of checking the current branch.
>
> What do you think?
I think we shouldn't. At first, every repository don't have a remote.
This may easily be passed by a "double check" with a logical OR between
the two statements.
But even with it, we would hit some foreign workflow. Think: Bob
directly push to Alice and Alice does the same to Bob. I don't use this
kind of workflow myself but I consider them to be sensible enough to
have our attention.
Now, I'm talking about what users may expect from the default behaviour.
I'm not against a new configuration variable. It would certainly give
more granularity to the expectation of "what is safe for me".
--
Nicolas Sebrecht
next prev parent reply other threads:[~2009-12-29 22:31 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-29 21:54 Question about 'branch -d' safety Nanako Shiraishi
2009-12-29 22:31 ` Nicolas Sebrecht [this message]
2009-12-30 3:12 ` Nanako Shiraishi
2009-12-30 6:43 ` Junio C Hamano
2009-12-30 21:08 ` Nicolas Sebrecht
2010-07-10 6:55 ` Clemens Buchacher
2010-07-10 21:40 ` Jonathan Nieder
2010-07-10 21:57 ` Jakub Narebski
2010-07-10 22:17 ` Jonathan Nieder
2010-07-11 6:55 ` Clemens Buchacher
2010-07-11 7:16 ` Jakub Narebski
2010-07-11 8:48 ` Julian Phillips
2010-07-11 13:37 ` Clemens Buchacher
2010-07-11 18:41 ` Junio C Hamano
2010-07-11 19:05 ` Jakub Narebski
2010-07-11 22:02 ` Will Palmer
2010-07-12 18:47 ` Clemens Buchacher
2010-07-12 23:50 ` Junio C Hamano
2010-07-13 7:13 ` Clemens Buchacher
2010-07-13 8:00 ` Will Palmer
2010-07-13 8:30 ` Johannes Sixt
2010-07-13 9:00 ` Will Palmer
2010-07-13 22:21 ` Clemens Buchacher
2010-07-17 9:30 ` Clemens Buchacher
2010-07-18 0:43 ` Jonathan Nieder
2010-07-18 11:55 ` Jakub Narebski
2010-07-18 20:27 ` Will Palmer
2010-07-18 23:19 ` Jakub Narebski
2010-07-19 7:12 ` Will Palmer
2010-07-19 11:01 ` Jakub Narebski
2010-07-19 17:16 ` Joshua Jensen
2010-07-19 19:34 ` Clemens Buchacher
2010-07-19 19:45 ` Will Palmer
2010-07-19 20:40 ` Jakub Narebski
2010-07-20 3:05 ` Joshua Jensen
2010-07-20 6:31 ` Will Palmer
2010-07-19 20:36 ` Jakub Narebski
2010-07-19 18:06 ` Junio C Hamano
2010-07-19 19:22 ` Clemens Buchacher
2010-07-19 20:49 ` Jakub Narebski
2010-07-20 13:19 ` Ævar Arnfjörð Bjarmason
2010-07-20 13:34 ` Matthieu Moy
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=20091229223123.GA12965@vidovic \
--to=nicolas.s.dev@gmx.fr \
--cc=git@vger.kernel.org \
--cc=nanako3@lavabit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.