* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Andrew Ardill @ 2012-12-17 8:53 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Chris Rorvick, git@vger.kernel.org,
Tomas Carnecky, Woody Wu
In-Reply-To: <50CED5D4.5040705@viscovery.net>
Regards,
Andrew Ardill
On 17 December 2012 19:20, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 12/17/2012 8:21, schrieb Junio C Hamano:
>> Chris Rorvick <chris@rorvick.com> writes:
>>> 'git checkout' [<branch>]::
>
> Is <branch> really optional in this form?
>
> BTW, what does plain 'git checkout' do? Just report ahead/behind information?
I think it defaults to either HEAD or the current branch, which shows
uncommitted changes and relationship to upstream.
>>> +
>>> + Update the index, working tree, and HEAD to reflect the
>>> + specified branch.
> ...
>>> +'git checkout' [--detach] [<commit>]::
>
> The title here is better spelled as two lines:
>
> 'git checkout' <commit>::
> 'git checkout' --detach <branch>::
>
> I don't think that <commit> or <branch> should be indicated as optional here.
doing 'git checkout --detach' will detach from the current branch if
you have one, but maybe listing <branch> as optional would work in
that case?
Here is my suggestion, differing from what Junio put forward primarily
by first indicating that a checkout is a 'switch' to a different
branch or commit. This makes sense to me, and is used elsewhere in the
documentation, so I thought it might make sense here too.
-->8--
From: Andrew Ardill <andrew.ardill@gmail.com>
Date: Mon, 17 Dec 2012 18:53:41 +1100
Subject: [PATCH] Documentation/git-checkout.txt: Use consistent terminology
git checkout is described as 'switching' branches in places. Use this
terminology more consistently.
Expand on the purpose of switching to a branch or commit, which is
typically to prepare to build history on top of that branch or commit.
Signed-off-by: Andrew Ardill <andrew.ardill@gmail.com>
---
Documentation/git-checkout.txt | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index db89cf7..e6db14f 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -23,8 +23,11 @@ branch.
'git checkout' [<branch>]::
- Update the index, working tree, and HEAD to reflect the
- specified branch.
+ Switch to the specified <branch>. Prepares for building new
+ history on <branch>, by updating the index and the files in the
+ working tree, and by pointing HEAD at the branch. Local
+ modifications to the files in the working tree are kept, so that
+ they can be committed on the <branch>.
+
If <branch> is not found but there does exist a tracking branch in
exactly one remote (call it <remote>) with a matching name, treat as
@@ -56,10 +59,13 @@ successful.
'git checkout' [--detach] [<commit>]::
- Update the index and working tree to reflect the specified
- commit and set HEAD to point directly to <commit> (see
- "DETACHED HEAD" section.) Passing `--detach` forces this
- behavior even if <commit> is a branch.
+ Switch to the specified <commit>. Prepares for building new
+ history on top of <commit>, by updating the index and the files
+ in the working tree, and by pointing HEAD at <commit>. Local
+ modifications to the files in the working tree are kept, so that
+ they can be committed on top of <commit>. Passing `--detach`
+ forces HEAD to point directly at <commit> even if <commit> is a
+ branch (see "DETACHED HEAD" section.)
'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
--
^ permalink raw reply related
* Re: [BUG] Cannot push some grafted branches
From: Junio C Hamano @ 2012-12-17 8:56 UTC (permalink / raw)
To: Yann Dirson; +Cc: git list
In-Reply-To: <20121217085242.02a77243@chalon.bertin.fr>
Yann Dirson <dirson@bertin.fr> writes:
> And we may still want the bug fixed, or would we just list it as a known bug ?
> At least it does not seem to occur with "replace" refs:
The "replace" was designed to "fix" known limitation of grafts,
which is _inherent_ to it; the graft information was designed _not_
to be shared across repositories. The fix was done by by using a
different mechanism to allow propagating the information across
repositories.
So there is nothing further to fix, except that there is a documentation
bug you can fix if you didn't find it documented.
Thanks.
>
> git-test$ rm .git/info/grafts
> git-test$ echo "fake merge" | git commit-tree master^{tree} -p master^ -p maint
> b821b2aa00973a47936d7cd25c9a5978b1c839c6
> git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
> git-test$ git push origin maint
> ...
> 50b03b0..79211fe maint -> maint
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Johannes Sixt @ 2012-12-17 8:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Chris Rorvick, git, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <7vk3shm5d5.fsf@alter.siamese.dyndns.org>
Am 12/17/2012 9:48, schrieb Junio C Hamano:
> Here is what I tentatively have ...
Thanks!
> -'git checkout' [--detach] [<commit>]::
> +'git checkout' --detach [<commit>]::
> +'git checkout' <commit>::
>
> - Update the index and working tree to reflect the specified
> - commit and set HEAD to point directly to <commit> (see
> - "DETACHED HEAD" section.) Passing `--detach` forces this
> - behavior even if <commit> is a branch.
> + Prepare to work on building new history on top of <commit>,
> + by detaching HEAD at the commit (see "DETACHED HEAD"
> + section), and updating the index and the files in the
> + working tree. Local modifications to the files in the
> + working tree are kept, so that they can be committed on the
> + <branch>.
The last half-sentence should better be removed.
> ++
> +Passing `--detach` forces this behavior even if <commit> is a branch.
>
> 'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
-- Hannes
^ permalink raw reply
* git log reliability
From: Prasad Karmarkar @ 2012-12-17 9:26 UTC (permalink / raw)
To: git
Hi ,
I have been hearing from my Release Management that git log is not
reliable. Is it so ?
Is there a known instance where Git log has missed out on commits ?
Any information about this would be really helpful
Regards,
Prasad
^ permalink raw reply
* Re: git log reliability
From: Tomas Carnecky @ 2012-12-17 9:38 UTC (permalink / raw)
To: Prasad Karmarkar, git
In-Reply-To: <CANirugRmpoGb=T1V2ZBw3GEE5nYwD-hyLOfWgt-UVvMXh-i_OA@mail.gmail.com>
On Mon, 17 Dec 2012 14:56:17 +0530, Prasad Karmarkar <prasad.s.karmarkar@gmail.com> wrote:
> Hi ,
>
> I have been hearing from my Release Management that git log is not
> reliable. Is it so ?
> Is there a known instance where Git log has missed out on commits ?
>
> Any information about this would be really helpful
Are you talking about git skipping commits due to history simplification (read
the corresponding section in the git-log man page)?
Also, what for does your release management use git log? Maybe there is
a better way to do what you need to do.
^ permalink raw reply
* Aw: Re: [PATCH] Move api-command.txt to the end of API list in api-index.txt
From: Thomas Ackermann @ 2012-12-17 9:43 UTC (permalink / raw)
To: gitster, th.acker; +Cc: git
In-Reply-To: <7vwqwhpy0a.fsf@alter.siamese.dyndns.org>
OK; I would also prefer to have it in ./howto.
So please drop this patch; I will provide a new one.
----- Original Nachricht ----
Von: Junio C Hamano <gitster@pobox.com>
An: Thomas Ackermann <th.acker@arcor.de>
Datum: 16.12.2012 21:01
Betreff: Re: [PATCH] Move api-command.txt to the end of API list in
api-index.txt
> Thomas Ackermann <th.acker@arcor.de> writes:
>
> > - because it describes a different form of API than the other api-*
> documents
>
> It makes me wonder if a more correct "fix" is to move this document
> to the ../howto/ hierarchy.
>
---
Thomas
^ permalink raw reply
* Re: [PATCH] Documentation: don't link to example mail addresses
From: John Keeping @ 2012-12-17 9:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vobhtnt57.fsf@alter.siamese.dyndns.org>
On Sun, Dec 16, 2012 at 09:29:24PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>> Here `<name>` is the person's display name (for example
>> ``Com M Itter'') and `<email>` is the person's email address
>> -(``cm@example.com''). `LT` and `GT` are the literal less-than (\x3c)
>> +(``$$cm@example.com$$''). `LT` and `GT` are the literal less-than (\x3c)
>> and greater-than (\x3e) symbols. These are required to delimit
>> the email address from the other fields in the line. Note that
>> `<name>` and `<email>` are free-form and may contain any sequence
>
> AsciiDoc 8.5.2 gives this:
>
> asciidoc: WARNING: git-fast-import.txt: line 434: nested inline passthrough
>
> Also in git-fast-import.1, there is this line:
>
> ... person\(cqs display name (for example `Com M Itter\(aq\(aq) and `<ema...
>
> (notice two leftover `s); not that this is a new issue with this patch.
>
> Which is puzzling, because the next input line formats better:
>
> ... email address (\(lqcm@example\&.com\(rq)\&. ...
I wonder if you're hitting this bug, which is listed as fixed in
AsciiDoc 8.6.0 [1]:
FIXED: Sometimes multiple double quoted text elements in the same
paragraph were mistakenly seen as starting with an inline literal.
As you said in your other message, it may be better to avoid using the
pretty quotes, although I don't think just changing them to `monospace
output` is sufficient as monospace output is not distinguished in the
default man page output. IMHO that's necessary for any examples that
contain whitespace. Perhaps a patch series turning MAN_BOLD_LITERAL on
by default and then changing these examples to `monospace output`?
John
[1] http://www.methods.co.nz/asciidoc/CHANGELOG.html#_version_8_6_0_2010_08_16
^ permalink raw reply
* problem with BOINC repository and CR/LF
From: Toralf Förster @ 2012-12-17 10:23 UTC (permalink / raw)
To: git
Hello,
I'm faced with this situation :
http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
and even a "git stash" doesn't help.
Now /me wonders whether that repository is just screwed up or whether I
do have with git.1.8.0.2 at an almost stable Gentoo linux a problem.
FWIW I already played (unsuccessful) with this too:
$ grep -B 3 crlf .gitconfig
confirm = never
[core]
autocrlf = true
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-17 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vfw35m509.fsf@alter.siamese.dyndns.org>
On Mon, 17 Dec 2012 00:56:06 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Yann Dirson <dirson@bertin.fr> writes:
>
> > And we may still want the bug fixed, or would we just list it as a known bug ?
> > At least it does not seem to occur with "replace" refs:
>
> The "replace" was designed to "fix" known limitation of grafts,
> which is _inherent_ to it; the graft information was designed _not_
> to be shared across repositories. The fix was done by by using a
> different mechanism to allow propagating the information across
> repositories.
I see. But from what I observed (without looking at the source), it looks like
when determining which commits are to be pushed, the grafts file is not "neutralized"
as it should.
> So there is nothing further to fix, except that there is a documentation
> bug you can fix if you didn't find it documented.
Will do.
> Thanks.
>
> >
> > git-test$ rm .git/info/grafts
> > git-test$ echo "fake merge" | git commit-tree master^{tree} -p master^ -p maint
> > b821b2aa00973a47936d7cd25c9a5978b1c839c6
> > git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
> > git-test$ git push origin maint
> > ...
> > 50b03b0..79211fe maint -> maint
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-17 10:40 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git list
In-Reply-To: <877goht6eu.fsf@pctrast.inf.ethz.ch>
On Mon, 17 Dec 2012 09:43:53 +0100
Thomas Rast <trast@student.ethz.ch> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Yann Dirson <dirson@bertin.fr> writes:
> >
> >> .... In this respect, they seem to be
> >> lacking a few features, when compared to "replace" refs, but they have different
> >> uses, ...
> >
> > Not reallyl; grafts were old hack whose use is still supported with
> > its original limitations; replace is meant to replace all uses of
> > grafts while removing grafts' largest warts.
>
> I suppose there's the additional issue that grafts are much easier to
> use than replacements if you really only want to replace some parent
> lists. With replace you need to handcraft the replacement commits, and
> git-replace(1) unhelpfully does not say this, much less gives an example
> how to do it.
>
Right, replace refs can surely be made easier to use. The requirement to craft a
new commit manually is a major step back in ease of use.
Maybe something like "git replace -p <orig-commit> <parent>..." to just provide a simple
API to the exact graft functionnality would be good. But it would be commit-specific, whereas
replace refs are indeed more generic, and, one could want to rewrite any other part of the commit,
so we could prefer a more general mechanism.
Something that could be useful in this respect, would be an --amend like option to git-commit, like
"git commit --replace". But unfortunately it does not allow to change parents, and it has the
drawback of requiring that HEAD points to the commit to be replaced.
So maybe, if there are no other idea, a simple "git graft" command that would wrap "git replace",
would fill the gap.
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [PATCH] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-17 11:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5gxnuy1.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 17/12/2012 05:50, Junio C Hamano ha scritto:
> Manlio Perillo <manlio.perillo@gmail.com> writes:
>
>> The git-completion.bash script did not implemented full support for
>> completion, for git commands that operate on files from the current
>> working directory or the index.
>>
>> For these commands, only options completion was available.
>
> Hrm, "git mv CO<TAB>" completes it to "COPYING" for me. Same for:
>
> git rm CO<TAB>
> git clean Doc<TAB>
> git commit --edit Doc<TAB>
>
> There must be something missing from the above description, and the
> claim the above two paragraphs make does no make sense without that
> something that is missing.
>
Thanks.
What is missing is that I forgot to explain that by "completion not
supported" I meant "*git aware* completion is not supported".
If you try, as an example, "git add <TAB>", bash will suggest *all*
files in your working directory, including ignored files and files with
no modifications.
>> * the path completion for the "git mv" and "git rm" commands is provided
>> using "git ls-files --exclude-standard"
>
> Does the above mean "git mv COPYING Doc<TAB>" would complete the
> command line to move it to Documentation/ directory?
>
It will suggest all tracked files from the Documentation directory.
One important detail is that it will recurse into sub directories.
This is not the behaviour of the current completion code.
The problem is that current code use ls-tree, and works only for paths
like <rev>:<path>.
My implementation use ls-files, that has a completly different interface
from ls-tree (and since I'm very new to git, this caused be some confusion).
It seems that with ls-files it is impossible to:
* get a list of path names without recursing into sub directories.
(this is only possible for untracked directories)
* get the file mode for all "modified" or "deleted" files.
If I do "git ls-files --stage --modified", git ignores the modified
option and will list all files
> I think "using X" is of secondary importance. Reviewers and future
> developers (who are reading "git log" output) can read it from the
> patch. What is expected in the log message is why the implemenation
> was chosen, and in order to achieve what effect.
>
Ok, thanks.
>
>> * the path completion for the "git clean" command is provided using
>> "git ls-files --exclude-standard -o"
>>
>> * the path completion for the "git commit" command is provides using
>> "git diff-index --name-only HEAD"
>
> As long as all of the above stops completion at directory boundary,
> I think the above sounds like a sensible thing to do. e.g. when
> "ls-files" gives Documentation/Makefile and Documentation/git.txt,
> "git cmd Doc<TAB>" first would give "git cmd Documentation/" and
> then the second <TAB> would offer these two paths as choices. That
> way, the user can choose to just execute "git cmd Documentation/"
> without even looking at these individual paths.
>
Right, this is what bash usually do.
However I don't know how to implement this with git.
> I am not sure how you would handle the last parameter to "git mv",
> though. That is by definition a path that does not exist,
> i.e. cannot be completed.
>
Right, the code should be changed.
No completion should be done for the second parameter.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDO/zoACgkQscQJ24LbaUSD1ACfXeH2GizdNG/uzlSneEpdi1Na
6IoAni3ZrhhCMXbVoTqIVjH4mEX/XmaH
=w56v
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v2] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2012-12-17 11:29 UTC (permalink / raw)
To: git; +Cc: Zoltan Klinger
(1) Only print out the names of the files and directories that got
actually deleted.
(2) Show warning message for ignored untracked git repositories
Consider the following repo layout:
test.git/
|-- tracked_file
|-- tracked_dir/
| |-- some_tracked_file
| |-- some_untracked_file
|-- untracked_file
|-- untracked_foo/
| |-- bar/
| | |-- bar.txt
| |-- emptydir/
| |-- frotz.git/
| |-- frotz.tx
|-- untracked_some.git/
|-- some.txt
Suppose the user issues 'git clean -fd' from the test.git directory.
When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
Removing untracked_foo/
Removing untracked_some.git/
The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectories 'bar' and 'emptydir' have been
deleted but they're not mentioned anywhere. Also, untracked_some.git
has not been removed either.
This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.
Improve the way the deleted directories are reported back to
the user:
(1) Modify the recursive delete function to run in both dry_run and
delete modes.
(2) During the recursion collect the name of the files and
directories that:
(a) will be or have been removed.
(b) could not be removed due to file system permissions, etc.
(c) will be or have been ignored because they are untracked
git repositories that are not removed by default unless
the --force --force option is used.
(3) After finishing the delete process print out:
(a) the names of all deleted topmost directories and nothing
about their (recursive) contents if all content was removed
successfully
(b) the names of all files that have been deleted but their parent
directory still exists
(c) warning for all untracked git repositories that have been
ignored
(d) warning about files and directories that failed to delete.
Consider the output of the improved version:
$ git clean -fd
Removing tracked_dir/some_untracked_file
Removing untracked_file
Removing untracked_foo/bar/
Removing untracked_foo/emptydir/
warning: ignoring untracked git repository untracked_foo/frotz.git/
warning: ignoring untracked git repository untracked_some.git/
Now it displays only the file and directory names that got actually
deleted and shows warnings about ignored untracked git repositories.
Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com>
Reported-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
---
Have updated patch with feedback received from Junio and Soren Brinkmann
builtin/clean.c | 78 +++++++++++++++++++++++++++++++++++--------------------
dir.c | 65 +++++++++++++++++++++++++++++++++++++++-------
dir.h | 4 +++
3 files changed, 109 insertions(+), 38 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..4824bac 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -34,22 +34,42 @@ static int exclude_cb(const struct option *opt, const char *arg, int unset)
return 0;
}
+static void print_filtered(const char *msg, struct string_list *lst)
+{
+ int i;
+ char *name;
+ char *dir = 0;
+
+ sort_string_list(lst);
+
+ for (i = 0; i < lst->nr; i++) {
+ name = lst->items[i].string;
+ if (dir == 0 || strncmp(name, dir, strlen(dir)) != 0)
+ printf("%s %s\n", msg, name);
+ if (name[strlen(name) - 1] == '/')
+ dir = name;
+ }
+}
+
int cmd_clean(int argc, const char **argv, const char *prefix)
{
int i;
- int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
+ int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
int ignored_only = 0, config_set = 0, errors = 0;
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
struct strbuf directory = STRBUF_INIT;
struct dir_struct dir;
static const char **pathspec;
struct strbuf buf = STRBUF_INIT;
+ struct string_list dels = STRING_LIST_INIT_DUP;
+ struct string_list skips = STRING_LIST_INIT_DUP;
+ struct string_list errs = STRING_LIST_INIT_DUP;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
const char *qname;
char *seen = NULL;
struct option options[] = {
OPT__QUIET(&quiet, N_("do not print names of files removed")),
- OPT__DRY_RUN(&show_only, N_("dry run")),
+ OPT__DRY_RUN(&dry_run, N_("dry run")),
OPT__FORCE(&force, N_("force")),
OPT_BOOLEAN('d', NULL, &remove_directories,
N_("remove whole directories")),
@@ -77,7 +97,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
if (ignored && ignored_only)
die(_("-x and -X cannot be used together"));
- if (!show_only && !force) {
+ if (!dry_run && !force) {
if (config_set)
die(_("clean.requireForce set to true and neither -n nor -f given; "
"refusing to clean"));
@@ -150,43 +170,45 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
if (S_ISDIR(st.st_mode)) {
strbuf_addstr(&directory, ent->name);
qname = quote_path_relative(directory.buf, directory.len, &buf, prefix);
- if (show_only && (remove_directories ||
- (matches == MATCHED_EXACTLY))) {
- printf(_("Would remove %s\n"), qname);
- } else if (remove_directories ||
- (matches == MATCHED_EXACTLY)) {
- if (!quiet)
- printf(_("Removing %s\n"), qname);
- if (remove_dir_recursively(&directory,
- rm_flags) != 0) {
- warning(_("failed to remove %s"), qname);
- errors++;
- }
- } else if (show_only) {
- printf(_("Would not remove %s\n"), qname);
- } else {
- printf(_("Not removing %s\n"), qname);
+ if (remove_directories || (matches == MATCHED_EXACTLY)) {
+ remove_dir_recursively_with_dryrun(&directory, rm_flags, dry_run,
+ &dels, &skips, &errs, prefix);
}
strbuf_reset(&directory);
} else {
if (pathspec && !matches)
continue;
qname = quote_path_relative(ent->name, -1, &buf, prefix);
- if (show_only) {
- printf(_("Would remove %s\n"), qname);
- continue;
- } else if (!quiet) {
- printf(_("Removing %s\n"), qname);
- }
- if (unlink(ent->name) != 0) {
- warning(_("failed to remove %s"), qname);
- errors++;
+ if (dry_run)
+ string_list_append(&dels, qname);
+ else {
+ if (unlink(ent->name) != 0)
+ string_list_append(&errs, qname);
+ else
+ string_list_append(&dels, qname);
}
}
}
+
+ if (!quiet) {
+ if (dry_run) {
+ print_filtered("Would remove", &dels);
+ print_filtered("Would ignore untracked git repository", &skips);
+ } else {
+ print_filtered("Removing", &dels);
+ print_filtered("warning: ignoring untracked git repository", &skips);
+ }
+ }
+
+ errors = errs.nr;
+ if (errors)
+ print_filtered("warning: failed to remove", &errs);
+
free(seen);
strbuf_release(&directory);
+ string_list_clear(&dels, 0);
+ string_list_clear(&errs, 0);
string_list_clear(&exclude_list, 0);
return (errors != 0);
}
diff --git a/dir.c b/dir.c
index 5a83aa7..fd38d5d 100644
--- a/dir.c
+++ b/dir.c
@@ -7,7 +7,9 @@
*/
#include "cache.h"
#include "dir.h"
+#include "quote.h"
#include "refs.h"
+#include "string-list.h"
struct path_simplify {
int len;
@@ -1294,11 +1296,30 @@ int is_empty_dir(const char *path)
return ret;
}
-static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
+static void append_dir_name(struct string_list *dels, struct string_list *skips,
+ struct string_list *errs, char *name, const char * prefix, int failed, int isdir)
+{
+ struct strbuf quoted = STRBUF_INIT;
+
+ quote_path_relative(name, strlen(name), "ed, prefix);
+ if (isdir && quoted.buf[strlen(quoted.buf) -1] != '/')
+ strbuf_addch("ed, '/');
+
+ if (skips)
+ string_list_append(skips, quoted.buf);
+ else if (!failed && dels)
+ string_list_append(dels, quoted.buf);
+ else if (errs)
+ string_list_append(errs, quoted.buf);
+}
+
+static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up,
+ int dry_run, struct string_list *dels, struct string_list *skips,
+ struct string_list *errs, const char *prefix)
{
DIR *dir;
struct dirent *e;
- int ret = 0, original_len = path->len, len, kept_down = 0;
+ int ret = 0, original_len = path->len, len, kept_down = 0, res = 0;
int only_empty = (flag & REMOVE_DIR_EMPTY_ONLY);
int keep_toplevel = (flag & REMOVE_DIR_KEEP_TOPLEVEL);
unsigned char submodule_head[20];
@@ -1306,6 +1327,7 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
if ((flag & REMOVE_DIR_KEEP_NESTED_GIT) &&
!resolve_gitlink_ref(path->buf, "HEAD", submodule_head)) {
/* Do not descend and nuke a nested git work tree. */
+ append_dir_name(NULL, skips, NULL, path->buf, prefix, 0, 1);
if (kept_up)
*kept_up = 1;
return 0;
@@ -1315,8 +1337,13 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
dir = opendir(path->buf);
if (!dir) {
/* an empty dir could be removed even if it is unreadble */
- if (!keep_toplevel)
- return rmdir(path->buf);
+ if (!keep_toplevel) {
+ res = 0;
+ if (!dry_run)
+ res = rmdir(path->buf);
+ append_dir_name(dels, NULL, errs, path->buf, prefix, res, 1);
+ return res;
+ }
else
return -1;
}
@@ -1334,10 +1361,17 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
if (lstat(path->buf, &st))
; /* fall thru */
else if (S_ISDIR(st.st_mode)) {
- if (!remove_dir_recurse(path, flag, &kept_down))
+ if (!remove_dir_recurse(path, flag, &kept_down, dry_run, dels,
+ skips, errs, prefix))
continue; /* happy */
- } else if (!only_empty && !unlink(path->buf))
- continue; /* happy, too */
+ } else if (!only_empty) {
+ res = 0;
+ if (!dry_run)
+ res = unlink(path->buf);
+ append_dir_name(dels, NULL, errs, path->buf, prefix, res, 0);
+ if (!res)
+ continue; /* happy, too */
+ }
/* path too long, stat fails, or non-directory still exists */
ret = -1;
@@ -1346,8 +1380,12 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
closedir(dir);
strbuf_setlen(path, original_len);
- if (!ret && !keep_toplevel && !kept_down)
- ret = rmdir(path->buf);
+ if (!ret && !keep_toplevel && !kept_down) {
+ ret = 0;
+ if (!dry_run)
+ ret = rmdir(path->buf);
+ append_dir_name(dels, NULL, errs, path->buf, prefix, res, 1);
+ }
else if (kept_up)
/*
* report the uplevel that it is not an error that we
@@ -1359,7 +1397,14 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
int remove_dir_recursively(struct strbuf *path, int flag)
{
- return remove_dir_recurse(path, flag, NULL);
+ return remove_dir_recurse(path, flag, NULL, 0, NULL, NULL, NULL, NULL);
+}
+
+int remove_dir_recursively_with_dryrun(struct strbuf *path, int flag,
+ int dry_run, struct string_list *dels, struct string_list *skips,
+ struct string_list *errs, const char *prefix)
+{
+ return remove_dir_recurse(path, flag, NULL, dry_run, dels, skips, errs, prefix);
}
void setup_standard_excludes(struct dir_struct *dir)
diff --git a/dir.h b/dir.h
index f5c89e3..780885a 100644
--- a/dir.h
+++ b/dir.h
@@ -131,6 +131,10 @@ extern void setup_standard_excludes(struct dir_struct *dir);
#define REMOVE_DIR_KEEP_NESTED_GIT 02
#define REMOVE_DIR_KEEP_TOPLEVEL 04
extern int remove_dir_recursively(struct strbuf *path, int flag);
+extern int remove_dir_recursively_with_dryrun(struct strbuf *path,
+ int flag, int dryrun, struct string_list *dels,
+ struct string_list *skips, struct string_list *errs,
+ const char *prefix);
/* tries to remove the path with empty directories along it, ignores ENOENT */
extern int remove_path(const char *path);
--
1.7.9.5
^ permalink raw reply related
* Git Log and History Simplification
From: Dinesh Subramani @ 2012-12-17 11:33 UTC (permalink / raw)
To: git
I am using the below command :
git log --stat --decorate=full --since=<date>
Can you please let me know if the above command will list all the
commits and would not skip any of the commits due to History
Simplification. Any help would be very useful.
Regards,
Dinesh
^ permalink raw reply
* RFC: "git config -l" should not expose sensitive information
From: Toralf Förster @ 2012-12-17 11:35 UTC (permalink / raw)
To: git
often the output is requested in help forums - and a
"git config -l | wgetpaste" exposes parameters like sendmail.smtppass -
so hide those variables in the output (if not explicitly wanted) would
makes sense, or ?
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Andrew Ardill @ 2012-12-17 11:38 UTC (permalink / raw)
To: Toralf Förster; +Cc: git@vger.kernel.org
In-Reply-To: <50CEF289.4040503@gmx.de>
On 17 December 2012 21:23, Toralf Förster <toralf.foerster@gmx.de> wrote:
> Hello,
>
> I'm faced with this situation :
> http://lists.ssl.berkeley.edu/mailman/private/boinc_alpha/2012-December/017371.html
> and even a "git stash" doesn't help.
Hi Toralf,
That list is private and not visible without an account. Can you
transcribe the relevant parts?
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH] log --format: teach %C(auto,black) to paint it black only on terminals
From: Nguyen Thai Ngoc Duy @ 2012-12-17 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Srb, Michal, Jeff King
In-Reply-To: <7vobhtm5pk.fsf_-_@alter.siamese.dyndns.org>
On Mon, Dec 17, 2012 at 3:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Traditionally, %C(color attr) always emitted the ANSI color
> sequence; it was up to the scripts that wanted to conditionally
> color their output to omit %C(...) specifier when they do not want
> colors.
>
> Optionally allow "auto," to be prefixed to the color, so that the
> output is colored iff it goes to the terminal.
I see "prefix" is clearly documented. Still it feels a bit unnatural
that %C(red,auto) won't work. But we can make that case work later if
somebody cares enough.
> if (!end)
> return 0;
> - color_parse_mem(placeholder + 2,
> - end - (placeholder + 2),
> + if (!memcmp(begin, "auto,", 5)) {
> + if (!want_color(-1))
> + return end - placeholder + 1;
This want_color() checks color.ui and only when color.ui = auto, it
bothers to check if the output is tty. I think the document should say
that "auto," (or maybe another name because it's not really auto)
respects color.ui.
--
Duy
^ permalink raw reply
* Re: Git Log and History Simplification
From: Nguyen Thai Ngoc Duy @ 2012-12-17 11:49 UTC (permalink / raw)
To: Dinesh Subramani; +Cc: git
In-Reply-To: <CAE116wxTY0sFh5nZwGEYRz=gJwXgFEj8Nvwh41RCYH4vgYCqSQ@mail.gmail.com>
On Mon, Dec 17, 2012 at 6:33 PM, Dinesh Subramani
<dinesh.subramani@gmail.com> wrote:
> I am using the below command :
>
> git log --stat --decorate=full --since=<date>
>
> Can you please let me know if the above command will list all the
> commits and would not skip any of the commits due to History
> Simplification. Any help would be very useful.
If my memory is still functioning, history simplification only takes
place when you specify pathspec. The above command does not have
pathspec, so no history simplification.
--
Duy
^ permalink raw reply
* Re: [PATCH v2] Documentation: don't link to example mail addresses
From: Jeff King @ 2012-12-17 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Keeping, git
In-Reply-To: <7vehippg91.fsf@alter.siamese.dyndns.org>
On Sun, Dec 16, 2012 at 06:24:58PM -0800, Junio C Hamano wrote:
> I seem to be getting
>
> (<tt>`\cm@example.com''). `LT</tt> and <tt>GT</tt> are the literal less-than (\x3c)
>
> out of this part in the resulting HTML output, which is probably not
> what you wanted to see.
>
> I have a feeling that it might be a better solution to stop using
> these pretty quotes. It's not like we use them a lot and a quick
> scanning of "git grep '``'" output seems to tell me that many of
> them should be `monospace output`, and the rest (mostly references
> to section headers) can be "Section".
Typographically speaking, I would also be just as happy to use regular
double-quotes throughout. But here's an example where they also caused
a problem (which was fixed by moving to smart-quotes in f34e9ed):
http://thread.gmane.org/gmane.comp.version-control.git/163067
-Peff
^ permalink raw reply
* Re: [PATCH] log --format: teach %C(auto,black) to paint it black only on terminals
From: Jeff King @ 2012-12-17 12:13 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git@vger.kernel.org, Srb, Michal
In-Reply-To: <CACsJy8Dt4vEpO+EcAhWnko=XAajQ9OMgbDbVx78Eb=sZTjmKQA@mail.gmail.com>
On Mon, Dec 17, 2012 at 06:44:10PM +0700, Nguyen Thai Ngoc Duy wrote:
> > if (!end)
> > return 0;
> > - color_parse_mem(placeholder + 2,
> > - end - (placeholder + 2),
> > + if (!memcmp(begin, "auto,", 5)) {
> > + if (!want_color(-1))
> > + return end - placeholder + 1;
>
> This want_color() checks color.ui and only when color.ui = auto, it
> bothers to check if the output is tty. I think the document should say
> that "auto," (or maybe another name because it's not really auto)
> respects color.ui.
Yeah, that should definitely be documented. I wonder if it should
actually respect color.diff, which is what "log" usually uses (albeit
mostly for the diff itself, we have always used it for the graph and for
the "commit" header of each entry).
-Peff
^ permalink raw reply
* Re: Git Log and History Simplification
From: Tomas Carnecky @ 2012-12-17 12:34 UTC (permalink / raw)
To: Dinesh Subramani, git
In-Reply-To: <CAE116wxTY0sFh5nZwGEYRz=gJwXgFEj8Nvwh41RCYH4vgYCqSQ@mail.gmail.com>
On Mon, 17 Dec 2012 17:03:09 +0530, Dinesh Subramani <dinesh.subramani@gmail.com> wrote:
> I am using the below command :
>
> git log --stat --decorate=full --since=<date>
>
> Can you please let me know if the above command will list all the
> commits and would not skip any of the commits due to History
> Simplification. Any help would be very useful.
The way I understand the man page, to disable history simplification you have
to use --full-history --sparse.
^ permalink raw reply
* Re: [PATCH] log --format: teach %C(auto,black) to paint it black only on terminals
From: Jeff King @ 2012-12-17 12:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Nguyen Thai Ngoc Duy, Srb, Michal
In-Reply-To: <7vobhtm5pk.fsf_-_@alter.siamese.dyndns.org>
On Mon, Dec 17, 2012 at 12:40:55AM -0800, Junio C Hamano wrote:
> +# %C(auto,...) should trump --color=always
> +#
> +# NEEDSWORK: --color=never should also be tested but we need to run a
> +# similar test under pseudo-terminal with test_terminal which is too
> +# much hassle for its worth.
> +
> +test_format advanced-colors-forced \
> + '%C(auto,red yellow bold)foo%C(auto,reset)' --color=always <<'EOF'
> +commit 131a310eb913d107dd3c09a65d1651175898735d
> +foo
> +commit 86c75cfd708a0e5868dc876ed5b8bb66c80b4873
> +foo
> +EOF
Hmm. I would have expected this to output colors. In other words, for
"auto" to work just like the config-respecting colorization that is
built into git.
Yes, in this toy example, one could always just drop the "auto" when
using --color=always. But part of the point of this is that I could do:
git config pretty.fake-oneline "%C(auto,yellow)%h%C(auto,reset) %s"
and have it behave like "--oneline", no matter what the user has in
their color.ui config or --color option on the command line.
I think the patch below (on top of yours) does the right thing by
copying the color option from the rev_info diff options into the
pretty-print context, which is the same place that the graph and
log-tree code look. That means you'll get consistent colorization
(either all or nothing) with:
git log --graph -p --format='%C(auto,blue)%s%C(auto,reset)'
no matter what your setting of color.diff, color.ui, or --color on the
command line.
It also means that pretty-print defaults to "no colors, do not even
check stdout" when people initialize it to all-zeroes. That's probably a
good thing, as it means any callers of format_commit_message have to
consciously opt into allowing colorization in their format messages.
diff --git a/commit.h b/commit.h
index b6ad8f3..0f469e5 100644
--- a/commit.h
+++ b/commit.h
@@ -89,6 +89,7 @@ struct pretty_print_context {
char *notes_message;
struct reflog_walk_info *reflog_info;
const char *output_encoding;
+ int color;
};
struct userformat_want {
diff --git a/log-tree.c b/log-tree.c
index 4f86def..8876c73 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -671,6 +671,7 @@ void show_log(struct rev_info *opt)
ctx.preserve_subject = opt->preserve_subject;
ctx.reflog_info = opt->reflog_info;
ctx.fmt = opt->commit_format;
+ ctx.color = opt->diffopt.use_color;
pretty_print_commit(&ctx, commit, &msgbuf);
if (opt->add_signoff)
diff --git a/pretty.c b/pretty.c
index 9e51fec..e6a2886 100644
--- a/pretty.c
+++ b/pretty.c
@@ -967,7 +967,7 @@ static size_t format_commit_one(struct strbuf *sb, const char *placeholder,
if (!end)
return 0;
if (!memcmp(begin, "auto,", 5)) {
- if (!want_color(-1))
+ if (!want_color(c->pretty_ctx->color))
return end - placeholder + 1;
begin += 5;
}
^ permalink raw reply related
* Re: [BUG] Cannot push some grafted branches
From: Christian Couder @ 2012-12-17 13:43 UTC (permalink / raw)
To: Yann Dirson; +Cc: Thomas Rast, Junio C Hamano, git list
In-Reply-To: <20121217114058.449cbc3c@chalon.bertin.fr>
Hi Yann,
On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson <dirson@bertin.fr> wrote:
> On Mon, 17 Dec 2012 09:43:53 +0100
> Thomas Rast <trast@student.ethz.ch> wrote:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>
>> I suppose there's the additional issue that grafts are much easier to
>> use than replacements if you really only want to replace some parent
>> lists. With replace you need to handcraft the replacement commits, and
>> git-replace(1) unhelpfully does not say this, much less gives an example
>> how to do it.
>>
>
> Right, replace refs can surely be made easier to use. The requirement to craft a
> new commit manually is a major step back in ease of use.
Yeah, at one point I wanted to have a command that created to craft a
new commit based on an existing one.
Perhaps it could be useful when using filter-branch or perhaps it
could reuse some filter-branch code.
> Maybe something like "git replace -p <orig-commit> <parent>..." to just provide a simple
> API to the exact graft functionnality would be good. But it would be commit-specific, whereas
> replace refs are indeed more generic, and, one could want to rewrite any other part of the commit,
> so we could prefer a more general mechanism.
Yeah I wondered at one point if something like the following would do:
git replace --parent <parent1> --parent <parent2> --author <author>
--commiter <commiter> ... <orig-commit>
> Something that could be useful in this respect, would be an --amend like option to git-commit, like
> "git commit --replace". But unfortunately it does not allow to change parents, and it has the
> drawback of requiring that HEAD points to the commit to be replaced.
>
> So maybe, if there are no other idea, a simple "git graft" command that would wrap "git replace",
> would fill the gap.
It would not be straightforward to call it "graft" if it uses git replace.
Best,
Christian.
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Yann Dirson @ 2012-12-17 14:02 UTC (permalink / raw)
To: Christian Couder; +Cc: Thomas Rast, Junio C Hamano, git list
In-Reply-To: <CAP8UFD2pkotNy=t5wTxDH-pMivQsTz-kw2y8Y7rWY42YKabp7g@mail.gmail.com>
On Mon, 17 Dec 2012 14:43:59 +0100
Christian Couder <christian.couder@gmail.com> wrote:
> Hi Yann,
>
> On Mon, Dec 17, 2012 at 11:40 AM, Yann Dirson <dirson@bertin.fr> wrote:
> > On Mon, 17 Dec 2012 09:43:53 +0100
> > Thomas Rast <trast@student.ethz.ch> wrote:
> >
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>
> >>
> >> I suppose there's the additional issue that grafts are much easier to
> >> use than replacements if you really only want to replace some parent
> >> lists. With replace you need to handcraft the replacement commits, and
> >> git-replace(1) unhelpfully does not say this, much less gives an example
> >> how to do it.
> >>
> >
> > Right, replace refs can surely be made easier to use. The requirement to craft a
> > new commit manually is a major step back in ease of use.
>
> Yeah, at one point I wanted to have a command that created to craft a
> new commit based on an existing one.
> Perhaps it could be useful when using filter-branch or perhaps it
> could reuse some filter-branch code.
>
> > Maybe something like "git replace -p <orig-commit> <parent>..." to just provide a simple
> > API to the exact graft functionnality would be good. But it would be commit-specific, whereas
> > replace refs are indeed more generic, and, one could want to rewrite any other part of the commit,
> > so we could prefer a more general mechanism.
>
> Yeah I wondered at one point if something like the following would do:
>
> git replace --parent <parent1> --parent <parent2> --author <author>
> --commiter <commiter> ... <orig-commit>
Yes, modification flags, that would only be allowed when the objects are commits,
and would cause creation of a replace commit that's <orig-commit> plus modifications.
We could then reuse the relevant options from git-commit, and add the missing --parent.
But wouldn't it stretch git-replace too much, to add commit-specific behaviour there ?
> > Something that could be useful in this respect, would be an --amend like option to git-commit, like
> > "git commit --replace". But unfortunately it does not allow to change parents, and it has the
> > drawback of requiring that HEAD points to the commit to be replaced.
> >
> > So maybe, if there are no other idea, a simple "git graft" command that would wrap "git replace",
> > would fill the gap.
>
> It would not be straightforward to call it "graft" if it uses git replace.
Well, "git replace" would just be the "implementation detail". The idea would be to keep
the concept of a "graft", and just change its implementation. If we care (and we surely
do not, it's just a thought experiment ;), we could even provide, for pre-replace gits, a
"git graft" implementation that would manipulate info/grafts, together with a docpatch
saying that direct manipulation of info/grafts is deprecated.
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: ASoC updates for v3.8
From: Mark Brown @ 2012-12-17 14:25 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel, Liam Girdwood, git
In-Reply-To: <s5hy5gwwz1d.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Mon, Dec 17, 2012 at 03:09:34PM +0100, Takashi Iwai wrote:
> At Mon, 17 Dec 2012 22:14:10 +0900,
> Mark Brown wrote:
> >
> > The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
> >
> > Linux 3.7 (2012-12-10 19:30:57 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
> No signed tag?
Oh, ffs. There's a tag asoc-3.8p1 which should have been there for days
but git's doing it's usual thing and silently substituting in a branch
for a tag. This is monumentally unhelpful, especially since it doesn't
even print a warning but rather just silently substitutes.
You can tell there's a signed tag from the way the message from the tag
is included in the pull request.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: ASoC updates for v3.8
From: Takashi Iwai @ 2012-12-17 14:45 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, Liam Girdwood, git
In-Reply-To: <20121217142500.GG4985@opensource.wolfsonmicro.com>
At Mon, 17 Dec 2012 14:25:00 +0000,
Mark Brown wrote:
>
> On Mon, Dec 17, 2012 at 03:09:34PM +0100, Takashi Iwai wrote:
> > At Mon, 17 Dec 2012 22:14:10 +0900,
> > Mark Brown wrote:
> > >
> > > The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
> > >
> > > Linux 3.7 (2012-12-10 19:30:57 -0800)
> > >
> > > are available in the git repository at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
>
> > No signed tag?
>
> Oh, ffs. There's a tag asoc-3.8p1 which should have been there for days
> but git's doing it's usual thing and silently substituting in a branch
> for a tag. This is monumentally unhelpful, especially since it doesn't
> even print a warning but rather just silently substitutes.
Yeah, this too kind feature bites me often.
> You can tell there's a signed tag from the way the message from the tag
> is included in the pull request.
Yes, I expected that, but not I wasn't sure which tag to take.
I thought you use tags/asoc-3.8, and I tried it, but this time it
isn't.
In anyway, pulled now. Thanks.
Takashi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox