[PATCH] add: Clarify documentation of -A and -u
The documentation of '-A' is very confusing for someone who doesn't already know what it does. In particular, it describes the option's meaning by reference to that of '-u', but it's no more similar to the latter than it is to the default behavior. Describe it directly (and in a way that uses the word 'all'), and then describe the contrast separately. Signed-off-by: Greg Price --- Documentation/git-add.txt | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index 388a225..f89d920 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -105,7 +105,9 @@ apply to the index. See EDITING PATCHES below. will never stage new files, but that it will stage modified new contents of tracked files and that it will remove files from the index if the corresponding files in the working tree - have been removed. + have been removed. By contrast `-A` will add new files as + well as updating and removing existing ones, and the default + behavior will add new files and will not remove existing ones. + If no is given, the current version of Git defaults to "."; in other words, update all tracked files in the current directory @@ -114,10 +116,17 @@ of Git, hence the form without should not be used. -A:: --all:: - Like `-u`, but match against files in the - working tree in addition to the index. That means that it - will find new files as well as staging modified content and - removing files that are no longer in the working tree. + Update the index regarding all files that match , + either in the index or the working tree. That is, remove + files that are only in the index, add files that are only in + the working tree, and update files that differ between the + two. By contrast `-u` only removes and updates, and the + default behavior only adds and updates. ++ +If no is given, the current version of Git defaults to +"."; in other words, update all tracked files in the current directory +and its subdirectories. This default will change in a future version +of Git, hence the form without should not be used. -N:: --intent-to-add:: -- 1.7.11.3 -- 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] add: cut redundant require_pathspec logic
If take_worktree_changes is true, then the logic around
option_with_implicit_dot ensures argc is positive by this point.
So require_pathspec never has an effect.
Signed-off-by: Greg Price
---
builtin/add.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 0dd014e..9feb2ba 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -358,7 +358,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
struct dir_struct dir;
int flags;
int add_new_files;
- int require_pathspec;
char *seen = NULL;
const char *option_with_implicit_dot = NULL;
const char *short_option_with_implicit_dot = NULL;
@@ -399,7 +398,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
add_new_files = !take_worktree_changes && !refresh_only;
- require_pathspec = !take_worktree_changes;
newfd = hold_locked_index(&lock_file, 1);
@@ -410,7 +408,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
(!(addremove || take_worktree_changes)
? ADD_CACHE_IGNORE_REMOVAL : 0));
- if (require_pathspec && argc == 0) {
+ if (argc == 0) {
fprintf(stderr, _("Nothing specified, nothing added.\n"));
fprintf(stderr, _("Maybe you wanted to say 'git add .'?\n"));
return 0;
--
1.7.11.3
--
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 v6] submodule: add 'deinit' command
On Tue, Mar 05, 2013 at 07:45:22AM -0800, Junio C Hamano wrote: > Heiko Voigt writes: > > >> + if test -z "$force" > >> + then > >> + git rm -n "$sm_path" || > >> + die "$(eval_gettext "Submodule work tree > >> '\$sm_path' contains local modifications; use '-f' to discard them")" > > > > Minor nit. IMO, there is an indentation for the || missing here. Maybe > > Junio can squash that in on his side? > > Sorry, but I do not see an indentation nit here. The format looks > perfectly sane to me and in fact any other indentation would be > wrong. > > Puzzled... Wouldn't you write this code snippet like this to make clear that there is another conditional? if test -z "$force" then git rm -n "$sm_path" || die "$(eval_gettext "Submodule work tree '\$sm_path' contains local modifications; use '-f' to discard them")" It seems it is not clear in the code base either. Some places do some do not indent: git grep -A 1 '||' *.sh Except for the testsuite I just assumed that this style was common, because for me it makes the code much easier to read. It seems it is not, so forget my comment. Cheers Heiko -- 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: "git rebase" loses the additional changes in "evil" merges
"Philip Oakley" writes: > Given that many folk appear to trip up with their rebase mindset, does > this suggest that a few tweaks to the manual may be in order to stop > such misunderstandings? Perhaps. -- 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: "git rebase" loses the additional changes in "evil" merges
From: "Junio C Hamano" Sent: Tuesday, March 05, 2013 9:35 PM Dale Worley writes: From: Junio C Hamano I think this is to be expected for "git rebase", as it does not even look at merges. It is a way to find non-merge commits that haven't been applied yet, and apply them to the upstream to create a new linear history. I disagree. "git rebase" is not characterized as ... The intention has always been "I have these patches, some were applied upstream already, now what do I have left?". Given that many folk appear to trip up with their rebase mindset, does this suggest that a few tweaks to the manual may be in order to stop such misunderstandings? Perhaps: git-rebase - Forward-port local commits, not in upstream, to the updated upstream head and to avoid "hidden" asides, add a few more paragraph breaks into the description texts, and perhaps bring the "Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD.. are omitted" sentence nearer the start. That is, don't let folks get a too simplistic view of rebase, missing its hidden powers. You do realize that you are disagreeing with somebody who designed the original "git rebase" (before the --preserve-merges was added), do you? However the broader userbase brings with it a better class of fool ;-) -- 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 v2 4/4] push: --follow-tags
The new option "--follow-tags" tells "git push" to push annotated
tags that are missing from the other side and that can be reached by
the history that is otherwise pushed out.
For example, if you are using the "simple", "current", or "upstream"
push, you would ordinarily push the history leading to the commit at
your current HEAD and nothing else. With this option, you would
also push all annotated tags that can be reached from that commit to
the other side.
Signed-off-by: Junio C Hamano
---
Documentation/git-push.txt | 8 +++-
builtin/push.c | 2 +
remote.c | 99 ++
remote.h | 3 +-
t/t5516-fetch-push.sh | 73 ++
transport.c| 2 +
transport.h| 1 +
7 files changed, 186 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 8b637d3..40377ba 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
[verse]
-'git push' [--all | --mirror | --tags] [-n | --dry-run]
[--receive-pack=]
+'git push' [--all | --mirror | --tags] [--follow-tags] [-n | --dry-run]
[--receive-pack=]
[--repo=] [-f | --force] [--prune] [-v | --verbose] [-u
| --set-upstream]
[ [...]]
@@ -111,6 +111,12 @@ no `push.default` configuration variable is set.
addition to refspecs explicitly listed on the command
line.
+--follow-tags::
+ Push all the refs that would be pushed without this option,
+ and also push annotated tags in `refs/tags` that are missing
+ from the remote but are pointing at committish that are
+ reachable from the refs being pushed.
+
--receive-pack=::
--exec=::
Path to the 'git-receive-pack' program on the remote
diff --git a/builtin/push.c b/builtin/push.c
index db9ba30..34a8271 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -399,6 +399,8 @@ int cmd_push(int argc, const char **argv, const char
*prefix)
OPT_BOOL(0, "progress", &progress, N_("force progress
reporting")),
OPT_BIT(0, "prune", &flags, N_("prune locally removed refs"),
TRANSPORT_PUSH_PRUNE),
+ OPT_BIT(0, "follow-tags", &flags, N_("push missing but relevant
tags"),
+ TRANSPORT_PUSH_FOLLOW_TAGS),
OPT_END()
};
diff --git a/remote.c b/remote.c
index ca1f8f2..f035af3 100644
--- a/remote.c
+++ b/remote.c
@@ -1195,6 +1195,101 @@ static struct ref **tail_ref(struct ref **head)
return tail;
}
+struct tips {
+ struct commit **tip;
+ int nr, alloc;
+};
+
+static void add_to_tips(struct tips *tips, const unsigned char *sha1)
+{
+ struct commit *commit;
+
+ if (is_null_sha1(sha1))
+ return;
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit || (commit->object.flags & TMP_MARK))
+ return;
+ commit->object.flags |= TMP_MARK;
+ ALLOC_GROW(tips->tip, tips->nr + 1, tips->alloc);
+ tips->tip[tips->nr++] = commit;
+}
+
+static void add_missing_tags(struct ref *src, struct ref **dst, struct ref
***dst_tail)
+{
+ struct string_list dst_tag = STRING_LIST_INIT_NODUP;
+ struct string_list src_tag = STRING_LIST_INIT_NODUP;
+ struct string_list_item *item;
+ struct ref *ref;
+ struct tips sent_tips;
+
+ /*
+* Collect everything we know they would have at the end of
+* this push, and collect all tags they have.
+*/
+ memset(&sent_tips, 0, sizeof(sent_tips));
+ for (ref = *dst; ref; ref = ref->next) {
+ if (ref->peer_ref &&
+ !is_null_sha1(ref->peer_ref->new_sha1))
+ add_to_tips(&sent_tips, ref->peer_ref->new_sha1);
+ else
+ add_to_tips(&sent_tips, ref->old_sha1);
+ if (!prefixcmp(ref->name, "refs/tags/"))
+ string_list_append(&dst_tag, ref->name);
+ }
+ clear_commit_marks_many(sent_tips.nr, sent_tips.tip, TMP_MARK);
+
+ sort_string_list(&dst_tag);
+
+ /* Collect tags they do not have. */
+ for (ref = src; ref; ref = ref->next) {
+ if (prefixcmp(ref->name, "refs/tags/"))
+ continue; /* not a tag */
+ if (string_list_has_string(&dst_tag, ref->name))
+ continue; /* they already have it */
+ if (sha1_object_info(ref->new_sha1, NULL) != OBJ_TAG)
+ continue; /* be conservative */
+ item = string_list_append(&src_tag, ref->name);
+ item->util = ref;
+ }
+ string_list_clear(&dst_tag, 0);
+
+ /*
+* At this point, src_tag lists tags that are missing from
+* dst, and sent_tip
[PATCH v2 3/4] commit.c: use clear_commit_marks_many() in in_merge_bases_many()
Signed-off-by: Junio C Hamano --- commit.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/commit.c b/commit.c index d12e799..b4512ab 100644 --- a/commit.c +++ b/commit.c @@ -876,8 +876,7 @@ int in_merge_bases_many(struct commit *commit, int nr_reference, struct commit * if (commit->object.flags & PARENT2) ret = 1; clear_commit_marks(commit, all_flags); - for (i = 0; i < nr_reference; i++) - clear_commit_marks(reference[i], all_flags); + clear_commit_marks_many(nr_reference, reference, all_flags); free_commit_list(bases); return ret; } -- 1.8.2-rc2-194-g549a9ef -- 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 v2 1/4] commit.c: add clear_commit_marks_many()
clear_commit_marks(struct commit *, unsigned) only can clear flag
bits starting from a single commit; introduce an API to allow
feeding an array of commits, so that flag bits can be cleared from
commits reachable from any of them with a single traversal.
Signed-off-by: Junio C Hamano
---
commit.c | 19 +--
commit.h | 1 +
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index e8eb0ae..4757e50 100644
--- a/commit.c
+++ b/commit.c
@@ -463,14 +463,23 @@ static void clear_commit_marks_1(struct commit_list
**plist,
}
}
-void clear_commit_marks(struct commit *commit, unsigned int mark)
+void clear_commit_marks_many(int nr, struct commit **commit, unsigned int mark)
{
struct commit_list *list = NULL;
- commit_list_insert(commit, &list);
+
+ while (nr--) {
+ commit_list_insert(*commit, &list);
+ commit++;
+ }
while (list)
clear_commit_marks_1(&list, pop_commit(&list), mark);
}
+void clear_commit_marks(struct commit *commit, unsigned int mark)
+{
+ clear_commit_marks_many(1, &commit, mark);
+}
+
void clear_commit_marks_for_object_array(struct object_array *a, unsigned mark)
{
struct object *object;
@@ -797,8 +806,7 @@ struct commit_list *get_merge_bases_many(struct commit *one,
if (!result || !result->next) {
if (cleanup) {
clear_commit_marks(one, all_flags);
- for (i = 0; i < n; i++)
- clear_commit_marks(twos[i], all_flags);
+ clear_commit_marks_many(n, twos, all_flags);
}
return result;
}
@@ -816,8 +824,7 @@ struct commit_list *get_merge_bases_many(struct commit *one,
free_commit_list(result);
clear_commit_marks(one, all_flags);
- for (i = 0; i < n; i++)
- clear_commit_marks(twos[i], all_flags);
+ clear_commit_marks_many(n, twos, all_flags);
cnt = remove_redundant(rslt, cnt);
result = NULL;
diff --git a/commit.h b/commit.h
index b6ad8f3..b997eea 100644
--- a/commit.h
+++ b/commit.h
@@ -134,6 +134,7 @@ struct commit *pop_most_recent_commit(struct commit_list
**list,
struct commit *pop_commit(struct commit_list **stack);
void clear_commit_marks(struct commit *commit, unsigned int mark);
+void clear_commit_marks_many(int nr, struct commit **commit, unsigned int
mark);
void clear_commit_marks_for_object_array(struct object_array *a, unsigned
mark);
/*
--
1.8.2-rc2-194-g549a9ef
--
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 v2 2/4] commit.c: add in_merge_bases_many()
Similar to in_merge_bases(commit, other) that returns true when
commit is an ancestor (i.e. in the merge bases between the two) of
the other commit, in_merge_bases_many(commit, n_other, other[])
checks if commit is an ancestor of any of the other[] commits.
Signed-off-by: Junio C Hamano
---
commit.c | 24 ++--
commit.h | 1 +
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/commit.c b/commit.c
index 4757e50..d12e799 100644
--- a/commit.c
+++ b/commit.c
@@ -859,25 +859,37 @@ int is_descendant_of(struct commit *commit, struct
commit_list *with_commit)
}
/*
- * Is "commit" an ancestor of (i.e. reachable from) the "reference"?
+ * Is "commit" an ancestor of one of the "references"?
*/
-int in_merge_bases(struct commit *commit, struct commit *reference)
+int in_merge_bases_many(struct commit *commit, int nr_reference, struct commit
**reference)
{
struct commit_list *bases;
- int ret = 0;
+ int ret = 0, i;
- if (parse_commit(commit) || parse_commit(reference))
+ if (parse_commit(commit))
return ret;
+ for (i = 0; i < nr_reference; i++)
+ if (parse_commit(reference[i]))
+ return ret;
- bases = paint_down_to_common(commit, 1, &reference);
+ bases = paint_down_to_common(commit, nr_reference, reference);
if (commit->object.flags & PARENT2)
ret = 1;
clear_commit_marks(commit, all_flags);
- clear_commit_marks(reference, all_flags);
+ for (i = 0; i < nr_reference; i++)
+ clear_commit_marks(reference[i], all_flags);
free_commit_list(bases);
return ret;
}
+/*
+ * Is "commit" an ancestor of (i.e. reachable from) the "reference"?
+ */
+int in_merge_bases(struct commit *commit, struct commit *reference)
+{
+ return in_merge_bases_many(commit, 1, &reference);
+}
+
struct commit_list *reduce_heads(struct commit_list *heads)
{
struct commit_list *p;
diff --git a/commit.h b/commit.h
index b997eea..5057f14 100644
--- a/commit.h
+++ b/commit.h
@@ -171,6 +171,7 @@ extern struct commit_list *get_shallow_commits(struct
object_array *heads,
int is_descendant_of(struct commit *, struct commit_list *);
int in_merge_bases(struct commit *, struct commit *);
+int in_merge_bases_many(struct commit *, int, struct commit **);
extern int interactive_add(int argc, const char **argv, const char *prefix,
int patch);
extern int run_add_interactive(const char *revision, const char *patch_mode,
--
1.8.2-rc2-194-g549a9ef
--
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 v2 0/4] push --follow-tags
The primary change since the last round is that it pushes out only annotated tags that are missing from the other side. Junio C Hamano (4): commit.c: add clear_commit_marks_many() commit.c: add in_merge_bases_many() commit.c: use clear_commit_marks_many() in in_merge_bases_many() push: --follow-tags Documentation/git-push.txt | 8 +++- builtin/push.c | 2 + commit.c | 42 ++-- commit.h | 2 + remote.c | 99 ++ remote.h | 3 +- t/t5516-fetch-push.sh | 73 ++ transport.c| 2 + transport.h| 1 + 9 files changed, 218 insertions(+), 14 deletions(-) -- 1.8.2-rc2-194-g549a9ef -- 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: Load testing of git
Thanks to everyone. The information was useful. On 24 February 2013 21:31, Shawn Pearce wrote: > On Sun, Feb 24, 2013 at 8:58 AM, Thomas Koch wrote: >> Yuri Mikhailov: >>> Dear Git community, >>> >>> I am a Software Developer and I have been using git for a while. >>> Currently my company is looking for a version control system to use >>> and we find Git a good candidate for us. But what is important for us >>> to know is scalability of this VCS. Does anyone performed load testing >>> of Git? What is the practical maximum number of files and revisions >>> this system can handle? >>> >>> Best regards, >>> Iurii Mykhailov >> >> Have a look at the projects using Git[1]. There are for sure projects that >> exceeds the scalability you're thinking about. The linux Kernel might be the >> biggest project. > > I highly doubt the Linux kernel is the biggest project. > > IIRC WebKit has more objects, more files, etc. Its repository's > compressed form is >4G. > > I know of at least some proprietary repositories with 96G in them. Not > much history, but a lot of binary blobs around 128M each doesn't > compress well. And bup wasn't used so we didn't get very good > compression over the files. -- 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: rebase destroys branches
From: "Gene Thomas [DATACOM]" Sent: Tuesday, March 05, 2013 1:05 AM Philip, Thanks for your reply. The original branch is not 'destroyed', rather the pointer to the previous tip is within the logs. Is that the 'git log' log or internal logs? Are you sure? There doesn't appear to be a way to checkout that tip of see the log back from that tip. Double checking the [rebase] manual page... [The ref] "ORIG_HEAD is set to point at the tip of the branch before the reset." So your original branch starts there (I just checked one of mine). Obviously this is only for the machine that did the rebase, and only has the last rebase tip. But then until it's pushed to an open repo no one knows ;-) All the content is still available until the logs expire. So we will be unable to checkout content after a time? Gene Thomas. -Original Message- From: Philip Oakley [mailto:philipoak...@iee.org] Sent: Tuesday, 5 March 2013 12:44 To: Gene Thomas [DATACOM]; Git List Subject: Re: rebase destroys branches From: "Gene Thomas [DATACOM]" Sent: Monday, March 04, 2013 11:06 PM Hello, I am evaluating git for use in a company. Please correct if I am wrong. I am concerned that an inexperienced developer could mistakenly rebase branches, destroying the original branch. The original branch is not 'destroyed', rather the pointer to the previous tip is within the logs. All the content is still available until the logs expire. Attached is a script (Windoze) that shows the 'topic' branch being moved!, after the rebase we are unable to see the original branch, read it's history or find it's commit points. Surely no operation should remove anything from the repository. Operations like this irreversibly break the repository . When rebasing the original branch must be retained. It's easy to misread some of Git's strengths if you have come from other historic corporate 'version control systems' which are often based on drawing office practice of old (e.g. the belief there is a single master to be protected is one misconception for software). Rebase, at the personal level, is an important mechanism for staff to prepare better code and commit messages. Trying to hide the reality will just make your management 'control' less effective as staff work around it and delay check-ins, etc. The broader access control and repo management issues are deliberately not part of Git, and there are good tools for that. e.g. Gitolite. Yours faithfully, Gene Thomas. Philip -- 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] reflog: fix typo in "reflog expire" clean-up codepath
In "reflog expire" we were not clearing the REACHABLE bit from
objects reachable from the tip of refs we marked earlier.
Signed-off-by: Junio C Hamano
---
builtin/reflog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index b3c9e27..ef56e7b 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -414,7 +414,7 @@ static int expire_reflog(const char *ref, const unsigned
char *sha1, int unused,
if (cb.unreachable_expire_kind == UE_HEAD) {
struct commit_list *elem;
for (elem = tips; elem; elem = elem->next)
- clear_commit_marks(tip_commit, REACHABLE);
+ clear_commit_marks(elem->item, REACHABLE);
free_commit_list(tips);
} else {
clear_commit_marks(tip_commit, REACHABLE);
--
1.8.2-rc2-187-g1ea4a7c
--
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: "git rebase" loses the additional changes in "evil" merges
Dale Worley writes: >> From: Junio C Hamano >> >> I think this is to be expected for "git rebase", as it does not even >> look at merges. It is a way to find non-merge commits that haven't >> been applied yet, and apply them to the upstream to create a new >> linear history. > > I disagree. "git rebase" is not characterized as ... The intention has always been "I have these patches, some were applied upstream already, now what do I have left?". You do realize that you are disagreeing with somebody who designed the original "git rebase" (before the --preserve-merges was added), do you? -- 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: Git hook commit similar to subversion start-commit hook
On Tue, Mar 05, 2013 at 10:14:42PM +0100, Jose Garcia Juanino wrote: > Is there any hook in Git similar to start-commit subversion hook? The > requirements would be: > > 1- A hook on the server side (as pre-receive) > 2- It will execute the actions *before* the begin of transaction > (pre-receive hook needs the references already pushed before). > > For example, it would be useful to refuse a push if the server has a > high load. If you are using Gitolite[1] then a PRE_GIT trigger could do this. With plain Git you can achieve the same by specifying a custom shell for the users logging in and performing the custom check when git-receive-pack is being executed. [1] http://gitolite.com/gitolite John -- 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: "git rebase" loses the additional changes in "evil" merges
> From: Junio C Hamano > > I think this is to be expected for "git rebase", as it does not even > look at merges. It is a way to find non-merge commits that haven't > been applied yet, and apply them to the upstream to create a new > linear history. I disagree. "git rebase" is not characterized as a way to "find non-merge commits that haven't been applied yet", but rather (as described in the git-rebase manual page): git-rebase - Forward-port local commits to the updated upstream head All changes made by commits in the current branch but that are not in are saved to a temporary area. [...] The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Now if you read far enough down the page, I'm sure it warns about merge commits. But the stated basic *intention* is to replicate the existing branch, re-rooted at a new place on the upstream branch. The current implementation fails this intention by losing changes made in merges. It fails this intention in a *dangerous* way by causing changes to be lost without warning. Dale -- 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/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
On Tue, Mar 5, 2013 at 3:51 PM, Jens Lehmann wrote:
> Am 05.03.2013 19:34, schrieb Junio C Hamano:
>> Eric Cousineau writes:
>>> ...
>> I am not entirely convinced we would want --include-super in the
>> first place, though. It does not belong to "submodule foreach";
>> it is doing something _outside_ the submoudules.
>
> I totally agree with that. First, adding --include-super does not
> belong into the --post-order patch at all, as that is a different
> topic (even though it belongs to the same use case Eric has). Also
> the reason why we are thinking about adding the --post-order option
> IMO cuts the other way for --include-super: It is so easy to do
> that yourself I'm not convinced we should add an extra option to
> foreach for that, especially as it has nothing to do with submodules.
> So I think we should just drop --include-super.
I agree it should not be part of this commit, but I've often found
myself in need of an --include-super switch. To me,
git-submodule-foreach means "visit all my .git repos in this project
and execute $cmd". It's a pity that the super-project is considered a
second-class citizen in this regard.
I have to do this sometimes:
${cmd} && git submodule foreach --recursive '${cmd}'
I often forget the first part in scripts, though, and I've seen others
do it too. I usually create a function for it in git-heavy scripts.
In a shell, it usually goes like this:
git submodule foreach --recursive '${cmd}'
{30-ish}
It'd be easier if I could just include a switch for this, and maybe
even create an alias for it. But maybe this is different command
altogether.
--
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
Git hook commit similar to subversion start-commit hook
Hello, Is there any hook in Git similar to start-commit subversion hook? The requirements would be: 1- A hook on the server side (as pre-receive) 2- It will execute the actions *before* the begin of transaction (pre-receive hook needs the references already pushed before). For example, it would be useful to refuse a push if the server has a high load. I have read man githook, but there is nothing similar. Best regard, and excuse my poor english. pgpW9RXG_kEMB.pgp Description: PGP signature
Re: auto merge bug
On 03/05/2013 07:47 PM, Junio C Hamano wrote: > Jeff King writes: > >> I'm also not sure how useful those really are in practice. I have not >> used "union" myself ever. And in the example that started this thread, I >> find the use of "union" slightly dubious. > > Yeah, I do not think anybody sane used "union" outside toy examples. I do, for lists used in tests or to generate perfect hashes from. It's really quite handy for things like that but totally useless for any type of multiline format, or even .ini style files unless you're very, very careful with how you write them. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
Am 05.03.2013 19:34, schrieb Junio C Hamano: > Eric Cousineau writes: > >> Would these be the correct behaviors of Heiko's implementation? > > I do not think Heiko already has an implementation, but let's try to > see how each example makes sense. > >> git submodule foreach # Empty command, pre-order >> git submodule foreach --pre-order # Same behavior >> git submodule foreach --post-order # Empty command, post-order > > OK. The last one shows "I am here" output differently from the > other two, but otherwise they are all no-op. > >> git submodule foreach 'frotz' # Do 'frotz' pre-order in each submodule > > OK. And it would be the same if you said either one of: > > git submodule foreach --pre-order 'frotz' > git submodule foreach --pre-order='frotz' > >> git submodule foreach --post-order 'frotz' # Do 'frotz' post-order in >> each submodule > > OK. > >> git submodule foreach --pre-order='frotz' --post-order='shimmy' # Do >> 'frotz' pre-order and 'shimmy' post-order in each submodule > > OK. > >> git submodule foreach --post-order='shimmy' 'frotz' # Invalid usage of >> the command > > I would expect this to behave exactly the same as: > > git submodule foreach \ > --post-order=shimmy \ > --pre-order=frotz > >> git submodule foreach --post-order --pre-order # > > I expect it to behave exactly the same as: > > git submodule foreach --post-order=: --pre-order=: I'd favor to just drop the --pre-order option and do this: foreach [--recursive] [--post-order ] [] Me thinks pre-order is a sane default and we shouldn't add an explicit option for that. And even with current Git you can simply give no command at all and it'll show you all the submodules it enters without doing anything in them, so we'd only need to add the --post-order handling anyway (and fix the synopsis by adding square brackets around the command while at it, as that is optional). >> It should not be too hard to have this functionality affect the >> --include-super command as well. > > I would assume that > > git submodule foreach --pre-order=A --post-order=B --include-super > > would be identical to running > > A && > git submodule foreach --pre-order=A --post-order=B && > B > > I am not entirely convinced we would want --include-super in the > first place, though. It does not belong to "submodule foreach"; > it is doing something _outside_ the submoudules. I totally agree with that. First, adding --include-super does not belong into the --post-order patch at all, as that is a different topic (even though it belongs to the same use case Eric has). Also the reason why we are thinking about adding the --post-order option IMO cuts the other way for --include-super: It is so easy to do that yourself I'm not convinced we should add an extra option to foreach for that, especially as it has nothing to do with submodules. So I think we should just drop --include-super. -- 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 2/2] push: --follow-tag
On Tue, Mar 05, 2013 at 11:17:11AM -0800, Junio C Hamano wrote: > I may have tentatively tagged the tip of 'master' as v1.8.2 in my > private repository, started the integration testing, but may not be > confident enough to push out the branch nor the tag yet. I may have > an experimental topic that I want to share with others before I am > done with the release to unblock them, and the topic may build on > the 'master' I may or may not want to redo before the release. > > I can do so with "git push github jc/topic" (no --follow-tags). > After doing such a "you may want to start with this" push, I can > continue working on the release, and the 'master' branch may turn > out to be good to go without redoing. > > A later "git push github --follow-tags master" in such a case should > send v1.8.2 out. It is inexcuable to break it, saying "Oh, I've > seen that commit already---it is part of the previous update to > jc/topic". That defeats the whole point of --follow-tags. That depends on the specifics of the rule. If the rule is "any commit that the server already has", then yes, it runs afoul of that problem. But what if it is "any commit in the ref update being sent"? That is, we would look at the range "origin/master..master" and send any tags that point to commits in that range. > The other "tags at the tip" is slightly less problematic than > "ignore the commits the receiving end has already seen", but it will > break if I tag the tip of 'maint' as v1.8.1.6, continue working > without being able to push perhaps due to network disruption, and > have already started building towards v1.8.1.7 when the network > comes back. 'maint' may be past v1.8.1.6 and its tip won't be > pointing at that tag, but it still is missing from the public > repository. Right, I think "tags at the tip" is too likely to miss things you did want to send. > While I agree with your goal to make it safer to use "push", both > "ignore commits that the receiving end already saw" and "only look > at the commits at the tip being sent" castrate the option too much > to the point that it is meaningless. The whole point of asking > explicitly with the "--follow-tags" option to "push" to push out > relevant tags is, eh, to push out relevant tags. I do not think it > is magical at all. "backfill" is an integral part of the option. I know, and I'm willing to accept that the right resolution is "we should not have this feature" (or possibly "the documentation must warn about caveats of the feature). I'm just worried about it accidentally being misused and causing problems. -Peff -- 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 2/2] push: --follow-tag
Jeff King writes: > Yeah, I think that is another sensible variant. It does not really > "backfill" in the way that Junio's patch does (e.g., if you forgot to > push out v1.6 to a remote 2 weeks ago and now you are pushing out v1.7, > Junio's patch will magically fill it in). I may have tentatively tagged the tip of 'master' as v1.8.2 in my private repository, started the integration testing, but may not be confident enough to push out the branch nor the tag yet. I may have an experimental topic that I want to share with others before I am done with the release to unblock them, and the topic may build on the 'master' I may or may not want to redo before the release. I can do so with "git push github jc/topic" (no --follow-tags). After doing such a "you may want to start with this" push, I can continue working on the release, and the 'master' branch may turn out to be good to go without redoing. A later "git push github --follow-tags master" in such a case should send v1.8.2 out. It is inexcuable to break it, saying "Oh, I've seen that commit already---it is part of the previous update to jc/topic". That defeats the whole point of --follow-tags. The other "tags at the tip" is slightly less problematic than "ignore the commits the receiving end has already seen", but it will break if I tag the tip of 'maint' as v1.8.1.6, continue working without being able to push perhaps due to network disruption, and have already started building towards v1.8.1.7 when the network comes back. 'maint' may be past v1.8.1.6 and its tip won't be pointing at that tag, but it still is missing from the public repository. While I agree with your goal to make it safer to use "push", both "ignore commits that the receiving end already saw" and "only look at the commits at the tip being sent" castrate the option too much to the point that it is meaningless. The whole point of asking explicitly with the "--follow-tags" option to "push" to push out relevant tags is, eh, to push out relevant tags. I do not think it is magical at all. "backfill" is an integral part of the option. -- 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: auto merge bug
Jeff King writes: > I'm also not sure how useful those really are in practice. I have not > used "union" myself ever. And in the example that started this thread, I > find the use of "union" slightly dubious. Yeah, I do not think anybody sane used "union" outside toy examples. IIRC, it was originally done as a "if you want a GIGO, here it is, go hang yourself." response to "I am too lazy to resolve conflicts myself, Git should let me take both sides blindly." -- 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/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
Eric Cousineau writes: > Would these be the correct behaviors of Heiko's implementation? I do not think Heiko already has an implementation, but let's try to see how each example makes sense. > git submodule foreach # Empty command, pre-order > git submodule foreach --pre-order # Same behavior > git submodule foreach --post-order # Empty command, post-order OK. The last one shows "I am here" output differently from the other two, but otherwise they are all no-op. > git submodule foreach 'frotz' # Do 'frotz' pre-order in each submodule OK. And it would be the same if you said either one of: git submodule foreach --pre-order 'frotz' git submodule foreach --pre-order='frotz' > git submodule foreach --post-order 'frotz' # Do 'frotz' post-order in > each submodule OK. > git submodule foreach --pre-order='frotz' --post-order='shimmy' # Do > 'frotz' pre-order and 'shimmy' post-order in each submodule OK. > git submodule foreach --post-order='shimmy' 'frotz' # Invalid usage of > the command I would expect this to behave exactly the same as: git submodule foreach \ --post-order=shimmy \ --pre-order=frotz > git submodule foreach --post-order --pre-order # I expect it to behave exactly the same as: git submodule foreach --post-order=: --pre-order=: > It should not be too hard to have this functionality affect the > --include-super command as well. I would assume that git submodule foreach --pre-order=A --post-order=B --include-super would be identical to running A && git submodule foreach --pre-order=A --post-order=B && B I am not entirely convinced we would want --include-super in the first place, though. It does not belong to "submodule foreach"; it is doing something _outside_ the submoudules. -- 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 2/2] push: --follow-tag
On Tue, Mar 05, 2013 at 12:49:57PM +0100, Michael Haggerty wrote: > > One obvious alternative is only to push annotated tags with this > > feature. That has the downside of not matching fetch's behavior, as well > > as withholding the feature from people whose workflow uses only > > unannotated tags. > > > > Another alternative would be to change the inclusion rule from > > "reachable" to "points at the tip of something being sent". But then we > > lose the feature that it would backfill any old tags the remote happens > > to be missing. > > I have no opinion on this matter, but ISTM that another obvious > alternative would be to push tags that point at *any* commits that are > being sent (not just at the tip), but not those that point to older > commits already known to the server. This would reduce the potential > for accidental pushes of "distant" tags. Yeah, I think that is another sensible variant. It does not really "backfill" in the way that Junio's patch does (e.g., if you forgot to push out v1.6 to a remote 2 weeks ago and now you are pushing out v1.7, Junio's patch will magically fill it in). But I do not see a huge value in backfilling. It is anyone's guess whether you simply forgot to push out v1.6 or whether you intended to hold it back. And I'd rather err on the side of not-pushing because of the difficulty of retraction. -Peff -- 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 2/2] push: --follow-tag
On Tue, Mar 05, 2013 at 10:15:20AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > But I wonder if fetching and pushing are different in that respect. You > > are (usually) fetching from a public publishing point, and it is assumed > > that whatever is there is useful for sharing. The only reason to limit > > it is to save time transferring objects the user does not want. > > There are those who have to emulate "git fetch" with a reverse "git > push" (or vice versa) due to network connection limitations, so I do > not think hardcoding such a policy decision in the direction is > necessarily a good idea. Yeah, but I think it makes sense to optimize the defaults for the common cases, and let people doing unusual things override the behavior via options (or even config). Don't get me wrong, I think there is value in the simplicity of having the push/fetch transactions be as symmetric as possible. But given the potentially high cost of a mistaken push (i.e., retracting published history can be embarrassing or complicated), there's also value in safe defaults. And I feel like we've already gone in that direction with the default refspecs being different between fetch and push. -Peff -- 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 2/2] push: --follow-tag
Jeff King writes: > But I wonder if fetching and pushing are different in that respect. You > are (usually) fetching from a public publishing point, and it is assumed > that whatever is there is useful for sharing. The only reason to limit > it is to save time transferring objects the user does not want. There are those who have to emulate "git fetch" with a reverse "git push" (or vice versa) due to network connection limitations, so I do not think hardcoding such a policy decision in the direction is necessarily a good idea. > ... But I also don't want to introduce a feature > that causes people to accidentally publish cruft. It may not be a > problem in practice; I'm just thinking out loud at this point. Likewise. -- 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: auto merge bug
On Tue, Mar 05, 2013 at 07:44:13AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think the merge will produce the results you are looking for. This
> > would have to be configurable, though, as it is a regression for
> > existing users of "union", which would want the duplicate-line
> > suppression (or maybe not; it will only catch such duplicates at the
> > beginning and end of the conflict hunk, so maybe it is sane to always
> > ask "union" to keep all lines).
>
> The original use-case example of "union" was to merge two shopping
> lists (e.g. I add "bread" and "orange juice" to remind me that we
> need to buy these things, while my wife adds "bread" and "butter").
>
> We do not necessarily want to end up with a shopping list to buy two
> loaves of bread. When the user verifies and fixes up the result, we
> can keep the current behaviour and those who want to re-dup can add
> one back, or we can change the behaviour to leave the duplicates and
> those who do not want to see duplicates can remove them manually.
>
> Given that the caveat you quoted already tells the user to verify
> the result and not to use it without understanding its implications,
> I think it technically is fine either way (read: keeping duplicates
> is not a clearly superiour solution). So let's leave it as-is.
My problem with the current behavior is that it is not predictable
whether it will de-dup or not. If your shopping lists are:
bread
orange juice
bread
butter
it works; you get only one bread. If they are:
milk
bread
orange juice
beer
bread
butter
you get two. It depends on the exact behavior of the XDL_MERGE_ZEALOUS
flag. What I'd propose is two different drivers:
1. Find conflicts via 3-way merge, and include both sides of the
conflict verbatim. Do not use XDL_MERGE_ZEALOUS, as it is more
important to retain items from both sides (in their original order)
than it is to remove duplicates.
2. A true line-based union, which should act like "cat $ours $theirs |
sort | uniq". That is what you want for the shopping list example,
I think (you could also preserve existing ordering with a lookup
table, though I prefer clobbering the ordering; the ordering of
resolved conflicts will be arbitrary anyway, so it makes it clear
from the outset that you should not use this driver if your content
is not really a set (in the mathematical sense) of lines).
You could also have sets of other objects (e.g., blank-line
delimited paragraphs, changelog entries, etc). But you would need
some way to specify the parsing then[1].
I'm not sure which should be called "union". The first one would still
need careful examination of the result. The second one should always be
correct, but only because it is limited to a much more constrained
problem.
I'm also not sure how useful those really are in practice. I have not
used "union" myself ever. And in the example that started this thread, I
find the use of "union" slightly dubious. I do not even know how it
would react to a line _changing_, or other complicated edit. Short of a
specialized XML-aware merge driver, using XDL_MERGE_ZEALOUS and kicking
the result out to the user (i.e., what the default merge driver does)
seems like the only sane thing, even if it is more work at merge time.
-Peff
[1] Some of this is fairly easy to do with perl one-liners (e.g., "perl
-00 -ne 'print unless $h{$_}++" for paragraph mode), so maybe it is
just an education/documentation issue. I dunno. I have always been
happy enough with the stock merge.
--
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] help: show manpage for aliased command on git --help
On Tue, Mar 05, 2013 at 02:44:41PM +, Ævar Arnfjörð Bjarmason wrote: > Change the semantics of "git --help" to show the help for the > command is aliased to, instead of just saying: > > `git ' is aliased to `' > > E.g. if you have "checkout" aliased to "co" you won't get: > > $ git co --help > `git co' is aliased to `checkout' > > But will instead get the manpage for git-checkout. The behavior this > is replacing was originally added by Jeff King in 2156435. I'm > changing it because of this off-the-cuff comment on IRC: > > 14:27:43 <@Tux> git can be very unhelpful, literally: > 14:27:46 <@Tux> $ git co --help > 14:27:46 <@Tux> `git co' is aliased to `checkout' > 14:28:08 <@Tux> I know!, gimme the help for checkout, please > > And because I also think it makes more sense than showing you what the > thing is aliased to. In this simple case, I think it is helpful to show the "checkout" manpage, because there is no other information to give (and by showing the checkout manpage, you implicitly indicate that "co" maps to "checkout"). But like others, I am concerned about the other cases, where there is no manpage, it is not a git command with a manpage, or it is a git command with options. You are losing useful information that is currently given to the user in all but the single-word case. In an ideal world, we could say "here is how the alias expands, and by the way, here is the manpage for the expanded command". And obviously just omit the latter part when there is no such page. But we are relying on external programs to do the presentation and paging. Doing the C equivalent of: echo "'git co' is aliased to 'checkout'" && man checkout does not quite work, because "man" will start a pager. We can run our own pager (which should suppress man's invocation), but that is a regression for anyone who uses MANPAGER. The user may also be using help.format to use something besides man. If help.format is set to "html", we will spawn a browser. In that case we can still output the alias information, but it may or may not be seen (though come to think of it, that is probably already a problem for "git help " on Windows systems, or anybody invoking git help from a GUI porcelain). So I'd only be in favor of this patch if it managed to avoid information loss in the more complicated cases. And I'm not sure how best to do that. The "only trigger for a single-word alias" suggestion seems like the least ugly to me. -Peff -- 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 2/2] push: --follow-tag
On Tue, Mar 05, 2013 at 07:58:45AM -0800, Junio C Hamano wrote: > > This will find anything under refs/tags, including annotated and > > non-annotated tags. I wonder if it is worth making a distinction. In > > many workflows, unannotated tags should not be leaked out to public > > repos. But because this feature finds any reachable tags, it will push a > > tag you made a long time ago as a bookmarker on some part of the history > > unrelated to the release you are making now. > > What does the auto-follow feature of "git fetch" do currently? > Whatever we do here on the "git push" side should match it. It fetches anything in refs/tags, unannotated or not. And that is certainly a point in favor of "git push" doing the same. But I wonder if fetching and pushing are different in that respect. You are (usually) fetching from a public publishing point, and it is assumed that whatever is there is useful for sharing. The only reason to limit it is to save time transferring objects the user does not want. But for "push", you are on the publishing side, which usually means you need to be a little more careful. It is not just an optimization; it is about deciding what should be shared. You do not want to accidentally push cruft or work in progress in your private repository. I think it's the same logic that leads us to fetch "refs/heads/*" by default, but only push "matching" (or more recently "HEAD"). > If somebody wants to add some form of filtering mechanism based on > the tagname (e.g. '--auto-follow-tags=v[0-9]*'), I would not have a > strong objection to it, but I think that is something we should do > on top and consistently between fetch and push. I am not thrilled > by the idea of conflating annotated-ness and the public-ness of > tags. I don't like it either. But I also don't want to introduce a feature that causes people to accidentally publish cruft. It may not be a problem in practice; I'm just thinking out loud at this point. -Peff -- 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] Fix `make install` when configured with autoconf
Thanks. -- 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] git-completion.zsh: define __gitcomp_file compatibility function
Matthieu Moy writes:
> Commit fea16b47b60 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
> git-completion.bash: add support for path completion), introduced a new
> __gitcomp_file function that uses the bash builtin "compgen". The
> function was redefined for ZSH in the deprecated section of
> git-completion.bash, but not in the new git-completion.zsh script.
>
> As a result, users of git-completion.zsh trying to complete "git add
> fo" get an error:
>
> git add fo__gitcomp_file:8: command not found: compgen
>
> This patch adds the redefinition and removes the error.
>
> Signed-off-by: Matthieu Moy
> ---
>> Felipe, you know ZSH completion much better than me. Could you turn this
>> into a real patch?
>
> No response from Felipe, so I'm trying my own patch. Compared to the
> snippet I already sent, I added the -f option to "compadd", which was
> there in the __gitcomp_file function defined in the deprecated ZSH
> compatibility section of the bash script, and gives the ZSH equivalent
> for "compopt -o filenames".
>
> This fixes an annoying regression for ZSH users, so it may deserve to
> be in the future 1.8.2.
Thanks, and I agree a fix to this issue should be fast-tracked.
>
> contrib/completion/git-completion.zsh | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/contrib/completion/git-completion.zsh
> b/contrib/completion/git-completion.zsh
> index 4577502..cf8116d 100644
> --- a/contrib/completion/git-completion.zsh
> +++ b/contrib/completion/git-completion.zsh
> @@ -60,6 +60,15 @@ __gitcomp_nl ()
> compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
> }
>
> +__gitcomp_file ()
> +{
> + emulate -L zsh
> +
> + local IFS=$'\n'
> + compset -P '*[=:]'
> + compadd -Q -p "${2-}" -f -- ${=1} && _ret=0
> +}
> +
> _git ()
> {
> local _ret=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] help: show manpage for aliased command on git --help
"H.Merijn Brand" writes: > A single word that is (already) known to git as being a valid command > to do --help with. I which case I fully agree. Just to insist on "that is known to git as being a valid command". Compare: $ git foo --help `git foo' is aliased to `bar' with $ git foo --help No manual entry for gitbar -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] help: show manpage for aliased command on git --help
Ævar Arnfjörð Bjarmason writes: > No objection to the patch in principle though? I.e. not showing you > what the alias points to. I am not interested enough to even strongly object to such a change, because it is not reasonable to react with a "I know!" to the output of "git co --help", i.e. "'git co' is aliased to 'checkout'", in the first place. Also some users may find it inconsistent if a single bareword jumps directly to the manpage and other input shows alias expansion. So,... I do not see a very big plus in the proposed (and then amended by others in the thread) change, but if the damage to the code that is necessary to implement it is not too bad, perhaps it is an OK thing to do. I don't know without seeing the 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/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
On Tue, Mar 5, 2013 at 10:09 AM, Junio C Hamano wrote: > Heiko Voigt writes: > >> On Mon, Mar 04, 2013 at 03:00:45PM -0800, Junio C Hamano wrote: >>> So if you want a single boolean to toggle between the current >>> behaviour and the other one, it would be --post-order. But you may >>> at least want to consider pros and cons of allowing users to give >>> two separate commands, one for the pre-order visitation (which is >>> the current "command") and the other for the post-order >>> visitation. Being able to run both might turn out to be useful. >> >> I second that. Having a --post-order= switch will give >> us much more flexibility. For ease of use we could allow --post-order >> without command to switch the meaning of the main command. >> >> So a final solution would have these switches: >> >> git submodule foreach ... [--pre-order[=]] >> [--post-order[=]] [] >> >> If only --pre-order without argument is given the command will be >> executed pre-order. If only --post-order the command will be executed >> post-order. If both are given its an error and so on... >> >> There are some combinations we would need to catch as errors but this >> design should allow a step by step implementation: >> >> 1. just the --post-order switch >> 2. --post-order with argument switch >> 3. --pre-order (including argument) for symmetry of usage > > Yeah, I think I can agree with that direction, and Eric's patch > could be that first step of the three-step progression, without > painting us into a corner we cannot get out of when we want to > advance to 2 and 3 later. > > I was more interested in the design aspect and I didn't look at the > actual patch text, though. Would these be the correct behaviors of Heiko's implementation? git submodule foreach # Empty command, pre-order git submodule foreach --pre-order # Same behavior git submodule foreach --post-order # Empty command, post-order git submodule foreach 'frotz' # Do 'frotz' pre-order in each submodule git submodule foreach --post-order 'frotz' # Do 'frotz' post-order in each submodule git submodule foreach --pre-order='frotz' --post-order='shimmy' # Do 'frotz' pre-order and 'shimmy' post-order in each submodule git submodule foreach --post-order='shimmy' 'frotz' # Invalid usage of the command git submodule foreach --post-order --pre-order # It should not be too hard to have this functionality affect the --include-super command as well. And would it be worth it to abstract this traversal to expose it to other commands, such as 'update', to consolidate the code some? I think Imram was doing something like that in his post. - Eric -- 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] help: show manpage for aliased command on git --help
On Tue, Mar 5, 2013 at 5:16 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Change the semantics of "git --help" to show the help for the >> command is aliased to, instead of just saying: >> >> `git ' is aliased to `' >> >> E.g. if you have "checkout" aliased to "co" you won't get: >> >> $ git co --help >> `git co' is aliased to `checkout' > > If you had "lg" aliased to "log --oneline" and you made > > $ git lg --help > > to give anything but > > 'git lg' is aliased to `log --oneline' > > I would say that is a grave regression. Good point. I'll fix that up. No objection to the patch in principle though? I.e. not showing you what the alias points to. -- 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] help: show manpage for aliased command on git --help
Ævar Arnfjörð Bjarmason writes: > Change the semantics of "git --help" to show the help for the > command is aliased to, instead of just saying: > > `git ' is aliased to `' > > E.g. if you have "checkout" aliased to "co" you won't get: > > $ git co --help > `git co' is aliased to `checkout' If you had "lg" aliased to "log --oneline" and you made $ git lg --help to give anything but 'git lg' is aliased to `log --oneline' I would say that is a grave regression. -- 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] Extend runtime prefix computation
Michael Weiser writes: > On Tue, Nov 27, 2012 at 05:30:04PM +0100, Michael Weiser wrote: > >> Support determining the binaries' installation path at runtime even if >> called without any path components (i.e. via search path). Implement >> fallback to compiled-in prefix if determination fails or is impossible. > > I see this hasn't made it into git, yet. Is there any reason? Most likely nobody was interested. The default for any change is not to include it. Is there any reason why we want this change? -- 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/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
Heiko Voigt writes: > On Mon, Mar 04, 2013 at 03:00:45PM -0800, Junio C Hamano wrote: >> So if you want a single boolean to toggle between the current >> behaviour and the other one, it would be --post-order. But you may >> at least want to consider pros and cons of allowing users to give >> two separate commands, one for the pre-order visitation (which is >> the current "command") and the other for the post-order >> visitation. Being able to run both might turn out to be useful. > > I second that. Having a --post-order= switch will give > us much more flexibility. For ease of use we could allow --post-order > without command to switch the meaning of the main command. > > So a final solution would have these switches: > > git submodule foreach ... [--pre-order[=]] > [--post-order[=]] [] > > If only --pre-order without argument is given the command will be > executed pre-order. If only --post-order the command will be executed > post-order. If both are given its an error and so on... > > There are some combinations we would need to catch as errors but this > design should allow a step by step implementation: > > 1. just the --post-order switch > 2. --post-order with argument switch > 3. --pre-order (including argument) for symmetry of usage Yeah, I think I can agree with that direction, and Eric's patch could be that first step of the three-step progression, without painting us into a corner we cannot get out of when we want to advance to 2 and 3 later. I was more interested in the design aspect and I didn't look at the actual patch text, though. -- 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] help: show manpage for aliased command on git --help
On Tue, 05 Mar 2013 16:42:52 +0100, Johannes Sixt
wrote:
> Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> > Change the semantics of "git --help" to show the help for the
> > command is aliased to, instead of just saying:
> >
> > `git ' is aliased to `'
> >
> > E.g. if you have "checkout" aliased to "co" you won't get:
> >
> > $ git co --help
> > `git co' is aliased to `checkout'
> >
> > But will instead get the manpage for git-checkout.
> ...
> > alias = alias_lookup(argv[0]);
> > if (alias && !is_git_command(argv[0])) {
> > - printf_ln(_("`git %s' is aliased to `%s'"), argv[0], alias);
> > - return 0;
> > + show_help_for = alias;
> > + } else {
> > + show_help_for = argv[0];
> > }
>
> This needs a lot more scrutiny. The alias can be more than just a single
> word, and it can even be a shell scriptlet, i.e., not a git command at all.
>
> It may make sense to show the help of the aliased-to command if the alias
> resolves to just a single word.
A single word that is (already) known to git as being a valid command
to do --help with. I which case I fully agree.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
--
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 2/2] push: --follow-tag
Jeff King writes: > Should this be called "--follow-tags"? That makes more sense to me, as > you are catching all tags. Perhaps. We are sending all zero-or-more relevant tags, so I agree that plural form is more appropriate. I have a doubt about "follow", though; inertia made me use "follow", but I am not sure what we are following. We certainly are not following tags. If anything, we are making tags to piggy back on the history being pushed. > For consistency, should this match the naming of git-fetch's > options (or vice versa)? There we have: > > : auto-follow tags > > --tags: fetch all of refs/heads/tags > > --no-tags: do not auto-follow > > I think that naming has caused some confusion in the past. "--tags" does not belong in the discussion of "auto following". It does not have to do with any "auto"-ness. Renaming "--no-tags" to "--no-follow-tags" does make sense, though. > And there is no way to explicitly specify the default behavior. I > wonder if both should support: > > --follow-tags: auto-follow tags > > --no-follow-tags: do not auto-follow tags Yup, I like that. Perhaps make "--no-tags" a deprecated synonym to the latter. > --tags: fetch/push all of refs/heads/tags > > --no-tags: turn off auto-following, and cancel any previous --tags Sounds sensible. > The default for push should probably keep auto-follow off, though. > >> +--follow-tag:: >> +Push all the refs that would be pushed without this option, >> +and also push the refs under `refs/tags` that are missing >> +from the remote but are reachable from the refs that would >> +be pushed without this option. >> + > > This reads OK to me, though it is a little confusing in that there are > two sets of refs being discussed, and "the refs that would be pushed > without this option" is quite a long noun phrase (that gets used twice). Yes, exactly why I said I do not like the phrasing of this one. > This will find anything under refs/tags, including annotated and > non-annotated tags. I wonder if it is worth making a distinction. In > many workflows, unannotated tags should not be leaked out to public > repos. But because this feature finds any reachable tags, it will push a > tag you made a long time ago as a bookmarker on some part of the history > unrelated to the release you are making now. What does the auto-follow feature of "git fetch" do currently? Whatever we do here on the "git push" side should match it. If somebody wants to add some form of filtering mechanism based on the tagname (e.g. '--auto-follow-tags=v[0-9]*'), I would not have a strong objection to it, but I think that is something we should do on top and consistently between fetch and push. I am not thrilled by the idea of conflating annotated-ness and the public-ness of tags. Thanks. -- 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 v6] submodule: add 'deinit' command
Heiko Voigt writes: >> +if test -z "$force" >> +then >> +git rm -n "$sm_path" || >> +die "$(eval_gettext "Submodule work tree >> '\$sm_path' contains local modifications; use '-f' to discard them")" > > Minor nit. IMO, there is an indentation for the || missing here. Maybe > Junio can squash that in on his side? Sorry, but I do not see an indentation nit here. The format looks perfectly sane to me and in fact any other indentation would be wrong. Puzzled... -- 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: auto merge bug
Jeff King writes: > I think the merge will produce the results you are looking for. This > would have to be configurable, though, as it is a regression for > existing users of "union", which would want the duplicate-line > suppression (or maybe not; it will only catch such duplicates at the > beginning and end of the conflict hunk, so maybe it is sane to always > ask "union" to keep all lines). The original use-case example of "union" was to merge two shopping lists (e.g. I add "bread" and "orange juice" to remind me that we need to buy these things, while my wife adds "bread" and "butter"). We do not necessarily want to end up with a shopping list to buy two loaves of bread. When the user verifies and fixes up the result, we can keep the current behaviour and those who want to re-dup can add one back, or we can change the behaviour to leave the duplicates and those who do not want to see duplicates can remove them manually. Given that the caveat you quoted already tells the user to verify the result and not to use it without understanding its implications, I think it technically is fine either way (read: keeping duplicates is not a clearly superiour solution). So let's leave it as-is. -- 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] help: show manpage for aliased command on git --help
Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> Change the semantics of "git --help" to show the help for the
> command is aliased to, instead of just saying:
>
> `git ' is aliased to `'
>
> E.g. if you have "checkout" aliased to "co" you won't get:
>
> $ git co --help
> `git co' is aliased to `checkout'
>
> But will instead get the manpage for git-checkout.
...
> alias = alias_lookup(argv[0]);
> if (alias && !is_git_command(argv[0])) {
> - printf_ln(_("`git %s' is aliased to `%s'"), argv[0], alias);
> - return 0;
> + show_help_for = alias;
> + } else {
> + show_help_for = argv[0];
> }
This needs a lot more scrutiny. The alias can be more than just a single
word, and it can even be a shell scriptlet, i.e., not a git command at all.
It may make sense to show the help of the aliased-to command if the alias
resolves to just a single word.
-- Hannes
--
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: "git commit" fails due to spurious file in index
Nope, it was a bug in my pre-commit hook. See the other response to this
message.
Robert Irelan | Server Systems | Epic | (608) 271-9000
-Original Message-
From: Torsten Bögershausen [mailto:tbo...@web.de]
Sent: Tuesday, March 05, 2013 4:41 AM
To: Robert Irelan
Cc: git@vger.kernel.org
Subject: Re: "git commit" fails due to spurious file in index
On 04.03.13 19:15, Robert Irelan wrote:
> Hello all:
>
> This is my first time posting to this mailing list, but it appears to
> me, through a Google search, that this is where you go to report what
> might be bugs. I'm not sure if this is a bug or not, but it is
> mysterious to me.
>
> My git repository has this directory structure (I don't know if the
> file names are necessary or not; only the leaf directories contain files):
>
> $ tree -ad -I.git
> .
> └── admin_scripts
> ├── integchk
> │ ├── 2012
> │ └── 2014
> ├── jrnadmin
> │ ├── 2012
> │ └── 2014
> └── logarchiver
> ├── 2012
> └── 2014
>
> 10 directories
>
> The last commit in this repo was a rearrangement of the hierarchy
> carried out using `git mv`. Before, the directory structure went
> `admin_scripts/version/script_name` instead of
> `admin_scripts/script_name/version`.
>
> Now I'm attempting to some new files that I've already created into
> the repository, so that the repo now looks like this (`setup/2012`
> contains files, while `setup/2014` is empty):
>
> $ tree -ad -I.git
> .
> └── admin_scripts
> ├── integchk
> │ ├── 2012
> │ └── 2014
> ├── jrnadmin
> │ ├── 2012
> │ └── 2014
> ├── logarchiver
> │ ├── 2012
> │ └── 2014
> └── setup
> ├── 2012
> └── 2014
>
> 13 directories
>
> Now, when I run 'git add admin_script/setup' to add the new directory
> to the repo and then try to commit, I receive the following message:
>
> $ git commit
> mv: cannot stat `admin_scripts/setup/2012/setup': No such file or
> directory
>
> The error message is correct in that `admin_scripts/setup/2012/setup`
> does not exist, either as a file or as a directory. However, I'm not
> attempting to add this path at all. Using grep, I've confirmed that
> the only place this path appears in any of my files is in `.git/index`.
>
> Also, I can commit to other places in the repository without
> triggering any error. In addition, I can clone the repository to other
> locations and apply the problematic commit manually. This is how I've
> worked around the problem for now, and I've moved the repository
> that's exhibiting problems to another directory and started work on
> the cloned copy.
>
> Why is this spurious path appearing in the index? Is it a bug, or a
> symptom that my repo has been somehow corrupted? Any help would be
> greatly appreciated.
>
> Robert Irelan | Server Systems | Epic | (608) 271-9000
You have come to the right group.
It might be difficult to tell (at least for me) if there is a bug or a
corruption, May be some tests could help to bring more light into the darkness:
What does "git status" (in the problematic repo) tell you?
What does "git fsck" (in the problematic repo) tell you?
What does "git ls-files" (in both repos) tell you?
/Torsten
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf
RE: "git commit" fails due to spurious file in index
Yes, you're correct, it was a bug in my pre-commit hook. Thanks!
For posterity, the issue is that I had the following line:
git diff -z --cached --name-only | egrep -z '\.(pl|pm|t)$' | \
while read -d'' -r f; do ...
In Bash, when `read` is passed the `-d` option with a zero-length
string argument, read will split on null characters (`'\0'`). However,
I did not put a space between the `-d` option and the argument, so
it took the `-` in the next argument `-r` as the delimiter. My commit
includes Perl files with `-` characters in the name, which I had not
previously committed to this repo, which is why I only ran into the
problem now. I fixed it by changing the read command to
`read -r -d '' f`, which now has the crucial space between -d and
its argument, making the zero-length string a separate argument.
Robert Irelan | Server Systems | Epic | (608) 271-9000
-Original Message-
From: Thomas Rast [mailto:tr...@student.ethz.ch]
Sent: Monday, March 04, 2013 2:59 PM
To: Robert Irelan
Cc: git@vger.kernel.org
Subject: Re: "git commit" fails due to spurious file in index
Robert Irelan writes:
> Now, when I run 'git add admin_script/setup' to add the new directory
> to the repo and then try to commit, I receive the following message:
>
> $ git commit
> mv: cannot stat `admin_scripts/setup/2012/setup': No such file or
> directory
>
> The error message is correct in that `admin_scripts/setup/2012/setup`
> does not exist, either as a file or as a directory. However, I'm not
> attempting to add this path at all. Using grep, I've confirmed that
> the only place this path appears in any of my files is in `.git/index`.
To me that sounds like the message comes from a commit hook. Can you check if
you have anything in .git/hooks/, especially pre-commit?
There really isn't any other good reason why 'git commit' would call 'mv'
(plain mv, not git!).
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: [BUG] Incorrect/misleading error when `git rev-list --objects --all` hits the max open files limit
rab...@rabbit.us wrote on Mon, 04 Mar 2013 10:29 +1100: > I was tinkering with a massive git repository (actually a bup > repository, but it is a standard valid git repo underneath). While > validating that a repack ran succesfully I executed the command: > > git rev-list --objects --all > rev.list > > And got back this: > > error: packfile > ./objects/pack/pack-d9808b7515419737806d0c621a0a1910f71c5cba.pack cannot be > accessed > fatal: missing blob object '27a8cf44da85b958aef2b5074931e7913e08ae95' > > Several hours later after successful fsck, and after chasing down trees > blobs etc, I realized that the problem is too many open files. The hint > came from ls-tree which lists the correct error (among a lot of spurious > junk): > > git ls-tree -r c636a5f51d4e > /dev/null > > error: packfile > ./objects/pack/pack-d9808b7515419737806d0c621a0a1910f71c5cba.pack cannot be > accessed > error: packfile > ./objects/pack/pack-841e375f5e6c793a52fd1a3a2aea0b76219c4cdd.pack cannot be > accessed > error: packfile > ./objects/pack/pack-e67d9bf75e0840fc6113170b314d2d5a32cbb45a.pack cannot be > accessed > error: packfile > ./objects/pack/pack-b8fd8f083461c391fe6ec396840c328620d912e2.pack cannot be > accessed > error: packfile > ./objects/pack/pack-d9808b7515419737806d0c621a0a1910f71c5cba.pack cannot be > accessed > error: packfile > ./objects/pack/pack-804e0fadf56e2a165c157ef257620369adeea595.pack cannot be > accessed > error: unable to open object pack directory: ./objects/pack: Too many open > files > error: packfile > ./objects/pack/pack-804e0fadf56e2a165c157ef257620369adeea595.pack cannot be > accessed > error: Could not read 32a050cb7e54a1e817d135d25ab251480e8d9e3c > > Failure to report the correct message verified with git 1.7.2.5 and > 1.8.2 (debian testing and experimental). > > I hope this is sufficient description to address the underlying issue. I > will keep the un-repacked "many files" repo around just in case you need > more info/testing (though lowering the ulimit works equally well on > normal-size repos). I've run into this twice: 1. user with restrictive ulimit on #files. 2. forgot to do "git gc" after regular fast-imports Here's one thread: http://thread.gmane.org/gmane.comp.version-control.git/179231/focus=179292 I've got a patch in cold storage. It's not beautiful because there are too many paths that can end up hitting EMFILE. I'll dust it off and see if it is worth considering. -- Pete -- 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] help: show manpage for aliased command on git --help
Change the semantics of "git --help" to show the help for the
command is aliased to, instead of just saying:
`git ' is aliased to `'
E.g. if you have "checkout" aliased to "co" you won't get:
$ git co --help
`git co' is aliased to `checkout'
But will instead get the manpage for git-checkout. The behavior this
is replacing was originally added by Jeff King in 2156435. I'm
changing it because of this off-the-cuff comment on IRC:
14:27:43 <@Tux> git can be very unhelpful, literally:
14:27:46 <@Tux> $ git co --help
14:27:46 <@Tux> `git co' is aliased to `checkout'
14:28:08 <@Tux> I know!, gimme the help for checkout, please
And because I also think it makes more sense than showing you what the
thing is aliased to.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
builtin/help.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index d1d7181..fdb3312 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -417,6 +417,7 @@ int cmd_help(int argc, const char **argv, const char
*prefix)
{
int nongit;
const char *alias;
+ const char *show_help_for;
enum help_format parsed_help_format;
load_command_list("git-", &main_cmds, &other_cmds);
@@ -449,20 +450,21 @@ int cmd_help(int argc, const char **argv, const char
*prefix)
alias = alias_lookup(argv[0]);
if (alias && !is_git_command(argv[0])) {
- printf_ln(_("`git %s' is aliased to `%s'"), argv[0], alias);
- return 0;
+ show_help_for = alias;
+ } else {
+ show_help_for = argv[0];
}
switch (help_format) {
case HELP_FORMAT_NONE:
case HELP_FORMAT_MAN:
- show_man_page(argv[0]);
+ show_man_page(show_help_for);
break;
case HELP_FORMAT_INFO:
- show_info_page(argv[0]);
+ show_info_page(show_help_for);
break;
case HELP_FORMAT_WEB:
- show_html_page(argv[0]);
+ show_html_page(show_help_for);
break;
}
--
1.7.10.4
--
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] Fix `make install` when configured with autoconf
Commit d8cf908c (config.mak.in: remove unused definitions) removed
exec_prefix = @exec_prefix@
from config.mak.in, because nobody directly used ${exec_prefix}, but
overlooked that other autoconf definitions could indirectly expand that
variable.
For example the following snippet from config.mak.in
prefix = @prefix@
bindir = @bindir@
gitexecdir = @libexecdir@/git-core
datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates
sysconfdir = @sysconfdir@
is expanded to
prefix = /home/kirr/local/git
bindir = ${exec_prefix}/bin <-- HERE
gitexecdir = ${exec_prefix}/libexec/git-core<--
datarootdir = ${prefix}/share
template_dir = ${datarootdir}/git-core/templates
sysconfdir = ${prefix}/etc
on my system, after `configure --prefix=$HOME/local/git`
and withot exec_prefix being defined there I get an error on
install:
install -d -m 755 '/bin'
install -d -m 755 '/libexec/git-core'
install: cannot create directory `/libexec': Permission denied
Makefile:2292: recipe for target `install' failed
Fix it.
Signed-off-by: Kirill Smelkov
---
config.mak.in | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.in b/config.mak.in
index 7440687..e6a6d0f 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -12,6 +12,7 @@ PACKAGE_TARNAME = @PACKAGE_TARNAME@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
prefix = @prefix@
+exec_prefix = @exec_prefix@
bindir = @bindir@
gitexecdir = @libexecdir@/git-core
datarootdir = @datarootdir@
--
1.8.2.rc2.353.gd2380b4
--
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 4/5] status: show the ref that is checked out, even if it's detached
Duy Nguyen writes: > - # Not currently on any branch. > + # Detached at $ONTO Without the context, I don't think "Detached" alone says something to the user. "Detached HEAD at ..." would IMHO be clearer and at least give the user enough keywords to search the web/doc for an explanation. Actually, in the case of "Detached HEAD at $branch", you may even add an advice saying something like: (run "git checkout $branch" to switch to branch $branch) or so. But that's not the common case, so maybe it's not that useful. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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] Extend runtime prefix computation
Hello, On Tue, Nov 27, 2012 at 05:30:04PM +0100, Michael Weiser wrote: > Support determining the binaries' installation path at runtime even if > called without any path components (i.e. via search path). Implement > fallback to compiled-in prefix if determination fails or is impossible. I see this hasn't made it into git, yet. Is there any reason? What can I do to get it included? Thanks, -- Michael Weiserscience + computing ag Senior Systems Engineer Geschaeftsstelle Duesseldorf Martinstrasse 47-55, Haus A phone: +49 211 302 708 32 D-40223 Duesseldorf fax: +49 211 302 708 50 www.science-computing.de -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- 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 2/2] push: --follow-tag
On 03/05/2013 09:22 AM, Jeff King wrote: > On Mon, Mar 04, 2013 at 04:54:39PM -0800, Junio C Hamano wrote: > [...] > This will find anything under refs/tags, including annotated and > non-annotated tags. I wonder if it is worth making a distinction. In > many workflows, unannotated tags should not be leaked out to public > repos. But because this feature finds any reachable tags, it will push a > tag you made a long time ago as a bookmarker on some part of the history > unrelated to the release you are making now. > > One obvious alternative is only to push annotated tags with this > feature. That has the downside of not matching fetch's behavior, as well > as withholding the feature from people whose workflow uses only > unannotated tags. > > Another alternative would be to change the inclusion rule from > "reachable" to "points at the tip of something being sent". But then we > lose the feature that it would backfill any old tags the remote happens > to be missing. I have no opinion on this matter, but ISTM that another obvious alternative would be to push tags that point at *any* commits that are being sent (not just at the tip), but not those that point to older commits already known to the server. This would reduce the potential for accidental pushes of "distant" tags. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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 4/5] status: show the ref that is checked out, even if it's detached
OK new try. This - no longer requires 1/5 (i'll resend full series later when the wanted behavior is found) - shows either "detached from" or "detached at". We could even do "4 commits from detached point XXX", like we do "5 commits ahead of upstream". But I'm not sure if we should do that. - otherwise shows "detached from ". IOW "currently not on any branch" is no longer shown. - fixes the case when reflog is too short and for_each_recent_reflog_ent returns false. I did not merge grab_1st_switch and grab_nth_branch_switch because they use different part of the reflog and merging seems to make it more complicated than necessary. -- 8< -- Subject: [PATCH] status: show more info than "currently not on any branch" When a remote ref or a tag is checked out, HEAD is automatically detached. There is no user friendly way to find out what ref is checked out in this case. This patch digs in reflog for this information and shows "Detached from/at origin/master" or "Detached from/at v1.8.0". When it cannot figure out the original ref, it shows an abbreviated SHA-1 instead. "Currently not on any branch" would never display. Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t7406-submodule-update.sh | 6 ++-- t/t7512-status-help.sh | 52 +-- wt-status.c | 87 ++--- wt-status.h | 4 ++- 4 files changed, 123 insertions(+), 26 deletions(-) diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index 4975ec0..50ac020 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -664,8 +664,10 @@ test_expect_success 'submodule add properly re-creates deeper level submodules' test_expect_success 'submodule update properly revives a moved submodule' ' (cd super && +H=$(git rev-parse --short HEAD) && git commit -am "pre move" && -git status >expect&& +H2=$(git rev-parse --short HEAD) && +git status | sed "s/$H/XXX/" >expect && H=$(cd submodule2; git rev-parse HEAD) && git rm --cached submodule2 && rm -rf submodule2 && @@ -674,7 +676,7 @@ test_expect_success 'submodule update properly revives a moved submodule' ' git config -f .gitmodules submodule.submodule2.path "moved/sub module" git commit -am "post move" && git submodule update && -git status >actual && +git status | sed "s/$H2/XXX/" >actual && test_cmp expect actual ) ' diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh index d2da89a..c4f030f 100755 --- a/t/t7512-status-help.sh +++ b/t/t7512-status-help.sh @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' ONTO=$(git rev-parse --short HEAD^^) && test_must_fail git rebase HEAD^ --onto HEAD^^ && cat >expected <<-EOF && - # Not currently on any branch. + # Detached at $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (fix conflicts and then run "git rebase --continue") # (use "git rebase --skip" to skip this patch) @@ -103,7 +103,7 @@ test_expect_success 'status when rebase in progress before rebase --continue' ' echo three >main.txt && git add main.txt && cat >expected <<-EOF && - # Not currently on any branch. + # Detached at $ONTO # You are currently rebasing branch '\''rebase_conflicts'\'' on '\''$ONTO'\''. # (all conflicts fixed: run "git rebase --continue") # @@ -135,7 +135,7 @@ test_expect_success 'status during rebase -i when conflicts unresolved' ' ONTO=$(git rev-parse --short rebase_i_conflicts) && test_must_fail git rebase -i rebase_i_conflicts && cat >expected <<-EOF && - # Not currently on any branch. + # Detached at $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (fix conflicts and then run "git rebase --continue") # (use "git rebase --skip" to skip this patch) @@ -161,7 +161,7 @@ test_expect_success 'status during rebase -i after resolving conflicts' ' test_must_fail git rebase -i rebase_i_conflicts && git add main.txt && cat >expected <<-EOF && - # Not currently on any branch. + # Detached at $ONTO # You are currently rebasing branch '\''rebase_i_conflicts_second'\'' on '\''$ONTO'\''. # (all conflicts fixed: run "git rebase --continue") # @@ -187,9 +187,10 @@ test_expect_success 'status when rebasing -i in edit mode' ' export FAKE_LINES && test_when_finished "git rebase --abort" && ONTO=$(git rev-parse --short HEAD~2) && + TGT=$(git rev-parse --short two_rebase_i) && git rebase -i HEAD~2 && cat >expected <<-EOF && - # Not currently on any branch. + # Detached from $TGT
Re: "git commit" fails due to spurious file in index
On 04.03.13 19:15, Robert Irelan wrote: > Hello all: > > This is my first time posting to this mailing list, but it appears to > me, through a Google search, that this is where you go to report what > might be bugs. I'm not sure if this is a bug or not, but it is > mysterious to me. > > My git repository has this directory structure (I don't know if the file > names are necessary or not; only the leaf directories contain files): > > $ tree -ad -I.git > . > └── admin_scripts > ├── integchk > │ ├── 2012 > │ └── 2014 > ├── jrnadmin > │ ├── 2012 > │ └── 2014 > └── logarchiver > ├── 2012 > └── 2014 > > 10 directories > > The last commit in this repo was a rearrangement of the hierarchy > carried out using `git mv`. Before, the directory structure went > `admin_scripts/version/script_name` instead of > `admin_scripts/script_name/version`. > > Now I'm attempting to some new files that I've already created into the > repository, so that the repo now looks like this (`setup/2012` > contains files, while `setup/2014` is empty): > > $ tree -ad -I.git > . > └── admin_scripts > ├── integchk > │ ├── 2012 > │ └── 2014 > ├── jrnadmin > │ ├── 2012 > │ └── 2014 > ├── logarchiver > │ ├── 2012 > │ └── 2014 > └── setup > ├── 2012 > └── 2014 > > 13 directories > > Now, when I run 'git add admin_script/setup' to add the new directory to > the repo and then try to commit, I receive the following message: > > $ git commit > mv: cannot stat `admin_scripts/setup/2012/setup': No such file or > directory > > The error message is correct in that `admin_scripts/setup/2012/setup` > does not exist, either as a file or as a directory. However, I'm not > attempting to add this path at all. Using grep, I've confirmed that the > only place this path appears in any of my files is in `.git/index`. > > Also, I can commit to other places in the repository without triggering > any error. In addition, I can clone the repository to other locations > and apply the problematic commit manually. This is how I've worked > around the problem for now, and I've moved the repository that's > exhibiting problems to another directory and started work on the cloned > copy. > > Why is this spurious path appearing in the index? Is it a bug, or a > symptom that my repo has been somehow corrupted? Any help would be > greatly appreciated. > > Robert Irelan | Server Systems | Epic | (608) 271-9000 You have come to the right group. It might be difficult to tell (at least for me) if there is a bug or a corruption, May be some tests could help to bring more light into the darkness: What does "git status" (in the problematic repo) tell you? What does "git fsck" (in the problematic repo) tell you? What does "git ls-files" (in both repos) tell you? /Torsten -- 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: Configurable .gitignore filename?
2013/3/5 David Aguilar : > On Mon, Mar 4, 2013 at 7:47 AM, Jari Pennanen wrote: >> I'm actually aware of that. Problem is the normal .gitignore files >> must *not* be used in the second GIT_DIR at all, in my case it's for >> syncing so I need to sync almost all files (including stuff inside >> .gitignore), though I'd still like to retain some ignore files for >> second GIT_DIR, e.g. like in rsync the .rsync-filter file. > > How about .git/info/exclude in the 2nd GIT_DIR? Would that help? The second GIT_DIR must not use the .gitignore files of the first GIT_DIR, so it does not help. Only way to skip the .gitignore files in git-add is to use "git add -f ." but that skips all excludes, including the .git/info/exclude. I need to skip .gitignore files used by the other GIT_DIR and still have some of ignore rules, IMO this is not possible at the moment. -- 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: Configurable .gitignore filename?
On Mon, Mar 4, 2013 at 7:47 AM, Jari Pennanen wrote: > 2013/3/4 Matthieu Moy : >> There is already core.excludesfile, which does not replace the usual >> .gitignore but comes in addition. The common use is a user-wide ignore >> file, not a per-directory one. > > I'm actually aware of that. Problem is the normal .gitignore files > must *not* be used in the second GIT_DIR at all, in my case it's for > syncing so I need to sync almost all files (including stuff inside > .gitignore), though I'd still like to retain some ignore files for > second GIT_DIR, e.g. like in rsync the .rsync-filter file. How about .git/info/exclude in the 2nd GIT_DIR? Would that help? -- David -- 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: Fwd: Strange remote interaction
> In a usual set-up, an access to git@server:javier/pfc will first > locate the home directory for the user "git" (the token before "@"), > and then its subdirectory javier/pfc, e.g. /home/git/javier/pfc, > while an access to server:javier/pfc will first locate the home > directory of whatever username the ssh connection uses by default > (typically the local user but ~/.ssh/config may have "User" > directive for the server) and then its subdirectory javier/pfc, > e.g. /home/javier/javier/pfc. These two may be different locations. > > Do these two commands show the same output? > > $ git ls-remote git@server:javier/pfc refs/heads/master > $ git ls-remote server:javier/pfc refs/heads/master > > If the above conjecture is correct, I suspect they don't. I have a gitolite setup there, so it is imposible the give the same output. Anyways, as I don't have a user in the server machine, the second fails. $ git ls-remote git@server:javier/pfc 22692a2d69d3138b7ccebd64e72c66ea8bf69e9f HEAD 22692a2d69d3138b7ccebd64e72c66ea8bf69e9f refs/heads/master It is the first time I encounter such a problem. -- 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: auto merge bug
On Tue, Mar 05, 2013 at 04:03:26AM -0500, Jeff King wrote:
> You might be able to get by with a version of the "union" driver that
> asks the 3-way merge driver to be less aggressive about shrinking the
> conflict blocks. For example, with this patch to git:
>
> diff --git a/ll-merge.c b/ll-merge.c
> index fb61ea6..61b1d4e 100644
> --- a/ll-merge.c
> +++ b/ll-merge.c
> @@ -100,7 +100,6 @@ static int ll_xdl_merge(const struct ll_merge_driver
> *drv_unused,
> }
>
> memset(&xmp, 0, sizeof(xmp));
> - xmp.level = XDL_MERGE_ZEALOUS;
> xmp.favor = opts->variant;
> xmp.xpp.flags = opts->xdl_opts;
> if (git_xmerge_style >= 0)
>
> I think the merge will produce the results you are looking for. This
> would have to be configurable, though, as it is a regression for
> existing users of "union", which would want the duplicate-line
> suppression (or maybe not; it will only catch such duplicates at the
> beginning and end of the conflict hunk, so maybe it is sane to always
> ask "union" to keep all lines).
Here's what the patch would look like to make it non-configurable, but
to just trigger for the "union" case:
diff --git a/ll-merge.c b/ll-merge.c
index fb61ea6..fc33a23 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -83,7 +83,8 @@ static int ll_xdl_merge(const struct ll_merge_driver
*drv_unused,
mmfile_t *src1, const char *name1,
mmfile_t *src2, const char *name2,
const struct ll_merge_options *opts,
- int marker_size)
+ int marker_size,
+ int level)
{
xmparam_t xmp;
assert(opts);
@@ -100,7 +101,7 @@ static int ll_xdl_merge(const struct ll_merge_driver
*drv_unused,
}
memset(&xmp, 0, sizeof(xmp));
- xmp.level = XDL_MERGE_ZEALOUS;
+ xmp.level = level;
xmp.favor = opts->variant;
xmp.xpp.flags = opts->xdl_opts;
if (git_xmerge_style >= 0)
@@ -129,7 +130,23 @@ static int ll_union_merge(const struct ll_merge_driver
*drv_unused,
o.variant = XDL_MERGE_FAVOR_UNION;
return ll_xdl_merge(drv_unused, result, path_unused,
orig, NULL, src1, NULL, src2, NULL,
- &o, marker_size);
+ &o, marker_size, XDL_MERGE_MINIMAL);
+}
+
+static int ll_text_merge(const struct ll_merge_driver *drv,
+mmbuffer_t *result,
+const char *path,
+mmfile_t *orig, const char *orig_name,
+mmfile_t *src1, const char *name1,
+mmfile_t *src2, const char *name2,
+const struct ll_merge_options *opts,
+int marker_size)
+{
+ return ll_xdl_merge(drv, result, path,
+ orig, orig_name,
+ src1, name1,
+ src2, name2,
+ opts, marker_size, XDL_MERGE_ZEALOUS);
}
#define LL_BINARY_MERGE 0
@@ -137,7 +154,7 @@ static struct ll_merge_driver ll_merge_drv[] = {
#define LL_UNION_MERGE 2
static struct ll_merge_driver ll_merge_drv[] = {
{ "binary", "built-in binary merge", ll_binary_merge },
- { "text", "built-in 3-way text merge", ll_xdl_merge },
+ { "text", "built-in 3-way text merge", ll_text_merge },
{ "union", "built-in union merge", ll_union_merge },
};
--
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: auto merge bug
On Mon, Mar 04, 2013 at 05:46:48PM +0100, David Krmpotic wrote: > We started working on a .NET app and the XML project file (.csproj) > got corrupted (a few closing tag missing). > > 79 > 80 SlovaricaForm.cs > 81+ > 82+ Form > 83+ > 84+ > 85+ WebCamForm.cs > 86 > > between lines 80 and 81 there should be > > [...] > > The problematic commit is here: > > https://github.com/davidhq/logo_x/commit/e3e5fa4b60b793b2a8c44330312755b72f93 Thanks for an easy-to-reproduce report. The problem here is that your .gitattributes file specifies the "union" merge driver for .csproj (and other) files. From "git help attributes": union Run 3-way file level merge for text files, but take lines from both versions, instead of leaving conflict markers. This tends to leave the added lines in the resulting file in random order and the user should verify the result. Do not use this if you do not understand the implications. Your stanzas each end on an identical line. So it sees that one side has: A B Z and the other side has: C D Z It realizes that the "Z" is common, so is not part of the conflict. But in the normal 3-way merge case, the rest of it conflicts, so you get a chance to inspect it. But with "union", it just silently concatenates the conflicting bits. I suspect you can run into other problems with "union" here, too, because line order _does_ matter for you. It comes close to working if both sides are just adding elements at the same level of the tree (as you are here), but what about more complicated edits? I think what you really want is an XML-aware merge tool that can see you just added two independent ... stanzas that can co-exist (i.e., it could do a union, but at the level of XML tags, not at the level of individual lines). I do not know offhand of any such tool (or for that matter, a good general XML-aware 3-way merge tool), but if you had one, you could plug it in as a custom merge driver. You might be able to get by with a version of the "union" driver that asks the 3-way merge driver to be less aggressive about shrinking the conflict blocks. For example, with this patch to git: diff --git a/ll-merge.c b/ll-merge.c index fb61ea6..61b1d4e 100644 --- a/ll-merge.c +++ b/ll-merge.c @@ -100,7 +100,6 @@ static int ll_xdl_merge(const struct ll_merge_driver *drv_unused, } memset(&xmp, 0, sizeof(xmp)); - xmp.level = XDL_MERGE_ZEALOUS; xmp.favor = opts->variant; xmp.xpp.flags = opts->xdl_opts; if (git_xmerge_style >= 0) I think the merge will produce the results you are looking for. This would have to be configurable, though, as it is a regression for existing users of "union", which would want the duplicate-line suppression (or maybe not; it will only catch such duplicates at the beginning and end of the conflict hunk, so maybe it is sane to always ask "union" to keep all lines). I'd still worry about more complicated edits fooling "union", but at least the simple cases would work. In the meantime, I think you are better to drop those "merge" gitattributes, and just let the regular three way merge generate a conflict which you can inspect. For the merge in question, it yields: diff --cc Logo/Logo.csproj index 4113434,c681862..000 --- a/Logo/Logo.csproj +++ b/Logo/Logo.csproj @@@ -67,17 -67,11 +67,25 @@@ ++<<< HEAD + + Form + + + MainForm.cs + + + Form + + + SlovaricaForm.cs ++=== + + Form + + + WebCamForm.cs ++>>> bd1a059 Form where you can see that it "shrinks" the conflict hunk to not include the line added by both sides (the file "" after the conflict). But by triggering a conflict, you can actually look at and fix it. That's more work, of course. Another alternate is to keep the "union" driver and just do better testing of merges. Even with the stock 3-way driver, a merge that auto-resolves is not necessarily correct (e.g., even if there are not textual conflicts, there may be semantic ones). -Peff -- 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] git-completion.zsh: define __gitcomp_file compatibility function
Commit fea16b47b60 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
git-completion.bash: add support for path completion), introduced a new
__gitcomp_file function that uses the bash builtin "compgen". The
function was redefined for ZSH in the deprecated section of
git-completion.bash, but not in the new git-completion.zsh script.
As a result, users of git-completion.zsh trying to complete "git add
fo" get an error:
git add fo__gitcomp_file:8: command not found: compgen
This patch adds the redefinition and removes the error.
Signed-off-by: Matthieu Moy
---
> Felipe, you know ZSH completion much better than me. Could you turn this
> into a real patch?
No response from Felipe, so I'm trying my own patch. Compared to the
snippet I already sent, I added the -f option to "compadd", which was
there in the __gitcomp_file function defined in the deprecated ZSH
compatibility section of the bash script, and gives the ZSH equivalent
for "compopt -o filenames".
This fixes an annoying regression for ZSH users, so it may deserve to
be in the future 1.8.2.
contrib/completion/git-completion.zsh | 9 +
1 file changed, 9 insertions(+)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 4577502..cf8116d 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -60,6 +60,15 @@ __gitcomp_nl ()
compadd -Q -S "${4- }" -p "${2-}" -- ${=1} && _ret=0
}
+__gitcomp_file ()
+{
+ emulate -L zsh
+
+ local IFS=$'\n'
+ compset -P '*[=:]'
+ compadd -Q -p "${2-}" -f -- ${=1} && _ret=0
+}
+
_git ()
{
local _ret=1
--
1.8.1.3.572.g35e1b60
--
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 2/2] push: --follow-tag
On Mon, Mar 04, 2013 at 04:54:39PM -0800, Junio C Hamano wrote:
>This is primarily to scratch my own itch; after tagging an rc or
>final release, I've been doing
>
> git push k.org v1.8.2
> git push k.org
>
>and the first step can easily be forgotten. With
>
> git push k.org --follow-tag
>
>I no longer should have to worry about that. It will push out
>whatever would be pushed out without --follow-tag, and also tags
>that are missing from my k.org repository that point into the
>history being pushed out.
I've run into the same problem. It's a minor annoyance, but your patch
should make it smoother.
Should this be called "--follow-tags"? That makes more sense to me, as
you are catching all tags. For consistency, should this match the naming
of git-fetch's options (or vice versa)? There we have:
: auto-follow tags
--tags: fetch all of refs/heads/tags
--no-tags: do not auto-follow
I think that naming has caused some confusion in the past. And there is
no way to explicitly specify the default behavior. I wonder if both
should support:
--follow-tags: auto-follow tags
--no-follow-tags: do not auto-follow tags
--tags: fetch/push all of refs/heads/tags
--no-tags: turn off auto-following, and cancel any previous --tags
The default for push should probably keep auto-follow off, though.
> +--follow-tag::
> + Push all the refs that would be pushed without this option,
> + and also push the refs under `refs/tags` that are missing
> + from the remote but are reachable from the refs that would
> + be pushed without this option.
> +
This reads OK to me, though it is a little confusing in that there are
two sets of refs being discussed, and "the refs that would be pushed
without this option" is quite a long noun phrase (that gets used twice).
You also don't define "reachable" here. Being familiar with git, I
assume it is "the commit that the refs/tag entry peels to is an ancestor
of a commit that is at the tip of a pushed ref". Maybe that is obvious
enough that it doesn't need to be spelled out.
I think you could just drop the second "refs that would be pushed
without this option", and just say "pushed refs". That is ambiguous (is
it all pushed refs, or refs that would be pushed without this option?),
but since reachability is transitive, they are the same set (i.e., if we
add a ref due to this option, then its ancestors are already candidates,
and it does not affect the outcome).
Maybe:
In addition to any refs that would be pushed without this option,
also push any refs under `refs/tags` that are missing from the remote
but are reachable from the pushed refs.
I dunno. I don't really like that version much, either.
> + /*
> + * At this point, src_tag lists tags that are missing from
> + * dst, and sent_tips lists the tips we are pushing (or those
> + * that we know they already have). An element in the src_tag
> + * that is not an ancestor of any of the sent_tips need to be
> + * sent to the other side.
> + */
> + if (sent_tips.nr) {
> + for_each_string_list_item(item, &src_tag) {
> + struct ref *ref = item->util;
> + struct ref *dst_ref;
> + struct commit *commit;
> +
> + if (is_null_sha1(ref->new_sha1))
> + continue;
> + commit = lookup_commit_reference_gently(ref->new_sha1,
> 1);
> + if (!commit)
> + /* not pushing a commit, which is not an error
> */
> + continue;
This will find anything under refs/tags, including annotated and
non-annotated tags. I wonder if it is worth making a distinction. In
many workflows, unannotated tags should not be leaked out to public
repos. But because this feature finds any reachable tags, it will push a
tag you made a long time ago as a bookmarker on some part of the history
unrelated to the release you are making now.
One obvious alternative is only to push annotated tags with this
feature. That has the downside of not matching fetch's behavior, as well
as withholding the feature from people whose workflow uses only
unannotated tags.
Another alternative would be to change the inclusion rule from
"reachable" to "points at the tip of something being sent". But then we
lose the feature that it would backfill any old tags the remote happens
to be missing.
-Peff
--
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: git repo on Win 2008
Hi, wrong mailing list for Windows questions. This is the correct one: http://groups.google.com/group/msysgit On Mon, Mar 04, 2013 at 04:43:27PM -0700, J.V. wrote: > What is the best way to host a shared git repo on a Windows 2008 > box? I would like to create a repo on the 2008 box (that everyone > will pull/push to), but add the initial code from my developer > (Windows7 box). The simplest way is: Just use a shared folder to which you push/clone a bare clone of your repository. Everyone with access to that folder will be able to clone from or push there. There is even an option in Git GUI for the initial operation: Menubar->Remote->Add, Fill in your information and choose "Initialize Remote Repository and Push" Cheers Heiko -- 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
