[PATCH] Don't create the $GIT_DIR/branches directory on init

[PATCH] Don't create the $GIT_DIR/branches directory on init

[Robin Rosenberg]

Git itself does not even look at this directory. Any tools that
actually needs it should create it itself.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
 templates/branches-- |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)
 delete mode 100644 templates/branches--

Shawn and other wants to stop JGit from creating this directory on
init with the motivation that newer Git version doesn't create it
anymore. This patch would make that assertion true.

-- robin

diff --git a/templates/branches-- b/templates/branches--
deleted file mode 100644
index fae8870..0000000
--- a/templates/branches--
+++ /dev/null
@@ -1 +0,0 @@
-: this is just to ensure the directory exists.
-- 
1.6.5.2.102.g1f8896

Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

[Junio C Hamano]

Robin Rosenberg <robin.rosenberg@dewire.com> writes:

> Git itself does not even look at this directory. Any tools that
> actually needs it should create it itself.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
>  templates/branches-- |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
>  delete mode 100644 templates/branches--
>
> Shawn and other wants to stop JGit from creating this directory on
> init with the motivation that newer Git version doesn't create it
> anymore. This patch would make that assertion true.

Cogito now seems really dead ;-).

Unless somebody complains I am Ok to queue this for 1.6.6.

>
> -- robin
>
> diff --git a/templates/branches-- b/templates/branches--
> deleted file mode 100644
> index fae8870..0000000
> --- a/templates/branches--
> +++ /dev/null
> @@ -1 +0,0 @@
> -: this is just to ensure the directory exists.
> -- 
> 1.6.5.2.102.g1f8896

Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

[Thomas Rast]

Robin Rosenberg wrote:
> Git itself does not even look at this directory.

This contradicts the git-fetch manpage though: from urls-remotes.txt,
it includes

  The name of one of the following can be used instead
  of a URL as `<repository>` argument:

  * a remote in the git configuration file: `$GIT_DIR/config`,
  * a file in the `$GIT_DIR/remotes` directory, or
  * a file in the `$GIT_DIR/branches` directory.

(and a longer explanation of what they need to look like).

So which one is wrong?

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

[Robin Rosenberg]

lördag 31 oktober 2009 10:11:29 skrev  Thomas Rast:
> Robin Rosenberg wrote:
> > Git itself does not even look at this directory.
>
> This contradicts the git-fetch manpage though: from urls-remotes.txt,
> it includes
>
>   The name of one of the following can be used instead
>   of a URL as `<repository>` argument:
>
>   * a remote in the git configuration file: `$GIT_DIR/config`,
>   * a file in the `$GIT_DIR/remotes` directory, or
>   * a file in the `$GIT_DIR/branches` directory.
>
> (and a longer explanation of what they need to look like).
>
> So which one is wrong?

I, and a few other people, it seems. Seems the purpose of these
files is a bit different. Git does look in these directories (both)
when fetch is run. Seems remotes is not created by init though.

-- robin

Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

[Shawn O. Pearce]

Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> >   * a remote in the git configuration file: `$GIT_DIR/config`,
> >   * a file in the `$GIT_DIR/remotes` directory, or
> >   * a file in the `$GIT_DIR/branches` directory.
> 
> I, and a few other people, it seems. Seems the purpose of these
> files is a bit different. Git does look in these directories (both)
> when fetch is run. Seems remotes is not created by init though.

Since remotes isn't created by init, branches shouldn't be either.
Cogito is dead, and that was the main customer who wanted branches
to be present in a repository.

I think its safe to remove branches from the template repository
and stop creating it, but continue to read from branches and
remotes if they exist.

We might want to consider dropping support for them in 1.7.0
or 1.8.0, because any new tools largely focus on config.
E.g. git-remote probably can't edit branches or remotes, git-gui
probably doesn't use them, JGit doesn't use them.

-- 
Shawn.

Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Robin Rosenberg wrote:
>> Git itself does not even look at this directory.

Modern git Porcelains write remote definitions solely to .git/config, but
still reads from .git/{branches,remotes}.  What we do not do is to update
these locations, and we do not need to have these locations to operate.

So "not even look at" is too strong; it just "not touch".

I do not think there is reason to change that part of the equation.  For
people who need to fetch and merge hundreds of random places, it is a lot
handier to be able to do

	echo "$url#$branch" >.git/branch/$nickname
        rm .git/branch/$nickname

to manage the set of locations added to and deleted from the daily
compose.  Andrew Morton explicitly asked for this to be kept a few years
ago and I do not see a reason to deprecate this.

Now, not installing an empty .git/branch directory does break the above
workflow.  You would need to mkdir _once_ yourself, but I do not think
that is such a big deal.

On the other hand, I do not think it is such a big deal to have otherwise
unused .git/branches/ directory, either.  Robin wrote:

    Shawn and other wants to stop JGit from creating this directory on
    init with the motivation that newer Git version doesn't create it
    anymore. This patch would make that assertion true.

and after re-reading it, I realize "the motivation" is not a motivation at
all---it is merely an excuse ("after this patch is applied, git wouldn't
create it anymore"---so JGit will have an excuse not to do so).  It does
not say _why_ it shouldn't be there in the first place.  IOW, we need to
fill in the blank in: "JGit is merely following suit; the reason git
stopped creating the directory is ________").

This patch alone breaks tests in the t55?? series quite a lot, and I am
tempted to revert it.  My time is more valuable than fixing the fallouts
from this change, when the real purpose of the change is not yet stated.

Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> Modern git Porcelains write remote definitions solely to .git/config, but
> still reads from .git/{branches,remotes}.
...
> Andrew Morton explicitly asked for this to be kept a few years
> ago and I do not see a reason to deprecate this.
...
>     Shawn and other wants to stop JGit from creating this directory on

I probably said something like this.  I won't bother denying it,
because list archives are more accurate than my own fallible memory.

But I didn't know the Andrew Morton part above.  After hearing it
from you, I'm reversing my (apparent) direction here.  We should
continue to create the branches directory within a new repository.

Sorry Robin, but Andrew Morton matters.  Its one stupid unused
directory in a repository that will chew through thousands of inodes
as loose objects.  Its a drop in the bucket in terms of resource
cost used by Git.  And Andrew is someone whose workflow we don't
want to break if we can avoid it.  He's a long time Git user who is
also high up in the kernel food chain.  Interrupting him disrupts
a fair chunk of kernel work while he grumbles about the Goddamn
Idiotic Truckload of s**t that Linus begat.

> This patch alone breaks tests in the t55?? series quite a lot,

Drop the patch.

-- 
Shawn.

Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

>> This patch alone breaks tests in the t55?? series quite a lot,
>
> Drop the patch.

Ok, I missed that the unstated goal was "we will eventually drop support
for reading from branches and remotes".  I think it is a worthy goal, but
also agree that should be done at 1.7.0 or 1.8.0 boundary.

If this were Andrew alone, I personally do not think it is such a big
deal.  My understanding is that an eventual goal over there in the kernel
land is to grow 'linux-next' tree even more so that akpm tree will shrink
in the longer term, anyway.  I consulted Andrew in early days while he was
fighting with git to get his scripts to do what he needs them to do, and I
can do that again to bring them up-to-date if necessary.

In order to better support "massive integrator" workflow
that involves interacting with dozens of remote branches, we need to admit
that some of the things you can do if you are set up like Andrew are less
convenient to do via "git remotes" managing .git/config file.  E.g.

    : add new
    $ echo "$korg:/home/rmk/linux-2.6-arm.git#master" >.git/branches/arm-current
    : remove stale
    $ rm -f .git/branches/powerpc
    : find source
    $ grep -r $something .git/branches
    : make random small changes, e.g. change branch name only
    $ vi .git/branches/sparc

and we _might_ need to improve "git remote" interface before dropping
support for reading branches and remotes files.

Admittedly, managing integration trees like -mm and linux-next needs not
just nickname-to-repo-branch mapping but also involves the correct merge
order anyway, and people like Andrew and Stephan Rothwell (linux-next)
maintain a text file to describe them that git does not know about.

E.g. http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.IncludedTrees

We do not have any infrastructure support for that kind of thing.

To manage 'pu' and 'next', I use specialized scripts (in my 'todo' branch,
look for Reintegrate script) myself, even though the number of topics I
manage is far smaller than what we are discussing here[*1*].  In that
sense, the difference between the remotes sections in .git/config file and
.git/branches/* files is not such a big issue in the larger picture.

As long as we keep the UI to deal with bare URL and branch names from the
command line properly working, the "massive intergrator" workflow might be
better done without _any_ remote definition, either in the config nor
branches/remotes files.  Two integrator scripts might read like these:

	#!/bin/sh
	# fetch-all script
        # fetch from repositories
        failed=
	while read nickname url branch
        do
        	git fetch -q "$url" "+$branch:refs/remotes/$nickname" ||
		failed="$failed$nickname "
	done <merge-order
        test -z "$failed" ||
        echo "Failed to fetch from $failed"

        #!/bin/sh
	# merge-all script
	# git reset --hard remotes/linus-tip
        while read nickname url branch
        do
        	git merge -m "Merge from $url#$branch" "remotes/$nickname" ||
		accept_rerere ||
                break
	done <merge-order

where accept_rerere is something like what my Reintegrate script (in
'todo' branch) has in it.  Then the workflow for the integrator would
become:

  1. to run "fetch-all" once;
  2. reset to Linus's tip of the day;
  3. run "merge-all";
     3.a fix up conflicts;
	 edit && git commit
     3.b decide to drop the day's tree and use previous day's:
	 git reset --hard &&
         git update-ref refs/remotes/$nick refs/remotes/$nick@{1.day}
     3.c decide to drop the tree:
	 git reset --hard &&
         edit merge-order
     and go back to step 3.


[Footnote]

*1* I do not keep a "merge order" file, but existing merges on 'pu' for
that purpose.  The Reintegrate script figures it out by looking at what
was in 'pu'.  One cycle of my git day looks like this, in this order:

    : record what topics are in 'next' and 'pu'
    : 'jch' is a shadow of 'next' that merges all the topics in 'next'
    : on top of 'master'.
    $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh
    $ Meta/Reintegrate jch..pu >/var/tmp/redo-pu.sh

    : queue a new topic
    $ git checkout -b xx/topic master
    $ git am -s $patch

    : update a topic
    $ git checkout xx/topic
    $ git am -s $patch

    : fix a topic (that is not in 'next' yet)
    $ git checkout xx/topic
    $ git rebase -i $(git merge-base master HEAD)

    : decide to graduate a topic to 'master'
    $ git checkout master
    $ git merge xx/topic

    : apply directly to master
    $ git checkout master
    $ git am -s $patch

    : update 'next' with what's new in 'master'
    $ git checkout next && git merge master
    : rebuild 'jch' (shadow of 'next')
    $ git branch -f jch master && git checkout jch
    $ sh /var/tmp/redo-jch.sh
    : at this point, 'jch' and 'next' must exactly match

    : add topics that are next-ready to 'jch' and test
    $ git merge xx/topic

    : merge them to 'next' as well
    $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh
    $ git checkout next && sh /var/tmp/redo-jch.sh
    : at this point, 'jch' and 'next' must exactly match

    : rebuild 'pu'
    $ git branch -f pu jch && git checkout pu
    $ sh /var/tmp/redo-pu.sh
    : merge new topics
    $ git merge xx/topic