* [PATCH] Wait help.autocorrect deciseconds before running corrected command
From: Alex Riesen @ 2008-07-23 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vsku1jz4u.fsf@gitster.siamese.dyndns.org>
Suggested by Junio, so he has a chance to hit Ctrl-C.
---
Junio C Hamano, Wed, Jul 23, 2008 01:08:17 +0200:
>
> Please make autocorrect not a binary but optionally the number of
> deciseconds before it continues, so that I have a chance to hit ^C ;-)
on top of the last patch.
Documentation/config.txt | 9 +++++++++
help.c | 7 ++++++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..5bf1d0d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -771,6 +771,15 @@ help.format::
Values 'man', 'info', 'web' and 'html' are supported. 'man' is
the default. 'web' and 'html' are the same.
+help.autocorrect::
+ Automatically correct and execute mistyped commands after
+ waiting for the given number of deciseconds (0.1 sec). If more
+ than one command can be deduced from the entered text, nothing
+ will be executed. If the value of this option is negative,
+ the corrected command will be executed immediately. If the
+ value is 0 - the command will be just shown but not executed.
+ This is the default.
+
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
environment variable (see linkgit:curl[1]). This can be overridden
diff --git a/help.c b/help.c
index 8b25a55..4d52781 100644
--- a/help.c
+++ b/help.c
@@ -271,7 +271,7 @@ static int git_help_config(const char *var, const char *value, void *cb)
if (!prefixcmp(var, "man."))
return add_man_viewer_info(var, value);
if (!strcmp(var, "help.autocorrect"))
- autocorrect = git_config_bool(var,value);
+ autocorrect = git_config_int(var,value);
return git_default_config(var, value, cb);
}
@@ -722,6 +722,11 @@ const char *help_unknown_cmd(const char *cmd)
"which does not exist.\n"
"Continuing under the assumption that you meant '%s'\n",
cmd, main_cmds.names[0]->name);
+ if (autocorrect > 0) {
+ fprintf(stderr, "in %0.1f seconds automatically...\n",
+ (float)autocorrect/10.0);
+ poll(NULL, 0, autocorrect * 100);
+ }
return main_cmds.names[0]->name;
}
--
1.6.0.rc0.50.g9c23
^ permalink raw reply related
* Re: [PATCH] perl/Makefile: update NO_PERL_MAKEMAKER section
From: Brandon Casey @ 2008-07-23 16:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20080722230940.GK32184@machine.or.cz>
Petr Baudis wrote:
> On Tue, Jul 22, 2008 at 04:15:41PM -0500, Brandon Casey wrote:
>> The perl modules must be copied to blib/lib so they are available for
>> testing.
>>
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>
> I don't understand why do you need to do this; perl.mak should do this
> on its own during project-wide make all.
perl.mak is auto-generated by one of two methods in perl/Makefile. This
patch modifies the 'NO_PERL_MAKEMAKER' section. Currently 'make all', when
NO_PERL_MAKEMAKER is set, does nothing, and looks like:
$ cat perl.mak
all:
:
install:
mkdir -p ...
With this patch it looks like:
$ cat perl.mak
all: private-Error.pm Git.pm
mkdir -p blib/lib
rm -f blib/lib/Git.pm; cp Git.pm blib/lib/
rm -f blib/lib/Error.pm; cp private-Error.pm blib/lib/Error.pm
install:
mkdir -p ...
-brandon
^ permalink raw reply
* [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Alex Riesen @ 2008-07-22 22:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807222242160.8986@racer>
It is off by default, to avoid scaring people unless they asked to.
---
Johannes Schindelin, Tue, Jul 22, 2008 23:44:50 +0200:
> On Tue, 22 Jul 2008, Alex Riesen wrote:
>
> > @@ -704,9 +707,10 @@ const char *help_unknown_cmd(const char *cmd)
> >
> > if (!main_cmds.cnt)
> > die ("Uh oh. Your system reports no Git commands at all.");
> > + git_config(git_help_config, NULL);
> > best_similarity = similarity(main_cmds.names[0]->name);
> > - if (main_cmds.cnt < 2 || best_similarity <
> > - similarity(main_cmds.names[1]->name)) {
> > + if (autocorrect && (main_cmds.cnt < 2 ||
> > + best_similarity < similarity(main_cmds.names[1]->name))) {
> > if (!*cwd)
> > exit(1);
> > if (chdir(cwd))
>
> This "if" already checks if there is only one candidate. So you should
> just add an inner "if (autocorrect) ... else single = 1;" or some such.
Oh right, stupid me.
> However, I think that the intention of this patch is too much DWIMery,
> which might be good for me (just like my "git add remote" patch), but not
> for the general audience.
Mustn't be good for all (for the "general audience" it is even common
practice to forget to thank. It may be even a sign of bad manners for
it). It is good for me though. And thanks for sharing.
Moved git_config before the calls where current directory is changed:
so that it has the same filesystem context as in normal case. Less
surprises.
help.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/help.c b/help.c
index 480befe..8b25a55 100644
--- a/help.c
+++ b/help.c
@@ -28,6 +28,7 @@ enum help_format {
HELP_FORMAT_WEB,
};
+static int autocorrect;
static int show_all = 0;
static enum help_format help_format = HELP_FORMAT_MAN;
static struct option builtin_help_options[] = {
@@ -269,6 +270,8 @@ static int git_help_config(const char *var, const char *value, void *cb)
}
if (!prefixcmp(var, "man."))
return add_man_viewer_info(var, value);
+ if (!strcmp(var, "help.autocorrect"))
+ autocorrect = git_config_bool(var,value);
return git_default_config(var, value, cb);
}
@@ -683,7 +686,7 @@ static int levenshtein_compare(const void *p1, const void *p2)
const char *help_unknown_cmd(const char *cmd)
{
- int i, best_similarity = 0;
+ int i, best_similarity = 0, n;
char cwd[PATH_MAX];
if (!getcwd(cwd, sizeof(cwd))) {
@@ -691,6 +694,7 @@ const char *help_unknown_cmd(const char *cmd)
cwd[0] = '\0';
}
+ git_config(git_help_config, NULL);
load_command_list();
ALLOC_GROW(main_cmds.names, main_cmds.cnt + other_cmds.cnt,
main_cmds.alloc);
@@ -705,8 +709,11 @@ const char *help_unknown_cmd(const char *cmd)
if (!main_cmds.cnt)
die ("Uh oh. Your system reports no Git commands at all.");
best_similarity = similarity(main_cmds.names[0]->name);
- if (main_cmds.cnt < 2 || best_similarity <
- similarity(main_cmds.names[1]->name)) {
+ n = 1;
+ while (n < main_cmds.cnt &&
+ best_similarity == similarity(main_cmds.names[n]->name))
+ ++n;
+ if (autocorrect && n == 1) {
if (!*cwd)
exit(1);
if (chdir(cwd))
@@ -721,10 +728,10 @@ const char *help_unknown_cmd(const char *cmd)
fprintf(stderr, "git: '%s' is not a git-command. See 'git --help'.\n", cmd);
if (best_similarity < 6) {
- fprintf(stderr, "\nDid you mean one of these?\n");
+ fprintf(stderr, "\nDid you mean %s?\n",
+ n < 2 ? "this": "one of these");
- for (i = 0; i < main_cmds.cnt && best_similarity ==
- similarity(main_cmds.names[i]->name); i++)
+ for (i = 0; i < n; i++)
fprintf(stderr, "\t%s\n", main_cmds.names[i]->name);
}
--
1.6.0.rc0.48.ga184
^ permalink raw reply related
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-23 16:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231713280.8986@racer>
On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
>
> > So in short, sparse prefix will be stored in config, core.sparsecheckout.
>
>
> Do you really think the prefix should be stored anywhere else than the
> index?
>
> With core.sparseCheckout you have to introduce a _sh*tload_ of config
> loaders.
>
> And with core.sparseCheckout you are at the whim of the user, since
> .git/config is _supposed_ to be user-editable.
>
> From a logical point of view, I'd say that the sparse prefix has nothing
> to do with the "configuration" of the local repository.
Well, whatever place. I chose .git/config because I did not want to
introduce a new config place. But then how about .git/sparsecheckout?
>
> Ciao,
> Dscho
>
--
Duy
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Avery Pennarun @ 2008-07-23 16:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, git, gitster
In-Reply-To: <alpine.DEB.1.00.0807231708520.8986@racer>
On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 23 Jul 2008, Avery Pennarun wrote:
> > However, taking out the auto-commit wouldn't pain me too much if
> > others want it that way.
>
> IMO the -rc0 cycle is a particularly ill-chosen time to discuss behavior
> changes like this.
Probably, but it relates to the discussion of the current patch.
Would it be better to change the rebase behaviour now and then
possibly again in the next version, or just leave it as-is for now?
Avery
^ permalink raw reply
* git-svn - failed to clone repository
From: Derek Fawcus @ 2008-07-23 16:06 UTC (permalink / raw)
To: git
I tried to create a clone of an svn repository, and it gave
up part way through with the following error:
Incomplete data: Delta source ended unexpectedly at /usr/bin/git-svn line 3858
Looking at the source, this is the call '$reporter->finish-report($pool)'
near the end of gs_do_update.
This is using git 1.5.6 from the etch backports repository.
The repository in question was cocotron, the command being:
git svn clone http://cocotron.googlecode.com/svn -t tags -b branches -T trunk
It seemed to fail at revision 91, the last couple of lines of the command output being:
r90 = <hex I can't be bothered to type unless required> (trunk)
M Foundation/NSStream/NSFileHandle.m
then followed by the above error. Looking at the actual revision
page (http://code.google.com/p/cocotron/source/detail?r=91)
the only thing that stands out as odd is one file claims to be 'too large to diff'.
It's ~900k and if one grabs and diffs by hand, the output is only ~70 lines.
So - is this at all related to the 'known bug' mentioned earlier - stopped on
line 3856 when using line ending mapping (I'm not using such), or is this
something else?
Last, assuming I was to simply grab and apply this changeset by hand,
what would I need to do to fix up metadata so that git-svn could continue
importing the history? There are about 200 changesets in the whole repository.
Thanks,
DF
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-23 16:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145518.GA29035@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 559 bytes --]
Hi,
On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> So in short, sparse prefix will be stored in config, core.sparsecheckout.
Do you really think the prefix should be stored anywhere else than the
index?
With core.sparseCheckout you have to introduce a _sh*tload_ of config
loaders.
And with core.sparseCheckout you are at the whim of the user, since
.git/config is _supposed_ to be user-editable.
>From a logical point of view, I'd say that the sparse prefix has nothing
to do with the "configuration" of the local repository.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Johannes Schindelin @ 2008-07-23 16:09 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Dmitry Potapov, git, gitster
In-Reply-To: <32541b130807230853y136f41bdmf221637e35d601c3@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> However, taking out the auto-commit wouldn't pain me too much if
> others want it that way.
IMO the -rc0 cycle is a particularly ill-chosen time to discuss behavior
changes like this.
Hth,
Dscho
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Johannes Schindelin @ 2008-07-23 16:07 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Alexander Litvinov, git
In-Reply-To: <32541b130807230849t42b491b9jf1d6f31bcdd50dac@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > > > In short: I can't clone svn repo into git when crlf convertion
> > > > > is activated.
> > > >
> > > > This is a known issue, but since nobody with that itch seems to
> > > > care enough to fix it, I doubt it will ever be fixed.
> > >
> > > That is a bad news for me. Anyway I will spend some time at
> > > holidays during digging this bug.
> >
> > Note that you will have to do your digging using msysGit (i.e. the
> > developer's pack, not the installer for plain Git), since git-svn will
> > be removed from the next official "Windows Git" release, due to lack
> > of fixers.
>
> Presumably cygwin git will work too, right?
Yes.
> Does this known issue apply only to msysGit, or both msys and Cygwin, or
> all versions? ie. could it be debugged on Linux?
You mean the crlf vs git-svn issue? No, yes, yes, yes, and yes.
Ciao,
Dscho
^ permalink raw reply
* [FYI PATCH] Added a git search and replace command
From: Sverre Rabbelier @ 2008-07-23 15:36 UTC (permalink / raw)
To: git; +Cc: Sverre Rabbelier
A simple script that uses 'git ls-files' and xargs to
search and replace all the specified files.
---
Not meant for inclusion, just a simple script I wrote up
when I wanted to change a function name in my repository
but didn't want to figure out which magic argument to find
does what I want. Another advantage of using git ls-files
is that it will prevent that any unrevertable changes will
be made (since the script checks if the tree is dirty or
not). I'm sure there's plenty of room for improvement here,
it's probably not portable at all either, so comments are
welcome :).
.gitignore | 1 +
Makefile | 1 +
git-sar.sh | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 63 insertions(+), 0 deletions(-)
create mode 100755 git-sar.sh
diff --git a/.gitignore b/.gitignore
index a213e8e..451cb93 100644
--- a/.gitignore
+++ b/.gitignore
@@ -108,6 +108,7 @@ git-rev-list
git-rev-parse
git-revert
git-rm
+git-sar
git-send-email
git-send-pack
git-sh-setup
diff --git a/Makefile b/Makefile
index b01cf1c..979e9ea 100644
--- a/Makefile
+++ b/Makefile
@@ -252,6 +252,7 @@ SCRIPT_SH += git-sh-setup.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
+SCRIPT_SH += git-sar.sh
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-archimport.perl
diff --git a/git-sar.sh b/git-sar.sh
new file mode 100755
index 0000000..db6317b
--- /dev/null
+++ b/git-sar.sh
@@ -0,0 +1,61 @@
+#!/bin/bash
+
+do_sed () {
+ sed "$2" $3 > $3.replaced
+ mv $3.replaced $3
+}
+
+do_git_find() {
+ # Sanity check
+ if is_dirty_tree
+ then
+ echo "Refusing to work on a dirty tree"
+ fi
+
+ files=`git ls-files "$1"`
+ if test -z "$files"
+ then
+ echo "Your pathspec did not match any files."
+ exit 1
+ fi
+ echo "$files" | xargs -n 1 git-sar --replace $2
+}
+
+is_dirty_tree () {
+ `git diff --quiet`
+ test $? -ne 0
+}
+
+do_show_usage() {
+ echo "usage: git-sar pathspec sed"
+ exit 128
+}
+
+do_main() {
+ # Verify argument size
+ if test "$#" -le 1 -o "$#" -ge 4
+ then
+ do_show_usage
+ fi
+
+ # Two argument form
+ if test "$#" -eq 2
+ then
+ do_git_find "$@"
+ fi
+
+ # Three argument form, we're calling ourselves through sed
+ if test "$#" -eq 3
+ then
+ # Double check if the user typoed or if we are indeed meta-calling
+ if test "$1" != "--replace"
+ then
+ do_show_usage
+ fi
+
+ do_sed "$@"
+ fi
+}
+
+do_main "$@"
+
--
1.5.6.4.570.g052e.dirty
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 16:02 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Jakub Narebski, git, Stephan Beyer
In-Reply-To: <20080723145455.GS2925@dpotapov.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 11:53:27AM +0200, Johannes Schindelin wrote:
> >
> > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >
> >
> > > 11. Why did you choose Git? (if you use Git)
> > > What do you like about using Git?
> > > (free form, not to be tabulated)
> >
> > Again, to avoid hassles with free-form:
> >
> > Mandatory: work, mandatory: open source project I am participating
> > in, speed, scalability, It's What Linus Uses, Other.
>
> If we move away from free-form, it should be much more choices here.
>
> - Ability to work offline
> - Cryptographic authentication of history.
Cryptographically strong integrity check. There is no authentication.
> - Distributed development (pull/push from/to more than one remote repo)
> - Easy to extend functionality through scripting
> - Efficient storage model
> - Elegant design
> - Fast
> - Good community support
> - Rewriting patches before publishing (git rebase, commit --amend)
> - Scalability (Efficient handling of large projects)
> - Strong support for non-linear development
> - Support of wide range of protocols for synchronization.
> ...
Yeah, I would tick all of them, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 16:00 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jakub Narebski, git
In-Reply-To: <200807231654.18019.robin.rosenberg.lists@dewire.com>
Hi,
On Wed, 23 Jul 2008, Robin Rosenberg wrote:
> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>
> > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >
> > > On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> > > > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> > > >
> > > > Some people prefer to stay anonymous, so I think email is out.
> > > >
> > > > > 04. Which programming languages you are proficient with?
> > > > > (The choices include programming languages used by git)
> > > > > (zero or more: multiple choice)
> > > > > - C, shell, Perl, Python, Tcl/Tk
> > > > > + (should we include other languages, like C++, Java, PHP,
> > > > > Ruby,...?)
> > > >
> > > > Yes, I think this should be a long list.
> > >
> > > I'd rather not have a "laundry list" of languages. I have put C++
> > > because QGit uses it, Java because of egit/jgit, PHP for web
> > > interfaces, Ruby because of GitHub and because of Ruby comminity
> > > choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
> > > JavaScript here. What other languages should be considered?
> >
> > C# at least, since we had one (pretty unsuccessful) attempt at
> > reimplementing Git in it.
>
> What is the reason for the question? Do we want to know what languages
> people would like to contribute to Git in or do we want to know what "kind"
> of programmers are attracted by Git? Making it a long list should make
> it easier to tabulate the responses.
"could contribute" is more appropriate IMHO. Although you might be right
to ask "would like to contribute"... ;-)
Ciao,
Dscho
^ permalink raw reply
* git svn throws locale related error when built from source
From: Anton Mostovoy @ 2008-07-23 16:00 UTC (permalink / raw)
To: git
In-Reply-To: <20080722203128.GB5113@blimp.local>
Hi
I built git 1.5.6.3 manually (no package with 1.5.4+ on gutsy), and I am
getting the error below when running 'git svn rebase'.
svn works fine on its own though.
The default locale is set to en_US.UTF-8
svn: error: cannot set LC_ALL locale
svn: error: environment variable LANG is en_US.UTF-8
svn: error: please check that your locale name is correct
I found a workaround that works, but it would be nice to have it work
properly.
$> LANG= git svn rebase"
Thanks in advance.
-Anton
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Avery Pennarun @ 2008-07-23 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7viquxjwyf.fsf@gitster.siamese.dyndns.org>
On 7/22/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Avery Pennarun" <apenwarr@gmail.com> writes:
> > Why doesn't "edit" just stage the commit and not auto-commit it at
> > all? That way an amend would *never* be necessary, and rebase
> > --continue would always do a commit -a (if there was anything left to
> > commit). The special case fixed by this patch would thus not be
> > needed.
>
> That would actually be in-line with the way how "rebase --skip" does the
> resetting without asking the user to do so, wouldn't it?
I'm not sure exactly what you mean, but I think with my proposed
change, "rebase --skip" would do "git reset --hard HEAD" while "rebase
--continue" would do "git commit -a", so it would be nice and
symmetrical, where currently it isn't exactly.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Avery Pennarun @ 2008-07-23 15:53 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <20080723120104.GQ2925@dpotapov.dyndns.org>
On 7/23/08, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Jul 22, 2008 at 06:22:34PM -0400, Avery Pennarun wrote:
> > This patch is perhaps a symptom of something I've been meaning to ask
> > about for a while.
> >
> > Why doesn't "edit" just stage the commit and not auto-commit it at
> > all? That way an amend would *never* be necessary, and rebase
> > --continue would always do a commit -a (if there was anything left to
> > commit).
>
> Actually, it would be better to refuse to continue if there are unstaged
> changes in the work tree, and if all changes are staged then just do git
> commit.
I'm not sure about that. The auto-committing on --continue has never
annoyed me, and in fact I greatly appreciate that I can just "git
rebase --continue" after making changes and the expected thing will
happen. After all, if I screw it up and commit too much at once, I
can always just rebase one more time.
However, taking out the auto-commit wouldn't pain me too much if
others want it that way. It would be somewhat more typing, but at
least makes easy to understand exactly what's going on.
> It would not only save typing, but also help to avoid costly mistakes
> where users, being taught to use "git commit --amend" after editing
> during git-rebase, fire this command automatically after a conflict
> resolution and get two commits accidently squashed.
Yes! Good point. I forgot about this, but I've been bitten by it a
couple of times.
Have fun,
Avery
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Avery Pennarun @ 2008-07-23 15:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alexander Litvinov, git
In-Reply-To: <alpine.DEB.1.00.0807231356540.8986@racer>
On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > > In short: I can't clone svn repo into git when crlf convertion is
> > > > activated.
> > >
> > > This is a known issue, but since nobody with that itch seems to care
> > > enough to fix it, I doubt it will ever be fixed.
> >
> > That is a bad news for me. Anyway I will spend some time at holidays
> > during digging this bug.
>
> Note that you will have to do your digging using msysGit (i.e. the
> developer's pack, not the installer for plain Git), since git-svn will be
> removed from the next official "Windows Git" release, due to lack of
> fixers.
Presumably cygwin git will work too, right?
Does this known issue apply only to msysGit, or both msys and Cygwin,
or all versions? ie. could it be debugged on Linux?
Thanks,
Avery
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Matthias Kestenholz @ 2008-07-23 15:43 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Jakub Narebski, git, Stephan Beyer
In-Reply-To: <20080723143810.GR2925@dpotapov.dyndns.org>
On Wed, 2008-07-23 at 18:38 +0400, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> > 02. What is your preferred non-programming language?
> > (or) What is the language you want computer communicate with you?
>
> IMHO, the later wording of the question is much better.
I think these are two separate questions. In my case the first is
(swiss) german, the second is english. I don't like localized software
too much, I always have to think what a certain german term might mean
in english to understand computing-specific texts.
That being said I think that the first question is irrelevant for the
git survey. Maybe we should use the term 'internationalization' or
'localization' somewhere to make clear what we are talking about. While
these terms might scare newbies away we can reasonably expect that they
are known by git users.
Matthias
^ permalink raw reply
* Re: [PATCH 2/2] sort_in_topological_order(): avoid setting a commit flag
From: Jon Loeliger @ 2008-07-23 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, pasky, git
In-Reply-To: <7v7ibdifbp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> Do people still actively use show-branch as a G/CUI, especially after that
> "log --graph" thing was introduced?
At the risk of sounding Old School, yes.
While the "log --graph" thing is Really Slick, it has
grumbly-factors, IMO. First, I have to set up an alias
all the time, as "git log --graph --pretty=oneline" is
grumpy typing. Second, I always have to widen my screen
to accommodate reasonable looking output or colrm it.
(Having it self-colrm to window-width would be nice.)
(Sure, --abbrev-commit too, but see "First," above. :-))
Finally, I frequently like seeing a self-limited history
when all the branches reach their common ancestor.
HTH,
jdl
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-23 15:38 UTC (permalink / raw)
To: git
In-Reply-To: <20080723145518.GA29035@laptop>
Sorry list. Forgot --thread in format-patch :(
--
Duy
^ permalink raw reply
* Re: [PATCH] index-pack: never prune base_cache.
From: Pierre Habouzit @ 2008-07-23 15:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Björn Steinbrink, spearce, Git ML, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807231537420.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
On Wed, Jul 23, 2008 at 02:41:14PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Björn Steinbrink wrote:
>
> > diff --git a/index-pack.c b/index-pack.c
> > index ac20a46..33ba8ef 100644
> > --- a/index-pack.c
> > +++ b/index-pack.c
> > @@ -699,6 +699,9 @@ static struct object_entry *append_obj_to_pack(
> > write_or_die(output_fd, header, n);
> > obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
> > obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
> > + obj[0].hdr_size = n;
> > + obj[0].type = type;
> > + obj[0].size = size;
> > obj[1].idx.offset = obj[0].idx.offset + n;
> > obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0]..idx.crc32);
> > hashcpy(obj->idx.sha1, sha1);
>
> I confirm that the issues I saw went away with this patch, and it looks
> obviously like the correct approach.
>
> The only things valgrind is still complaining about (apart from libz,
> which I will not bother commenting about) are uninitialized parts of the
> data being written to disk, and a crc over them.
>
> Judging from the addresses, those are probably the bytes that are padded
> for 4- or 8-byte alignment, so they are probably fine.
I confirm this analysis having done the same independently and reached
the same conclusions.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Ingo Molnar @ 2008-07-23 15:06 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <20080723145622.GA23440@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> > Shouldn't this be:
> >
> > [ -f "$CACHE" -a "$CACHE" -nt .git/refs/heads/$BRANCH ] && {
> >
> > ?
>
> yeah, i just figured it out too ... the hard way :)
>
> Updated script below. This works fine across resets in the master
> branch.
>
> While it's fast in the empty-merge case, it's not as fast as i'd like
> it to be in the almost-empty-merge case.
When i update a topic branch, i first get a relatively fast run:
earth4:~/tip> time todo-merge-all
merging all branches ...
Auto-merged arch/x86/kernel/genx2apic_uv_x.c
Merge made by recursive.
arch/x86/kernel/genx2apic_uv_x.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
... merge done.
real 0m6.625s
user 0m3.740s
sys 0m2.563s
Then on the next run it's slower:
earth4:~/tip> time todo-merge-all
merging all branches ...
... merge done.
real 0m30.823s
user 0m23.403s
sys 0m7.545s
that's unfortunate. The freshly updated topic branch was at the end of
the run, now all other topic branches will have to run slow at least
once until they become cached again.
Perhaps the cache should update all other current topics to the new
sha1, to establish the fact that they were not merged this time. (and
that they are still not to be merged)
(It's still much faster than completely uncached though, because of the
overlap in sha1's.)
Third (empty) run is fast again, because it's fully cached:
earth4:~/tip> time todo-merge-all
merging all branches ...
... merge done.
real 0m3.036s
user 0m1.360s
sys 0m1.782s
But it would be nice if the cache worked more intelligently in the
one-topic-updated-only case as well.
Ingo
^ permalink raw reply
* [PATCH 12/12] git-status: print sparse checkout status
From: Nguyễn Thái Ngọc Duy @ 2008-07-23 14:58 UTC (permalink / raw)
To: git
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
wt-status.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 889e50f..28add31 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -361,12 +361,18 @@ void wt_status_print(struct wt_status *s)
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "# Initial commit");
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
- wt_status_print_initial(s);
}
- else {
- wt_status_print_updated(s);
+
+ if (get_sparse_prefix()) {
+ color_fprintf(s->fp, color(WT_STATUS_HEADER), "# Sparse checkout: ");
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), get_sparse_prefix_str());
}
+ if (s->is_initial)
+ wt_status_print_initial(s);
+ else
+ wt_status_print_updated(s);
+
wt_status_print_changed(s);
if (wt_status_submodule_summary)
wt_status_print_submodule_summary(s);
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 10/12] git-checkout: support --full and --path to manipulate sparse checkout
From: Nguyễn Thái Ngọc Duy @ 2008-07-23 14:57 UTC (permalink / raw)
To: git
"git checkout --full" will quit sparse checkout mode while
"git checkout --sparse=prefix" will turn on sparse checkout or
update sparse prefix.
twoway_merge has been updated to deal with sparse checkout update.
Files that are in old sparse prefix only will get removed while
files that are in new sparse prefix only will get added.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-checkout.c | 44 +++++++++++++++++++
cache.h | 2 +
unpack-trees.c | 120 ++++++++++++++++++++++++++++++++++++++++++++++++----
unpack-trees.h | 3 +-
4 files changed, 160 insertions(+), 9 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index eec1bde..410a53a 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -160,6 +160,9 @@ struct checkout_opts {
char *new_branch;
int new_branch_log;
enum branch_track track;
+
+ char *sparse_prefix;
+ int no_sparse_checkout;
};
static int reset_tree(struct tree *tree, struct checkout_opts *o, int worktree)
@@ -255,7 +258,25 @@ static int merge_working_tree(struct checkout_opts *opts,
tree = parse_tree_indirect(new->commit->object.sha1);
init_tree_desc(&trees[1], tree->buffer, tree->size);
+ if (opts->no_sparse_checkout)
+ topts.new_sparse_prefix = 1;
+
+ if (opts->sparse_prefix) {
+ char **new_sparse_prefix = split_prefix(opts->sparse_prefix);
+
+ if (!new_sparse_prefix) {
+ error("new sparse prefix invalid");
+ return 1;
+ }
+ topts.new_sparse_prefix = 1;
+ topts.unpack_data = new_sparse_prefix;
+ }
+
ret = unpack_trees(2, trees, &topts);
+
+ if (topts.new_sparse_prefix && topts.unpack_data)
+ free_prefix_list((char **)topts.unpack_data);
+
if (ret == -1) {
/*
* Unpack couldn't do a trivial merge; either
@@ -299,6 +320,14 @@ static int merge_working_tree(struct checkout_opts *opts,
commit_locked_index(lock_file))
die("unable to write new index file");
+ /*
+ * update sparse checkout accordingly
+ * show_local_changes will need it
+ */
+ if (opts->no_sparse_checkout)
+ free_prefix_list(save_sparse_prefix());
+ if (opts->sparse_prefix)
+ set_sparse_prefix(opts->sparse_prefix);
if (!opts->force)
show_local_changes(&new->commit->object);
@@ -409,6 +438,13 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
update_refs_for_switch(opts, &old, new);
+ /* now save new sparse prefix */
+ if (opts->no_sparse_checkout)
+ git_config_set("core.sparsecheckout", NULL);
+
+ if (opts->sparse_prefix)
+ git_config_set("core.sparsecheckout", opts->sparse_prefix);
+
ret = post_checkout_hook(old.commit, new->commit, 1);
return ret || opts->writeout_error;
}
@@ -428,6 +464,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
BRANCH_TRACK_EXPLICIT),
OPT_BOOLEAN('f', NULL, &opts.force, "force"),
OPT_BOOLEAN('m', NULL, &opts.merge, "merge"),
+ OPT_STRING(0, "path", &opts.sparse_prefix, "prefixes", "update sparse checkout"),
+ OPT_BOOLEAN(0, "full", &opts.no_sparse_checkout, "quit sparse checkout"),
OPT_END(),
};
@@ -468,6 +506,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (!opts.new_branch && (opts.track != git_branch_track))
die("git checkout: --track and --no-track require -b");
+ if (opts.no_sparse_checkout && opts.sparse_prefix)
+ die("git checkout: --path and --full are incompatible");
+
if (opts.force && opts.merge)
die("git checkout: -f and -m are incompatible");
@@ -486,6 +527,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
}
}
+ if (opts.no_sparse_checkout || opts.sparse_prefix)
+ die("git checkout: updating paths is incompatible with setting sparse checkout");
+
return checkout_paths(source_tree, pathspec);
}
diff --git a/cache.h b/cache.h
index b9a1d96..9e7f146 100644
--- a/cache.h
+++ b/cache.h
@@ -138,6 +138,8 @@ struct cache_entry {
#define CE_HASHED (0x100000)
#define CE_UNHASHED (0x200000)
+#define CE_WD_REMOVE (0x400000)
+
/*
* Copy the sha1 and stat state of a cache entry from one to
* another. But we never change the name, or the hash state!
diff --git a/unpack-trees.c b/unpack-trees.c
index 0a30d68..a88c53f 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -105,13 +105,29 @@ static int check_updates(struct unpack_trees_options *o)
struct index_state *index = &o->result;
int i;
int errs = 0;
+ char **old_sparse_prefix = NULL;
+ char **new_sparse_prefix = NULL;
+
+ /*
+ * for sparse checkout update, we need to widen the prefix a bit
+ * so that updating in new sparse prefix won't get caught by
+ * sparse prefix checks
+ */
+ if (o->new_sparse_prefix) {
+ old_sparse_prefix = save_sparse_prefix();
+ if (o->unpack_data) {
+ new_sparse_prefix = o->unpack_data;
+ new_sparse_prefix = combine_prefix_list(old_sparse_prefix, new_sparse_prefix);
+ restore_sparse_prefix(new_sparse_prefix);
+ }
+ }
if (o->update && o->verbose_update) {
for (total = cnt = 0; cnt < index->cache_nr; cnt++) {
struct cache_entry *ce = index->cache[cnt];
if (outside_sparse_prefix(ce->name))
continue;
- if (ce->ce_flags & (CE_UPDATE | CE_REMOVE))
+ if (ce->ce_flags & (CE_UPDATE | CE_REMOVE | CE_WD_REMOVE))
total++;
}
@@ -125,12 +141,14 @@ static int check_updates(struct unpack_trees_options *o)
if (outside_sparse_prefix(ce->name))
continue;
- if (ce->ce_flags & CE_REMOVE) {
+ if (ce->ce_flags & (CE_REMOVE | CE_WD_REMOVE)) {
display_progress(progress, ++cnt);
if (o->update)
unlink_entry(ce);
- remove_index_entry_at(&o->result, i);
- i--;
+ if (ce->ce_flags & CE_REMOVE) {
+ remove_index_entry_at(&o->result, i);
+ i--;
+ }
continue;
}
}
@@ -149,6 +167,10 @@ static int check_updates(struct unpack_trees_options *o)
}
}
stop_progress(&progress);
+ if (o->new_sparse_prefix) {
+ restore_sparse_prefix(old_sparse_prefix);
+ free_prefix_list(new_sparse_prefix);
+ }
return errs != 0;
}
@@ -680,8 +702,8 @@ static int verify_absent(struct cache_entry *ce, const char *action,
return 0;
}
-static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
- struct unpack_trees_options *o)
+static int merged_entry_internal(struct cache_entry *merge, struct cache_entry *old,
+ struct unpack_trees_options *o, int set, int clear)
{
int update = CE_UPDATE;
@@ -708,10 +730,28 @@ static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
invalidate_ce_path(merge, o);
}
- add_entry(o, merge, update, CE_STAGEMASK);
+ add_entry(o, merge, (update & (~clear)) | set, CE_STAGEMASK);
return 1;
}
+static int merged_entry(struct cache_entry *merge, struct cache_entry *old,
+ struct unpack_trees_options *o)
+{
+ return merged_entry_internal(merge, old, o, 0, 0);
+}
+
+static int merged_entry_and_no_add(struct cache_entry *merge, struct cache_entry *old,
+ struct unpack_trees_options *o)
+{
+ return merged_entry_internal(merge, old, o, 0, CE_UPDATE);
+}
+
+static int merged_entry_and_add(struct cache_entry *merge, struct cache_entry *old,
+ struct unpack_trees_options *o)
+{
+ return merged_entry_internal(merge, old, o, CE_UPDATE, 0);
+}
+
static int deleted_entry(struct cache_entry *ce, struct cache_entry *old,
struct unpack_trees_options *o)
{
@@ -734,6 +774,20 @@ static int keep_entry(struct cache_entry *ce, struct unpack_trees_options *o)
return 1;
}
+static int keep_entry_and_add(struct cache_entry *ce, struct unpack_trees_options *o)
+{
+ add_entry(o, ce, CE_UPDATE, 0);
+ return 1;
+}
+
+static int keep_entry_and_remove(struct cache_entry *ce, struct unpack_trees_options *o)
+{
+ if (verify_uptodate(ce, o))
+ return -1;
+ add_entry(o, ce, CE_WD_REMOVE, 0);
+ return 1;
+}
+
#if DBRT_DEBUG
static void show_stage_entry(FILE *o,
const char *label, const struct cache_entry *ce)
@@ -918,12 +972,31 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
* over a merge failure when it makes sense. For details of the
* "carry forward" rule, please see <Documentation/git-read-tree.txt>.
*
+ * Two-way merge with sparse prefix update.
+ *
+ * The rules are as same as plain two-way merge, except:
+ * 1) if it's in old sparse checkout, but not the new one, mark it CE_WD_REMOVE
+ * 2) if it's in the new one, but not the old one, mark it CE_UPDATE
+ * 3) otherwise, let old two-way merge take it
+ *
+ * case 1)
+ * keep index implies CE_WD_REMOVE (remove workdir only, keep file in index)
+ * use M implies no CE_UPDATE
+ * if index is not clean, fail
+ *
+ * case 2)
+ * keep index implies CE_UPDATE
+ * use M implies CE_UPDATE
+ * index can't be unclean, so ignore this
+ *
*/
int twoway_merge(struct cache_entry **src, struct unpack_trees_options *o)
{
struct cache_entry *current = src[0];
struct cache_entry *oldtree = src[1];
struct cache_entry *newtree = src[2];
+ int remove = 0, add = 0;
+ char **new_sparse_prefix = (char **)o->unpack_data;
if (o->merge_size != 2)
return error("Cannot do a twoway merge of %d trees",
@@ -935,6 +1008,13 @@ int twoway_merge(struct cache_entry **src, struct unpack_trees_options *o)
newtree = NULL;
if (current) {
+ if (o->new_sparse_prefix) {
+ remove = !outside_sparse_prefix(current->name) &&
+ outside_prefix_list(new_sparse_prefix, current->name);
+ add = outside_sparse_prefix(current->name) &&
+ !outside_prefix_list(new_sparse_prefix, current->name);
+ }
+
if ((!oldtree && !newtree) || /* 4 and 5 */
(!oldtree && newtree &&
same(current, newtree)) || /* 6 and 7 */
@@ -943,6 +1023,12 @@ int twoway_merge(struct cache_entry **src, struct unpack_trees_options *o)
(oldtree && newtree &&
!same(oldtree, newtree) && /* 18 and 19 */
same(current, newtree))) {
+ if (o->new_sparse_prefix) {
+ if (remove)
+ return keep_entry_and_remove(current, o);
+ if (add)
+ return keep_entry_and_add(current, o);
+ }
return keep_entry(current, o);
}
else if (oldtree && !newtree && same(current, oldtree)) {
@@ -952,6 +1038,12 @@ int twoway_merge(struct cache_entry **src, struct unpack_trees_options *o)
else if (oldtree && newtree &&
same(current, oldtree) && !same(current, newtree)) {
/* 20 or 21 */
+ if (o->new_sparse_prefix) {
+ if (remove)
+ return merged_entry_and_no_add(newtree, current, o);
+ if (add)
+ return merged_entry_and_add(newtree, current, o);
+ }
return merged_entry(newtree, current, o);
}
else {
@@ -965,8 +1057,20 @@ int twoway_merge(struct cache_entry **src, struct unpack_trees_options *o)
return -1;
}
}
- else if (newtree)
+ else if (newtree) {
+ if (o->new_sparse_prefix) {
+ remove = !outside_sparse_prefix(newtree->name) &&
+ outside_prefix_list(new_sparse_prefix, newtree->name);
+ add = outside_sparse_prefix(newtree->name) &&
+ !outside_prefix_list(new_sparse_prefix, newtree->name);
+
+ if (remove)
+ return merged_entry_and_no_add(newtree, current, o);
+ if (add)
+ return merged_entry_and_add(newtree, current, o);
+ }
return merged_entry(newtree, current, o);
+ }
return deleted_entry(oldtree, current, o);
}
diff --git a/unpack-trees.h b/unpack-trees.h
index a1b46f9..5a29fc4 100644
--- a/unpack-trees.h
+++ b/unpack-trees.h
@@ -27,7 +27,8 @@ struct unpack_trees_options {
aggressive:1,
skip_unmerged:1,
gently:1,
- check_index_prefix:1;
+ check_index_prefix:1,
+ new_sparse_prefix:1; /* unpack_data must contain new prefix */
const char *prefix;
int pos;
struct dir_struct *dir;
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 11/12] tests for checkout [--full|--path]
From: Nguyễn Thái Ngọc Duy @ 2008-07-23 14:57 UTC (permalink / raw)
To: git
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t2010-checkout-sparse.sh | 71 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
create mode 100755 t/t2010-checkout-sparse.sh
diff --git a/t/t2010-checkout-sparse.sh b/t/t2010-checkout-sparse.sh
new file mode 100755
index 0000000..5bb82ae
--- /dev/null
+++ b/t/t2010-checkout-sparse.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+test_description='sparse checkout'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ mkdir work1 work2 work3
+ touch one two three
+ touch work1/one work2/two work3/three
+ git add one work1/one
+ git commit -m work1
+ git add two work2/two
+ git commit -m work2
+ git add three work3/three
+ git commit -m work3
+'
+
+test_expect_success '--full on no-sparse checkout' '
+ git checkout --full
+'
+
+test_expect_success '--full and --path incompatible' '
+ test_must_fail git checkout --full --path=work1
+'
+
+test_expect_success 'limit worktree to work1 and work2' '
+ git checkout --path=work1:work2 &&
+ test work1:work2 = "$(git rev-parse --show-sparse-prefix)" &&
+ test -f work1/one &&
+ test -f work2/two &&
+ ! test -f work3/three
+'
+
+test_expect_success 'update worktree to work2 and work3' '
+ git checkout --path=work2:work3 &&
+ test work2:work3 = "$(git rev-parse --show-sparse-prefix)" &&
+ ! test -f work1/one &&
+ test -f work2/two &&
+ test -f work3/three
+'
+
+test_expect_success 'update sparse prefix with modification' '
+ echo modified >> work2/two &&
+ git checkout --path=work1:work2 &&
+ test work1:work2 = "$(git rev-parse --show-sparse-prefix)" &&
+ test -f work1/one &&
+ test -f work2/two &&
+ ! test -f work3/three &&
+ grep -q modified work2/two
+'
+
+test_expect_success 'update sparse should not lose modification' '
+ ! git checkout --path=work1:work3 &&
+ test work1:work2 = "$(git rev-parse --show-sparse-prefix)" &&
+ test -f work1/one &&
+ test -f work2/two &&
+ ! test -f work3/three &&
+ grep -q modified work2/two
+'
+
+test_expect_success 'exit sparse checkout' '
+ git checkout --full &&
+ test -z "$(git rev-parse --show-sparse-prefix)" &&
+ test -f work1/one &&
+ test -f work2/two &&
+ test -f work3/three &&
+ test one
+'
+
+test_done
--
1.5.5.GIT
^ permalink raw reply related
* [PATCH 09/12] tests for sparse clone
From: Nguyễn Thái Ngọc Duy @ 2008-07-23 14:57 UTC (permalink / raw)
To: git
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t5703-clone-sparse.sh | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
create mode 100755 t/t5703-clone-sparse.sh
diff --git a/t/t5703-clone-sparse.sh b/t/t5703-clone-sparse.sh
new file mode 100755
index 0000000..012ead0
--- /dev/null
+++ b/t/t5703-clone-sparse.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+test_description='sparse clone'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ rm -fr .git &&
+ test_create_repo src &&
+ (
+ cd src
+ mkdir -p work/sub/dir
+ touch untracked tracked modified added
+ touch work/untracked work/tracked work/modified work/added
+ git add tracked work/tracked
+ git add modified work/modified
+ git commit -m initial
+ )
+
+'
+
+test_expect_success 'sparse clone incompatible with --bare' '
+ rm -fr dst &&
+ test_must_fail git clone --path=work --bare src dst
+'
+
+test_expect_success 'sparse clone incompatible with --no-checkout' '
+ rm -fr dst &&
+ test_must_fail git clone --path=work -n src dst
+'
+
+test_expect_success 'clone with --path' '
+ rm -fr dst &&
+ git clone --path=work src dst &&
+ cd dst &&
+ test work = "$(git rev-parse --show-sparse-prefix)" &&
+ test -z "$(git ls-files | grep -v ^work/)"
+'
+
+test_done
--
1.5.5.GIT
^ permalink raw reply related
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