RE: problems with git --git-dir on windows 7
Hi all,
Thanks for your answers:
As you said the solution is:
For non-bare-repos the .git-directory must be specified:
git --git-dir=c:\usertemp\git\appli2\.git tag
for bare-repositories the .git does not exist , so
git --git-dir=c:\usertemp\git\appli3_bare tag
works(bare-repo) correctly
thanks a lot
Manfred
-Original Message-
From: Trần Ngọc Quân [mailto:vnwild...@gmail.com]
Sent: vendredi 6 décembre 2013 02:35
To: SCHILZ MANFRED
Cc: Duy Nguyen; Git Mailing List; msysGit
Subject: Re: problems with git --git-dir on windows 7
* This message comes from the Internet Network *
On 06/12/2013 08:07, Duy Nguyen wrote:
> On Wed, Dec 4, 2013 at 11:11 PM, SCHILZ MANFRED wrote:
>> Hello,
>> We are using git on windows7(git-version 1.8.1; see below) and we get the
>> following problem in using the command 'git --git-dir='
>>
>>
>> C:\UserTemp\git\appli3>git --git-dir=C:\UserTemp\git\appli3 tag
>> fatal: Not a git repository: 'C:\UserTemp\git\appli3'
>>
>>
>> but the repository is well defined,as we can run the following command:
>>
>> C:\UserTemp\git\appli3>git log -1 --oneline
>> 37cdbe0 Merge branch 'master' of
>> L:/_ApplicationData/FBLU_IT-FLIT/se-DevelopSupp
> I have no clue. The --git-dir calls
> is_git_directory("C:\\UserTemp\\git\\appli3") while the "git log"
> calls is_git_directory("."). The former fails and the latter suceeds..
> Copying msysgit@ maybe they know something. Btw what if you try
>
> git --git-dir=. tag
in linux:
$ git --git-dir=. tag
fatal: Not a git repository: '.'
>
> ?
You have to specify git dir instead of the dir contain .git This option use
when your are not in git repo or git dir isn't .git as by default $ git
--git-dir=.git tag $ git --git-dir=/mnt/E/MyProjects/git/.git tag $ git
--version git version 1.8.5-rc1
>
>> When running the equivalent command on Linux, we don't have any problems:
>> On Linux:
>>> git --git-dir="/tmp/GITPOC/appli3" tag
>> V1.0
>> V1.1
>> V2.0
>> V3.0
>>
>> Could you help me please ?
>>
>> Best regards
>>
>> Manfred Schilz
>>
>> -
>> --
>> C:\UserTemp\git\appli3>git --version
>> git version 1.8.1.msysgit.1
>>
>>
>> Internet communications are not secure and therefore BGL BNP Paribas does
>> not accept legal responsibility for the contents of this message. The
>> information contained in this e-mail is confidential and may be legally
>> privileged. It is intended solely for the addressee. If you are not the
>> intended recipient, any disclosure, copying, distribution or any action
>> taken or omitted to be taken in reliance on it, is prohibited and may be
>> unlawful. Nothing in the message is capable or intended to create any
>> legally binding obligations on either party and it is not intended to
>> provide legal advice.
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in the
>> body of a message to majord...@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
>
--
Trần Ngọc Quân.
Re: Publishing "filtered branch repositories" - workflow / recommendations?
Am 05.12.2013 23:06, schrieb Martin Langhoff:
> On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann wrote:
>> Am 05.12.2013 20:27, schrieb Martin Langhoff:
>>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:
Without knowing more I can't think of a reason why submodules should
not suit your use case (but you'd have to script branching and tagging
yourself until these commands learn to recurse into submodules too).
>>>
>>> The submodules feature is way too fiddly and has abundant gotchas.
>>
>> Care to explain what bothers you the most? Being one of the people
>> improving submodules I'm really interested in hearing more about that.
>
> Very glad to hear submodules is getting TLC! I have other scenarios at
> $dayjob where I may need submodules, so happy happy.
>
> I may be unaware of recent improvements, here's my (perhaps outdated) list
Thanks a lot for your feedback!
> - git clone does not clone existing submodules by default. An ideal
> workflow assumes that the user wants a fully usable checkout.
You get that when using "git clone --recurse-submodules", but there
is no configuration option yet to switch that on by default (but we
are planning to add one).
> - git pull does not fetch&update all submodules (assuming a trivial
> "tracking repos" scenario)
Current pull does fetch them (when changes to them are found in the
fetched commits of the superproject), but it does not yet update
them (there is the "recursive update" work in progress to do that).
> - git push does not warn if you forgot to push commits in the submodule
We do have a command line option ("--recurse-submodules=check" is
what you want here), but no configuration option yet.
> there's possibly a few others that I've forgotten. The main issue is
> that things that are conceptually simple (clone, git pull with no
> local changes) are very fiddly. Our new developers, testers and
> support folks hurt themselves with it plenty.
Seems like we already solved some of those, and your feedback shows
me that we are moving in the right direction. I keep a list of open
issues we are aware of at:
https://github.com/jlehmann/git-submod-enhancements/wiki
Feel free to point out missing topics.
> I don't mind complex scenarios being complex to handle. If you hit a
> nasty merge conflict in your submodule, and that's gnarly to resolve,
> that's not a showstopper.
Good to hear that! Solving them automatically is hard, only fast
forwards are currently resolved without user intervention.
> While writing this email, I reviewed Documentation/git-submodule.txt
> in git master, and it does seem to have grown some new options. I
> wonder if there is a tutorial with an example workflow anywhere
> showing the current level of usability. My hope is actually for some
> bits of automagic default behaviors to help things along (rather than
> new options)...
Right you are, we need tutorials for the most prominent use cases.
> Early git was very pedantic, and over time it learned some DWIMery.
> You're giving me hope that similar smarts might have grown in around
> submodule support ...
That's what we are aiming at :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules
gitmodules(5) states that submodule.$name.update should be defined in .gitmodules. However in cmd_update() in git-submodule.sh, git config is used with "-f .gitmodules". Consequently this flag is only respected in .git/config Tested against: 1.8.2.1 [sorry! I've checked the relevant bit of source and it's the same] Steps to reproduce: $ git init $ git submodule add -b master someproject $ git config -f .gitmodules --add submodule.someproject.update merge $ # Go to someproject and commit something $ git submodule update --remote The latter does not perform a merge, and behaviour is visibly different to adding --merge. I would submit a patch but I'm not completely sure what the behaviour would be - simply adding "-f .gitmodules" would hurt users that have adopted the practice of specifying their update preference in .git/config. Perhaps the right thing to do is read from .git/config and fall back to .gitmodules using get_submodule_config(). Cheers, Charlie -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git reports
Hi, On another git server, I get reports like Cloning into 'tcmb'... remote: Counting objects: 704, done. remote: Compressing objects: 100% (574/574), done. remote: Total 704 (delta 369), reused 107 (delta 60) Receiving objects: 100% (704/704), 129.99 KiB | 23 KiB/s, done. Resolving deltas: 100% (369/369), done. whereas I don't get those with my own. What could I be doing wrong? Regards, mto -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
On Fri, 6 Dec 2013 18:51:47 +0200 Muzaffer Tolga Ozses wrote: > On another git server, I get reports like > Cloning into 'tcmb'... > remote: Counting objects: 704, done. > remote: Compressing objects: 100% (574/574), done. > remote: Total 704 (delta 369), reused 107 (delta 60) > Receiving objects: 100% (704/704), 129.99 KiB | 23 KiB/s, done. > Resolving deltas: 100% (369/369), done. > > whereas I don't get those with my own. What could I be doing wrong? The documentation on `git push` states: --progress Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal. So it might turn out on your own server Git for some reason fails to figure out its standard error stream is connected to a terminal. Or, the error stream of your shell process is redirected somewhere (and hence inherited by Git). Or you pass the "-q" command-line option to `git clone`. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
On Fri, 6 Dec 2013 21:00:35 +0400 Konstantin Khomoutov wrote: [...] > > Resolving deltas: 100% (369/369), done. > > > > whereas I don't get those with my own. What could I be doing wrong? > > The documentation on `git push` states: > > --progress > > Progress status is reported on the standard error stream by > default when it is attached to a terminal, unless -q is specified. > This flag forces progress status even if the standard error stream is > not directed to a terminal. > > So it might turn out on your own server Git for some reason fails to > figure out its standard error stream is connected to a terminal. > Or, the error stream of your shell process is redirected somewhere > (and hence inherited by Git). To underline the fact this is not all too unlikely, you're able to completely silence error reports in your shell prompt by executing exec 2>/dev/null (you can regain it back by doing `exec 2>&1`). So you might face a misbehaving shell logon script for instance. As to whether Git senses the TTY -- what does running stty tells you? Does it fail with something like "inappropriate ioctl for device" or prints a couple of settings? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitignore excludes not working?
Tested with git 1.7.12.4 (Apple Git-37) and git 1.8.3.1 on F20. $ mkdir foo $ cd foo $ git init Initialized empty Git repository in /tmp/foo/.git/ $ mkdir -p modules/boring $ mkdir -p modules/interesting $ touch modules/boring/lib.c $ touch modules/interesting/other.c $ touch modules/interesting/lib.c $ git add modules/interesting/lib.c $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." to unstage) # # new file: modules/interesting/lib.c # # Untracked files: # (use "git add ..." to include in what will be committed) # # modules/boring/ # modules/interesting/other.c $ echo '/modules/' > .gitignore $ echo '!/modules/interesting/' >> .gitignore On this git status, I would expect to see modules/interesting/other.c listed as untracked, however: $ git status # On branch master # # Initial commit # # Changes to be committed: # (use "git rm --cached ..." to unstage) # # new file: modules/interesting/lib.c # # Untracked files: # (use "git add ..." to include in what will be committed) # # .gitignore thoughts? m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
stty tells me speed 38400 baud; line = 0; eol = M-^?; eol2 = M-^?; swtch = M-^?; ixany iutf8 And I run identical commands on both servers, only URL changes. On 6 December 2013 19:09, Konstantin Khomoutov wrote: > On Fri, 6 Dec 2013 21:00:35 +0400 > Konstantin Khomoutov wrote: > > [...] >> > Resolving deltas: 100% (369/369), done. >> > >> > whereas I don't get those with my own. What could I be doing wrong? >> >> The documentation on `git push` states: >> >> --progress >> >> Progress status is reported on the standard error stream by >> default when it is attached to a terminal, unless -q is specified. >> This flag forces progress status even if the standard error stream is >> not directed to a terminal. >> >> So it might turn out on your own server Git for some reason fails to >> figure out its standard error stream is connected to a terminal. >> Or, the error stream of your shell process is redirected somewhere >> (and hence inherited by Git). > > To underline the fact this is not all too unlikely, you're able to > completely silence error reports in your shell prompt by executing > > exec 2>/dev/null > > (you can regain it back by doing `exec 2>&1`). > > So you might face a misbehaving shell logon script for instance. > > As to whether Git senses the TTY -- what does running > > stty > > tells you? Does it fail with something like "inappropriate ioctl for > device" or prints a couple of settings? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
On Fri, Dec 06, 2013 at 07:44:21PM +0200, Muzaffer Tolga Ozses wrote: > stty tells me > speed 38400 baud; line = 0; > eol = M-^?; eol2 = M-^?; swtch = M-^?; > ixany iutf8 > > And I run identical commands on both servers, only URL changes. What protocol/transport are you using (http, ssh, git)? Can you try running with: GIT_TRACE_PACKET=$PWD/trace.out git clone ... You should be able to see whether the client tells the server to suppress progress output (look for the first "want" line in the output, which may or may not contain the flag "no-progress"). That will let us figure out whether it is the client who is unexpectedly asking to turn off progress, or whether the server is failing to produce progress. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
On Fri, 6 Dec 2013 19:44:21 +0200 Muzaffer Tolga Ozses wrote: [...] > >> > Resolving deltas: 100% (369/369), done. > >> > > >> > whereas I don't get those with my own. What could I be doing > >> > wrong? [...] > >> So it might turn out on your own server Git for some reason fails > >> to figure out its standard error stream is connected to a terminal. > >> Or, the error stream of your shell process is redirected somewhere > >> (and hence inherited by Git). [...] > > So you might face a misbehaving shell logon script for instance. > > > > As to whether Git senses the TTY -- what does running > > > > stty > > > > tells you? Does it fail with something like "inappropriate ioctl > > for device" or prints a couple of settings? > stty tells me > speed 38400 baud; line = 0; > eol = M-^?; eol2 = M-^?; swtch = M-^?; > ixany iutf8 > > And I run identical commands on both servers, only URL changes. OK, so we could supposedly rule out the possibility Git does not sense it's connected to a terminal. So let's do the next test: does echo test >&2 print "test" on the box where Git does not report progress? Another one: does Git report progress if you explicitly pass --progress to it? Does it work if you do git clone $URL 2>&1 ? What Git and OS versions are on both machines? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] diff: Add diff.orderfile configuration variable
Samuel Bronson writes:
> From: Anders Waldenborg
>
> diff.orderfile acts as a default for the -O command line option.
>
> [sb: fixed testcases & revised docs based on Jonathan Nieder's suggestions]
>
> Signed-off-by: Anders Waldenborg
> Thanks-to: Jonathan Nieder
> Signed-off-by: Samuel Bronson
Thanks for reviving a stalled topic.
> ---
> *I* even verified that the tests do fail properly when the feature is
> sabotaged.
Sabotaged in what way?
> Documentation/diff-config.txt | 5 +++
> Documentation/diff-options.txt | 2 ++
> diff.c | 5 +++
> t/t4056-diff-order.sh | 79
> ++
> 4 files changed, 91 insertions(+)
> create mode 100755 t/t4056-diff-order.sh
>
> diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
> index 223b931..f07b451 100644
> --- a/Documentation/diff-config.txt
> +++ b/Documentation/diff-config.txt
> @@ -98,6 +98,11 @@ diff.mnemonicprefix::
> diff.noprefix::
> If set, 'git diff' does not show any source or destination prefix.
>
> +diff.orderfile::
> + File indicating how to order files within a diff, using
> + one shell glob pattern per line.
> + Can be overridden by the '-O' option to linkgit:git-diff[1].
> +
> diff.renameLimit::
> The number of files to consider when performing the copy/rename
> detection; equivalent to the 'git diff' option '-l'.
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index bbed2cd..1af5a5e 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -432,6 +432,8 @@ endif::git-format-patch[]
> -O::
> Output the patch in the order specified in the
> , which has one shell glob pattern per line.
> + This overrides the `diff.orderfile' configuration variable
> + ((see linkgit:git-config[1]).
Double opening parenthesis?
If somebody has diff.orderfile configuration that points at a custom
ordering, and wants to send out a patch (or show a diff) with the
standard order, how would the "overriding" command line look like?
Would it be "git diff -O/dev/null"?
> diff --git a/t/t4056-diff-order.sh b/t/t4056-diff-order.sh
> new file mode 100755
> index 000..a756b34
> --- /dev/null
> +++ b/t/t4056-diff-order.sh
> @@ -0,0 +1,79 @@
> +#!/bin/sh
> +
> +test_description='diff order'
> +
> +. ./test-lib.sh
> +
> +create_files () {
> + echo "$1" >a.h &&
> + echo "$1" >b.c &&
> + echo "$1" >c/Makefile &&
> + echo "$1" >d.txt &&
> + git add a.h b.c c/Makefile d.txt &&
> + git commit -m"$1"
> + return $?
> +}
That return looks somewhat strange. Does it even need to be there?
> +test_expect_success "setup" '
Makes readers wonder why dq is used here, I think.
> + mkdir c &&
> + create_files 1 &&
> + create_files 2
> +'
> +
> +cat >order_file_1 < +*Makefile
> +*.txt
> +*.h
> +*
> +EOF
> +cat >order_file_2 < +*Makefile
> +*.h
> +*.c
> +*
> +EOF
> +
> +cat >expect_diff_headers_none < +diff --git a/a.h b/a.h
> +diff --git a/b.c b/b.c
> +diff --git a/c/Makefile b/c/Makefile
> +diff --git a/d.txt b/d.txt
> +EOF
> +
> +cat >expect_diff_headers_1 < +diff --git a/c/Makefile b/c/Makefile
> +diff --git a/d.txt b/d.txt
> +diff --git a/a.h b/a.h
> +diff --git a/b.c b/b.c
> +EOF
> +
> +cat >expect_diff_headers_2 < +diff --git a/c/Makefile b/c/Makefile
> +diff --git a/a.h b/a.h
> +diff --git a/b.c b/b.c
> +diff --git a/d.txt b/d.txt
> +EOF
All of these "cat" outside the test_expect_* are better be inside
the 'setup' section, I think. I.e.
test_expect_success setup '
mkdir c &&
create_files 1 &&
create_files 2 &&
cat >order_file_1 <<-\EOF &&
*Makefile
*.txt
*.h
*
EOF
cat >order_file_2 <<-\EOF &&
...
cat >expect_diff_headers_2 < +test_expect_success "no order (=tree object order)" '
> + git diff HEAD^..HEAD >patch &&
> + grep ^diff patch >actual_diff_headers &&
> + test_cmp expect_diff_headers_none actual_diff_headers
> +'
Instead of grepping, "git diff --name-only" would be far easier to
check, no?
> +for i in 1 2; do
> + test_expect_success "orderfile using option ($i)" "
> + git diff -Oorder_file_$i HEAD^..HEAD >patch &&
> + grep ^diff patch >actual_diff_headers &&
> + test_cmp expect_diff_headers_$i actual_diff_headers
> +"
> +done
> +for i in 1 2; do
> + test_expect_success "orderfile using config ($i)" "
> + git -c diff.orderfile=order_file_$i diff HEAD^..HEAD >patch &&
> + grep ^diff patch >actual_diff_headers &&
> + test_cmp expect_diff_headers_$i actual_diff_headers
> +"
> +done
I'd probably write the above like so:
for i in 1 2
do
test_expect_success "orderfile using option ($i)" '
git diff -Oorder_file_$i --name-onl
Re: [PATCH 0/3] Exclude pathspec
Nguyễn Thái Ngọc Duy writes: > You > can now say "select this path except this subpath..." for nearly all > commands that take pathspec. Good; thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fixup! config: arbitrary number of matches for --unset and --replace-all
---
* I'll squash this to tr/config-multivalue-lift-max in preparation
for merging it to 'master',which should happen by the end of
this week.
Thanks.
config.c| 8
t/t1303-wacky-config.sh | 14 +++---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/config.c b/config.c
index 431dcb7..a1e80da 100644
--- a/config.c
+++ b/config.c
@@ -1192,7 +1192,7 @@ static int store_aux(const char *key, const char *value,
void *cb)
warning("%s has multiple values", key);
}
- ALLOC_GROW(store.offset, store.seen+1,
+ ALLOC_GROW(store.offset, store.seen + 1,
store.offset_alloc);
store.offset[store.seen] = cf->do_ftell(cf);
@@ -1222,14 +1222,14 @@ static int store_aux(const char *key, const char
*value, void *cb)
* Do not increment matches: this is no match, but we
* just made sure we are in the desired section.
*/
- ALLOC_GROW(store.offset, store.seen+1,
+ ALLOC_GROW(store.offset, store.seen + 1,
store.offset_alloc);
store.offset[store.seen] = cf->do_ftell(cf);
/* fallthru */
case SECTION_END_SEEN:
case START:
if (matches(key, value)) {
- ALLOC_GROW(store.offset, store.seen+1,
+ ALLOC_GROW(store.offset, store.seen + 1,
store.offset_alloc);
store.offset[store.seen] = cf->do_ftell(cf);
store.state = KEY_SEEN;
@@ -1239,7 +1239,7 @@ static int store_aux(const char *key, const char *value,
void *cb)
!strncmp(key, store.key, store.baselen)) {
store.state = SECTION_SEEN;
ALLOC_GROW(store.offset,
- store.seen+1,
+ store.seen + 1,
store.offset_alloc);
store.offset[store.seen] =
cf->do_ftell(cf);
}
diff --git a/t/t1303-wacky-config.sh b/t/t1303-wacky-config.sh
index 7d55730..3a2c819 100755
--- a/t/t1303-wacky-config.sh
+++ b/t/t1303-wacky-config.sh
@@ -66,13 +66,13 @@ setup_many() {
# Semi-efficient way of concatenating 5^5 = 3125 lines. Note
# that because 'setup' already put one line, this means 3126
# entries for section.key in the config file.
- cat >5to1 <5to1 <<-\EOF &&
+ key = foo
+ key = foo
+ key = foo
+ key = foo
+ key = foo
+ EOF
cat 5to1 5to1 5to1 5to1 5to1 >5to2 && # 25
cat 5to2 5to2 5to2 5to2 5to2 >5to3 && # 125
cat 5to3 5to3 5to3 5to3 5to3 >5to4 && # 635
--
1.8.5.1-402-gdd8f092
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
Hi, > What protocol/transport are you using (http, ssh, git)? I am cloning over http > Can you try running with: GIT_TRACE_PACKET=$PWD/trace.out git clone ... GIT_TRACE_PACKET=$PWD/trace.out git clone http://git.webciniz.im/project/night_pharmacy.git Cloning into 'night_pharmacy'... Checking connectivity... done That's all I get. No trace.out was written. > So let's do the next test: does echo test >&2 print "test" on the box where Git does not report progress? Yes it does. > Another one: does Git report progress if you explicitly pass --progress to it? git clone --progress http://git.webciniz.im/project/night_pharmacy.git Cloning into 'night_pharmacy'... Checking connectivity... done That's all I get > Does it work if you do git clone $URL 2>&1 git clone http://git.webciniz.im/project/night_pharmacy.git 2>&1 Cloning into 'night_pharmacy'... Checking connectivity... done That's all I get. Regards mto On 6 December 2013 19:53, Konstantin Khomoutov wrote: > On Fri, 6 Dec 2013 19:44:21 +0200 > Muzaffer Tolga Ozses wrote: > > [...] >> >> > Resolving deltas: 100% (369/369), done. >> >> > >> >> > whereas I don't get those with my own. What could I be doing >> >> > wrong? > [...] >> >> So it might turn out on your own server Git for some reason fails >> >> to figure out its standard error stream is connected to a terminal. >> >> Or, the error stream of your shell process is redirected somewhere >> >> (and hence inherited by Git). > [...] >> > So you might face a misbehaving shell logon script for instance. >> > >> > As to whether Git senses the TTY -- what does running >> > >> > stty >> > >> > tells you? Does it fail with something like "inappropriate ioctl >> > for device" or prints a couple of settings? >> stty tells me >> speed 38400 baud; line = 0; >> eol = M-^?; eol2 = M-^?; swtch = M-^?; >> ixany iutf8 >> >> And I run identical commands on both servers, only URL changes. > > OK, so we could supposedly rule out the possibility Git does not sense > it's connected to a terminal. > > So let's do the next test: does > > echo test >&2 > > print "test" on the box where Git does not report progress? > > Another one: does Git report progress if you explicitly pass --progress > to it? > > Does it work if you do > > git clone $URL 2>&1 > > ? > > What Git and OS versions are on both machines? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
Sorry, my git server is on CentOS and git 1.8.4.2 and my machine on which I clone is Ubuntu, 1.8.3.2 On 6 December 2013 21:19, Muzaffer Tolga Ozses wrote: > Hi, > >> What protocol/transport are you using (http, ssh, git)? > I am cloning over http > >> Can you try running with: > > GIT_TRACE_PACKET=$PWD/trace.out git clone ... > GIT_TRACE_PACKET=$PWD/trace.out git clone > http://git.webciniz.im/project/night_pharmacy.git > Cloning into 'night_pharmacy'... > Checking connectivity... done > > That's all I get. No trace.out was written. > >> So let's do the next test: does > > echo test >&2 > > print "test" on the box where Git does not report progress? > > Yes it does. > >> Another one: does Git report progress if you explicitly pass --progress > to it? > > git clone --progress http://git.webciniz.im/project/night_pharmacy.git > Cloning into 'night_pharmacy'... > Checking connectivity... done > > That's all I get > >> Does it work if you do > > git clone $URL 2>&1 > > git clone http://git.webciniz.im/project/night_pharmacy.git 2>&1 > Cloning into 'night_pharmacy'... > Checking connectivity... done > > That's all I get. > > Regards > mto > > On 6 December 2013 19:53, Konstantin Khomoutov > wrote: >> On Fri, 6 Dec 2013 19:44:21 +0200 >> Muzaffer Tolga Ozses wrote: >> >> [...] >>> >> > Resolving deltas: 100% (369/369), done. >>> >> > >>> >> > whereas I don't get those with my own. What could I be doing >>> >> > wrong? >> [...] >>> >> So it might turn out on your own server Git for some reason fails >>> >> to figure out its standard error stream is connected to a terminal. >>> >> Or, the error stream of your shell process is redirected somewhere >>> >> (and hence inherited by Git). >> [...] >>> > So you might face a misbehaving shell logon script for instance. >>> > >>> > As to whether Git senses the TTY -- what does running >>> > >>> > stty >>> > >>> > tells you? Does it fail with something like "inappropriate ioctl >>> > for device" or prints a couple of settings? >>> stty tells me >>> speed 38400 baud; line = 0; >>> eol = M-^?; eol2 = M-^?; swtch = M-^?; >>> ixany iutf8 >>> >>> And I run identical commands on both servers, only URL changes. >> >> OK, so we could supposedly rule out the possibility Git does not sense >> it's connected to a terminal. >> >> So let's do the next test: does >> >> echo test >&2 >> >> print "test" on the box where Git does not report progress? >> >> Another one: does Git report progress if you explicitly pass --progress >> to it? >> >> Does it work if you do >> >> git clone $URL 2>&1 >> >> ? >> >> What Git and OS versions are on both machines? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
Muzaffer Tolga Ozses wrote: > I am cloning over http I am guessing you are using the "dumb" (plain static file transfer) HTTP protocol. With that protocol the server doesn't do anything other than shuttle out files, so it doesn't need to do its own progress reporting. Perhaps the client should do some progress reporting based on file sizes and amount downloaded so far, but it's hard to get excited about given the existence of "smart" (transfer only what is needed) HTTP protocol. See git-http-backend(1) for details. Perhaps we can document this better? (If so, where would it have been useful to learn about this, and do you have ideas for how it could be worded? I'm thinking it might make sense to put a note on this in a new giturls(7) page with content that used to be in the git-clone(1) 'GIT URLS' section.) Or if someone wants to work on a progress display, that would be nice, too. ;-) Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Publishing "filtered branch repositories" - workflow / recommendations?
On Fri, Dec 6, 2013 at 3:48 AM, Jens Lehmann wrote: > Right you are, we need tutorials for the most prominent use cases. In the meantime, are there any hints? Emails on this list showing a current "smart" workflow? Blog posts? Notes on a wiki? >> Early git was very pedantic, and over time it learned some DWIMery. >> You're giving me hope that similar smarts might have grown in around >> submodule support ... > > That's what we are aiming at :-) That is fantastic! Thank you. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
Jonathan Nieder writes: > Muzaffer Tolga Ozses wrote: > >> I am cloning over http > > I am guessing you are using the "dumb" (plain static file transfer) > HTTP protocol. With that protocol the server doesn't do anything > other than shuttle out files, so it doesn't need to do its own > progress reporting. > > Perhaps the client should do some progress reporting based on file > sizes and amount downloaded so far, but it's hard to get excited > about given the existence of "smart" (transfer only what is needed) > HTTP protocol. See git-http-backend(1) for details. > > Perhaps we can document this better? (If so, where would it have been > useful to learn about this, and do you have ideas for how it could be > worded? I'm thinking it might make sense to put a note on this in a > new giturls(7) page with content that used to be in the git-clone(1) > 'GIT URLS' section.) Or if someone wants to work on a progress > display, that would be nice, too. ;-) I wouldn't be worried too much about progress display, but I would think it might be a good idea to teach the http client side, perhaps with a -v option, to report which variant of the protocol is in use, primarily to warn those who have a server that is capable of running the smart protocol but forgot to set it up, or unaware that smart is generally a better option for them. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fixup! config: arbitrary number of matches for --unset and --replace-all
On Fri, Dec 06, 2013 at 10:46:42AM -0800, Junio C Hamano wrote: > --- > * I'll squash this to tr/config-multivalue-lift-max in preparation >for merging it to 'master',which should happen by the end of >this week. Yeah, all makes sense to me. Thanks. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] rev-parse and "--"
On Thu, Dec 05, 2013 at 01:44:12PM -0800, Junio C Hamano wrote: > ;-) Good flow of thought. As to your rev-parse change, I don't > immediately think of a hole/flaw offhand; it looked a good > straight-forward change to me. Here it is with tests and a commit message. While writing the tests, I noticed that also do not handle true ambiguity the same (we prefer revs, rather than complaining). That's fixed in the second commit. [1/2]: rev-parse: correctly diagnose revision errors before "--" [2/2]: rev-parse: diagnose ambiguous revision/filename arguments -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] rev-parse: correctly diagnose revision errors before "--"
Rev-parse understands that a "--" may separate revisions and
filenames, and that anything after the "--" is taken as-is.
However, it does not understand that anything before the
token must be a revision (which is the usual rule
implemented by the setup_revisions parser).
Since rev-parse prefers revisions to files when parsing
before the "--", we end up with the correct result (if such
an argument is a revision, we parse it as one, and if it is
not, it is an error either way). However, we misdiagnose
the errors:
$ git rev-parse foobar -- >/dev/null
fatal: ambiguous argument 'foobar': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
$ >foobar
$ git rev-parse foobar -- >/dev/null
fatal: bad flag '--' used after filename
In both cases, we should know that the real error is that
"foobar" is meant to be a revision, but could not be
resolved.
Signed-off-by: Jeff King
---
builtin/rev-parse.c| 10 ++
t/t1506-rev-parse-diagnosis.sh | 24
2 files changed, 34 insertions(+)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 1d9ecaf..bb694ab 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -488,6 +488,7 @@ N_("git rev-parse --parseopt [options] -- [...]\n"
int cmd_rev_parse(int argc, const char **argv, const char *prefix)
{
int i, as_is = 0, verify = 0, quiet = 0, revs_count = 0, type = 0;
+ int has_dashdash = 0;
int output_prefix = 0;
unsigned char sha1[20];
const char *name = NULL;
@@ -501,6 +502,13 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
if (argc > 1 && !strcmp("-h", argv[1]))
usage(builtin_rev_parse_usage);
+ for (i = 1; i < argc; i++) {
+ if (!strcmp(argv[i], "--")) {
+ has_dashdash = 1;
+ break;
+ }
+ }
+
prefix = setup_git_directory();
git_config(git_default_config, NULL);
for (i = 1; i < argc; i++) {
@@ -788,6 +796,8 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
}
if (verify)
die_no_single_rev(quiet);
+ if (has_dashdash)
+ die("bad revision '%s'", arg);
as_is = 1;
if (!show_file(arg, output_prefix))
continue;
diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
index f950c10..613d9bf 100755
--- a/t/t1506-rev-parse-diagnosis.sh
+++ b/t/t1506-rev-parse-diagnosis.sh
@@ -196,4 +196,28 @@ test_expect_success 'dotdot is not an empty set' '
test_cmp expect actual
'
+test_expect_success 'arg before dashdash must be a revision (missing)' '
+ test_must_fail git rev-parse foobar -- 2>stderr &&
+ test_i18ngrep "bad revision" stderr
+'
+
+test_expect_success 'arg before dashdash must be a revision (file)' '
+ >foobar &&
+ test_must_fail git rev-parse foobar -- 2>stderr &&
+ test_i18ngrep "bad revision" stderr
+'
+
+test_expect_success 'arg before dashdash must be a revision (ambiguous)' '
+ >foobar &&
+ git update-ref refs/heads/foobar HEAD &&
+ {
+ # we do not want to use rev-parse here, because
+ # we are testing it
+ cat .git/refs/heads/foobar &&
+ printf "%s\n" --
+ } >expect &&
+ git rev-parse foobar -- >actual &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.5.524.g6743da6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] rev-parse: diagnose ambiguous revision/filename arguments
If you have both a file and a branch named "foo", running:
git log foo
will complain. We should do the same in rev-parse, and
demand that it be disambiguated with:
git rev-parse foo --
or
git rev-parse -- foo
Signed-off-by: Jeff King
---
Hmm, looking at this again, I guess we need to give the same treatment
to the try_difference code path above, as "foo..bar" can be ambiguous
with a filename (and "git log" seems to diagnose that).
builtin/rev-parse.c| 5 -
t/t1506-rev-parse-diagnosis.sh | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index bb694ab..3ff4f8a 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -790,8 +790,11 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
if (!get_sha1(name, sha1)) {
if (verify)
revs_count++;
- else
+ else {
show_rev(type, sha1, name);
+ if (!has_dashdash)
+ verify_non_filename(prefix, arg);
+ }
continue;
}
if (verify)
diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
index 613d9bf..7ccbcf4 100755
--- a/t/t1506-rev-parse-diagnosis.sh
+++ b/t/t1506-rev-parse-diagnosis.sh
@@ -220,4 +220,11 @@ test_expect_success 'arg before dashdash must be a
revision (ambiguous)' '
test_cmp expect actual
'
+test_expect_success 'ambiguous arg without dashdash' '
+ >foobar &&
+ git update-ref refs/heads/foobar HEAD &&
+ test_must_fail git rev-parse foobar 2>stderr &&
+ test_i18ngrep ambiguous stderr
+'
+
test_done
--
1.8.5.524.g6743da6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:Answer back
I would like to discuss a very important crude oil project with you,kindly revert back to me if this is your valid email address for further information. Regards, Lee -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] difftool: Change prompt to display the number of files in the diff queue
Zoltan Klinger writes: > Reworked patch to use run_command_v_opt_cd_env() function when invoking > the external diff program. Modified test script to use write_script > helper function. Thanks; will queue with a minor tweak. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] rev-parse and "--"
On Fri, Dec 06, 2013 at 04:15:09PM -0500, Jeff King wrote: > If you have both a file and a branch named "foo", running: > > git log foo > > will complain. We should do the same in rev-parse, and > demand that it be disambiguated with: > > git rev-parse foo -- > > or > > git rev-parse -- foo > > Signed-off-by: Jeff King > --- > Hmm, looking at this again, I guess we need to give the same treatment > to the try_difference code path above, as "foo..bar" can be ambiguous > with a filename (and "git log" seems to diagnose that). Here's a revised series which handles that: [1/3]: rev-parse: correctly diagnose revision errors before "--" [2/3]: rev-parse: be more careful with munging arguments [3/3]: rev-parse: diagnose ambiguous revision/filename arguments While fixing this commit, I noticed another bug whose fix is a prerequisite. That's now patch 2 in the series. I think the first two patches are correct and should be applied. Patch 3 is the revised version of this patch which notices ambiguity. However, I'm having second thoughts on it. I think it's the right thing to do if you want to help people build something like "git log" themselves. But it does mean that we are breaking somebody who does: echo foo >HEAD commit=$(git rev-parse HEAD) I'm tempted to say that people who did that are stupid and wrong (and ugly, too). They should probably be using "--verify" in this case. But it has been that way for a long time, and there are two instances in our test scripts that are broken by the patch. Is it better for "rev-parse" to be more careful, and to behave more like the rest of git? Or is better to be historically compatible? One thing to note is that "git rev-parse HEAD" is slightly broken there already. Because "git rev-parse $some_branch" may do very different things than what the caller expects if $some_branch does not exist (but there is a file with the same name). So maybe we are doing a favor by calling out the problem; if they want a rev, they should be using "--verify" (or "--"). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] rev-parse: correctly diagnose revision errors before "--"
Rev-parse understands that a "--" may separate revisions and
filenames, and that anything after the "--" is taken as-is.
However, it does not understand that anything before the
token must be a revision (which is the usual rule
implemented by the setup_revisions parser).
Since rev-parse prefers revisions to files when parsing
before the "--", we end up with the correct result (if such
an argument is a revision, we parse it as one, and if it is
not, it is an error either way). However, we misdiagnose
the errors:
$ git rev-parse foobar -- >/dev/null
fatal: ambiguous argument 'foobar': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
$ >foobar
$ git rev-parse foobar -- >/dev/null
fatal: bad flag '--' used after filename
In both cases, we should know that the real error is that
"foobar" is meant to be a revision, but could not be
resolved.
Signed-off-by: Jeff King
---
builtin/rev-parse.c| 10 ++
t/t1506-rev-parse-diagnosis.sh | 24
2 files changed, 34 insertions(+)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index 1d9ecaf..bb694ab 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -488,6 +488,7 @@ N_("git rev-parse --parseopt [options] -- [...]\n"
int cmd_rev_parse(int argc, const char **argv, const char *prefix)
{
int i, as_is = 0, verify = 0, quiet = 0, revs_count = 0, type = 0;
+ int has_dashdash = 0;
int output_prefix = 0;
unsigned char sha1[20];
const char *name = NULL;
@@ -501,6 +502,13 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
if (argc > 1 && !strcmp("-h", argv[1]))
usage(builtin_rev_parse_usage);
+ for (i = 1; i < argc; i++) {
+ if (!strcmp(argv[i], "--")) {
+ has_dashdash = 1;
+ break;
+ }
+ }
+
prefix = setup_git_directory();
git_config(git_default_config, NULL);
for (i = 1; i < argc; i++) {
@@ -788,6 +796,8 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
}
if (verify)
die_no_single_rev(quiet);
+ if (has_dashdash)
+ die("bad revision '%s'", arg);
as_is = 1;
if (!show_file(arg, output_prefix))
continue;
diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
index f950c10..613d9bf 100755
--- a/t/t1506-rev-parse-diagnosis.sh
+++ b/t/t1506-rev-parse-diagnosis.sh
@@ -196,4 +196,28 @@ test_expect_success 'dotdot is not an empty set' '
test_cmp expect actual
'
+test_expect_success 'arg before dashdash must be a revision (missing)' '
+ test_must_fail git rev-parse foobar -- 2>stderr &&
+ test_i18ngrep "bad revision" stderr
+'
+
+test_expect_success 'arg before dashdash must be a revision (file)' '
+ >foobar &&
+ test_must_fail git rev-parse foobar -- 2>stderr &&
+ test_i18ngrep "bad revision" stderr
+'
+
+test_expect_success 'arg before dashdash must be a revision (ambiguous)' '
+ >foobar &&
+ git update-ref refs/heads/foobar HEAD &&
+ {
+ # we do not want to use rev-parse here, because
+ # we are testing it
+ cat .git/refs/heads/foobar &&
+ printf "%s\n" --
+ } >expect &&
+ git rev-parse foobar -- >actual &&
+ test_cmp expect actual
+'
+
test_done
--
1.8.5.524.g6743da6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] rev-parse: be more careful with munging arguments
When rev-parse looks at whether an argument like "foo..bar"
or "foobar^@" is a difference or parent-shorthand, it
internally munges the arguments so that it can pass the
individual rev arguments to get_sha1. However, we do not
consistently un-munge the result.
For cases where we do not match (e.g., "doesnotexist..HEAD"),
we wouuld then want to try to treat the argument as a
filename. try_difference gets this right, and always
unmunges in this case. However, try_parent_shorthand never
unmunges, leading to incorrect error messages, or even
incorrect results:
$ git rev-parse foobar^@
foobar
fatal: ambiguous argument 'foobar': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
$ >foobar
$ git rev-parse foobar^@
foobar
For cases where we do match, neither function unmunges. This
does not currently matter, since we are done with the
argument. However, a future patch will do further
processing, and this prepares for it. In addition, it's
simply a confusing interface for some cases to modify the
const argument, and others not to.
Signed-off-by: Jeff King
---
As an aside, this is one of those places where C's string functions do
gross things with const. We modify a const argument to the function
without any casts or warnings, because the return value from strstr
implicitly drops the const. Time for us all to move to C++ with
templated strstr, right?
builtin/rev-parse.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index bb694ab..a60fcd3 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -286,6 +286,7 @@ static int try_difference(const char *arg)
exclude = n;
}
}
+ *dotdot = '.';
return 1;
}
*dotdot = '.';
@@ -309,8 +310,10 @@ static int try_parent_shorthands(const char *arg)
return 0;
*dotdot = 0;
- if (get_sha1_committish(arg, sha1))
+ if (get_sha1_committish(arg, sha1)) {
+ *dotdot = '^';
return 0;
+ }
if (!parents_only)
show_rev(NORMAL, sha1, arg);
@@ -319,6 +322,7 @@ static int try_parent_shorthands(const char *arg)
show_rev(parents_only ? NORMAL : REVERSED,
parents->item->object.sha1, arg);
+ *dotdot = '^';
return 1;
}
--
1.8.5.524.g6743da6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] rev-parse: diagnose ambiguous revision/filename arguments
If you have both a file and a branch named "foo", running:
git log foo
will complain. We should do the same in rev-parse, and
demand that it be disambiguated with:
git rev-parse foo --
or
git rev-parse -- foo
Signed-off-by: Jeff King
---
builtin/rev-parse.c| 12
t/t1506-rev-parse-diagnosis.sh | 22 ++
2 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index a60fcd3..a3a58bf 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -781,10 +781,11 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
}
/* Not a flag argument */
- if (try_difference(arg))
- continue;
- if (try_parent_shorthands(arg))
+ if (try_difference(arg) || try_parent_shorthands(arg)) {
+ if (!has_dashdash)
+ verify_non_filename(prefix, arg);
continue;
+ }
name = arg;
type = NORMAL;
if (*arg == '^') {
@@ -794,8 +795,11 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
if (!get_sha1(name, sha1)) {
if (verify)
revs_count++;
- else
+ else {
show_rev(type, sha1, name);
+ if (!has_dashdash)
+ verify_non_filename(prefix, arg);
+ }
continue;
}
if (verify)
diff --git a/t/t1506-rev-parse-diagnosis.sh b/t/t1506-rev-parse-diagnosis.sh
index 613d9bf..dc1f1dc 100755
--- a/t/t1506-rev-parse-diagnosis.sh
+++ b/t/t1506-rev-parse-diagnosis.sh
@@ -220,4 +220,26 @@ test_expect_success 'arg before dashdash must be a
revision (ambiguous)' '
test_cmp expect actual
'
+test_expect_success 'ambiguous arg without dashdash (normal)' '
+ >foobar &&
+ git update-ref refs/heads/foobar HEAD &&
+ test_must_fail git rev-parse foobar 2>stderr &&
+ test_i18ngrep ambiguous stderr
+'
+
+test_expect_success 'ambiguous arg without dashdash (difference)' '
+ >one..two &&
+ git update-ref refs/heads/one HEAD &&
+ git update-ref refs/heads/two HEAD &&
+ test_must_fail git rev-parse one..two 2>stderr &&
+ test_i18ngrep ambiguous stderr
+'
+
+test_expect_success 'ambiguous arg without dashdash (parents)' '
+ >"foobar^@" &&
+ git update-ref refs/heads/foobar HEAD &&
+ test_must_fail git rev-parse foobar^@ 2>stderr &&
+ test_i18ngrep ambiguous stderr
+'
+
test_done
--
1.8.5.524.g6743da6
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] redundant error message
On Fri, Dec 06, 2013 at 08:15:52AM +0700, Duy Nguyen wrote: > On Fri, Dec 6, 2013 at 4:28 AM, Jeff King wrote: > > BTW, the raw looping to find "--" made me wonder how we handle: > > > > git log --grep -- HEAD > > > > I'd expect it to be equivalent to: > > > > git log --grep=-- HEAD > > > > but it's not; we truncate the arguments and complain that --grep is > > missing its argument. Which is probably good enough, given that the > > alternative is doing a pass that understands all of the options. But it > > does mean that the "--long-opt=arg" form is safer than the split form if > > you are passing along an arbitrary "arg". > > Maybe we could make setup_revisions() use parse_options() someday, > which understands about arguments and dashdash. > > $ ./git grep -e -- foo > fatal: ambiguous argument 'foo': both revision and filename > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > $ ./git grep -e -- -- foo Yes, although we use it some in handle_revision_opt, I believe. The problem isn't inherent to parse_options or not, though. To do it correctly, we need to either: 1. make two passes with the code that actually understands the options (be it parse_options or not); the first looking for "--", and the second to do the actual parsing. Right now our first pass does not understand the options at all. 2. store the non-option arguments (including "--"), and only resolve and verify them after we have gone through the whole command-line and know whether we hit a "--" or not. I suspect the second option would be simpler, as neither parse-options nor the current revision code is safe to run through twice (e.g., parse-options may have callbacks that add to a list, and we would need to add some kind of "dry-run" flag). It's something that would be nice to fix, but I don't see myself working on it anytime soon. It's a lot of work for very little benefit. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pack-objects: name pack files after trailer hash
On Thu, Dec 05, 2013 at 02:59:45PM -0800, Junio C Hamano wrote: > > One test needs to be updated, because it actually corrupts a > > pack and expects that re-packing the corrupted bytes will > > use the same name. It won't anymore, but we can easily just > > use the name that pack-objects hands back. > > Re-reading the tests in that script, I am not sure if keeping these > tests is even a sane thing to do, by the way. It "expects" that > certain breakages are propagated, and anybody who breaks that > expectation by improving pack-objects etc. to catch such breakages > will be yelled at by breaking the test that used to pass. I had a similar thought, but I figured I would leave it for the person who _does_ make that change. The yelling will be a good signal that they've got it right, and they can clean up the test (either by dropping it, or modifying it to check the right thing) at that point. > Seeing that the way the test scripts are line-wrapped follows the > ancient convention, I suspect that this may be because it predates > our more recent best practice to document known breakages with > test_expect_failure. I read it more as "make sure that the v1 index breaks, so when we are testing v2 we know it is not an accident that we notice the breakage". But I also see your reason, and I think it would be fine to use test_expect_failure. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git reports
On Fri, Dec 06, 2013 at 11:26:51AM -0800, Jonathan Nieder wrote: > > I am cloning over http > > I am guessing you are using the "dumb" (plain static file transfer) > HTTP protocol. With that protocol the server doesn't do anything > other than shuttle out files, so it doesn't need to do its own > progress reporting. Yeah, that would also explain why GIT_TRACE_PACKET produced no output. > Perhaps the client should do some progress reporting based on file > sizes and amount downloaded so far, but it's hard to get excited > about given the existence of "smart" (transfer only what is needed) > HTTP protocol. See git-http-backend(1) for details. You get some very verbose and nasty progress with "-vv". It would be nice to have a regular throughput meter for dumb-http, though. I haven't bothered adding one so far because I don't expect many people are using http. However, if we start supporting fetching via bundles over http, then it will be very nice to have some kind of progress display there (since the main use is to get gigantic full clones). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/WIP PATCH 3/4] teach add -f option for ignored submodules
Heiko Voigt writes:
> When the user wants to bypass the ignored status configured by
> submodule..ignore=all it is now allowed by using the -f option.
>
> Signed-off-by: Heiko Voigt
> ---
> builtin/add.c | 49 +
> submodule.c | 10 ++
> submodule.h | 1 +
> 3 files changed, 48 insertions(+), 12 deletions(-)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index 2d0d2ef..d6cab7f 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -16,6 +16,7 @@
> #include "revision.h"
> #include "bulk-checkin.h"
> #include "submodule.h"
> +#include "string-list.h"
>
> static const char * const builtin_add_usage[] = {
> N_("git add [options] [--] ..."),
> @@ -37,6 +38,20 @@ struct update_callback_data {
> static const char *option_with_implicit_dot;
> static const char *short_option_with_implicit_dot;
>
> +static struct lock_file lock_file;
> +
> +static const char ignore_error[] =
> +N_("The following paths are ignored by one of your .gitignore files:\n");
> +static const char submodule_ignore_error[] =
> +N_("The following paths are ignored submodules:\n");
> +
> +static int verbose, show_only, ignored_too, refresh_only;
> +static int ignore_add_errors, intent_to_add, ignore_missing;
> +
> +#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */
> +static int addremove = ADDREMOVE_DEFAULT;
> +static int addremove_explicit = -1; /* unspecified */
> +
> static void warn_pathless_add(void)
> {
> static int shown;
> @@ -140,6 +155,9 @@ static void update_callback(struct diff_queue_struct *q,
> warn_pathless_add();
> continue;
> }
> + if (is_ignored_submodule(path) && !ignored_too)
> + continue;
> +
> switch (fix_unmerged_status(p, data)) {
> default:
> die(_("unexpected diff status %c"), p->status);
> @@ -174,6 +192,7 @@ static void update_files_in_cache(const char *prefix,
> struct rev_info rev;
>
> init_revisions(&rev, prefix);
> + enforce_no_complete_ignore_submodule(&rev.diffopt);
> setup_revisions(0, NULL, &rev, NULL);
> if (pathspec)
> copy_pathspec(&rev.prune_data, pathspec);
> @@ -332,18 +351,6 @@ static int edit_patch(int argc, const char **argv, const
> char *prefix)
> return 0;
> }
>
> -static struct lock_file lock_file;
> -
> -static const char ignore_error[] =
> -N_("The following paths are ignored by one of your .gitignore files:\n");
> -
> -static int verbose, show_only, ignored_too, refresh_only;
> -static int ignore_add_errors, intent_to_add, ignore_missing;
> -
> -#define ADDREMOVE_DEFAULT 0 /* Change to 1 in Git 2.0 */
> -static int addremove = ADDREMOVE_DEFAULT;
> -static int addremove_explicit = -1; /* unspecified */
> -
> static int ignore_removal_cb(const struct option *opt, const char *arg, int
> unset)
> {
> /* if we are told to ignore, we are not adding removals */
> @@ -407,6 +414,17 @@ static int add_files(struct dir_struct *dir, int flags)
> return exit_status;
> }
>
> +static void die_ignored_submodules(struct string_list *ignored_submodules)
> +{
> + struct string_list_item *path;
> +
> + fprintf(stderr, _(submodule_ignore_error));
> + for_each_string_list_item(path, ignored_submodules)
> + fprintf(stderr, "%s\n", path->string);
> + fprintf(stderr, _("Use -f if you really want to add them.\n"));
> + die(_("no files added"));
> +}
> +
> int cmd_add(int argc, const char **argv, const char *prefix)
> {
> int exit_status = 0;
> @@ -419,6 +437,7 @@ int cmd_add(int argc, const char **argv, const char
> *prefix)
> char *seen = NULL;
> int implicit_dot = 0;
> struct update_callback_data update_data;
> + struct string_list ignored_submodules = STRING_LIST_INIT_NODUP;
>
> gitmodules_config();
> git_config(add_config, NULL);
> @@ -550,6 +569,7 @@ int cmd_add(int argc, const char **argv, const char
> *prefix)
>
> for (i = 0; i < pathspec.nr; i++) {
> const char *path = pathspec.items[i].match;
> + char path_copy[PATH_MAX];
> if (!seen[i] &&
> ((pathspec.items[i].magic &
> (PATHSPEC_GLOB | PATHSPEC_ICASE)) ||
> @@ -562,6 +582,9 @@ int cmd_add(int argc, const char **argv, const char
> *prefix)
> die(_("pathspec '%s' did not match any
> files"),
> pathspec.items[i].original);
> }
> + normalize_path_copy(path_copy, path);
> + if (is_ignored_submodule(path_copy))
> + string_list_insert(&ignored_submodules, path);
> }
> free(seen);
> }
> @@ -583,6 +606,8 @@ int cmd_add(int argc, const char **argv, const
Re: [PATCH v2 0/3] rev-parse and "--"
Jeff King wrote: > Patch 3 is the revised version of this patch which notices ambiguity. > However, I'm having second thoughts on it. I think it's the right thing > to do if you want to help people build something like "git log" > themselves. But it does mean that we are breaking somebody who does: > > echo foo >HEAD > commit=$(git rev-parse HEAD) > > I'm tempted to say that people who did that are stupid and wrong (and > ugly, too). They should probably be using "--verify" in this case. But > it has been that way for a long time, and there are two instances in our > test scripts that are broken by the patch. Wouldn't the same thing happen for $(git rev-parse HEAD^..HEAD) when there is a 'HEAD^..HEAD' file, too? --verify doesn't support that. I think it's a nice idea to provide this functionality for people who need it, which would mean protected by an option (--check-ambiguity or something). I don't think it's a good change to do it unconditionally. My two cents, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] rev-parse and "--"
On Fri, Dec 06, 2013 at 03:25:56PM -0800, Jonathan Nieder wrote: > > commit=$(git rev-parse HEAD) > > > > I'm tempted to say that people who did that are stupid and wrong (and > > ugly, too). They should probably be using "--verify" in this case. But > > it has been that way for a long time, and there are two instances in our > > test scripts that are broken by the patch. > > Wouldn't the same thing happen for $(git rev-parse HEAD^..HEAD) when > there is a 'HEAD^..HEAD' file, too? --verify doesn't support that. True, but they can use "rev-parse HEAD^..HEAD --", which is probably a better alternative to --verify. > I think it's a nice idea to provide this functionality for people who > need it, which would mean protected by an option (--check-ambiguity or > something). I don't think it's a good change to do it > unconditionally. I don't think it's worth making it conditional. Literally nobody has asked for it. I was mostly trying to harmonize "rev-parse" and the rest of the revision parser. If that's not worth doing, I'd just as soon drop it (and people using "--" properly already get the right behavior). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] rev-parse: correctly diagnose revision errors before "--"
Jeff King wrote:
> Since rev-parse prefers revisions to files when parsing
> before the "--", we end up with the correct result (if such
> an argument is a revision, we parse it as one, and if it is
> not, it is an error either way). However, we misdiagnose
> the errors:
>
> $ git rev-parse foobar -- >/dev/null
> fatal: ambiguous argument 'foobar': unknown revision or path not in the
> working tree.
> Use '--' to separate paths from revisions, like this:
> 'git [...] -- [...]'
>
> $ >foobar
> $ git rev-parse foobar -- >/dev/null
> fatal: bad flag '--' used after filename
>
> In both cases, we should know that the real error is that
> "foobar" is meant to be a revision, but could not be
> resolved.
Neat.
[...]
> --- a/builtin/rev-parse.c
> +++ b/builtin/rev-parse.c
> @@ -488,6 +488,7 @@ N_("git rev-parse --parseopt [options] -- [...]\n"
> int cmd_rev_parse(int argc, const char **argv, const char *prefix)
> {
> int i, as_is = 0, verify = 0, quiet = 0, revs_count = 0, type = 0;
> + int has_dashdash = 0;
> int output_prefix = 0;
> unsigned char sha1[20];
> const char *name = NULL;
> @@ -501,6 +502,13 @@ int cmd_rev_parse(int argc, const char **argv, const
> char *prefix)
> if (argc > 1 && !strcmp("-h", argv[1]))
> usage(builtin_rev_parse_usage);
>
> + for (i = 1; i < argc; i++) {
> + if (!strcmp(argv[i], "--")) {
> + has_dashdash = 1;
> + break;
> + }
> + }
> +
> prefix = setup_git_directory();
> git_config(git_default_config, NULL);
> for (i = 1; i < argc; i++) {
> @@ -788,6 +796,8 @@ int cmd_rev_parse(int argc, const char **argv, const char
> *prefix)
> }
> if (verify)
> die_no_single_rev(quiet);
> + if (has_dashdash)
> + die("bad revision '%s'", arg);
> as_is = 1;
Yep, this is the "fall back to looking for a file" part of rev-parse,
so erroring out if there as a dashdash coming is the right thing to
do. And a quick code search for "rev-parse.*\ --\ " reveals that
most callers would simply not be affected by this.
Thanks for a pleasant patch.
For what it's worth,
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Dec 2013, #02; Fri, 6)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of 'next' has been rewound, ejecting a few topics that used to be there. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * jn/git-gui-chmod+x (2013-11-25) 1 commit - git-gui: chmod +x po2msg, windows/git-gui.sh Parked here until I get the same change back from the upstream git-gui tree. * jn/gitk-chmod+x (2013-11-25) 1 commit - gitk: chmod +x po2msg Parked here until I get the same change back from the upstream gitk tree. * jk/name-pack-after-byte-representation (2013-12-05) 2 commits - pack-objects: name pack files after trailer hash - sha1write: make buffer const-correct (this branch is tangled with jk/pack-bitmap.) * nd/negative-pathspec (2013-12-06) 3 commits - pathspec.c: support adding prefix magic to a pathspec with mnemonic magic - Support pathspec magic :(exclude) and its short form :! - glossary-content.txt: rephrase magic signature part * nd/transport-positive-depth-only (2013-12-06) 1 commit - clone,fetch: catch non positive --depth option value * zk/difftool-counts (2013-12-06) 1 commit - difftool: display the number of files in the diff queue in the prompt -- [Graduated to "master"] * ak/submodule-foreach-quoting (2013-09-27) 1 commit (merged to 'next' on 2013-10-14 at d77c5f1) + submodule foreach: skip eval for more than one argument A behavior change, but maybe a worthwhile one: "git submodule foreach" was treating its arguments as part of a single command to be concatenated and passed to a shell, making writing buggy scripts too easy. This patch preserves the old "just pass it to the shell" behavior when a single argument is passed to 'git submodule foreach' and moves to a new "skip the shell and use the arguments passed unmolested" behavior when more than one argument is passed. The old behavior (always concatenating and passing to the shell) was similar to the 'ssh' command, while the new behavior (switching on the number of arguments) is what 'xterm -e' does. May need more thought to make sure this change is advertised well; scripts that used multiple arguments but added their own extra layer of quoting are broken, and the users need to adjust them. * bc/http-100-continue (2013-10-31) 3 commits (merged to 'next' on 2013-11-01 at e12ae23) + remote-curl: fix large pushes with GSSAPI + remote-curl: pass curl slot_results back through run_slot + http: return curl's AUTHAVAIL via slot_results Issue "100 Continue" responses to help use of GSS-Negotiate authentication scheme over HTTP transport when needed. * jc/bundle (2013-11-12) 1 commit (merged to 'next' on 2013-11-21 at 535b046) + bundle: use argv-array Code clean-up. * jc/merge-base-reflog (2013-10-29) 2 commits (merged to 'next' on 2013-11-01 at 6114764) + merge-base: teach "--fork-point" mode + merge-base: use OPT_CMDMODE and clarify the command line parsing Code the logic in "pull --rebase" that figures out a fork point from reflog entries in C. * jc/ref-excludes (2013-11-01) 5 commits (merged to 'next' on 2013-11-04 at fac1ed0) + rev-parse: introduce --exclude= to tame wildcards + rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API + rev-list --exclude: tests + document --exclude option + revision: introduce --exclude= to tame wildcards People often wished a way to tell "git log --branches" (and "git log --remotes --not --branches") to exclude some local branches from the expansion of "--branches" (similarly for "--tags", "--all" and "--glob="). Now they have one. * jh/loose-object-dirs-creation-race (2013-10-28) 1 commit (merged to 'next' on 2013-11-01 at 3169b0f) + sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs Two processes creating loose objects at the same time could have failed unnecessarily when they happened to have created objects whose names share the same first byte. * jk/remove-experimental-loose-object-support (2013-11-21) 1 commit (merged to 'next' on 2013-11-21 at d37bab7) + drop support for "experimental" loose objects Read-only support for experimental loose-object format, in which users could optionally choose to write in their loose objects for a short while between v1.4.3 to v1.5.3 era, has been dropped. * jk/replace-perl-in-built-scripts (2013-10-29) 1 commit (merged to 'next' on 2013-11-01 at 2384e29) + use @@PERL@@ in built scripts * jk/robustify-parse-commit (2013-10-24) 6 commits (merged to 'next' on 2013-11-01 at 2bfbaab) + checkout: do not die when leaving broken detached HEAD + use parse_commit_or_die instead of custom message + use parse_commit_or_die instea
Re: [PATCH v2 2/3] rev-parse: be more careful with munging arguments
Jeff King wrote:
> As an aside, this is one of those places where C's string functions do
> gross things with const.
Yes, yuck.
The fundamental grossness is that argv is semantically char **
(assuming this doesn't segfault) but passed around as const char **.
I wonder why we don't use the same trick in git_extract_argv0_path and
when handling STRIP_EXTENSION in git.c.
Alternatively, try_difference could create a new buffer for its own
use. Originally (v0.99~273, 2005-06-13) this dotdot handling code was
pretty simple:
for (i = 1; i < argc; i++) {
char *arg = argv[i];
...
dotdot = strstr(arg, "..");
if (dotdot) {
unsigned char end[20];
char *n = dotdot+2;
*dotdot = 0;
if (!get_sha1(arg, sha1)) {
if (!*n)
n = "HEAD";
if (!get_sha1(n, end)) {
printf("%s\n", sha1_to_hex(end));
printf("^%s\n", sha1_to_hex(sha1));
continue;
}
}
*dotdot = '.';
}
printf("%s\n", arg);
}
The 'continue' without making the argument right again was justified
because we were done with the argument.
Now it is still not much more complicated --- the function is
logically just trying to parse the argument into a "this" and "next"
part and print them.
Something like the following (untested). Or if the allocation churn
is too much, it could use a static strbuf.
diff --git i/builtin/rev-parse.c w/builtin/rev-parse.c
index c76b89d..98262b3 100644
--- i/builtin/rev-parse.c
+++ w/builtin/rev-parse.c
@@ -234,37 +234,35 @@ static int try_difference(const char *arg)
unsigned char sha1[20];
unsigned char end[20];
const char *next;
- const char *this;
+ struct strbuf this = STRBUF_INIT;
int symmetric;
- static const char head_by_default[] = "HEAD";
if (!(dotdot = strstr(arg, "..")))
return 0;
next = dotdot + 2;
- this = arg;
symmetric = (*next == '.');
-
- *dotdot = 0;
next += symmetric;
- if (!*next)
- next = head_by_default;
- if (dotdot == arg)
- this = head_by_default;
-
- if (this == head_by_default && next == head_by_default &&
- !symmetric) {
+ if (!*next && dotdot == arg && !symmetric)
/*
* Just ".."? That is not a range but the
* pathspec for the parent directory.
*/
- *dotdot = '.';
return 0;
+
+ strbuf_add(&this, arg, dotdot - arg);
+
+ if (!*next)
+ next = "HEAD";
+ if (dotdot == arg) {
+ strbuf_reset(&this);
+ strbuf_addstr(&this, "HEAD");
}
- if (!get_sha1_committish(this, sha1) && !get_sha1_committish(next,
end)) {
+ if (!get_sha1_committish(this.buf, sha1)
+ && !get_sha1_committish(next, end)) {
show_rev(NORMAL, end, next);
- show_rev(symmetric ? NORMAL : REVERSED, sha1, this);
+ show_rev(symmetric ? NORMAL : REVERSED, sha1, this.buf);
if (symmetric) {
struct commit_list *exclude;
struct commit *a, *b;
@@ -279,9 +277,10 @@ static int try_difference(const char *arg)
exclude = n;
}
}
+ strbuf_release(&this);
return 1;
}
- *dotdot = '.';
+ strbuf_release(&this);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitignore excludes not working?
2013/12/7 Martin Langhoff : > Tested with git 1.7.12.4 (Apple Git-37) and git 1.8.3.1 on F20. > > $ mkdir foo > $ cd foo > $ git init > Initialized empty Git repository in /tmp/foo/.git/ > $ mkdir -p modules/boring > $ mkdir -p modules/interesting > $ touch modules/boring/lib.c > $ touch modules/interesting/other.c > $ touch modules/interesting/lib.c > $ git add modules/interesting/lib.c > $ git status > # On branch master > # > # Initial commit > # > # Changes to be committed: > # (use "git rm --cached ..." to unstage) > # > # new file: modules/interesting/lib.c > # > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # modules/boring/ > # modules/interesting/other.c > > $ echo '/modules/' > .gitignore > $ echo '!/modules/interesting/' >> .gitignore > I happened to write a software "Gistore" to backup arbitrary files and directories using Git, and it will save interesting things in .git/info/exclude. For your case, you could write .gitignore as: /modules/* !/modules/interesting !/modules/interesting/** You can find my code in Gistore to generate proper .gitignore here: https://github.com/jiangxin/gistore/blob/master/lib/gistore/repo.rb#L228 Because I will ignore all files except what I want, the ignore file would be: * !/modules !/modules/interesting !/modules/interesting/** -- Jiang Xin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] diff: Add diff.orderfile configuration variable
On Fri, Dec 6, 2013 at 1:11 PM, Junio C Hamano wrote: > Samuel Bronson writes: > Thanks for reviving a stalled topic. I was asking about such a feature in #git and jrnieder was nice enough to point me at the stalled patch. >> *I* even verified that the tests do fail properly when the feature is >> sabotaged. > > Sabotaged in what way? I commented out the "options->orderfile = diff_order_file_cfg;" line. >> @@ -432,6 +432,8 @@ endif::git-format-patch[] >> -O:: >> Output the patch in the order specified in the >> , which has one shell glob pattern per line. >> + This overrides the `diff.orderfile' configuration variable >> + ((see linkgit:git-config[1]). > > Double opening parenthesis? Oops, and it looks like I messed up the quoting on diff.orderfile too ... > If somebody has diff.orderfile configuration that points at a custom > ordering, and wants to send out a patch (or show a diff) with the > standard order, how would the "overriding" command line look like? > Would it be "git diff -O/dev/null"? It looks like that works ... and so do files that don't exist. What do you think should happen with -O file-that-does-not-exist, and how do you suppose it should be tested? After having fixed this, will /dev/null still work everywhere, or will we want a new diff flag to unset the option? (I see that "git diff /dev/null some-file" works fine with msysgit, which doesn't seem to actually be linked with MSYS, but I don't know *why* it works, and I don't know what other non-POSIXoid ports exist.) For the moment, I've added this to "for" loop (after some changes based on some of your other suggestions): # I don't think this should just pretend the orderfile was empty? test_expect_failure "override with bogus orderfile ($i)" ' test_might_fail git -c diff.orderfile=order_file_$i diff -Obogus_file --name-only HEAD^..HEAD >actual_diff_filenames && ! test_cmp expect_diff_filenames_none actual_diff_filenames ' Does this look (modulo gmail's stupid indentation) anything like a reasonable approach to testing that? (Of course, you can't actually test it because it depends on other changes I haven't posted yet ...) Also, I'm starting to wonder if I shouldn't split this into two patches: 1. diff: Add tests for -O flag 2. diff: Add diff.orderfile configuration variable (If so, I would obviously want to rewrite the above test to avoid the configuration option.) >> + return $? >> +} > > That return looks somewhat strange. Does it even need to be there? I'm certainly no great expert at shell functions, so I expect it isn't. I'm not really sure what possessed me to think it might be needed. > EOF > cat >order_file_2 <<-\EOF && I'd kind of prefer to keep a blank line between one EOF and the next cat, if that's okay with you. > > Quoting the EOF like the above will help the readers by signaling > them that they do not have to wonder if there is some substitution > going on in the here text. Perhaps, but probably only after they've scrutinized their shell manuals to figure out what the - and the \ are for. (I had to check two: dash(1) wasn't clear enough for me about the quoting ...) >> +test_expect_success "no order (=tree object order)" ' >> + git diff HEAD^..HEAD >patch && >> + grep ^diff patch >actual_diff_headers && >> + test_cmp expect_diff_headers_none actual_diff_headers >> +' > > Instead of grepping, "git diff --name-only" would be far easier to > check, no? It certainly makes for less-cluttered expected output. (I guess jrnieder didn't know about that trick when he suggested using the intermediate file?) > Points to note: > > * We eval the scriptlets inside test framework, so using $i as a >variable inside the single quotes will have the expected result. >You do not have to worry about extra quoting inside dq pair. Hmm. I'm obviously not used to things getting eval'd in the same shell instance as my script ... (Thanks for the review!) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitignore excludes not working?
On Sat, Dec 7, 2013 at 12:26 AM, Martin Langhoff wrote: > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > # modules/boring/ > # modules/interesting/other.c > > $ echo '/modules/' > .gitignore > $ echo '!/modules/interesting/' >> .gitignore Once you ignore the directory "modules", it won't bother with anything inside. As a result, !/modules/interesting/ is ignored. Turning the first rule to /modules/* like Jiang Xin showed does the trick because git is told to ignore entries inside 'modules', not 'modules' itself. I think the best we could do is turning /modules/ into /modules/* internally. But it only works for simple cases like yours. If you write /mo*ules/, I don't think we can make git smart enough to correlate /mo*ules/ to !/modules/interesting/. So the second best thing is improve documents about this case, which is what kb/doc-exclude-directory-semantics does (currently on 'next'). -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] parse-options: remove OPT_BOOLEAN
After a86a8b9 (sb/parseopt-boolean-removal), the deprecated
OPT_BOOLEAN is not used anywhere except by OPT__* macros. Kill
OPT_BOOLEAN and make OPT__* use OPT_COUNTUP directly instead. This
should stop OPT_BOOLEAN from entering the tree again in new patches.
OPT__DRY_RUN() is converted to use OPT_BOOL though because it does not
make sense to increase the level of dryness. All OPT__DRY_RUN call
sites have been checked and they look safe for OPT_BOOL.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
parse-options.h | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/parse-options.h b/parse-options.h
index 8736006..d670cb9 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -161,9 +161,6 @@ struct option {
N_("no-op (backward compatibility)"), \
PARSE_OPT_HIDDEN | PARSE_OPT_NOARG, parse_opt_noop_cb }
-/* Deprecated synonym */
-#define OPT_BOOLEAN OPT_COUNTUP
-
/* parse_options() will filter out the processed options and leave the
* non-option arguments in argv[]. usagestr strings should be marked
* for translation with N_().
@@ -232,15 +229,15 @@ extern int parse_opt_tertiary(const struct option *,
const char *, int);
extern int parse_opt_string_list(const struct option *, const char *, int);
extern int parse_opt_noop_cb(const struct option *, const char *, int);
-#define OPT__VERBOSE(var, h) OPT_BOOLEAN('v', "verbose", (var), (h))
-#define OPT__QUIET(var, h)OPT_BOOLEAN('q', "quiet", (var), (h))
+#define OPT__VERBOSE(var, h) OPT_COUNTUP('v', "verbose", (var), (h))
+#define OPT__QUIET(var, h)OPT_COUNTUP('q', "quiet", (var), (h))
#define OPT__VERBOSITY(var) \
{ OPTION_CALLBACK, 'v', "verbose", (var), NULL, N_("be more verbose"), \
PARSE_OPT_NOARG, &parse_opt_verbosity_cb, 0 }, \
{ OPTION_CALLBACK, 'q', "quiet", (var), NULL, N_("be more quiet"), \
PARSE_OPT_NOARG, &parse_opt_verbosity_cb, 0 }
-#define OPT__DRY_RUN(var, h) OPT_BOOLEAN('n', "dry-run", (var), (h))
-#define OPT__FORCE(var, h)OPT_BOOLEAN('f', "force", (var), (h))
+#define OPT__DRY_RUN(var, h) OPT_BOOL('n', "dry-run", (var), (h))
+#define OPT__FORCE(var, h)OPT_COUNTUP('f', "force", (var), (h))
#define OPT__ABBREV(var) \
{ OPTION_CALLBACK, 0, "abbrev", (var), N_("n"), \
N_("use digits to display SHA-1s"), \
--
1.8.5.1.77.g42c48fa
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
