This parameter has not been used since commit 1d389ab65dc6
("Add support for parallel HTTP transfers") back in 2005
Signed-off-by: Eric Wong
---
I might followup in a few days/weeks with further updates in
this area, but at least should be trivially correct :)
http-walker.c | 4 ++--
1 file c
On Tue, Jul 05, 2016 at 09:53:15PM +0200, Dennis Kaarsemaker wrote:
> On di, 2016-07-05 at 14:06 -0400, Kevin Paxton wrote:
> > Thank you for the response.
> >
> > I apologize. RHEL 6.5, not 5.5.
>
> That's less ancient, but still not recommended. When using RHEL, try to
> stay with the latest po
Greetings to the community of this wonderful piece of software!
I am a lightweigt git user so by all means not a reference, but I was
wondering why exactly does "git rm" also delete the file (remove it
from the working tree). I see it as an unintended behaviour as git is
written in a way that it
On Tue, Jul 5, 2016 at 1:44 PM, Jeff King wrote:
> On Tue, Jul 05, 2016 at 04:28:20PM -0400, Jeff King wrote:
>
>> I wonder if parse_options_concat should simply allocate a new list
>> (after computing the total required size). I guess this is the only
>> caller, though, so perhaps it's not the en
On Tue, Jul 05, 2016 at 04:28:20PM -0400, Jeff King wrote:
> I wonder if parse_options_concat should simply allocate a new list
> (after computing the total required size). I guess this is the only
> caller, though, so perhaps it's not the end of the world. In the
> meantime, your patch is certain
--
Hello,
Can i talk with you..?
--
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 Wed, 29 Jun 2016, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > To make it clearer, here's a patch on top of pu that fixes all the
> > issues I think are remaining. All tests pass now.
>
> Lukas, can you see what is in 'pu' after I push out today's
> integration result in several hour
On Tue, Jul 05, 2016 at 01:58:51PM +0200, Johannes Schindelin wrote:
> This developer stumbled over repeated OPT_END entries and was *so
> close* (almost touches his thumb with his index finger) to collapse
> them into a single one. Only inspecting the file's history with
> `git log -p -SOPT_END`
Am 05.07.2016 um 19:05 schrieb Nguyễn Thái Ngọc Duy:
+ die(Q_("premature end of pack file, %"PRIuMAX" byte
missing",
+ "premature end of pack file, %"PRIuMAX" bytes
missing",
I would be surprised if this form of translation worked...
+
On di, 2016-07-05 at 14:06 -0400, Kevin Paxton wrote:
> Thank you for the response.
>
> I apologize. RHEL 6.5, not 5.5.
That's less ancient, but still not recommended. When using RHEL, try to
stay with the latest point release so you get security updates.
> Would the same version be applicable t
On Mon, Jul 04, 2016 at 08:37:39PM +0200, Bernhard Kirchen wrote:
> Today I started using --dir-diff and noticed a problem when specifying a
> non-full path limiter. My diff tool is setup to be meld (*1).
>
> OK while working directory is repo root; also OK while working directory is
> repo subfol
Thank you very much!
--
With kind regards
Christoph Michelbach
On Tue, 2016-07-05 at 19:05 +0200, Nguyễn Thái Ngọc Duy wrote:
> Since I now could reproduce the problem that Christoph showed, I
> decided to send the good patches out. To sum up, we use "unsigned
> long" in some places related to f
On Tue, 5 Jul 2016 07:45:12 -0400
Kevin Paxton wrote:
> I’m looking to install git on a separate network that is running
> Redhat 5.5. I need to know what is the list of packages that I need to
> download to be able to install git-all? I plan on using git-svn to
> migrate an existing svn repo ove
Thank you both!
I cloned the repository to fix it yet found it already fixed so assumed
either of you did that. But according to git blame, that line was last
touched 94 days ago by Yue Lin Ho and they made exactly that change. It
seems to take a long time until they publish it on the website.
--
Thank you for the response.
I apologize. RHEL 6.5, not 5.5.
Would the same version be applicable to 6.5 as well as the
dependencies that you mentioned?
On Tue, Jul 5, 2016 at 1:53 PM, Dennis Kaarsemaker
wrote:
> On di, 2016-07-05 at 07:45 -0400, Kevin Paxton wrote:
>> Hi,
>>
>> I’m looking to i
On di, 2016-07-05 at 07:45 -0400, Kevin Paxton wrote:
> Hi,
>
> I’m looking to install git on a separate network that is running
> Redhat 5.5.
That's ancient and unsupported. If you insist on using rhel 5, at least
do 5.11 so you get the security updates.
> I need to know what is the list of pa
This field, filled by sha1_object_info() contains the on-disk size of
an object, which could go over 4GB limit of unsigned long on 32-bit
systems. Use off_t for it instead and update all callers.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/cat-file.c | 4 ++--
cache.h| 2 +-
2 fi
On 32-bit systems with large file support, one entry could be larger
than 4GB and overflow "len". Correct it so we can unpack a full entry.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin/inde
unpack_entry_data() receives an off_t value from unpack_raw_entry(),
which could be larger than unsigned long on 32-bit systems with large
file support. Correct the type so truncation does not happen. This
only affects bad object reporting though.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/
Use the right type for offsets in this case, off_t, which makes a
difference on 32-bit systems with large file support, and change
formatting code accordingly.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/index-pack.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/
On 32 bit systems with large file support, unsigned long is 32-bit
while the two offsets in the subtraction expression (pack-objects has
the exact same expression as in sha1_file.c but not shown in diff) are
in 64-bit. If an in-pack object is larger than 2^32 len/datalen is
truncated and we get a m
Since I now could reproduce the problem that Christoph showed, I
decided to send the good patches out. To sum up, we use "unsigned
long" in some places related to file size. On 32-bit systems, it's
limited to 32 bits even though the system can handle files larger than
that (off_t is 64-bit). This f
On Tue, Jul 5, 2016 at 5:07 PM, Johannes Schindelin
wrote:
> Hi Duy,
>
> ever since I started working extensively with worktrees, I end up with
> these funny gc problems, like broken links and stale reflogs.
Yeah we have problem with gc not traversing all worktree refs. I had
something that could
Sehr geehrter Kunde,
Sie haben ein Paket von FedEx am Samstag, den 7. März 2015 um 13:16 Uhr Uhr
Wir haben darauf gewartet, dass Sie uns für Ihre Bestätigte Paket zu
kontaktieren, die unser Büro angekommen zu Ihrem Land ansässigen Versand. Das
Paket wurde von Herrn John "Jack" Lange geschickt, de
Hi Duy,
ever since I started working extensively with worktrees, I end up with
these funny gc problems, like broken links and stale reflogs.
Is it maybe possible that the reflogs (which are per-worktree now) are not
traversed completely when gc'ing (which is *not* per-worktree)?
Ciao,
Dscho
--
T
Hi Kuba,
On Tue, 5 Jul 2016, Jakub Narębski wrote:
> W dniu 2016-07-05 o 13:23, Johannes Schindelin pisze:
> > diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> > index f02e3d2..00ea91a 100644
> > --- a/builtin/ls-files.c
> > +++ b/builtin/ls-files.c
> > @@ -118,7 +118,8 @@ static void show_
W dniu 2016-07-05 o 08:10, Johannes Schindelin pisze:
> Hi Chris,
>
> On Tue, 5 Jul 2016, Christoph Michelbach wrote:
>
>> Hi, I noticed that the instructions on https://git-scm.com/book/en/v2/G
>> etting-Started-Installing-Git don't work without dh-autoreconf
>> installed on an apt-get system wh
Hi, and thanks for your contribution.
Alexandru Zbarcea writes:
> Signed-off-by: Alexandru Zbarcea
> ---
> contrib/mw-to-git/Makefile | 44 -
> contrib/mw-to-git/git-mediawiki.txt| 100
> +
> contrib/mw-to-git/git-remote-mediawi
W dniu 2016-07-05 o 13:23, Johannes Schindelin pisze:
> diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> index f02e3d2..00ea91a 100644
> --- a/builtin/ls-files.c
> +++ b/builtin/ls-files.c
> @@ -118,7 +118,8 @@ static void show_killed_files(struct dir_struct *dir)
>
(This is not a big bug, but it is clearly not right.)
The problem is mostly described in the patch below.
This patch can perhaps be improved a bit by using an abbreviated
hash for the chosen merge base, in the case of multiple merge
bases, and/or by removing some of the paranoia-style checking (b
W dniu 2016-07-05 o 13:43, Johannes Schindelin pisze:
> On Wed, 29 Jun 2016, Jeff King wrote:
>
>> I haven't thought hard specifically about merge bases computation, so
>> perhaps that is a case that isn't helped at all.
>
> I guess it is not helped by generation numbers.
>
> But then, we often
This developer stumbled over repeated OPT_END entries and was *so
close* (almost touches his thumb with his index finger) to collapse
them into a single one. Only inspecting the file's history with
`git log -p -SOPT_END` clarified why they are there.
This confusion can be easily prevented by inser
Hi,
I’m looking to install git on a separate network that is running
Redhat 5.5. I need to know what is the list of packages that I need to
download to be able to install git-all? I plan on using git-svn to
migrate an existing svn repo over to git as well. Svn version we have
installed is 1.9.3.
Hi Peff,
On Wed, 29 Jun 2016, Jeff King wrote:
> I haven't thought hard specifically about merge bases computation, so
> perhaps that is a case that isn't helped at all.
I guess it is not helped by generation numbers.
But then, we often ask: "is commit A an ancestor of commit B" e.g. to
check w
Hi Duy,
On Sat, 2 Jul 2016, Duy Nguyen wrote:
> You're changing the string and adding more work to translators. So
> either leave the string untouched, or drop _().
Thanks. I addressed that concern in v2. Could you please now have a look at
the parts of the patch series which could possibly regr
Hi Tarun,
On Tue, 5 Jul 2016, tarun patanwar wrote:
> Siebel is a Oracle Product for CRM implementation, just like SAP and
> SalesForce. So Siebel as a product provides option to integrate any
> third party Source Control tool with it.
>
> Integration between Siebel and Source Control tool is fa
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
almost 11 years already, we demonstrated our disrespect to the pioneers
of software development like Ada Lovelace, Grace Hopper and Margaret
Hamilton, by pretending that each and every software developer is male
("his_tree").
Last October, we had to change this code to run `git merge-recursive`
in a child process: git-am wants to print some helpful advice when the
merge failed, but the code in question was not prepared to return, it
die()d instead.
We are finally at a point when the code *is* prepared to return errors,
It is technically allowed, as per C89, for functions' return type to
be complete structs (i.e. *not* just pointers to structs).
However, it was just an oversight of this developer when converting
Python code to C code in 6d297f8 (Status update on merge-recursive in
C, 2006-07-08) which introduced
It is possible that a tree cannot be written (think: disk full). We
will want to give the caller a chance to clean up instead of letting
the program die() in such a case.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
The data structure passed to the recursive merge machinery has a feature
where the caller can ask for the output to be buffered into a strbuf, by
setting the field 'buffer_output'.
Previously, we simply swallowed the buffered output when showing error
messages. With this patch, we show the output
The recursive merge machinery accumulates its output in an output
buffer, to be flushed at the end of merge_recursive(). At this point,
we forgot to release the output buffer.
When calling merge_trees() (i.e. the non-recursive part of the recursive
merge) directly, the output buffer is never flush
We are about to libify the recursive merge machinery, where we only
die() in case of a bug or memory contention. To that end, we must heed
negative return values as indicating errors.
This requires our functions to be careful to pass through error
conditions in call chains, and for quite a few fun
In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we
changed the code such that it prints the output in one go, to avoid
interfering with the progress output.
Let's make sure that the same holds true when outputting the commit
title: previously, we used several printf() stateme
The recursive merge machinery is supposed to be a library function, i.e.
it should return an error when it fails. Originally the functions were
part of the builtin "merge-recursive", though, where it was simpler to
call die() and be done with error handling.
The existing callers were already prepa
There are a couple of places where return values indicating errors
are ignored. Let's teach them manners.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 66ce27c..7
Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14),
we already accumulate the output in a buffer. The idea was to avoid
interfering with the progress output that goes to stderr, which is
unbuffered, when we write to stdout, which is buffered.
We extend that buffering to allow
Ever since 66a155b (Enable output buffering in merge-recursive.,
2007-01-14), we had a problem: When the merge failed in a fatal way, all
regular output was swallowed because we called die() and did not get a
chance to drain the output buffers.
To fix this, several modifications were necessary:
-
Previously, callers of merge_trees() or merge_recursive() expected that
code to die() with an error message. This used to be okay because we
called those commands from scripts, and had a chance to print out a
message in case the command failed fatally (read: with exit code 128).
As scripting incur
Signed-off-by: Johannes Schindelin
---
t/t5520-pull.sh | 30 ++
1 file changed, 30 insertions(+)
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 3159956..b281d6f 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -255,6 +255,36 @@ test_expect_success '--rebase
The vast majority of error messages in Git's source code which report a
bug use the convention to prefix the message with "BUG:".
As part of cleaning up merge-recursive to stop die()ing except in case of
detected bugs, let's just make the remainder of the bug reports consistent
with the de facto r
It can be puzzling to see that was_tracked() asks to get an index entry
by name, but does not take a negative return value for an answer.
The reason we have to do this is that cache_name_pos() only looks for
entries in stage 0, even if nobody asked for any stage in particular.
Let's rewrite the l
While working on the patch series that avoids die()ing in recursive
merges, the issue came up that bug reports (i.e. die("BUG: ...")
constructs) should never be translated, as the target audience is the
Git developer community, not necessarily the current user, and hence
a translated message would
This is the second iteration of the long-awaited re-roll of the attempt to
avoid spawning merge-recursive from the builtin am and use merge_recursive()
directly instead.
The *real* reason for the reroll is that I need a libified recursive
merge to accelerate the interactive rebase by teaching the
Hi Johannes,
Thanks for getting back.
Siebel is a Oracle Product for CRM implementation, just like SAP and
SalesForce. So Siebel as a product provides option to integrate any
third party Source Control tool with it.
Integration between Siebel and Source Control tool is facilitated by
the batch f
Hi Tarun,
On Tue, 5 Jul 2016, tarun patanwar wrote:
> We are trying to integrate GIT with Siebel 8.1 for source code control.
> We are not able to progress further since there seems to be no
> documentation available for the same.
Would you kindly explain what Siebel is, and what purpose the bat
On Mon, 4 Jul 2016 17:03:46 -0400
shawn wilson wrote:
[...]
> > I don't possess the official stance on this topic but AFAIK
> > user-level questions are fine on this list.
>
> In that case :)
> ... still having issues w/ filter-branch:
[...]
I used something along these lines:
git filter-bra
Dear GIT Team,
We are trying to integrate GIT with Siebel 8.1 for source code
control. We are not able to progress further since there seems to be
no documentation available for the same.
Siebel provides a batch control file (srcctrl.bat) which can be
amended for Source Control Toll integration.
58 matches
Mail list logo