* Re: git-commit feature request: pass editor command line options
From: Miklos Vajna @ 2009-10-14 17:23 UTC (permalink / raw)
To: Matthew Cline; +Cc: git
In-Reply-To: <25885354.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 831 bytes --]
On Tue, Oct 13, 2009 at 09:58:51PM -0700, Matthew Cline <matt@nightrealms.com> wrote:
>
> I'd like to be able to have git-commit pass the commit-message editor command
> line options which aren't passed to the editor for other usages. Right now
> I have "co" aliased to "!sh -c 'GIT_EDITOR=git-commit-editor git commit'",
> where git-commit-editor is a wrapper around my editor-of-choice which passes
> the editor the command line options I want, but it'd be simpler and cleaner
> if I could just set "commit.editor_options=-BAR". Or even let there be a
> separate editor for commits, so I could do "core.editor=foo" and
> "commit.editor=foo -BAR".
Hmm, what is the use-case when using an option --foo is useful when
creating a commit, but not useful when crating a tag?
Apart from introducing inconsistency...
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: linkify author/committer names with search
From: Wincent Colaiuta @ 2009-10-14 16:55 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <1255486344-11891-1-git-send-email-bebarino@gmail.com>
El 14/10/2009, a las 04:12, Stephen Boyd escribió:
> It's nice to search for an author by merely clicking on their name in
> gitweb. This is usually faster than selecting the name, copying the
> selection, pasting it into the search box, selecting between
> author/committer and then hitting enter.
What about installs where search is turned off? (ie. with "$feature
{'search'}{'default'} = [undef];" in gitweb.conf)
Cheers,
Wincent
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Avery Pennarun @ 2009-10-14 16:28 UTC (permalink / raw)
To: Eric Wong; +Cc: Bruno Harbulot, git
In-Reply-To: <20091014060307.GA17178@dcvr.yhbt.net>
On Wed, Oct 14, 2009 at 2:03 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> wrote:
>> What surprises me is that it looks like it's looping over and over,
>> since sometimes it starts back from SVN revision 1 when it's trying to
>> import a new tag.
>
> Yeah, that's an unfortunate thing about the flexibility of Subversion,
> basically anything can be a "tag" or a directory and it's extremely
> hard for git svn to support any uncommon cases for tags/branches
> out-of-the box, so the manual config editing is needed.
I've been thinking about this myself for some time. One option that
might be "interesting" would be to just grab the *entire* svn tree
(from the root), and then use git-subtree[1] to slice and dice it into
branches using your local copy of git (which is fast and uses no
bandwidth) instead of during the svn fetch (which is slow and uses
lots of bandwidth). I think it would also simplify the git-svn code
quite a lot, at least for fetching, since there would always be a
global view of the tree and SVN things like "copy branch A to tag B"
would just be exactly that.
Of course I have no time to code this up myself, so I apologize for
just dumping ideas on you without code behind them. If this inspires
anyone, I'd be happy to help with any missing features (or
documentation) this exposes in git-subtree, though.
Have fun,
Avery
[1] http://github.com/apenwarr/git-subtree
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Shawn O. Pearce @ 2009-10-14 16:12 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Andy Isaacson, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0910141208170.20122@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> wrote:
> > Some types of corruption to a pack may confuse the deflate stream
> > which stores an object. In Andy's reported case a 36 byte region
> > of the pack was overwritten, leading to what appeared to be a valid
> > deflate stream that was trying to produce a result larger than our
> > allocated output buffer could accept.
...
> This is unfortunate that making a test case for this isn't exactly
> trivial.
Hmmm. We could do something like manually create a pack file of
one non-delta blob whose pack header length is 16, but use a zlib
stream whose result body is 64. Prior to this fix, we'd be stuck
in the infinite loop. :-)
Its a PITA to create though, you have to hand-craft the test vector
and save it in the repository, we can't produce such a pack with
any real code we ship.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Michael J Gruber @ 2009-10-14 16:09 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <94a0d4530910140726i4465e919h77045904aa33c61a@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 14.10.2009 16:26:
> On Tue, Oct 13, 2009 at 10:19 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Felipe Contreras venit, vidit, dixit 12.10.2009 19:09:
>>> On Mon, Oct 12, 2009 at 3:25 PM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>> Well, you do talk about "system" below, and that's about it. Also, the
>>>> configuration is not really distributed among different locations. Most
>>>> newbies interested in a *D*VCS will misunderstand this (as git having
>>>> distributed configuration).
>>>>
>>>> Alternative:
>>>>
>>>> Git's default configuration can be changed on a system wide, global (per
>>>> user) and local (per repository) level, in the order of increasing
>>>> precedence.
>>>
>>> When I read that it's not clear if the local level discards the global
>>> level completely or it's aggregated. If we specify that it's only the
>>> variables that take precedence it might be clearer:
>>>
>>> Git's configuration is composed of variables that are stored in
>>> multiple locations: 'system' (all users), 'global' (for the user), and
>>> 'repository' -- in decreasing order of precedence.
>>
>> Yep, although established lingo is "options" (not "variables"), and it's
>> really increasing order, not decreasing.
>
> Really? I remember clearly Junio stating otherwise:
> http://marc.info/?l=git&m=123460371724873&w=2
>
> ----
>> + OPT_BOOLEAN(0, "unset", &do_unset, "removes an option: name [value-regex]"),
>
> Please don't introduce a new noun "option" that has never been used to
> mean a "configuration variable" in git documentation. It unnecessarily
> confuses everybody.
> ----
Well, Junio certainly is authoritative, and I don't want to risk any bad
patch-acceptance-fu ( :) ), but
2d2465c (Add documentation for git-config-set, 2005-11-17)
is the origin of that doc for git-config. I'm not just claiming it
myself. That commit introduced "option", uses it in all but one place,
and this never changed since then! [The ratio went up from 6:1 to 40:5]
I have no objection to changing this established notion, but established
it is. I haven't tracked down the use of option vs. variable in other
places than git-config.txt and its predecessors.
Michael
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Nicolas Pitre @ 2009-10-14 16:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andy Isaacson, Junio C Hamano, git
In-Reply-To: <20091014142351.GI9261@spearce.org>
On Wed, 14 Oct 2009, Shawn O. Pearce wrote:
> Andy Isaacson <adi@hexapodia.org> wrote:
> > We're looping in unpack_compressed_entry, adding a fprintf immediately
> > after the call to git_inflate() shows:
>
> Thanks, that was really quite helpful. Junio/Nico, I think we can
> just apply this patch to maint and include it in the next release:
>
> --8<--
> [PATCH] sha1_file: Fix infinite loop when pack is corrupted
>
> Some types of corruption to a pack may confuse the deflate stream
> which stores an object. In Andy's reported case a 36 byte region
> of the pack was overwritten, leading to what appeared to be a valid
> deflate stream that was trying to produce a result larger than our
> allocated output buffer could accept.
>
> Z_BUF_ERROR is returned from inflate() if either the input buffer
> needs more input bytes, or the output buffer has run out of space.
> Previously we only considered the former case, as it meant we needed
> to move the stream's input buffer to the next window in the pack.
>
> We now abort the loop if inflate() returns Z_BUF_ERROR without
> consuming the entire input buffer it was given, or has filled
> the entire output buffer but has not yet returned Z_STREAM_END.
> Either state is a clear indicator that this loop is not working
> as expected, and should not continue.
>
> This problem cannot occur with loose objects as we open the entire
> loose object as a single buffer and treat Z_BUF_ERROR as an error.
>
> Reported-by: Andy Isaacson <adi@hexapodia.org>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
This is unfortunate that making a test case for this isn't exactly
trivial.
> ---
> sha1_file.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 4ea0b18..4cc8939 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1357,6 +1357,8 @@ unsigned long get_size_from_delta(struct packed_git *p,
> in = use_pack(p, w_curs, curpos, &stream.avail_in);
> stream.next_in = in;
> st = git_inflate(&stream, Z_FINISH);
> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
> + break;
> curpos += stream.next_in - in;
> } while ((st == Z_OK || st == Z_BUF_ERROR) &&
> stream.total_out < sizeof(delta_head));
> @@ -1594,6 +1596,8 @@ static void *unpack_compressed_entry(struct packed_git *p,
> in = use_pack(p, w_curs, curpos, &stream.avail_in);
> stream.next_in = in;
> st = git_inflate(&stream, Z_FINISH);
> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
> + break;
> curpos += stream.next_in - in;
> } while (st == Z_OK || st == Z_BUF_ERROR);
> git_inflate_end(&stream);
> --
> 1.6.5.52.g0ff2e
>
> --
> Shawn.
>
^ permalink raw reply
* Re: [msysgit? bug] crlf double-conversion on win32
From: Laurent Boulard @ 2009-10-14 15:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Raible, git
In-Reply-To: <alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de>
On Wed, Oct 14, 2009 at 16:03, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
>>
>> In which Junio suggests:
>> $ rm .git/index
>> $ git reset --hard
>>
>> in order to "restore sanity to your work tree"
>
> Of course this is insane as a user interface. It is not even plumbing.
>
> So I started some time ago to code a "git checkout --fix-crlf", but I
> am not really happy with the user interface. I think that Git should
> realize itself that something went wrong with the line endings. If I say
> "git reset --hard", it is just a bug in Git when it insists afterwards
> that the files are modified.
I have to work on win32 at work and depending of projects, I have to
play with autocrlf/crlf config.
So I cannot do a git clone because it will inherit the global crlf
configuration which is not want I want. My flow is often:
$ git init ...
$ git config core.autocrlf ...
$ git remote add origin ...
$ git fetch origin ...
I stuffed those four lines behind a few git alias but I think having a
config option for git init and git clone to set core.autocrlf in
repository would be a (small) improvement, isn't it ?
Laurent.
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Daniel Barkalow @ 2009-10-14 15:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091014050851.GE31810@coredump.intra.peff.net>
On Wed, 14 Oct 2009, Jeff King wrote:
> On Wed, Oct 14, 2009 at 12:44:34AM -0400, Daniel Barkalow wrote:
>
> > +char *get_detached_head_string(void)
> > +{
> > + char *filename = git_path("DETACH_NAME");
> > + struct stat st;
> > + if (stat(filename, &st) || !S_ISREG(st.st_mode))
> > + return NULL;
> > + struct strbuf buf = STRBUF_INIT;
> > + strbuf_read_file(&buf, filename, st.st_size);
> > + strbuf_trim(&buf);
> > + return strbuf_detach(&buf, 0);
> > +}
>
> Would it hurt to tuck this information into HEAD itself, as we already
> put arbitrary text into FETCH_HEAD?
I don't know; I'll have to try that and see if the tools that handle HEAD
are happy with extra text there. If it works, it's a good solution.
I think I tried it at some point and things failed all over the place, but
that may have been before symrefs, when you could get the actual sha1
hash out of HEAD with "$(cat .git/HEAD)".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Changing branches in supermodule does not affect submodule?
From: Jens Lehmann @ 2009-10-14 15:39 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0910140728420.16100@ds9.cixit.se>
Peter Krefting schrieb:
> Jens Lehmann:
>
>> just calling "git submodule update" every time you want the submodule
>> to be updated according to the state committed in the superproject
>> will do the trick (but keep in mind that all referenced commits have
>> to be accessible in the local clone of your submodule, so you might
>> have to do a fetch there once in a while).
BTW: unless you use the -N or --no-fetch option, git submodule update
will do the fetch for you.
> Is it possible to automate this from a hook or something else?
Yep, you can use the post-checkout hook for that, just put a "git
submodule update" in it.
*But*: If you do a checkout in the superproject while the submodule
has new commits not contained in any branch (remember submodules
often have a detached head) you'll silently lose these commits!
Then only the reflog can help you ...
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Jeff King @ 2009-10-14 15:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0910141233060.4985@pacific.mpi-cbg.de>
On Wed, Oct 14, 2009 at 12:33:22PM +0200, Johannes Schindelin wrote:
> > > +char *get_detached_head_string(void)
> > > +{
> > > + char *filename = git_path("DETACH_NAME");
> > > + struct stat st;
> > > + if (stat(filename, &st) || !S_ISREG(st.st_mode))
> > > + return NULL;
> > > + struct strbuf buf = STRBUF_INIT;
> > > + strbuf_read_file(&buf, filename, st.st_size);
> > > + strbuf_trim(&buf);
> > > + return strbuf_detach(&buf, 0);
> > > +}
> >
> > Would it hurt to tuck this information into HEAD itself, as we already
> > put arbitrary text into FETCH_HEAD?
>
> AFAIR we still remember HEAD to be a symlink.
I think that has been abandoned for detached HEAD (that is, if you
support only symlinked HEAD, then you cannot detach at all). But I might
be wrong. It has been a while since I looked at that code.
-Peff
^ permalink raw reply
* Re: [PATCH 1/6] Open the pack file and keep a map on it.
From: Hervé Cauwelier @ 2009-10-14 15:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List
In-Reply-To: <fabb9a1e0910140548g2ad99ec4ia0f4cd4cb6fc409c@mail.gmail.com>
On 14/10/2009 14:48, Sverre Rabbelier wrote:
> Heya,
>
> 2009/10/14 Hervé Cauwelier<herve@itaapy.com>:
>
> Please include a cover letter for series as long as these (anything
> larger than 4 should have a cover letter IMHO). Doing so makes it
> easier for those that follow the series to see what changed (assuming
> you write down what changed in the cover letter). Also, it makes it
> easier for those that were not following the series to drop in at the
> current version (assuming you provide a short summary of what the
> series is about in the cover letter).
Hi, indeed I forgot and send-email sent them without asking confirmation.
The only change is the comment by Shawn about keeping the PACK_TOC
constant as is and calling the other one PACK_HDR.
Regards
--
Hervé Cauwelier - ITAAPY - 9 rue Darwin 75018 Paris
Tél. 01 42 23 67 45 - Fax 01 53 28 27 88
http://www.itaapy.com/ - http://www.cms-migration.com
^ permalink raw reply
* Re: [PATCH 1/6] Open the pack file and keep a map on it.
From: Sverre Rabbelier @ 2009-10-14 15:30 UTC (permalink / raw)
To: Hervé Cauwelier; +Cc: Git List
In-Reply-To: <4AD5EE77.3030802@itaapy.com>
Heya,
2009/10/14 Hervé Cauwelier <herve@itaapy.com>:
> Hi, indeed I forgot and send-email sent them without asking confirmation.
Note to self: write patch to git send-email...
Note to self 2: learn perl
Note to self 3: find someone else to write said patch to git
send-email, perl is scary
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Petr Baudis @ 2009-10-14 14:40 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git
In-Reply-To: <4AD5E1A5.7020909@hartwork.org>
On Wed, Oct 14, 2009 at 04:35:17PM +0200, Sebastian Pipping wrote:
> Petr Baudis wrote:
> > On Tue, Oct 13, 2009 at 02:14:48PM +0200, Sebastian Pipping wrote:
> >> Petr, any news on this one?
> >>
> >> I just check and it still seems broken.
> >
> > Fixed, it's a HTML::Email::Obfuscate bug.
>
> Though the feed works in Firefox now I wouldn't call it fixed, yet,
>
> As I elaborated earlier in this thread the Atom you generate is not
> valid. I cannot put it better than feedvalidator:
>
> http://feedvalidator.org/check.cgi?url=http%3A%2F%2Frepo.or.cz%2Fw%2Fdottout.git%3Fa%3Datom
>
> Please fix that, too.
I'm sorry, I don't have time for fixing that. Feel free to send me a
patch.
Kind regards,
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Sebastian Pipping @ 2009-10-14 14:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20091014141744.GO6695@machine.or.cz>
Petr Baudis wrote:
> On Tue, Oct 13, 2009 at 02:14:48PM +0200, Sebastian Pipping wrote:
>> Petr, any news on this one?
>>
>> I just check and it still seems broken.
>
> Fixed, it's a HTML::Email::Obfuscate bug.
Though the feed works in Firefox now I wouldn't call it fixed, yet,
As I elaborated earlier in this thread the Atom you generate is not
valid. I cannot put it better than feedvalidator:
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Frepo.or.cz%2Fw%2Fdottout.git%3Fa%3Datom
Please fix that, too.
Sebastian
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-14 14:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <4AD42A1C.1080709@drmicha.warpmail.net>
On Tue, Oct 13, 2009 at 10:19 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 12.10.2009 19:09:
>> On Mon, Oct 12, 2009 at 3:25 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Well, you do talk about "system" below, and that's about it. Also, the
>>> configuration is not really distributed among different locations. Most
>>> newbies interested in a *D*VCS will misunderstand this (as git having
>>> distributed configuration).
>>>
>>> Alternative:
>>>
>>> Git's default configuration can be changed on a system wide, global (per
>>> user) and local (per repository) level, in the order of increasing
>>> precedence.
>>
>> When I read that it's not clear if the local level discards the global
>> level completely or it's aggregated. If we specify that it's only the
>> variables that take precedence it might be clearer:
>>
>> Git's configuration is composed of variables that are stored in
>> multiple locations: 'system' (all users), 'global' (for the user), and
>> 'repository' -- in decreasing order of precedence.
>
> Yep, although established lingo is "options" (not "variables"), and it's
> really increasing order, not decreasing.
Really? I remember clearly Junio stating otherwise:
http://marc.info/?l=git&m=123460371724873&w=2
----
> + OPT_BOOLEAN(0, "unset", &do_unset, "removes an option: name [value-regex]"),
Please don't introduce a new noun "option" that has never been used to
mean a "configuration variable" in git documentation. It unnecessarily
confuses everybody.
----
>> I disagree. Most useful configurations (color.ui, user.email) should
>> be global. The complete newbie might think: cool, now I have my git
>> properly configured (with 'git config -e'), and then when cloning a
>> new repo (s)he would think: ok, git just forgot what I told him. When
>> that happens (s)he would have to re-learn and re-configure git.
>>
>> When users think about configuration, it's usually a 'global'
>> configuration, so that's what we should teach from the beginning and
>> make sure they understand the difference between 'global' and
>> 'repository' configurations.
>
> Sure. What I meant are the file locations, the actual paths. First
> timers should use "git config -e" and "git config --global -e" if they
> really want to edit their local and global config files. Better yet,
> they should use "git config" and "git config --global" in their set and
> get modes, because they make sure that there's no total garbage in the
> config. The locations of the files are an implementation detail.
Oh, in that case I agree.
>> Looks better, except s/configuration options/configuration variables/
>>
>
> Uhm, no, for the reason mentioned above. While the man page of git
> config is not completely consistent either, we're really talking about
> configuration options. An "option" can be set to a "value", and the
> thing you pass in order to do that can be called a "variable". For the
> most part this is how git-config[1] uses this terminology.
Yeah, but not everything in there is an option. Personally I would
prefer the "option" term, but as I said, Junio disagreed some time
ago.
--
Felipe Contreras
^ permalink raw reply
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Petr Baudis @ 2009-10-14 14:17 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git
In-Reply-To: <4AD46F38.30100@hartwork.org>
On Tue, Oct 13, 2009 at 02:14:48PM +0200, Sebastian Pipping wrote:
> Petr, any news on this one?
>
> I just check and it still seems broken.
Fixed, it's a HTML::Email::Obfuscate bug.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Shawn O. Pearce @ 2009-10-14 14:23 UTC (permalink / raw)
To: Andy Isaacson, Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <20091014042249.GA5250@hexapodia.org>
Andy Isaacson <adi@hexapodia.org> wrote:
> We're looping in unpack_compressed_entry, adding a fprintf immediately
> after the call to git_inflate() shows:
Thanks, that was really quite helpful. Junio/Nico, I think we can
just apply this patch to maint and include it in the next release:
--8<--
[PATCH] sha1_file: Fix infinite loop when pack is corrupted
Some types of corruption to a pack may confuse the deflate stream
which stores an object. In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.
Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.
We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.
This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.
Reported-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
sha1_file.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4ea0b18..4cc8939 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1357,6 +1357,8 @@ unsigned long get_size_from_delta(struct packed_git *p,
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
+ if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
+ break;
curpos += stream.next_in - in;
} while ((st == Z_OK || st == Z_BUF_ERROR) &&
stream.total_out < sizeof(delta_head));
@@ -1594,6 +1596,8 @@ static void *unpack_compressed_entry(struct packed_git *p,
in = use_pack(p, w_curs, curpos, &stream.avail_in);
stream.next_in = in;
st = git_inflate(&stream, Z_FINISH);
+ if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
+ break;
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end(&stream);
--
1.6.5.52.g0ff2e
--
Shawn.
^ permalink raw reply related
* Re: [PATCH 0/2] user-manual: reorganize the configuration steps
From: Felipe Contreras @ 2009-10-14 14:14 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git, Junio C Hamano, Jonathan Nieder
In-Reply-To: <20091014024940.GB9700@fieldses.org>
On Wed, Oct 14, 2009 at 5:49 AM, J. Bruce Fields <bfields@citi.umich.edu> wrote:
> On Sun, Oct 11, 2009 at 11:43:04PM +0300, Felipe Contreras wrote:
>> This basically introduces the "getting started" section so users get familiar
>> with the configuration from the get-go, and also, most people prefer to teach
>> 'git config --global' to setup the user name and email. Here are a few
>> examples:
>
> I'm not personally a big fan of starting out with a "how to use
> git-config" section, because it's not that difficult or important:
> questions we get on this list suggest confusion about a lot of things,
> but git configuration is rarely one of them (that I've noticed).
Which means either people understand the configuration perfectly, look
somewhere else for that, or they don't do it at all.
Judging by the fact that most guides cover it at the beginning, and
people still send commits without proper user{.name,.email}, I would
say it is needed.
> I'd rather just point people to the git-config man page the first time
> we mention any git configuration. (And improve the man page if
> necessary to ensure it's up to the job.)
>
> If we have to do this, just keep it short....
That's what I tried to do.
--
Felipe Contreras
^ permalink raw reply
* [msysgit? bug] CRLF in info/grafts causes parse error
From: Yann Dirson @ 2009-10-14 14:07 UTC (permalink / raw)
To: git
When creating an info/grafts under windows, one typically gets a CRLF file.
Then:
* gitk loudly complains about "bad graft data"
* "git log > /dev/null" does not report any problem
* "git log > foo" does report the problem on sdterr, but exit code is still 0
Recreating the graft as a LF file (eg with "echo" or "printf") causes the
graft to be properly interpreted.
^ permalink raw reply
* Re: Bad URL passed to RA lay
From: m.skoric @ 2009-10-14 14:02 UTC (permalink / raw)
To: Eric Wong; +Cc: git
> -----Ursprüngliche Nachricht-----
> Von: "Eric Wong" <normalperson@yhbt.net>
> Gesendet: 14.10.09 09:07:31
> An: m.skoric@web.de
> CC: git@vger.kernel.org
> Betreff: Re: Bad URL passed to RA lay
> m.skoric@web.de wrote:
> > Hi List,
> >
> > i have a problem with git-svn clone / fetch. I get following error
> > while doing one of previous command -> "Bad URL passed to RA lay" This
> > happens because a branch doesn't exists in svn anymore and git wants
> > to retrieve data from it. Here is the complete error message
> >
> > Initializing parent: Abo-Uebernahme (Bug #994)@341
> > Found possible branch point: "quoted"..trunk => "quoted"...Abo-Uebernahme (Bug #994), 203
> > Found branch parent: (Abo-Uebernahme (Bug #994)@341) bb831869748c98bf97d105c5894ae65331c95c08
> > Bad URL passed to RA layer: Malformed URL for repository at /usr/bin/git-svn line 4311
> >
> > git version 1.6.3.3
> >
> > Aynone else has this Problem?
>
> Hi,
>
> Unlikely, not many people use URIs as weird as yours :)
Ye, i know ;) This is really old stuff and we already changed them to more sane ones ;)
> The existing test case (t9118) we have was also inspired by you,
> on the same branch, even.
>
> > Can anyone help me?
>
> What exactly is the "quoted" you refer to? That's not an actual branch
> name, is it?
ah brainfart.
This info is essential!
quoted = branches/dirk/Abo-Uebernahme... => https...branches/Abo-Uebernahme...
> Can you try it with v1.6.5? You might need to edit your $GIT_CONFIG,
> but commit 5268f9edc3c86b07a64fcc2679e5ffe39be28d97 was the last
> fix for URI-escaping problems:
This is not a URI Escaping Problem. As i allready mentioned: I think its a svn
problem and git can't handle that.
svn History:
r203 svn copy /trunk/ /branches/dirk/Abo..
r204 svn mv /branches/dirk/Abo.. /branches/Abo..
r341 svn mv /branches/Abo.. /branches/0944-Abo..
r203 branch was created from trunk.
r204 branch was moved from /branches/dirk/ to /branches
r341 branch was renamed to 0944-Abo
This is what git does.
>Initializing parent: refs/remote/Abo-Uebernahme (Bug #994)@341
>Found possible branch point: branches/Abo => branches/dirk/Abo-Uebernahme (Bug #994), 203
>Found branch parent: (Abo-Uebernahme (Bug #994)@341) bb831869748c98bf97d105c5894ae65331c95c08
>Bad URL passed to RA layer: Malformed URL for repository at /usr/bin/git-svn line 4311
I think the problem is that git doesn't like this kinda action.
branch -> do something with branch -> rename branch.
After some debugging i found something in git-svn
sub find_parent_branch
{
...
} elseif ($self->ra->trees_match($new_url, $r0, $self->full_url, $rev))
....
}
the trees_match sub doesn't do any error handling. if $self->full_url doesn't
exits anymore this will fail, right?
I don't know if the followong piece of code in find_parent_branch works like
you expect it!?
>unless (defined $paths) {
> my $err_handler = $SVN::Error::handler;
> $SVN::Error::handler = \&Git::SVN::Ra::skip_unknown_revs;
> $self->ra->get_log([$self->{path}], $rev, $rev, 0, 1, 1,
> sub { $paths = $_[0] });
> $SVN::Error::handler = $err_handler;
>}
>return undef unless defined $paths;
Maybe its just a problem with renaming branches or something!?
My Perl knowledge is really limited, so its up to you my friend ;)
Majk
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
^ permalink raw reply
* Re: [msysgit? bug] crlf double-conversion on win32
From: Johannes Schindelin @ 2009-10-14 14:03 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20091014T001602-378@post.gmane.org>
Hi,
On Tue, 13 Oct 2009, Eric Raible wrote:
> Yann Dirson <y.dirson <at> e-sidor.com> writes:
>
> >
> > With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file
> > to a Linux box and committed it.
> >
> > In that situation, the win32 client in autocrlf mode keeps telling that
> > the files are locally modified, even after eg "git reset --hard". Without
> > touching the crlf setting (which I believe should not ever be necessary),
> > this can be corrected by committing the faulty files after dos2unix'ing
> > them, and using "git fetch && git reset --hard origin/master" ("git pull
> > --rebase" refuses to do the job since it believes there are local
> > changes).
>
> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
>
> In which Junio suggests:
> $ rm .git/index
> $ git reset --hard
>
> in order to "restore sanity to your work tree"
Of course this is insane as a user interface. It is not even plumbing.
So I started some time ago to code a "git checkout --fix-crlf", but I
am not really happy with the user interface. I think that Git should
realize itself that something went wrong with the line endings. If I say
"git reset --hard", it is just a bug in Git when it insists afterwards
that the files are modified.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jay Soffian @ 2009-10-14 12:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Thomas Rast, Euguess,
Mikael Magnusson, Matthieu Moy, git, Johannes Sixt
In-Reply-To: <7vfx9modqf.fsf@alter.siamese.dyndns.org>
On Tue, Oct 13, 2009 at 11:28 PM, Junio C Hamano <gitster@pobox.com> wrote:
> When you do not have local "frotz" branch, and do have cloned/fetched from
> the origin that has "frotz" branch, I am actually Ok with this
>
> $ git checkout frotz [--]
>
> to do an equivalent of:
>
> $ git checkout -t -b frotz origin/frotz
>
> I do not have problem with this _particular_ DWIMmery. It will not break
> people's expectations, other than "asking to check out non-existing ref
> should fail". That expectation might be logical, but I do not think it is
> useful.
>
> Another reason I won't have problem with this one is that perhaps after
> creating a few more commits, the next day when the user does the same
>
> $ git checkout frotz
>
> what will be shown is the _local_ frotz branch. Nowhere in this sequence
> there is any room to mistake that you somehow checked out a branch owned
> by somebody else (namely, origin). You started by auto-creating your
> local branch, worked on it, and checked it out again the next day. In
> other words, this is really about a shorthand to create a new local branch
> called "frotz" when the commit that the branch should start from is
> clearly unambiguous.
Okay, this is good, and I can work up a patch if no one beats me to the punch.
> I have trouble with yours, on the other hand, which is to make
>
> $ git checkout origin/frotz
> $ git checkout v1.5.5
>
> into
>
> $ git checkout -b frotz-47 origin/frotz
> $ git checkout -b v1.5.5-47 v1.5.5
I suggested no such thing, at least, I don't think I did. What I said was:
---snip---
Modify checkout so that the first commit while detached automatically
creates a branch. Perhaps the name is derived from the branch point,
or the user is prompted for a name.
---snip---
So we'd only automatically create a new branch at commit time. But
never mind that, it was just a suggestion and I don't like it.
What if instead we do something like this:
$ git checkout v1.5.5
Note: moving to 'v1.5.5' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 1d2375d... GIT 1.5.5
$ [edit foo.c]
$ git add foo.c
$ git commit -m "edited some file"
Cannot commit to v1.5.5. Please use git commit -b <branch> to specify
the name of a new branch to commit to, or use git commit --detach to
force a detached commit.
So we modify git to, by default, no longer allow creating a commit
while detached or on a branch that cannot be committed to.
j.
^ permalink raw reply
* Re: [PATCH 1/6] Open the pack file and keep a map on it.
From: Sverre Rabbelier @ 2009-10-14 12:48 UTC (permalink / raw)
To: Hervé Cauwelier; +Cc: Git List
In-Reply-To: <1255516669-26745-1-git-send-email-herve@itaapy.com>
Heya,
2009/10/14 Hervé Cauwelier <herve@itaapy.com>:
Please include a cover letter for series as long as these (anything
larger than 4 should have a cover letter IMHO). Doing so makes it
easier for those that follow the series to see what changed (assuming
you write down what changed in the cover letter). Also, it makes it
easier for those that were not following the series to drop in at the
current version (assuming you provide a short summary of what the
series is about in the cover letter).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jakub Narebski @ 2009-10-14 10:46 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Johannes Schindelin, Euguess, Mikael Magnusson,
Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <200910141156.55536.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> So I think we're now mixing up two different goals in this thread:
> a) Stopping the users from hurting themselves by inadvertent detaching
> b) Helping the users by DWIMming local branches for them
>
> I'm all for (a), but (b) is much harder.
Perhaps (b) should be protected by branch.autocreatelocal (similar to
branch.autosetupmerge and branch.autosetuprebase).
Also we should always print a message if we DWIM creating or checking
out local branch equivalent to remote-tracking branch.
Also, why interactive checkout (checkout --interactive?) idea was
abandoned?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 3/6] Allow zlib to read a pack buffer longer than the actual data
From: Hervé Cauwelier @ 2009-10-14 10:37 UTC (permalink / raw)
To: git
In-Reply-To: <1255516669-26745-2-git-send-email-herve@itaapy.com>
As we don't know where the compressed data end, only the size of the
uncompressed data.
Signed-off-by: Hervé Cauwelier <herve@itaapy.com>
---
src/odb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/odb.c b/src/odb.c
index 2b4b016..349747b 100644
--- a/src/odb.c
+++ b/src/odb.c
@@ -432,7 +432,7 @@ static int inflate_buffer(void *in, size_t inlen, void *out, size_t outlen)
inflateEnd(&zs);
- if ((status != Z_STREAM_END) || (zs.avail_in != 0))
+ if (status != Z_STREAM_END)
return GIT_ERROR;
if (zs.total_out != outlen)
--
1.6.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox