* Re: "git commit" fails due to spurious file in index
From: Torsten Bögershausen @ 2013-03-05 10:40 UTC (permalink / raw)
To: Robert Irelan; +Cc: git@vger.kernel.org
In-Reply-To: <2D9BD788B02ABA478C57929170AF952B7622B5@EXCH-MBX-3.epic.com>
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
^ permalink raw reply
* Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached
From: Duy Nguyen @ 2013-03-05 11:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <7vy5e49l3i.fsf@alter.siamese.dyndns.org>
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 <sha1>". 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 <pclouds@gmail.com>
---
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
# You are currently editing a commit while rebasing branch '\''rebase_i_edit'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -214,8 +215,9 @@ test_expect_success 'status when splitting a commit' '
ONTO=$(git rev-parse --short HEAD~3) &&
git rebase -i HEAD~3 &&
git reset HEAD^ &&
+ TGT=$(git rev-parse --short HEAD) &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached at $TGT
# You are currently splitting a commit while rebasing branch '\''split_commit'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
@@ -243,10 +245,11 @@ test_expect_success 'status after editing the last commit with --amend during a
export FAKE_LINES &&
test_when_finished "git rebase --abort" &&
ONTO=$(git rev-parse --short HEAD~3) &&
+ TGT=$(git rev-parse --short three_amend) &&
git rebase -i HEAD~3 &&
git commit --amend -m "foo" &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $TGT
# You are currently editing a commit while rebasing branch '\''amend_last'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -276,7 +279,7 @@ test_expect_success 'status: (continue first edit) second edit' '
git rebase -i HEAD~3 &&
git rebase --continue &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -298,7 +301,7 @@ test_expect_success 'status: (continue first edit) second edit and split' '
git rebase --continue &&
git reset HEAD^ &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
@@ -325,7 +328,7 @@ test_expect_success 'status: (continue first edit) second edit and amend' '
git rebase --continue &&
git commit --amend -m "foo" &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -347,7 +350,7 @@ test_expect_success 'status: (amend first edit) second edit' '
git commit --amend -m "a" &&
git rebase --continue &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -370,7 +373,7 @@ test_expect_success 'status: (amend first edit) second edit and split' '
git rebase --continue &&
git reset HEAD^ &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
@@ -398,7 +401,7 @@ test_expect_success 'status: (amend first edit) second edit and amend' '
git rebase --continue &&
git commit --amend -m "d" &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -422,7 +425,7 @@ test_expect_success 'status: (split first edit) second edit' '
git commit -m "e" &&
git rebase --continue &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -447,7 +450,7 @@ test_expect_success 'status: (split first edit) second edit and split' '
git rebase --continue &&
git reset HEAD^ &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently splitting a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (Once your working directory is clean, run "git rebase --continue")
#
@@ -477,7 +480,7 @@ test_expect_success 'status: (split first edit) second edit and amend' '
git rebase --continue &&
git commit --amend -m "h" &&
cat >expected <<-EOF &&
- # Not currently on any branch.
+ # Detached from $ONTO
# You are currently editing a commit while rebasing branch '\''several_edits'\'' on '\''$ONTO'\''.
# (use "git commit --amend" to amend the current commit)
# (use "git rebase --continue" once you are satisfied with your changes)
@@ -572,8 +575,9 @@ test_expect_success 'status when bisecting' '
git bisect start &&
git bisect bad &&
git bisect good one_bisect &&
- cat >expected <<-\EOF &&
- # Not currently on any branch.
+ TGT=$(git rev-parse --short two_bisect) &&
+ cat >expected <<-EOF &&
+ # Detached at $TGT
# You are currently bisecting branch '\''bisect'\''.
# (use "git bisect reset" to get back to the original branch)
#
@@ -596,7 +600,7 @@ test_expect_success 'status when rebase conflicts with statushints disabled' '
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 '\''statushints_disabled'\'' on '\''$ONTO'\''.
#
# Unmerged paths:
@@ -662,5 +666,15 @@ test_expect_success 'status when cherry-picking after resolving conflicts' '
test_i18ncmp expected actual
'
+test_expect_success 'status showing detached from a tag' '
+ test_commit atag tagging &&
+ git checkout atag &&
+ cat >expected <<-\EOF
+ # Detached at atag
+ nothing to commit (use -u to show untracked files)
+ EOF
+ git status --untracked-files=no >actual &&
+ test_i18ncmp expected actual
+'
test_done
diff --git a/wt-status.c b/wt-status.c
index 6a3566b..7ad3c2b 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1001,7 +1001,70 @@ static void read_and_strip_branch(struct strbuf *sb,
*branch = xstrdup(*branch);
}
-void wt_status_get_state(struct wt_status_state *state)
+struct grab_1st_switch_cbdata {
+ struct strbuf buf;
+ unsigned char nsha1[20];
+};
+
+static int grab_1st_switch(unsigned char *osha1, unsigned char *nsha1,
+ const char *email, unsigned long timestamp, int tz,
+ const char *message, void *cb_data)
+{
+ struct grab_1st_switch_cbdata *cb = cb_data;
+ const char *target = NULL, *end;
+
+ if (prefixcmp(message, "checkout: moving from "))
+ return 0;
+ message += strlen("checkout: moving from ");
+ target = strstr(message, " to ");
+ if (!target)
+ return 0;
+ target += strlen(" to ");
+ strbuf_reset(&cb->buf);
+ hashcpy(cb->nsha1, nsha1);
+ for (end = target; *end && *end != '\n'; end++)
+ ;
+ strbuf_add(&cb->buf, target, end - target);
+ return 0;
+}
+
+static void wt_status_get_detached_from(struct wt_status_state *state)
+{
+ struct grab_1st_switch_cbdata cb;
+ struct commit *commit;
+ unsigned char sha1[20];
+ char *ref = NULL;
+
+ strbuf_init(&cb.buf, 0);
+ if (for_each_recent_reflog_ent("HEAD", grab_1st_switch, 4096, &cb))
+ for_each_reflog_ent("HEAD", grab_1st_switch, &cb);
+ if (!cb.buf.len)
+ return;
+
+ if (dwim_ref(cb.buf.buf, cb.buf.len, sha1, &ref) == 1 &&
+ (commit = lookup_commit_reference_gently(sha1, 1)) != NULL &&
+ !hashcmp(cb.nsha1, commit->object.sha1)) {
+ int ofs;
+ if (!prefixcmp(ref, "refs/tags/"))
+ ofs = strlen("refs/tags/");
+ else if (!prefixcmp(ref, "refs/remotes/"))
+ ofs = strlen("refs/remotes/");
+ else
+ ofs = 0;
+ state->detached_from = xstrdup(ref + ofs);
+ hashcpy(state->detached_sha1, sha1);
+ } else if (!get_sha1(cb.buf.buf, sha1)) {
+ state->detached_from =
+ xstrdup(find_unique_abbrev(sha1, DEFAULT_ABBREV));
+ hashcpy(state->detached_sha1, sha1);
+ }
+
+ free(ref);
+ strbuf_release(&cb.buf);
+}
+
+void wt_status_get_state(struct wt_status_state *state,
+ int get_detached_from)
{
struct strbuf branch = STRBUF_INIT;
struct strbuf onto = STRBUF_INIT;
@@ -1040,6 +1103,10 @@ void wt_status_get_state(struct wt_status_state *state)
read_and_strip_branch(&branch, &state->branch,
"BISECT_START");
}
+
+ if (get_detached_from)
+ wt_status_get_detached_from(state);
+
strbuf_release(&branch);
strbuf_release(&onto);
}
@@ -1066,7 +1133,8 @@ void wt_status_print(struct wt_status *s)
const char *branch_status_color = color(WT_STATUS_HEADER, s);
struct wt_status_state state;
- wt_status_get_state(&state);
+ wt_status_get_state(&state,
+ s->branch && !strcmp(s->branch, "HEAD"));
if (s->branch) {
const char *on_what = _("On branch ");
@@ -1074,9 +1142,19 @@ void wt_status_print(struct wt_status *s)
if (!prefixcmp(branch_name, "refs/heads/"))
branch_name += 11;
else if (!strcmp(branch_name, "HEAD")) {
- branch_name = "";
branch_status_color = color(WT_STATUS_NOBRANCH, s);
- on_what = _("Not currently on any branch.");
+ if (state.detached_from) {
+ unsigned char sha1[20];
+ branch_name = state.detached_from;
+ if (!get_sha1("HEAD", sha1) &&
+ !hashcmp(sha1, state.detached_sha1))
+ on_what = _("Detached at ");
+ else
+ on_what = _("Detached from ");
+ } else {
+ branch_name = "";
+ on_what = _("Not currently on any branch.");
+ }
}
status_printf(s, color(WT_STATUS_HEADER, s), "");
status_printf_more(s, branch_status_color, "%s", on_what);
@@ -1088,6 +1166,7 @@ void wt_status_print(struct wt_status *s)
wt_status_print_state(s, &state);
free(state.branch);
free(state.onto);
+ free(state.detached_from);
if (s->is_initial) {
status_printf_ln(s, color(WT_STATUS_HEADER, s), "");
diff --git a/wt-status.h b/wt-status.h
index 5ddcbf6..5cb7df9 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -81,12 +81,14 @@ struct wt_status_state {
int bisect_in_progress;
char *branch;
char *onto;
+ char *detached_from;
+ unsigned char detached_sha1[20];
};
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
-void wt_status_get_state(struct wt_status_state *state);
+void wt_status_get_state(struct wt_status_state *state, int get_detached_from);
void wt_shortstatus_print(struct wt_status *s);
void wt_porcelain_print(struct wt_status *s);
-- 8< --
^ permalink raw reply related
* Re: [PATCH 2/2] push: --follow-tag
From: Michael Haggerty @ 2013-03-05 11:49 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130305082204.GB13552@sigill.intra.peff.net>
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
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] Extend runtime prefix computation
From: Michael Weiser @ 2013-03-05 11:58 UTC (permalink / raw)
To: git
In-Reply-To: <20121127163004.GC7499@science-computing.de>
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 Weiser science + 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
^ permalink raw reply
* Re: [PATCH 4/5] status: show the ref that is checked out, even if it's detached
From: Matthieu Moy @ 2013-03-05 12:18 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Junio C Hamano, git, Jonathan Niedier
In-Reply-To: <20130305113958.GA26236@lanh>
Duy Nguyen <pclouds@gmail.com> 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/
^ permalink raw reply
* [PATCH] Fix `make install` when configured with autoconf
From: Kirill Smelkov @ 2013-03-05 12:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Komissarov, git, Kirill Smelkov
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 <kirr@mns.spb.ru>
---
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
^ permalink raw reply related
* [PATCH] help: show manpage for aliased command on git <alias> --help
From: Ævar Arnfjörð Bjarmason @ 2013-03-05 14:44 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, H.Merijn Brand,
Ævar Arnfjörð Bjarmason
Change the semantics of "git <alias> --help" to show the help for the
command <alias> is aliased to, instead of just saying:
`git <alias>' is aliased to `<whatever>'
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 <avarab@gmail.com>
---
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
^ permalink raw reply related
* Re: [BUG] Incorrect/misleading error when `git rev-list --objects --all` hits the max open files limit
From: Pete Wyckoff @ 2013-03-05 15:26 UTC (permalink / raw)
To: Peter Rabbitson; +Cc: git
In-Reply-To: <20130303232927.GA16606@rabbit.us>
rabbit@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
^ permalink raw reply
* RE: "git commit" fails due to spurious file in index
From: Robert Irelan @ 2013-03-05 15:30 UTC (permalink / raw)
To: Thomas Rast; +Cc: git@vger.kernel.org
In-Reply-To: <87y5e2op9p.fsf@pctrast.inf.ethz.ch>
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:trast@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 <rirelan@epic.com> 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
^ permalink raw reply
* RE: "git commit" fails due to spurious file in index
From: Robert Irelan @ 2013-03-05 15:30 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git@vger.kernel.org
In-Reply-To: <5135CBBB.60102@web.de>
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:tboegi@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
^ permalink raw reply
* Re: [PATCH] help: show manpage for aliased command on git <alias> --help
From: Johannes Sixt @ 2013-03-05 15:42 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Jonathan Nieder, Jeff King, H.Merijn Brand
In-Reply-To: <1362494681-11419-1-git-send-email-avarab@gmail.com>
Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> Change the semantics of "git <alias> --help" to show the help for the
> command <alias> is aliased to, instead of just saying:
>
> `git <alias>' is aliased to `<whatever>'
>
> 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
^ permalink raw reply
* Re: auto merge bug
From: Junio C Hamano @ 2013-03-05 15:44 UTC (permalink / raw)
To: Jeff King; +Cc: David Krmpotic, git
In-Reply-To: <20130305090326.GC13552@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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.
^ permalink raw reply
* Re: [PATCH v6] submodule: add 'deinit' command
From: Junio C Hamano @ 2013-03-05 15:45 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Phil Hord, Git Mailing List, Michael J Gruber,
Marc Branchaud, W. Trevor King
In-Reply-To: <20130305072944.GA4677@sandbox-ub>
Heiko Voigt <hvoigt@hvoigt.net> 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...
^ permalink raw reply
* Re: [PATCH 2/2] push: --follow-tag
From: Junio C Hamano @ 2013-03-05 15:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130305082204.GB13552@sigill.intra.peff.net>
Jeff King <peff@peff.net> 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:
>
> <default>: 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.
^ permalink raw reply
* Re: [PATCH] help: show manpage for aliased command on git <alias> --help
From: H.Merijn Brand @ 2013-03-05 15:54 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ævar Arnfjörð Bjarmason, git, Junio C Hamano,
Jonathan Nieder, Jeff King
In-Reply-To: <5136127C.2090402@viscovery.net>
On Tue, 05 Mar 2013 16:42:52 +0100, Johannes Sixt
<j.sixt@viscovery.net> wrote:
> Am 3/5/2013 15:44, schrieb Ævar Arnfjörð Bjarmason:
> > Change the semantics of "git <alias> --help" to show the help for the
> > command <alias> is aliased to, instead of just saying:
> >
> > `git <alias>' is aliased to `<whatever>'
> >
> > 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/
^ permalink raw reply
* Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
From: Junio C Hamano @ 2013-03-05 16:09 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Jens Lehmann, Eric Cousineau, git
In-Reply-To: <20130305075901.GB4677@sandbox-ub>
Heiko Voigt <hvoigt@hvoigt.net> 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=<command/script> 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[=<command>]] [--post-order[=<command>]] [<command>]
>
> 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.
^ permalink raw reply
* Re: [PATCH] Extend runtime prefix computation
From: Junio C Hamano @ 2013-03-05 16:13 UTC (permalink / raw)
To: Michael Weiser; +Cc: git
In-Reply-To: <20130305115837.GD21473@science-computing.de>
Michael Weiser <M.Weiser@science-computing.de> 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?
^ permalink raw reply
* Re: [PATCH] help: show manpage for aliased command on git <alias> --help
From: Junio C Hamano @ 2013-03-05 16:16 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Jonathan Nieder, Jeff King, H.Merijn Brand
In-Reply-To: <1362494681-11419-1-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Change the semantics of "git <alias> --help" to show the help for the
> command <alias> is aliased to, instead of just saying:
>
> `git <alias>' is aliased to `<whatever>'
>
> 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.
^ permalink raw reply
* Re: [PATCH] help: show manpage for aliased command on git <alias> --help
From: Ævar Arnfjörð Bjarmason @ 2013-03-05 16:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder, Jeff King, H.Merijn Brand
In-Reply-To: <7v8v61vn3h.fsf@alter.siamese.dyndns.org>
On Tue, Mar 5, 2013 at 5:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Change the semantics of "git <alias> --help" to show the help for the
>> command <alias> is aliased to, instead of just saying:
>>
>> `git <alias>' is aliased to `<whatever>'
>>
>> 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.
^ permalink raw reply
* Re: [PATCH/RFC] Changing submodule foreach --recursive to be depth-first, --parent option to execute command in supermodule as well
From: Eric Cousineau @ 2013-03-05 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, Jens Lehmann, git
In-Reply-To: <7vhakpvnex.fsf@alter.siamese.dyndns.org>
On Tue, Mar 5, 2013 at 10:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Heiko Voigt <hvoigt@hvoigt.net> 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=<command/script> 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[=<command>]] [--post-order[=<command>]] [<command>]
>>
>> 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
^ permalink raw reply
* Re: [PATCH] help: show manpage for aliased command on git <alias> --help
From: Junio C Hamano @ 2013-03-05 16:52 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Jonathan Nieder, Jeff King, H.Merijn Brand
In-Reply-To: <CACBZZX5=ARahxswkN_mLbBF3fQxV-HtKgehe_3ogHg5-i7utYw@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.
^ permalink raw reply
* Re: [PATCH] help: show manpage for aliased command on git <alias> --help
From: Matthieu Moy @ 2013-03-05 16:41 UTC (permalink / raw)
To: H.Merijn Brand
Cc: Johannes Sixt, Ævar Arnfjörð Bjarmason, git,
Junio C Hamano, Jonathan Nieder, Jeff King
In-Reply-To: <20130305165453.6077226c@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> 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/
^ permalink raw reply
* Re: [PATCH] git-completion.zsh: define __gitcomp_file compatibility function
From: Junio C Hamano @ 2013-03-05 16:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, felipe.contreras, manlio.perillo
In-Reply-To: <1362473035-5034-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> 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<tab>" 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 <Matthieu.Moy@imag.fr>
> ---
>> 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
^ permalink raw reply
* Re: [PATCH] Fix `make install` when configured with autoconf
From: Junio C Hamano @ 2013-03-05 16:56 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Dmitry Komissarov, git
In-Reply-To: <1362487405-32044-1-git-send-email-kirr@mns.spb.ru>
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] push: --follow-tag
From: Jeff King @ 2013-03-05 17:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlia1vnwq.fsf@alter.siamese.dyndns.org>
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox