* Re: [PATCH] t3070: Disable some failing fnmatch tests
From: Ramsay Jones @ 2012-12-17 22:05 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <CACsJy8DOhZjm05KVQYaR+HbQAu=wDNR=+NZ7H_hG8P5ZsNzSKg@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On Sun, Dec 16, 2012 at 2:19 AM, Ramsay Jones
> <ramsay@ramsay1.demon.co.uk> wrote:
>>
>> The failing tests make use of a POSIX character class, '[:xdigit:]'
>> in this case, which some versions of the fnmatch() library function
>> do not support. In the spirit of commit f1cf7b79 ("t3070: disable
>> unreliable fnmatch tests", 15-10-2012), we disable the fnmatch() half
>> of these tests.
>
> I have no problem with this. You're on cygwin, right?
My main platform is Linux, but I also like to keep cygwin working.
(... and I also build MinGW just for fun!)
Yes, it was cygwin that suffered these test failures. (MinGW is built
with NO_FNMATCH=YesPlease.)
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 1/1] tests: Allow customization of how say_color() prints
From: Ramsay Jones @ 2012-12-17 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7vobhuqzdc.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index f50f834..9dcf3c1 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -202,6 +202,15 @@ do
>> esac
>> done
>>
>> +if test -z "$GIT_TEST_PRINT"
>> +then
>> + GIT_TEST_PRINT="printf %s"
>> +fi
>> +if test -z "$GIT_TEST_PRINT_LN"
>> +then
>> + GIT_TEST_PRINT_LN="printf %s\n"
>> +fi
>> +
>> if test -n "$color"
>> then
>> say_color () {
>> @@ -221,7 +230,7 @@ then
>> test -n "$quiet" && return;;
>> esac
>> shift
>> - printf "%s" "$*"
>> + $GIT_TEST_PRINT "$*"
>> tput sgr0
>> echo
>> )
>> @@ -230,7 +239,7 @@ else
>> say_color() {
>> test -z "$1" && test -n "$quiet" && return
>> shift
>> - printf "%s\n" "$*"
>> + $GIT_TEST_PRINT_LN "$*"
>> }
>> fi
>
> As you said, this is ugly and also unwieldy in that I do not see an
> easy way for a platform/builder to define something that needs to
> pass a parameter with $IFS in it in these two variables.
Yes, I spent 10 minutes trying to decide if I should send this patch
at all ... (ie how much public humiliation could I take :-D )
> Why does your printf die in the first place???
I really don't know. I'm not sure I will ever know. A couple of years
ago, when I was trying to debug the (harmless) "--color" spew, I found
(via google, etc) numerous accounts of similar problems, with various
workarounds for specific problems. One such account claimed that the
cause of the problem was an official "fix" from Microsoft (as part of
a service pack) which worked just fine on Windows Vista (and later) but
had this known side-effect on XP. Since it fixed the problem it was
intended to fix, even on XP, and the unfortunate "side-effect" on XP
should be quite rare, they decided to apply it on XP anyway. :(
Hmm, on reflection, it would probably be best if you just drop this patch.
I can keep it locally and apply it on top of any branch I want to test.
(Actually, it would be easier to simply revert commit 7bc0911d.)
Sorry for wasting your time.
ATB,
Ramsay Jones
^ permalink raw reply
* Acknowledgements
From: Alessandro Rossini @ 2012-12-17 21:35 UTC (permalink / raw)
To: git
Dear all,
You may like to know that I acknowledged the Git community in my PhD thesis (Preface, last paragraph):
http://alessandrorossini.org/2011/12/08/the-last-four-years-of-my-life/
Keep up the good work!
Best regards,
Alessandro Rossini
http://alessandrorossini.org
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Junio C Hamano @ 2012-12-17 21:59 UTC (permalink / raw)
To: Andrew Ardill
Cc: Philip Oakley, Chris Rorvick, Git List, Tomas Carnecky, Woody Wu
In-Reply-To: <CAH5451nVe1VcD3VzCO7EtKSkzv9CyJs=uqQ9MkMTJEXMTwEvmw@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> Even if the primary purpose of "git checkout <branch>" is to "check
> out the branch so that further work is done on that branch", I don't
> believe that means it has to be stated first. In fact, I would say
> that there are enough other use cases that the language should be
> slightly more use-case agnostic in the first situation. For example,
> someone might switch to another branch or commit simply to see what
> state the tree was in at that point.
I've been deliberately avoiding the term "switch", actually. I
agree that it may be familiar to people with prior exposure to
subversion, but that is not the primary audience of the manual.
> Some people use checkout to
> deploy a tag of the working tree onto a production server. The first
> example in particular is, I think, a common enough operation that
> restricting the opening lines of documentation to talking about
> building further work is misleading.
I agree with you that sightseeing use case where you do not intend
to make any commit is also important. That is exactly why I said
"further work is done on that branch" not "to that branch" in the
message you are responding to.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Andrew Ardill @ 2012-12-17 21:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Philip Oakley, Chris Rorvick, Git List, Tomas Carnecky, Woody Wu
In-Reply-To: <7v1ueol6ut.fsf@alter.siamese.dyndns.org>
On 18 December 2012 08:13, Junio C Hamano <gitster@pobox.com> wrote:
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com> Sent: Monday, December 17,
>>> This is to "check out the branch" ;-)
>>> ...
>>
>> From a user perspective it's better to refer to the working directory
>> first rather than the internal mechanics.
>>
>> Prepare to work on <branch>, by updating the files in the
>> working tree and index to the branch's previous content, and
>> pointing HEAD to it.
>
> I agree that the mention of "pointing HEAD to" may be better to be
> rephrased in the user facing terms.
>
> Because the primary purpose of "git checkout <branch>" is to "check
> out the branch so that further work is done on that branch", that
> aspect of the behaviour should be mentioned first. Updating of the
> working tree files and the index is the implemenation detail of
> starting to work on that branch.
Even if the primary purpose of "git checkout <branch>" is to "check
out the branch so that further work is done on that branch", I don't
believe that means it has to be stated first. In fact, I would say
that there are enough other use cases that the language should be
slightly more use-case agnostic in the first situation. For example,
someone might switch to another branch or commit simply to see what
state the tree was in at that point. Some people use checkout to
deploy a tag of the working tree onto a production server. The first
example in particular is, I think, a common enough operation that
restricting the opening lines of documentation to talking about
building further work is misleading.
My earlier submission dealt with this by using the 'Switch to the
specified ...' terminology. For me this is implicitly stating 'Switch
the state of the repository to be the same as the specified ...' but
perhaps it would do to be more explicit? I prefer the shorter form
myself.
By following this with the typical use case it makes it clear what the
intended use of the command is, and some idea about the mechanics of
its function.
I realised that my signature was improperly placed when I submitted my
suggestion last, so I will include it here as reference for anyone who
skipped over it. It builds on top of the two original patches.
Regards,
Andrew Ardill
-->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: [PATCH v2] git-clean: Display more accurate delete messages
From: Junio C Hamano @ 2012-12-17 21:40 UTC (permalink / raw)
To: Zoltan Klinger; +Cc: git
In-Reply-To: <1355743765-17549-1-git-send-email-zoltan.klinger@gmail.com>
Zoltan Klinger <zoltan.klinger@gmail.com> writes:
> +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;
> + }
> +}
Here, prefixcmp() may be easier to read than strncmp(). We tend to
prefer writing comparison with zero like this:
if (!dir || prefixcmp(name, dir))
...
but I think we can go either way.
My reading of the above is that "lst" after sorting is expected to
have something like:
a/
a/b/
a/b/to-be-removed
a/to-be-removed
and we first show "a/", remember that prefix in "dir", not show
"a/b/" because it matches prefix, but still update the prefix to
"a/b/", not show "a/b/to-be-removed", and because "a/to-be-removed"
does not match the latest prefix, it is now shown. Am I confused???
> @@ -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);
> }
Moving the above logic to a single helper function makes sense, but
can we name it a bit more concisely? Also this helper feels very
specific to "clean"---does it need to go to dir.[ch], I have to
wonder.
Other than the above two points, the resulting builtin/clean.c looks
much more nicely structured than before.
I am not very much pleased by the change to dir.[ch] in this patch,
though.
> +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);
> +}
The three lists dels/skips/errs are mostly mutually exclusive (the
caller knows which one to throw the element in) except that failed
controls which one between dels or errs is used.
That's an ugly interface, I have to say. I think the quote-path
part should become a separate helper function to be used by the
callers of this function, and the callers should stuff the path to
the list they want to put the element in. That will eliminate the
need for this ugliness.
Also, didn't you make remove_dir_recursively() excessively leaky by
doing this? The string in quoted is still created, even though the
caller passes NULL to all the lists.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2012, #04; Sun, 16)
From: Matt Kraai @ 2012-12-17 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
> It could turn out that we may be able to get rid of sys/param.h
> altogether, but one step at a time. Inputs from people on minority
> platforms are very much appreciated---does your platform build fine
> when the inclusion of the file is removed from git-compat-util.h?
QNX builds fine when sys/param.h is not included.
--
Matt Kraai
https://ftbfs.org/kraai
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Junio C Hamano @ 2012-12-17 21:14 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Christian Couder, Yann Dirson, Thomas Rast, git list
In-Reply-To: <m21ueo78f8.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> Yeah, at one point I wanted to have a command that created to craft a
>> new commit based on an existing one.
>
> This isn't hard to do, you only have to resort to plumbing:
>
> $ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/ | git hash-object -t commit --stdin -w
> bb45cc6356eac6c7fa432965090045306dab7026
Good. I do not think an extra special-purpose command is welcome
here.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Junio C Hamano @ 2012-12-17 21:13 UTC (permalink / raw)
To: Philip Oakley
Cc: Chris Rorvick, Git List, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <17103971665F4C4495C6C96086A58B8F@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> From: "Junio C Hamano" <gitster@pobox.com> Sent: Monday, December 17,
>> This is to "check out the branch" ;-)
>> ...
>
> From a user perspective it's better to refer to the working directory
> first rather than the internal mechanics.
>
> Prepare to work on <branch>, by updating the files in the
> working tree and index to the branch's previous content, and
> pointing HEAD to it.
I agree that the mention of "pointing HEAD to" may be better to be
rephrased in the user facing terms.
Because the primary purpose of "git checkout <branch>" is to "check
out the branch so that further work is done on that branch", that
aspect of the behaviour should be mentioned first. Updating of the
working tree files and the index is the implemenation detail of
starting to work on that branch.
So your suggestion is going backwards, I'd have to say.
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Philip Oakley @ 2012-12-17 20:51 UTC (permalink / raw)
To: Junio C Hamano, Chris Rorvick
Cc: Git List, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <7vhanlnnz7.fsf@alter.siamese.dyndns.org>
From: "Junio C Hamano" <gitster@pobox.com> Sent: Monday, December 17,
2012 7:21 AM
> Chris Rorvick <chris@rorvick.com> writes:
>
>> The forms of checkout that do not take a path are lumped together in
>> the
>> DESCRIPTION section, but the description for this group is dominated
>> by
>> explanation of the -b|-B form. Split these apart for more clarity.
>>
>> Signed-off-by: Chris Rorvick <chris@rorvick.com>
>> ---
>> Documentation/git-checkout.txt | 26 +++++++++++++++++---------
>> 1 file changed, 17 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/git-checkout.txt
>> b/Documentation/git-checkout.txt
>> index 7958a47..a47555c 100644
>> --- a/Documentation/git-checkout.txt
>> +++ b/Documentation/git-checkout.txt
>> @@ -22,17 +22,18 @@ also update `HEAD` to set the specified branch as
>> the current
>> branch.
>>
>> 'git checkout' [<branch>]::
>> +
>> + Update the index, working tree, and HEAD to reflect the
>> + specified branch.
>
> This is to "check out the branch" ;-)
>
> But of course, we cannot define "checkout" in terms of "checkout",
> so we need to phrase it without saying "checkout" and explain what
> it *means* to check out the branch.
>
> I am not sure "Reflect" is a good word. Making the result similar
> to the branch is only one aspect of the act of checking out the
> branch. The other equally important aspect is that this is done to
> advance the history of the branch.
>
> Perhaps...
>
> Prepare to work on building new history on <branch>, by
> pointing the HEAD to the branch 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>.
>From a user perspective it's better to refer to the working directory
first rather than the internal mechanics. Perhaps:
Prepare to work on <branch>, by updating the files in the
working tree and index to the branch's previous content, and
pointing HEAD to it.
Local modifications to the files in the working tree are kept,
so that they can be committed on the <branch>.
>
>> 'git checkout' -b|-B <new_branch> [<start point>]::
>>
>> + Specifying `-b` causes a new branch to be created as if
>> + linkgit:git-branch[1] were called and then checked out. In
>> + this case you can use the `--track` or `--no-track` options,
>> + which will be passed to 'git branch'. As a convenience,
>> + `--track` without `-b` implies branch creation; see the
>> + description of `--track` below.
>> +
>> If `-B` is given, <new_branch> is created if it doesn't exist;
>> otherwise, it
>> is reset. This is the transactional equivalent of
>> @@ -45,6 +46,13 @@ $ git checkout <branch>
>> that is to say, the branch is not reset/created unless "git
>> checkout" is
>> 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.
>
> Prepare to work on building new history on top of <commit>,
> by detaching HEAD at the commit and ...(likewise)...
^ permalink raw reply
* Re: Submodule not updated automatically on merge conflict
From: Heiko Voigt @ 2012-12-17 20:41 UTC (permalink / raw)
To: ?A???Y; +Cc: git, Jens Lehmann
In-Reply-To: <CAHtLG6S28bhkAuypy-YgYY9wOWTH+Mp9g-CWmM_aDf7=dpKXZw@mail.gmail.com>
Hi,
On Thu, Dec 13, 2012 at 01:46:43PM +0800, ?A???Y wrote:
> If there are merge conflict files, then changed submodules are not
> updated automatically.
> Why not submodules?
> Files do try to merge / update.
This is work in progress, currently you still have to use submodule
update to get them in sync with the tracked sha1. BTW, I would not expect
merge to update any submodules but let them stay at the tip of the
branch you are merging in. Or which side would you expect to get checked
out?
Cheers Heiko
^ permalink raw reply
* Re: [PATCH] git-completion.bash: update obsolete code.
From: Junio C Hamano @ 2012-12-17 20:29 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50CF4E05.7050103@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
> By the way, IMHO there should be an option for adding a slash to
> directory names in ls-tree.
I am not sure about that; ls-tree is meant to be used by scripts
that are capable of doing that kind of thing themselves.
If we were to add an option to add a slash, I think it should be
modeled after "ls -F", whose output is meant for humans and no sane
scripts would read from it. It is very likely that such an option
should add @ at the end of the name for a symbolic link, so it won't
be useful for your patch.
^ permalink raw reply
* Re: [PATCH 0/2] second try
From: Junio C Hamano @ 2012-12-17 20:08 UTC (permalink / raw)
To: Sven Strickroth; +Cc: git, Jeff King, Jakub Narebski, Eric Wong
In-Reply-To: <50CF4020.4090901@tu-clausthal.de>
Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
> Am 26.11.2012 05:50 schrieb Junio C Hamano:
>> I think between Peff and me it fell in the cracks during the
>> hand-off; I do not know about the others, probably people did not
>> find it interesting perhaps?
>>
>> I'll add Eric Wong (git-svn submaintainer) to Cc.
>
> I received no feedback, so is there any progress on this issue?
I took a look at it, and from the code-cleanness point of view, I
think it loos more or less right, even though I'd prefer to see the
"fall back on SSH_ASKPASS" bit as a separate patch, either before or
after [1/2] that moves the logic to a separate helper function.
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Andreas Schwab @ 2012-12-17 20:03 UTC (permalink / raw)
To: Christian Couder; +Cc: Yann Dirson, Thomas Rast, Junio C Hamano, git list
In-Reply-To: <CAP8UFD2pkotNy=t5wTxDH-pMivQsTz-kw2y8Y7rWY42YKabp7g@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> Yeah, at one point I wanted to have a command that created to craft a
> new commit based on an existing one.
This isn't hard to do, you only have to resort to plumbing:
$ git cat-file commit fef11965da875c105c40f1a9550af1f5e34a6e62 | sed s/bfae342c973b0be3c9e99d3d86ed2e6b152b4a6b/790c83cda92f95f1b4b91e2ddc056a52a99a055d/ | git hash-object -t commit --stdin -w
bb45cc6356eac6c7fa432965090045306dab7026
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] log --format: teach %C(auto,black) to paint it black only on terminals
From: Junio C Hamano @ 2012-12-17 20:03 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, git@vger.kernel.org, Srb, Michal
In-Reply-To: <20121217194926.GA5209@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If "git frotz" wants to have a separate "color.frotz" option to override
> that, then they would need to implement that themselves either with or
> without your patch. I do not think its presence makes things any harder.
That _was_ (but no longer is) exactly my point. Eh, rather, its
absense does not make things any harder.
> So no, I do not think you can cover every conceivable case. But having
> git-log respect --color and the usual color.* variables for this feature
> seems like the only sane default. It makes the easy cases just work, and
> the hard cases are not any worse off (and they may even be better off,
> since the script can manipulate --color instead of rewriting their
> format strings, but that is a minor difference).
OK, care to reroll the one with your patch in the other message
squashed in, possibly with fixes to the test (the result should now
honor --color={always,never}, I think)?
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Documentation: don't link to example mail addresses
From: Junio C Hamano @ 2012-12-17 19:57 UTC (permalink / raw)
To: Jeff King; +Cc: John Keeping, git
In-Reply-To: <20121217120253.GA21858@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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
I agree with the typography argument.
Many monospaced fonts used in the windows where the programmers view
the source of the docmentation, a 'normal' single quote does not
slant by the same amount to the `opposite` quote, so ``a pair does
not balance'' visually in the source. And the whole point of
writing documentation in AsciiDoc is to keep the source readable.
The use of pretty quote throws discards that primary benefit of
choosing AsciiDoc in the first place.
^ permalink raw reply
* Re: Git Log and History Simplification
From: Junio C Hamano @ 2012-12-17 19:53 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Dinesh Subramani, git
In-Reply-To: <CACsJy8BsL03zr_wGZH5kqS0NaMfPKct2T7_62jstxRB4c_FudQ@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 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.
Think of the pathspec limiting as asking to choose commits by one
criteria (i.e. touches paths in a way that matters in the result),
like any other commit limiting criteria like "--grep" (i.e. asks to
choose commits that has the given string in its message).
With something like --author or --grep, we would need to look at
each individual commmit to decide if it matches the criteria. With
pathspec, when we look at a single-parent commit, we inspect it to
decide if it matches the criteria of touching the specified paths.
When we are looking at a merge commit, however, if one of the
parents match the result at all the paths that match the given
pathspec, we know any and all commits on the other side branches do
not matter in the result, hence we can omit them by not even having
to follow that parent ancestry.
If you mention --full-history in your answer, it will be perfect ;-)
^ permalink raw reply
* Re: [PATCH] log --format: teach %C(auto,black) to paint it black only on terminals
From: Jeff King @ 2012-12-17 19:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git@vger.kernel.org, Srb, Michal
In-Reply-To: <7v4njkmq07.fsf@alter.siamese.dyndns.org>
On Mon, Dec 17, 2012 at 11:34:48AM -0800, Junio C Hamano wrote:
> > 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).
>
> I actually do not like this patch very much. The original motive
> behind this "auto" thing was to relieve the script writers from
> the burden of having to write:
>
> if tty -s
> then
> warn='%C(red)'
> reset='%C(reset)'
> else
> warn= reset=
> fi
> fmt="${warn}WARNING: boo${reset} %s"
>
> and instead let them write:
>
> fmt="%C(auto,red)WARNING: boo%C(auto,reset) %s"
>
> but between the two, there is no $cmd.color configuration involved
> in the first place. I am not sure what $cmd.color configuration
> should take effect---perhaps for a "git frotz" script, we should
> allow the script writer to honor frotz.color=(auto,never,always)
> configuration, not just ui.color variable.
Since this is by definition just talking about the log traversal, I
think it makes sense to respect the log traversal option by default
(which is confusingly color.diff, of course, but that is a separate
issue). That means that scripts which just wrap a regular traversal will
do what the user is accustomed to.
If "git frotz" wants to have a separate "color.frotz" option to override
that, then they would need to implement that themselves either with or
without your patch. I do not think its presence makes things any harder.
> Also the patch as posted deliberately omits support to honor command
> line override --color=(auto,never,always), but it may be more
> natural to expect
>
> git show --format='%C(auto,red)%s%C(auto,reset)' --color=never
>
> to defeat the "auto," part the script writer wrote.
>
> Now, such a script would be run by its end users as
>
> $ git frotz --color=never
>
> It has to do its own option parsing before running the underlying
> "git show" to decide if it passes "--color=never" from the command
> line for that to happen.
Yeah, _if_ it does not just pass its options directly to git-log. Which
I think a reasonable number of scripts do, as well as pretty.* aliases
(which are not really scripts, but have the same relationship with
respect to this feature). For example, "git stash list" does not use
color in its output, but could be improved to do so after your patch.
So no, I do not think you can cover every conceivable case. But having
git-log respect --color and the usual color.* variables for this feature
seems like the only sane default. It makes the easy cases just work, and
the hard cases are not any worse off (and they may even be better off,
since the script can manipulate --color instead of rewriting their
format strings, but that is a minor difference).
-Peff
^ permalink raw reply
* Re: [PATCH] git-completion.bash: add support for path completion
From: Junio C Hamano @ 2012-12-17 19:42 UTC (permalink / raw)
To: Manlio Perillo; +Cc: git
In-Reply-To: <50CEFF3A.4050802@gmail.com>
Manlio Perillo <manlio.perillo@gmail.com> writes:
>> 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.
That sounds like a regression to me.
>> 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.
I deliberately wrote "the last" not "the second", as you can do
$ mkdir X
$ git mv COPYING README X/.
You do need to expand the second parameter to README when the user
types
git mv COPYING REAMDE X
then goes back with \C-b to "M", types \C-d three times to remove
"MDE", and then finally says <TAB>, to result in
git mv COPYING README X
^ permalink raw reply
* Re: [PATCH] log --format: teach %C(auto,black) to paint it black only on terminals
From: Junio C Hamano @ 2012-12-17 19:34 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, git@vger.kernel.org, Srb, Michal
In-Reply-To: <20121217121354.GB21858@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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).
I actually do not like this patch very much. The original motive
behind this "auto" thing was to relieve the script writers from
the burden of having to write:
if tty -s
then
warn='%C(red)'
reset='%C(reset)'
else
warn= reset=
fi
fmt="${warn}WARNING: boo${reset} %s"
and instead let them write:
fmt="%C(auto,red)WARNING: boo%C(auto,reset) %s"
but between the two, there is no $cmd.color configuration involved
in the first place. I am not sure what $cmd.color configuration
should take effect---perhaps for a "git frotz" script, we should
allow the script writer to honor frotz.color=(auto,never,always)
configuration, not just ui.color variable.
Also the patch as posted deliberately omits support to honor command
line override --color=(auto,never,always), but it may be more
natural to expect
git show --format='%C(auto,red)%s%C(auto,reset)' --color=never
to defeat the "auto," part the script writer wrote.
Now, such a script would be run by its end users as
$ git frotz --color=never
It has to do its own option parsing before running the underlying
"git show" to decide if it passes "--color=never" from the command
line for that to happen.
But at that point, we are back to the square one. Such a script
would be doing something like:
if cmdline_has_color_flag
then
use_color=... that flag ...
elif git config --get-colorbool frotz.color
then
use_color=--color=always
else
use_color=--color=never
fi
in its early part to decide $use_color, to be used in the call it
makes to "git show" later on:
git show --format="$fmt" $use_color
Adding the logic to decide if %C(...) should be added to $fmt no
longer is an additional burden to the script writer, making the
whole %C(auto,red) machinery of little use.
So...
^ permalink raw reply
* Re: [PATCH 1/2] Documentation/git-checkout.txt: clarify usage
From: Junio C Hamano @ 2012-12-17 19:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Chris Rorvick, git, Andrew Ardill, Tomas Carnecky, Woody Wu
In-Reply-To: <50CEDF0A.7040603@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> 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.
True; we do not have a particular "on the <branch>" in this state.
At least, "on the <branch>" needs to be removed. But I think we may
want a more different wording here, including the earlier "work on
building new history on top of" part.
The detached HEAD state primarily is a sightseeing mode, where the
user is expected to view but not touch. Even for experienced users,
commits on a detached HEAD are for keeping snapshots of interim
states during a throw-away experiment, so the purpose of detaching
is not exactly "to work on *building* new history" in the first
place.
Carefree experimentation is encouraged by not forbidding commmits
from this state, with the expectation that:
(1) if it does not lead to interesting result, another "git
checkout <branch>" will wipe the throw-away experiment without
affecting any of your more important branches; and
(2) an experiment that yielded something useful can be further
polished on a concrete branch by "git checkout -b <newbranch>".
I think the above discussion on detached HEAD can be added to its
own section.
Prepare to work on top of <commit>, by detaching HEAD at it
(see "DETACHED HEAD" section), and updating te index and the
files in the working tree. Local modifications to the files
in the working tree are kept, so that the resulting working
tree will be the state recorded in the commit plus the local
modifications.
Or something, perhaps?
^ permalink raw reply
* Re: [PATCH] git-completion.bash: update obsolete code.
From: Manlio Perillo @ 2012-12-17 16:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtxrlnuqr.fsf@alter.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 17/12/2012 05:54, Junio C Hamano ha scritto:
> Manlio Perillo <manlio.perillo@gmail.com> writes:
>
>> The git-completion.bash script was using the git ls-tree command
>> without the --name-only option, with a sed filter to parse path names;
>> use the --name-only option, instead.
>>
>> Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
>> ---
>
> Did you miss the different handling between blobs and trees the
> latter gets trailing slash in the completion)?
>
Yes, I totally missed it, sorry.
I was assuming the bash completion script was written before --name-only
option was added to ls-tree.
By the way, IMHO there should be an option for adding a slash to
directory names in ls-tree.
> [...]
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAlDPTgUACgkQscQJ24LbaUSkKgCePH2NFHf/qp2ZrgI9eD9D0D3G
zOwAmL8Dc8r9DevyV1ZhaCb2G9MPZxU=
=QJEy
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: problem with BOINC repository and CR/LF
From: Toralf Förster @ 2012-12-17 16:01 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git@vger.kernel.org
In-Reply-To: <CAH5451=FpmtGVVJ=mubE0KeD-tTVaNU96audzTRnNQh2BEEXPg@mail.gmail.com>
On 12/17/2012 12:38 PM, Andrew Ardill wrote:
> 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
>
Oh of course :
On 12/17/2012 12:03 AM, Gianfranco Costamagna wrote:
> So if you have further issues with boinc feel free to look in our debian
> git and feel free to download appropriate patches :-)
>
> Gianfranco
thx
Currently I'm struggling with a git problem of the boinc repository
itself and b/c I'm using git for the linux kernel tree w/o any problems
since eons /me wonders whether this is a BOINC-repository specific problem :
After doing the following sequence with git 1.8.0.2 :
$> git clone git://boinc.berkeley.edu/boinc.git
$> cd boinc
$> git checkout client_release_7.0.39
$> git checkout master
(sometimes I've to repeat this :
$> git checkout client_release_7.0.39
$> git checkout master
)
I'm faced with this situation :
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: clientgui/AsyncRPC.cpp
# modified: clientgui/sg_BoincSimpleFrame.cpp
#
no changes added to commit (use "git add" and/or "git commit -a")
(sometimes only clientgui/sg_BoincSimpleFrame.cpp is mentioned)
Now these commands
$ git checkout -- clientgui/AsyncRPC.cpp
$ git checkout -- clientgui/sg_BoincSimpleFrame.cpp
doesn't help - the status is still the same (and ofc now I'm no longer
allowed to make a "git checkout" - due to un-commited changes).
Now I'm wondering where to start to investigate this issue ...
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: [PATCH 0/2] second try
From: Sven Strickroth @ 2012-12-17 15:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jakub Narebski, Eric Wong
In-Reply-To: <7vtxsdvug3.fsf@alter.siamese.dyndns.org>
Hi,
Am 26.11.2012 05:50 schrieb Junio C Hamano:
> Sven Strickroth <sven.strickroth@tu-clausthal.de> writes:
>
>> Am 11.11.2012 17:40 schrieb Sven Strickroth:
>>> Am 06.10.2012 20:28 schrieb Junio C Hamano:
>>>> It is either that it was simply forgotten, or after I wrote the part
>>>> you quoted early in January there were discussions later that showed
>>>> the patch was not desirable for some reason. I do not recall which.
>>>
>>> I noticed no threads about possible problems, so I try again.
>>
>> On November 11th I submitted the updated patches again, however, without
>> any reaction or comments.
>
> I think between Peff and me it fell in the cracks during the
> hand-off; I do not know about the others, probably people did not
> find it interesting perhaps?
>
> I'll add Eric Wong (git-svn submaintainer) to Cc.
I received no feedback, so is there any progress on this issue?
I'd really appreciate if we could fix it soon.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ 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