On Mon, 2008-06-30 at 15:15 -0700, Junio C Hamano wrote: > Kristian Høgsberg <krh@xxxxxxxxxx> 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? > (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 -- 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
