Le mercredi 12 septembre 2012 à 17:04 -0400, Jeff King a écrit :
Wouldn't this break all of the code that is planning to index W by
32-bit words (see the definitions of setW in block-sha1/sha1.c)?
That's not the same W ... This part of the code is indeed unclear.
Sorry, you're
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 append .gitattributes to see if that
directory has a per-directory
On 09/13/2012 12:49 AM, Philip Oakley wrote:
My comment, as a simple reader, is that I misread the order of the
items, in that I miss-associate the description paragraph with the *
title _below_. That is, I see the description first and then read on...
Thinking about it, if the description
This way it just got added to gnulib too.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
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
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
From: Philip Oakley philipoak...@iee.org
Sent: Wednesday, September 12, 2012 11:49 PM
From: Jens Lehmann jens.lehm...@web.de
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.
Junio C Hamano venit, vidit, dixit 12.09.2012 19:25:
Michael J Gruber g...@drmicha.warpmail.net 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
In case 'git cherry-pick -s commit' 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
From: Devin J. Pohly djpo...@gmail.com
Allow a fetch-style remote helper to issue the notification
ref sha1 name
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
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai ti...@suse.de 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
At Thu, 13 Sep 2012 19:51:14 +0800,
Linus Torvalds wrote:
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai ti...@suse.de 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
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 ti...@suse.de wrote:
are available in the git repository at:
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 append
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.
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 check
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 going to a
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.
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:
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
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
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 g...@drmicha.warpmail.net
---
t/t7810-grep.sh | 24 ++--
1
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
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
+++
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 -
Takashi Iwai ti...@suse.de 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.
2012/9/12 Junio C Hamano gits...@pobox.com:
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
On Thu, Sep 13, 2012 at 10:52:08AM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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,
Andrew Ardill andrew.ard...@gmail.com writes:
Currently, the output for each branch looks something like:
* branch-name (creation-date) number-of-commits
(merge-status)
[list-of-commits]
(branch-usage)
long-description
notes-and-memoranda
next-steps
and these are grouped by current
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 cr 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
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]
Jeremy White jwh...@codeweavers.com 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.
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
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
Junio C Hamano gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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
Ralf Thielow ralf.thie...@gmail.com 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:
From: Jeremy White jwh...@codeweavers.com
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
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
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
Jeff King p...@peff.net 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
In case 'git cherry-pick -s commit' 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
Michael J Gruber g...@drmicha.warpmail.net writes:
--all-match is ignored for author matching on purpose.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
What the added test expects is correct, but I do not think the above
description is correct. all-match is implicitly turned
Miklos Vajna vmik...@suse.cz 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),
+
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 jwh...@codeweavers.com
---
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-parents
Jeremy White jwh...@codeweavers.com 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
+++
On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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
Michael J Gruber g...@drmicha.warpmail.net 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
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 use of
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
Michael J Gruber g...@drmicha.warpmail.net 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'
Junio C Hamano gits...@pobox.com 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_bodybodycommit
(or
pattern_bodybodytag
(or
pattern_headhead 1Linus
(or
Andrew Ardill andrew.ard...@gmail.com writes:
On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote:
Andrew Ardill andrew.ard...@gmail.com writes:
short-branch-description
long-branch-description
notes
next-steps
* branch-name (creation-date) number-of-commits
On 14 September 2012 12:29, Junio C Hamano gits...@pobox.com wrote:
Andrew Ardill andrew.ard...@gmail.com writes:
On 14 September 2012 04:06, Junio C Hamano gits...@pobox.com wrote:
Andrew Ardill andrew.ard...@gmail.com writes:
short-branch-description
long-branch-description
notes
On Thu, Sep 13, 2012 at 8:09 AM, Jens Bauer jens-li...@gpio.dk 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
Junio C Hamano gits...@pobox.com 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.
David Aguilar dav...@gmail.com 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
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 just
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 RETURN
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
Ralf Thielow ralf.thie...@gmail.com 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
59 matches
Mail list logo
