Hi all,
This simple two-line patch fixes a bug that makes gitweb unusable on
systems where the installed CGI.pm is version 4.04 or later (such as on
Debian unstable). That version removed the startform method, which had
previously been deprecated in favour of start_form since 2009.
I don't h
On Thu, Oct 16, 2014 at 2:13 AM, Ben Aveling wrote:
> On 14/10/2014 19:21, Jeff King wrote:
>> On Mon, Oct 13, 2014 at 09:37:27AM +1100, Ben Aveling wrote:
>>> A question about fsck - is there a reason it doesn't have an option to
>>> delete bad objects?
>>
>> If the objects are reachable, then de
Hi
I downloaded and started to Install Git.
There is a Virus on you setup.
Program that appears to have trojan-like features or behavior.
Git/bin/pdfinfo.exe
trojan.generic.[variant], gen:trojan.[variant]
Why???
Br.
Risto
--
To unsubscribe from this list: send the line "unsubscribe git" in
On Thu, 16 Oct 2014 12:35:33 +0300 (EEST)
"risto.makini...@pp.inet.fi" wrote:
> I downloaded and started to Install Git.
>
> There is a Virus on you setup.
> Program that appears to have trojan-like features or behavior.
>
> Git/bin/pdfinfo.exe
>
> trojan.generic.[variant], gen:trojan.[variant
Ben Aveling writes:
> And that seems sensible to me - the object is corrupt, it is unusable,
> the object graph is already broken, we already have big problems,
> removing the corrupt object(s) doesn't create any new problems, and it
> allows the possibility that the damaged objects can be restor
On Thu, Oct 16, 2014 at 11:04:04AM +0200, Johan Herland wrote:
> I simply copied the packfile containing the good copy into the
> corrupted repo, and then ran a "git gc", which "happened" to use the
> good copy of the corrupted object and complete successfully (instead
> of barfing on the bad copy
On Thu, Oct 16, 2014 at 2:25 PM, Jeff King wrote:
> On Thu, Oct 16, 2014 at 11:04:04AM +0200, Johan Herland wrote:
>> I simply copied the packfile containing the good copy into the
>> corrupted repo, and then ran a "git gc", which "happened" to use the
>> good copy of the corrupted object and comp
Hi,
I've encountered an oddity with git describe.
Consider the following snippet:
-
mkdir test
cd test
git init
echo 1 > file
git add file
git commit -m "changes"
$ git describe --always --dirty
8ad486e
$ cd ..
$ git --git-dir=test/.git describe --always --dirty
8ad486e-dirty
$ GIT_DIR=test/.g
For example:
git diff --color-words <(echo a b c) <(echo a d c)
Changes to struct diff_filespec:
- is_stdin renamed to skip_hashing, which is what it did
- follow_symlinks added, causing diff_populate_filespec to look at
file contents instead of the readlink value
Paths that are handled sp
On 14-10-15 05:50 PM, Junio C Hamano wrote:
> Marc Branchaud writes:
>
>> Yes, but we're cloning gko, not the neighbour. Doesn't that mean that the
>> clone operation won't know about any of the neighbour's refs?
>
> No. --reference (and a natural implementation of --borrow, I would imagine)
>
I have relocated a file into another directory and committed that.
Using the --follow command on the NEW path of the file, I want to find
all commits to that file by a specific author:
$ git log --follow --author david -- new/path/to/file.cpp
When I do this, I get NO results. When I use the OLD p
Johan Herland writes:
> I simply copied the packfile containing the good copy into the
> corrupted repo, and then ran a "git gc", which "happened" to use the
> good copy of the corrupted object and complete successfully (instead
> of barfing on the bad copy). The GC then removed the old
> (now-ob
Thomas Braun writes:
> I've encountered an oddity with git describe.
> Consider the following snippet:
> -
> mkdir test
> cd test
> git init
> echo 1 > file
> git add file
> git commit -m "changes"
> $ git describe --always --dirty
> 8ad486e
> $ cd ..
> $ git --git-dir=test/.git describe --al
Jeff King writes:
> Otherwise, callers must do so or risk triggering warnings
> -Wchar-subscript (and rightfully so; a signed char might
> cause us to use a bogus negative index into the
> hexval_table).
>
> While we are dropping the now-unnecessary casts from the
> caller in urlmatch.c, we can g
Jeff King writes:
> This is not a lot of code, but it's a logical construct that
> should not need to be repeated (and we are about to add a
> third repetition).
Good, but I have two and a half tangential comments about the
context that appears in this patch ;-)
> void object_array_filter(stru
Jeff King writes:
> To find the set of reachable objects, we add a bunch of
> possible sources to our rev_info, call prepare_revision_walk,
> and then launch into a custom walker that handles each
> object top. This is a subset of what traverse_commit_list
> does, so we can just reuse that code (
Brandon Turner brandonturner.net> writes:
>
> On Thu, Oct 9, 2014 at 5:11 PM, Junio C Hamano pobox.com> wrote:
> > Actually the patch was slightly wrong. It did not quite matter as
> > "cd ''" is a no-op, but "git -C '' cmd" is not that lenient (which
> > may be something we may want to fix) a
Jeff King writes:
> There is currently no easy way to ask the revision traversal
> machinery to include objects reachable from the index (e.g.,
> blobs and trees that have not yet been committed). This
> patch adds an option to do so.
>
> Signed-off-by: Jeff King
> ---
> I was tempted to call th
Am 16.10.2014 um 18:57 schrieb Junio C Hamano:
> Thomas Braun writes:
>
>> I've encountered an oddity with git describe.
>> Consider the following snippet:
>> -
>> mkdir test
>> cd test
>> git init
>> echo 1 > file
>> git add file
>> git commit -m "changes"
>> $ git describe --always --dirty
Junio C Hamano writes:
> Marc Branchaud writes:
>
>> I think things would be more understandable if the option was "--dissociate
>> " and was an explicit alternative to --reference:
>> [[--reference | --dissociate] ]
>>
>> I'm still not liking the name "--dissociate" though. The original s
core.filemode is set automatically when a repo is created.
But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
core.filemode may better be set manually to false.
Update and improve the documentation.
Helped-by: Junio C Hamano
Signed-off-by: Torsten Bögershausen
---
Does
Looks sensible to me; Jakub, ack?
Roland Mas writes:
> Hi all,
>
> This simple two-line patch fixes a bug that makes gitweb unusable on
> systems where the installed CGI.pm is version 4.04 or later (such as on
> Debian unstable). That version removed the startform method, which had
> previous
Am 16.10.2014 um 21:29 schrieb Torsten Bögershausen:
> core.filemode is set automatically when a repo is created.
> But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
> core.filemode may better be set manually to false.
> Update and improve the documentation.
>
> Helped-b
Hi,
On Thu, 16 Oct 2014, Thomas Braun wrote:
> Am 16.10.2014 um 21:29 schrieb Torsten Bögershausen:
> > core.filemode is set automatically when a repo is created.
> > But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
> > core.filemode may better be set manually to false
Torsten Bögershausen writes:
> core.filemode is set automatically when a repo is created.
> But when a repo is exported via CIFS or cygwin is mixed with Git for Windows
> core.filemode may better be set manually to false.
> Update and improve the documentation.
>
> Helped-by: Junio C Hamano
> Si
Jakub Narębski writes:
> On Thu, Oct 16, 2014 at 9:36 PM, Junio C Hamano wrote:
>
>> Looks sensible to me; Jakub, ack?
>>
>
> Ack.
>
> Nb. this code follows back to original gitweb.cgi by Kay Sievers, very
> early in the development (2005)
Thanks. I realize that Ack sounds as if "Yeah, I ackno
Michael Haggerty writes:
> This is a rif on Duy's oldish patch series [1]. I started reviewing
> his patch series, but found that some of his patches did multiple
> things, making it harder to review. I started pulling it apart into
> smaller changes to aid my review, and I guess I got carried aw
On Wed, Oct 15, 2014 at 08:57:20PM +0200, Jens Lehmann wrote:
> Am 15.10.2014 um 00:15 schrieb Max Kirillov:
>> I think the logic can be simple: it a submodule is not
>> checked-out in the repository "checkout --to" is called
>> from, then it is not checked-out to the new one also. If it
>> is, the
Somewhere in this series the object enumeration seems to get
broken. "git clone --no-local" of git.git repository died
with
Cloning into 'victim-7'...
remote: Counting objects: 173727, done.
remote: Compressing objects: 100% (43697/43697), done.
remote: Total 173727 (delta 130908)
Junio C Hamano writes:
> Somewhere in this series the object enumeration seems to get
> broken. "git clone --no-local" of git.git repository died
> with
>
> Cloning into 'victim-7'...
> remote: Counting objects: 173727, done.
> remote: Compressing objects: 100% (43697/43697), done.
>
On Thu, Oct 16, 2014 at 02:07:47PM -0700, Junio C Hamano wrote:
> Somewhere in this series the object enumeration seems to get
> broken. "git clone --no-local" of git.git repository died
> with
>
> Cloning into 'victim-7'...
> remote: Counting objects: 173727, done.
> remote: Compres
On Thu, Oct 16, 2014 at 05:21:12PM -0400, Jeff King wrote:
> Hrm. I cannot reproduce the clone failure...
Oh, because I have bitmaps turned on, and we do not run the list-objects
code at all in that case.
The bug unsurprisingly bisects to "traverse_commit_list: support
pending blobs/trees with p
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
Junio C Hamano writes:
> Michael Haggerty writes:
>
>> This is a rif on Duy's oldish patch series [1]. I started reviewing
>> his patch series, but found that some of his patches did multiple
>> things, making it harder to review. I started pulling it apart into
>> smaller changes to aid my revi
Jeff King writes:
> On Thu, Oct 16, 2014 at 05:21:12PM -0400, Jeff King wrote:
>
>> Hrm. I cannot reproduce the clone failure...
>
> Oh, because I have bitmaps turned on, and we do not run the list-objects
> code at all in that case.
;-)
> We should probably add a test for cloning a tag of an o
From: "brian m. carlson"
This series is designed to implement the changes necessary to build
Git
using Asciidoctor instead of AsciiDoc.
[..]
Even with these patches, Asciidoctor warns about everyday.txt and
user-manual.txt. I'm not sending patches for these right now because
I've seen recent
On 10/16/2014 10:47 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> This is a rif on Duy's oldish patch series [1]. I started reviewing
>> his patch series, but found that some of his patches did multiple
>> things, making it harder to review. I started pulling it apart into
>> smaller
On 10/15/2014 02:45 AM, Jonathan Nieder wrote:
> This series by Ronnie was last seen on-list at [1]. It includes some
> improvements to the ref-transaction API, improves handling of poorly
> named refs (which should make it easier to tighten the refname format
> checks in the future), and is a ste
On Wed, Oct 15, 2014 at 10:06 PM, Michael Haggerty wrote:
> As far as I know, Duy isn't actively working on this, so I hope my
> reroll is not unwelcome.
I couldn't be happier that someone does the work for me and I still
benefit from it ;)
--
Duy
--
To unsubscribe from this list: send the line
--
Are you in a financial distress? do you need financial assistant to
start up a business or to pay bills? we offer loans to individual's and
company investors at 3% interest rate.Email us at adeyemisu...@gmail.com
Fill out the details below:
Full name:
Country:
Address:
State:
Zip code:
A
On Thu, Oct 16, 2014 at 03:18:34PM -0700, Junio C Hamano wrote:
> > We should probably add a test for cloning a tag of an otherwise
> > unreferenced object, too.
>
> Yeah, that too ;-)
Here's that test (after the scissors below). It can be applied totally
separately, though I stuck it in as patc
On Thu, Oct 16, 2014 at 11:41:35AM -0700, Junio C Hamano wrote:
> I agree that "--index" is a bad name as it usually is used in a
> particular context: the command can work on various combination of
> working tree and the index, and I am asking it to work on both
> (e.g. "apply --index" as opposed
[subject tweaked as we have veered quite far off the original, and
this might get more attention from interested people]
On Thu, Oct 16, 2014 at 10:39:54AM -0700, Junio C Hamano wrote:
> 2. We use object_array_remove_duplicates() to de-dup "git bundle
> create x master master", which came
On Thu, Oct 16, 2014 at 08:12:31PM -0400, Jeff King wrote:
> > "--indexed-objects" (short for "--show-objects-in-the-index") or
> > something?
>
> That sounds reasonable. We could technically do `--indexed` as that is
> different from `--index`, but maybe they are still confusingly close.
Here's
This does the same thing as our custom code, so let's not
repeat ourselves.
Signed-off-by: Jeff King
---
reachable.c | 52 +---
1 file changed, 1 insertion(+), 51 deletions(-)
diff --git a/reachable.c b/reachable.c
index 0176a88..a647267 100644
--
There is currently no easy way to ask the revision traversal
machinery to include objects reachable from the index (e.g.,
blobs and trees that have not yet been committed). This
patch adds an option to do so.
Signed-off-by: Jeff King
---
Documentation/rev-list-options.txt | 5
revision.c
This saves us from having to bump the rp_av count when we
add new traversal options.
Signed-off-by: Jeff King
---
builtin/pack-objects.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 4df9499..b2627
When we pack all objects, we use only the objects reachable
from references and reflogs. This misses any objects which
are reachable from the index, but not yet referenced.
By itself this isn't a big deal; the objects can remain
loose until they are actually used in a commit. However, it
does crea
When we are given an expiration time like
--unpack-unreachable=2.weeks.ago, we avoid writing out old,
unreachable loose objects entirely, under the assumption
that running "prune" would simply delete them immediately
anyway. However, this is only valid if we computed the same
set of reachable objec
If a pack.packSizeLimit is set, we may split the pack data
across multiple packfiles. This means we cannot generate
.bitmap files, as they require that all of the reachable
objects are in the same pack. We check that condition when
we are generating the list of objects to pack (and disable
bitmaps
On Thu, Oct 16, 2014 at 09:13:39PM -0700, Junio C Hamano wrote:
> Just being curious, but would the same bug, if allowed to be triggered
> cutting repacking of your repository, have corrupted the resulting bitmap?
I didn't test, but yes, almost certainly. The bug was in list-objects.c,
which is u
51 matches
Mail list logo
