git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Clemens Buchacher <drizzd@aon.at>
To: git@vger.kernel.org
Cc: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
	Nanako Shiraishi <nanako3@lavabit.com>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Question about 'branch -d' safety
Date: Sat, 10 Jul 2010 08:55:49 +0200	[thread overview]
Message-ID: <20100710065549.GA24296@localhost> (raw)
In-Reply-To: <20091230121238.6117@nanako3.lavabit.com>

[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]

Hi,

I'm sorry to revive this old thread. But I recently hit this
behavior myself, using the workflow described below, and I ended up
deleting an unmerged branch with git branch -d.

This discussion is about v1.7.0-rc0~18^2 (branch -d: base the
"already-merged" safety on the branch it merges with, 2009-12-29),
which teaches 'git branch' to delete a branch with -d, if it is
merged into the branch it is tracking, even if it is not merged
into any local branch.

On Wed, Dec 30, 2009 at 12:12:38PM +0900, Nanako Shiraishi wrote:
> Quoting Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
> 
> > 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.
> 
> Here is what I think about your scenario.
> 
> Bob directly pushes to Alice and Alice does the same to Bob, both
> to their refs/remotes/<other person>/ tracking branches, and
> their own local branches fork from the remote tracking branches
> that keep track of other person's work. You would still want the
> check based on that tracking branch, not based on 'master' that
> has no relationship with the branches they are exchanging.

So I had a branch 'topic' in two repositories, neither of which was
in any way authoritative. They were both upstreams to each other.
And the 'topic' branch in each tracked the 'topic' branch in the
other.

At some point, I used branch -d to delete branch 'topic' in one
repo. Later, I did the same in the other. I then realized that
after I do git remote prune origin, the branch will be gone,
without ever having being merged into another branch.

I often use branch -d simply to check if I still forgot something
about this branch, or if it has become redundant. With the above
scenario, I can not rely on branch -d safety any more.

On the other hand, I do think the new behavior is quite useful in
general. Maybe the real solution is a reflog for deleted branch
heads, rather than being too careful about whether or not a branch
can be deleted.

Clemens

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  parent reply	other threads:[~2010-07-10  6:57 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
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 [this message]
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=20100710065549.GA24296@localhost \
    --to=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=nanako3@lavabit.com \
    --cc=nicolas.s.dev@gmx.fr \
    /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).