Re: What's cooking in git.git (topics)

On Mon, 2008-06-30 at 15:15 -0700, Junio C Hamano wrote:

Kristian Høgsberg [off-list ref] writes:

quoted

On Mon, 2008-06-30 at 02:08 -0700, Junio C Hamano wrote:
...

quoted

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?

 (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.

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