All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Pearce <spearce@spearce.org>
To: Joel Dice <dicej@mailsnare.net>
Cc: Petr Baudis <pasky@suse.cz>, git@vger.kernel.org
Subject: Re: Subversion-style incrementing revision numbers
Date: Tue, 19 Sep 2006 18:39:05 -0400	[thread overview]
Message-ID: <20060919223905.GE11601@spearce.org> (raw)
In-Reply-To: <Pine.LNX.4.62.0609191525490.9752@joeldicepc.ecovate.com>

Joel Dice <dicej@mailsnare.net> wrote:
> I'm not too worried about cg-admin-uncommit or git-reset, since the IRN 
> feature is intended mainly for shared repositories.  I would suggest that 
> such commands simply be disallowed for such repositories.
> 
> The problem of temporary commits certainly needs to be addressed.  In this 
> case, may I assume nothing under $GIT_DIR/refs is ever modified?  If so, 
> perhaps I could somehow hook into the git-update-ref step.  Is that what 
> the revlog code does?

$GIT_DIR/refs is always modified.  Its probably the most heavily
modified part of a GIT_DIR, aside from the index.  Simply because
the ref files must be modified every time a commit, fetch or merge
completes.  Its also a directory you don't want to delete; I once
did an `rm -rf .git/refs` in a repository with a many branches.
That was no fun to recover.

git-update-ref is used by pretty much all non-C code to update a
ref file.  The APIs it calls invoke the reflog code to record the
update being made to the ref if the user has enabled logging on
that ref (not all users want all refs logged apparently).  I don't
think its a great idea to plug more complex logic into that part
of the system.  The reflog code already made it more complex then
it needed to be; Linus apparently just found out how heavily we
use static buffers down there...

-- 
Shawn.

  parent reply	other threads:[~2006-09-19 22:39 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-19 21:07 Subversion-style incrementing revision numbers Joel Dice
2006-09-19 21:18 ` Petr Baudis
2006-09-19 21:42   ` Joel Dice
2006-09-19 22:00     ` Petr Baudis
2006-09-19 22:24       ` Joel Dice
2006-09-19 22:33         ` Shawn Pearce
2006-09-19 22:40         ` Johannes Schindelin
2006-09-19 22:39     ` Shawn Pearce [this message]
2006-09-19 21:58   ` Jakub Narebski
2006-09-19 21:51 ` Linus Torvalds
2006-09-19 22:06   ` Petr Baudis
2006-09-19 22:20     ` Linus Torvalds
2006-09-19 23:35       ` Joel Dice
2006-09-20  0:15         ` Jakub Narebski
2006-09-20 16:13           ` Joel Dice
2006-09-20  7:46     ` Junio C Hamano
2006-09-20 17:28     ` Robin Rosenberg
2006-09-20 18:22       ` Petr Baudis
2006-09-20 19:07         ` Junio C Hamano
2006-09-19 22:07 ` Jakub Narebski
2006-09-19 22:11   ` Petr Baudis
2006-09-19 22:17   ` Jakub Narebski
2006-09-19 23:07     ` Joel Dice
2006-09-19 22:18   ` Shawn Pearce
2006-09-19 22:23   ` Shawn Pearce
2006-09-19 22:30   ` Joel Dice
2006-09-19 22:09 ` Shawn Pearce
2006-09-19 22:40   ` Joel Dice

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=20060919223905.GE11601@spearce.org \
    --to=spearce@spearce.org \
    --cc=dicej@mailsnare.net \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    /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.