* 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: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: 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
* [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: [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
* 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] 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: 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: 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: [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: [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
* [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] 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
* 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
* [PATCH] Documentation update for 'git branch --list'
From: Vincent van Ravesteijn @ 2011-11-21 14:33 UTC (permalink / raw)
To: git; +Cc: gitster, git, Vincent van Ravesteijn
Indicate that the <pattern>... argument is only valid when using --list.
Otherwise a branch with the name <pattern> will be created. The current
synopsis also suggests that 'git branch -d <pattern>...' would be a valid
command.
Minor changes:
- add a period to a sentence,
- change tag into branch.
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.
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Show error for 'git merge' with unset merge.defaultToUpstream
From: Vincent van Ravesteijn @ 2011-11-21 13:30 UTC (permalink / raw)
To: git; +Cc: gitster, Vincent van Ravesteijn
'git merge' can be called without any arguments if merge.defaultToUpstream
is set. However, when merge.defaultToUpstream is not set, the user will be
presented the usage information as if he entered a command with a wrong
syntaxis. Ironically, the usage information confirms that no arguments are
mandatory.
This adds a proper error message telling the user why the command failed. As
a side-effect this can help the user in discovering the possibility to merge
with the upstream branch by setting merge.defaultToUpstream.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
builtin/merge.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index dffd5ec..900a297 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1160,9 +1160,12 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
die(_("You cannot combine --no-ff with --ff-only."));
if (!abort_current_merge) {
- if (!argc && default_to_upstream)
- argc = setup_with_upstream(&argv);
- else if (argc == 1 && !strcmp(argv[0], "-"))
+ if (!argc) {
+ if (default_to_upstream)
+ argc = setup_with_upstream(&argv);
+ else
+ die(_("No commit specified and merge.defaultToUpstream not set."));
+ } else if (argc == 1 && !strcmp(argv[0], "-"))
argv[0] = "@{-1}";
}
if (!argc)
--
1.7.4.1
^ permalink raw reply related
* Re: Feature requset: listing of current stash in git gui
From: dexen deVries @ 2011-11-21 12:41 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4ECA2D8F.4060005@atlas-elektronik.com>
On Monday 21 of November 2011 11:53:03 Stefan Näwe wrote:
> You can simply put the following in your ~/.gitconfig:
>
> [guitool "Stash/show"]
> cmd = git stash show -p
> [guitool "Stash/list"]
> cmd = git stash list
> [guitool "Stash/pop"]
> cmd = git stash pop
> [guitool "Stash/drop"]
> cmd = git stash drop
> confirm = yes
that's nice, but doesn't list visually the stashed changes. I'd rather have a
listing similar to Unstanged Changes / Staged Changes, with ability to view
line-by-line diff just like for Changes.
Regards,
--
dexen deVries
[[[↓][→]]]
``As my friend Jacob Gabrielson once put it, advocating Object-Oriented
Programming is like advocating Pants-Oriented Clothing.''
-- Steve Yegge, in
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
^ permalink raw reply
* Re: [PATCH] documentation fix: git difftool uses diff tools, not merge tools.
From: David Aguilar @ 2011-11-21 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Hochstein, git
In-Reply-To: <7v62imi6c7.fsf@alter.siamese.dyndns.org>
On Mon, Nov 14, 2011 at 4:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thomas Hochstein <thh@inter.net> writes:
>
>> Let the documentation for -t list valid *diff* tools,
>> not valid *merge* tools.
>>
>> Signed-off-by: Thomas Hochstein <thh@inter.net>
>> ---
>> Documentation/git-difftool.txt | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
>> index a03515f..19d473c 100644
>> --- a/Documentation/git-difftool.txt
>> +++ b/Documentation/git-difftool.txt
>> @@ -31,7 +31,7 @@ OPTIONS
>> -t <tool>::
>> --tool=<tool>::
>> Use the diff tool specified by <tool>.
>> - Valid merge tools are:
>> + Valid diff tools are:
>> araxis, bc3, diffuse, emerge, ecmerge, gvimdiff, kdiff3,
>> kompare, meld, opendiff, p4merge, tkdiff, vimdiff and xxdiff.
>> +
>
> The patch is obviously correct, and it is so trivial that there is no risk
> of breaking anything. It would even be OK for 1.7.7.X maintenance series.
>
> But in the longer term, I suspect that we would want to drop this
> enumeration from the documentation, and instead give "--list-tools"
> option or something to the command. That way, we only need to keep
> the list of known tools in one place where it matters, namely, the
> command that knows about them.
>
> David, what do you think?
>
> The same comment applies to "git mergetool", I would think.
Exactly my thoughts.
--
David
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: Stefan Näwe @ 2011-11-21 10:53 UTC (permalink / raw)
To: dexen deVries; +Cc: git@vger.kernel.org
In-Reply-To: <201111211100.52367.dexen.devries@gmail.com>
Am 21.11.2011 11:00, schrieb dexen deVries:
> Hi,
>
>
> please consider listing modifications stored in git's stash somewhere in git
> gui window. Perhaps above the `Staged Changes' subframe. Format of the listing
> similar to output of `git stash list'. Available operations would be Pop,
> Apply, Save and Drop.
You can simply put the following in your ~/.gitconfig:
[guitool "Stash/show"]
cmd = git stash show -p
[guitool "Stash/list"]
cmd = git stash list
[guitool "Stash/pop"]
cmd = git stash pop
[guitool "Stash/drop"]
cmd = git stash drop
confirm = yes
That will give you a new sub-menu in the 'Tools' menu of git gui.
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Dreams are free, but you get soaked on the connect time.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Feature requset: listing of current stash in git gui
From: dexen deVries @ 2011-11-21 10:00 UTC (permalink / raw)
To: git
Hi,
please consider listing modifications stored in git's stash somewhere in git
gui window. Perhaps above the `Staged Changes' subframe. Format of the listing
similar to output of `git stash list'. Available operations would be Pop,
Apply, Save and Drop.
Regards,
--
dexen deVries
[[[↓][→]]]
``As my friend Jacob Gabrielson once put it, advocating Object-Oriented
Programming is like advocating Pants-Oriented Clothing.''
-- Steve Yegge, in
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-21 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vsjlhhq33.fsf@alter.siamese.dyndns.org>
On Mon, Nov 21, 2011 at 2:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If this is a feature, we would like a patch to Documentation/gitignore.txt
> as well, I think. Also I have a suspicion that this was an unintended
> "regression"; do you have a bisection?
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. "read tree --exclude-per-directory"
is used in git-checkout.sh and the same logic is carried over to
builtin-checkout.c until today.
I guess it's time to add "read-tree --exclude-from". Not sure what to
do with git-checkout though. We may add an option to checkout to skip
either .git/info/exclude or .gitignore, or both.
--
Duy
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-21 8:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
On Mon, Nov 21, 2011 at 08:23:45AM +0100, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> It is an unintended accident that entries matched by .git/info/exclude are
> considered precious, but entries matched by .gitignore are not. That is,
> 'git checkout' will overwrite untracked files matched by .gitignore, but
> refuses to overwrite files matched by .git/info/exclude.
>
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
>
> Add a test that codifies the accident as wanted behavior.
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. This patch makes t2023.3
fail. I haven't dug into history to see if this is on purpose though.
-- 8< --
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2a80772..c2fc2ba 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -412,6 +412,8 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.dir = xcalloc(1, sizeof(*topts.dir));
topts.dir->flags |= DIR_SHOW_IGNORED;
topts.dir->exclude_per_dir = ".gitignore";
+ if (!access(git_path("info/exclude"), R_OK))
+ add_excludes_from_file(topts.dir, git_path("info/exclude"));
tree = parse_tree_indirect(old->commit ?
old->commit->object.sha1 :
EMPTY_TREE_SHA1_BIN);
-- 8< --
--
Duy
^ permalink raw reply related
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 7:59 UTC (permalink / raw)
To: Philip Oakley; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <00392567F0B045E38A429F95594C1BD2@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> Shouldn't there be some documentation changes to support this very
> useful feature.
I do not agree it is "useful", if it is info/exclude only, which by design
would not propagate across repositories and histories.
If we were to support "precious" as a feature, we should do that properly
with a properly defined syntax (e.g. just like '!' prefix is "no, this is
not 'ignored' entry", use some prefix to say "well, this is ignored in the
sense that not to be tracked, but that does not mean this can be nuked")
that can be in any exclude sources.
Exclude patterns in info/exclude should work just like ones in the in-tree
.gitignore only at different precedence for uniformity and consistency, so
the behaviour J6t showed in the new test should be fixed.
The entries in info/exclude are at lower priority than the ones in in-tree
.gitignore files, which probably was a design mistake, but that is a
separate issue.
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 7:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
> ...
> Here you are. As you can see from my commit message, IMO, this is
> a very useful accident. Therefore, there is no 'test_expect_failure'
> in the test script :-)
Heh.
If this is a feature, we would like a patch to Documentation/gitignore.txt
as well, I think. Also I have a suspicion that this was an unintended
"regression"; do you have a bisection?
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Philip Oakley @ 2011-11-21 7:45 UTC (permalink / raw)
To: Johannes Sixt, Junio C Hamano; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
From: "Johannes Sixt" <j.sixt@viscovery.net>
> From: Johannes Sixt <j6t@kdbg.org>
>
> It is an unintended accident that entries matched by .git/info/exclude are
> considered precious, but entries matched by .gitignore are not. That is,
> 'git checkout' will overwrite untracked files matched by .gitignore, but
> refuses to overwrite files matched by .git/info/exclude.
>
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
>
> Add a test that codifies the accident as wanted behavior.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Am 11/21/2011 4:36, schrieb Junio C Hamano:
>> As far as I am aware, info/exclude should work exactly the same as having
>> a .gitignore file at the root level of the working tree. Can you show a
>> minimum reproduction recipe in a form of a patch to our test scripts in
>> t/
>> hierarchy?
>
> Here you are. As you can see from my commit message, IMO, this is
> a very useful accident. Therefore, there is no 'test_expect_failure'
> in the test script :-)
Shouldn't there be some documentation changes to support this very useful
feature. By documenting the existing code functionality we get the double
benefit of no code changes and we publish the existance of a desired bit of
functionality.
Philip
>
> -- Hannes
>
> t/t2023-checkout-ignored.sh | 51
> +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 51 insertions(+), 0 deletions(-)
> create mode 100755 t/t2023-checkout-ignored.sh
>
> diff --git a/t/t2023-checkout-ignored.sh b/t/t2023-checkout-ignored.sh
> new file mode 100755
> index 0000000..03a5a56
> --- /dev/null
> +++ b/t/t2023-checkout-ignored.sh
> @@ -0,0 +1,51 @@
> +#!/bin/sh
> +
> +test_description='checkout overwrites or preserves ignored files
> +
> +`git checkout` makes a distinction between files mentioned in
> +.gitignore and .git/info/exclude in that untracked files matched
> +by the latter are considered precious and are not overwritten.
> +'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> +
> + echo excluded > excluded &&
> + echo ignored > ignored &&
> + git add . &&
> + test_commit initial &&
> + git checkout -b side &&
> + git rm excluded &&
> + git mv ignored .gitignore &&
> + test_commit side &&
> + echo excluded >> .git/info/exclude
> +'
> +
> +test_expect_success 'files are ignored' '
> +
> + echo keep > excluded &&
> + echo overwrite > ignored &&
> + list=$(git ls-files --others --exclude-standard) &&
> + test -z "$list"
> +'
> +
> +test_expect_success 'entries in .git/info/exclude are precious' '
> +
> + test_must_fail git checkout master 2>errors &&
> + test_i18ngrep "would be overwritten" errors &&
> + grep " excluded" errors &&
> + ! grep " ignored" errors &&
> + grep keep excluded &&
> + grep overwrite ignored
> +'
> +
> +test_expect_success 'entries in .gitignore are not precious' '
> +
> + rm -f excluded &&
> + git checkout master &&
> + grep excluded excluded &&
> + grep ignored ignored
> +'
> +
> +test_done
> --
> 1.7.8.rc0.126.gd15506
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1872 / Virus Database: 2092/4628 - Release Date: 11/20/11
>
^ 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