Junio C Hamano venit, vidit, dixit 20.02.2013 00:47:
> Scott Chacon writes:
>
>> Junio, are you interested in attending?
>
> I am interested in meeting our European contributors, but Berlin is
> kind of very far, so give me a few days to think about it.
>
> Thanks.
>
Maybe, we can - for the ne
On 02/20/2013 02:39 AM, Jiang Xin wrote:
>
> [SNIP]
>
> I am not familiar with autoconf. After clone autoconf and check,
> I cannot find a neat way to change "htmldir" default location to
> use ${datarootdir} (just like mandir).
>
This one-line change should be enough to do what you want:
diff
>From a pristine master checkout:
$ make configure && ./configure make
... # All successfull
$ touch configure.ac
$ make
GEN config.status
make[1]: Entering directory `/storage/home/stefano/git/src'
GEN config.status
make[2]: Entering directory `/storage/home/stefano/git/src'
On Mon, Feb 18, 2013 at 04:33:31PM -0500, Jeff King wrote:
> On Mon, Feb 18, 2013 at 01:25:35PM -0800, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > But it's easy to do (1), and it starts the clock ticking for
> > > the 1000-byte readers to become obsolete.
> >
> > Yup, I agree with
On Tue, Feb 19, 2013 at 11:44:48PM -0800, Junio C Hamano wrote:
> * jk/smart-http-robustify (2013-02-17) 3 commits
> - remote-curl: sanity check ref advertisement from server
> - remote-curl: verify smart-http metadata lines
> - pkt-line: teach packet_get_line a no-op mode
>
> Parse the HTTP
Jeff King wrote:
>
>In the meantime, please hold off on what I've posted so far (that
>includes the jk/smart-http-robustify topic).
Surely. I'm done for the night already. Looking forward to see the reroll
tomorrow.
Thanks.
--
Pardon terseness, typo and HTML from a tablet.
--
To unsubscribe
On Wed, Feb 20, 2013 at 09:05:46AM +0100, Michael J Gruber wrote:
> Maybe, we can - for the next time - try to coordinate the date with the
> various international IT conferences which take place here, like
> Linux-Tag in Berlin (just a few weeks apart), CEBIT in Hannover or the
> smaller Chemnitz
Commit 1b77d83cab 'setup_git_directory_gently_1(): resolve symlinks in
ceiling paths' changed the setup code to resolve symlinks in the
entries in GIT_CEILING_DIRECTORIES. Because those entries are
compared textually to the symlink-resolved current directory, an entry
in GIT_CEILING_DIRECTORIES th
On Tue, Feb 19, 2013 at 03:40:16PM -0800, Junio C Hamano wrote:
> I am not sure if such a layout can be actually used for installing,
> though. Didn't we see some issues around the relativeness of
> htmldir and mandir vs passing them down to Documentation/Makefile,
> or is it not an issue when ./c
On Tue, 19 Feb 2013, Junio C Hamano wrote:
> Assuming that this says "yes":
>
> D=/afs/athena.mit.edu/user/a/n/andersk/my/dir
> cd "$D"
> test "$(/bin/pwd)" = "$D" && echo yes
Correct.
> Perhaps existing of an empty element in the list would do? E.g.
>
> GIT_CEILING
2013/2/20 Stefano Lattarini :
> On 02/20/2013 02:39 AM, Jiang Xin wrote:
>>
>> [SNIP]
>>
>> I am not familiar with autoconf. After clone autoconf and check,
>> I cannot find a neat way to change "htmldir" default location to
>> use ${datarootdir} (just like mandir).
>>
> This one-line change shoul
On Tue, Feb 19, 2013 at 06:53:07PM -0800, Junio C Hamano wrote:
> Adam Spiers writes:
>
> > OK, thanks for the information. IMHO it would be nice if 'git
> > format-patch' and 'git am' supported this style of inline patch
> > inclusion, but maybe there are good reasons to discourage it?
>
> "gi
Hi,
On Wed, Feb 20, 2013 at 7:50 AM, Shawn Pearce wrote:
> On Mon, Feb 18, 2013 at 9:42 AM, Jeff King wrote:
>> On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:
>>
>>> * We need an org admin. AFAIK this was done by Peff and Shawn in
>>> tandem last year. Would you do it again?
>>
Christian Couder writes:
> - yes, we could improve mentoring by providing better projects and
> insisting even more on submitting earlier
A few words about my experience, not with GSoC, but with school projects
(I've been proposing a few students in Ensimag to contribute to Git each
year since 2
Michael Haggerty writes:
> A while ago, I submitted an RFC for adding a new email notification
> script to "contrib" [1].
We've discussed offline with Michael, a few patches have been merged,
and there are still a few pending pull requests. I liked the script
already, but it's getting even cool
On 02/20/2013 11:42 AM, Jiang Xin wrote:
> 2013/2/20 Stefano Lattarini :
>> On 02/20/2013 02:39 AM, Jiang Xin wrote:
>>>
>>> [SNIP]
>>>
>>> I am not familiar with autoconf. After clone autoconf and check,
>>> I cannot find a neat way to change "htmldir" default location to
>>> use ${datarootdir} (
On Tue, Feb 19, 2013 at 06:47:23PM -0800, Junio C Hamano wrote:
> Adam Spiers writes:
> >> Remove a sweep-the-issue-under-the-rug conditional in check-ignore
> >> that avoided to pass an empty string to the callchain while at it.
> >> It is a valid question to ask for check-ignore if the top-level
On Tue, Feb 19, 2013 at 11:08:29AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > Also, it appears that the `git-rebase--*.sh` handlers don't use the
> > pre-rebase hook. Is this intentional?
>
> The codeflow of git-rebase front-end, when you start rebasing, will
> call run_pre_reba
On Sat, 9 Feb 2013 05:58:47 -0500 John Szakmeister
wrote:
JS> On Thu, Feb 7, 2013 at 9:46 AM, Ted Zlatanov wrote:
>> On Thu, 27 Oct 2011 12:05:03 -0400 John Szakmeister
>> wrote:
>>
JS> Just wanted to keep folks in the loop. It turns out that the Secrets
JS> API is still to young. I asked
"W. Trevor King" writes:
> Since $upstream_arg will always be set, would it make sense to change
> the `${1+"$@"}` syntax in run_pre_rebase_hook() to a plain "$@"?
I suspect that there no longer is a need for ${1+"$@"} in today's
world even when you do not have arguments, and it certainly is fin
Michael Haggerty writes:
> This is a possible implementation (untested!) of Junio's suggestion,
> with the slight twist that the empty entry can appear anywhere in
> GIT_CEILING_DIRECTORIES and only turns off symlink expansion for
> subsequent entries.
Sounds like a good way to go, I think.
Ori
Hi-
I've been investigating the cases where merge is allowed to proceed when
there are staged changes in the index or unstaged files in the working
directory. There are cases where I find the behavior surprising and I
hope I can get clarification. There are also two cases that I will report
as b
Here's another round of my pkt-line fixes. The more I dug, the more
interesting corners I found. :)
There are really several potentially independent topics rolled together
here. There are dependencies between some of them, so I tried to float
the most independent and non-controversial bits to the
When we receive a line like "shallow " from the
client, we feed the part to get_sha1. This is a
mistake, as the argument on a shallow line is defined by
Documentation/technical/pack-protocol.txt to contain an
"obj-id". This is never defined in the BNF, but it is clear
from the text and from the o
This code predates prefixcmp, so it used memcmp along with
static sizes. Replacing these memcmps with prefixcmp makes
the code much more readable, and the lack of static sizes
will make refactoring it in future patches simpler.
Note that we used to be unnecessarily liberal in parsing the
"unpack"
According to the comment, enter_repo will modify its input.
However, this has not been the case since 1c64b48
(enter_repo: do not modify input, 2011-10-04). Drop the
now-useless copy.
Signed-off-by: Jeff King
---
builtin/upload-archive.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletion
The current parsing scheme for upload-archive is to pack
arguments into a fixed-size buffer, separated by NULs, and
put a pointer to each argument in the buffer into a
fixed-size argv array.
This works fine, and the limits are high enough that nobody
reasonable is going to hit them, but it makes t
The write_or_die function will always die on an error,
including EPIPE. However, it currently treats EPIPE
specially by suppressing any error message, and by exiting
with exit code 0.
Suppressing the error message makes some sense; a pipe death
may just be a sign that the other side is not interes
The comment describing the packet writing interface was
originally written above packet_write, but migrated to be
above safe_write in f3a3214, probably because it is meant to
generally describe the packet writing interface and not a
single function. Let's move it into the header file, where
users o
This is just write_or_die by another name. The one
distinction is that write_or_die will treat EPIPE specially
by suppressing error messages. That's fine, as we die by
SIGPIPE anyway (and in the off chance that it is disabled,
write_or_die will simulate it).
Signed-off-by: Jeff King
---
builtin/
Originally we had a single function for reading packetized
data: packet_read_line. Commit 46284dd grew a more "gentle"
form, packet_read, that returns an error instead of dying
upon reading a truncated input stream. However, it is not
clear from the names which should be called, or what the
differe
The packets sent during ref negotiation are all terminated
by newline; even though the code to chomp these newlines is
short, we end up doing it in a lot of places.
This patch teaches packet_read_line to auto-chomp the
trailing newline; this lets us get rid of a lot of inline
chomping code.
As a
Having the packet sizes defined near the packet read/write
functions makes more sense.
Signed-off-by: Jeff King
---
http.c | 1 +
pkt-line.h | 3 +++
sideband.h | 3 ---
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/http.c b/http.c
index d9d1aad..8803c70 100644
--- a/http.c
Most of the callers of packet_read_line just read into a
static 1000-byte buffer (callers which handle arbitrary
binary data already use LARGE_PACKET_MAX). This works fine
in practice, because:
1. The only variable-sized data in these lines is a ref
name, and refs tend to be a lot shorter t
On 02/18/2013 06:42 PM, Jeff King wrote:
>
> I will do it again, if people feel strongly about Git being a part of
> it. However, I have gotten a little soured on the GSoC experience. Not
> because of anything Google has done; it's a good idea, and I think they
> do a fine of administering the pro
The packet_read function reads from a descriptor. The
packet_get_line function is similar, but reads from an
in-memory buffer, and uses a completely separate
implementation. This patch teaches the generic packet_read
function to accept either source, and we can do away with
packet_get_line's implem
Now that we can read packet data from memory as easily as a
descriptor, get_remote_heads can take either one as a
source. This will allow further refactoring in remote-curl.
Signed-off-by: Jeff King
---
Another "wrapper vs NULL argument" opportunity. I could go either way if
we feel strongly in o
Until recently, get_remote_heads only knew how to read refs
from a file descriptor. To hack around this, we spawned a
thread (or forked a process) to write the buffer back to us.
Now that we can just pass it our buffer directly, we don't
have to use this hack anymore.
Signed-off-by: Jeff King
--
The ref-parsing functions are static. Let's move them up in
the file to be available to more functions, which will help
us with later refactoring.
Signed-off-by: Jeff King
---
remote-curl.c | 118 +-
1 file changed, 59 insertions(+), 59 del
When remote-curl receives a list of refs from a server, it
keeps the whole buffer intact. When we get a "list" command,
we feed the result to get_remote_heads, and when we get a
"fetch" or "push" command, we feed it to fetch-pack or
send-pack, respectively.
If the HTTP response from the server is
When the client tells us it has a shallow object via
"shallow ", we make sure we have the object, mark it
with a flag, then add it to a dynamic array of shallow
objects. This means that a client can get us to allocate
arbitrary amounts of memory just by flooding us with shallow
lines (whether they
If you set the GIT_DEBUG_SEND_PACK environment variable,
upload-pack will dump lines it receives in the receive_needs
phase to a descriptor. This debugging harness is a strict
subset of what GIT_TRACE_PACKET can do. Let's just drop it
in favor of that.
A few tests used GIT_DEBUG_SEND_PACK to confi
When we read acks from the remote, we expect either:
ACK
or
ACK
We parse the "ACK " bit from the line, and then start
looking for the flag strings at "line+45"; if we don't have
them, we assume it's of the first type. But if we do have
the first type, then line+45 is not necessarily ins
Edward Thomson writes:
> What was surprising to me was that my merge can proceed if I stage a change
> that is identical to the merge result. That is, if my merge result would
> be to take the contents from "theirs", then my merge can proceed if I've
> already staged the same contents:
>
>in
On 2/20/13 2:21 PM, "Junio C Hamano" wrote:
>Both are very much on purpose. The integrator may have seen the
>patch on the list, ran "git apply [--index]" on it to contemplate on
>it, and before commiting the result, saw a pull request for a branch
>that contains the change. The above two allow
Jeff King wrote:
> The write_or_die function will always die on an error,
> including EPIPE. However, it currently treats EPIPE
> specially by suppressing any error message, and by exiting
> with exit code 0.
>
> Suppressing the error message makes some sense; a pipe death
> may just be a sign tha
On Wed, Feb 20, 2013 at 01:51:11PM -0800, Jonathan Nieder wrote:
> > This distinction doesn't typically matter in git, because we
> > do not ignore SIGPIPE in the first place. Which means that
> > we will not get EPIPE, but instead will just die when we get
> > a SIGPIPE. But it's possible for a d
Jeff King wrote:
> On Wed, Feb 20, 2013 at 01:51:11PM -0800, Jonathan Nieder wrote:
>>> + if (err == EPIPE) {
>>> + signal(SIGPIPE, SIG_DFL);
>>> + raise(SIGPIPE);
>>> + /* Should never happen, but just in case... */
>>> + exit(141);
>>
>> How about
>>
>>
On Wed, Feb 20, 2013 at 02:01:14PM -0800, Jonathan Nieder wrote:
> >> How about
> >>
> >>die("BUG: another thread changed SIGPIPE handling behind my
> >> back!");
> >>
> >> to make it easier to find and fix such problems?
> >
> > You mean for the "should never happen" bit, not the fir
Jeff King wrote:
> On Wed, Feb 20, 2013 at 02:01:14PM -0800, Jonathan Nieder wrote:
How about
die("BUG: another thread changed SIGPIPE handling behind my
back!");
to make it easier to find and fix such problems?
>>>
>>> You mean for the "should never happe
On Wed, Feb 20, 2013 at 02:06:37PM -0800, Jonathan Nieder wrote:
> > I don't mind adding a "BUG: " message like you described, but we should
> > still try to exit(141) as the backup, since that is the shell-equivalent
> > code to the SIGPIPE signal death.
>
> If you want. :)
>
> I think caring a
Edward Thomson writes:
> I also appreciate your explanation of the affect of the workdir,
> and that makes sense. I would have expected that the default was
> to presume the workdir files were existent, rather than the
> other way around, but we can agree that is an implementation detail.
>
> My
Jeff King writes:
> I am more concerned that the assertion is not "oops, another thread is
> doing something crazy, and it is a bug", but rather that there is some
> weird platform where SIG_DFL does not kill the program under SIGPIPE.
> That seems pretty crazy, though. I think I'd squash in some
To talk to a site that serves multiple names on a single IP address,
the client needs to ask for the specific hostname it wants to talk
to. Otherwise, the default certificate returned from the IP address
may not match that of the host we wanted to talk to.
Signed-off-by: Junio C Hamano
---
* I
Git::config() returns `undef` when given keys that do not exist.
Check that the $guitool value is defined to prevent a noisy
"Use of uninitialized variable $guitool in length" warning.
Signed-off-by: David Aguilar
---
Unchanged since v1.
git-difftool.perl | 2 +-
1 file changed, 1 insertion(+),
Signed-off-by: David Aguilar
---
Unchanged since v2.
t/t7800-difftool.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index eb1d3f8..5b5939b 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -1,6 +1,6 @@
#!/bin/sh
#
-
Eliminate a lot of redundant work by using test_config().
Catch more return codes by more use of temporary files
and test_cmp.
The original tests relied upon restore_test_defaults()
from the previous test to provide the next test with a sane
environment. Make the tests do their own setup so that
073678b8e6324a155fa99f40eee0637941a70a34 reworked the
mergetools/ directory so that every file corresponds to a
difftool-supported tool. When this happened the "defaults"
file went away as it was no longer needed by mergetool--lib.
t7800 tests that configured commands can override builtins,
but t
Thanks; will replace and queue.
--
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
David Aguilar writes:
> diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
> index fb00273..21fbba9 100755
> --- a/t/t7800-difftool.sh
> +++ b/t/t7800-difftool.sh
> @@ -60,9 +60,9 @@ test_expect_success PERL 'custom commands' '
> '
>
> test_expect_success PERL 'custom tool commands overri
Junio C Hamano writes:
> To talk to a site that serves multiple names on a single IP address,
> the client needs to ask for the specific hostname it wants to talk
> to. Otherwise, the default certificate returned from the IP address
> may not match that of the host we wanted to talk to.
>
> Signe
On Wed, Feb 20, 2013 at 09:35:16PM -0800, Junio C Hamano wrote:
>> (2) I do not know if everybody has SSL_set_tslext_host_name() macro
>> defined, so this patch may be breaking build for people with
>> different versions of OpenSSL.
> [...]
>
> +#ifdef SSL_CTRL_SET_TLSEXT_HOSTNAME
> +
On Wed, Feb 20, 2013 at 09:44:58AM +0100, Stefano Lattarini wrote:
> From a pristine master checkout:
>
> $ make configure && ./configure make
> ... # All successfull
> $ touch configure.ac
> $ make
> GEN config.status
> make[1]: Entering directory `/storage/home/stefano/git/src'
>
Jeff King writes:
> I can easily replicate it here.
>
>> This seems due to the change in commit v1.7.12.4-1-g1226504: the
>> issue is still present there, but no longer is in the preceding
>> commit 7e201053 (a.k.a. v1.7.12.4).
>>
>> I haven't investigated this any further for the moment.
>
> Hm
On Wed, Feb 20, 2013 at 10:10:42PM -0800, Junio C Hamano wrote:
> I noticed this while looking at the other autoconf patch yesterday,
> but I was otherwise occupied in the evening and did not pursue it
> further. Thanks for looking into it.
Here's the patch with a commit message. I'm pretty sure
Jewellery has been worn by mankind for generations, and meant different
things to different people and cultures. Throughout history human beings
have sought out items with which to adorn themselves, sometimes for
ornament, sometimes for a deeper meaning. Today people tend to have certain
expectatio
Jeff King writes:
> Anyway, here is the patch to fix the loop.
>
> -- >8 --
> Subject: [PATCH] Makefile: avoid infinite loop on configure.ac change
>
> If you are using autoconf and change the configure.ac, the
> Makefile will notice that config.status is older than
> configure.ac, and will attem
67 matches
Mail list logo
