[PATCH] http-walker: remove unused parameter from fetch_object

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 |

Re: Dependencies required for offline installation

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

Fwd: git rm

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

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

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

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

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

Hello..

-- 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

Re: [PATCH v4] Refactor recv_sideband()

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

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

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`

Re: [PATCH 3/5] index-pack: correct "len" type in unpack_data()

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... +

Re: Dependencies required for offline installation

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

[PATCH] difftool: fix argument handling in subdirs

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

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

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

Re: Dependencies required for offline installation

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

Re: Missing Package in git Installation Instructions (git-scm.com)

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.

Re: Dependencies required for offline installation

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: >>

[PATCH 4/5] index-pack: report correct bad object offsets even if they are large

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

[PATCH 2/5] sha1_file.c: use type off_t* for object_info->disk_sizep

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

[PATCH 3/5] index-pack: correct "len" type in unpack_data()

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

[PATCH 5/5] index-pack: correct "offset" type in unpack_entry_data()

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

[PATCH 1/5] pack-objects: pass length to check_pack_crc() without truncation

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

[PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

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

Re: reflogs and worktrees?

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

FEDEX DELIEVERY

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,

reflogs and worktrees?

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 --

Re: [PATCH v2 02/17] Report bugs consistently

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

Re: Missing Package in git Installation Instructions (git-scm.com)

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

Re: [PATCH] add documentation to mw-to-git

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 > + >

Re: [PATCH v2 02/17] Report bugs consistently

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) >

git diff A...B is both overly forgiving and weird

(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

Re: topological index field for commit objects

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

[PATCH] revert: clarify seemingly bogus OPT_END repetition

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

Dependencies required for offline installation

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.

Re: topological index field for commit objects

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

Re: [PATCH 1/9] Report bugs consistently

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

Re: GIT Integration with Siebel

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

[PATCH v2 11/17] am: counteract gender bias

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").

[PATCH v2 12/17] am -3: use merge_recursive() directly again

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

[PATCH v2 07/17] merge-recursive: avoid returning a wholesale struct

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

[PATCH v2 08/17] merge-recursive: allow write_tree_from_memory() to error out

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

[PATCH v2 13/17] merge-recursive: flush output buffer before printing error messages

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

[PATCH v2 09/17] merge-recursive: handle return values indicating errors

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

[PATCH v2 16/17] Ensure that the output buffer is released after calling merge_trees()

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

[PATCH v2 17/17] merge-recursive: flush output buffer even when erroring out

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:

[PATCH v2 05/17] Prepare the builtins for a libified merge_recursive()

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

[PATCH v2 14/17] merge-recursive: write the commit title in one go

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()

[PATCH v2 10/17] merge-recursive: switch to returning errors instead of dying

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

[PATCH v2 06/17] merge_recursive: abort properly upon errors

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

[PATCH v2 15/17] merge-recursive: offer an option to retain the output in 'obuf'

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

[PATCH v2 01/17] Verify that `git pull --rebase` shows the helpful advice when failing

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 @@

[PATCH v2 02/17] Report bugs consistently

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

[PATCH v2 04/17] merge-recursive: clarify code in was_tracked()

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

[PATCH v2 03/17] Avoid translating bug messages

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

[PATCH v2 00/17] Use merge_recursive() directly in the builtin am

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

Re: GIT Integration with Siebel

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

Re: GIT Integration with Siebel

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

Re: split directories into branches

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

GIT Integration with Siebel

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.

Re: Missing Package in git Installation Instructions (git-scm.com)

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 which isn't listed on that site. Can you > fix that or tell me