what is the function of .git/branches/?

what is the function of .git/branches/?

[Robert P. J. Day]

  currently proofing "pro git" book, and an example of a new repo
doesn't show a .git/branches/ directory, but initializing a new repo
with current version of 2.13.6 *does* show an initially empty
directory by that name. however, AFAICT, branches are still tracked
under .git/refs/heads/, so what's with that branches/ directory?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: what is the function of .git/branches/?

[Jeff King]

On Sun, Nov 05, 2017 at 11:24:00AM +0200, Robert P. J. Day wrote:

>   currently proofing "pro git" book, and an example of a new repo
> doesn't show a .git/branches/ directory, but initializing a new repo
> with current version of 2.13.6 *does* show an initially empty
> directory by that name. however, AFAICT, branches are still tracked
> under .git/refs/heads/, so what's with that branches/ directory?

It's a historical way of storing what's now in the "[remote]" section of
config files. It's covered briefly in "git help repository-layout"
(which is a good starting point for similar questions), and in more
detail in the REMOTES section of fetch/pull/push.

-Peff

Re: what is the function of .git/branches/?

[Junio C Hamano]

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

>   currently proofing "pro git" book, and an example of a new repo
> doesn't show a .git/branches/ directory, but initializing a new repo
> with current version of 2.13.6 *does* show an initially empty
> directory by that name. however, AFAICT, branches are still tracked
> under .git/refs/heads/, so what's with that branches/ directory?

There are three ways to specify what branches of which remote
repository your fetch and/or push interacts with, and having
.git/branches/foo file is one of these three ways (the other two are
to have .git/remotes/foo file, and to have [remote "foo"] section in
the .git/config).

If your workflow involves having to interact with tons of remotes
(imagine being a maintainer who regularly pulls from dozens of
sub-maintainer's repositories, each of which places the material to
be upstreamed on a single branch) and that set changes from time to
time, using .git/branches/* is a lot more efficient than having to
keep track of the same information in other two formats, so even
though it was the invented the earliest and is the least flexible
format among the three, it still has its uses.

Re: what is the function of .git/branches/?

[Robert P. J. Day]

On Mon, 6 Nov 2017, Junio C Hamano wrote:

> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>
> >   currently proofing "pro git" book, and an example of a new repo
> > doesn't show a .git/branches/ directory, but initializing a new
> > repo with current version of 2.13.6 *does* show an initially empty
> > directory by that name. however, AFAICT, branches are still
> > tracked under .git/refs/heads/, so what's with that branches/
> > directory?

> There are three ways to specify what branches of which remote
> repository your fetch and/or push interacts with, and having
> .git/branches/foo file is one of these three ways (the other two are
> to have .git/remotes/foo file, and to have [remote "foo"] section in
> the .git/config).

> If your workflow involves having to interact with tons of remotes
> (imagine being a maintainer who regularly pulls from dozens of
> sub-maintainer's repositories, each of which places the material to
> be upstreamed on a single branch) and that set changes from time to
> time, using .git/branches/* is a lot more efficient than having to
> keep track of the same information in other two formats, so even
> though it was the invented the earliest and is the least flexible
> format among the three, it still has its uses.

  ah, useful to know, thanks. as i mentioned, i'm clawing my way
through the current version of the "pro git" book and submitting all
sorts of updates, and this is the sort of thing i'm keeping track of
to see if i can sneak it in somewhere.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================