In case 'git cherry-pick -s ' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Also update 'git commit -s', so that in case there is already a
Junio C Hamano writes:
> Who guarantees at this point in the codepath that option_branch is
> set when option_single_branch is non-zero? Until we talk with the
> remote, "clone --single-branch" without an explicit "--branch" will
> not learn which branch at the remote we are going to fetch (it w
"Devin J. Pohly" writes:
> From: "Devin J. Pohly"
>
> Allow a fetch-style remote helper to issue the notification
> ref
> to specify a ref's value during the fetch operation.
>
> Currently, a remote helper with the "fetch" capability cannot fetch a
> ref unless its sha1 was known when the "l
From: "Junio C Hamano"
Sent: Friday, September 14, 2012 3:29 AM
Andrew Ardill writes:
On 14 September 2012 04:06, Junio C Hamano wrote:
Andrew Ardill writes:
* ()
()
[list-of-commits]
()
I do not see how it makes any sense to have the "This is where the
section
Ralf Thielow writes:
> After using "git clone" with the "--single-branch"
> option, the configured refspec for this repo was
> "+refs/heads/*:refs/remotes/origin/*".
> After fetching changes from this repo again, it'll
> receive all refs instead of the single ref which
> was used in "--single-bra
I sometimes wonder what value the message is giving us.
For example, while reviewing a patch in my Emacs session, I may say
| git am -s3c
which runs the command on the contents of the e-mail I am reading,
to apply the patch. After that, I would go to a separate terminal
and do things like
After using "git clone" with the "--single-branch"
option, the configured refspec for this repo was
"+refs/heads/*:refs/remotes/origin/*".
After fetching changes from this repo again, it'll
receive all refs instead of the single ref which
was used in "--single-branch". Fixing the refspec
that it ju
David Aguilar writes:
> git doesn't really even support LF.
At the storage level that is correct, but the above is a bit of
stretch. It may not be "support", but git _does_ rely on LF when
running many text oriented operations (a rough rule of thumb is
"does 'a line' in a file matter to the ope
Junio C Hamano writes:
> I've played with both and have prepared patches to Reintegrate and
> cook (both in the 'todo' branch). Will play with the changes a bit
> more and then decide.
So here is how tonight's "What's cooking" may look like with extra
indentation and blank lines.
The tools tha
Hi David.
Thank you for the information.
I am not the one to decide whether or not this should be a built-in feature;
I'm only a plain user. :)
My personal opinion: If it was a built-in feature, people all over the World
would not be getting into trouble with it.
I've seen on the net, that even
Andrew Ardill writes:
> I feel a little bit like I might be bikeshedding this...
Yes you are.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 13, 2012 at 8:09 AM, Jens Bauer wrote:
> Hi everyone.
>
> I'm quite fond of git, and have used it for a while.
> Recently, I've started making printed circuit boards (PCBs) using an
> application called OsmondPCB (for Mac), and I'd like to use git to track
> changes on these.
> This
On 14 September 2012 12:29, Junio C Hamano wrote:
> Andrew Ardill writes:
>
>> On 14 September 2012 04:06, Junio C Hamano wrote:
>>> Andrew Ardill writes:
>>>
* ()
()
[list-of-commits]
()
>>>
>>> I do not see how it makes any sens
Andrew Ardill writes:
> On 14 September 2012 04:06, Junio C Hamano wrote:
>> Andrew Ardill writes:
>>
>>>
>>>
>>>
>>>
>>> * ()
>>> ()
>>>[list-of-commits]
>>> ()
>>
>> I do not see how it makes any sense to have the "This is where the
>> section begins with, and its na
On 14 September 2012 04:06, Junio C Hamano wrote:
> Andrew Ardill writes:
>
>> Currently, the output for each branch looks something like:
>> * ()
>> ()
>> [list-of-commits]
>> ()
>>
>>
>>
>>
>> and these are grouped by current integration status (new, graduated,
>> stalled etc)
>
> Yes
Junio C Hamano writes:
> Assuming that the patch I posted earlier actually works, I think the
> description can become vastly simpler, if you stop explaining author
> and committer in terms of "grep".
And here is a replacement in a patch form.
-- >8 --
Subject: [PATCH] log: document use of mu
Jeff King writes:
> On Thu, Sep 13, 2012 at 12:40:39PM -0700, Junio C Hamano wrote:
>
>> > Interesting. I don't get any such warning on repack. And RelNotes points
>> > to a file, so I'm not sure why stat() would make us think it was a dir.
>>
>> Interesting. The command in question is
>>
>>
Junio C Hamano writes:
>> diff --git a/Documentation/rev-list-options.txt
>> b/Documentation/rev-list-options.txt
>> index 5436eba..b2dbfb5 100644
>> --- a/Documentation/rev-list-options.txt
>> +++ b/Documentation/rev-list-options.txt
>> @@ -6,6 +6,19 @@ special notations explained in the descri
On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote:
> > I agree that the line is not bright. I do not know if it is worthwhile
> > or not. I think it will solve some practical problems, but it may also
> > introduce others. But basically having a per-repo LANG setting (which
> > is wh
Junio C Hamano writes:
> One possible improvement we can make is to parse the command line in
> the last example with "--all-match" to
>
> [all-match]
> (or
> pattern_bodycommit
> (or
> pattern_bodytag
> (or
>pattern_headLinus
>(or
> pattern_h
Michael J Gruber writes:
> The current behavior is probably as useful as it is confusing. In any
> case it is going to stay. So, document it.
>
> This does not take into account the issue of 'log --all-match
> --author=me --grep=foo --grep=bar' not honoring '--all-match' because it
> is hopefully
The discussion of email subject throughout the documentation is
misleading; it indicates that the first line will always become
the subject. In fact, the subject is generally all lines up until
the first full blank line.
This patch refines that, and makes more use of the concept of a
commit title
> For that kind of casual wording, we have used "title" on this list
> for quite a long time, I think. So I'd rather see a change that
> just says "title" (if we are making such a change to the
> documentation, that is). This is not a very strong preference,
> though.
Ah, I was unaware of the us
Jeff King writes:
> On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > I do not think they are incompatible if you separate it into three
>> > categories: machine readable (must never be translated), for the current
>> > user right now (current i18n),
Jeremy White writes:
> The discussion of email subject throughout the documentation is
> misleading; it indicates that the first line will always become
> the subject. In fact, the subject is generally all lines up until
> the first full blank line.
>
> Signed-off-by: Jeremy White
> ---
> Docu
On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do not think they are incompatible if you separate it into three
> > categories: machine readable (must never be translated), for the current
> > user right now (current i18n), and for sharing with other
Jeremy White writes:
>>> I did not substantially alter this. The emphasis of this section
>>> is on the broader show-branch output, and belaboring the subject would
>>> be distracting and unnecessary imho.
>>
>> Yeah, but if that is the focus of this part of the documentation,
>> wouldn't a patc
Jeff King writes:
> I do not think they are incompatible if you separate it into three
> categories: machine readable (must never be translated), for the current
> user right now (current i18n), and for sharing with other humans
> (i18n.projectlang).
Anything you see as a user is potentially use
Michael J Gruber writes:
> Thanks for "this" ;)
Here is a replacement to "this", that adds the "--debug" option to
"git grep" and an equivalent "--debug-grep" to "git log" family.
-- >8 --
Subject: [PATCH] grep: teach --debug option to dump the parse tree
Our "grep" allows complex boolean expr
On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I suspect we will end up with people not setting i18n.projectlang, and
> > getting Klingon diffstats on the list.
>
> Yes, but when our starting point is that the diffstat summary is not
> meant for machin
>> I did not substantially alter this. The emphasis of this section
>> is on the broader show-branch output, and belaboring the subject would
>> be distracting and unnecessary imho.
>
> Yeah, but if that is the focus of this part of the documentation,
> wouldn't a patch to update "the first line"
Jeremy White writes:
> Thanks for the feedback; new patch inbound. Minor nits:
>
>>> diff --git a/Documentation/gitcore-tutorial.txt
>>> b/Documentation/gitcore-tutorial.txt
>>> index f7815e9..92f97e6 100644
>>> --- a/Documentation/gitcore-tutorial.txt
>>> +++ b/Documentation/gitcore-tutorial.t
On Thu, Sep 13, 2012 at 12:40:39PM -0700, Junio C Hamano wrote:
> > Interesting. I don't get any such warning on repack. And RelNotes points
> > to a file, so I'm not sure why stat() would make us think it was a dir.
>
> Interesting. The command in question is
>
> git-pack-objects --keep-true-
The discussion of email subject throughout the documentation is
misleading; it indicates that the first line will always become
the subject. In fact, the subject is generally all lines up until
the first full blank line.
Signed-off-by: Jeremy White
---
Documentation/git-commit.txt |2
Miklos Vajna writes:
> +void append_signoff(struct strbuf *msgbuf, int ignore_footer)
> +{
> + struct strbuf sob = STRBUF_INIT;
> + int i;
> +
> + strbuf_addstr(&sob, sign_off_header);
> + strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
> + g
Jeff King writes:
> I suspect we will end up with people not setting i18n.projectlang, and
> getting Klingon diffstats on the list.
Yes, but when our starting point is that the diffstat summary is not
meant for machine consumption, which I tend to agree, that is a
logical consequence no matter h
On Thu, Sep 13, 2012 at 11:40:12AM -0700, Junio C Hamano wrote:
> > More than one people explicitly said that they do not want to see
> > this in Klingon. Even if the system is fully internationalized,
> > these "... (+), ... (-)" should never be localized, just like we
> > will never localize "d
Thanks for the feedback; new patch inbound. Minor nits:
>> diff --git a/Documentation/gitcore-tutorial.txt
>> b/Documentation/gitcore-tutorial.txt
>> index f7815e9..92f97e6 100644
>> --- a/Documentation/gitcore-tutorial.txt
>> +++ b/Documentation/gitcore-tutorial.txt
>> @@ -956,7 +956,7 @@ $ git
Michael J Gruber writes:
> --all-match is ignored for author matching on purpose.
>
> Signed-off-by: Michael J Gruber
> ---
What the added test expects is correct, but I do not think the above
description is correct. "all-match" is implicitly turned on when
you use header match.
When you say
In case 'git cherry-pick -s ' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Also update 'git commit -s', so that in case there is already a
Michael J Gruber writes:
> So, this turned out to be a bit longer.
> I decided not to implement "--debug" for "git log --grep" and such
> because the current code does a lot of special casing, so that the
> existing debug code happily outputs OR nodes in cases where the code
> in grep.c effective
Jeff King writes:
> On Wed, Sep 12, 2012 at 11:32:22PM -0700, Junio C Hamano wrote:
>
>> "git repack" started giving the above warning, and I am guessing
>> that the recent 11e50b2 (attr: warn on inaccessible attribute files,
>> 2012-08-21) exposed a bug where we ask stat(2) not lstat(2) by
>> mi
Hi Johannes.
I've changed...
tr '\\r' '\\n'
...to...
tr '\\15' '\\12'
...As you are right in that it is more correct. (Then in theory, it would be
portable).
[I once came across tftpd, tried compiling it on a Mac, but it failed to work,
because \r and \n were swapped on the comp
Hi Jeff and Drew.
Excellent. I now removed the repository from the server, removed it from my
gitolite.conf, added it to gitolite.conf, re-initialized and it works.
git diff shows what I wanted.
Thank you *very* much for making my dream come true. :)
-And thank you all for all the hard work you'
On Thu, Sep 13, 2012 at 8:45 PM, Junio C Hamano wrote:
> Ralf Thielow writes:
>
>> # looking again to my branches
>
> Don't look at your branches, but look at how the refspecs are
> configured by "git clone" in .git/config; I suspect we just write
> the default 'refs/heads/*:refs/remotes/origin/*
From: "Jeremy White"
Sent: Thursday, September 13, 2012 1:42 PM
The discussion of email subject throughout the documentation is
misleading; it indicates that the first line will become the subject.
In fact, the first and second and third lines will become the subject,
up until the first full bla
Ralf Thielow writes:
> # looking again to my branches
Don't look at your branches, but look at how the refspecs are
configured by "git clone" in .git/config; I suspect we just write
the default 'refs/heads/*:refs/remotes/origin/*' pattern.
--
To unsubscribe from this list: send the line "unsubsc
On Thu, Sep 13, 2012 at 02:30:19PM -0400, Peter Colberg wrote:
> I have trouble installing the Git Perl module to the correct
> installation prefix, which is required for git send-email.
>
> The problem is reproducible with the following commands:
>
> ./configure --prefix=/home/peter/usr/rhel
Junio C Hamano writes:
> Nguyễn Thái Ngọc Duy writes:
>
>> Git is still partly i18n-ized, turning a few strings back does not
>> seem a big regression.
>
> More than one people explicitly said that they do not want to see
> this in Klingon. Even if the system is fully internationalized,
> the
Hi,
I know people which have a separate directory for every
branch. In this case it doesn't make sense to download
the whole repo with all branches. So I guess the
"--single-branch" option is the solution in that case!?!
But I'm wondering about it's behaviour.
# first clone the branch of the repo
Hi,
I have trouble installing the Git Perl module to the correct
installation prefix, which is required for git send-email.
The problem is reproducible with the following commands:
./configure --prefix=/home/peter/usr/rhel6-x86_64/git-1.7.12
make
make install
While git is installed
Am 13.09.2012 17:53, schrieb Jens Bauer:
> Hi Jeff and Drew.
>
> Thank you for your quick replies! :)
>
> The diffs look nasty yes; that's my main issue.
> It can be worked around in many ways; eg a simple (but time consuming) way:
> $ git diff mypcb.osm >mypcb.diff && nano mypcb.diff
>
> -It'd
On 09/13/2012 09:33 AM, Peter Krefting wrote:
But this could potentially be dangerous because if "rebase" fires up
a editor for any other reason (e.g. having a "reword" or "squash" in
your recipe), then the commit message will be messed up. So you need
to make sure your recipe won't trigger any
Jeremy White writes:
> The discussion of email subject throughout the documentation is
> misleading; it indicates that the first line will become the subject.
> In fact, the first and second and third lines will become the subject,
> up until the first full blank line. Describing it as the first
On Thu, Sep 13, 2012 at 08:17:20PM +0200, Jens Bauer wrote:
> In my home directory, I have a .gitconfig file, here's the interesting part:
> [core]
> editor = nano
> excludesfile = /Users/jens/.gitexcludes
> attributesfile = /Users/jens/.gitattributes
>
> [filter "cr"]
>
Hi Jeff and Drew.
I've been messing a little with clean/smudge filters; I think I understand them
partly.
Let's call the file I have on the server that have line endings,
"mypcb.osm".
If I clone the project, and do the following...
$ cat mypcb.osm | tr '\r' '\n'
I can read the file in the term
Andrew Ardill writes:
> Currently, the output for each branch looks something like:
> * ()
> ()
> [list-of-commits]
> ()
>
>
>
>
> and these are grouped by current integration status (new, graduated,
> stalled etc)
Yes. Thanks for a concise summary.
> A format that would make this in
On Thu, Sep 13, 2012 at 10:52:08AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> But it should not be per-command, but per-message, and
> >> should include all output that is not diagnostic and is not
> >> machine-parseable (e.g., what I mentioned above, request-pul
On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:
> > But it should not be per-command, but per-message, and
> > should include all output that is not diagnostic and is not
> > machine-parseable (e.g., what I mentioned above, request-pull
> > output, etc). If it i
Junio C Hamano writes:
>> But it should not be per-command, but per-message, and
>> should include all output that is not diagnostic and is not
>> machine-parseable (e.g., what I mentioned above, request-pull
>> output, etc). If it is the project's language, then the team
>>
Elia Pinto writes:
> 2012/9/12 Junio C Hamano :
>>
>> Interesting, but it bothers me to make it enabled unconditionally.
>> At least, this shouldn't be enabled under GIT_TEST_OPTS=--valgrind, no?
> Sorry for the late response and thanks.
>
> No, setting MALLOC_CHECK don't require
> valgrind ...
Nguyễn Thái Ngọc Duy writes:
> Git is still partly i18n-ized, turning a few strings back does not
> seem a big regression.
More than one people explicitly said that they do not want to see
this in Klingon. Even if the system is fully internationalized,
these "... (+), ... (-)" should never be
Jeff King writes:
> I think I'd prefer:
>
> 1. Revert diffstat to always be in English/C locale for now. For all
> commands. People too frequently end up showing the output of things
> besides format-patch. It means they will have to read the English
> when they are just running
Miklos Vajna writes:
> +void append_signoff(struct strbuf *msgbuf, int ignore_footer)
> +{
> + struct strbuf sob = STRBUF_INIT;
> + int i;
> +
> + strbuf_addstr(&sob, sign_off_header);
> + strbuf_addstr(&sob, fmt_name(getenv("GIT_COMMITTER_NAME"),
> + g
Miklos Vajna writes:
> In case 'git cherry-pick -s ' failed, the user had to use 'git
> commit -s' (i.e. state the -s option again), which is easy to forget
> about. Instead, write the signed-off-by line early, so plain 'git
> commit' will have the same result.
>
> Also update 'git commit -s', s
Recent versions of Linux libc (later than 5.4.23) and glibc (2.x)
include a malloc() implementation which is tunable via environment
variables. When MALLOC_CHECK_ is set, a special (less efficient)
implementation is used which is designed to be tolerant against
simple errors, such as double calls o
2012/9/12 Junio C Hamano :
>
> Interesting, but it bothers me to make it enabled unconditionally.
> At least, this shouldn't be enabled under GIT_TEST_OPTS=--valgrind, no?
Sorry for the late response and thanks.
No, setting MALLOC_CHECK don't require
valgrind and it considered a best QA to have th
Hi Jeff and Drew.
Thank you for your quick replies! :)
The diffs look nasty yes; that's my main issue.
It can be worked around in many ways; eg a simple (but time consuming) way:
$ git diff mypcb.osm >mypcb.diff && nano mypcb.diff
-It'd be better to just pipe it into a regex, which changes CR to
On Thu, Sep 13, 2012 at 5:34 PM, Drew Northup wrote:
> On Thu, 2012-09-13 at 17:09 +0200, Jens Bauer wrote:
>> Hi everyone.
>>
>> I'm quite fond of git, and have used it for a while.
>> Recently, I've started making printed circuit boards (PCBs) using an
>> application called OsmondPCB (for Mac),
On Thu, Sep 13, 2012 at 11:34:50AM -0400, Drew Northup wrote:
> > I've read that git supports two different line endings; either CRLF or LF,
> > but it does not support CR.
> > Would it make sense to add support for CR (if so, I hereby request it as a
> > new feature) ?
>
> Even if Git can't do
On Thu, 2012-09-13 at 17:09 +0200, Jens Bauer wrote:
> Hi everyone.
>
> I'm quite fond of git, and have used it for a while.
> Recently, I've started making printed circuit boards (PCBs) using an
> application called OsmondPCB (for Mac), and I'd like to use git to track
> changes on these.
> Thi
At Thu, 13 Sep 2012 08:14:27 -0700,
Junio C Hamano wrote:
>
> Takashi Iwai writes:
>
> >> I can't reproduce here. What is your exact request-pull invocation?
>
> This question was not answerd.
It was (a sort of), but let me clarify again.
In my original pull request, I did git-request-pull for
Hi everyone.
I'm quite fond of git, and have used it for a while.
Recently, I've started making printed circuit boards (PCBs) using an
application called OsmondPCB (for Mac), and I'd like to use git to track
changes on these.
This application was originally written for the old Mac OS (Mac OS 6 t
Takashi Iwai writes:
>> I can't reproduce here. What is your exact request-pull invocation?
This question was not answerd. Did you ask request-pull to ask for
a branch to be pulled, or did you ask it to ask for the tag to be
pulled?
If the former, I would have say it is a pebcak. Linus asked
"Philip Oakley" writes:
>> Thinking about it, if the description paragraph was indented by one
>> space then the * title would create that obvious content indent
>> that (I am) would be expected.
>>
>> Obviously only a useful suggestion if it's easy to implement...
>>
>> Philip
> Thinking overni
On Thu, Sep 13, 2012 at 09:16:26PM +0700, Nguyen Thai Ngoc Duy wrote:
> This reverts the i18n part of 7f81463 (Use correct grammar in diffstat
> summary line - 2012-02-01) but still keeps the grammar correctness for
> English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on
> diffstat -
This reverts the i18n part of 7f81463 (Use correct grammar in diffstat
summary line - 2012-02-01) but still keeps the grammar correctness for
English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on
diffstat - 2012-08-27). The result is diffstat always in English
for all commands.
This
There are tests for this interaction already. Restructure slightly and
avoid any claims about --all-match.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/t/t7810-grep.sh b/t/t7810-gr
The current behavior is probably as useful as it is confusing. In any
case it is going to stay. So, document it.
This does not take into account the issue of 'log --all-match
--author=me --grep=foo --grep=bar' not honoring '--all-match' because it
is hopefully a corner case (and, even more hopeful
--all-match is ignored with multiple author options on purpose.
It is also ignored with multiple --grep options when an --author option
is present. Mark this as known failure.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 20
1 file changed, 20 insertions(+)
diff --
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 9b683ac..1db3dcb 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -546,6 +546,22 @@ test_expect_success 'log grep (6)' '
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
index 1db3dcb..9bc63a3 100755
--- a/t/t7810-grep.sh
+++ b/t/t7810-grep.sh
@@ -580,6 +580,14 @@
The log --grep tests generate the expected out in different ways.
Make them all use command blocks so that subshells are avoided and the
expected output is easier to grasp visually.
Signed-off-by: Michael J Gruber
---
t/t7810-grep.sh | 24 ++--
1 file changed, 18 insertions(+
So, this turned out to be a bit longer.
I decided not to implement "--debug" for "git log --grep" and such
because the current code does a lot of special casing, so that the
existing debug code happily outputs OR nodes in cases where the code
in grep.c effectively does AND (without changing the exp
Andrew Wong:
Instead of rebasing to "HEAD~", you should be able to do:
git rebase -i HEAD
Would you look at that, that actually works. So much for not testing
that. Thanks, that makes it a lot easier.
Instead of appending your own recipe, you could also abuse the EDITOR
environment vari
Hi folks,
I'm currently trying to import apache.org svn server, without success.
See:
git@moonshine:~/projects/common/libs$ git svn clone --stdlayout
http://svn.apache.org/repos/asf/commons/proper/discovery/
Initialized empty Git repository in
/home/git/projects/common/libs/discovery/.git/
W: I
On Wed, Sep 12, 2012 at 11:18:06AM -0700, Junio C Hamano wrote:
> I am so far taking the silence in the thread to mean they do not mind
> seeing the diffstat summary untranslated and they do not mind seeing
> it in Klingon, as long as the three numbers are there with (+) and (-)
> markings.
Actua
At Thu, 13 Sep 2012 09:03:44 -0400,
Jeff King wrote:
>
> On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote:
>
> > > FWIW, it was an output from git-pull-request, which fell back to the
> > > equivalent branch. Usually I check it manually but I forgot it at
> > > this time just before
On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote:
> > FWIW, it was an output from git-pull-request, which fell back to the
> > equivalent branch. Usually I check it manually but I forgot it at
> > this time just before going to a meeting.
> >
> > This was with git 1.7.11.5. I'll che
The discussion of email subject throughout the documentation is
misleading; it indicates that the first line will become the subject.
In fact, the first and second and third lines will become the subject,
up until the first full blank line. Describing it as the first paragraph
is more accurate.
S
On Wed, Sep 12, 2012 at 11:32:22PM -0700, Junio C Hamano wrote:
> "git repack" started giving the above warning, and I am guessing
> that the recent 11e50b2 (attr: warn on inaccessible attribute files,
> 2012-08-21) exposed a bug where we ask stat(2) not lstat(2) by
> mistake before deciding to ap
At Thu, 13 Sep 2012 14:03:16 +0200,
Takashi Iwai wrote:
>
> At Thu, 13 Sep 2012 19:51:14 +0800,
> Linus Torvalds wrote:
> >
> > On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote:
> > > are available in the git repository at:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sou
At Thu, 13 Sep 2012 19:51:14 +0800,
Linus Torvalds wrote:
>
> On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote:
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
>
> *PLEASE* don't do this.
>
> You point to a branch,
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote:
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
*PLEASE* don't do this.
You point to a branch, but then the pull request clearly implies there
is a tag with extra informat
From: "Devin J. Pohly"
Allow a fetch-style remote helper to issue the notification
ref
to specify a ref's value during the fetch operation.
Currently, a remote helper with the "fetch" capability cannot fetch a
ref unless its sha1 was known when the "list" command was executed.
This limitatio
In case 'git cherry-pick -s ' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Also update 'git commit -s', so that in case there is already a
Junio C Hamano venit, vidit, dixit 12.09.2012 19:25:
> Michael J Gruber writes:
>
>> It was introduced in 0ab7befa with a clear meaning (AND everything),
>> then the general logic (without --all-match) was modified in 80235ba7
>> (to take headermatch AND (all greps ORed)), and 5aaeb733 finally ma
From: "Philip Oakley"
Sent: Wednesday, September 12, 2012 11:49 PM
From: "Jens Lehmann"
Sent: Wednesday, September 12, 2012 8:21 PM
Am 11.09.2012 21:41, schrieb Junio C Hamano:
Thanks. I wish all others paid attention to "What's cooking" like
you did here.
And if it is hard to do so for wha
Joachim Schmitz wrote:
Joachim Schmitz wrote:
If poll() is used as a milli-second sleep, like in help.c, by passing
a NULL in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be
fixed like in this commit, which is not to exit
This way it just got added to gnulib too.
Signed-off-by: Joachim Schmitz
---
compat/poll/poll.c | 5 +
1 file changed, 4 insertions(+)
diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index e4b8319..10a204e 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -306,6 +306,10 @@ co
1 - 100 of 101 matches
Mail list logo
