git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Sitaram Chamarty <sitaramc@gmail.com>
Cc: Jeff King <peff@peff.net>,
	Michael Haggerty <mhagger@alum.mit.edu>,
	Git Mailing List <git@vger.kernel.org>,
	Elijah Newren <newren@gmail.com>
Subject: Re: can we prevent reflog deletion when branch is deleted?
Date: Sat, 1 Jun 2013 23:26:11 +0530	[thread overview]
Message-ID: <CALkWK0=SqCh-82F4ud+AxuzzEezyMWqMvc6HAPoxOk32vUND7A@mail.gmail.com> (raw)
In-Reply-To: <CAMK1S_hPups3SCwxhHRYWBJzpPreNVUfNdx1+_Hjy2_d0MMpaA@mail.gmail.com>

Sitaram Chamarty wrote:
> I think I'd have to be playing with *several* branches simultaneously
> before I got to the point of forgetting the branch name!

Yeah, I work on lots of small unrelated things: the patch-series I
send in are usually the result of few hours of work (upto a few days).
 I keep the branch around until I've rewritten it for enough re-rolls
and am sufficiently sure that it'll hit master.

> More to the point, your use case may be relevant for a non-bare repo
> where "work" is being done, but for a bare repo on a server, I think
> the branch name *does* have significance, because it's what people are
> collaborating on.
>
> (Imagine someone accidentally nukes a branch, and then someone else
> tries to "git pull" and finds it gone.  Any recovery at that point
> must necessarily use the branch name).

Ah, you're mostly talking about central workflows.  I'm on the other
end of the spectrum: I want triangular workflows (and git.git is
slowly getting there).  However, I might have a (vague) thought on
server-side safety in general: I think the harsh dichotomy in ff-only
versus non-ff branches is very inelegant.  Imposing ff-only feels like
a hammer solution, because what happens in practice is different: the
`master` does not need to be rewritten most of the time, but I think
it's useful to allow some "safe" rewrites to undo the mistake of
checking in an private key or something [*1*].  By safety, I mean that
git should give the user easy access to recent dangling objects by
annotating it with enough information: sort of like a general-purpose
"pretty" reflog that is gc-safe (configurable trunc_length?).  It's a
serves more usecases than just the branch-removal problem.

Ofcourse, the standard disclaimer applies: there's a high likelihood
that I'm saying nonsense, because I've never worked in a central
environment.

[Footnotes]

*1* It turns out that this is not uncommon:
https://github.com/search?q=path%3A.ssh%2Fid_rsa&type=Code&ref=searchresults

  reply	other threads:[~2013-06-01 17:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-01  1:31 can we prevent reflog deletion when branch is deleted? Sitaram Chamarty
2013-06-01  3:00 ` Michael Haggerty
2013-06-01  5:03   ` Jeff King
2013-06-01  7:59     ` Ramkumar Ramachandra
2013-06-01  9:09       ` Jeff King
2013-06-01  9:47         ` Ramkumar Ramachandra
2013-06-01 17:25           ` Sitaram Chamarty
2013-06-01 17:56             ` Ramkumar Ramachandra [this message]
2013-06-02 10:20               ` Sitaram Chamarty
2013-11-14  0:18               ` Sitaram Chamarty
2013-11-14  7:56                 ` Thomas Rast
2013-11-14  8:07                   ` Jeff King
2013-11-14 10:56                     ` Sitaram Chamarty
2013-11-14 11:09                       ` Jeff King
2013-11-14 11:17                         ` Luca Milanesio
2013-11-14 13:48                           ` Sitaram Chamarty
2013-11-14 13:47                         ` Sitaram Chamarty
2013-11-14  8:14                 ` Jeff King
2013-11-14 14:42                   ` Stephen Bash
2013-11-14 16:20                     ` Sitaram Chamarty
2013-11-14 16:06                   ` Sitaram Chamarty

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='CALkWK0=SqCh-82F4ud+AxuzzEezyMWqMvc6HAPoxOk32vUND7A@mail.gmail.com' \
    --to=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=sitaramc@gmail.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).