David Aguilar writes:
> On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth
> wrote:
>> TortoiseMerge caused to whole
>> argument instead of just the file name to be quoted
>
> s/caused to whole/caused the whole/
>
> I think this commit message is very nice. Is it too late to replace
> the current
On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth
wrote:
> TortoiseMerge caused to whole
> argument instead of just the file name to be quoted
s/caused to whole/caused the whole/
I think this commit message is very nice. Is it too late to replace
the current patch with this one?
--
David
--
To
Jonathan Nieder writes:
> Looks like this was fixed in the week since last pull.
>
> http://thread.gmane.org/gmane.comp.version-control.git/214312
>
> Paul, would it be safe for Junio to pull again?
Thanks. I think I pulled a few days ago, and the result should have
already been propagate
On Fri, Feb 01, 2013 at 02:45:19PM -0800, Jonathan Nieder wrote:
> After a change in a header file, object files in a subdirectory are
> not automatically rebuilt by "make":
>
> $ touch cache.h
> $ make builtin/add.o
> $
>
> Luckily we can prevent trouble by explicitly supplyin
On 31/01/2013 3:17 AM, Junio C Hamano wrote:
Jason Wenger writes:
Trying to start up discussion of whether there would be merit to a "half-
ignored" state -- Files which are excluded from tracking, but which still
show in git status, and which are removed by git clean.
I see no merit for "ign
Hi Ram,
Ramkumar Ramachandra wrote:
> 8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed
> "/gitk-git/gitk-wish" from the toplevel .gitignore, with the intent of
> moving it to gitk-git/.gitignore in a later patch. This was never
> realized.
>
> Signed-off-by: Ramkumar Ramacha
Date: Fri, 18 Nov 2011 17:23:24 -0600
"gcc -MF depfile -MMD -MP -c -o path/to/file.o" produces a makefile
snippet named "depfile" describing what files are needed to build the
target given by "-o". When ccache versions before v3.0pre0~187 (Fix
handling of the -MD and -MDD options, 2009-11-01) run
Jongman Heo wrote:
>> But it doesn't stimulate any prerequisites in make, which is weird.
>> What's in builtin/.depend/fetch.o.d?
[...]
> please see below~.
>
> $ cat builtin/.depend/fetch.o.d
> fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
That's the problem. S
Jeff King writes:
> On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote:
>
>> > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
>> > Users of "git help foo" would not ever see this, but people who
>> > have trained their fingers to type "man gitfoo" wo
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of this month.
You can find the changes
Martin von Zweigbergk wrote:
> I'm working on a re-roll of
> http://thread.gmane.org/gmane.comp.version-control.git/205796
>
> and finally got around to including test cases for what you fixed in
> this patch. I want to make sure I'm testing what you fixed here. See
> questions below.
Thanks for
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax.
This change was necessary because of MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge c
Hi Erik,
Erik Faye-Lund wrote:
> This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
>
> commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
> the only call-site for strtok_r. So let's get rid of the compat
> implementation as well.
Yes, good idea. Sorry I didn't take care
Am 01.02.2013 21:15 schrieb Junio C Hamano:
>> TortoiseGitMerge is an improved version of TortoiseMerge specifically
>> for use with Git on Windows. Due to MSYS path mangling [1], the ":"
>> after the "base" etc. arguments to TortoiseMerge caused to whole
>> argument instead of just the file name t
Am 01.02.2013 21:07 schrieb Sebastian Schuberth:
> mergetools: Teach tortoisemerge about TortoiseGitMerge
This subject doesn't make any sense if we don't combine the two patches.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the li
>
> Presumably the first "The" should be dropped from either the link or
> the surrounding text.
>
> Doubled 'The'.
>
You are right. I missed that; sorry.
>
> Isn't the old title more informative?
>
Yes; but every other link just uses the shorter version "Everyday Git".
---
Thomas
--
To uns
Jonathan Nieder writes:
> Thomas Ackermann wrote:
>
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -23,7 +23,7 @@ and full access to internals.
>>
>> See linkgit:gittutorial[7] to get started, then see
>> link:everyday.html[Everyday Git] for a useful minimum set of
>> -co
Jonathan Nieder writes:
>> diff --git a/Documentation/git-rev-parse.txt
>> b/Documentation/git-rev-parse.txt
>> index c743469..14386ed 100644
>> --- a/Documentation/git-rev-parse.txt
>> +++ b/Documentation/git-rev-parse.txt
>> @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero s
Sebastian Schuberth writes:
> The commit message still does not mention MSYS path mangling at all,
> which probably is why the reasoning of this patch was not yet fully
> understood.
Ahh, you are very right. I didn't realize that was what this funny
"with colon, with SP" business was about.
>
On Fri, Feb 1, 2013 at 8:33 PM, Sven Strickroth
wrote:
> TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
> with spaces in them by using -option "$FILE" (not -option:"$FILE",
> which does not work for such paths) syntax. Both do not have a fully
> posix compatible cli parameter
Thomas Ackermann wrote:
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -23,7 +23,7 @@ and full access to internals.
>
> See linkgit:gittutorial[7] to get started, then see
> link:everyday.html[Everyday Git] for a useful minimum set of
> -commands. The link:user-manual.html[G
Junio C Hamano wrote:
> How about saying something like this here in the glossary:
>
> A plain file `.git` at the root of a working tree that
> points at the directory that is the real repository.
>
> And then as a separate patch, in gitrepository-layout.txt (eek---see
> the other thre
Hi,
Thomas Ackermann wrote:
> Found by Junio:
> Change git-dir to $GIT_DIR and git-file to gitfile.
>
> Signed-off-by: Thomas Ackermann
> ---
> Documentation/git-rev-parse.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-rev-parse.txt b/Docum
On Fri, Feb 01, 2013 at 02:38:51PM -0500, Jeff King wrote:
> Junio, do you want to apply the patch below? I guess it conflicts with
> John's gitremote-helper.txt tweak, though.
Argh, it would help if I actually ran "git commit", and/or looked at
what I was sending out. Here it is with the actual
On Fri, Feb 01, 2013 at 11:20:10AM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > We keep a list of the various files that end up as man1,
> > man5, etc. Let's break these single-line lists into sorted
> > multi-line lists, which makes diffs that touch them much
> > easier to read.
>
> I
Jonathan Nieder writes:
>> --- a/Documentation/Makefile
>> +++ b/Documentation/Makefile
>> @@ -1,13 +1,28 @@ MAN7_TXT += gitcredentials.txt
>> -MAN1_TXT= \
>> -$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
>> -$(wildcard git-*.txt)) \
>> -gitk.txt gitweb.txt gi
spaces with TortoiseGitMerge
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax. Both do not have a fully
posix compatible cli parameter parser, however, TortoiseGitMerge
Junio C Hamano writes:
> Thomas Ackermann writes:
>
>> Signed-off-by: Thomas Ackermann
>> ---
>> Documentation/glossary-content.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/glossary-content.txt
>> b/Documentation/glossary-content.txt
>> index 7c15bc0..ddf2f
Jeff King wrote:
> Let's just call everything git-*, which is simpler. This
> patch renames the documentation files, updates the Makefile
> to find them, and updates internal linkgit references to the
> pages. It updates builtin/help.c so that users of "git help
> foo" will not even notice the dif
Jeff King wrote:
> We keep a list of the various files that end up as man1,
> man5, etc. Let's break these single-line lists into sorted
> multi-line lists, which makes diffs that touch them much
> easier to read.
Independentally of the rest of the series, I think this is a good
cleanup.
> --- a
I'm working on a re-roll of
http://thread.gmane.org/gmane.comp.version-control.git/205796
and finally got around to including test cases for what you fixed in
this patch. I want to make sure I'm testing what you fixed here. See
questions below.
On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord wrote:
On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote:
> > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
> > Users of "git help foo" would not ever see this, but people who
> > have trained their fingers to type "man gitfoo" would, along with
> > a
On Fri, Feb 01, 2013 at 10:09:26AM -0800, Junio C Hamano wrote:
> > so I do not think the patch makes anything worse. However, should we
> > take this opportunity to make the "did we get a smart response" test
> > more robust? That is, should we actually be checking the content-type
> > in the out
Jeff King writes:
> Right. So we have some that must be "gitfoo", and others that do not
> care. If we turned "githooks" into "git-hooks" and removed the "is it a
> command?" magic from "git help", then "git help hooks" would still find
> hooks. And likewise, "git help gitignore" would still find
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
I think this deserves to be a separate patch in the series, that
says "StGit is the right spelling of the system, not StGIT",
referring to https://gna.org/projects/stgit/ or somewhere, in the
log message.
Will massage the above i
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
> Documentation/git.txt | 2 +-
> Documentation/gitcore-tutorial.txt | 6 +++---
> Documentation/gittutorial-2.txt| 2 +-
> Documentation/gittutorial.txt | 2 +-
> 4 files changed, 6 insertions(+), 6 deletion
In the current German translation, the word "revision" was
translated as both "Version" (translation of "commit") and
"Revision". Since a revision in Git is not necessarily a
commit, we should not translate it with the same word in
order to give the user an idea that it's not necessarily
the same.
Thomas Ackermann writes:
> Signed-off-by: Thomas Ackermann
> ---
> Documentation/glossary-content.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/glossary-content.txt
> b/Documentation/glossary-content.txt
> index 7c15bc0..ddf2f66 100644
> --- a/Documentation/glos
Thomas Ackermann writes:
> >
>> I think we have waited long enough and as far as I recall we didn't
>> see any reports of misconversion or forgotten conversion, so I'll
>> squash the fixes parked on the topic branch, whose tip is at
>> bfb8e1eb6375afb (fixup! Change 'git' to 'Git' whenever the
Signed-off-by: Thomas Ackermann
---
Documentation/git.txt | 2 +-
Documentation/gitcore-tutorial.txt | 6 +++---
Documentation/gittutorial-2.txt| 2 +-
Documentation/gittutorial.txt | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/git.txt
Signed-off-by: Thomas Ackermann
---
Documentation/glossary-content.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 7c15bc0..ddf2f66 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossar
Signed-off-by: Thomas Ackermann
---
Documentation/git-p4.txt| 4 ++--
Documentation/git-remote-fd.txt | 2 +-
Documentation/gittutorial.txt | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 1d1b020..3417cb3 1
Jeff King writes:
> Should this be "From:" Shawn? The tone of the message and the S-O-B
> order makes it look like it.
Yes. I should have left that line when edited the format-patch
output in my MUA to say I was resending something that vger rejected
and people did not see after tweaking the pat
Signed-off-by: Thomas Ackermann
---
Documentation/git-tools.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
index 338986a..ad8b823 100644
--- a/Documentation/git-tools.txt
+++ b/Documentation/git-tools.txt
@@ -2
Found by Junio:
Change git-dir to $GIT_DIR and git-file to gitfile.
Signed-off-by: Thomas Ackermann
---
Documentation/git-rev-parse.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index c743469..14386
Found by David and Junio:
Inconsistent quoting within config.txt should be fixed in a separate patch.
Signed-off-by: Thomas Ackermann
---
Documentation/config.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3652ee0
>
> I think we have waited long enough and as far as I recall we didn't
> see any reports of misconversion or forgotten conversion, so I'll
> squash the fixes parked on the topic branch, whose tip is at
> bfb8e1eb6375afb (fixup! Change 'git' to 'Git' whenever the whole
> system is referred to #4,
bin4LBRs7J_4W.bin
Description: iso-8859-1
On Fri, Feb 01, 2013 at 09:39:39AM +0100, Michael Haggerty wrote:
> On 01/30/2013 09:31 PM, John Keeping wrote:
> > On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
> >> [...] maybe we should establish a small Python library of
> >> compatibility utilities (like a small "six"). [..
>> [...]
>> Finished prerequisites of target file `builtin/fetch.o'.
>> Prerequisite `builtin/fetch.c' is older than target `builtin/fetch.o'.
>> Prerequisite `GIT-CFLAGS' is older than target `builtin/fetch.o'.
>> No need to remake target `builtin/fetch.o'.
>
>But it doesn't stimulate any prer
On Fri, Feb 01, 2013 at 10:30:24AM +, Jongman Heo wrote:
> Short answer;
>
> * Version of make is 3.81 on both machines
> * builtin/fetch.o is not rebuilt (see entire log below)
> * git works fine with "make all install COMPUTE_HEADER_DEPENDENCIES=no"
OK, that gets us closer. It's defini
On Thu, Jan 31, 2013 at 06:06:56PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
> > Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
> > space/time trade-off.
>
> Following the on-disk format experiment yesterday, I changed the
>
On Fri, Feb 1, 2013 at 11:33 AM, Erik Faye-Lund wrote:
> This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
>
> commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
> the only call-site for strtok_r. So let's get rid of the compat
> implementation as well.
>
> Conflicts:
>
This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
the only call-site for strtok_r. So let's get rid of the compat
implementation as well.
Conflicts:
Makefile
config.mak.in
configure.ac
---
I just
On Thu, Jan 31, 2013 at 06:06:56PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
> > Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
> > space/time trade-off.
>
> Following the on-disk format experiment yesterday, I changed the
>
On Wed, Jan 30, 2013 at 08:56:07PM +0700, Nguyen Thai Ngoc Duy wrote:
> Another point, but not really important at this stage, I think we have
> memory leak somewhere (lookup_commit??). It used up to 800 MB RES on
> linux-2.6.git while generating the cache.
We generate (and then leak!) the linked
On Fri, Feb 01, 2013 at 09:14:41AM +, Jongman Heo wrote:
> I can reproduce the issue in my machine (RedHat Enterprise 5, x86 PAE) as
> follows.
Great, thanks for taking the time to reproduce.
> But in my different machine (Fedora 16 x86) I can't reproduce.
That makes me wonder if it is re
On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote:
> > Of course, it is more convenient to store this kind of things in a
> > separate file while experimenting and improving the mechanism, but I
> > do not think we want to see each packfile in a repository comes with
> > 47 auxiliary
On Tue, Jan 29, 2013 at 11:17:41PM -0800, Junio C Hamano wrote:
> > True, but it is even less headache if the file is totally separate and
> > optional.
>
> Once you start thinking about using an offset to some list of SHA-1,
> perhaps? A section inside the same file can never go out of sync.
Y
Junio C Hamano wrote :
> 허종만 writes:
>> But usually when I build upstream Linux kernel, I don't do "make
>> clean" after git pull.. I didn't expect that I needed "make
>> clean" for git build.
>
> We don't expect anybody need "make clean", either. There is
> something wrong in the dependency.
On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote:
> >> - System resource cost we incur by having to keep 50 file
> >>descriptors open and maintaining 50 mmap windows will reduce by
> >>50 fold.
> >
> > I wonder how measurable that is (and if it matters on Linux versus less
On Thu, Jan 31, 2013 at 09:14:26AM -0800, Shawn O. Pearce wrote:
> On Tue, Jan 29, 2013 at 1:14 AM, Jeff King wrote:
> > This is the cleaned-up version of the commit caching patches I mentioned
> > here:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/212329
> ...
> > The short
Using Ubuntu Precise 12.04 with git version (1.8.0.3) I discovered a bug
whereby git-clone deletes the repository
it has just created if there is a GnuTLS error after the final transfer.
I switched to building and using the current git head
(1.8.1.2.433.g070c57d.dirty) and found the same issue i
On Thu, Jan 31, 2013 at 02:09:40PM -0800, Junio C Hamano wrote:
> Before parsing a suspected smart-HTTP response verify the returned
> Content-Type matches the standard. This protects a client from
> attempting to process a payload that smells like a smart-HTTP
> server response.
>
> JGit has bee
On 01/30/2013 09:31 PM, John Keeping wrote:
> On Wed, Jan 30, 2013 at 11:05:10AM +0100, Michael Haggerty wrote:
>> [...] maybe we should establish a small Python library of
>> compatibility utilities (like a small "six"). [...]
>> But I haven't had time to think of where to put such a library, how
The manpages for commands have always been spelled
"git-cmd". But "concept" manpages, like "gitrevisions" were
spelled without the dash. This is complex, and does not
actually buy anything. You might think it creates a separate
namespace for concepts and commands, but "git help foo" will
prefer the
We keep a list of the various files that end up as man1,
man5, etc. Let's break these single-line lists into sorted
multi-line lists, which makes diffs that touch them much
easier to read.
Signed-off-by: Jeff King
---
Documentation/Makefile | 33 -
1 file changed,
On Fri, Feb 01, 2013 at 02:33:52AM -0500, Jeff King wrote:
> I am starting to think it has grown in an unnecessarily complex
> direction, and we would be much happier just calling all of the
> "concept" documentation "git-".
>
> The steps I see are:
I am still undecided on whether it is a good i
68 matches
Mail list logo
