reflog support, which allows you to determine what the state of a branch
was at a particular date/time, is often cited as something that would be
useful to have on by default. Modify git init-db, so that newly created
repositories have this on.
Signed-off-by: Anand Kumria <redacted>
---
Documentation/config.txt | 2 +-
builtin-init-db.c | 3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9d3c71c..e8d0bc1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -80,7 +80,7 @@ core.logAllRefUpdates::
This information can be used to determine what commit
was the tip of a branch "2 days ago". This value is
- false by default (no automated creation of log files).
+ true by default.
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..4ea865d 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -239,6 +239,9 @@ static void create_default_files(const c
git_config_set("core.filemode",
filemode ? "true" : "false");
}
+
+ git_config_set("core.logAllRefUpdates", "true");
+
}
static const char init_db_usage[] =--
1.4.3.3
I do not think I can take this patch in its current form.
Although I think majority of users would find it convenient to
have ref-log enabled by default on repositories to be developed
in, it does not make sense to enable ref-log by default for bare
repositories that is used as a distribution point. So at least
this needs an option to disable it (if you make it the default),
or enable it.
Side note. A ref-log at a distribution point _could_ be
used for somebody to say "Hey, I pushed that fix three
days ago -- why are you complaining about the breakage
I've already fixed before checking the public tip?", but
that is a manifestation of lack of communication among
people and a SCM is not about solving that problem.
But having to add an option tends to drive people nuts. We
already have --shared and --template, so adding --with-reflog
would be "just one more option" that we may not have to worry
too much about, but we would have to revisit this as we gain
more experience using git and more best-current-practices are
learned. I wonder if we can infer if a particular invocation of
init-db is to prepare a repository to be developed in without
being told with a command line option. If we can do so, then we
can do the configuratio setting with --with-reflog=[yes|no|guess]
option (and lack of --with-reflog means "guess").
There are three use cases that init-db is run directly from the
command line, and I think you want different behaviours.
(1) you have a directory, perhaps already with many files
there, because you are doing an initial import to prepare a
repository to work in. You obviously want a ref-log there,
and you want --shared=no. You do not care about
denyNonFastForwards because you are not likely to be
pushing into it.
(2) you are preparing a public distribution point for _your_
own tree. You do not want a ref-log, you want --shared=no,
and you _might_ want denyNonFastForwards.
(3) you are preparing a public shared repository for project
members to use to synchronize, CVS-style. You do not want
a ref-log, you do want --shared=group, and and you want
denyNonFastForwards.
Another case that init-db is run indirectly is via git-clone and
via foreign SCM importers. I think enabling ref-log during
non-bare clone, for example, should behave similarly to (1)
because the resulting repository is clearly meant to be used
with a working tree in which to develop. A bare clone is either
(2) or (3) but you do not have to decide what to do with ref-log
(i.e. "don't"). But in these "indirect" cases, the command that
drives init-db can explicitly tell init-db what it is doing, and
we would need to have both --with-reflog and --without-reflog
options so that the command can tell what it wants from init-db
explicitly without having init-db guess.
If you can come up with a reliable way to tell (1)..(3) then we
can make init-db to do the right thing without an end user to
tell what should happen --with-reflog or --without-reflog; and
they do not even have to say --shared anymore as an added bonus.
Having thought about all the above, I think the event to create
distribution/synchronization point repositories are rare enough
and the simplest and cleanest way might be to make it default
and add a --without-reflog option to the command, and forget
about the guessing.
Junio C Hamano [off-list ref] wrote:
I do not think I can take this patch in its current form.
Although I think majority of users would find it convenient to
have ref-log enabled by default on repositories to be developed
in, it does not make sense to enable ref-log by default for bare
repositories that is used as a distribution point. So at least
this needs an option to disable it (if you make it the default),
or enable it.
What about just suggesting that the individual user run:
git repo-config --global core.logAllRefUpdates true
?
This has the effect of enabling reflog by default for any repository
that the user creates or clones, unless its explicitly disabled in
that repository.
I've done this in any account that I use to access working directory
repositories and it works well. But I also just realized that I have
it enabled in one account which also pushes to some bare repositories
through local filesystem URLs and thus those bare repositories are
also getting reflogged. But given that they are used as backups of
my working directory repositories (different drive) and are never
pruned, I actually consider that to be a feature. :-)
Your idea of guessing the intent of the repository and setting up the
configuration based on that intent is a good one, but unfortunately I
have no suggestions for how to solve the (1)..(3) cases you raised.
But setting core.logAllRefUpdates in the global configuration of
an interactive account appears to be a reasonable workaround.
--