On Fri, Nov 07, 2014 at 05:13:47PM +0700, Duy Nguyen wrote:
By the way, one other thing I wondered while looking at this code: when
we checkout a working tree file, we unlink the old one and write the new
one in-place. Is there a particular reason we do this versus writing to
a temporary
On Fri, Nov 07, 2014 at 09:14:42AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Is there a reason that we don't use this diff technique for checkout?
I suspect that the reasons are probably mixture of these:
(1) the code path may descend from checkout-index
On Fri, Nov 07, 2014 at 07:50:49PM +0100, Christian Couder wrote:
diff --git a/trailer.c b/trailer.c
index 761b763..f4d51ba 100644
--- a/trailer.c
+++ b/trailer.c
@@ -583,8 +583,12 @@ static int parse_trailer(struct strbuf *tok, struct
strbuf *val, const char *tra
strbuf_addch(seps,
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
I think that has direct linkage; what you have in mind I think is
http://thread.gmane.org/gmane.comp.version-control.git/234903/focus=234935
Thanks for that link.
I did spend a few hours on this topic earlier today, and got very
On Sat, Nov 08, 2014 at 03:30:40AM -0500, Jeff King wrote:
So just to be clear, the behavior we want is that:
echo foo some-new-path
git add some-new-path
git checkout HEAD -- .
will delete some-new-path (whereas the current code turns it into an
untracked file). What should
On Fri, Nov 07, 2014 at 04:31:08PM +0100, Christian Halstrick wrote:
In a repo where no remote.name.fetch config parameter is set what
should a git fetch do? My experiments let me think it's
HEAD:FETCH_HEAD. Right?
Basically, yes. We always write FETCH_HEAD, regardless of the refspec.
We
On Sat, Nov 08, 2014 at 11:44:39AM +0100, Thomas Quinot wrote:
It may be impractical to install a wrapper script for ssh
when additional parameters need to be passed. Provide an
alternative way of specifying these by means of the GIT_SSH_ARGS
environment variable. Arguments are whitespace
On Fri, Nov 07, 2014 at 02:58:17PM +0100, Johannes Schindelin wrote:
Under certain circumstances, it makes a *lot* of sense to allow pushing
into the current branch. For example, when two machines with different
Operating Systems are required for testing, it makes much more sense to
On Sat, Nov 08, 2014 at 11:28:32AM -0800, Michael Blume wrote:
When I build and run tests I get
[11:17][michael.blume@tcc-michael-4:~/workspace/git/t(master)]$
./t1410-reflog.sh
What does ./t1410-reflog.sh -v -i report?
A quick search seems to indicate the test is pretty new?
On Sat, Nov 08, 2014 at 08:43:54PM -0500, Jeff King wrote:
Unfortunately I don't have an OS X install handy to test on.
I lied; it turns out I still had access to an old VM. The problem did
turn out to be rather silly. Here's a patch.
-- 8 --
Two tests recently added to t1410 create branches
On Sun, Nov 09, 2014 at 01:05:31AM +0100, Manzur Mukhitdinov wrote:
When object is replaced with itself git shows unhelpful messages like(git
log):
fatal: replace depth too high for object SHA1
Prevents user from replacing object with itself(with test for checking
this case).
I
On Sat, Nov 08, 2014 at 08:19:21AM -0800, Martin von Zweigbergk wrote:
What should:
git checkout HEAD -- some-new-path
do in that case? With the current code, it actually barfs, complaining
that nothing matched some-new-path (because it is not part of HEAD, and
therefore we don't
On Sat, Nov 08, 2014 at 03:27:53PM +0100, Thomas Quinot wrote:
It may be impractical to install a wrapper script for GIT_SSH
when additional parameters need to be passed. Provide an alternative
way of specifying a shell command to be run, including command line
arguments, by means of the
the path A/B in the working tree.
There's no conflict on a case-sensitive filesystem, but on a
case-insensitive one, git log will complain that a/b is
both a revision and a working tree path.
We can fix this by using -- to disambiguate.
Signed-off-by: Jeff King p...@peff.net
---
t/t1410-reflog.sh
On Sun, Nov 09, 2014 at 08:48:06PM -0500, Brian Gernhardt wrote:
A pair of recently added tests used branches a and a/b, but earlier
tests created files A and A/B. On case insensitive filesystems (such
as HFS+), that causes git to complain about the name being ambiguous
between branch and
On Sun, Nov 09, 2014 at 09:48:29AM -0800, Junio C Hamano wrote:
Michael Blume blume.m...@gmail.com writes:
Works for me, thanks =)
I'm curious now, is there an automated build of git running on a mac
anywhere? There's a mac mini running jenkins in my office and it's
possible I could
nor defined, causing
the compiler to complain.
Signed-off-by: Jeff King p...@peff.net
---
On top of br/imap-send-via-libcurl. I needed this to compile 'pu' with
NO_CURL (which I don't usually do, but was testing on a minimal box). I
expect it can just be squashed in to the next re-roll.
Since we
|-alternation, even when backslash escaped. Some versions can turn on
extended regexps with a special option, but of course that option is not
standard, either. Let's just write out our alternates longhand.
Signed-off-by: Jeff King p...@peff.net
---
On top of the tr/remerge-diff topic
On Sun, Nov 09, 2014 at 10:47:52PM -0800, Junio C Hamano wrote:
On Sun, Nov 9, 2014 at 10:30 PM, Jeff King p...@peff.net wrote:
I know you make test before pushing out the results of any integration
you do. And I recall that for a while (and maybe still?) you even did so
on VMs of a few
On Sun, Nov 09, 2014 at 11:42:32PM +0100, Thomas Quinot wrote:
It may be impractical to install a wrapper script for GIT_SSH
when additional parameters need to be passed. Provide an alternative
way of specifying a shell command to be run, including command line
arguments, by means of the
initialization by mistake.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Rene Scharfe l@web.de
---
trailer.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Thanks, both this one and the other you just sent (to use
child_process.args in more places) look good to me.
-Peff
On Mon, Nov 10, 2014 at 01:39:47AM -0500, Jeff King wrote:
On top of br/imap-send-via-libcurl. I needed this to compile 'pu' with
NO_CURL (which I don't usually do, but was testing on a minimal box). I
expect it can just be squashed in to the next re-roll.
Oops, just started reading through
On Mon, Nov 10, 2014 at 07:47:32PM +1100, Bryan Turner wrote:
First change: git update-ref -d /refs/heads/nonexistent
some-valid-sha1 now produces an error about ref locking that it
didn't produce before
Git 2.1.x and prior produced this output:
error: unable to resolve reference
On Mon, Nov 10, 2014 at 07:51:00PM +1100, Bryan Turner wrote:
Second change: git gc --auto now fails if there are loose empty blobs.
We have a test which just touched empty files in objects/17 to trigger
the gc --auto preconditions (Note: I realize this is completely
invalid, and I've
On Tue, Nov 11, 2014 at 02:40:19AM +0100, Johan Herland wrote:
This and all other failures are due to the output of 'wc -l', which on
Mac is {whitespace}1 rather than just 1 as it is on other
platforms. fbe4f748 added quotes around the $(... | wc -l) invocation
which caused the whitespace
On Mon, Nov 10, 2014 at 02:43:10PM -0800, Junio C Hamano wrote:
Explicitly declare that git_atexit_dispatch() and git_atexit_clear()
take no parameters instead of leaving their parameter list empty and
thus unspecified.
[...]
I was kind of surprised after running a git blame to find
On Tue, Nov 11, 2014 at 12:20:56AM +0100, Manzur Mukhitdinov wrote:
When object is replaced with itself git shows unhelpful messages like(git
log):
fatal: replace depth too high for object SHA1
Prevents user from replacing object with itself(with test for checking
this case).
Thanks,
On Mon, Nov 10, 2014 at 01:44:24PM -0800, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
In start_command(), unset env fields are initialized via env_array. In
finish_command(), the env_array is cleared, therefore the env field
will point to free()d data.
On Mon, Nov 10, 2014 at 03:41:09PM +0100, Johannes Schindelin wrote:
However, start_command() will set env to env_array.argv only if env
was unset to begin with, and if it was already set, the caller will need
the original value. Therefore, we need to be very careful only to reset
env in
On Tue, Oct 21, 2014 at 01:36:47PM -0700, Ronnie Sahlberg wrote:
commit e193c10fc4f9274d1e751cfcdcc4507818e8d498 upstream.
Change lock_ref_sha1_basic to return an error instead of dying when
we fail to lock a file during a transaction.
This function is only called from transaction_commit()
[+cc git@vger, since this may be of interest to others]
On Tue, Nov 11, 2014 at 02:40:59PM -0800, Scott Baker wrote:
I'd like to recreate the github style diffs on the command line. It
appears that your diff-highlight is very close. The current version only
allows you to invert the colors
On Wed, Nov 12, 2014 at 11:45:19AM +0100, Johannes Schindelin wrote:
Okay, I have to say that I was led to believe that reusing the
child_process struct is okay because argv_array_clear() explicitly
reinitializes the env_array field, something that is useless churn unless
you plan to reuse
On Wed, Nov 12, 2014 at 05:52:29AM -0500, Jeff King wrote:
However, my personal taste says that reusing the same memory is more
elegant than to waste extra memory unnecessarily, so I will go with the
child_process_init() solution.
I do not mind much either way. But I doubt that a single
On Wed, Nov 12, 2014 at 09:20:22PM +0100, Johannes Sixt wrote:
Am 09.11.2014 um 02:59 schrieb Jeff King:
test_expect_success 'stale dirs do not cause d/f conflicts (reflogs off)' '
- test_when_finished git branch -d a || git branch -d a/b
+ test_when_finished git branch -d one || git
On Thu, Nov 13, 2014 at 09:50:24AM +0100, Johannes Sixt wrote:
That looks more like it is failing the actual test (i.e., the creation
of branch one when there is cruft in the reflog). My guess is that
calling open() on a directory is giving us EACCES instead of EISDIR. Can
you verify that?
On Thu, Nov 13, 2014 at 08:36:07AM +0100, Torsten Bögershausen wrote:
A URL like file;//. is (no longer) supported by Git:
Typically there is no host, and RFC1738 says that file:///path
should be used.
Update t5705 to use a working URL.
Interesting. This looks like it was unintentionally
On Thu, Nov 13, 2014 at 11:27:06AM +1100, Colin Smith wrote:
Apologies if this has already been raised or PEBCAK, but I've noticed
a bug where git log with certain date ranges breaks things. It appears
to be any --since date with a --until date in the future between
2014-12-01 and 2014-12-09.
On Thu, Nov 13, 2014 at 04:36:06AM -0500, Jeff King wrote:
On Thu, Nov 13, 2014 at 11:27:06AM +1100, Colin Smith wrote:
Apologies if this has already been raised or PEBCAK, but I've noticed
a bug where git log with certain date ranges breaks things. It appears
to be any --since date
in the future. Let's make sure that the now override makes
it to that spot, too, so we can consistently test that
feature.
Signed-off-by: Jeff King p...@peff.net
---
This code path also gets called from the more-strict parse_date (which
does not know about the current time). This continues to call
, as that is consistent with what we use elsewhere
in git.
[1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
[2] http://en.wikipedia.org/wiki/Calendar_date
Reported-by: Colin Smith colin.web...@gmail.com
Signed-off-by: Jeff King p...@peff.net
---
I did not single out -mm
On Thu, Nov 13, 2014 at 04:59:12PM +0600, Alex Kuleshov wrote:
i just got git from master (f6f61cbbad0611e03b712cc354f1665b5d7b087e),
built and installed it successfully, now i'm running make test and got
following error:
*** t9902-completion.sh ***
t9902-completion.sh: 118:
On Thu, Nov 13, 2014 at 05:34:50PM +0600, Alex Kuleshov wrote:
I'm using ubuntu 14.04 x86_64 and bash GNU bash, version
4.3.11(1)-release (x86_64-pc-linux-gnu).
I didn't applied any patches to bash for all time since i installed
system. so it reall weird
I tried on a fresh install of
On Sun, Nov 09, 2014 at 09:21:49AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Fri, Nov 07, 2014 at 11:35:59PM -0800, Junio C Hamano wrote:
I think that has direct linkage; what you have in mind I think is
http://thread.gmane.org/gmane.comp.version-control.git
On Sun, Jul 07, 2013 at 10:49:46AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Perhaps we need
git cat-file --batch-format=%(disk-size) %(object)
or similar.
I agree with your reasoning. It may be simpler to give an interface
to ask for which pieces of info
On Mon, Jul 08, 2013 at 07:07:01PM +0530, Ramkumar Ramachandra wrote:
There's also syntax sharing. I don't think each command should have
its own syntax. f-e-r already has %(objectsize). If we plan to have a
common syntax, perhaps %(disk-size) should be %(objectsize:disk) or
something.
Here's a re-roll of the cat-file --batch-disk-sizes series.
The main change is that it replaces the --batch-disk-sizes option with a
format string for --batch-check, syntactically modeled after the
for-each-ref format string.
[01/10]: zero-initialize object_info structs
[02/10]: teach
to
be updated to explicitly turn off the new ones (by setting
them to NULL). Instead, let's teach each caller to
zero-initialize the struct, so that they do not have to
learn about each new query item added.
Signed-off-by: Jeff King p...@peff.net
---
sha1_file.c | 2 +-
streaming.c | 2 +-
2 files changed, 2
).
This patch adds a disk_sizep field to struct object_info,
and fills it in during sha1_object_info_extended if it is
non-NULL.
Signed-off-by: Jeff King p...@peff.net
---
cache.h | 1 +
sha1_file.c | 20
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git
In modern tests, we typically put output into a file and
compare it with test_cmp. This is nicer than just comparing
via test, and much shorter than comparing via test and
printing a custom message.
Signed-off-by: Jeff King p...@peff.net
---
I didn't do the whole file, just the ones
We currently use an int to tell us whether --batch parsing
is on, and if so, whether we should print the full object
contents. Let's instead factor this into a struct, filled in
by callback, which will make further batch-related options
easy to add.
Signed-off-by: Jeff King p...@peff.net
lead
to extra work, but it should be dwarfed by the cost of
actually accessing the object itself. In my measurements,
there was a 1-2% slowdown when using --batch on a large
number of objects.
Signed-off-by: Jeff King p...@peff.net
---
builtin/cat-file.c | 41
the interface as
consistent as possible, and may help later on if the
implementations are unified.
Signed-off-by: Jeff King p...@peff.net
---
If the 1% slowdown in the streaming blob patch is too much, the simplest
thing would be to have this formatting apply only to --batch-check, and
let --batch
be the case for non-trivial objects).
Signed-off-by: Jeff King p...@peff.net
---
Documentation/git-cat-file.txt | 18 ++
builtin/cat-file.c | 6 ++
2 files changed, 24 insertions(+)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
a
true uint32_t.
While we're at it, we can fix the binary search not to
overflow in such a case if our unsigned is 32 bits.
Signed-off-by: Jeff King p...@peff.net
---
I didn't look farther in the pack code to see if we have other
problematic instances. So there may be others lurking, but these ones
:
before after
real0m0.046s 0m0.017s
user0m0.036s 0m0.012s
sys 0m0.008s 0m0.000s
Signed-off-by: Jeff King p...@peff.net
---
I changed a few things from the original, including:
1. We take an unsigned number of objects to match the fix in the
last patch.
2. The 16
On Wed, Jul 10, 2013 at 07:55:57AM -0400, Jeff King wrote:
5. We use memcpy instead of an open-coded loop to copy the whole array
at the end. The individual bucket-assignment is still done by
struct assignment. I haven't timed if memcpy would make a
difference there.
I just
On Wed, Jul 10, 2013 at 06:47:49PM +0530, Ramkumar Ramachandra wrote:
For a 64-bit off_t, using 16-bit digits gives us k=4.
Wait, isn't off_t a signed data type? Did you account for that in
your algorithm?
It is signed, but the values we are storing in the revindex are all
positive file
On Wed, Jul 10, 2013 at 10:10:16AM -0700, Brandon Casey wrote:
On the linux.git repo, with about 3M objects to sort, this
yields a 400% speedup. Here are the best-of-five numbers for
running echo HEAD | git cat-file --batch-disk-size, which
is dominated by time spent building the pack
On Wed, Jul 10, 2013 at 08:21:15PM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
+If `--batch` or `--batch-check` is given, `cat-file` will read objects
+from stdin, one per line, and print information about them.
+
+You can specify the information shown for each object by using
objects), the
speedup goes away entirely, as the small advantage of the
radix sort gets erased by the book-keeping costs (and at
those sizes, the cost to generate the the rev-index gets
lost in the noise anyway).
Signed-off-by: Jeff King p...@peff.net
---
pack-revindex.c | 100
On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:
The newest test in t0008 streaming support for --stdin, seems to
hang sporadically on my MacBook Pro (running 10.8.4). The hang seems
to be related to running it in parallel with other tests, as I can
only reliably cause it by
On Thu, Jul 11, 2013 at 07:36:53AM -0400, Jeff King wrote:
On Wed, Jul 10, 2013 at 08:59:51PM +0530, Ramkumar Ramachandra wrote:
Jeff King wrote:
git rev-list --objects HEAD |
git cat-file --batch-check='%(objectsize) %(text)'
If anything, I would have expected %(rest
In my earlier series introducing git cat-file --batch-check=format,
found here:
http://thread.gmane.org/gmane.comp.version-control.git/229761/focus=230041
I spent a little time optimizing revindex generation, and measured by
requesting information on a single object from a large repository.
for
the warning.
Signed-off-by: Jeff King p...@peff.net
---
The solution feels a little hacky, but I'm not sure there is a better
one short of reverting the warning entirely.
We could also tie it to warn_ambiguous_refs (or add another config
variable), but I don't think that makes sense
The value we get from each low-level object_info function
(e.g., loose, packed) is actually the object type (or -1 for
error). Let's explicitly call it type, which will make
further refactorings easier to read.
Signed-off-by: Jeff King p...@peff.net
---
sha1_file.c | 20 ++--
1
(and the return value is 0 or -1 for
success or error, respectively).
There should be no functional change yet, though, as
sha1_object_info_extended, the only caller, will always ask
for a type.
Signed-off-by: Jeff King p...@peff.net
---
Obviously the end goal is to have sha1_object_info_extended do
these types. The function will now return the
representation type (or OBJ_BAD on failure), and will only
optionally fill in the true type.
There should be no behavior change yet, as the only caller,
sha1_object_info_extended, will always feed it a type
pointer.
Signed-off-by: Jeff King p
optional in the
future (and keep our indentation level sane).
Signed-off-by: Jeff King p...@peff.net
---
Annoyingly, since the part we are moving comprises the bulk
of the function, the diff tends to show the opposite of what
actually happened: it looks like we renamed the function to its helper
name
Signed-off-by: Jeff King p...@peff.net
---
This ends up changing the behavior of sha1_object_info_extended without
changing its function signature. Given that it is a fairly inactive area
of the code and that there are no topics in flight, I think this is OK.
But an alternative could be to add (yet
later easier.
Signed-off-by: Jeff King p...@peff.net
---
This one is an optional cleanup. The diff is quite noisy due to all of
the s/foo/oi-foo/, so it is arguable whether the result is nicer or
not. It would make later additions to object_info nicer, but I do not
plan to add any more.
It _would_
On Fri, Jul 12, 2013 at 10:47:46AM +0200, Michael Haggerty wrote:
The solution feels a little hacky, but I'm not sure there is a better
one short of reverting the warning entirely.
We could also tie it to warn_ambiguous_refs (or add another config
variable), but I don't think that
On Thu, Jul 11, 2013 at 02:50:03PM -0700, Kyle J. McKay wrote:
The url value is considered a match to a url if the url value
is either an exact match or a prefix of the url which ends on a
path component boundary ('/'). So https://example.com/test; will
match https://example.com/test; and
cursory
read-through, and I don't see any problems. So:
Acked-by: Jeff King p...@peff.net
-Peff
--
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, Jul 11, 2013 at 09:09:55AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Wed, Jul 10, 2013 at 12:36:40PM -0400, Brian Gernhardt wrote:
The newest test in t0008 streaming support for --stdin, seems to
hang sporadically on my MacBook Pro (running 10.8.4
On Fri, Jul 12, 2013 at 10:23:34AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The results for running (in linux.git):
$ git rev-list --objects --all objects
$ git cat-file --batch-check='%(objectsize:disk)' objects /dev/null
I can see how these patches are very
On Fri, Jul 12, 2013 at 09:23:54AM -0700, Junio C Hamano wrote:
In that case, check-ignore gets a SIGPIPE and dies. The
outer shell then tries to open the output fifo but blocks
indefinitely, because there is no writer. We can fix it by
keeping a descriptor open through the whole
On Fri, Jul 12, 2013 at 09:10:30AM -0700, Junio C Hamano wrote:
You can fix it with -Wno-zero-format-length, so the hassle is not
huge. But I am also inclined to just drop this one. We have lived
without the extra safety for a long time, and list review does tend to
catch such problems in
On Sun, Jul 14, 2013 at 08:45:37PM -0700, Junio C Hamano wrote:
To cat-file we could add an option like --sha1-only or --literal or
--no-dwim (... better names are failing me) which would skip *all*
dwimming of 40-character strings. It would also assume that any shorter
strings are
On Fri, Jul 12, 2013 at 12:30:07PM +0200, Michael Haggerty wrote:
But with particular respect to git cat-file, I see problems:
1. get_ref_snapshot() would have to read all loose and packed refs
within the specified subtree, because loose refs have to be read before
packed refs. So the call
On Fri, Jul 12, 2013 at 06:07:35AM -0700, Kyle J. McKay wrote:
It looks like you're matching the URLs as raw strings, and I don't see
any canonicalization going on. What happens if I have
https://example.com/foo+bar; in my config, but then I visit
https://example.comfoo%20bar;?
The
On Sat, Jul 13, 2013 at 12:46:17PM -0700, Kyle J. McKay wrote:
I expect it will be easier just to normalize the URL without
splitting. That is, lowercase the parts that are case-insensitive
(scheme and host name) and adjust the URL-escaping to remove URL
escaping (%xx) from characters that
On Sun, Jul 14, 2013 at 09:02:19PM -0700, Junio C Hamano wrote:
Or proceed with what's there right now (there are a few pending
updates from reviewers) and then, as Junio says above, adjust it later
if needed?
I have been assuming that strictly textual match will be a subset
of the
On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
Am 7/15/2013 19:31, schrieb Ramsay Jones:
Sparse issues three Using plain integer as NULL pointer warnings.
Each warning relates to the use of an '{0}' initialiser expression
in the declaration of an 'struct object_info'.
I
the warnings, we conditionally
define the GIT_SENTINEL macro to provide the sentinel attribute
for gcc v4.0 and newer.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Acked-by: Jeff King p...@peff.net
-__attribute__((sentinel))
+GIT_SENTINEL(0)
void argv_array_pushl(struct argv_array
On Fri, Jul 19, 2013 at 12:40:55PM -0700, Junio C Hamano wrote:
Andreas Schwab sch...@linux-m68k.org writes:
Rahul Bansal rahul.ban...@rtcamp.com writes:
IMHO git tag is expected to show tag-list ordered by versions.
A git tag can be anything, not related to versions at all.
On Tue, Jul 23, 2013 at 10:06:05PM +0200, Fredrik Gustafsson wrote:
Confirmed (tested both with and without trailing /, IIRC there was some
configuration change recently that effect that):
iveqy@kolya:~/slask/git$ git clone
https://git.kernel.org/cgit/git/git.git/
Klonar till git...
error:
On Mon, Jul 22, 2013 at 01:24:06PM -0700, Kyle J. McKay wrote:
I am not yet convinced that the precedence rule specified in this
what we want (I do not have an example why it is *not* what we want,
either). Another definition could be if user@ is present in the
request, give lower precedence
On Mon, Jul 22, 2013 at 05:56:44AM -0700, Kyle J. McKay wrote:
+ matches a url if it refers to the same scheme, host and port and the
+ path portion is an exact match or a prefix that matches at a /
+ boundary. If url does not include a user name, it will match a url
+ with
On Mon, Jul 22, 2013 at 05:56:43AM -0700, Kyle J. McKay wrote:
In order to perform sane URL matching for http.url.* options,
http.c normalizes URLs before performing matches.
A new test-url-normalize test program is introduced along with
a new t5200-url-normalize.sh script to run the tests.
On Mon, Jul 22, 2013 at 05:56:41AM -0700, Kyle J. McKay wrote:
+enum http_option_type {
+ OPT_POST_BUFFER,
+ OPT_MIN_SESSIONS,
+ OPT_SSL_VERIFY,
+ OPT_SSL_TRY,
+ OPT_SSL_CERT,
+ OPT_SSL_CAINFO,
+ OPT_LOW_SPEED,
+ OPT_LOW_TIME,
+ OPT_NO_EPSV,
+
On Mon, Jul 15, 2013 at 07:25:19PM +0700, Nguyen Thai Ngoc Duy wrote:
I noticed that quiet and agent capabilities were missing in
protocol-capabilitities.txt. I have a rough idea what they do, but I
think it's best to be documented by the authors. Maybe you have some
time to make a patch?
The report-status capability is understood by receive-pack,
not upload-pack.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/protocol-capabilities.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/protocol-capabilities.txt
b
not mention it
explicitly. Let's do so.
Note that receive-pack does not understand side-band, which
was obsolete by that point.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/protocol-capabilities.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation
This was added in c207e34 (fix push --quiet: add 'quiet'
capability to receive-pack, 2012-01-08) but never
documented.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/protocol-capabilities.txt | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
This was added in ff5effd (include agent identifier in
capability string, 2012-08-03), but neither the syntax nor
the semantics were ever documented outside of the commit
message.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/technical/protocol-capabilities.txt | 17
On Wed, Jul 24, 2013 at 12:01:26PM -0700, Kyle J. McKay wrote:
Right now, the values are only available as various strings, ints,
longs etc. which have to be formatted differently for output. The
original string value they were converted from is gone. The snippet
shown above only shows some
on the list; the comment should
have been removed from the latter commit.
Signed-off-by: Jeff King p...@peff.net
---
Not that important, really. I only bothered tracking down the source of
the error because I was curious if it was a mis-merge or something. But
nope, just me screwing up, and missing
On Thu, Jul 25, 2013 at 08:29:05PM +0200, Ondřej Bílka wrote:
One solution would be to use same trick as was done in google code.
Build and keep database of trigraphs and which files contain how many of
them. When querry is made then check
only these files that have appropriate combination of
On Thu, Jul 25, 2013 at 03:39:13PM -0700, Kyle J. McKay wrote:
Overhaul the text of the http.url.* options documentation
providing a hopefully easier to understand itemized list of
matching behavior as suggested by and including text from
Jeff King.
---
Signed-off-by: Jeff King p
On Fri, Jul 26, 2013 at 07:39:37PM +0200, Carlos Martín Nieto wrote:
A command of e.g.
git push --set-upstream /tmp/t master
will call install_branch_config() with a remote name of /tmp/t. This
function will set the 'branch.master.remote' key to, which is
nonsensical as there is no
1101 - 1200 of 13736 matches
Mail list logo
