* [RFC/PATCH] Documentation: be consistent about "git-" versus "git "
From: Jonathan Nieder @ 2008-06-30 7:30 UTC (permalink / raw)
To: git
I guess this patch is too long (168 KB). You can find it at
<http://home.uchicago.edu/~jrnieder/20080630-git-documentation-patch.txt>.
In a world where git-* are not in $(bindir), using "git-command
<parameters>" in examples in the documentation is not a good
idea. On the other hand, it is convenient for commands to be
named with one word, not two, the manpages are still called
"git-command (1)", and the user is not going to be able to escape
seeing "git-command" in the "wild" from time to time anyway. What
to do?
This patch keeps the dash when naming an operation, command,
program, process, or action but tries to be dashless in all
complete command lines ready to be entered at a shell (i.e.,
without options omitted).
The changes consist mostly of adding and removing dashes
accordingly. Other changes:
* "git clone" has been replaced with "git clone <repo>" (rather
than "git-clone") in the example at the beginning of
user-manual.txt in an attempt to make the switching between
dashed and dashless commands a little less confusing.
* git-merge-one-file has been replaced with $(git
--exec-path)/git-merge-one-file in two places
* /usr/bin/git has been replaced with /usr/bin/git-daemon in the
sample inetd.conf lines in git-daemon(1). The analogous
changes in git-cvsserver(1) have *not* been made.
* Some whitespace changes (spaces changing into dashes
disallowed some line breaks; some sequences of spaces have been
changed into tabs in the same line as other changes)
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
I just realized that most of the rest of the man pages
(aside from git-{sh-setup,parse-remote} (1)) are not ready
for the Git tools to move, either. Here's a start towards
less confusing documentation for that situation.
Sorry for the enormous patch. Hope it gives someone some
amusement. It is only an RFC because
1) I am not sure whether the criterion for dashworthiness
I used is the right one. I tried to follow the lead of
good existing documentation, but there is no one
convention used throughout.
2) I also want to make the formatting a bit more consistent
(always 'git-command' or always `git-command`) in
another patch if that is appropriate, while I am at it.
So I don't want this commited yet.
3) I would be much more comfortable if I could run some
commands to quickly check that this patch only does
what I have claimed it does.
Thoughts? Suggestions?
Documentation/git-add.txt | 2 +-
Documentation/git-am.txt | 4 +-
Documentation/git-annotate.txt | 2 +-
Documentation/git-apply.txt | 2 +-
Documentation/git-archimport.txt | 2 +-
Documentation/git-archive.txt | 2 +-
Documentation/git-blame.txt | 2 +-
Documentation/git-branch.txt | 8 +-
Documentation/git-bundle.txt | 14 ++--
Documentation/git-cat-file.txt | 4 +-
Documentation/git-check-attr.txt | 2 +-
Documentation/git-check-ref-format.txt | 4 +-
Documentation/git-checkout-index.txt | 20 +++---
Documentation/git-checkout.txt | 8 +-
Documentation/git-cherry-pick.txt | 2 +-
Documentation/git-clean.txt | 2 +-
Documentation/git-clone.txt | 2 +-
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-commit.txt | 4 +-
Documentation/git-config.txt | 26 ++++----
Documentation/git-count-objects.txt | 4 +-
Documentation/git-cvsexportcommit.txt | 9 ++-
Documentation/git-cvsimport.txt | 4 +-
Documentation/git-cvsserver.txt | 2 +-
Documentation/git-daemon.txt | 10 ++--
Documentation/git-describe.txt | 10 ++--
Documentation/git-diff-files.txt | 2 +-
Documentation/git-diff-index.txt | 12 ++--
Documentation/git-diff-tree.txt | 8 +-
Documentation/git-diff.txt | 18 +++---
Documentation/git-fast-import.txt | 8 +-
Documentation/git-fetch-pack.txt | 2 +-
Documentation/git-fetch.txt | 4 +-
Documentation/git-filter-branch.txt | 4 +-
Documentation/git-fmt-merge-msg.txt | 4 +-
Documentation/git-for-each-ref.txt | 8 +-
Documentation/git-format-patch.txt | 2 +-
Documentation/git-fsck-objects.txt | 2 +-
Documentation/git-fsck.txt | 4 +-
Documentation/git-gc.txt | 4 +-
Documentation/git-get-tar-commit-id.txt | 2 +-
Documentation/git-grep.txt | 2 +-
Documentation/git-hash-object.txt | 2 +-
Documentation/git-http-fetch.txt | 2 +-
Documentation/git-http-push.txt | 2 +-
Documentation/git-imap-send.txt | 4 +-
Documentation/git-index-pack.txt | 4 +-
Documentation/git-init-db.txt | 2 +-
Documentation/git-init.txt | 6 +-
Documentation/git-instaweb.txt | 4 +-
Documentation/git-lost-found.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-ls-remote.txt | 2 +-
Documentation/git-ls-tree.txt | 2 +-
Documentation/git-mailinfo.txt | 6 +-
Documentation/git-mailsplit.txt | 2 +-
Documentation/git-merge-base.txt | 4 +-
Documentation/git-merge-file.txt | 4 +-
Documentation/git-merge-index.txt | 6 +-
Documentation/git-merge-tree.txt | 2 +-
Documentation/git-merge.txt | 8 +-
Documentation/git-mergetool.txt | 16 +++---
Documentation/git-mktag.txt | 2 +-
Documentation/git-mv.txt | 6 +-
Documentation/git-name-rev.txt | 2 +-
Documentation/git-pack-objects.txt | 2 +-
Documentation/git-pack-redundant.txt | 4 +-
Documentation/git-pack-refs.txt | 8 +-
Documentation/git-patch-id.txt | 2 +-
Documentation/git-peek-remote.txt | 2 +-
Documentation/git-prune-packed.txt | 2 +-
Documentation/git-prune.txt | 2 +-
Documentation/git-pull.txt | 2 +-
Documentation/git-push.txt | 2 +-
Documentation/git-quiltimport.txt | 2 +-
Documentation/git-read-tree.txt | 32 +++++-----
Documentation/git-rebase.txt | 18 +++---
Documentation/git-receive-pack.txt | 6 +-
Documentation/git-relink.txt | 2 +-
Documentation/git-remote.txt | 12 ++--
Documentation/git-repack.txt | 10 ++--
Documentation/git-repo-config.txt | 2 +-
Documentation/git-request-pull.txt | 2 +-
Documentation/git-rerere.txt | 4 +-
Documentation/git-rev-list.txt | 10 ++--
Documentation/git-rev-parse.txt | 6 +-
Documentation/git-revert.txt | 2 +-
Documentation/git-rm.txt | 6 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-send-pack.txt | 2 +-
Documentation/git-shortlog.txt | 6 +-
Documentation/git-show-branch.txt | 4 +-
Documentation/git-show-index.txt | 2 +-
Documentation/git-show-ref.txt | 6 +-
Documentation/git-show.txt | 2 +-
Documentation/git-stash.txt | 14 ++--
Documentation/git-status.txt | 6 +-
Documentation/git-stripspace.txt | 2 +-
Documentation/git-submodule.txt | 10 ++--
Documentation/git-svn.txt | 34 +++++-----
Documentation/git-symbolic-ref.txt | 2 +-
Documentation/git-tag.txt | 16 +++---
Documentation/git-tar-tree.txt | 2 +-
Documentation/git-unpack-file.txt | 2 +-
Documentation/git-unpack-objects.txt | 2 +-
Documentation/git-update-index.txt | 12 ++--
Documentation/git-update-ref.txt | 10 ++--
Documentation/git-update-server-info.txt | 2 +-
Documentation/git-upload-archive.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
Documentation/git-var.txt | 4 +-
Documentation/git-verify-pack.txt | 2 +-
Documentation/git-verify-tag.txt | 2 +-
Documentation/git-web--browse.txt | 2 +-
Documentation/git-whatchanged.txt | 6 +-
Documentation/git-write-tree.txt | 2 +-
Documentation/gitattributes.txt | 14 ++--
Documentation/gitcore-tutorial.txt | 94 +++++++++++++++---------------
Documentation/gitcvs-migration.txt | 8 +-
Documentation/gitdiffcore.txt | 2 +-
Documentation/githooks.txt | 10 ++--
Documentation/gitignore.txt | 4 +-
Documentation/gitrepository-layout.txt | 20 +++---
Documentation/gittutorial-2.txt | 18 +++---
Documentation/gittutorial.txt | 34 +++++-----
Documentation/user-manual.txt | 76 ++++++++++++------------
126 files changed, 456 insertions(+), 455 deletions(-)
Patch at
<http://home.uchicago.edu/~jrnieder/20080630-git-documentation-patch.txt>.
^ permalink raw reply
* [PATCH] Only use GIT_CONFIG in "git config", not other programs
From: Daniel Barkalow @ 2008-06-30 7:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
For everything other than using "git config" to read or write a
git-style config file that isn't the current repo's config file,
GIT_CONFIG was actively detrimental. Rather than argue over which
programs are important enough to have work anyway, just fix all of
them at the root.
Also removes GIT_LOCAL_CONFIG, which would only be useful for programs
that do want to use global git-specific config, but not the repo's own
git-specific config, and want to use some other, presumably
git-specific config. Despite being documented, I can't find any sign that
it was ever used.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
This passes all of the tests, including the git-svn ones. It seems that,
in fact, GIT_CONFIG was only used to control "git config" in scripts and
tests are protected with GIT_CONFIG_NOSYSTEM and GIT_CONFIG_NOGLOBAL.
Along with this, my clone patch makes most sense, because the environment
variable won't do anything anyway, so we don't have to change it at all.
Documentation/git-config.txt | 9 --------
builtin-config.c | 15 ++++++-------
cache.h | 2 +-
config.c | 47 +++++++++++++++++------------------------
4 files changed, 28 insertions(+), 45 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index c90421e..30c8432 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -191,11 +191,6 @@ variables. The '--global' and the '--system' options will limit the file used
to the global or system-wide file respectively. The GIT_CONFIG environment
variable has a similar effect, but you can specify any filename you want.
-The GIT_CONFIG_LOCAL environment variable on the other hand only changes
-the name used instead of the repository configuration file. The global and
-the system-wide configuration files will still be read. (For writing options
-this will obviously result in the same behavior as using GIT_CONFIG.)
-
ENVIRONMENT
-----------
@@ -205,10 +200,6 @@ GIT_CONFIG::
Using the "--global" option forces this to ~/.gitconfig. Using the
"--system" option forces this to $(prefix)/etc/gitconfig.
-GIT_CONFIG_LOCAL::
- Take the configuration from the given file instead if .git/config.
- Still read the global and the system-wide configuration files, though.
-
See also <<FILES>>.
diff --git a/builtin-config.c b/builtin-config.c
index 3a441ef..39f63d7 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -81,12 +81,10 @@ static int get_value(const char* key_, const char* regex_)
char *global = NULL, *repo_config = NULL;
const char *system_wide = NULL, *local;
- local = getenv(CONFIG_ENVIRONMENT);
+ local = config_exclusive_filename;
if (!local) {
const char *home = getenv("HOME");
- local = getenv(CONFIG_LOCAL_ENVIRONMENT);
- if (!local)
- local = repo_config = xstrdup(git_path("config"));
+ local = repo_config = xstrdup(git_path("config"));
if (git_config_global() && home)
global = xstrdup(mkpath("%s/.gitconfig", home));
if (git_config_system())
@@ -289,6 +287,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
char* value;
const char *file = setup_git_directory_gently(&nongit);
+ config_exclusive_filename = getenv(CONFIG_ENVIRONMENT);
+
while (1 < argc) {
if (!strcmp(argv[1], "--int"))
type = T_INT;
@@ -309,14 +309,13 @@ int cmd_config(int argc, const char **argv, const char *prefix)
char *home = getenv("HOME");
if (home) {
char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
- setenv(CONFIG_ENVIRONMENT, user_config, 1);
- free(user_config);
+ config_exclusive_filename = user_config;
} else {
die("$HOME not set");
}
}
else if (!strcmp(argv[1], "--system"))
- setenv(CONFIG_ENVIRONMENT, git_etc_gitconfig(), 1);
+ config_exclusive_filename = git_etc_gitconfig();
else if (!strcmp(argv[1], "--file") || !strcmp(argv[1], "-f")) {
if (argc < 3)
usage(git_config_set_usage);
@@ -325,7 +324,7 @@ int cmd_config(int argc, const char **argv, const char *prefix)
argv[2]);
else
file = argv[2];
- setenv(CONFIG_ENVIRONMENT, file, 1);
+ config_exclusive_filename = file;
argc--;
argv++;
}
diff --git a/cache.h b/cache.h
index 64ef86e..bab0115 100644
--- a/cache.h
+++ b/cache.h
@@ -298,7 +298,6 @@ static inline enum object_type object_type(unsigned int mode)
#define GRAFT_ENVIRONMENT "GIT_GRAFT_FILE"
#define TEMPLATE_DIR_ENVIRONMENT "GIT_TEMPLATE_DIR"
#define CONFIG_ENVIRONMENT "GIT_CONFIG"
-#define CONFIG_LOCAL_ENVIRONMENT "GIT_CONFIG_LOCAL"
#define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
#define GITATTRIBUTES_FILE ".gitattributes"
#define INFOATTRIBUTES_FILE "info/attributes"
@@ -743,6 +742,7 @@ extern int check_repository_format_version(const char *var, const char *value, v
extern int git_config_system(void);
extern int git_config_global(void);
extern int config_error_nonbool(const char *);
+extern const char *config_exclusive_filename;
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
diff --git a/config.c b/config.c
index 58749bf..2862cc4 100644
--- a/config.c
+++ b/config.c
@@ -16,6 +16,8 @@ static int config_linenr;
static int config_file_eof;
static int zlib_compression_seen;
+const char *config_exclusive_filename = NULL;
+
static int get_next_char(void)
{
int c;
@@ -611,31 +613,28 @@ int git_config(config_fn_t fn, void *data)
{
int ret = 0;
char *repo_config = NULL;
- const char *home = NULL, *filename;
+ const char *home = NULL;
/* $GIT_CONFIG makes git read _only_ the given config file,
* $GIT_CONFIG_LOCAL will make it process it in addition to the
* global config file, the same way it would the per-repository
* config file otherwise. */
- filename = getenv(CONFIG_ENVIRONMENT);
- if (!filename) {
- if (git_config_system() && !access(git_etc_gitconfig(), R_OK))
- ret += git_config_from_file(fn, git_etc_gitconfig(),
- data);
- home = getenv("HOME");
- filename = getenv(CONFIG_LOCAL_ENVIRONMENT);
- if (!filename)
- filename = repo_config = xstrdup(git_path("config"));
- }
+ if (config_exclusive_filename)
+ return git_config_from_file(fn, config_exclusive_filename, data);
+ if (git_config_system() && !access(git_etc_gitconfig(), R_OK))
+ ret += git_config_from_file(fn, git_etc_gitconfig(),
+ data);
+ home = getenv("HOME");
if (git_config_global() && home) {
char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
if (!access(user_config, R_OK))
- ret = git_config_from_file(fn, user_config, data);
+ ret += git_config_from_file(fn, user_config, data);
free(user_config);
}
- ret += git_config_from_file(fn, filename, data);
+ repo_config = xstrdup(git_path("config"));
+ ret += git_config_from_file(fn, repo_config, data);
free(repo_config);
return ret;
}
@@ -873,13 +872,10 @@ int git_config_set_multivar(const char* key, const char* value,
struct lock_file *lock = NULL;
const char* last_dot = strrchr(key, '.');
- config_filename = getenv(CONFIG_ENVIRONMENT);
- if (!config_filename) {
- config_filename = getenv(CONFIG_LOCAL_ENVIRONMENT);
- if (!config_filename)
- config_filename = git_path("config");
- }
- config_filename = xstrdup(config_filename);
+ if (config_exclusive_filename)
+ config_filename = xstrdup(config_exclusive_filename);
+ else
+ config_filename = xstrdup(git_path("config"));
/*
* Since "key" actually contains the section name and the real
@@ -1136,13 +1132,10 @@ int git_config_rename_section(const char *old_name, const char *new_name)
int out_fd;
char buf[1024];
- config_filename = getenv(CONFIG_ENVIRONMENT);
- if (!config_filename) {
- config_filename = getenv(CONFIG_LOCAL_ENVIRONMENT);
- if (!config_filename)
- config_filename = git_path("config");
- }
- config_filename = xstrdup(config_filename);
+ if (config_exclusive_filename)
+ config_filename = xstrdup(config_exclusive_filename);
+ else
+ config_filename = xstrdup(git_path("config"));
out_fd = hold_lock_file_for_update(lock, config_filename, 0);
if (out_fd < 0) {
ret = error("could not lock config file %s", config_filename);
--
1.5.6.1.103.g1c643
^ permalink raw reply related
* Re: [PATCH] Skip unwritable tests for root
From: Jakub Narebski @ 2008-06-30 7:39 UTC (permalink / raw)
To: Fernando J. Pereda; +Cc: git, Junio C Hamano
In-Reply-To: <1214809551-14603-1-git-send-email-ferdy@ferdyx.org>
"Fernando J. Pereda" <ferdy@ferdyx.org> writes:
> +if test "$(id -u)" -eq 0
> +then
> + test_expect_success 'root writes to unwritable places, skipping test' :
> + test_done
> + exit
> +fi
Yet another place that would profit from test_skip in test-lib.sh...
(Junio uses "say skip" instead of "test_expect_success" in the place
like above here).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [StGit PATCH 1/2] Try "stg sink" without applied patches
From: Sverre Rabbelier @ 2008-06-30 7:53 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Catalin Marinas, git, Erik Sandberg
In-Reply-To: <20080629224541.9267.19258.stgit@yoghurt>
On Mon, Jun 30, 2008 at 12:45 AM, Karl Hasselström <kha@treskal.com> wrote:
> (The implicit sink testcase actually passes, but that's just because
> the test suite can't distinguish between a program bug and an orderly
> abort.)
Yes it can, that's where "test_must_fail" comes in.
<snip>
> +test_expect_success 'sink without applied patches' '
> + test_must_fail stg sink
> +'
> +
Like that.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Only use GIT_CONFIG in "git config", not other programs
From: Junio C Hamano @ 2008-06-30 7:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Johannes Schindelin
In-Reply-To: <alpine.LNX.1.00.0806300328380.19665@iabervon.org>
Hmm, I actually think this is a good thing to do in the sense that it
vastly simplifies the user experience ;-). Two less things to explain.
Care to write up a snippet for 1.6.0 release notes, as this is quite a
large user visible backward incompatible change, even though it would be
an improvement?
^ permalink raw reply
* Re: [StGit PATCH 1/2] Try "stg sink" without applied patches
From: Karl Hasselström @ 2008-06-30 8:44 UTC (permalink / raw)
To: sverre; +Cc: Catalin Marinas, git, Erik Sandberg
In-Reply-To: <bd6139dc0806300053m4325104dx145cd8840c630453@mail.gmail.com>
On 2008-06-30 09:53:22 +0200, Sverre Rabbelier wrote:
> On Mon, Jun 30, 2008 at 12:45 AM, Karl Hasselström <kha@treskal.com> wrote:
>
> > (The implicit sink testcase actually passes, but that's just
> > because the test suite can't distinguish between a program bug and
> > an orderly abort.)
>
> Yes it can, that's where "test_must_fail" comes in.
>
> > +test_expect_success 'sink without applied patches' '
> > + test_must_fail stg sink
> > +'
> > +
>
> Like that.
Well, except that
1. test_must_fail doesn't even exist in StGit's test-lib.sh, because
I've omitted it on purpose when stealing good stuff from git's
test-lib.sh, because
2. StGit is written in Python, so random bugs virtually never cause
segfaults and stuff, they just raise various exceptions.
That said, StGit (especially in the master branch -- but this patch
was against stable, where this is much less true) does exit with
different exit codes depending on what kind of exception interrupted
the program, and all exceptions not on a certain list cause it to exit
with an exit code that means there's a bug (see the end of
stgit/main.py for details). So writing a test_must_fail with sane
behavior is perfectly doable and not actually all that hard.
Patch? :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Skip unwritable tests for root
From: Junio C Hamano @ 2008-06-30 9:08 UTC (permalink / raw)
To: Fernando J. Pereda; +Cc: git
In-Reply-To: <1214809551-14603-1-git-send-email-ferdy@ferdyx.org>
"Fernando J. Pereda" <ferdy@ferdyx.org> writes:
> Signed-off-by: Fernando J. Pereda <ferdy@ferdyx.org>
Hmm. Actually we've deliberately ignored this so far. If we were to do
anything, don't we rather want to fail everything upfront when the tests
are run by root?
Running "make" and "make test" before "make install" is so that you have
less chance hurting your running system, and I find it simply crazy to
build (i.e. "make all") as root, let alone running tests.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-30 9:08 UTC (permalink / raw)
To: git
In-Reply-To: <7vod5kd3im.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be applied to the maintenance series have "maint-" in their
names.
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:
* MinGW will be in.
* With the default Makefile settings, most of the programs will be
installed outside your $PATH, except for "git", "gitk", "git-gui" and
some server side programs that need to be accessible for technical
reasons. Invoking a git subcommand as "git-xyzzy" from the command
line has been deprecated since early 2006 (and officially announced in
1.5.4 release notes); use of them from your scripts after adding
output from "git --exec-path" to the $PATH will still be supported in
1.6.0, but users are again strongly encouraged to adjust their
scripts to use "git xyzzy" form, as we will stop installing
"git-xyzzy" hardlinks for built-in commands in later releases.
* git-merge will be rewritten in C.
* default pack and idx versions will be updated as scheduled for some
time ago.
----------------------------------------------------------------
[Will merge to master soon]
* nd/dashless (Tue Jun 24 19:58:11 2008 -0700) 2 commits
+ Keep some git-* programs in $(bindir)
+ Move all dashed-form commands to libexecdir
Scheduled for 1.6.0. We'll leave server-side programs in $(bindir) so
that ssh clients can ask for "git-program" and find them on the $PATH.
Next major release after 1.6.0 would most likely remove the hardlinks to
built-in commands, but not yet.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 4 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
+ Prepare execv_git_cmd() for removal of builtins from the
filesystem
+ git-shell: accept "git foo" form
----------------------------------------------------------------
[Actively Cooking]
* jk/maint-fetch-ref-hier (Fri Jun 27 00:01:41 2008 -0400) 2 commits
+ fetch: give a hint to the user when local refs fail to update
+ fetch: report local storage errors in status table
When the remote used to have "foo" branch but now has "foo/bar", fetch
refuses to delete the existing remote tracking branch "foo" to create a
new remote tracking branch "foo/bar", but the error message was
confusing.
* jc/maint-reset (Wed Jun 25 18:16:36 2008 -0700) 1 commit
+ Allow "git-reset path" when unambiguous
We used to require "git-reset -- path" even when there is no ambiguity
(i.e. path cannot be mistaken as a valid tree-ish and it is a filename in
the work tree).
* js/maint-clone-insteadof (Fri Jun 27 13:55:23 2008 +0100) 2 commits
+ clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
+ clone: respect url.insteadOf setting in global configs
"git clone" did not honor "url.InsteadOf" in $HOME/.gitconfig. I think
Daniel's "Let's get rid of internal use of GIT_CONFIG" makes sense (even
though it feels very scary), and it would make the solution much simpler,
but it came late and it is already past my bedtime, so...
* tr/send-email-ssl (Thu Jun 26 23:03:21 2008 +0200) 2 commits
+ git-send-email: prevent undefined variable warnings if no
encryption is set
+ git-send-email: add support for TLS via Net::SMTP::SSL
* kb/send-email-fifo (Wed Jun 25 15:44:40 2008 -0700) 1 commit
+ git-send-email: Accept fifos as well as files
Two minor send-email feature enhancements for 1.6.0.
* jc/checkdiff (Sun Jun 29 16:49:06 2008 -0400) 7 commits
+ Fix t4017-diff-retval for white-space from wc
+ Update sample pre-commit hook to use "diff --check"
+ diff --check: detect leftover conflict markers
+ Teach "diff --check" about new blank lines at end
+ checkdiff: pass diff_options to the callback
+ check_and_emit_line(): rename and refactor
+ diff --check: explain why we do not care whether old side is
binary
Allows us to replace the sample pre-commit hook that was not aware of the
line termination convention per path nor newer whitespace breakage rules.
* np/pack-default (Wed Jun 25 00:25:53 2008 -0400) 2 commits
+ pack.indexversion config option now defaults to 2
+ repack.usedeltabaseoffset config option now defaults to "true"
Updates the default value for pack.indexversion to 2 and use delta-base
offset encoding of the packfiles by default.
* js/apply-recount (Fri Jun 27 18:43:09 2008 +0100) 1 commit
+ Allow git-apply to recount the lines in a hunk (AKA recountdiff)
A good ingredient for implementing "apply --edit".
* dz/apply-again (Fri Jun 27 14:39:12 2008 -0400) 1 commit
+ git-apply: handle a patch that touches the same path more than
once better
Allows us to feed a patch that touches the same path more than once.
* jc/reflog-expire (Sat Jun 28 22:24:49 2008 -0700) 2 commits
- Make default expiration period of reflog used for stash infinite
- Per-ref reflog expiry configuration
As 1.6.0 will be a good time to make backward incompatible changes, the
tip commit makes the default expiry period of stash 'never', unless you
configure them to expire explicitly using gc.refs/stash.* variables.
Needs consensus, but I am guessing that enough people would want stash
that does not expire.
* jc/merge-theirs (Sat Jun 28 17:28:22 2008 -0700) 3 commits
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged. It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are. The interface to the backends is updated so that you can
say "git merge -Xours -s recursive other" now.
* j6t/mingw (Sat Nov 17 20:48:14 2007 +0100) 38 commits
+ compat/pread.c: Add a forward declaration to fix a warning
+ Windows: Fix ntohl() related warnings about printf formatting
+ Windows: TMP and TEMP environment variables specify a temporary
directory.
+ Windows: Make 'git help -a' work.
+ Windows: Work around an oddity when a pipe with no reader is
written to.
+ Windows: Make the pager work.
+ When installing, be prepared that template_dir may be relative.
+ Windows: Use a relative default template_dir and ETC_GITCONFIG
+ Windows: Compute the fallback for exec_path from the program
invocation.
+ Turn builtin_exec_path into a function.
+ Windows: Use a customized struct stat that also has the st_blocks
member.
+ Windows: Add a custom implementation for utime().
+ Windows: Add a new lstat and fstat implementation based on Win32
API.
+ Windows: Implement a custom spawnve().
+ Windows: Implement wrappers for gethostbyname(), socket(), and
connect().
+ Windows: Work around incompatible sort and find.
+ Windows: Implement asynchronous functions as threads.
+ Windows: Disambiguate DOS style paths from SSH URLs.
+ Windows: A rudimentary poll() emulation.
+ Windows: Implement start_command().
+ Windows: A pipe() replacement whose ends are not inherited to
children.
+ Windows: Wrap execve so that shell scripts can be invoked.
+ Windows: Implement setitimer() and sigaction().
+ Windows: Fix PRIuMAX definition.
+ Windows: Implement gettimeofday().
+ Make my_mktime() public and rename it to tm_to_time_t()
+ Windows: Work around misbehaved rename().
+ Windows: always chmod(, 0666) before unlink().
+ Windows: A minimal implemention of getpwuid().
+ Windows: Implement a wrapper of the open() function.
+ Windows: Strip ".exe" from the program name.
+ Windows: Handle absolute paths in
safe_create_leading_directories().
+ Windows: Treat Windows style path names.
+ setup.c: Prepare for Windows directory separators.
+ Windows: Use the Windows style PATH separator ';'.
+ Add target architecture MinGW.
+ Compile some programs only conditionally.
+ Add compat/regex.[ch] and compat/fnmatch.[ch].
No explanation necessary ;-)
* mv/merge-in-c (Mon Jun 30 03:39:58 2008 +0200) 13 commits
- Build in merge
- Add new test case to ensure git-merge prepends the custom merge
message
- Add new test case to ensure git-merge reduces octopus parents when
possible
- Introduce reduce_heads()
- Introduce get_merge_bases_many()
- Add new test to ensure git-merge handles more than 25 refs.
- Introduce get_octopus_merge_bases() in commit.c
- git-fmt-merge-msg: make it usable from other builtins
- Move read_cache_unmerged() to read-cache.c
- Add new test to ensure git-merge handles pull.twohead and
pull.octopus
- Move parse-options's skip_prefix() to git-compat-util.h
- Move commit_list_count() to commit.c
- Move split_cmdline() to alias.c
The last one is still in flux.
* dr/ceiling (Mon May 19 23:49:34 2008 -0700) 4 commits
+ Eliminate an unnecessary chdir("..")
+ Add support for GIT_CEILING_DIRECTORIES
+ Fold test-absolute-path into test-path-utils
+ Implement normalize_absolute_path
* jc/rerere (Sun Jun 22 02:04:31 2008 -0700) 5 commits
+ rerere.autoupdate
+ t4200: fix rerere test
+ rerere: remove dubious "tail_optimization"
+ git-rerere: detect unparsable conflicts
+ rerere: rerere_created_at() and has_resolution() abstraction
A new configuration will allow paths that have been resolved cleanly by
rerere to be updated in the index automatically.
* ph/parseopt-step-blame (Tue Jun 24 11:12:12 2008 +0200) 7 commits
- Migrate git-blame to parse-option partially.
- parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
- parse-opt: fake short strings for callers to believe in.
- parse-opt: do not pring errors on unknown options, return -2
intead.
- parse-opt: create parse_options_step.
- parse-opt: Export a non NORETURN usage dumper.
- parse-opt: have parse_options_{start,end}.
----------------------------------------------------------------
[Graduated to "master"]
----------------------------------------------------------------
[On Hold]
* ph/mergetool (Mon Jun 16 17:33:41 2008 -0600) 1 commit
+ Remove the use of '--' in merge program invocation
Waiting for success reports from people who use various backends.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Stalled/Needs more work]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 7 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
+ git-blame --reverse
+ builtin-blame.c: allow more than 16 parents
+ builtin-blame.c: move prepare_final() into a separate function.
+ rev-list --children
+ revision traversal: --children option
The blame that finds where each line in the original lines moved to. This
may help a GSoC project that wants to gather statistical overview of the
history. The final presentation may need tweaking (see the log message of
the commit ""git-blame --reverse" on the series).
The tip two commits are for peeling to see what's behind the blamed
commit, which we should be able to separate out into an independent topic
from the rest.
----------------------------------------------------------------
[Dropped for now]
* sj/merge (Sat May 3 16:55:47 2008 -0700) 6 commits
. Introduce fast forward option only
. Head reduction before selecting merge strategy
. Restructure git-merge.sh
. Introduce -ff=<fast forward option>
. New merge tests
. Documentation for joining more than two histories
This will interfere with Miklos's rewrite of merge to C.
* js/rebase-i-sequencer (Sun Apr 27 02:55:50 2008 -0400) 17 commits
. Use perl instead of tac
. Fix t3404 assumption that `wc -l` does not use whitespace.
. rebase -i: Use : in expr command instead of match.
. rebase -i: update the implementation of 'mark' command
. Add option --preserve-tags
. Teach rebase interactive the tag command
. Add option --first-parent
. Do rebase with preserve merges with advanced TODO list
. Select all lines with fake-editor
. Unify the length of $SHORT* and the commits in the TODO list
. Teach rebase interactive the merge command
. Move redo merge code in a function
. Teach rebase interactive the reset command
. Teach rebase interactive the mark command
. Move cleanup code into it's own function
. Don't append default merge message to -m message
. fake-editor: output TODO list if unchanged
* jc/cherry-pick (Wed Feb 20 23:17:06 2008 -0800) 3 commits
. WIP: rethink replay merge
. Start using replay-tree merge in cherry-pick
. revert/cherry-pick: start refactoring call to merge_recursive
This is meant to improve cherry-pick's behaviour when renames are
involved, by not using merge-recursive (whose d/f conflict resolution is
quite broken), but unfortunately has stalled for some time now.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
Just my toy at this moment.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
. "git push": tellme-more protocol extension
^ permalink raw reply
* Re: [PATCH] Skip unwritable tests for root
From: Fernando J. Pereda @ 2008-06-30 9:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabh31e9p.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Mon, Jun 30, 2008 at 02:08:18AM -0700, Junio C Hamano wrote:
> "Fernando J. Pereda" <ferdy@ferdyx.org> writes:
>
> > Signed-off-by: Fernando J. Pereda <ferdy@ferdyx.org>
>
> Hmm. Actually we've deliberately ignored this so far. If we were to do
> anything, don't we rather want to fail everything upfront when the tests
> are run by root?
>
> Running "make" and "make test" before "make install" is so that you have
> less chance hurting your running system, and I find it simply crazy to
> build (i.e. "make all") as root, let alone running tests.
*nod*
This originated because Gentoo can be told to build stuff as root (and
run test as root) under a sandbox. Since I already had the patch
locally, I guessed you might be interested in it and just sent it.
I'll just apply it locally.
- ferdy
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jan Wielemaker @ 2008-06-30 9:49 UTC (permalink / raw)
To: git
Hi,
I'm a bit puzzled. I have a bare repository, somehow without any files
in refs/heads.
It started using conversion from CVS via SVN using git-1.5.3.4. It is
configured for group access and there are a number of SSH accounts on
the machine in the proper group using git-shell for fellow developers.
I never have any problems, but after upgrading to git-git (1.5.6.rc3)
fellow users get error:
error: no such remote ref refs/heads/JPL31
error: no such remote ref refs/heads/V57X
error: no such remote ref refs/heads/V5_4_patches
error: no such remote ref refs/heads/XML_UNICODE
error: no such remote ref refs/heads/attvar
error: no such remote ref refs/heads/gmp
Creating a new account and doing a fresh clone I even got the fatal
error there are no remote branches!? Still, using my own user id, I
could do anything I wanted. I checked permissions to see whether there
are differences between group and owner permissions, but couldn't find
anything suspicious. git fsck --full on the repo gives no errors.
It turns out the directory refs/heads is empty!?
I made a fresh clone of the repo as myself, creating all references
nicely in refs/remotes/origin. Then I copied these files to refs/heads
into the main bare repository and now all appears to work nicely again.
Still, this is a bit worrying ... My questions:
* Is my work-around safe and sound?
* How can this have happened?
* Why can I clone as myself and not as anyone else!? Stranger:
after a "sudo -u <someone> /bin/bash" I could not clone. I can
copy the entire tree using cp -a, but I still cannot clone the
copy with this user, while as myself I can clone the copy.
Somehow `as myself' appears to get the branchheads from somewhere.
There is only one copy of git installed, so both users use the
same. What can cause this difference?
Thanks --- Jan
^ permalink raw reply
* [PATCH/RFC] git-blame.el: Use eldoc-mode to display current commit.
From: Nikolaj Schumacher @ 2008-06-30 9:57 UTC (permalink / raw)
To: git; +Cc: David Kågedal
I think this is a better way to display the current commit. However,
I'm not sure whether to rely on eldoc, or create my own timer.
regards,
Nikolaj Schumacher
>From 4bbd50ab1ae26ca154c20d140edfa187c9124959 Mon Sep 17 00:00:00 2001
From: Nikolaj Schumacher <git@nschum.de>
Date: Mon, 30 Jun 2008 11:44:46 +0200
Subject: [PATCH] git-blame.el: Use eldoc-mode to display current commit.
Previously, the current commit was displayed on every point movement using
text properties. These properties stick to copied text, so that an error is
thrown once it is pasted in a different buffer. Additionally, there is no
way to turn them off. Using a configurable timer solves these problems.
Since eldoc already provides such functionality, hand off the work to it.
---
contrib/emacs/git-blame.el | 27 +++++++++++----------------
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 9f92cd2..c13e445 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -40,7 +40,7 @@
;; turn it on while viewing a file, the editor buffer will be updated by
;; setting the background of individual lines to a color that reflects
;; which commit it comes from. And when you move around the buffer, a
-;; one-line summary will be shown in the echo area.
+;; one-line summary will be shown in the echo area if `eldoc-mode' is on.
;;; Installation:
;;
@@ -195,6 +195,7 @@ See also function `git-blame-mode'."
(setq git-blame-colors git-blame-light-colors)))
(setq git-blame-cache (make-hash-table :test 'equal))
(setq git-blame-mode t)
+ (setq eldoc-documentation-function 'git-blame-identify)
(git-blame-run))
(defun git-blame-mode-off ()
@@ -354,15 +355,7 @@ See also function `git-blame-mode'."
(overlay-put ovl 'git-blame info)
(overlay-put ovl 'help-echo hash)
(overlay-put ovl 'face (list :background
- (cdr (assq 'color (nthcdr 5 info)))))
- ;; the point-entered property doesn't seem to work in overlays
- ;;(overlay-put ovl 'point-entered
- ;; `(lambda (x y) (git-blame-identify ,hash)))
- (let ((modified (buffer-modified-p)))
- (put-text-property (if (= start 1) start (1- start)) (1- end)
- 'point-entered
- `(lambda (x y) (git-blame-identify ,hash)))
- (set-buffer-modified-p modified))))
+ (cdr (assq 'color (nthcdr 5 info)))))))
(setq num-lines (1- num-lines))))))
(defun git-blame-add-info (key value)
@@ -383,14 +376,16 @@ See also function `git-blame-mode'."
hash)
(buffer-substring (point-min) (1- (point-max)))))
-(defvar git-blame-last-identification nil)
-(make-variable-buffer-local 'git-blame-last-identification)
(defun git-blame-identify (&optional hash)
(interactive)
- (let ((info (gethash (or hash (git-blame-current-commit)) git-blame-cache)))
- (when (and info (not (eq info git-blame-last-identification)))
- (message "%s" (nth 4 info))
- (setq git-blame-last-identification info))))
+ (condition-case err
+ (let ((info (nth 4 (gethash (or hash (git-blame-current-commit))
+ git-blame-cache))))
+ (when info
+ (when (interactive-p)
+ (message "%s" info))
+ info))
+ (error nil)))
;; (defun git-blame-after-save ()
;; (when git-blame-mode
--
1.5.5.3
^ permalink raw reply related
* Re: Patches for qgit on MacOS X
From: Marco Costalba @ 2008-06-30 10:00 UTC (permalink / raw)
To: ocroquette; +Cc: git
In-Reply-To: <48665027.3090406@free.fr>
On Sat, Jun 28, 2008 at 3:52 PM, Olivier Croquette <ocroquette@free.fr> wrote:
> Hi all
>
> I have posted 2 patches against qgit to make it work (better) under MacOS X:
> http://sourceforge.net/tracker/index.php?func=detail&aid=2005126&group_id=139897&atid=744829
> http://sourceforge.net/tracker/index.php?func=detail&aid=2005125&group_id=139897&atid=744829
>
> Comments are welcome.
>
Thanks for the patches, I'll apply them.
Can I ask why don't you use qgit-2.X series ? being based on Qt4
should be much easier to make it work under MacOS X and it's a better
qgit overall.
Thanks
Marco
^ permalink raw reply
* [PATCH] Don't cut off last character of commit descriptions.
From: Nikolaj Schumacher @ 2008-06-30 10:08 UTC (permalink / raw)
To: git; +Cc: David Kågedal
>From d485d9c86cba49671b74c7c1571a6ad7ec6d09b6 Mon Sep 17 00:00:00 2001
From: Nikolaj Schumacher <git@nschum.de>
Date: Mon, 30 Jun 2008 12:06:01 +0200
Subject: [PATCH] Don't cut off last character of commit descriptions.
---
contrib/emacs/git-blame.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 9f92cd2..4fa70c5 100644
--- a/contrib/emacs/git-blame.el
+++ b/contrib/emacs/git-blame.el
@@ -381,7 +381,7 @@ See also function `git-blame-mode'."
"log" "-1"
(concat "--pretty=" git-blame-log-oneline-format)
hash)
- (buffer-substring (point-min) (1- (point-max)))))
+ (buffer-substring (point-min) (point-max))))
(defvar git-blame-last-identification nil)
(make-variable-buffer-local 'git-blame-last-identification)
--
1.5.5.3
^ permalink raw reply related
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jakub Narebski @ 2008-06-30 10:10 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200806301149.18115.J.Wielemaker@uva.nl>
Jan Wielemaker <J.Wielemaker@uva.nl> writes:
> I'm a bit puzzled. I have a bare repository, somehow without any files
> in refs/heads.
Do you have .git/packed-refs file? How do you have gc.packrefs set
("git config --get gc.packrefs")? What are the git version on the
clients that have trouble accessing repository, and what protocol
(transport merhod) do they use: "file", http(s)/ftp, git, ssh?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* error: Untracked working tree file '(myfile)' would be overwritten by merge. when checking out a more recent branch
From: Swanny Lorenzi @ 2008-06-30 10:15 UTC (permalink / raw)
To: git
Hi,
We got at work a surprising error when trying to checkout a more recent
branch :
error: Untracked working tree file '(file)' would be overwritten by
merge. (I replaced the actual file name by 'file' in this mail)
The context is :
- Each developer has its own git repository, and makes all developement
work in it
- We use a "central" git repository to gather all our work, all devs
track this common repository's branches to pull and push they work.
- We don't allow devs to track another dev branch, everything must pass
by this central repository.
- We use git v 1.5.5.4, tig and git gui.
- Our main branch is called "trunk", and we use several other branches
for our work.
Last Thursday, I had to replace 6 directories (with files in them) by
symbolic links to another directory, in the "trunk" branch.
I removed them using sh rm -rf, then ln -s to create the links. Problem,
git gui failed to stage the changes to a single commit.
I split the change into 2 operations : the directory removal -> commit,
then the symlink creation -> commit.
I pushed the 2 commits - and other commits after - into our central
repository, no error was prompted.
Then came the issue :
Each time a dev tried to checkout the trunk branch from an older version
(e.g. a branch that has its origin to an older commit of trunk), he got
the error message
error: Untracked working tree file '(file)' would be overwritten by merge.
=> Checkout failed, etc. Obliged to force the checkout with git checkout -f.
- The file listed in the error message is absolutely not affected by any
commit in the 2 I mentioned above, nor in the 10 surrounding them. It
was not even changed for 2 monthes.
- The error occur even if we don't have any "modified" file (git status
answers nothing to commit, nor any untracked files)
- After investigations, it seems that the error occurs each time we ask
git to run the 2 commits mentioned above in a single checkout command :
If I checkout a branch pointing to the 1st commit (dir deletion), then
another checkout to the trunk head, the error does not occur.
- The file mentioned in the error is the first file in the directory
that follow the parent dir of the removed dirs (in the order returned by
ls):
- I failed to reproduce this bug using clean repositories...
Has anyone got this error before ?
Is it a git bug ?
Thanks for all
Swanny
^ permalink raw reply
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jan Wielemaker @ 2008-06-30 10:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3r6afgrme.fsf@localhost.localdomain>
Hi Jakub,
Thanks for the quick reply. Info:
On Monday 30 June 2008 12:10, Jakub Narebski wrote:
> Jan Wielemaker <J.Wielemaker@uva.nl> writes:
> > I'm a bit puzzled. I have a bare repository, somehow without any files
> > in refs/heads.
>
> Do you have .git/packed-refs file? How do you have gc.packrefs set
Its a bare repo, so I'll forget the .git. Yes, I have that file and
it contains nice references, I checked a few by hand, and they have
the same SHA1 as the files I copied.
> ("git config --get gc.packrefs")? What are the git version on the
This gives no output, so I guess the answer is 'no'. Is that wrong?
This is indeed the case (config):
----------------------------------------------------------------
[core]
repositoryformatversion = 0
filemode = true
bare = true
sharedrepository = 1
[gitcvs]
enabled = 1
logfile = /home/git/pl.git/cvs.log
allbinary = 1
----------------------------------------------------------------
> clients that have trouble accessing repository, and what protocol
> (transport merhod) do they use: "file", http(s)/ftp, git, ssh?
I could reproduce the problem using the same git that maintains the bare
repository, which started as git-1.5.3.4 and is now 1.5.6.rc3. It
reproduces both using local file access and ssh. Other people have a
variety of versions. I know of concrete problems using the stable 1.5.5
over ssh.
The problem that I can't even clone is indeed after running a git-gc.
So, now I have all branch head refs double (in packed-refs and in
refs/heads). That explains ar least where they come from, but it fails
to explain why doing exactly the same using the same git on the same
repo as two users yields a different result. Of course, besides the
desire to understand how his works, I'm mostly interested in how to fix
this :-)
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH] Don't cut off last character of commit descriptions.
From: David Kågedal @ 2008-06-30 10:55 UTC (permalink / raw)
To: git, Nikolaj Schumacher
In-Reply-To: <m2abh3z14f.fsf@nschum.de>
Nikolaj Schumacher <n_schumacher@web.de> writes:
> From d485d9c86cba49671b74c7c1571a6ad7ec6d09b6 Mon Sep 17 00:00:00 2001
> From: Nikolaj Schumacher <git@nschum.de>
> Date: Mon, 30 Jun 2008 12:06:01 +0200
> Subject: [PATCH] Don't cut off last character of commit descriptions.
>
> ---
> contrib/emacs/git-blame.el | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
> index 9f92cd2..4fa70c5 100644
> --- a/contrib/emacs/git-blame.el
> +++ b/contrib/emacs/git-blame.el
> @@ -381,7 +381,7 @@ See also function `git-blame-mode'."
> "log" "-1"
> (concat "--pretty=" git-blame-log-oneline-format)
> hash)
> - (buffer-substring (point-min) (1- (point-max)))))
> + (buffer-substring (point-min) (point-max))))
>
> (defvar git-blame-last-identification nil)
> (make-variable-buffer-local 'git-blame-last-identification)
Yes, this should have been part of
24a2293ad35d567530048f0d2b0d11e0012af26d git-blame.el: show the when,
who and what in the minibuffer. that changed from using
--pretty=oneline to --pretty=format:... without terminating newline.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH/RFC] git-blame.el: Use eldoc-mode to display current commit.
From: David Kågedal @ 2008-06-30 10:47 UTC (permalink / raw)
To: git, Nikolaj Schumacher
In-Reply-To: <m2ej6fz1lv.fsf@nschum.de>
Nikolaj Schumacher <n_schumacher@web.de> writes:
> I think this is a better way to display the current commit. However,
> I'm not sure whether to rely on eldoc, or create my own timer.
Yes, maybe it is better to use a timer. But you should definitively
create a new timer, it isn't hard.
--
David Kågedal
^ permalink raw reply
* How to reduce remaining differences to 4msysgit? (was What's cooking in git.git (topics))
From: Steffen Prohaska @ 2008-06-30 11:19 UTC (permalink / raw)
To: msysGit, Junio C Hamano, Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <7v3amv1e8n.fsf@gitster.siamese.dyndns.org>
On Jun 30, 2008, at 11:08 AM, Junio C Hamano wrote:
> * MinGW will be in.
If this is done, we should be able to create the msysgit release
directly
from Junio's master. Hannes changes alone, however, are not sufficient,
because some commits have been parked in 4msysgit. Now that MinGW is
on Junio's next and Junio's next is also on 4msysgit's next, it it easy
to see how much is left to do by running:
git diff --stat junio/next..4msysgit/next
junio is a remote pointing to git://git.kernel.org/pub/scm/git/git.git.
4msysgit is a remote pointing to git://repo.or.cz/git/mingw/
4msysgit.git.
I attached the output below.
How should we proceed to get rid of the differences?
Should we prepare and send patches directly to the official git list
now?
Should we wait until the first MinGW branch is on master?
Should we prepare a whole patch series? Maybe Hannes would maintain
this
patch series.
I have not yet looked at the remaining differences in detail. I expect
most of them to be trivial. But some might require discussion on the
list, so at some point we should send the patches to the official list.
Steffen
$ git diff --stat junio/next..4msysgit/next
Makefile | 23 ++-
README.MinGW | 77 ++++++++
RelNotes | 1 -
builtin-fetch-pack.c | 3 +-
builtin-tag.c | 14 ++
builtin-verify-tag.c | 2 +
cache.h | 2 +
check-builtins.sh | 2 +-
compat/mingw.c | 4 +-
compat/winansi.c | 309 +++++++++++++++++++++++
+++++++++
connect.c | 5 +-
convert.c | 4 +
fast-import.c | 2 +
git-add--interactive.perl | 2 +-
git-compat-util.h | 7 +
git-parse-remote.sh | 3 +-
gitk-git/Makefile | 4 +
gitk-git/gitk | 2 +
help.c | 30 +++-
path.c | 13 ++
read-cache.c | 5 +
setup.c | 7 +-
t/t0000-basic.sh | 31 +++-
t/t0001-init.sh | 2 +-
t/t0004-unwritable.sh | 7 +
t/t1002-read-tree-m-u-2way.sh | 6 +
t/t1003-read-tree-prefix.sh | 4 +
t/t1004-read-tree-m-u-wf.sh | 2 +
t/t1300-repo-config.sh | 1 +
t/t1301-shared-repo.sh | 4 +
t/t2001-checkout-cache-clash.sh | 2 +
t/t2003-checkout-cache-mkdir.sh | 4 +
t/t2004-checkout-cache-temp.sh | 2 +
t/t2007-checkout-symlink.sh | 7 +
t/t2100-update-cache-badpath.sh | 2 +
t/t2201-add-update-typechange.sh | 11 +-
t/t3000-ls-files-others.sh | 1 +
t/t3010-ls-files-killed-modified.sh | 7 +
t/t3100-ls-tree-restrict.sh | 12 ++
t/t3200-branch.sh | 2 +
t/t3700-add.sh | 10 +
t/t3901-i18n-patch.sh | 4 +
t/t3903-stash.sh | 12 +-
t/t4004-diff-rename-symlink.sh | 7 +
t/t4008-diff-break-rewrite.sh | 4 +
t/t4011-diff-symlink.sh | 7 +
t/t4023-diff-rename-typechange.sh | 5 +
t/t4109-apply-multifrag.sh | 4 +
t/t4110-apply-scan.sh | 4 +
t/t4114-apply-typechange.sh | 5 +
t/t4115-apply-symlink.sh | 7 +
t/t4116-apply-reverse.sh | 3 +-
t/t4122-apply-symlink-inside.sh | 7 +
t/t4150-am.sh | 6 +-
t/t5000-tar-tree.sh | 7 +
t/t5300-pack-object.sh | 62 +++----
t/t5502-quickfetch.sh | 3 +
t/t5503-tagfollow.sh | 25 +++-
t/t5505-remote.sh | 3 +
t/t5511-refspec.sh | 11 +-
t/t5512-ls-remote.sh | 3 +
t/t5520-pull.sh | 1 +
t/t5530-upload-pack-error.sh | 1 +
t/t7004-tag.sh | 5 +-
t/t7005-editor.sh | 1 +
t/t7201-co.sh | 6 +-
t/t7401-submodule-summary.sh | 30 ++--
t/t7501-commit.sh | 1 +
t/t7502-status.sh | 4 +
t/t7503-pre-commit-hook.sh | 6 +
t/t7504-commit-msg-hook.sh | 6 +
t/t9001-send-email.sh | 4 +
t/t9200-git-cvsexportcommit.sh | 4 +
t/t9500-gitweb-standalone-no-errors.sh | 3 +
t/test-lib.sh | 17 ++
templates/Makefile | 3 +
utf8.c | 7 +
utf8.h | 4 -
78 files changed, 844 insertions(+), 86 deletions(-)
^ permalink raw reply
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jakub Narebski @ 2008-06-30 11:26 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200806301230.38980.J.Wielemaker@uva.nl>
Jan Wielemaker wrote:
> On Monday 30 June 2008 12:10, Jakub Narebski wrote:
>> Jan Wielemaker <J.Wielemaker@uva.nl> writes:
>>>
>>> I'm a bit puzzled. I have a bare repository, somehow without any files
>>> in refs/heads.
>>
>> Do you have .git/packed-refs file?
>
> Its a bare repo, so I'll forget the .git. Yes, I have that file and
> it contains nice references, I checked a few by hand, and they have
> the same SHA1 as the files I copied.
That is where the refs are instead of being in individual files under
refs/ - those are so called "packed refs".
When a ref is missing from the traditional $GIT_DIR/refs hierarchy,
it is looked up in $GIT_DIR/packed-refs and used if found.
I'm not sure why branches are also packed, because git used to pack
only tags and refs which were packed already.
>> How do you have gc.packrefs set ("git config --get gc.packrefs")?
>
> This gives no output, so I guess the answer is 'no'.
In git-config(1) you can find the following:
gc.packrefs::
`git gc` does not run `git pack-refs` in a bare repository by
default so that older dumb-transport clients can still fetch
from the repository. Setting this to `true` lets `git
gc` to run `git pack-refs`. Setting this to `false` tells
`git gc` never to run `git pack-refs`. The default setting is
`notbare`. Enable it only when you know you do not have to
support such clients. The default setting will change to `true`
at some stage, and setting this to `false` will continue to
prevent `git pack-refs` from being run from `git gc`.
Unless something changed (and git Documentation was not updated) git
should not pack refs by default.
>> What are the git version on the
>> clients that have trouble accessing repository, and what protocol
>> (transport method) do they use: "file", http(s)/ftp, git, ssh?
>
> I could reproduce the problem using the same git that maintains the bare
> repository, which started as git-1.5.3.4 and is now 1.5.6.rc3. It
> reproduces both using local file access and ssh. Other people have a
> variety of versions. I know of concrete problems using the stable 1.5.5
> over ssh.
>
> The problem that I can't even clone is indeed after running a git-gc.
Hmmm... strange. I know that there can be problems with older clients
(those which do not understand packed-refs format) accessing
repositories with packed refs (without loose refs) via "dumb"
protocols. Problems with accessing repositories locally and via ssh
might point to some troubles with permissions and ownership of
$GIT_DIR and $GIT_DIR/packed-refs.
git-gc can pack refs, that is what running it causes problems.
> So, now I have all branch head refs double (in packed-refs and in
> refs/heads). That explains ar least where they come from, but it fails
> to explain why doing exactly the same using the same git on the same
> repo as two users yields a different result. Of course, besides the
> desire to understand how his works, I'm mostly interested in how to fix
> this :-)
Unfortunately as it is not caused by the issue I thought about I cannot
help you further...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Johannes Schindelin @ 2008-06-30 11:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Pieter de Bie, Git Mailinglist
In-Reply-To: <7vwsk730mm.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 29 Jun 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sun, 29 Jun 2008, Daniel Barkalow wrote:
> >
> >> Did we even make a commitment on whether:
> >>
> >> GIT_CONFIG=foo git clone bar
> >>
> >> must ignore the environment variable, or simply doesn't necessarily
> >> obey it?
> >
> > I'd rather strongly argue that no matter what is the answer to this
> > question, we _HAVE TO_ unsetenv() GIT_CONFIG at some stage, otherwise
> > no .git/config will be written.
> >
> > So, this is a NACK on your patch.
>
> True. We are creating the config file for the new repository, so the
> initial setenv() would make sense. We _could_ save away end user's
> GIT_CONFIG and restore it where you unsetenv() in your patch,
No. That would break again, since then,
- $HOME/.gitconfig would be ignored again (which was the single issue my
patch addressed), and
- the remote information would be written into the wrong file.
Ciao,
Dscho
^ permalink raw reply
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jan Wielemaker @ 2008-06-30 11:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200806301326.12140.jnareb@gmail.com>
Hi Jakub,
Summarising, I think the conclusion is that git pack-refs has somehow
been run on this repository, and being a bare one this is not a
particulary good idea right now. I have the impression I should `unpack'
them by putting the appriate files in heads (done) and tags (now still)
and (re)move packed-refs.
Cheers --- Jan
On Monday 30 June 2008 13:26, Jakub Narebski wrote:
> Jan Wielemaker wrote:
> > On Monday 30 June 2008 12:10, Jakub Narebski wrote:
> >> Jan Wielemaker <J.Wielemaker@uva.nl> writes:
> >>> I'm a bit puzzled. I have a bare repository, somehow without any files
> >>> in refs/heads.
> >>
> >> Do you have .git/packed-refs file?
> >
> > Its a bare repo, so I'll forget the .git. Yes, I have that file and
> > it contains nice references, I checked a few by hand, and they have
> > the same SHA1 as the files I copied.
>
> That is where the refs are instead of being in individual files under
> refs/ - those are so called "packed refs".
>
> When a ref is missing from the traditional $GIT_DIR/refs hierarchy,
> it is looked up in $GIT_DIR/packed-refs and used if found.
>
> I'm not sure why branches are also packed, because git used to pack
> only tags and refs which were packed already.
>
> >> How do you have gc.packrefs set ("git config --get gc.packrefs")?
> >
> > This gives no output, so I guess the answer is 'no'.
>
> In git-config(1) you can find the following:
>
> gc.packrefs::
> `git gc` does not run `git pack-refs` in a bare repository by
> default so that older dumb-transport clients can still fetch
> from the repository. Setting this to `true` lets `git
> gc` to run `git pack-refs`. Setting this to `false` tells
> `git gc` never to run `git pack-refs`. The default setting is
> `notbare`. Enable it only when you know you do not have to
> support such clients. The default setting will change to `true`
> at some stage, and setting this to `false` will continue to
> prevent `git pack-refs` from being run from `git gc`.
>
> Unless something changed (and git Documentation was not updated) git
> should not pack refs by default.
>
> >> What are the git version on the
> >> clients that have trouble accessing repository, and what protocol
> >> (transport method) do they use: "file", http(s)/ftp, git, ssh?
> >
> > I could reproduce the problem using the same git that maintains the bare
> > repository, which started as git-1.5.3.4 and is now 1.5.6.rc3. It
> > reproduces both using local file access and ssh. Other people have a
> > variety of versions. I know of concrete problems using the stable 1.5.5
> > over ssh.
> >
> > The problem that I can't even clone is indeed after running a git-gc.
>
> Hmmm... strange. I know that there can be problems with older clients
> (those which do not understand packed-refs format) accessing
> repositories with packed refs (without loose refs) via "dumb"
> protocols. Problems with accessing repositories locally and via ssh
> might point to some troubles with permissions and ownership of
> $GIT_DIR and $GIT_DIR/packed-refs.
>
> git-gc can pack refs, that is what running it causes problems.
>
> > So, now I have all branch head refs double (in packed-refs and in
> > refs/heads). That explains ar least where they come from, but it fails
> > to explain why doing exactly the same using the same git on the same
> > repo as two users yields a different result. Of course, besides the
> > desire to understand how his works, I'm mostly interested in how to fix
> > this :-)
>
> Unfortunately as it is not caused by the issue I thought about I cannot
> help you further...
^ permalink raw reply
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Björn Steinbrink @ 2008-06-30 11:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jan Wielemaker, git
In-Reply-To: <200806301326.12140.jnareb@gmail.com>
On 2008.06.30 13:26:10 +0200, Jakub Narebski wrote:
> Jan Wielemaker wrote:
> > On Monday 30 June 2008 12:10, Jakub Narebski wrote:
> >> Jan Wielemaker <J.Wielemaker@uva.nl> writes:
> >>>
> >>> I'm a bit puzzled. I have a bare repository, somehow without any files
> >>> in refs/heads.
> >>
> >> Do you have .git/packed-refs file?
> >
> > Its a bare repo, so I'll forget the .git. Yes, I have that file and
> > it contains nice references, I checked a few by hand, and they have
> > the same SHA1 as the files I copied.
>
> That is where the refs are instead of being in individual files under
> refs/ - those are so called "packed refs".
>
> When a ref is missing from the traditional $GIT_DIR/refs hierarchy,
> it is looked up in $GIT_DIR/packed-refs and used if found.
>
> I'm not sure why branches are also packed, because git used to pack
> only tags and refs which were packed already.
>
> >> How do you have gc.packrefs set ("git config --get gc.packrefs")?
> >
> > This gives no output, so I guess the answer is 'no'.
>
> In git-config(1) you can find the following:
>
> gc.packrefs::
> `git gc` does not run `git pack-refs` in a bare repository by
> default so that older dumb-transport clients can still fetch
> from the repository. Setting this to `true` lets `git
> gc` to run `git pack-refs`. Setting this to `false` tells
> `git gc` never to run `git pack-refs`. The default setting is
> `notbare`. Enable it only when you know you do not have to
> support such clients. The default setting will change to `true`
> at some stage, and setting this to `false` will continue to
> prevent `git pack-refs` from being run from `git gc`.
>
> Unless something changed (and git Documentation was not updated) git
> should not pack refs by default.
I had a quick glance over the log for builtin-gc.c, and that changed
last year in:
56752391 Make "git gc" pack all refs by default
Björn - who lacks time to provide a doc update patch :-(
^ permalink raw reply
* Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig
From: Johannes Schindelin @ 2008-06-30 11:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Pieter de Bie, Git Mailinglist
In-Reply-To: <alpine.LNX.1.00.0806292320300.19665@iabervon.org>
Hi,
On Sun, 29 Jun 2008, Daniel Barkalow wrote:
> Now, clone writes to the config file before reading any configuration, so,
> if it's going to write to ".git/config" instead of $GIT_CONFIG, it can't
> read from $GIT_CONFIG either. So there's no way (outside of redesigning
> config.c) to make GIT_CONFIG useful for "clone" in particular.
Except you could read the config _before_ writing.
Or you could enhance (not redesign, as you suggest) config.c thusly:
-- snip --
diff --git a/cache.h b/cache.h
index 871f6c1..f3ea997 100644
--- a/cache.h
+++ b/cache.h
@@ -742,6 +742,7 @@ extern int git_config_bool(const char *, const char *);
extern int git_config_string(const char **, const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
+extern int git_config_set_multivar_in_file(const char *, const char *, const char *, int, const char *);
extern int git_config_rename_section(const char *, const char *);
extern const char *git_etc_gitconfig(void);
extern int check_repository_format_version(const char *var, const char *value, void *cb);
diff --git a/config.c b/config.c
index 58749bf..41a35eb 100644
--- a/config.c
+++ b/config.c
@@ -863,23 +863,31 @@ int git_config_set(const char* key, const char* value)
* - the config file is removed and the lock file rename()d to it.
*
*/
-int git_config_set_multivar(const char* key, const char* value,
- const char* value_regex, int multi_replace)
+int git_config_set_multivar(const char *key, const char *value,
+ const char *value_regex, int multi_replace)
+{
+ return git_config_set_multivar_in_file(key, value, value_regex,
+ multi_replace, NULL);
+}
+
+int git_config_set_multivar_in_file(const char *key, const char *value,
+ const char *value_regex, int multi_replace, const char *config_filename)
{
int i, dot;
int fd = -1, in_fd;
int ret;
- char* config_filename;
+ char *filename;
struct lock_file *lock = NULL;
const char* last_dot = strrchr(key, '.');
- config_filename = getenv(CONFIG_ENVIRONMENT);
+ if (!config_filename)
+ config_filename = getenv(CONFIG_ENVIRONMENT);
if (!config_filename) {
config_filename = getenv(CONFIG_LOCAL_ENVIRONMENT);
if (!config_filename)
- config_filename = git_path("config");
+ config_filename =
+ filename = xstrdup(git_path("config"));
}
- config_filename = xstrdup(config_filename);
/*
* Since "key" actually contains the section name and the real
@@ -1091,7 +1099,8 @@ int git_config_set_multivar(const char* key, const char* value,
out_free:
if (lock)
rollback_lock_file(lock);
- free(config_filename);
+ if (filename)
+ free(filename);
return ret;
write_err_out:
-- snap --
... and then have something like
config_filename = xstrdup(mkpath("%s/config", git_dir));
if (safe_create_leading_directories_const(git_dir) < 0)
die("could not create leading directories of '%s'", git_dir);
set_git_dir(make_absolute_path(git_dir));
[...]
if (option_bare) {
strcpy(branch_top, "refs/heads/");
git_config_set_multivar_in_file("core.bare", "true",
NULL, 0, config_filename);
[...]
Of course, you would also have to teach init_db() to use this filename.
But frankly, I do not see the use of your "narrow" special case. And as I
stated in another thread, I am pretty opposed to crossing bridges that are
miles (or an eternity) away.
So unless you present me with a sensible scenario where your "respect
GIT_CONFIG for _reading_ in GIT_CONFIG=... git clone" makes sense, there
is nothing to see here, please move along.
Ciao,
Dscho
^ permalink raw reply related
* Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
From: Jakub Narebski @ 2008-06-30 12:03 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200806301344.09938.J.Wielemaker@uva.nl>
Jan Wielemaker wrote:
> Summarising, I think the conclusion is that git pack-refs has somehow
> been run on this repository, and being a bare one this is not a
> particulary good idea right now. I have the impression I should `unpack'
> them by putting the appriate files in heads (done) and tags (now still)
> and (re)move packed-refs.
If you use new enough git both on server and on clients it should
not have problems with packed-refs. I would rather check permissions
of $GIT_DIR and $GIT_DIR/packed-refs.
If "git show-ref" and "git for-each-ref" works, then
"git ls-remote <repo>" should work, and git-fetch/git-clone
shoulw work too...
--
Jakub Narebski
Poland
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox