On Mon, 2008-06-30 at 15:15 -0700, Junio C Hamano wrote:
quoted text
> Kristian Høgsberg <krh@redhat.com> writes:
> 
> > On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
> > ...
> >> It already is beginning to become clear what 1.6.0 will look like.  What's
> >> already in 'next' all are well intentioned (I do not guarantee they are
> >> already bug-free --- that is what cooking them in 'next' is for) and are
> >> good set of feature enhancements.  Bigger changes will be:
> > ...
> > A small detail I've suggested scheduling for 1.6 before is removing (or
> > rather, stop creating) the empty .git/branches directory.  How does that
> > sound?
> 
> What's the benefit of the removal that outweighs the downside?  I can
> imagine two contradicting voices from new end users.
> 
>  (1) With current git, I ran "git init" and I have an empty
>      .git/branches/, but my remote information created with "git clone"
>      and "git remote add" all go to .git/config these days.  Why do I have
>      to have this empty directory that I do not use?

Yeah, that's one reason, my main problem with .git/branches is that for
a user that wants to learn about git and peeks into .git it's pretty
confusing.  "I wonder where and how git stores the information about
branches... oh look, .git/branches, that must it... hmm, wait no..."
Git is still getting a lot of bad-mouthing for being hard to learn and
inconsitent.  I think it makes sense to push git towards consistency and
simplicity (where is doesn't affect the flexibility) and this seemed
like a tiny step towards that.  As Dscho mentioned we have two other
ways of accomplishing what .git/branches did, so maybe it makes sense to
retire this one?

quoted text
>  (2) It is documented that "git fetch" can use files in .git/branches/ as
>      the source specification, but when I ran "git init", it does not
>      create the directory with Kristian's git. I need to do an extra
>      "mkdir .git/branches/" myself.  Why?

We could just change the documentation to ask the user to create
the .git/branches directory if they want to use that feature.

quoted text
> You are obviously coming from the former camp, but do you have a good
> answer to people from the other camp?
> 
> I do not recall if Cogito required to have .git/branches created by us or
> it can create it on demand if we don't.  If the latter, that would be
> great, otherwise remaining users would be in the latter camp as well, and
> we may have to make sure Cogito is really dead already (or wait for it to
> die), or Cogito gets updated for its remaining users to tolerate the
> initial lack of the directory (and wait for that version percolates down
> to the users).
> 
> Some people rely on (or at least "like") the convenience of being able to
> create a single-liner file in .git/branches/ to easily add, and remove
> such a file to easily remove where they integrate from.  This is
> especially so when they have dozens of source repositories to fetch from.
> I do not think we want to remove support for .git/branches as a way to
> specify fetch sources (this is why I am CC'ing Andrew who I know uses
> branches, and Stephen who is also a heavy integrator even though I do not
> know if he is in branches camp or uses more modern style), but they now
> have to do an extra "mkdir .git/branches" after "git init" to continue
> their workflow if we adopt the change you are proposing here.  It is not a
> big deal, but it still is a backward incompatible change.

Yeah... I have to confess, that when I suggested removing it, I was
under the impression that git didn't use .git/branches, but only created
it to be nice to cogito.  I just read the code in remote.c that deals
with .git/branches and understand that it's still used by git.  From the
feedback from Stephen, Andrew and Pasky, it looks like we can drop
the .git/branches from the template for 1.6 and maybe in the future, we
could drop the .git/branches support entirely.  Dunno.

cheers,
Kristian


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