Re: [PATCH] completion: fix completion of certain aliases
Hi,
On Sat, Dec 07, 2013 at 07:11:13AM -0600, Felipe Contreras wrote:
Some commands need the first word to determine the actual action that is
being executed, however, the command is wrong when we use an alias,
This first sentence was hard to understand for me because of the wrong
terminology used. How about this instead:
Some completion helper functions need to know the name of the git
command to act properly. However, ...
for
example 'alias.p=push', if we try to complete 'git p origin ', the
result would be wrong because __git_complete_remote_or_refspec() doesn't
know where it come from.
Are there other helper functions that are affected? After a quick
glance I didn't find any. In this case we could even write the above
as
The __git_complete_remote_or_refspec() completion helper function
needs to know ...
So let's override words[1], so the alias 'p' is override by the actual
command, 'push'.
words[1] is not always the name of the git command, it can also be an
option to the main git command, e.g. in case of 'git -c key=value push
...' with this patch '-c' would be overwritten.
Best,
Gábor
Reported-by: Aymeric Beaumet aymeric.beau...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 1 +
contrib/completion/git-completion.zsh | 1 +
2 files changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index dba3c15..c14bac4 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2530,6 +2530,7 @@ __git_main ()
local expansion=$(__git_aliased_command $command)
if [ -n $expansion ]; then
+ words[1]=$expansion
completion_func=_git_${expansion//-/_}
declare -f $completion_func /dev/null $completion_func
fi
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index fac5e71..3eeb7f8 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -96,6 +96,7 @@ __git_zsh_bash_func ()
local expansion=$(__git_aliased_command $command)
if [ -n $expansion ]; then
+ words[1]=$expansion
completion_func=_git_${expansion//-/_}
declare -f $completion_func /dev/null $completion_func
fi
--
1.8.4.2+fc1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/POC 1/7] Make git_path() beware of file relocation in $GIT_DIR
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+static void adjust_git_path(char *buf, int git_dir_len)
+{
+ /* XXX buffer overflow */
+ char *base = buf + git_dir_len;
+ if (git_graft_env !strcmp(base, info/grafts))
+ strcpy(buf, get_graft_file());
+ else if (git_index_env !strcmp(base, index))
+ strcpy(buf, get_index_file());
+ else if (git_db_env dir_prefix(base, objects))
+ replace_dir(buf, git_dir_len + 7, get_object_directory());
+}
+
static char *vsnpath(char *buf, size_t n, const char *fmt, va_list args)
{
const char *git_dir = get_git_dir();
- size_t len;
+ size_t len, total_len;
len = strlen(git_dir);
if (n len + 1)
@@ -60,9 +88,10 @@ static char *vsnpath(char *buf, size_t n, const char *fmt,
va_list args)
memcpy(buf, git_dir, len);
if (len !is_dir_sep(git_dir[len-1]))
buf[len++] = '/';
- len += vsnprintf(buf + len, n - len, fmt, args);
- if (len = n)
+ total_len = len + vsnprintf(buf + len, n - len, fmt, args);
+ if (total_len = n)
goto bad;
+ adjust_git_path(buf, len);
This is a minor tangent, but this part of the patch made me raise my
eyebrow, wondering what Git-specific path mangler is doing in a
function vsnpath that is named as if it is a lot more generic, until
I read the change in context.
The vnspath() is already Git-specific---it is a helper that is used
to create a path inside the $GIT_DIR directory.
We probably should do two things to clear things up:
- Right now, path.c has definitions of functions in this order:
char *mksnpath(char *buf, size_t n, const char *fmt, ...)
static char *vsnpath(char *buf, size_t n, const char *fmt, va_list args)
char *git_snpath(char *buf, size_t n, const char *fmt, ...)
char *git_pathdup(const char *fmt, ...)
char *mkpathdup(const char *fmt, ...)
char *mkpath(const char *fmt, ...)
char *git_path(const char *fmt, ...)
The two functions mkpathdup() and mkpath() are not Git specific
at all. They should be moved up to be grouped together with
mksnpath() that is also not Git-specific.
- Rename the static vsnpath() to further clarify that it is Git
specific.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] remote-hg: fix 'shared path' path
On Sat, Dec 7, 2013 at 2:09 PM, Felipe Contreras felipe.contre...@gmail.com wrote: If the repository is moved, the absolute path of the shared repository would fail. Make sure it's always up-to-date. Reported-by: Michael Davis mjmda...@gmail.com Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/remote-helpers/git-remote-hg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg index aa1d230..718ef95 100755 --- a/contrib/remote-helpers/git-remote-hg +++ b/contrib/remote-helpers/git-remote-hg @@ -416,6 +416,9 @@ def get_repo(url, alias): local_path = os.path.join(dirname, 'clone') if not os.path.exists(local_path): hg.share(myui, shared_path, local_path, update=False) +else: +# make sure the shared path is always up-to-date +util.writefile(os.path.join(local_path, '.hg', 'sharedpath'), hg_path) Considering this is modifying a private mercurial file, would it make sense to include a test like I did in my equivalent patch ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/POC 2/7] Add new environment variable $GIT_SUPER_DIR
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This is the base for git-new-workdir integration. The git-new-workdir
script creates a separate worktree that shares everything except
worktree-related stuff. The sharing is eanbled by this new env
variable.
In the new worktree, both variables are set at the same time, GIT_DIR
and GIT_SUPER_DIR. Shared paths are checked at adjust_git_path() and
rewritten to use $GIT_SUPER_DIR instead of $GIT_DIR. Let's call this
split-repo setup to distinguish from $GIT_DIR-only one.
The ln -s is avoided because Windows probably does not have the
support, and symlinks don't survive operations that delete the old
file, then create a new one.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h | 2 ++
environment.c | 11 +++--
path.c| 10
t/t0060-path-utils.sh | 67
+++
4 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index cdafbd7..823582f 100644
--- a/cache.h
+++ b/cache.h
@@ -347,6 +347,7 @@ static inline enum object_type object_type(unsigned int
mode)
/* Double-check local_repo_env below if you add to this list. */
#define GIT_DIR_ENVIRONMENT GIT_DIR
+#define GIT_SUPER_DIR_ENVIRONMENT GIT_SUPER_DIR
#define GIT_NAMESPACE_ENVIRONMENT GIT_NAMESPACE
#define GIT_WORK_TREE_ENVIRONMENT GIT_WORK_TREE
#define GIT_PREFIX_ENVIRONMENT GIT_PREFIX
@@ -399,6 +400,7 @@ extern int is_inside_git_dir(void);
extern char *git_work_tree_cfg;
extern int is_inside_work_tree(void);
extern const char *get_git_dir(void);
+extern const char *get_git_super_dir(void);
extern int is_git_directory(const char *path);
extern char *get_object_directory(void);
extern char *get_index_file(void);
diff --git a/environment.c b/environment.c
index 1d74dde..d5ae7a3 100644
--- a/environment.c
+++ b/environment.c
@@ -79,7 +79,7 @@ static char *work_tree;
static const char *namespace;
static size_t namespace_len;
-static const char *git_dir;
+static const char *git_dir, *git_super_dir;
static char *git_object_dir, *git_index_file, *git_graft_file;
int git_db_env, git_index_env, git_graft_env;
@@ -131,10 +131,12 @@ static void setup_git_env(void)
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
gitfile = read_gitfile(git_dir);
git_dir = xstrdup(gitfile ? gitfile : git_dir);
+ git_super_dir = getenv(GIT_SUPER_DIR_ENVIRONMENT);
git_object_dir = getenv(DB_ENVIRONMENT);
if (!git_object_dir) {
git_object_dir = xmalloc(strlen(git_dir) + 9);
- sprintf(git_object_dir, %s/objects, git_dir);
+ sprintf(git_object_dir, %s/objects,
+ git_super_dir ? git_super_dir : git_dir);
} else
git_db_env = 1;
git_index_file = getenv(INDEX_ENVIRONMENT);
@@ -167,6 +169,11 @@ const char *get_git_dir(void)
return git_dir;
}
+const char *get_git_super_dir(void)
+{
+ return git_super_dir;
+}
+
const char *get_git_namespace(void)
{
if (!namespace)
diff --git a/path.c b/path.c
index eda9176..86a7c15 100644
--- a/path.c
+++ b/path.c
@@ -75,6 +75,16 @@ static void adjust_git_path(char *buf, int git_dir_len)
strcpy(buf, get_index_file());
else if (git_db_env dir_prefix(base, objects))
replace_dir(buf, git_dir_len + 7, get_object_directory());
+ else if (get_git_super_dir()) {
+ if (dir_prefix(base, objects) || dir_prefix(base, info) ||
+ dir_prefix(base, refs) ||
+ (dir_prefix(base, logs) strcmp(base, logs/HEAD)) ||
+ dir_prefix(base, rr-cache) || dir_prefix(base, hooks) ||
+ dir_prefix(base, svn) ||
+ !strcmp(base, config) || !strcmp(base, packed-refs) ||
+ !strcmp(base, shallow))
+ replace_dir(buf, git_dir_len, get_git_super_dir());
+ }
This is essentially the list of what are shared across workdirs,
right? I wonder if it is a bad idea to make everything under .git
of the borrowed repository shared by default, with selected
exceptions. Granted, not sharing by default is definitely safer
than blindly sharing by default, so that alone may be a good
argument to use a set of known-to-be-safe-to-share paths, like this
code does.
Don't we want .git/branches and .git/remotes shared? After all,
their moral equivalents from .git/config are shared with the code.
The name super might need to be rethought, but getting the
mechanism and the semantics right is the more important first step,
and I think this is going in a good direction.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/POC 3/7] setup.c: add split-repo support to .git files
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: If a .git file contains gitsuper: path gitdir: id then we set GIT_SUPER_DIR to path and GIT_DIR to $GIT_SUPER_DIR/repos/id. I initially thought: what is with that complexity? isn't it just the matter of replacing 'gitdir: path' with 'gitsuper: path' stored in the file .git??? Until I realized that there is nowhere to keep per-workdir data if we only had .git as a pointer, and that is why you have that id thing. It would have helped me avoid that confusion if the above description was followed by: The latter, $GIT_SUPER_DIR/repos/id, is a directory, underneath which per-work-dir items like index, HEAD, logs/HEAD (what else?) reside. or something like that. And $GIT_SUPER_DIR/repos/*/HEAD, especially when they are detached, plus $GIT_SUPER_DIR/repos/*/index, will work as the starting point of object reachability scanning when running repack, fsck, etc. A few more random thoughts... - Reusing gitdir: for this purpose is not advisable; use a different name. This id is used to identify a workdir, so perhaps gitworkdir: id might be a better name; - Do we want to record where the working tree directory is in $GIT_SUPER_DIR/repos/id somewhere? Would it help to have such a record? - How would this interact with core.worktree in .git/config of that super repository? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitk: Comply with XDG base directory specification
Write the gitk config data to $XDG_CONFIG_HOME/git/gitk ($HOME/.config/git/gitk
by default) in line with the XDG specification. This makes it consistent with
git which also follows the spec.
If $HOME/.gitk already exists use that for backward compatibility, so only new
installations are affected.
Signed-off-by: Astril Hayato astrilhay...@gmail.com
---
gitk | 33 -
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/gitk b/gitk
index 33c3a6c..34dd4a6 100755
--- a/gitk
+++ b/gitk
@@ -2761,14 +2761,17 @@ proc savestuff {w} {
global linkfgcolor circleoutlinecolor
global autoselect autosellen extdifftool perfile_attrs markbgcolor use_ttk
global hideremotes want_ttk maxrefs
+global config_file config_file_tmp
if {$stuffsaved} return
if {![winfo viewable .]} return
catch {
- if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
- set f [open ~/.gitk-new w]
+ if {[file exists $config_file_tmp]} {
+ file delete -force $config_file_tmp
+ }
+ set f [open $config_file_tmp w]
if {$::tcl_platform(platform) eq {windows}} {
- file attributes ~/.gitk-new -hidden true
+ file attributes $config_file_tmp -hidden true
}
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
@@ -2845,7 +2848,7 @@ proc savestuff {w} {
}
puts $f }
close $f
- file rename -force ~/.gitk-new ~/.gitk
+ file rename -force $config_file_tmp $config_file
}
set stuffsaved 1
}
@@ -12058,7 +12061,27 @@ namespace import ::msgcat::mc
## And eventually load the actual message catalog
::msgcat::mcload $gitk_msgsdir
-catch {source ~/.gitk}
+catch {
+# follow the XDG base directory specification by default. See
+# http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
+if {[info exists env(XDG_CONFIG_HOME)] $env(XDG_CONFIG_HOME) ne } {
+ # XDG_CONFIG_HOME environment variable is set
+ set config_file [file join $env(XDG_CONFIG_HOME) git gitk]
+ set config_file_tmp [file join $env(XDG_CONFIG_HOME) git gitk-tmp]
+} else {
+ # default XDG_CONFIG_HOME
+ set config_file ~/.config/git/gitk
+ set config_file_tmp ~/.config/git/gitk-tmp
+}
+if {![file exists $config_file]} {
+ if {![file exists [file dirname $config_file]]} {
+ file mkdir [file dirname $config_file]
+ }
+ # for backward compatability use the old config file if it exists
+ if {[file exists ~/.gitk]} {set config_file ~/.gitk}
+}
+source $config_file
+}
parsefont mainfont $mainfont
eval font create mainfont [fontflags mainfont]
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] contrib/git-credential-gnome-keyring.c: small stylistic cleanups
Junio C Hamano gits...@pobox.com writes:
John Szakmeister j...@szakmeister.net writes:
On Mon, Dec 9, 2013 at 1:06 PM, Junio C Hamano gits...@pobox.com wrote:
[snip]
I thought we cast without SP after the (typename), i.e.
gpointer *data = (gpointer *)user_data;
I've found a mixture of both in the code base, and the
CodingGuidelines doesn't say either way. I'm happy to switch the file
to no SP after the typename if that's the project preference.
Somewhat arbitrary and unscientific, but between
git grep -e '[^f]([a-z_ ]* \*)[^ ]' -- \*.c | wc -l
422
$ git grep -e '[^f]([a-z_ ]* \*) ' -- \*.c | wc -l
233
I see that we favor (struct blah *)apointer over (int *)
apointer. Many hits in the latter grep come from compat/
that are borrowed pieces of code we tend not to style-fix.
The leading [^f] is crudely excludes sizeof(typename *); it does
not change the resulting picture in a major way, though.
Thanks.
Here is a squashable diff on top of your clean-up:
* A few more violations of the same asterisk sticks to what is the
pointer, not the name of the type;
* No SP between (typename) and castee;
* Opening parenthesis of struct/union name comes on the same line
as the struct/union keyword;
* Opening parenthesis of structured statements e.g. if/while/for/...
comes on the same line as the starting keyword;
* Body of structured controls e.g. if/while/... on a separate line.
I may have caught all of them, but I wasn't trying to be super
careful, so...
diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
index 1613404..d45503c 100644
--- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
+++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
@@ -60,7 +60,7 @@
#define gnome_keyring_memory_free gnome_keyring_free_password
#define gnome_keyring_memory_strdup g_strdup
-static const char* gnome_keyring_result_to_message(GnomeKeyringResult result)
+static const char *gnome_keyring_result_to_message(GnomeKeyringResult result)
{
switch (result) {
case GNOME_KEYRING_RESULT_OK:
@@ -95,9 +95,9 @@ static const char*
gnome_keyring_result_to_message(GnomeKeyringResult result)
static void gnome_keyring_done_cb(GnomeKeyringResult result, gpointer
user_data)
{
- gpointer *data = (gpointer *) user_data;
- int *done = (int *) data[0];
- GnomeKeyringResult *r = (GnomeKeyringResult *) data[1];
+ gpointer *data = (gpointer *)user_data;
+ int *done = (int *)data[0];
+ GnomeKeyringResult *r = (GnomeKeyringResult *)data[1];
*r = result;
*done = 1;
@@ -130,8 +130,7 @@ static GnomeKeyringResult
gnome_keyring_item_delete_sync(const char *keyring, gu
/*
* This credential struct and API is simplified from git's credential.{h,c}
*/
-struct credential
-{
+struct credential {
char *protocol;
char *host;
unsigned short port;
@@ -144,8 +143,7 @@ struct credential
typedef int (*credential_op_cb)(struct credential *);
-struct credential_operation
-{
+struct credential_operation {
char *name;
credential_op_cb op;
};
@@ -155,7 +153,7 @@ struct credential_operation
/* - GNOME Keyring functions - */
/* create a special keyring option string, if path is given */
-static char* keyring_object(struct credential *c)
+static char *keyring_object(struct credential *c)
{
if (!c-path)
return NULL;
@@ -168,7 +166,7 @@ static char* keyring_object(struct credential *c)
static int keyring_get(struct credential *c)
{
- char* object = NULL;
+ char *object = NULL;
GList *entries;
GnomeKeyringNetworkPasswordData *password_data;
GnomeKeyringResult result;
@@ -202,7 +200,7 @@ static int keyring_get(struct credential *c)
}
/* pick the first one from the list */
- password_data = (GnomeKeyringNetworkPasswordData *) entries-data;
+ password_data = (GnomeKeyringNetworkPasswordData *)entries-data;
gnome_keyring_memory_free(c-password);
c-password = gnome_keyring_memory_strdup(password_data-password);
@@ -302,7 +300,7 @@ static int keyring_erase(struct credential *c)
}
/* pick the first one from the list (delete all matches?) */
- password_data = (GnomeKeyringNetworkPasswordData *) entries-data;
+ password_data = (GnomeKeyringNetworkPasswordData *)entries-data;
result = gnome_keyring_item_delete_sync(
password_data-keyring, password_data-item_id);
@@ -355,12 +353,11 @@ static int credential_read(struct credential *c)
key = buf = gnome_keyring_memory_alloc(1024);
- while (fgets(buf, 1024, stdin))
- {
+ while (fgets(buf, 1024, stdin)) {
line_len = strlen(buf);
if (line_len buf[line_len-1] ==
Re: [PATCH/POC 3/7] setup.c: add split-repo support to .git files
Junio C Hamano wrote: - Do we want to record where the working tree directory is in $GIT_SUPER_DIR/repos/id somewhere? Would it help to have such a record? That could be nice for the purpose of garbage collecting them. I fear that for users it is too tempting to remove a worktree with rm -rf without considering the relationship from the parent repo that might be making walking through all reflogs slower or holding on to objects no one cares about any more. I imagine it would work like this: 1. At worktree creation time, full path to the working tree directory is stored in $GIT_SUPER_DIR/repos/id. 2. git gc notices that the worktree is missing and writes a file under $GIT_SUPER_DIR/repos/id with a timestamp, saying so. 3. If the worktree still hasn't existed for a month, git gc deletes the corresponding $GIT_SUPER_DIR/repos/id directory. Problems: * What if I move my worktree with mv? Then I still need the corresponding $GIT_SUPER_DIR/repos/id directory, and nobody told the GIT_SUPER_DIR about it. * What if my worktree is on removable media (think network filesystem) and has just been temporarily unmounted instead of deleted? So maybe it would be nicer to: i. When the worktree is on the same filesystem, keep a *hard link* to some file in the worktree (e.g., the .git file). If the link count goes down, it is safe to remove the $GIT_SUPER_DIR/repos/id directory. ii. When the worktree is on another filesystem, always keep $GIT_SUPER_DIR/repos/id unless the user decides to manually remove it. Provide documentation or a command to list basic information about $GIT_SUPER_DIR/repos directories (path to worktree, what branch they're on, etc). (i) doesn't require any futureproofing. As soon as someone wants it, they can implement the check and fall back to (ii) for worktrees without the magic hard link. (ii) would benefit from recording the working tree directory as a possibly unreliable, human-friendly reminder. - How would this interact with core.worktree in .git/config of that super repository? Eek. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Dec 2013, #03; Thu, 12)
Torsten Bögershausen tbo...@web.de writes: On 12/13/2013 01:57 AM, Junio C Hamano wrote: [Cooking] * fc/transport-helper-fixes (2013-12-09) 6 commits - remote-bzr: support the new 'force' option - test-hg.sh: tests are now expected to pass - transport-helper: check for 'forced update' message - transport-helper: add 'force' to 'export' helpers - transport-helper: don't update refs in dry-run - transport-helper: mismerge fix Updates transport-helper, fast-import and fast-export to allow the ref mapping and ref deletion in a way similar to the natively supported transports. Will merge to 'next'. This breaks t5541, (at least on my systems, both Linux and Mac OS) Thanks for stopping me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] send-pack.c: mark a file-local function static
On 13/12/13 00:58, Duy Nguyen wrote: On Fri, Dec 13, 2013 at 6:15 AM, Ramsay Jones ram...@ramsay1.demon.co.uk wrote: BTW, I have not been following these patches, but I noticed that the 'remove_nonexistent_ours_in_pack()' function has no callers. (There are two commented out callers - but they seem to have *always* been commented out ;-) ). So, step 5 is no longer required? :-D It's more of an optimization than a requirement, to avoid expensive calculation later. Uncommenting is possible but I need to pass the pack file name around a bit. Ah, OK. (I should probably refrain from commenting on code I haven't read ... :-P ) ATB, Ramsay Jones -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] diff: move no-index detection to builtin/diff.c
Hi,
Thomas Gummerer wrote:
Signed-off-by: Thomas Gummerer t.gumme...@gmail.com
Thanks, and sorry for the slow follow-up.
[...]
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -16,6 +16,9 @@
[...]
@@ -283,14 +286,57 @@ int cmd_diff(int argc, const char **argv, const char
*prefix)
* Other cases are errors.
*/
+ /* Were we asked to do --no-index explicitly? */
+ for (i = 1; i argc; i++) {
+ if (!strcmp(argv[i], --)) {
+ i++;
+ break;
+ }
+ if (!strcmp(argv[i], --no-index))
+ no_index = DIFF_NO_INDEX_EXPLICIT;
Neat.
[...]
+ /*
+ * Treat git diff with at least one path outside of the
+ * repo the same as if the command would have been executed
+ * outside of a git repository. In this case it behaves
+ * the same way as git diff --no-index a b, which acts
+ * as a colourful diff replacement.
+ */
+ if (nongit || ((argc == i + 2)
+(!path_inside_repo(prefix, argv[i]) ||
+ !path_inside_repo(prefix, argv[i + 1]
+ no_index = DIFF_NO_INDEX_IMPLICIT;
What happens if I run 'git diff --no-index /tmp git.c git.c' from
within a git repository? With this, I fear I will get
Not a git repository
To compare two paths outside a working tree:
usage: git diff [--no-index] path path
instead of the expected
usage: git diff --no-index path path
Something like
if (no_index)
;
else if (nongit)
no_index = DIFF_NO_INDEX_IMPLICIT;
else if (argc != i + 2)
;
else if (!path_inside_repo(prefix, argv[i]) ||
!path_inside_repo(prefix, argv[i + 1]))
no_index = DIFF_NO_INDEX_IMPLICIT;
should work. Or:
if (!no_index) {
/*
* Treat git diff with ...
*/
if (nongit || ...)
no_index = DIFF_NO_INDEX_IMPLICIT;
}
Or the '!no_index ' condition inserted some other way.
- /* If this is a no-index diff, just run it and exit there. */
- diff_no_index(rev, argc, argv, nongit, prefix);
+ if (no_index) {
+ if (argc != i + 2) {
[...]
+ /* Give the usage message for non-repository usage and
exit. */
+ usagef(git diff %s path path,
+no_index == DIFF_NO_INDEX_EXPLICIT ?
+ --no-index : [--no-index]);
+
+ }
+ /* If this is a no-index diff, just run it and exit there. */
+ diff_no_index(rev, argc, argv, prefix);
+ }
Perhaps, to avoid some nesting:
/* A no-index diff takes exactly two path arguments. */
if (no_index argc != i + 2) {
...
usagef(...);
}
if (no_index)
/* Just run the diff and exit. */
diff_no_index(...);
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] diff: don't read index when --no-index is given
Thomas Gummerer wrote: Also add a test to guard against future breakages, and a performance test to show the improvements. Very nice. Signed-off-by: Thomas Gummerer t.gumme...@gmail.com Reviewed-by: Jonathan Nieder jrnie...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/POC 2/7] Add new environment variable $GIT_SUPER_DIR
On Sat, Dec 14, 2013 at 1:12 AM, Junio C Hamano gits...@pobox.com wrote:
diff --git a/path.c b/path.c
index eda9176..86a7c15 100644
--- a/path.c
+++ b/path.c
@@ -75,6 +75,16 @@ static void adjust_git_path(char *buf, int git_dir_len)
strcpy(buf, get_index_file());
else if (git_db_env dir_prefix(base, objects))
replace_dir(buf, git_dir_len + 7, get_object_directory());
+ else if (get_git_super_dir()) {
+ if (dir_prefix(base, objects) || dir_prefix(base, info) ||
+ dir_prefix(base, refs) ||
+ (dir_prefix(base, logs) strcmp(base, logs/HEAD)) ||
+ dir_prefix(base, rr-cache) || dir_prefix(base, hooks)
||
+ dir_prefix(base, svn) ||
+ !strcmp(base, config) || !strcmp(base, packed-refs) ||
+ !strcmp(base, shallow))
+ replace_dir(buf, git_dir_len, get_git_super_dir());
+ }
This is essentially the list of what are shared across workdirs,
right? I wonder if it is a bad idea to make everything under .git
of the borrowed repository shared by default, with selected
exceptions. Granted, not sharing by default is definitely safer
than blindly sharing by default, so that alone may be a good
argument to use a set of known-to-be-safe-to-share paths, like this
code does.
The exception list could be equally long (most of them are *_HEAD).
.git is also used for temporary files with mkstemp, but I think that's
safe for sharing. What could break is when people add a new local
*_HEAD and forget to update the exception list.
Don't we want .git/branches and .git/remotes shared? After all,
their moral equivalents from .git/config are shared with the code.
Yes. I missed them.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/POC 3/7] setup.c: add split-repo support to .git files
On Sat, Dec 14, 2013 at 3:43 AM, Jonathan Nieder jrnie...@gmail.com wrote: Junio C Hamano wrote: - Do we want to record where the working tree directory is in $GIT_SUPER_DIR/repos/id somewhere? Would it help to have such a record? That could be nice for the purpose of garbage collecting them. I fear that for users it is too tempting to remove a worktree with rm -rf without considering the relationship from the parent repo that might be making walking through all reflogs slower or holding on to objects no one cares about any more. I imagine it would work like this: 1. At worktree creation time, full path to the working tree directory is stored in $GIT_SUPER_DIR/repos/id. 2. git gc notices that the worktree is missing and writes a file under $GIT_SUPER_DIR/repos/id with a timestamp, saying so. 3. If the worktree still hasn't existed for a month, git gc deletes the corresponding $GIT_SUPER_DIR/repos/id directory. I was thinking about doing something like this in git prune but manually. Your idea sounds nicer. Problems: * What if I move my worktree with mv? Then I still need the corresponding $GIT_SUPER_DIR/repos/id directory, and nobody told the GIT_SUPER_DIR about it. We could store $GIT_SUPER_DIR as relative path. That way if you move it, you break it. When you fix it, hopefully you remember to fix the link in repos/id too Alternatively, the setup up code could be taught to verify that $GIT_SUPER_DIR/repos/id/backlink actually points to the current worktree. If not warn the user or something * What if my worktree is on removable media (think network filesystem) and has just been temporarily unmounted instead of deleted? Or we keep update a timestamp in repos/id to note the last used time of this worktree. gc or prune would warn about unused repos after a certain amount of time, do not remove them automatically. This could be iii. to your list below. So maybe it would be nicer to: i. When the worktree is on the same filesystem, keep a *hard link* to some file in the worktree (e.g., the .git file). If the link count goes down, it is safe to remove the $GIT_SUPER_DIR/repos/id directory. This can still break with updating by creating a new version, then renaming it. Although I can't think why anybody (or anything) would want to do that on .git file. This does not work on Windows though. ii. When the worktree is on another filesystem, always keep $GIT_SUPER_DIR/repos/id unless the user decides to manually remove it. Provide documentation or a command to list basic information about $GIT_SUPER_DIR/repos directories (path to worktree, what branch they're on, etc). And on Windows, a new partition means a new drive, so it works there too. (i) doesn't require any futureproofing. As soon as someone wants it, they can implement the check and fall back to (ii) for worktrees without the magic hard link. (ii) would benefit from recording the working tree directory as a possibly unreliable, human-friendly reminder. - How would this interact with core.worktree in .git/config of that super repository? Eek. I'll see if I can ignore core.worktree when $GIT_SUPER_DIR is set. If not, ban this use case :) -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 02/14] add a hashtable implementation that supports O(1) removal
Hi, Karsten Blees wrote: test-hashmap.c | 340 Here come two small tweaks on top (meant for squashing in or applying to the series, whichever is more convenient). Thanks, Jonathan Nieder (2): Add test-hashmap to .gitignore Drop unnecessary #includes from test-hashmap .gitignore | 1 + test-hashmap.c | 3 +-- 2 files changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Add test-hashmap to .gitignore
Prevent the test-hashmap program from being accidentally tracked with git add or cluttering git status output. Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index b5f9def..dc600f9 100644 --- a/.gitignore +++ b/.gitignore @@ -182,6 +182,7 @@ /test-dump-cache-tree /test-scrap-cache-tree /test-genrandom +/test-hashmap /test-index-version /test-line-buffer /test-match-trees -- 1.8.5.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Drop unnecessary #includes from test-hashmap
Per Documentation/CodingGuidelines most C files in git start with
a #include of git-compat-util.h or another header file that includes
it, such as cache.h or builtin.h. This file doesn't need anything
beyond git-compat-util.h, so use that.
Remove a #include of the system header stdio.h since it is already
included by git-compat-util.h.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
test-hashmap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/test-hashmap.c b/test-hashmap.c
index 7e86f88..f5183fb 100644
--- a/test-hashmap.c
+++ b/test-hashmap.c
@@ -1,6 +1,5 @@
-#include cache.h
+#include git-compat-util.h
#include hashmap.h
-#include stdio.h
struct test_entry
{
--
1.8.5.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] l10n:gitk: Init Vietnamese translation
On 14/12/2013 09:42, Tran Ngoc Quan wrote: Signed-off-by: Tran Ngoc Quan vnwild...@gmail.com --- gitk-git/po/vi.po | 1350 + po/vi.po | 594 +++ Sorry, not include po/vi.po I Will sent other patch! -- Trần Ngọc Quân. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] l10n:gitk: Init Vietnamese translation
Signed-off-by: Tran Ngoc Quan vnwild...@gmail.com --- gitk-git/po/vi.po | 1350 + 1 file changed, 1350 insertions(+) create mode 100644 gitk-git/po/vi.po diff --git a/gitk-git/po/vi.po b/gitk-git/po/vi.po new file mode 100644 index 000..7c56995 --- /dev/null +++ b/gitk-git/po/vi.po @@ -0,0 +1,1350 @@ +# Vietnamese translations for gitk package. +# Bản dịch tiếng Việt cho gói gitk. +# This file is distributed under the same license as the gitk package. +# Trần Ngọc Quân vnwild...@gmail.com, 2013. +# +msgid +msgstr +Project-Id-Version: gitk @@GIT_VERSION@@\n +Report-Msgid-Bugs-To: \n +POT-Creation-Date: 2013-12-14 09:24+0700\n +PO-Revision-Date: 2013-12-14 09:25+0700\n +Last-Translator: Trần Ngọc Quân vnwild...@gmail.com\n +Language-Team: Vietnamese\n +Language: vi\n +MIME-Version: 1.0\n +Content-Type: text/plain; charset=UTF-8\n +Content-Transfer-Encoding: 8bit\n +Plural-Forms: nplurals=1; plural=0;\n + +#: gitk:140 +msgid Couldn't get list of unmerged files: +msgstr Không thể lấy danh sách các tập-tin chưa được hòa trộn: + +#: gitk:212 gitk:2353 +msgid Color words +msgstr Tô màu chữ + +#: gitk:217 gitk:2353 gitk:8103 gitk:8136 +msgid Markup words +msgstr Đánh dấu chữ + +#: gitk:322 +msgid Error parsing revisions: +msgstr Gặp lỗi khi phân tích điểm xét duyệt: + +#: gitk:378 +msgid Error executing --argscmd command: +msgstr Gặp lỗi khi thực hiện lệnh --argscmd: + +#: gitk:391 +msgid No files selected: --merge specified but no files are unmerged. +msgstr +Chưa chọn tập tin: --merge đã chỉ định nhưng không có tập tin chưa hòa trộn. + +#: gitk:394 +msgid +No files selected: --merge specified but no unmerged files are within file +limit. +msgstr +Chưa chọn tập tin: --merge đã chỉ định nhưng không có tập tin chưa hòa trộn +trong giới hạn tập tin. + +#: gitk:416 gitk:564 +msgid Error executing git log: +msgstr Gặp lỗi khi thực hiện lệnh git log: + +#: gitk:434 gitk:580 +msgid Reading +msgstr Đang đọc + +#: gitk:494 gitk:4429 +msgid Reading commits... +msgstr Đang đọc các lần chuyển giao... + +#: gitk:497 gitk:1635 gitk:4432 +msgid No commits selected +msgstr Chưa chọn các lần chuyển giao + +#: gitk:1509 +msgid Can't parse git log output: +msgstr Không thể phân tích kết xuất từ lệnh git log: + +#: gitk:1738 +msgid No commit information available +msgstr Không có thông tin về lần chuyển giao nào + +#: gitk:1895 +msgid mc +msgstr mc + +#: gitk:1930 gitk:4222 gitk:9552 gitk:11122 gitk:11401 +msgid OK +msgstr Đồng ý + +#: gitk:1932 gitk:4224 gitk:9079 gitk:9158 gitk:9274 gitk:9323 gitk:9554 +#: gitk:11123 gitk:11402 +msgid Cancel +msgstr Thôi + +#: gitk:2067 +msgid Update +msgstr Cập nhật + +#: gitk:2068 +msgid Reload +msgstr Tải lại + +#: gitk:2069 +msgid Reread references +msgstr Đọc lại tham chiếu + +#: gitk:2070 +msgid List references +msgstr Liệt kê các tham chiếu + +#: gitk:2072 +msgid Start git gui +msgstr Khởi chạy git gui + +#: gitk:2074 +msgid Quit +msgstr Thoát + +#: gitk:2066 +msgid File +msgstr Chính + +#: gitk:2078 +msgid Preferences +msgstr Cá nhân hóa + +#: gitk:2077 +msgid Edit +msgstr Chỉnh sửa + +#: gitk:2082 +msgid New view... +msgstr Thêm trình bày mới... + +#: gitk:2083 +msgid Edit view... +msgstr Sửa cách trình bày... + +#: gitk:2084 +msgid Delete view +msgstr Xóa cách trình bày + +#: gitk:2086 +msgid All files +msgstr Mọi tập tin + +#: gitk:2081 gitk:3975 +msgid View +msgstr Trình bày + +#: gitk:2091 gitk:2101 gitk:2945 +msgid About gitk +msgstr Giới thiệu về gitk + +#: gitk:2092 gitk:2106 +msgid Key bindings +msgstr Tổ hợp phím + +#: gitk:2090 gitk:2105 +msgid Help +msgstr Trợ giúp + +#: gitk:2183 gitk:8535 +msgid SHA1 ID: +msgstr SHA1 ID: + +#: gitk:2227 +msgid Row +msgstr Hàng + +#: gitk:2265 +msgid Find +msgstr Tìm + +#: gitk:2266 +msgid next +msgstr tiếp + +#: gitk:2267 +msgid prev +msgstr trước + +#: gitk:2268 +msgid commit +msgstr commit + +#: gitk:2271 gitk:2273 gitk:4590 gitk:4613 gitk:4637 gitk:6653 gitk:6725 +#: gitk:6810 +msgid containing: +msgstr có chứa: + +#: gitk:2274 gitk:3457 gitk:3462 gitk:4666 +msgid touching paths: +msgstr đang chạm đường dẫn: + +#: gitk:2275 gitk:4680 +msgid adding/removing string: +msgstr thêm/gỡ bỏ chuỗi: + +#: gitk:2276 gitk:4682 +msgid changing lines matching: +msgstr những dòng thay đổi khớp mẫu: + +#: gitk:2285 gitk:2287 gitk:4669 +msgid Exact +msgstr Chính xác + +#: gitk:2287 gitk:4757 gitk:6621 +msgid IgnCase +msgstr BquaHt + +#: gitk:2287 gitk:4639 gitk:4755 gitk:6617 +msgid Regexp +msgstr BTCQ + +#: gitk:2289 gitk:2290 gitk:4777 gitk:4807 gitk:4814 gitk:6746 gitk:6814 +msgid All fields +msgstr Mọi trường + +#: gitk:2290 gitk:4774 gitk:4807 gitk:6684 +msgid Headline +msgstr Nội dung chính + +#: gitk:2291 gitk:4774 gitk:6684 gitk:6814 gitk:7283 +msgid Comments +msgstr Ghi chú + +#: gitk:2291 gitk:4774 gitk:4779 gitk:4814 gitk:6684 gitk:7218 gitk:8713 +#: gitk:8728 +msgid Author +msgstr Tác giả + +#: gitk:2291 gitk:4774 gitk:6684 gitk:7220 +msgid Committer +msgstr Người chuyển giao +
Re: [PATCH] l10n:gitk: Init Vietnamese translation
You should have copied Paul, gitk maintainer. I think Junio only pulls gitk patches from him, not random ones on the list. +Paul as I have something to say about gitk itself, not just the translations. 2013/12/14 Tran Ngoc Quan vnwild...@gmail.com: +#: gitk:494 gitk:4429 +msgid Reading commits... +msgstr Đang đọc các lần chuyển giao... + +#: gitk:497 gitk:1635 gitk:4432 +msgid No commits selected +msgstr Chưa chọn các lần chuyển giao + +#: gitk:1738 +msgid No commit information available +msgstr Không có thông tin về lần chuyển giao nào I'd rather keep commit untranslated until we find a Vietnamese word that fits the concept. I see you keep commit in many strings down, perhaps keep them here too for consistent? +#: gitk:2066 +msgid File +msgstr Chính This keeps bugging me. Why do GUI apps always name the first menu File even if it has nothing to do with files? Should gitk rename File to General, Main or something? +#: gitk:2287 gitk:4757 gitk:6621 +msgid IgnCase +msgstr BquaHt + +#: gitk:2287 gitk:4639 gitk:4755 gitk:6617 +msgid Regexp +msgstr BTCQ This is in a drop box whose width is auto adjusted to fit the text. I think you could translate as if the original strings are Ignore case and Regular expression (and perhaps gitk should update IgnCase to Ignore Case as well) +#: gitk:2291 gitk:4774 gitk:6684 gitk:7220 +msgid Committer +msgstr Người chuyển giao Người commit may be more inline if you keep commit unstranlated. +#: gitk:2330 +msgid Diff +msgstr Diff So sánh maybe? +#: gitk:3991 +msgid Committer: +msgstr Người gửi: Inconsistent with the previous translation above. +#: gitk:11235 +#, tcl-format +msgid Maximum graph width (% of pane) +msgstr Độ rộng biểu đồ tối đa (% của bảng hiển) Not sure what bảng hiển means, perhaps bảng is enough? +#: gitk:11341 +msgid Main font +msgstr Cỡ phông chữ chính Remove Cỡ? There's no size in the original string. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
