Re: [RFC/PATCH 4/4] Disallow working directory commands in a bare repository.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sun, 31 Dec 2006, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> >> While we're talking about potentially deprecating GIT_DIR for users,
> >> out of curiosity, what valid workflows would cause users to want to
> >> use GIT_INDEX_FILE and GIT_OBJECT_DIRECTORY?  Seems like they would
> >> cause more confusion and support problems than anything else.  
> >
> > Easy, guys.
> >
> > It is a valid -- indeed, useful -- thing to be able to script nice 
> > helpers. For example, in one project I track tar balls. So, I wrote a 
> > script which will unpack the tar ball in a directory, build a new index 
> > from it, and commit the corresponding tree on top of the tracking branch. 
> > This setup relies _heavily_ on being able to redirect GIT_INDEX_FILE and 
> > GIT_DIR.
> 
> I do agree INDEX_FILE and OBJECT_DIRECTORY are handy things for
> the user to muck around.  What I am not sure about is GIT_DIR,
> in the sense that I suspect it is not such a pain to do without
> for such a script.

Uhm. In the example I illustrated, I need to set GIT_DIR, because I want 
to commit a new version into a branch of my current repository, but 
without touching the working tree and the index.

Thus, I have to create a temporary directory, unpack the new 
(upstream) version, set GIT_DIR _and_ GIT_INDEX_FILE, do a write-tree and 
a commit-tree with some automatic message, and then update the ref. Yes, I 
could separate the steps, but why make it harder than it needs be?

> > ...  Now, if somebody starts git in a 
> > bare repo, where "index" is present, it could die with a helpful message 
> > like
> >
> > 	It seems that this is a bare git repository, but there is an index 
> > 	file present, which contradicts that assumption. If the repository
> > 	is indeed bare, please remove the index file.
> 
> That is probably worse.  
> 
>  * there is no reason for non working-tree operations such as
>    git-log to fail when you go to a bare repository (or for that
>    matter .git in a repository with a working-tree).  we should
>    not have to error out nor remove the index we will not use.
> 
>  * if you did the above in response to a misguided 'git
>    checkout' in a bare repository, the next error message the
>    user will get will be 'huh?  you are in a bare repository,
>    bozo'.
> 
> So I do not think the helpful message should even be necessary.

Yeah, I meant this message only to appear when you call a program which 
needs a working directory. But I agree that this is probably stupid.

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]