* Re: [PATCH] Documentation update for 'git branch --list'
From: Vincent van Ravesteijn @ 2011-11-21 15:00 UTC (permalink / raw)
To: Vincent van Ravesteijn; +Cc: git, gitster, git
In-Reply-To: <1321886000-4163-1-git-send-email-vfr@lyx.org>
> The current synopsis also suggests that 'git branch -d<pattern>...'
> would be a valid command.
Well.. that's a lie.
Vincent
^ permalink raw reply
* [PATCH] Documentation update for 'git branch --list'
From: Vincent van Ravesteijn @ 2011-11-21 14:33 UTC (permalink / raw)
To: git; +Cc: gitster, git, Vincent van Ravesteijn
Indicate that the <pattern>... argument is only valid when using --list.
Otherwise a branch with the name <pattern> will be created. The current
synopsis also suggests that 'git branch -d <pattern>...' would be a valid
command.
Minor changes:
- add a period to a sentence,
- change tag into branch.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
Documentation/git-branch.txt | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index f46013c..9f49db4 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,8 +9,9 @@ SYNOPSIS
--------
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
- [--list] [-v [--abbrev=<length> | --no-abbrev]]
- [(--merged | --no-merged | --contains) [<commit>]] [<pattern>...]
+ [-v [--abbrev=<length> | --no-abbrev]]
+ [(--merged | --no-merged | --contains) [<commit>]]
+ [--list [<pattern>...]]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
@@ -23,8 +24,8 @@ be highlighted with an asterisk. Option `-r` causes the remote-tracking
branches to be listed, and option `-a` shows both. This list mode is also
activated by the `--list` option (see below).
<pattern> restricts the output to matching branches, the pattern is a shell
-wildcard (i.e., matched using fnmatch(3))
-Multiple patterns may be given; if any of them matches, the tag is shown.
+wildcard (i.e., matched using fnmatch(3)).
+Multiple patterns may be given; if any of them matches, the branch is shown.
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
@@ -114,7 +115,7 @@ OPTIONS
--all::
List both remote-tracking branches and local branches.
---list::
+--list [<pattern>...]::
Activate the list mode. `git branch <pattern>` would try to create a branch,
use `git branch --list <pattern>` to list matching branches.
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Show error for 'git merge' with unset merge.defaultToUpstream
From: Vincent van Ravesteijn @ 2011-11-21 13:30 UTC (permalink / raw)
To: git; +Cc: gitster, Vincent van Ravesteijn
'git merge' can be called without any arguments if merge.defaultToUpstream
is set. However, when merge.defaultToUpstream is not set, the user will be
presented the usage information as if he entered a command with a wrong
syntaxis. Ironically, the usage information confirms that no arguments are
mandatory.
This adds a proper error message telling the user why the command failed. As
a side-effect this can help the user in discovering the possibility to merge
with the upstream branch by setting merge.defaultToUpstream.
Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>
---
builtin/merge.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index dffd5ec..900a297 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1160,9 +1160,12 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
die(_("You cannot combine --no-ff with --ff-only."));
if (!abort_current_merge) {
- if (!argc && default_to_upstream)
- argc = setup_with_upstream(&argv);
- else if (argc == 1 && !strcmp(argv[0], "-"))
+ if (!argc) {
+ if (default_to_upstream)
+ argc = setup_with_upstream(&argv);
+ else
+ die(_("No commit specified and merge.defaultToUpstream not set."));
+ } else if (argc == 1 && !strcmp(argv[0], "-"))
argv[0] = "@{-1}";
}
if (!argc)
--
1.7.4.1
^ permalink raw reply related
* Re: Feature requset: listing of current stash in git gui
From: dexen deVries @ 2011-11-21 12:41 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <4ECA2D8F.4060005@atlas-elektronik.com>
On Monday 21 of November 2011 11:53:03 Stefan Näwe wrote:
> You can simply put the following in your ~/.gitconfig:
>
> [guitool "Stash/show"]
> cmd = git stash show -p
> [guitool "Stash/list"]
> cmd = git stash list
> [guitool "Stash/pop"]
> cmd = git stash pop
> [guitool "Stash/drop"]
> cmd = git stash drop
> confirm = yes
that's nice, but doesn't list visually the stashed changes. I'd rather have a
listing similar to Unstanged Changes / Staged Changes, with ability to view
line-by-line diff just like for Changes.
Regards,
--
dexen deVries
[[[↓][→]]]
``As my friend Jacob Gabrielson once put it, advocating Object-Oriented
Programming is like advocating Pants-Oriented Clothing.''
-- Steve Yegge, in
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
^ permalink raw reply
* Re: [PATCH] documentation fix: git difftool uses diff tools, not merge tools.
From: David Aguilar @ 2011-11-21 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Hochstein, git
In-Reply-To: <7v62imi6c7.fsf@alter.siamese.dyndns.org>
On Mon, Nov 14, 2011 at 4:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thomas Hochstein <thh@inter.net> writes:
>
>> Let the documentation for -t list valid *diff* tools,
>> not valid *merge* tools.
>>
>> Signed-off-by: Thomas Hochstein <thh@inter.net>
>> ---
>> Documentation/git-difftool.txt | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
>> index a03515f..19d473c 100644
>> --- a/Documentation/git-difftool.txt
>> +++ b/Documentation/git-difftool.txt
>> @@ -31,7 +31,7 @@ OPTIONS
>> -t <tool>::
>> --tool=<tool>::
>> Use the diff tool specified by <tool>.
>> - Valid merge tools are:
>> + Valid diff tools are:
>> araxis, bc3, diffuse, emerge, ecmerge, gvimdiff, kdiff3,
>> kompare, meld, opendiff, p4merge, tkdiff, vimdiff and xxdiff.
>> +
>
> The patch is obviously correct, and it is so trivial that there is no risk
> of breaking anything. It would even be OK for 1.7.7.X maintenance series.
>
> But in the longer term, I suspect that we would want to drop this
> enumeration from the documentation, and instead give "--list-tools"
> option or something to the command. That way, we only need to keep
> the list of known tools in one place where it matters, namely, the
> command that knows about them.
>
> David, what do you think?
>
> The same comment applies to "git mergetool", I would think.
Exactly my thoughts.
--
David
^ permalink raw reply
* Re: Feature requset: listing of current stash in git gui
From: Stefan Näwe @ 2011-11-21 10:53 UTC (permalink / raw)
To: dexen deVries; +Cc: git@vger.kernel.org
In-Reply-To: <201111211100.52367.dexen.devries@gmail.com>
Am 21.11.2011 11:00, schrieb dexen deVries:
> Hi,
>
>
> please consider listing modifications stored in git's stash somewhere in git
> gui window. Perhaps above the `Staged Changes' subframe. Format of the listing
> similar to output of `git stash list'. Available operations would be Pop,
> Apply, Save and Drop.
You can simply put the following in your ~/.gitconfig:
[guitool "Stash/show"]
cmd = git stash show -p
[guitool "Stash/list"]
cmd = git stash list
[guitool "Stash/pop"]
cmd = git stash pop
[guitool "Stash/drop"]
cmd = git stash drop
confirm = yes
That will give you a new sub-menu in the 'Tools' menu of git gui.
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Dreams are free, but you get soaked on the connect time.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Feature requset: listing of current stash in git gui
From: dexen deVries @ 2011-11-21 10:00 UTC (permalink / raw)
To: git
Hi,
please consider listing modifications stored in git's stash somewhere in git
gui window. Perhaps above the `Staged Changes' subframe. Format of the listing
similar to output of `git stash list'. Available operations would be Pop,
Apply, Save and Drop.
Regards,
--
dexen deVries
[[[↓][→]]]
``As my friend Jacob Gabrielson once put it, advocating Object-Oriented
Programming is like advocating Pants-Oriented Clothing.''
-- Steve Yegge, in
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-21 8:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vsjlhhq33.fsf@alter.siamese.dyndns.org>
On Mon, Nov 21, 2011 at 2:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If this is a feature, we would like a patch to Documentation/gitignore.txt
> as well, I think. Also I have a suspicion that this was an unintended
> "regression"; do you have a bisection?
It dated back to f8a9d42 (read-tree: further loosen "working file will
be lost" check. - 2006-12-04) when you introduced
--exclude-per-directory to read-tree, but not --exclude-from to
explicitly add .git/info/exclude. "read tree --exclude-per-directory"
is used in git-checkout.sh and the same logic is carried over to
builtin-checkout.c until today.
I guess it's time to add "read-tree --exclude-from". Not sure what to
do with git-checkout though. We may add an option to checkout to skip
either .git/info/exclude or .gitignore, or both.
--
Duy
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Nguyen Thai Ngoc Duy @ 2011-11-21 8:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
On Mon, Nov 21, 2011 at 08:23:45AM +0100, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> It is an unintended accident that entries matched by .git/info/exclude are
> considered precious, but entries matched by .gitignore are not. That is,
> 'git checkout' will overwrite untracked files matched by .gitignore, but
> refuses to overwrite files matched by .git/info/exclude.
>
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
>
> Add a test that codifies the accident as wanted behavior.
If you want to keep this accident (which is a bug to me), you may want
to add the reason: callers to unpack_trees() are supposed to also
setup exclude rules in .git/info/exclude before calling
unpack_trees(), which they don't.
So .git/info/exclude is entirely dismissed. This patch makes t2023.3
fail. I haven't dug into history to see if this is on purpose though.
-- 8< --
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2a80772..c2fc2ba 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -412,6 +412,8 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.dir = xcalloc(1, sizeof(*topts.dir));
topts.dir->flags |= DIR_SHOW_IGNORED;
topts.dir->exclude_per_dir = ".gitignore";
+ if (!access(git_path("info/exclude"), R_OK))
+ add_excludes_from_file(topts.dir, git_path("info/exclude"));
tree = parse_tree_indirect(old->commit ?
old->commit->object.sha1 :
EMPTY_TREE_SHA1_BIN);
-- 8< --
--
Duy
^ permalink raw reply related
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 7:59 UTC (permalink / raw)
To: Philip Oakley; +Cc: Johannes Sixt, Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <00392567F0B045E38A429F95594C1BD2@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> Shouldn't there be some documentation changes to support this very
> useful feature.
I do not agree it is "useful", if it is info/exclude only, which by design
would not propagate across repositories and histories.
If we were to support "precious" as a feature, we should do that properly
with a properly defined syntax (e.g. just like '!' prefix is "no, this is
not 'ignored' entry", use some prefix to say "well, this is ignored in the
sense that not to be tracked, but that does not mean this can be nuked")
that can be in any exclude sources.
Exclude patterns in info/exclude should work just like ones in the in-tree
.gitignore only at different precedence for uniformity and consistency, so
the behaviour J6t showed in the new test should be fixed.
The entries in info/exclude are at lower priority than the ones in in-tree
.gitignore files, which probably was a design mistake, but that is a
separate issue.
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Junio C Hamano @ 2011-11-21 7:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
> ...
> Here you are. As you can see from my commit message, IMO, this is
> a very useful accident. Therefore, there is no 'test_expect_failure'
> in the test script :-)
Heh.
If this is a feature, we would like a patch to Documentation/gitignore.txt
as well, I think. Also I have a suspicion that this was an unintended
"regression"; do you have a bisection?
^ permalink raw reply
* Re: [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Philip Oakley @ 2011-11-21 7:45 UTC (permalink / raw)
To: Johannes Sixt, Junio C Hamano; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <4EC9FC81.3080306@viscovery.net>
From: "Johannes Sixt" <j.sixt@viscovery.net>
> From: Johannes Sixt <j6t@kdbg.org>
>
> It is an unintended accident that entries matched by .git/info/exclude are
> considered precious, but entries matched by .gitignore are not. That is,
> 'git checkout' will overwrite untracked files matched by .gitignore, but
> refuses to overwrite files matched by .git/info/exclude.
>
> It is a lucky accident: it allows the distinction between "untracked but
> precious" and "untracked and garbage". And it is a doubly lucky accident:
> .gitignore entries are meant for files like build products, which usually
> affect all consumers of a repository, whereas .git/info/exclude is
> intended for personal files, which frequently are precious (think of a
> TODO file).
>
> Add a test that codifies the accident as wanted behavior.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> Am 11/21/2011 4:36, schrieb Junio C Hamano:
>> As far as I am aware, info/exclude should work exactly the same as having
>> a .gitignore file at the root level of the working tree. Can you show a
>> minimum reproduction recipe in a form of a patch to our test scripts in
>> t/
>> hierarchy?
>
> Here you are. As you can see from my commit message, IMO, this is
> a very useful accident. Therefore, there is no 'test_expect_failure'
> in the test script :-)
Shouldn't there be some documentation changes to support this very useful
feature. By documenting the existing code functionality we get the double
benefit of no code changes and we publish the existance of a desired bit of
functionality.
Philip
>
> -- Hannes
>
> t/t2023-checkout-ignored.sh | 51
> +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 51 insertions(+), 0 deletions(-)
> create mode 100755 t/t2023-checkout-ignored.sh
>
> diff --git a/t/t2023-checkout-ignored.sh b/t/t2023-checkout-ignored.sh
> new file mode 100755
> index 0000000..03a5a56
> --- /dev/null
> +++ b/t/t2023-checkout-ignored.sh
> @@ -0,0 +1,51 @@
> +#!/bin/sh
> +
> +test_description='checkout overwrites or preserves ignored files
> +
> +`git checkout` makes a distinction between files mentioned in
> +.gitignore and .git/info/exclude in that untracked files matched
> +by the latter are considered precious and are not overwritten.
> +'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> +
> + echo excluded > excluded &&
> + echo ignored > ignored &&
> + git add . &&
> + test_commit initial &&
> + git checkout -b side &&
> + git rm excluded &&
> + git mv ignored .gitignore &&
> + test_commit side &&
> + echo excluded >> .git/info/exclude
> +'
> +
> +test_expect_success 'files are ignored' '
> +
> + echo keep > excluded &&
> + echo overwrite > ignored &&
> + list=$(git ls-files --others --exclude-standard) &&
> + test -z "$list"
> +'
> +
> +test_expect_success 'entries in .git/info/exclude are precious' '
> +
> + test_must_fail git checkout master 2>errors &&
> + test_i18ngrep "would be overwritten" errors &&
> + grep " excluded" errors &&
> + ! grep " ignored" errors &&
> + grep keep excluded &&
> + grep overwrite ignored
> +'
> +
> +test_expect_success 'entries in .gitignore are not precious' '
> +
> + rm -f excluded &&
> + git checkout master &&
> + grep excluded excluded &&
> + grep ignored ignored
> +'
> +
> +test_done
> --
> 1.7.8.rc0.126.gd15506
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1872 / Virus Database: 2092/4628 - Release Date: 11/20/11
>
^ permalink raw reply
* [PATCH] Add test that checkout does not overwrite entries in .git/info/exclude
From: Johannes Sixt @ 2011-11-21 7:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Taylor Hedberg, Bertrand BENOIT, git
In-Reply-To: <7vzkfqgn91.fsf@alter.siamese.dyndns.org>
From: Johannes Sixt <j6t@kdbg.org>
It is an unintended accident that entries matched by .git/info/exclude are
considered precious, but entries matched by .gitignore are not. That is,
'git checkout' will overwrite untracked files matched by .gitignore, but
refuses to overwrite files matched by .git/info/exclude.
It is a lucky accident: it allows the distinction between "untracked but
precious" and "untracked and garbage". And it is a doubly lucky accident:
.gitignore entries are meant for files like build products, which usually
affect all consumers of a repository, whereas .git/info/exclude is
intended for personal files, which frequently are precious (think of a
TODO file).
Add a test that codifies the accident as wanted behavior.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Am 11/21/2011 4:36, schrieb Junio C Hamano:
> As far as I am aware, info/exclude should work exactly the same as having
> a .gitignore file at the root level of the working tree. Can you show a
> minimum reproduction recipe in a form of a patch to our test scripts in t/
> hierarchy?
Here you are. As you can see from my commit message, IMO, this is
a very useful accident. Therefore, there is no 'test_expect_failure'
in the test script :-)
-- Hannes
t/t2023-checkout-ignored.sh | 51 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
create mode 100755 t/t2023-checkout-ignored.sh
diff --git a/t/t2023-checkout-ignored.sh b/t/t2023-checkout-ignored.sh
new file mode 100755
index 0000000..03a5a56
--- /dev/null
+++ b/t/t2023-checkout-ignored.sh
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+test_description='checkout overwrites or preserves ignored files
+
+`git checkout` makes a distinction between files mentioned in
+.gitignore and .git/info/exclude in that untracked files matched
+by the latter are considered precious and are not overwritten.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo excluded > excluded &&
+ echo ignored > ignored &&
+ git add . &&
+ test_commit initial &&
+ git checkout -b side &&
+ git rm excluded &&
+ git mv ignored .gitignore &&
+ test_commit side &&
+ echo excluded >> .git/info/exclude
+'
+
+test_expect_success 'files are ignored' '
+
+ echo keep > excluded &&
+ echo overwrite > ignored &&
+ list=$(git ls-files --others --exclude-standard) &&
+ test -z "$list"
+'
+
+test_expect_success 'entries in .git/info/exclude are precious' '
+
+ test_must_fail git checkout master 2>errors &&
+ test_i18ngrep "would be overwritten" errors &&
+ grep " excluded" errors &&
+ ! grep " ignored" errors &&
+ grep keep excluded &&
+ grep overwrite ignored
+'
+
+test_expect_success 'entries in .gitignore are not precious' '
+
+ rm -f excluded &&
+ git checkout master &&
+ grep excluded excluded &&
+ grep ignored ignored
+'
+
+test_done
--
1.7.8.rc0.126.gd15506
^ permalink raw reply related
* Re: Switch from svn to git and modify repo completely
From: Jonathan Nieder @ 2011-11-21 7:02 UTC (permalink / raw)
To: Matthias Fechner; +Cc: git, Alexey Shumkin
In-Reply-To: <4EC97D52.1010308@fechner.net>
(re-populating cc list)
Hi Matthias,
Matthias Fechner wrote:
> git told me:
> Ref 'refs/heads/master' was rewritten
> Ref 'refs/remotes/origin/master' was rewritten
> WARNING: Ref 'refs/remotes/origin/master' is unchanged
>
> 3. I cloned the repository with:
> git clone --no-hardlinks repo-orig.git repo-filtered.git
>
> 4. After this I verified in the repo-filtered.git that the file was
> really completely removed, but it was not the case.
The section "CHECKLIST FOR SHRINKING A REPOSITORY" from the
git-filter-branch(1) manual page has some hints. In particular, "git
clone --no-hardlinks" still _copies_ all objects --- you probably
would want "git clone file://$(pwd)/repo-orig" to make sure the
ordinary transfer negotiation kicks in.
It's very important that the documentation not be misleading, so if
you can point to places where the wording can be less confusing, that
would be very welcome.
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* Re: Bug report - local (and git ignored) file silently removed after checkout
From: Junio C Hamano @ 2011-11-21 3:36 UTC (permalink / raw)
To: Taylor Hedberg; +Cc: Bertrand BENOIT, git
In-Reply-To: <20111120221930.GF14902@foodlogiq3-xp-d620.thebe.ath.cx>
Taylor Hedberg <tmhedberg@gmail.com> writes:
> Junio C Hamano, Sun 2011-11-20 @ 13:16:27-0800:
>> We do not have "not tracked, but precious (e.g. your TODO)" category;
>> from time to time we have discussed possibilities of adding such to
>> enrich the categorization, but nobody stepped up to actually do the
>> work of designing let alone coding such a beast.
>
> If I'm not mistaken, files ignored by .git/info/exclude rather than
> .gitignore do exhibit this behavior.
As far as I am aware, info/exclude should work exactly the same as having
a .gitignore file at the root level of the working tree. Can you show a
minimum reproduction recipe in a form of a patch to our test scripts in t/
hierarchy?
^ permalink raw reply
* Re: [PATCH 2/3] config.c: Fix a static buffer overwrite bug by avoiding mkpath()
From: Junio C Hamano @ 2011-11-21 3:32 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4EC80688.609@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> In order to fix the problem, we replace the call to mkpath() with
> a call to mksnpath() and provide our own buffer.
A longer term fix might be to get rid of unwanted git_config_* call from
stat() callchain, but as a short-term fix, this patch with minor tweaks
should do.
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
> config.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/config.c b/config.c
> index edf9914..5a9ca84 100644
> --- a/config.c
> +++ b/config.c
> @@ -851,6 +851,7 @@ int git_config_system(void)
>
> int git_config_early(config_fn_t fn, void *data, const char *repo_config)
> {
> + char buf[4096];
> int ret = 0, found = 0;
> const char *home = NULL;
Two points. (1) This buffer does not need to be inside the whole function
scope, no? (2) s/4096/PATH_MAX/ to match what get_pathname() has been
returning to the caller?
That is, something like the attached squashed in?
> @@ -865,12 +866,11 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)
>
> home = getenv("HOME");
> if (home) {
> - char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
> + char *user_config = mksnpath(buf, sizeof(buf), "%s/.gitconfig", home);
> if (!access(user_config, R_OK)) {
> ret += git_config_from_file(fn, user_config, data);
> found += 1;
> }
> - free(user_config);
> }
>
> if (repo_config && !access(repo_config, R_OK)) {
config.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.c b/config.c
index 5a9ca84..b6d789a 100644
--- a/config.c
+++ b/config.c
@@ -851,7 +851,6 @@ int git_config_system(void)
int git_config_early(config_fn_t fn, void *data, const char *repo_config)
{
- char buf[4096];
int ret = 0, found = 0;
const char *home = NULL;
@@ -866,6 +865,7 @@ int git_config_early(config_fn_t fn, void *data, const char *repo_config)
home = getenv("HOME");
if (home) {
+ char buf[PATH_MAX];
char *user_config = mksnpath(buf, sizeof(buf), "%s/.gitconfig", home);
if (!access(user_config, R_OK)) {
ret += git_config_from_file(fn, user_config, data);
^ permalink raw reply related
* Re: [PATCH 1/3] t5501-*.sh: Fix url passed to clone in setup test
From: Junio C Hamano @ 2011-11-21 3:24 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4EC805CE.10203@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> In particular, the url passed to git-clone has an extra '/' given
> after the 'file://' schema prefix, thus:
>
> git clone --reference=original "file:///$(pwd)/original one
>
> Once the prefix is removed, the remainder of the url looks something
> like "//home/ramsay/git/t/...", which is then interpreted as an
> network path. This then results in a "Permission denied" error, like
> so:
>
> ramsay $ ls //home
> ls: cannot access //home: No such host or network path
> ramsay $ ls //home/ramsay
> ls: cannot access //home/ramsay: Permission denied
> ramsay $
>
> In order to fix the problem, we simply remove the extraneous '/'
> character from the url.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
Thanks; obviously correct.
> t/t5501-fetch-push-alternates.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t5501-fetch-push-alternates.sh b/t/t5501-fetch-push-alternates.sh
> index b5ced84..1bc57ac 100755
> --- a/t/t5501-fetch-push-alternates.sh
> +++ b/t/t5501-fetch-push-alternates.sh
> @@ -28,7 +28,7 @@ test_expect_success setup '
> done
> ) &&
> (
> - git clone --reference=original "file:///$(pwd)/original" one &&
> + git clone --reference=original "file://$(pwd)/original" one &&
> cd one &&
> echo Z >count &&
> git add count &&
^ permalink raw reply
* Re: Switch from svn to git and modify repo completely
From: Matthias Fechner @ 2011-11-20 22:21 UTC (permalink / raw)
To: git
In-Reply-To: <20111119225048.384189bc@zappedws>
Am 19.11.2011 19:50, schrieb Alexey Shumkin:
> take a look at "git filter-branch"
thanks a lot for your answer. I checked the manual page, but it does not
work like I expected it or it is described. What I did:
1. I searched the path name with the command:
git show --pretty="format:" --name-only firstrev..endrev | sort | uniq
|grep sdcc
2. I tried to remove the file with the command:
git filter-branch -f --tree-filter 'rm -f
software/tools/net.sourceforge.eclipsesdcc-1.0.0-win32.x86.zip'
--prune-empty -- --all
git told me:
Ref 'refs/heads/master' was rewritten
Ref 'refs/remotes/origin/master' was rewritten
WARNING: Ref 'refs/remotes/origin/master' is unchanged
3. I cloned the repository with:
git clone --no-hardlinks repo-orig.git repo-filtered.git
4. After this I verified in the repo-filtered.git that the file was
really completely removed, but it was not the case. I was able to
checkout the revision which holds the file.
Regarding the manual page it should work... but reality is different.
Has here anyone an idea what I did wrong?
Bye
Matthias
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook
^ permalink raw reply
* Re: Bug report - local (and git ignored) file silently removed after checkout
From: Taylor Hedberg @ 2011-11-20 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bertrand BENOIT, git
In-Reply-To: <7vehx2ijf8.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 624 bytes --]
Junio C Hamano, Sun 2011-11-20 @ 13:16:27-0800:
> We do not have "not tracked, but precious (e.g. your TODO)" category;
> from time to time we have discussed possibilities of adding such to
> enrich the categorization, but nobody stepped up to actually do the
> work of designing let alone coding such a beast.
If I'm not mistaken, files ignored by .git/info/exclude rather than
.gitignore do exhibit this behavior. That is, Git will refuse a checkout
with an error message if it would overwrite a path listed in that file.
I don't know if that's actually intended behavior, but I've noticed it
before and made use of it.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Bug report - local (and git ignored) file silently removed after checkout
From: Junio C Hamano @ 2011-11-20 21:16 UTC (permalink / raw)
To: Bertrand BENOIT; +Cc: git
In-Reply-To: <CAPRVejcpAZrLWCeHTZJr9Uk6_z6hTPQLLd6pCOKteYnRGMQ5ig@mail.gmail.com>
Bertrand BENOIT <projettwk@users.sourceforge.net> writes:
> Context:
> - in previous version of my project, the TODO file was versioned
> - in current development version, this file is NO more versioned AND
> it is ignored by a gitignore rule,...
What you observed is expected with all the versions of Git since the
gitignore mechanism was introduced. The ignored files are "not tracked,
are cruft that can be removed to make room if it is necessary for checking
out a tracked version, and would not want to track (e.g. build artifacts
like '*.o')" (I am not saying that it is the most sane semantics, I am
just stating the fact).
We do not have "not tracked, but precious (e.g. your TODO)" category; from
time to time we have discussed possibilities of adding such to enrich the
categorization, but nobody stepped up to actually do the work of designing
let alone coding such a beast.
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 1/2] MSVC: Do not close stdout to prevent a crash
From: Junio C Hamano @ 2011-11-20 21:10 UTC (permalink / raw)
To: Johannes Sixt
Cc: Andreas Schwab, Vincent van Ravesteijn, git, msysgit, kusmabite,
Johannes.Schindelin
In-Reply-To: <4EC8C7FE.5050903@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> But in the description of fclose() there is also:
>
> After the call to fclose(), any use of stream results in undefined
> behavior.
>
> And we do call fclose(stdout) in cmd_format_patch.
Yeah; this means the "in case builtin implementation is too lazy to clean
up after themselves, run_builtin() will clean things up for them" approach
taken by 0f15731 (Check for IO errors after running a command, 2007-06-24)
fundamentally does not work, which is a bit sad.
^ permalink raw reply
* Bug report - local (and git ignored) file silently removed after checkout
From: Bertrand BENOIT @ 2011-11-20 13:42 UTC (permalink / raw)
To: git
Hi,
In a (special ?) situation, I've lost a local (and git ignored) file
silently, and I've failed to get it back.
Context:
- in previous version of my project, the TODO file was versioned
- in current development version, this file is NO more versioned AND
it is ignored by a gitignore rule, but still at the same place for
better ease of access -> such a way, this file has been locally
updated several times
- during worflow process, I've finally performed a checkout on a
previous version (in which the TODO file was versioned) -> after that
the file has been silently updated with the old version
- after modification, I've performed back a checkout on the current
version and this time my TODO file has been fully and silently removed
Questions:
- is it a behavior regarded as normal ?
- is there any way to get back the TODO file, in LOCAL version it
was before the first checkout ?
- in any case, is there any way to be warned (and to make the
checkout fail) of such situation (local ignored file being overwritten
with 'older' not-ignored version) ?
Thx,
Best regards,
TWK
^ permalink raw reply
* [PATCH 3/3] revert: improve error message for cherry-pick during cherry-pick
From: Jonathan Nieder @ 2011-11-20 9:51 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord
In-Reply-To: <20111120094650.GB2278@elie.hsd1.il.comcast.net>
In the spirit of v1.6.3.3~3^2 (refuse to merge during a merge,
2009-07-01), "git cherry-pick" refuses to start a new cherry-pick when
in the middle of an existing conflicted cherry-pick in the following
sequence:
1. git cherry-pick HEAD..origin
2. resolve conflicts
3. git cherry-pick HEAD..origin (instead of "git cherry-pick
--continue", by mistake)
Good. However, the error message on attempting step 3 is more
convoluted than necessary:
$ git cherry-pick HEAD..origin
error: .git/sequencer already exists.
error: A cherry-pick or revert is in progress.
hint: Use --continue to continue the operation
hint: or --quit to forget about it
fatal: cherry-pick failed
Clarify by removing the double redundant first "error:" message,
simplifying the advice, and using lower-case and no full stops to be
consistent with other commands that prefix their messages with
"error:", so it becomes
error: a cherry-pick or revert is already in progress
hint: try "git cherry-pick (--continue | --quit)"
fatal: cherry-pick failed
The "fatal: cherry-pick failed" line seems unnecessary, too, but
that can be fixed some other day.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
That's the end of the series. There are more error messages, but
let's start with this one.
Thanks for reading.
builtin/revert.c | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index dd072ce6..9db4c1e4 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -843,8 +843,11 @@ static int create_seq_dir(void)
{
const char *seq_dir = git_path(SEQ_DIR);
- if (file_exists(seq_dir))
- return error(_("%s already exists."), seq_dir);
+ if (file_exists(seq_dir)) {
+ error(_("a cherry-pick or revert is already in progress"));
+ advise(_("try \"git cherry-pick (--continue | --quit)\""));
+ return -1;
+ }
else if (mkdir(seq_dir, 0777) < 0)
die_errno(_("Could not create sequencer directory %s"), seq_dir);
return 0;
@@ -988,12 +991,8 @@ static int pick_revisions(struct replay_opts *opts)
*/
walk_revs_populate_todo(&todo_list, opts);
- if (create_seq_dir() < 0) {
- error(_("A cherry-pick or revert is in progress."));
- advise(_("Use --continue to continue the operation"));
- advise(_("or --quit to forget about it"));
+ if (create_seq_dir() < 0)
return -1;
- }
if (get_sha1("HEAD", sha1)) {
if (opts->action == REVERT)
return error(_("Can't revert as initial commit"));
--
1.7.8.rc3
^ permalink raw reply related
* [PATCH 2/3] revert: rearrange pick_revisions() for clarity
From: Jonathan Nieder @ 2011-11-20 9:50 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord
In-Reply-To: <20111120094650.GB2278@elie.hsd1.il.comcast.net>
Deal completely with "cherry-pick --quit" and --continue at the
beginning of pick_revisions(), leaving the rest of the function for
the more interesting "git cherry-pick <commits>" case.
No functional change intended. The impact is just to unindent the
code a little.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
This also paves the way to factoring out the REPLAY_CONTINUE case
into a separate function.
builtin/revert.c | 48 ++++++++++++++++++++++++------------------------
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/builtin/revert.c b/builtin/revert.c
index b59dd68c..dd072ce6 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -968,40 +968,40 @@ static int pick_revisions(struct replay_opts *opts)
if (opts->subcommand == REPLAY_REMOVE_STATE) {
remove_sequencer_state(1);
return 0;
- } else if (opts->subcommand == REPLAY_CONTINUE) {
+ }
+ if (opts->subcommand == REPLAY_CONTINUE) {
if (!file_exists(git_path(SEQ_TODO_FILE)))
- goto error;
+ return error(_("No %s in progress"), action_name(opts));
read_populate_opts(&opts);
read_populate_todo(&todo_list, opts);
/* Verify that the conflict has been resolved */
if (!index_differs_from("HEAD", 0))
todo_list = todo_list->next;
- } else {
- /*
- * Start a new cherry-pick/ revert sequence; but
- * first, make sure that an existing one isn't in
- * progress
- */
+ return pick_commits(todo_list, opts);
+ }
+
+ /*
+ * Start a new cherry-pick/ revert sequence; but
+ * first, make sure that an existing one isn't in
+ * progress
+ */
- walk_revs_populate_todo(&todo_list, opts);
- if (create_seq_dir() < 0) {
- error(_("A cherry-pick or revert is in progress."));
- advise(_("Use --continue to continue the operation"));
- advise(_("or --quit to forget about it"));
- return -1;
- }
- if (get_sha1("HEAD", sha1)) {
- if (opts->action == REVERT)
- return error(_("Can't revert as initial commit"));
- return error(_("Can't cherry-pick into empty head"));
- }
- save_head(sha1_to_hex(sha1));
- save_opts(opts);
+ walk_revs_populate_todo(&todo_list, opts);
+ if (create_seq_dir() < 0) {
+ error(_("A cherry-pick or revert is in progress."));
+ advise(_("Use --continue to continue the operation"));
+ advise(_("or --quit to forget about it"));
+ return -1;
+ }
+ if (get_sha1("HEAD", sha1)) {
+ if (opts->action == REVERT)
+ return error(_("Can't revert as initial commit"));
+ return error(_("Can't cherry-pick into empty head"));
}
+ save_head(sha1_to_hex(sha1));
+ save_opts(opts);
return pick_commits(todo_list, opts);
-error:
- return error(_("No %s in progress"), action_name(opts));
}
int cmd_revert(int argc, const char **argv, const char *prefix)
--
1.7.8.rc3
^ permalink raw reply related
* [PATCH 1/3] revert: rename --reset option to --quit
From: Jonathan Nieder @ 2011-11-20 9:48 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: git, Christian Couder, Martin von Zweigbergk, Phil Hord
In-Reply-To: <20111120094650.GB2278@elie.hsd1.il.comcast.net>
The option to "git cherry-pick" and "git revert" to discard the
sequencer state introduced by v1.7.8-rc0~141^2~6 (revert: Introduce
--reset to remove sequencer state, 2011-08-04) has a confusing name.
Change it now, while we still have the time.
Mechanics:
This commit removes the "git cherry-pick --reset" option. Hopefully
nobody was using it. If somebody was, we can add it back again as a
synonym.
The new name for "cherry-pick, please get out of my way, since I've
long forgotten about the sequence of commits I was cherry-picking when
you wrote that old .git/sequencer directory" is --quit. Mnemonic:
this is analagous to quiting a program the user is no longer using ---
we just want to get out of the multiple-command cherry-pick procedure
and not to reset HEAD or restore any other old state.
Adjust documentation and tests to match. While at it, let's clarify
the short descriptions of these operations in "-h" output.
Before:
--reset forget the current operation
--continue continue the current operation
After:
--quit end revert or cherry-pick sequence
--continue resume revert or cherry-pick sequence
Noticed-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-cherry-pick.txt | 2 +-
Documentation/git-revert.txt | 2 +-
Documentation/sequencer.txt | 10 +++++-----
builtin/revert.c | 22 +++++++++++-----------
sequencer.h | 2 +-
t/t3510-cherry-pick-sequence.sh | 10 +++++-----
t/t7106-reset-sequence.sh | 2 +-
7 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 2660a842..21998b82 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] <commit>...
-'git cherry-pick' --reset
'git cherry-pick' --continue
+'git cherry-pick' --quit
DESCRIPTION
-----------
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index f3519413..b0fcabc8 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -9,8 +9,8 @@ SYNOPSIS
--------
[verse]
'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>...
-'git revert' --reset
'git revert' --continue
+'git revert' --quit
DESCRIPTION
-----------
diff --git a/Documentation/sequencer.txt b/Documentation/sequencer.txt
index 3e6df338..75f8e869 100644
--- a/Documentation/sequencer.txt
+++ b/Documentation/sequencer.txt
@@ -1,9 +1,9 @@
---reset::
- Forget about the current operation in progress. Can be used
- to clear the sequencer state after a failed cherry-pick or
- revert.
-
--continue::
Continue the operation in progress using the information in
'.git/sequencer'. Can be used to continue after resolving
conflicts in a failed cherry-pick or revert.
+
+--quit::
+ Forget about the current operation in progress. Can be used
+ to clear the sequencer state after a failed cherry-pick or
+ revert.
diff --git a/builtin/revert.c b/builtin/revert.c
index 544e8c30..b59dd68c 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -40,7 +40,7 @@ static const char * const cherry_pick_usage[] = {
};
enum replay_action { REVERT, CHERRY_PICK };
-enum replay_subcommand { REPLAY_NONE, REPLAY_RESET, REPLAY_CONTINUE };
+enum replay_subcommand { REPLAY_NONE, REPLAY_REMOVE_STATE, REPLAY_CONTINUE };
struct replay_opts {
enum replay_action action;
@@ -133,11 +133,11 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
{
const char * const * usage_str = revert_or_cherry_pick_usage(opts);
const char *me = action_name(opts);
- int reset = 0;
+ int remove_state = 0;
int contin = 0;
struct option options[] = {
- OPT_BOOLEAN(0, "reset", &reset, "forget the current operation"),
- OPT_BOOLEAN(0, "continue", &contin, "continue the current operation"),
+ OPT_BOOLEAN(0, "quit", &remove_state, "end revert or cherry-pick sequence"),
+ OPT_BOOLEAN(0, "continue", &contin, "resume revert or cherry-pick sequence"),
OPT_BOOLEAN('n', "no-commit", &opts->no_commit, "don't automatically commit"),
OPT_BOOLEAN('e', "edit", &opts->edit, "edit the commit message"),
OPT_NOOP_NOARG('r', NULL),
@@ -168,13 +168,13 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
/* Check for incompatible subcommands */
verify_opt_mutually_compatible(me,
- "--reset", reset,
+ "--quit", remove_state,
"--continue", contin,
NULL);
/* Set the subcommand */
- if (reset)
- opts->subcommand = REPLAY_RESET;
+ if (remove_state)
+ opts->subcommand = REPLAY_REMOVE_STATE;
else if (contin)
opts->subcommand = REPLAY_CONTINUE;
else
@@ -183,8 +183,8 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts)
/* Check for incompatible command line arguments */
if (opts->subcommand != REPLAY_NONE) {
char *this_operation;
- if (opts->subcommand == REPLAY_RESET)
- this_operation = "--reset";
+ if (opts->subcommand == REPLAY_REMOVE_STATE)
+ this_operation = "--quit";
else
this_operation = "--continue";
@@ -965,7 +965,7 @@ static int pick_revisions(struct replay_opts *opts)
* cherry-pick should be handled differently from an existing
* one that is being continued
*/
- if (opts->subcommand == REPLAY_RESET) {
+ if (opts->subcommand == REPLAY_REMOVE_STATE) {
remove_sequencer_state(1);
return 0;
} else if (opts->subcommand == REPLAY_CONTINUE) {
@@ -988,7 +988,7 @@ static int pick_revisions(struct replay_opts *opts)
if (create_seq_dir() < 0) {
error(_("A cherry-pick or revert is in progress."));
advise(_("Use --continue to continue the operation"));
- advise(_("or --reset to forget about it"));
+ advise(_("or --quit to forget about it"));
return -1;
}
if (get_sha1("HEAD", sha1)) {
diff --git a/sequencer.h b/sequencer.h
index 905d2950..f435fdb4 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -13,7 +13,7 @@
*
* With the aggressive flag, it additionally removes SEQ_OLD_DIR,
* ignoring any errors. Inteded to be used by the sequencer's
- * '--reset' subcommand.
+ * '--quit' subcommand.
*/
void remove_sequencer_state(int aggressive);
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index 3bca2b3d..913435e2 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick-sequence.sh
@@ -13,7 +13,7 @@ test_description='Test cherry-pick continuation features
. ./test-lib.sh
pristine_detach () {
- git cherry-pick --reset &&
+ git cherry-pick --quit &&
git checkout -f "$1^0" &&
git read-tree -u --reset HEAD &&
git clean -d -f -f -q -x
@@ -70,15 +70,15 @@ test_expect_success 'cherry-pick cleans up sequencer state upon success' '
test_path_is_missing .git/sequencer
'
-test_expect_success '--reset does not complain when no cherry-pick is in progress' '
+test_expect_success '--quit does not complain when no cherry-pick is in progress' '
pristine_detach initial &&
- git cherry-pick --reset
+ git cherry-pick --quit
'
-test_expect_success '--reset cleans up sequencer state' '
+test_expect_success '--quit cleans up sequencer state' '
pristine_detach initial &&
test_must_fail git cherry-pick base..picked &&
- git cherry-pick --reset &&
+ git cherry-pick --quit &&
test_path_is_missing .git/sequencer
'
diff --git a/t/t7106-reset-sequence.sh b/t/t7106-reset-sequence.sh
index 4956caaf..3f86e8c5 100755
--- a/t/t7106-reset-sequence.sh
+++ b/t/t7106-reset-sequence.sh
@@ -12,7 +12,7 @@ test_description='Test interaction of reset --hard with sequencer
. ./test-lib.sh
pristine_detach () {
- git cherry-pick --reset &&
+ git cherry-pick --quit &&
git checkout -f "$1^0" &&
git read-tree -u --reset HEAD &&
git clean -d -f -f -q -x
--
1.7.8.rc3
^ 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