* Re: [PATCH] Documentation update for 'git branch --list'
From: Vincent van Ravesteijn @ 2011-11-21 15:00 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, gitster, git
In-Reply-To: <1321886000-4163-1-git-send-email-vfr@lyx.org>
> The current synopsis also suggests that 'git branch -d<pattern>...'
> would be a valid command.
Well.. that's a lie.
Vincent
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 15:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <20111121081701.GA7985@do>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> If you want to keep this accident (which is a bug to me), you may want
> to add the reason: callers to unpack_trees() are supposed to also
> setup exclude rules in .git/info/exclude before calling
> unpack_trees(), which they don't.
>
> So .git/info/exclude is entirely dismissed.
Ohh, thanks for this and also for digging this through in your other
message.
I think it is the right thing to do to make sure .gitignore and
info/exclude behave the same way regardless of the original issue in this
topic.
In the medium term, I think one reasonable way forward solving the "TODO
that used to be tracked but now untracked and ignored" issue is to
introduce "info/exclude-override" that comes between command line and
in-tree patterns. The info/exclude file is designed as the fallback
definition to be used when all other sources are too lax, and comes near
the precedence stack; the "TODO" situation however calls for an override
that is stronger than the in-tree patterns.
In the longer term, we should carefully determine if we need "precious" in
the first place. The last time this was brought up there were people who
argued they are OK with having to remove the ignored file by hand when
checking out another branch (i.e. we switch the semantics of "ignored" so
that they are "not tracked but all precious").
I think it matters in two cases.
(1) If you change an untracked "cruft" file on branch A into a directory
with tracked files in it on another branch B. If you are on branch A,
have that "cruft" file (perhaps it is a build product after running
"make"), and try to checkout branch B, such an updated "git checkout"
will start erroring out telling you that "cruft" will be lost.
(2) If you have a directory on branch A, underneath of which there are
untracked "cruft" files (e.g. think "build/" directory that is full
of "*.o" files and ".gitignore" to mark object files as ignored but
is otherwise empty), and another branch B that has the same path as a
file. If you are on branch A, have "cruft" files in that directory,
and try to checkout branch B, such an updated "git checkout" will
start erroring out telling you that "cruft" will be lost.
If people are OK with such a behaviour, we can do without "precious".
Otherwise we would need to update excluded() in dir.c to return tristate
(ignored, precious or unspecified) instead of the current boolean (ignored
or unspecified), examine and decide for each caller what they want to do
to "precious" files.
^ permalink raw reply
* [PATCH] spec: add missing build dependency
From: Felipe Contreras @ 2011-11-21 15:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
From: Felipe Contreras <felipe.contreras@gmail.com>
Otherwise:
/usr/bin/perl Makefile.PL PREFIX='/opt/git' INSTALL_BASE=''
Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at Makefile.PL line 1.
BEGIN failed--compilation aborted at Makefile.PL line 1.
make[1]: *** [perl.mak] Error 2
make: *** [perl/perl.mak] Error 2
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git.spec.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index c562c62..4d7ac1a 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -101,6 +101,7 @@ Group: Development/Libraries
Requires: git = %{version}-%{release}
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
BuildRequires: perl(Error)
+BuildRequires: perl(ExtUtils::MakeMaker)
%description -n perl-Git
Perl interface to Git
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH] spec: add missing build dependency
From: Felipe Contreras @ 2011-11-21 15:43 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano
In-Reply-To: <1321889726-29620-1-git-send-email-felipe.contreras@nokia.com>
On Mon, Nov 21, 2011 at 5:35 PM, Felipe Contreras
<felipe.contreras@nokia.com> wrote:
> From: Felipe Contreras <felipe.contreras@gmail.com>
>
> Otherwise:
>
> /usr/bin/perl Makefile.PL PREFIX='/opt/git' INSTALL_BASE=''
> Can't locate ExtUtils/MakeMaker.pm in @INC (@INC contains: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at Makefile.PL line 1.
> BEGIN failed--compilation aborted at Makefile.PL line 1.
> make[1]: *** [perl.mak] Error 2
> make: *** [perl/perl.mak] Error 2
Just to clarify... I didn't actually build the RPM, just doing 'make
install' after getting the dependencies from the spec. So I'm not sure
if this is really needed.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Bertrand BENOIT @ 2011-11-21 15:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, Johannes Sixt, Taylor Hedberg, git
In-Reply-To: <7vk46th5bz.fsf@alter.siamese.dyndns.org>
2011/11/21 Junio C Hamano <gitster@pobox.com>:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> If you want to keep this accident (which is a bug to me), you may want
>> to add the reason: callers to unpack_trees() are supposed to also
>> setup exclude rules in .git/info/exclude before calling
>> unpack_trees(), which they don't.
>>
>> So .git/info/exclude is entirely dismissed.
>
> Ohh, thanks for this and also for digging this through in your other
> message.
>
> I think it is the right thing to do to make sure .gitignore and
> info/exclude behave the same way regardless of the original issue in this
> topic.
>
> In the medium term, I think one reasonable way forward solving the "TODO
> that used to be tracked but now untracked and ignored" issue is to
> introduce "info/exclude-override" that comes between command line and
> in-tree patterns. The info/exclude file is designed as the fallback
> definition to be used when all other sources are too lax, and comes near
> the precedence stack; the "TODO" situation however calls for an override
> that is stronger than the in-tree patterns.
>
> In the longer term, we should carefully determine if we need "precious" in
> the first place. The last time this was brought up there were people who
> argued they are OK with having to remove the ignored file by hand when
> checking out another branch (i.e. we switch the semantics of "ignored" so
> that they are "not tracked but all precious").
>
> I think it matters in two cases.
>
> (1) If you change an untracked "cruft" file on branch A into a directory
> with tracked files in it on another branch B. If you are on branch A,
> have that "cruft" file (perhaps it is a build product after running
> "make"), and try to checkout branch B, such an updated "git checkout"
> will start erroring out telling you that "cruft" will be lost.
>
> (2) If you have a directory on branch A, underneath of which there are
> untracked "cruft" files (e.g. think "build/" directory that is full
> of "*.o" files and ".gitignore" to mark object files as ignored but
> is otherwise empty), and another branch B that has the same path as a
> file. If you are on branch A, have "cruft" files in that directory,
> and try to checkout branch B, such an updated "git checkout" will
> start erroring out telling you that "cruft" will be lost.
>
> If people are OK with such a behaviour, we can do without "precious".
>
> Otherwise we would need to update excluded() in dir.c to return tristate
> (ignored, precious or unspecified) instead of the current boolean (ignored
> or unspecified), examine and decide for each caller what they want to do
> to "precious" files.
IMO, as user, I think that erroring out telling you that 'cruft' will
be lost, is enough to avoid data loss.
However, in addition the tristate system (with a dedicated syntax in
.gitattributes and/or .gitignore files) would give more freedom,
without having to move 'untracked but precious' files between each
updated 'git checkout'.
^ permalink raw reply
* Re: Fixing a broken GIT repo
From: Erik Faye-Lund @ 2011-11-21 16:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Bart van den Burg, git
In-Reply-To: <4EC6625B.2070301@viscovery.net>
On Fri, Nov 18, 2011 at 2:49 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 11/18/2011 11:54, schrieb Bart van den Burg:
>> I somehow managed to break my GIT repo. Whenever I try to clone or fetch
>> from a clean local repo, I get an error.
>>
>> I'm able to go back on the server, to the very last commit where
>> everything works, but as soon as I make a change locally and push it, it
>> breaks again.
> ...
>> $ git clone git@git.samson-it.nl:/home/git/shifter_rai
> ...
>> Receiving objects: 100% (9557/9557), 2.85 MiB | 1.06 MiB/s, done.
> ...
>> $ git push
>> Counting objects: 4, done.
>> Delta compression using up to 4 threads.
>> Compressing objects: 100% (2/2), done.
>> Writing objects: 100% (3/3), 271 bytes, done.
>> Total 3 (delta 1), reused 0 (delta 0)
>> To git@git.samson-it.nl:/home/git/shifter_rai
>> cc5693a..85d1ee9 master -> master
>
> It looks like you are pushing via git protocol from Windows
> (Git-for-Windows). This is known to dead-lock in most cases, and even
> though it did not here, I would not be surprised if it had other issues.
>
> Do not do it. Push via ssh instead.
>
Does it? Doesn't the "To git@git.samson-it.nl:/home/git/shifter_rai"
line suggests ssh?
^ permalink raw reply
* Re: Fixing a broken GIT repo
From: Johannes Sixt @ 2011-11-21 16:45 UTC (permalink / raw)
To: kusmabite; +Cc: Bart van den Burg, git
In-Reply-To: <CABPQNSaJVYqLw+JuOWg2wqa-Sig6+W_W-id7yRFLzZ0kTr73hw@mail.gmail.com>
Am 11/21/2011 17:37, schrieb Erik Faye-Lund:
> On Fri, Nov 18, 2011 at 2:49 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Am 11/18/2011 11:54, schrieb Bart van den Burg:
>>> To git@git.samson-it.nl:/home/git/shifter_rai
>>> cc5693a..85d1ee9 master -> master
>>
>> It looks like you are pushing via git protocol from Windows
>> (Git-for-Windows). This is known to dead-lock in most cases, and even
>> though it did not here, I would not be surprised if it had other issues.
>>
>> Do not do it. Push via ssh instead.
>>
>
> Does it? Doesn't the "To git@git.samson-it.nl:/home/git/shifter_rai"
> line suggests ssh?
Oops, you are right.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 17:27 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <CACsJy8AgDKYhyJ2CD0Y7trGrT63bUuYAS0DadD9khyqEYpguew@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> It dated back to f8a9d42 (read-tree: further loosen "working file will
> be lost" check. - 2006-12-04) when you introduced --exclude-per-directory
> to read-tree, but not --exclude-from to explicitly add .git/info/exclude.
That one together with 1127148 (Loosen "working file will be lost" check
in Porcelain-ish, 2006-12-04) complets the picture. Thanks for digging
this out.
> I guess it's time to add "read-tree --exclude-from".
Perhaps, also --exclude-standard to match?
> We may add an option to checkout to skip
> either .git/info/exclude or .gitignore, or both.
I do not think we want to go that route, because it is not just "checkout"
but is an issue shared across users of unpack-trees machinery.
When a merge result loses build/ directory and replaces it with a regular
file "build", with the current ignore semantics, build/*.o will go but if
you had an untracked and ignored build/TODO, the file will also go, for
example. If we want to have "precious", we should either make "ignored" to
mean "precious", or introduce a "precious" as a new category
(cf. $gmane/185746)
^ permalink raw reply
* Re: [PATCH] Show error for 'git merge' with unset merge.defaultToUpstream
From: Junio C Hamano @ 2011-11-21 17:30 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git
In-Reply-To: <1321882240-3783-1-git-send-email-vfr@lyx.org>
Smells correct from a cursory look; thanks.
^ permalink raw reply
* Re: [PATCH] Documentation update for 'git branch --list'
From: Junio C Hamano @ 2011-11-21 17:37 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, git
In-Reply-To: <1321886000-4163-1-git-send-email-vfr@lyx.org>
Vincent van Ravesteijn <vfr@lyx.org> writes:
> Indicate that the <pattern>... argument is only valid when using --list.
> Otherwise a branch with the name <pattern> will be created.
I actually think there are some bugs in the implementation along that line
and the way forward is to fix the implementation, instead of documenting
the buggy behaviour.
It is natural to expect "git branch --merged pu vr/\*" to list branches
that are contained in 'pu' whose names match the given pattern, but it
seems to try creating a branch called "vr/*" and fails, for example.
> The current
> synopsis also suggests that 'git branch -d <pattern>...' would be a valid
> command.
That is not how I read the current synopsis for -d; doesn't it avoid using
<pattern> and explicitly say <branchname>?
> Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
> ---
> Documentation/git-branch.txt | 11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> index f46013c..9f49db4 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -9,8 +9,9 @@ SYNOPSIS
> --------
> [verse]
> 'git branch' [--color[=<when>] | --no-color] [-r | -a]
> - [--list] [-v [--abbrev=<length> | --no-abbrev]]
> - [(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]
> + [-v [--abbrev=<length> | --no-abbrev]]
> + [(--merged | --no-merged | --contains) [<commit>]]
> + [--list [<pattern>...]]
> 'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
> 'git branch' (-m | -M) [<oldbranch>] <newbranch>
> 'git branch' (-d | -D) [-r] <branchname>...
> @@ -23,8 +24,8 @@ be highlighted with an asterisk. Option `-r` causes the remote-tracking
> branches to be listed, and option `-a` shows both. This list mode is also
> activated by the `--list` option (see below).
> <pattern> restricts the output to matching branches, the pattern is a shell
> -wildcard (i.e., matched using fnmatch(3))
> -Multiple patterns may be given; if any of them matches, the tag is shown.
> +wildcard (i.e., matched using fnmatch(3)).
> +Multiple patterns may be given; if any of them matches, the branch is shown.
>
> With `--contains`, shows only the branches that contain the named commit
> (in other words, the branches whose tip commits are descendants of the
> @@ -114,7 +115,7 @@ OPTIONS
> --all::
> List both remote-tracking branches and local branches.
>
> ---list::
> +--list [<pattern>...]::
> Activate the list mode. `git branch <pattern>` would try to create a branch,
> use `git branch --list <pattern>` to list matching branches.
^ permalink raw reply
* [PATCH] convert.c: Fix return type of git_path_check_eol()
From: Ramsay Jones @ 2011-11-21 18:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: artagnon, GIT Mailing-list
The git_path_check_eol() function converts a string value to the
corresponding 'enum eol' value. However, the function is currently
declared to return an 'enum crlf_action', which causes sparse to
complain thus:
SP convert.c
convert.c:736:50: warning: mixing different enum types
convert.c:736:50: int enum crlf_action versus
convert.c:736:50: int enum eol
In order to suppress the warning, we simply correct the return type
in the function declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
convert.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/convert.c b/convert.c
index 038b0be..86e9c29 100644
--- a/convert.c
+++ b/convert.c
@@ -658,7 +658,7 @@ static enum crlf_action git_path_check_crlf(const char *path, struct git_attr_ch
return CRLF_GUESS;
}
-static enum crlf_action git_path_check_eol(const char *path, struct git_attr_check *check)
+static enum eol git_path_check_eol(const char *path, struct git_attr_check *check)
{
const char *value = check->value;
--
1.7.7
^ permalink raw reply related
* Re: clean bug on ignored subdirectories with no tracked files?
From: Jay Soffian @ 2011-11-21 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5vbj4rb.fsf@alter.siamese.dyndns.org>
On Sat, Nov 19, 2011 at 2:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> git init test_repo &&
>> cd test_repo &&
>> mkdir -p foo/bar &&
>> echo baz > foo/bar/baz &&
>> echo /foo/bar > .gitignore &&
>> git add .gitignore &&
>> git clean -n -d
>>
>> Initialized empty Git repository in .../test_repo/.git/
>> Would remove foo/
>>
>> Seems surprising.
>
> You said "everythingthing in foo/bar is uninteresting and can be cleaned",
> you have one untracked file in "foo/bar" hierarchy, and you have nothing
> else in "foo/" hierarchy.
Just because it is uninteresting to git does not mean that it isn't
precious. In this case the ignored files are from svn and checked out
via another tool (gclient).
> Removing the uninteresting cruft as your .gitignore instructs Git makes
> the entire "foo/" hierarchy devoid of any contents. I would *expect* Git
> to clean "foo" in this case.
But .gitignore is not for indicating "this is cruft", it is for
indicating "this is not under git's purview." You must admit that git
clean's behavior above, if not surprising to you, is at least
inconsistent with:
$ git init test_repo && cd test_repo && mkdir foo && touch foo/bar &&
echo /foo > .gitignore && git add .gitignore && git clean -n -d
which does protect foo (and its contents) from being cleaned.
git clean specifically has an option for "remove only the stuff which
is ignored" which implies that it should not be removing ignored stuff
w/o that option.
> I've seen some "surprising" behaviour in "git clean" (which I do not use
> myself, I do not consider part of "my code", and I am not surprised if it
> has many bugs), but I fail to see what is surprising in your transcript.
>
> It would be a different issue if you had ">foo/other" before your "clean".
> Then "foo/" has "foo/clean" that is not declared to be uninteresting.
Huh? clean is designed to remove untracked unignored files, so I'd
expect it to remove foo/other in that case. And what is this foo/clean
to which you refer?
j.
^ permalink raw reply
* Re: clean bug on ignored subdirectories with no tracked files?
From: Junio C Hamano @ 2011-11-21 19:02 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <CAG+J_DwKeWntmi22vHS6CRud6Lo0P_+D5u5ih2Bbc50ekYji5w@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Just because it is uninteresting to git does not mean that it isn't
> precious.
That statement is false with the versions of Git so far. See the other
thread for the current status and possible future directions.
^ permalink raw reply
* Re: Possible bug with branch names and case sensitivity
From: Jay Soffian @ 2011-11-21 19:18 UTC (permalink / raw)
To: Gerd Knops; +Cc: git
In-Reply-To: <D144F6C9-C6A3-4516-BC88-B9EB50890EF4@bitart.com>
On Sat, Nov 19, 2011 at 3:08 PM, Gerd Knops <gerti@bitart.com> wrote:
> On Mac OS X with a case-insensitive file system (not sure if that matters) git get's confused with branch names that differ only in case.
This is true. The branch code assumes a case-sensitive filesystem. I
started working on a fix, but it was more involved than I first
thought it would be. See my local WIP commit below, apologies if gmail
lines wraps it.
j.
commit dfa86073b7
Author: Jay Soffian <jaysoffian@gmail.com>
Date: Thu Oct 6 14:51:15 2011 -0400
Try not to confuse branch foo with branch Foo (WIP)
This probably needs to canonicalize the branch name instead. Sigh.
diff --git a/builtin/checkout.c b/builtin/checkout.c
index a41c818a7c..0e7362345d 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -363,7 +363,7 @@ static void setup_branch_path(struct branch_info *branch)
struct strbuf buf = STRBUF_INIT;
strbuf_branchname(&buf, branch->name);
- if (strcmp(buf.buf, branch->name))
+ if (strcmp_icase(buf.buf, branch->name))
branch->name = xstrdup(buf.buf);
strbuf_splice(&buf, 0, 0, "refs/heads/", 11);
branch->path = strbuf_detach(&buf, NULL);
@@ -523,7 +523,7 @@ static void record_checkout(const char *name,
const char *new_work_tree)
} else { /* release name if we reserved it */
struct branch *branch = branch_get(name);
if (branch->work_tree &&
- !strcmp(branch->work_tree, get_git_work_tree()))
+ !strcmp_icase(branch->work_tree, get_git_work_tree()))
git_config_set(key.buf, "");
}
strbuf_release(&key);
@@ -567,7 +567,7 @@ static void update_refs_for_switch(struct
checkout_opts *opts,
strbuf_addf(&msg, "checkout: moving from %s to %s",
old_desc ? old_desc : "(invalid)", new->name);
- if (!strcmp(new->name, "HEAD") && !new->path && !opts->force_detach) {
+ if (!strcmp_icase(new->name, "HEAD") && !new->path && !opts->force_detach) {
/* Nothing to do. */
} else if (opts->force_detach || !new->path) { /* No longer on any branch. */
update_ref(msg.buf, "HEAD", new->commit->object.sha1, NULL,
@@ -582,7 +582,7 @@ static void update_refs_for_switch(struct
checkout_opts *opts,
} else if (new->path) { /* Switch branches. */
create_symref("HEAD", new->path, msg.buf);
if (!opts->quiet) {
- if (old->path && !strcmp(new->path, old->path)) {
+ if (old->path && !strcmp_icase(new->path, old->path)) {
fprintf(stderr, _("Already on '%s'\n"),
new->name);
} else if (opts->new_branch) {
@@ -612,7 +612,7 @@ static void update_refs_for_switch(struct
checkout_opts *opts,
remove_branch_state();
strbuf_release(&msg);
if (!opts->quiet &&
- (new->path || (!opts->force_detach && !strcmp(new->name, "HEAD"))))
+ (new->path || (!opts->force_detach && !strcmp_icase(new->name, "HEAD"))))
report_tracking(new);
}
@@ -719,7 +719,7 @@ static void check_if_checked_out(struct
checkout_opts *opts, const char *name)
{
struct branch *branch = branch_get(name);
if (branch->work_tree && strlen(branch->work_tree) &&
- strcmp(branch->work_tree, get_git_work_tree())) {
+ strcmp_icase(branch->work_tree, get_git_work_tree())) {
if (opts->force)
warning(_("branch '%s' is currently checked out"
" in '%s'"), name, branch->work_tree);
diff --git a/remote.c b/remote.c
index 283b2121bd..1fba1c7fa3 100644
--- a/remote.c
+++ b/remote.c
@@ -166,9 +166,9 @@ static struct branch *make_branch(const char *name, int len)
char *refname;
for (i = 0; i < branches_nr; i++) {
- if (len ? (!strncmp(name, branches[i]->name, len) &&
+ if (len ? (!strncmp_icase(name, branches[i]->name, len) &&
!branches[i]->name[len]) :
- !strcmp(name, branches[i]->name))
+ !strcmp_icase(name, branches[i]->name))
return branches[i];
}
@@ -829,7 +829,7 @@ static int query_refspecs(struct refspec *refs,
int ref_count, struct refspec *q
query->force = refspec->force;
return 0;
}
- } else if (!strcmp(needle, key)) {
+ } else if (!strcmp_icase(needle, key)) {
*result = xstrdup(value);
query->force = refspec->force;
return 0;
^ permalink raw reply related
* Re: clean bug on ignored subdirectories with no tracked files?
From: Junio C Hamano @ 2011-11-21 19:28 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <7vy5v9fgel.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Just because it is uninteresting to git does not mean that it isn't
>> precious.
>
> That statement is false with the versions of Git so far. See the other
> thread for the current status and possible future directions.
Oops, sorry, I was really confused. You are right that "ignored" for
"clean" does not mean "they are not tracked and should be removed". That
would result in removal of build artifacts '*.o' and unnecesary
recompilation.
What "precious" means is a bit different, however. With verisons of Git so
far, what "ignored" means is that they are not tracked, and _can_ be
removed when needed to complete normal Git operations. When checking out
another branch that has a tracked file at the same path as an untracked
and ignored file in your current branch, removal of that ignored file is
necessary to complete the checkout, and for that purpose, the ignored file
is considered expendable. And we do not have a concept of "precious",
unexpendable but untracked file, nor a way to specify that to gitignore
mechanism (which is the topic of the other discussion thread).
"clean" without "-x" is meant to preserve untracked but expendable paths
(e.g. build products), so if something is removed that is untracked but
matches the ignore pattern, then that is a bug to be fixed. Care to roll
a patch to fix it?
Sorry for the confusion, but as I said, I do not use (hence nor care much
about) "clean" myself, so...
^ permalink raw reply
* Re: clean bug on ignored subdirectories with no tracked files?
From: Jay Soffian @ 2011-11-21 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vty5xff6l.fsf@alter.siamese.dyndns.org>
On Mon, Nov 21, 2011 at 2:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "clean" without "-x" is meant to preserve untracked but expendable paths
> (e.g. build products), so if something is removed that is untracked but
> matches the ignore pattern, then that is a bug to be fixed. Care to roll
> a patch to fix it?
Okay, just confirming it is a bug. I'll add this e-mail to my todo
list, but I don't have time for a patch anytime soon. :-(
> Sorry for the confusion, but as I said, I do not use (hence nor care much
> about) "clean" myself, so...
Okay.
j.
^ permalink raw reply
* Re: [PATCH 1/3] revert: rename --reset option to --quit
From: Junio C Hamano @ 2011-11-21 20:36 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord
In-Reply-To: <20111120094824.GC2278@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> The option to "git cherry-pick" and "git revert" to discard the
> sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
> --reset to remove sequencer state, 2011-08-04) has a confusing name.
> Change it now, while we still have the time.
>
> Mechanics:
>
> This commit removes the "git cherry-pick --reset" option. Hopefully
> nobody was using it. If somebody was, we can add it back again as a
> synonym.
>
> The new name for "cherry-pick, please get out of my way, since I've
> long forgotten about the sequence of commits I was cherry-picking when
> you wrote that old .git/sequencer directory" is --quit.
Wouldn't it match other commands better if we called this --abort instead
of --quit?
Other than that I think I agree with the reasoning (and I think I too had
encountered the irritation with the "sequencer state").
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-21 21:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s1G9jJyiis7z7XbPvW925E-u=0_-h9jJKkj2wyPS9o5ig@mail.gmail.com>
On Mon, Nov 14, 2011 at 03:57:07PM +0200, Felipe Contreras wrote:
> >> I'm not going to investigate the subtleties of these different setups,
> >> I'm going to put my common user hat and ask; how do I fetch as a
> >> mirror?
> >
> > The problem with that question is that you haven't defined mirror. Does
> > that mean you just want pruning, or does it mean that you want your
> > local ref namespace to match that of the remote?
>
> Exactly, no mirror has been defined, because I don't want a mirror. A
> mirror is supposed to have all the refs in sync all the time; that's
> not what I want.
I didn't mean "you didn't define a mirror in your config". I meant "your
question is not well-defined, because you haven't defined the term
'mirror'". IOW, I can't answer your question without knowing exactly
what you meant.
> > BTW, right now there is "git remote add --mirror ...", which sets up the
> > fetch refspec for you (in this case, mirror is "make your refs look like
> > the remote's"). Perhaps rather than adding syntactic sugar to fetch, it
> > would be best to channel users into configuring a remote that selects
> > from one of a few common setups (including different types of mirrors).
>
> But that assumes that they would want the same refspec operation *all
> the time* which is not the case (at least for me). Sometimes I want to
> update only existing branches, sometimes I want to fetch new branches
> too, sometimes I want to prune local branches, sometimes not.
OK, then that means it must be a fetch command-line thing, not a
configured thing. Though note that even leaving prune out, I don't think
git does what you want (e.g., how are you fetching only to update
existing branches?).
> > No, you would just do "--prune", because your refspecs are _already_
> > indicating that you are writing into the local namespace, and anything
> > you have locally would be deleted by the prune operation. I.e., there is
> > no need for --prune-local in this scenario; --prune already does what we
> > want.
>
> That's very risky. The user might forget that this is a mirror repo,
> and delete the local branches unintentionally. Plus, it would be then
> impossible to prune remote tracking branches.
Sorry, but I don't see how "--prune" is supposed to know what to prune
except through the refspecs that have been provided to it (either in
configuration or on the command line). So what is:
git fetch --prune <remote> refs/*:refs/*
_supposed_ to do, if not prune your local namespace?
I don't buy the "it's too risky" argument. You have configured a remote
that will fetch and overwrite your local branches already, if you ever
run "git fetch foo". But somehow running "git fetch --prune foo" is too
risky, because you might forget that it will delete all of your
branches?
> > As a user, how do I resolve the situation? I might say topic-Y is
> > obsolete and get rid of it. I might rebase it onto another branch. Or I
> > might declare it to have no upstream. But all of those are branch
> > operations, not fetch operations.
>
> Yes, but that has nothing to do with the operation I want to achieve:
> git remote sync. By which I mean synchronize the local branches with
> the branches of a certain remote.
Right. I was only trying to explain a case where you would want to prune
in the local namespace, when fetch is not configured to touch the local
namespace. Which is the only use case I could think of for something
named --prune-local. But let's forget it. My point was that it is not
related to fetch, and I was just guessing at what you might want from
--prune-local.
> > So what I was trying to say was that either your fetch refspecs tell
> > fetch to write into your local branch namespace, or not. If they do,
> > then --prune is sufficient (with no -local variant required). If not,
> > then touching your local branch namespace is outside the scope of fetch.
>
> I don't want this to be a *permanent* configuration. I see this
> similar to --force. You can achieve the same by adding a + at the
> beginning of the refspec, but this is something that should be
> activated on a per-command basis, thus the option. I think this should
> be the same.
Then you can tweak what is pruned on a per-command basis by providing
alternate refspecs. Right now that would probably mean:
git fetch --prune <remote> refs/*:refs/*
or
git fetch --prune <remote> refs/heads/*:refs/remotes/<remote>/*
but as we discussed earlier in the thread, those can be made less scary
with syntactic sugar.
-Peff
^ permalink raw reply
* [PATCH] run-command.c: Accept EACCES as command not found
From: Frans Klaver @ 2011-11-21 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Frans Klaver
execvp returns ENOENT if a command was not found after searching PATH.
If path contains a directory that current user has insufficient
privileges to, EACCES is returned. This may still mean the program
wasn't found.
If the latter case is encountered, git errors out without giving aliases
a try, which breaks t0001.3 and alias handling in general.
This can be fixed by handling the EACCES case equally to the ENOENT
case.
Signed-off-by: Frans Klaver <fransklaver@gmail.com>
---
I'm actually not too happy about the location of the tests. I couldn't
find out from the available tests and the documentation where I would
have to create the new ones. For now, I've added the tests to the same
set that I found the issue with.
run-command.c | 10 ++++++++--
t/t0001-init.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/run-command.c b/run-command.c
index 1c51043..ad3c120 100644
--- a/run-command.c
+++ b/run-command.c
@@ -280,12 +280,18 @@ fail_pipe:
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
- if (errno == ENOENT) {
+ switch (errno) {
+ case ENOENT:
if (!cmd->silent_exec_failure)
error("cannot run %s: %s", cmd->argv[0],
strerror(ENOENT));
exit(127);
- } else {
+ case EACCES:
+ if (!cmd->silent_exec_failure)
+ error("fatal: cannot exec '%s': %s", cmd->argv[0],
+ strerror(EACCES));
+ exit(127);
+ default:
die_errno("cannot exec '%s'", cmd->argv[0]);
}
}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index ad66410..d40966a 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -63,6 +63,54 @@ test_expect_success 'plain through aliased command, outside any git repo' '
check_config plain-aliased/.git false unset
'
+test_expect_success 'plain through aliased command, inaccessible path, outside any git repo' '
+ (
+ sane_unset GIT_DIR GIT_WORK_TREE &&
+ HOME=$(pwd)/alias-config-path &&
+ export HOME &&
+ mkdir alias-config-path &&
+ echo "[alias] aliasedinit = init" >alias-config-path/.gitconfig &&
+
+ GIT_CEILING_DIRECTORIES=$(pwd) &&
+ export GIT_CEILING_DIRECTORIES &&
+
+ mkdir searchpath &&
+ chmod 400 searchpath &&
+ PATH=$(pwd)/searchpath:$PATH &&
+ export PATH &&
+
+ mkdir plain-aliased-path &&
+ cd plain-aliased-path &&
+ git aliasedinit
+ ) &&
+ check_config plain-aliased-path/.git false unset
+'
+
+test_expect_success 'plain through aliased command, inaccessible command, outside any git repo' '
+ (
+ sane_unset GIT_DIR GIT_WORK_TREE &&
+ HOME=$(pwd)/alias-config-cmd &&
+ export HOME &&
+ mkdir alias-config-cmd &&
+ echo "[alias] aliasedinit = init" >alias-config-cmd/.gitconfig &&
+
+ GIT_CEILING_DIRECTORIES=$(pwd) &&
+ export GIT_CEILING_DIRECTORIES &&
+
+ mkdir searchpathcmd &&
+ chmod 755 searchpathcmd &&
+ PATH=$(pwd)/searchpathcmd:$PATH &&
+ export PATH &&
+
+ touch searchpathcmd/git-aliasedinit &&
+
+ mkdir plain-aliased-cmd &&
+ cd plain-aliased-cmd &&
+ git aliasedinit
+ ) &&
+ check_config plain-aliased-cmd/.git false unset
+'
+
test_expect_failure 'plain nested through aliased command' '
(
sane_unset GIT_DIR GIT_WORK_TREE &&
--
1.7.7
^ permalink raw reply related
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Phillip Susi @ 2011-11-21 22:09 UTC (permalink / raw)
To: Jeff King; +Cc: Simon Brenner, git
In-Reply-To: <20111114103451.GA10847@sigill.intra.peff.net>
On 11/14/2011 5:34 AM, Jeff King wrote:
> One issue with this scheme (or most similar schemes) is that child repos
> are uniquely identified by their directory name. In the absence of
> alternates, it's perfectly reasonable to do:
>
> git init; hack hack hack; commit commit commit
> cd .. ; mv project new-project-name
>
> but here it would break the shared repo's link to the child (which is
> not just inconvenient, but dangerous, as we will not respect its refs
> when pruning). Probably the "warning" above should actually error out
> and force the user to say "yes, I deleted this child" or "no, I moved it
> here".
I hacked together a setup a few weeks ago that doesn't suffer from that
problem. I had two repos that had considerable shared history ( one
forked from the other ), so I created a temporary repository and pointed
its alternates to the other two. I then did some shell magic to
generate a list of all objects shared by both repos, and sent that list
to git-pack-objects. This gave me a pack file in the temp repo that
contained all of the shared objects. I then made a .keep file and hard
linked this pack file ( and index, and .keep file ) into both original
repos, deleted the temp repo, and then repacked both original repos.
This left them both with two pack files: one that is shared, and one
that is all of the objects specific to that repo.
Because the shared objects are in a pack file that both repos hard link
to, neither one will break if I (re)move the other. It would be nice if
git relink could be enhanced to do this, then you can just periodically
run relink with a list of repos and it could hard link all of the shared
data into a big shared pack file, with no need to have a "master" repo
that requires special handling.
^ permalink raw reply
* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Junio C Hamano @ 2011-11-21 22:13 UTC (permalink / raw)
To: Frans Klaver; +Cc: git
In-Reply-To: <1321912387-4569-1-git-send-email-fransklaver@gmail.com>
Frans Klaver <fransklaver@gmail.com> writes:
> execvp returns ENOENT if a command was not found after searching PATH.
> If path contains a directory that current user has insufficient
> privileges to, EACCES is returned. This may still mean the program
> wasn't found.
>
> If the latter case is encountered, git errors out without giving aliases
> a try,...
Isn't that a *good* thing in general, though, so that the user can
diagnose the breakage in the $PATH and fix it?
^ permalink raw reply
* Re: [RFC] deprecating and eventually removing "git relink"?
From: Jeff King @ 2011-11-21 22:19 UTC (permalink / raw)
To: Phillip Susi; +Cc: Simon Brenner, git
In-Reply-To: <4ECACC13.7050507@cfl.rr.com>
On Mon, Nov 21, 2011 at 05:09:23PM -0500, Phillip Susi wrote:
> I hacked together a setup a few weeks ago that doesn't suffer from
> that problem. I had two repos that had considerable shared history (
> one forked from the other ), so I created a temporary repository and
> pointed its alternates to the other two. I then did some shell magic
> to generate a list of all objects shared by both repos, and sent that
> list to git-pack-objects. This gave me a pack file in the temp repo
> that contained all of the shared objects. I then made a .keep file
> and hard linked this pack file ( and index, and .keep file ) into
> both original repos, deleted the temp repo, and then repacked both
> original repos. This left them both with two pack files: one that is
> shared, and one that is all of the objects specific to that repo.
>
> Because the shared objects are in a pack file that both repos hard
> link to, neither one will break if I (re)move the other.
Yes, that is one way to do it. The big drawback there is that by using
hard links, you can only share objects between repos within the same
filesystem.
I think the presence of the '.keep' files should make "git gc" do the
right thing, and not waste space. The relinking procedure is a little
more complex, but that's not a big deal. It's just a periodic
maintenance thing that will happen inside a script (and you would want
to do the periodic maintenance as often as you would with the shared
repo approach).
Nothing is maintaining the list of "here are all of the related repos
that are sharing objects". Which is a feature in some ways, because you
don't have to care if repos go away or move. But when your periodic "git
relink" comes around, the burden is on the user to redecide the set of
related repos.
So unlike with the shared repo, where "git gc" in a child repo could say
"Oh, I have a shared parent; I should go there and do the parent-gc
there", relinking would be a more manual thing. On the other hand,
nothing is stopping you from building something more automated around
this relink-repos-together building block.
So yeah, I think it's a perfectly reasonable approach, if you don't mind
the hard link requirement, and your relink is something like "git relink
~/linux-repos/*".
Patches? :)
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] revert: rename --reset option to --quit
From: Jakub Narebski @ 2011-11-21 22:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord
In-Reply-To: <7vpqglfc1k.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
> > The option to "git cherry-pick" and "git revert" to discard the
> > sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
> > --reset to remove sequencer state, 2011-08-04) has a confusing name.
> > Change it now, while we still have the time.
> >
> > Mechanics:
> >
> > This commit removes the "git cherry-pick --reset" option. Hopefully
> > nobody was using it. If somebody was, we can add it back again as a
> > synonym.
> >
> > The new name for "cherry-pick, please get out of my way, since I've
> > long forgotten about the sequence of commits I was cherry-picking when
> > you wrote that old .git/sequencer directory" is --quit.
>
> Wouldn't it match other commands better if we called this --abort instead
> of --quit?
Actually from what I understand --reset / --quit has to have different
meaning than --abort. While for multi-commit operation --abort goes back
to the state before last operation, --reset / --quit just clears sequencer
state, but does not change working area, nor index, not HEAD. This is to
be used when encounering stale old rebase / am / cherry-pick / revert.
BTW. I think that '--clear' (or '--clear-state') would be a better name
for this option.
> Other than that I think I agree with the reasoning (and I think I too had
> encountered the irritation with the "sequencer state").
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH 1/3] revert: rename --reset option to --quit
From: Jonathan Nieder @ 2011-11-21 22:43 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, Ramkumar Ramachandra, git, Christian Couder,
Martin von Zweigbergk, Phil Hord
In-Reply-To: <m3bos5m7ez.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Actually from what I understand --reset / --quit has to have different
> meaning than --abort.
Right. I'll send a strawman series that introduces a "cherry-pick
--abort" option soon to clarify this.
[...]
> BTW. I think that '--clear' (or '--clear-state') would be a better name
> for this option.
Could you explain why? When I run "git cherry-pick --clear", I'd
expect that it removes some files. Problems:
(1) It's not clear to the novice _which_ files it will remove. Maybe
".rej" files or something?
(2) That the sequencer state is stored in files is an implementation
detail.
>> Other than that I think I agree with the reasoning (and I think I too had
>> encountered the irritation with the "sequencer state").
Thanks for the quick feedback, both of you.
^ permalink raw reply
* Re: [PATCH] run-command.c: Accept EACCES as command not found
From: Frans Klaver @ 2011-11-21 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbos5f7ix.fsf@alter.siamese.dyndns.org>
On Mon, 21 Nov 2011 23:13:58 +0100, Junio C Hamano <gitster@pobox.com>
wrote:
> Frans Klaver <fransklaver@gmail.com> writes:
>
>> execvp returns ENOENT if a command was not found after searching PATH.
>> If path contains a directory that current user has insufficient
>> privileges to, EACCES is returned. This may still mean the program
>> wasn't found.
>>
>> If the latter case is encountered, git errors out without giving aliases
>> a try,...
>
> Isn't that a *good* thing in general, though, so that the user can
> diagnose the breakage in the $PATH and fix it?
Actually I went through diagnosing and fixing it. After tracking it down,
I did wonder about this question myself and I didn't come to a definitive
conclusion on it. On one hand I do agree that it may be an incentive for
the user to fix his path. On the other hand I found it an obscure one to
track down; git's behavior doesn't match bash behavior:
$ git config --global alias.aliasedinit init &&
mkdir searchpath && chmod 400 searchpath && PATH=$(pwd)/searchpath:$PATH
&& export PATH &&
mkdir someproject && cd someproject &&
git aliasedinit
fatal: cannot exec 'git-aliasedinit': Permission denied
$ git-aliasedinit
bash: git-aliasedinit: command not found
This isn't very intuitive to track down an incorrect PATH with, imo. You
have to dig into git core code, learn about how git handles commands,
learn about debugging forked processes, and find out that execvp uses
EACCES for more than just "permission denied" _just_ to find out you've
got a wrong environment variable lying about. That's a full day of work
gone for a newbie. If bash would also tell me in natural language that
permission was denied, I wouldn't even have considered doing this patch.
For my part the root of the problem lies with the use of EACCES by execvp
here, not so much with how git uses it. For this particular case, EACCES
doesn't just mean "it exists, but you cannot execute this", it may also
mean "not found, but one of the paths could not be accessed". If git were
to provide a really helpful message, we'd have to detect which paths got
denied. Once we know that, we can even on the spot decide to error out or
not. In other words, we'd have to figure out which meaning of EACCES is
actually used. Based on that, git can error out, warn or ignore at will.
In any case, I thought it best to have other developers have a look at it.
I can put a bit more of that information in the commit message, but I'd be
just as happy to drop the patch and keep the exercise.
Frans
^ 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