On Fri, Feb 22, 2013 at 9:30 AM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Yes, but push.default is really different: there is a config variable,
>> and we want the behavior to be configurable. In the case of "git add",
>> I don't think adding a configuration option would be the right thi
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Oops, bogus indentation in the first 3/2
Documentation/git-update-index.txt | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 77a912d..dbb75f4 100644
Signed-off-by: Nguyễn Thái Ngọc Duy
---
.. and the user should know (briefly) the differences between index
versions too.
Documentation/git-update-index.txt | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-up
Olivier Delalleau writes:
> 2013/1/5 Pete Wyckoff :
>> sh...@keba.be wrote on Thu, 03 Jan 2013 15:58 -0500:
> ...
>> Please do feel welcome to to rearrange or expand the
>> documentation so it makes more sense, if you are so inspired.
>
> I'm afraid I'm not familiar enough with git documentation
I was on my master branch, I checked out a branch (origin/somebranch),
did nothing, made no updates
but did a few git pulls over about a week; made a small change to one
file & comitted & pushed.
Now am trying to go back to my master branch and get:
error: The following untracked working tree
Hi,
I'm looking at adding a "git subtree status" command that will tell if
a subtree is up-to-date, ahead of, behind, divergant with or unrelated
to a remote repo.
I just wanted to check that I'm working this out correctly before
writing the code.
1) perform a synthetic subtree split
mine=$(g
Just a quick update.
I am planning to merge the following to 'master':
* regression fixes and finishing touches to a new feature
ct/autoconf-htmldir
jn/less-reconfigure
as/check-ignore
* documentation updates
wk/man-deny-current-branch-is-default-these-days
wk/user-manual
I'd
Brandon Casey writes:
> From: Brandon Casey
>
> These tests call test_set_editor to set an alternate editor script, but
> they appear to presume that the assignment is of a temporary nature and
> will not have any effect outside of each individual test. That is not
> the case. All of the test
Jeff King writes:
> On Fri, Feb 22, 2013 at 02:53:48PM -0800, Junio C Hamano wrote:
>
>> > I guess we should probably issue a warning, too. Also disappointingly,
>> > git-fsck does not seem to detect this breakage at all.
>>
>> Yes for the warning,
>
> Unfortunately, a good warning is harder th
On Sat, Feb 23, 2013 at 1:04 AM, Jeff King wrote:
> On Fri, Feb 22, 2013 at 02:53:48PM -0800, Junio C Hamano wrote:
>> and no for disappointing. IIRC, in the very early implementations
>> allowed tag object without dates.
>>
>> I _think_ we can start tightening fsck, though.
>
> Then I think it w
From: Brandon Casey
These tests call test_set_editor to set an alternate editor script, but
they appear to presume that the assignment is of a temporary nature and
will not have any effect outside of each individual test. That is not
the case. All of the test functions within a test script shar
On Fri, Feb 22, 2013 at 03:01:32PM -0800, Jonathan Nieder wrote:
> > Git doesn't handle the resulting tag objects nicely at all. For example,
> > running `git cat-file -p` on the new object outputs a really odd
> > timestamp "Thu Jun Thu Jan 1 00:16:09 1970 +0016" (I'm guessing it
> > parses the y
Jonathan Nieder writes:
> Perhaps by default hash-object should automatically fsck the objects
> it is asked to create.
Yes, and let the experimentors to override when they are trying to
invent a new object type, finished a reader but not a writer (that
is why they are exprimenting with hash-obj
On Fri, Feb 22, 2013 at 02:53:48PM -0800, Junio C Hamano wrote:
> > I guess we should probably issue a warning, too. Also disappointingly,
> > git-fsck does not seem to detect this breakage at all.
>
> Yes for the warning,
Unfortunately, a good warning is harder than I had hoped. At the point
w
When using "hash-object -w" to create non-blob objects, it is
generally a good policy to run "git fsck" afterward to make sure the
resulting object is valid. Add a warning to the manpage.
While it at, gently nudge the user of "hash-object -w" toward
higher-level interfaces for creating or modifyi
Jeff King writes:
> I guess we should probably issue a warning, too. Also disappointingly,
> git-fsck does not seem to detect this breakage at all.
Yes for the warning, and no for disappointing. IIRC, in the very
early implementations allowed tag object without dates.
I _think_ we can start ti
On Sat, Feb 23, 2013 at 12:30:28AM +0200, Mantas Mikulėnas wrote:
> When messing around with various repositories, I noticed that git 1.8
> (currently using 1.8.2.rc0.22.gb3600c3) has problems parsing tag objects
> that have invalid timestamps.
>
> Times in tag objects appear to be kept as Unix t
Jeff King writes:
> FWIW, as a casual reader of this series, I find this to be way easier
> to follow than the previous round.
It is assuring to know that I am not the only one getting slow with
age ;-)
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a m
On Fri, Feb 22, 2013 at 02:05:27PM -0800, Brandon Casey wrote:
> From: Brandon Casey
>
> Before commit 33f2f9ab, 'commit -s' would populate the edit buffer with
> a blank line before the Signed-off-by line. This provided a nice
> hint to the user that something should be filled in. Let's resto
When messing around with various repositories, I noticed that git 1.8
(currently using 1.8.2.rc0.22.gb3600c3) has problems parsing tag objects
that have invalid timestamps.
Times in tag objects appear to be kept as Unix timestamps, but I didn't
realize this at first, and ran something roughly equi
On Fri, 22 Feb 2013, Junio C Hamano wrote:
http_proxy=http://proxy.myco.com
https_proxy=https://proxy.myco.com
The problem is that libcurl ignores the protocol part of the proxy
url, and it defaults to port 1080. wget honors the protocol specifier,
but it defaults to port 80 if none is
From: Brandon Casey
Before commit 33f2f9ab, 'commit -s' would populate the edit buffer with
a blank line before the Signed-off-by line. This provided a nice
hint to the user that something should be filled in. Let's restore that
behavior, but now let's ensure that the Signed-off-by line is prec
On Fri, Feb 22, 2013 at 10:35 AM, Junio C Hamano wrote:
> Brandon Casey writes:
>> diff --git a/sequencer.c b/sequencer.c
>> index 53ee49a..2dac106 100644
>> --- a/sequencer.c
>> +++ b/sequencer.c
>> @@ -1127,9 +1127,10 @@ void append_signoff(struct strbuf *msgbuf, int
>> ignore_footer, unsigne
Phil Hord writes:
> I have been unable to clone via http proxy because of a wrongly
> configured proxy setup in my lab.
>
> I had this env:
>
> http_proxy=http://proxy.myco.com
> https_proxy=https://proxy.myco.com
>
> The problem is that libcurl ignores the protocol part of the proxy
> ur
Phil Hord writes:
> Or maybe --amend should imply --cleanup=whitespace.
I am fairly negative on that.
Such a hidden linkage, even if it is documented, is just one more
thing people need to learn.
It _might_ be interesting (note: I did not say "worthwhile" here) to
think what happens if we scan
Thanks.
--
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
Hi
I'm trying to setup the post-receive-email hook, from contrib, using a
custom_showrev, from the script I do this by setting hooks.showrev
# hooks.showrev
# The shell command used to format each revision in the email, with
# "%s" replaced with the commit id. Defaults to "git rev-list -1
#
Read and write each 1024 byte buffer, rather than trying to buffer
the entire content of the file.
Previous code would crash on all files > 2 Gib, when the offset variable
became negative (perhaps below the level of perl), resulting in a crash.
On a 32 bit system, or a system with low memory it mig
Nguyễn Thái Ngọc Duy writes:
> 9d22778 (read-cache.c: write prefix-compressed names in the index -
> 2012-04-04) defined these. Interestingly, they were not used by
> read-cache.c, or anywhere in that patch. They were used in
> builtin/update-index.c later for checking supported index
> versions
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Documentation/technical/index-format.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/technical/index-format.txt
> b/Documentation/technical/index-format.txt
> index 27c7
Nguyễn Thái Ngọc Duy writes:
> branch_get() can return NULL (so far on detached HEAD only) but some
> code paths in builtin/branch.c cannot deal with that and cause
> segfaults. While at there, make sure we bail out when the user gives 2
> or more arguments, but we only process the first one and
On Tue, Feb 19, 2013 at 6:02 AM, Duy Nguyen wrote:
> On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund wrote:
>> On Tue, Feb 19, 2013 at 10:32 AM, David Wade wrote:
>>> Hi,
>>>
>>> I wrote a commit message beginning with a hash (#) character, like this:
>>> 'git commit -m "#ifdef " '
>>>
>>>
Thanks. Your code changes are looking good and the commit message
explains what you did and why you did it. A few comments below.
Am 22.02.2013 05:25, schrieb Will Entriken:
>>From d3fe2c76e6fa53e4cfa6f81600685c21bdadd4e3 Mon Sep 17 00:00:00 2001
> From: William Entriken
> Date: Thu, 21 Feb 2013
Thanks for all the input and patience.
On Fri, Feb 22, 2013 at 10:34 AM, Jeff King wrote:
> On Fri, Feb 22, 2013 at 09:30:57AM -0800, Joshua Clayton wrote:
>
>> Read and write each 1024 byte buffer, rather than trying to buffer
>> the entire content of the file.
>
> OK. Did you ever repeat your t
Jeff King writes:
> On Fri, Feb 22, 2013 at 10:06:56AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > How are you proposing to verify master~12 in that example? Because
>> > during parsing, it starts with "master", and we remember that?
>>
>> By not cheating (i.e. using get_sha1()
Joshua Clayton writes:
> Read and write each 1024 byte buffer, rather than trying to buffer
> the entire content of the file.
> Previous code would crash on all files > 2 Gib, when the offset variable
> became negative (perhaps below the level of perl), resulting in a crash.
> On a 32 bit system,
On Fri, Feb 22, 2013 at 09:30:57AM -0800, Joshua Clayton wrote:
> Subject: Re: [PATCH] Fix in Git.pm cat_blob crashes on large files
> (resubmit with reviewed-by)
One thing I forgot to note in my other response: the subject is part of
the commit message, so information like "resubmit with..." s
Brandon Casey writes:
> Before commit 33f2f9ab, 'commit -s' would populate the edit buffer with
> a blank line before the Signed-off-by line. This provided a nice
> hint to the user that something should be filled in. Let's restore that
> behavior, but now let's ensure that the Signed-off-by li
On Fri, Feb 22, 2013 at 09:30:57AM -0800, Joshua Clayton wrote:
> Read and write each 1024 byte buffer, rather than trying to buffer
> the entire content of the file.
OK. Did you ever repeat your timing with a larger symmetric buffer? That
should probably be a separate patch on top, but it might
On Fri, Feb 22, 2013 at 10:06:56AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > How are you proposing to verify master~12 in that example? Because
> > during parsing, it starts with "master", and we remember that?
>
> By not cheating (i.e. using get_sha1()), but making sure you can
>
Jeff King writes:
> How are you proposing to verify master~12 in that example? Because
> during parsing, it starts with "master", and we remember that?
By not cheating (i.e. using get_sha1()), but making sure you can
parse "master" and the adornment on it "~12" is something sane.
That is why I
Read and write each 1024 byte buffer, rather than trying to buffer
the entire content of the file.
Previous code would crash on all files > 2 Gib, when the offset variable
became negative (perhaps below the level of perl), resulting in a crash.
On a 32 bit system, or a system with low memory it mig
Matthieu Moy writes:
> Yes, but push.default is really different: there is a config variable,
> and we want the behavior to be configurable. In the case of "git add",
> I don't think adding a configuration option would be the right thing.
> That would mean typing "git add -u" on an account which
On Fri, Feb 22, 2013 at 09:10:46AM -0800, Junio C Hamano wrote:
> I personally think that it is OK to limit the scope to expressions
> that start from the tip of ref and expressions that start with the
> SHA-1 at the tip of ref, e.g.
>
> master~12:Documentation
> v2.6.11:arch/alpha
>
On Fri, Feb 22, 2013 at 08:47:39AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> ... ...
> >> +}
> >
> > Nice, I'm glad you handled this case properly. I've wondered if we
> > should have an option to do a similar test when writing out the "real"
> > message format. I.e., to put the e
David Aguilar writes:
> Please enlighten me.
As you lack the knowledge of previous discussion, I think you will
be the best person to proofread the paragraph on this issue in the
"backward compatibilty notes" section of the draft release notes to
v1.8.2 to see if that is understandable to the en
Sergey Sergeev writes:
[jc: please do not top-post]
> You are right,
> I'll rethink this patch and write some test for this cases.
Thanks.
Note that this is harder to implement than one would naïvely think,
if one aims for a very generic solution, without walking the whole
history.
I personal
On Fri, Feb 22, 2013 at 6:03 PM, Joshua Clayton
wrote:
> Read and write each 1024 byte buffer, rather than trying to buffer
> the entire content of the file.
> Previous code would crash on all files > 2 Gib, when the offset variable
> became negative (perhaps below the level of perl), resulting in
Read and write each 1024 byte buffer, rather than trying to buffer
the entire content of the file.
Previous code would crash on all files > 2 Gib, when the offset variable
became negative (perhaps below the level of perl), resulting in a crash.
On a 32 bit system, or a system with low memory it mig
Miles Bader writes:
> Junio C Hamano writes:
>> * Introduce "git add --ignore-removal" option in the release after
>>the current cycle (a new feature is too late for this cycle):
>
> Too late in the cycle even if the option is simply ignored ... ?
>
> [To extend the range of git versions wh
Jeff King writes:
>> ... ...
>> +}
>
> Nice, I'm glad you handled this case properly. I've wondered if we
> should have an option to do a similar test when writing out the "real"
> message format. I.e., to put the extra "From" line in the body of the
> message when !is_current_user(). Traditiona
On Fri, Feb 22, 2013 at 07:11:54AM -0800, Joshua Clayton wrote:
> running git svn fetch on a remote repository (yes I know there are a
> lot of possible outside variables, including network latency)
> Code with 1024 reads and 64k writes:
>
> real75m19.906s
> user16m43.919s
> sys 29m16
On Thu, Feb 21, 2013 at 06:13:28PM -0500, Jeff King wrote:
> On Thu, Feb 21, 2013 at 12:26:22PM -0800, Junio C Hamano wrote:
>
> > Some people may find it convenient to append a simple patch at the
> > bottom of a discussion e-mail separated by a "scissors" mark, ready
> > to be applied with "git
running git svn fetch on a remote repository (yes I know there are a
lot of possible outside variables, including network latency)
Code with 1024 reads and 64k writes:
real75m19.906s
user16m43.919s
sys 29m16.326s
Code with 1024 reads and 1024 writes:
real71m21.006s
user12m36.
9d22778 (read-cache.c: write prefix-compressed names in the index -
2012-04-04) defined these. Interestingly, they were not used by
read-cache.c, or anywhere in that patch. They were used in
builtin/update-index.c later for checking supported index
versions. Use them here too.
Signed-off-by: Nguyễ
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/technical/index-format.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/index-format.txt
b/Documentation/technical/index-format.txt
index 27c716b..0810251 100644
--- a/Documentation/techni
branch_get() can return NULL (so far on detached HEAD only) but some
code paths in builtin/branch.c cannot deal with that and cause
segfaults. While at there, make sure we bail out when the user gives 2
or more arguments, but we only process the first one and silently
ignore the rest.
Signed-off-b
On Wed, Feb 20, 2013 at 3:04 PM, Jeff King wrote:
> diff --git a/pkt-line.h b/pkt-line.h
> index fa93e32..47361f5 100644
> --- a/pkt-line.h
> +++ b/pkt-line.h
> @@ -25,9 +25,16 @@ void packet_buf_write(struct strbuf *buf, const char *fmt,
> ...) __attribute__((f
> void packet_buf_write(struct st
On 02/22/2013 01:57 AM, Jeff King wrote:
> I think the problem is that your test file is so tiny that it falls
> afoul of git's MINIMUM_BREAK_SIZE heuristic of 400 bytes (which prevents
> false positives on tiny files). Try replacing your "Lorem ipsum" echo
> with something like "seq 1 150", and I
David Aguilar writes:
> Please enlighten me.
> Are we really getting rid of it and replacing it with ":/"?
> That syntax looks like a meh face.. just sayin'
The current behavior is indeed replaced by "git add -u .", not ":/".
> Unlike push.default, whose warning can be silenced with configurati
Before commit 33f2f9ab, 'commit -s' would populate the edit buffer with
a blank line before the Signed-off-by line. This provided a nice
hint to the user that something should be filled in. Let's restore that
behavior, but now let's ensure that the Signed-off-by line is preceded
by two blank line
Junio C Hamano writes:
> * Introduce "git add --ignore-removal" option in the release after
>the current cycle (a new feature is too late for this cycle):
Too late in the cycle even if the option is simply ignored ... ?
[To extend the range of git versions where it's not an error]
-miles
62 matches
Mail list logo
