* Re: Allowing override of the default "origin" nickname
From: Jakub Narebski @ 2008-01-11 15:25 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <30e4a070801110653n61a826c0y33ed13f95cddf25d@mail.gmail.com>
"Mark Levedahl" <mlevedahl@gmail.com> writes:
> On Jan 11, 2008 8:52 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > IMHO you should optimise the communication by agreeing on one origin,
> > or alternatively not talk about a server at all (which is made easy by the
> > global uniqueness of commit names; just say "my tip is ac9b7192").
> >
>
> We *cannot* agree on one definition of "origin": there is no single
> server accessible by all, but use of submodules currently *requires*
> that each repo's upstream be given the nickname "origin". With this
> change, I can enforce that each server has a unique nickname and that
> one unique nickname per server is used across the program. Absent
> this, I cannot and end up having to have everyone translate "origin"
> into what it means for them.
>
> SHA-1's are absolutely unique, but what do you do when "origin" does
> not have acdc101? I want to know that server-x@joe.com doesn't have
> it, while server-y@mary.org does. This is the frequent problem in
> conversation, and is the reason we have to be able to talk about the
> particular upstream server.
>
> This change does not eliminate the ability to obscure multiple
> different server names using "origin" for those who think that is the
> best way to do things, it just eliminates the requirement for doing
> so.
Dscho, although I can agree that more flexibility is not always a good
thing, I think that in this situation it is a good thing. I especially
like that git-clone remembers what name it used for upstream repository
(git clone --origin <name>).
Mark, if this change is mainly about the fact that git doesn't allow
to specify default remote to fetch for detached HEAD (and submodules
use detached HEAD), why not provide "branch.HEAD.remote" etc., which
would be used _only_ if we are on detached HEAD (i.e. branch has no
name).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/5] Use new compress helpers in git files
From: Kristian Høgsberg @ 2008-01-11 15:29 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550801102337w1afc6c88n2c60f26fa80d8da4@mail.gmail.com>
On Fri, 2008-01-11 at 08:37 +0100, Marco Costalba wrote:
> These are the 'easy' ones, where a signgle step
> compression is requested so that we can use only
> one call to compress_all()
>
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
> ---
> archive-zip.c | 28 +++-------------------------
> builtin-pack-objects.c | 21 ++++-----------------
> diff.c | 22 +++++-----------------
> index-pack.c | 20 +++-----------------
> 4 files changed, 15 insertions(+), 76 deletions(-)
>
> diff --git a/archive-zip.c b/archive-zip.c
> index 74e30f6..9071b86 100644
> --- a/archive-zip.c
> +++ b/archive-zip.c
> @@ -3,6 +3,7 @@
> */
> #include "cache.h"
> #include "commit.h"
> +#include "compress.h"
> #include "blob.h"
> #include "tree.h"
> #include "quote.h"
> @@ -97,33 +98,10 @@ static void copy_le32(unsigned char *dest,
> static void *zlib_deflate(void *data, unsigned long size,
> unsigned long *compressed_size)
> {
How about just getting rid of this function alltogether, since it seems
to do more or less the same as your new compress_all() function? Just
change the call-sites of zlib_deflate() to call compress_all() instead.
> @@ -1037,23 +1038,10 @@ static unsigned char *deflate_it(char *data,
> unsigned long size,
> unsigned long *result_size)
> {
Same here.
cheers,
Kristian
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Harris @ 2008-01-11 15:39 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0801111409400.2497@ds9.cixit.se>
On Jan 11, 2008 8:12 AM, Peter Karlsson <peter@softwolves.pp.se> wrote:
> > > I meant to say that any software that claims to be Windows software
> > > should handle, and produce, CRLF line breaks in text files.
>
> > Including zip/unzip?
>
> Yup (zip -l, unzip -a).
How is this any different from core.autocrlf? You get CRLF conversion
if you ask for it, and not if you don't.
Peter Harris
^ permalink raw reply
* Re: [PATCH 4/5] Use new compress helpers in http-push.c
From: Kristian Høgsberg @ 2008-01-11 15:39 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550801102339o757eea62h40b5e00cd904f7e1@mail.gmail.com>
On Fri, 2008-01-11 at 08:39 +0100, Marco Costalba wrote:
> A multistep compress is required here, so
> we need the full arsenal of compress helpers.
>
> Signed-off-by: Marco Costalba <mcostalba@gmail.com>
> ---
> http-push.c | 22 ++++++++--------------
> 1 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/http-push.c b/http-push.c
> index 55d0c94..b7fe57f 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -1,5 +1,6 @@
> #include "cache.h"
> #include "commit.h"
> +#include "compress.h"
> #include "pack.h"
> #include "tag.h"
> #include "blob.h"
> @@ -491,31 +492,24 @@ static void start_put(struct transfer_request
> hdrlen = sprintf(hdr, "%s %lu", typename(type), len) + 1;
>
> /* Set it up */
> - memset(&stream, 0, sizeof(stream));
> - deflateInit(&stream, zlib_compression_level);
> - size = deflateBound(&stream, len + hdrlen);
> + size = compress_alloc(&stream, zlib_compression_level, len + hdrlen);
> strbuf_init(&request->buffer.buf, size);
> request->buffer.posn = 0;
>
> /* Compress it */
> - stream.next_out = (unsigned char *)request->buffer.buf.buf;
> - stream.avail_out = size;
> + compress_start(&stream, (void *)hdr, hdrlen,
> + (unsigned char *)request->buffer.buf.buf, size);
>
> /* First header.. */
> - stream.next_in = (void *)hdr;
> - stream.avail_in = hdrlen;
> - while (deflate(&stream, 0) == Z_OK)
> - /* nothing */;
> + compress_next(&stream, Z_NO_FLUSH);
How about moving next_in and avail_in to be args of compress_next() so
the user doesn't have to deal with the z_stream object at all? For
example:
compress_next(&stream, hdr, hdrlen, Z_NO_FLUSH);
and of course remove them from the compress_start() function.
> /* Then the data itself.. */
> stream.next_in = unpacked;
> stream.avail_in = len;
> - while (deflate(&stream, Z_FINISH) == Z_OK)
> - /* nothing */;
> - deflateEnd(&stream);
> - free(unpacked);
> + compress_next(&stream, Z_FINISH);
This whole chunk just becomes
compress_next(&stream, unpacked, len, Z_FINISH);
cheers,
Kristian
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-11 15:58 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Gregory Jefferis, Junio C Hamano, Git Mailing List
In-Reply-To: <7EAB1DA8-627D-455E-AA23-C404FDC615D9@zib.de>
On Fri, 11 Jan 2008, Steffen Prohaska wrote:
>
> Are you also for "autocrlf=input" as the default on Unix?
No. What would it help?
"autocrlf" on Windows actually helps you (big upside, very small
downside). On Unix or other sane systems, it has zero upside, so while the
risk is still very small, there is now no big upside to counteract it.
Again, what is "default" supposed to be? I argue that it's supposed to be
the thing that is right for 99.9% of all people. And that simply isn't
true on Unix.
Linus
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Linus Torvalds @ 2008-01-11 16:03 UTC (permalink / raw)
To: Sam Vilain
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <47870CDF.4010606@vilain.net>
On Fri, 11 Jan 2008, Sam Vilain wrote:
>
> The difference seems only barely measurable;
Ok.
It may be that it might help other cases, but that seems unlikely.
The more likely answer is that it's either of:
- yes, zlib uncompression is noticeable in profiles, but that the
cold-cache access is simply the bigger problem, and getting rid of zlib
just moves the expense to whatever other thing that needs to access it
(memcpy, xdelta apply, whatever)
or
- I don't know exactly which patch you used (did you just do the
"core.deltacompression=0" thing?), and maybe zlib is fairly expensive
even for just the setup crud, even when it doesn't really need to be.
but who knows..
Linus
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Mark Levedahl @ 2008-01-11 16:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <m3odbsmlkr.fsf@roke.D-201>
On Jan 11, 2008 10:25 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>
> Mark, if this change is mainly about the fact that git doesn't allow
> to specify default remote to fetch for detached HEAD (and submodules
> use detached HEAD), why not provide "branch.HEAD.remote" etc., which
> would be used _only_ if we are on detached HEAD (i.e. branch has no
> name).
>
Practically speaking, this would just change the name of the config
variable (from remotes.default to branch.HEAD.remote). However, this
value is used *whenever* the current branch does not have
corresponding branch.<name>.remote, and that is not restricted to
detached heads, it applies anytime the current HEAD is not a tracking
branch. So, I believe remotes.default better reflects this generality
than does branch.HEAD.remote.
Mark
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-11 16:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Gregory Jefferis, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801110756260.3148@woody.linux-foundation.org>
On Jan 11, 2008, at 4:58 PM, Linus Torvalds wrote:
>
>
> On Fri, 11 Jan 2008, Steffen Prohaska wrote:
>>
>> Are you also for "autocrlf=input" as the default on Unix?
>
> No. What would it help?
You may later decide that you want to check out your project on Windows.
In this case your repository should not contain CRLF. autocrlf=input
ensures this.
So given the current options, autocrlf=input is the only
reasonable default on Unix if git wants to support cross-platform
development as its default.
> "autocrlf" on Windows actually helps you (big upside, very small
> downside). On Unix or other sane systems, it has zero upside, so
> while the
> risk is still very small, there is now no big upside to counteract it.
autocrlf=input on Unix helps cross-platform development, too.
> Again, what is "default" supposed to be? I argue that it's supposed
> to be
> the thing that is right for 99.9% of all people. And that simply isn't
> true on Unix.
autocrlf=input is true for the very same people that need autocrlf=true
on Windows. Every developer who ever plans to check out his code on
Windows and on Unix should have these default.
I don't think the CRLF problem is a Windows vs. Unix discussion.
In my view, the discussion is wether git will have real cross-
platform support as its default or not. The current default is
sane for native Unix or native Windows projects. For cross-
platform projects the default needs to be changed in the way
described above. Git needs to ensure that CRLF never enters the
repository for text files. If you did not set autocrlf=true,
copying source code from Windows to Unix would not be supported.
But as you earlier mentioned, this seems to be a common
operation and I am observing the same. So I recommend
autocrlf=input on Unix if you plan to ever go cross-platform.
Steffen
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Douglas Stockwell @ 2008-01-11 16:36 UTC (permalink / raw)
To: git
In-Reply-To: <2faad3050801110419h20acbda8me1cbdb4c6e06a086@mail.gmail.com>
Baz wrote:
> On Jan 10, 2008 10:49 PM, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> With Authen::SASL and Net::SMTP::SSL, you can get 1 patch at a time in
> via gmail. The alternative connection mode which git-send-email
> doesn't support yet is to connect over smtp then negotiate TLS using
> 'STARTTLS'. If you do this then you can send multiple patches via
> gmail with a single call to git-send-email.
I just tested this. I *was* able to send multiple patches in a single call?
Doug
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Mark Levedahl @ 2008-01-11 16:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.LSU.1.00.0801111501510.31053@racer.site>
On Jan 11, 2008 10:03 AM, Johannes Schindelin >
> Okay, so with your change the user has to either remember or lookup which
> is the default remote. Without your change, the user has to either
> remember or lookup where origin points to.
>
> I still think your change does not help.
That's a theoretical argument: my *experience* with trying to make the
current workflow operate was sufficiently bad and troublesome that it
caused me to write code and fix it to enable the new workflow. Also,
absent submodules the new workflow is fully supported by
branch.<name>.remote: are you advocating the elimination of that
existing feature?
Mark
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Björn Steinbrink @ 2008-01-11 17:01 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Johannes Schindelin, gitster, git
In-Reply-To: <30e4a070801110839j6b27e224j9a83fc9975f2e4c6@mail.gmail.com>
On 2008.01.11 11:39:48 -0500, Mark Levedahl wrote:
> On Jan 11, 2008 10:03 AM, Johannes Schindelin >
> > Okay, so with your change the user has to either remember or lookup which
> > is the default remote. Without your change, the user has to either
> > remember or lookup where origin points to.
> >
> > I still think your change does not help.
>
> That's a theoretical argument: my *experience* with trying to make the
> current workflow operate was sufficiently bad and troublesome that it
> caused me to write code and fix it to enable the new workflow. Also,
> absent submodules the new workflow is fully supported by
> branch.<name>.remote: are you advocating the elimination of that
> existing feature?
AFAICT your main point is that you can do:
git config --get remotes.default
and get an unique _symbolic_ name, right? So while you still need to
lookup the value of remotes.default, you get e.g. "myremote" instead of
"git://myremote/foo.git" which you get from "git remote show origin". At
least that's how I interpreted it. Your argumentation wasn't that clear
on what you actually want to achieve/improve and why just looking up
"origin" isn't enough, IMHO.
A different approach, which feels more in-line with the current state of
things, might be to allow remote aliases. "origin" would be an alias of
"myremote", and "git remote show origin" might say "origin is an alias
for myremote" followed by the details of "myremote". So that would give
you the same benefit, but "origin" would keep its meaning, and you would
not get different behaviour depending on some configuration setting (so
the poor folks on #git can just assume that "origin" is the default for
everyone).
Admittedly, I don't see any use-case for aliases except for that origin
thing, but maybe someone else does?
Björn
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Baz @ 2008-01-11 17:22 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: git
In-Reply-To: <fm85u3$mbd$1@ger.gmane.org>
On Jan 11, 2008 4:36 PM, Douglas Stockwell <doug@11011.net> wrote:
> Baz wrote:
> > On Jan 10, 2008 10:49 PM, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > With Authen::SASL and Net::SMTP::SSL, you can get 1 patch at a time in
> > via gmail. The alternative connection mode which git-send-email
> > doesn't support yet is to connect over smtp then negotiate TLS using
> > 'STARTTLS'. If you do this then you can send multiple patches via
> > gmail with a single call to git-send-email.
>
> I just tested this. I *was* able to send multiple patches in a single call?
I'm not going to question the bearer of good news :). The error simon
was getting with this was:
> Well, it seems that this only works when sending only 1 patch, when
> sending multiple patches the second one fails with this error:
>> 5.7.0 No identity changes permitted. c14sm2136541nfi
(this was off-list at the tail end of the thread). IIRC I confirmed
that this happened to me but I've used msmtp ever since. Maybe
something's changed at the google end in the meantime.
And looking back at Paolo's problem I see its not going to be the
Authen::SASL problem, its too early in the code; its possible that
he's still trying to connect to port 587 (requires smtp/starttls) not
the default ssl port.
>
> Doug
Cheers,
Baz
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-11 17:25 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Gregory Jefferis, Junio C Hamano, Git Mailing List
In-Reply-To: <D36EB89D-11A3-4EAF-BC1C-6100383FCBFC@zib.de>
On Fri, 11 Jan 2008, Steffen Prohaska wrote:
> >
> > No. What would it help?
>
> You may later decide that you want to check out your project on Windows.
> In this case your repository should not contain CRLF. autocrlf=input
> ensures this.
But under Unix, it would never do that *anyway*, unless the file for some
reason really needs it (which I cannot imagine, but I've never seen
anything so craptastically stupid that some crazy person hasn't done it)
So your argument is bogus.
Linus
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Jakub Narebski @ 2008-01-11 17:27 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Mark Levedahl, Johannes Schindelin, gitster, git
In-Reply-To: <20080111170127.GA23893@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> A different approach, which feels more in-line with the current state of
> things, might be to allow remote aliases. "origin" would be an alias of
> "myremote", and "git remote show origin" might say "origin is an alias
> for myremote" followed by the details of "myremote". So that would give
> you the same benefit, but "origin" would keep its meaning, and you would
> not get different behaviour depending on some configuration setting (so
> the poor folks on #git can just assume that "origin" is the default for
> everyone).
>
> Admittedly, I don't see any use-case for aliases except for that origin
> thing, but maybe someone else does?
Aliases for remotes can address current deficiency in git, namely that
you cannot have push and pull under the same remote if they use different
URLs. One could use such alias to have the same name for pull and for push.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-11 17:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Gregory Jefferis, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801110924380.3148@woody.linux-foundation.org>
On Jan 11, 2008, at 6:25 PM, Linus Torvalds wrote:
>
>
> On Fri, 11 Jan 2008, Steffen Prohaska wrote:
>>>
>>> No. What would it help?
>>
>> You may later decide that you want to check out your project on
>> Windows.
>> In this case your repository should not contain CRLF. autocrlf=input
>> ensures this.
>
> But under Unix, it would never do that *anyway*, unless the file
> for some
> reason really needs it (which I cannot imagine, but I've never seen
> anything so craptastically stupid that some crazy person hasn't
> done it)
>
> So your argument is bogus.
Ah sorry, I misunderstood you in [1]. I thought your last point
"Mixed Windows usage" meant what I have in mind: A user working
in a mixed Windows/Unix environment who creates a file using
Windows tools and commits it in the Unix environment. In this
case the CRLF file will be transferred from Windows to Unix
without git being involved. The right thing for git on Unix is
to remove CRLF during a commit but still write only LF during
check out. So autocrlf=input is the right choice.
[1] http://article.gmane.org/gmane.comp.version-control.git/70082
It happens that people working in a mixed environment do such things.
They just copy files from Windows to Unix and commit there. Not very
often, but it happens. So it would be nice if git would handle this
situation and it actually can by setting autocrlf=input.
My point is that perfect support for mixed environments requires
that git removes CRLF from any input on any platform. However,
git should behave differently during checkout. In this case the
native line ending should be written (LF on Unix, CRLF on
Windows). The difference happens during check out; commit should
be handled identically.
Steffen
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-11 18:10 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Gregory Jefferis, Junio C Hamano, Git Mailing List
In-Reply-To: <930EC77A-73D1-4DDD-81D4-BF22B248FCB6@zib.de>
On Fri, 11 Jan 2008, Steffen Prohaska wrote:
>
> Ah sorry, I misunderstood you in [1]. I thought your last point
> "Mixed Windows usage" meant what I have in mind: A user working
> in a mixed Windows/Unix environment who creates a file using
> Windows tools and commits it in the Unix environment. In this
> case the CRLF file will be transferred from Windows to Unix
> without git being involved. The right thing for git on Unix is
> to remove CRLF during a commit but still write only LF during
> check out. So autocrlf=input is the right choice.
Oh, ok, I didn't realize.
But yes, if you use a network share across windows and Unixand actually
*share* the working tree over it, then yes, you'd want "autocrlf=input" on
the unix side.
However, I think that falls under the "0.1%" case, not the "99.9%" case.
I realize that people probably do that more often with centralized
systems, but with a distributed thing, it probably makes a *ton* more
sense to have separate trees. But I could kind of see having a shared
development directory and accessing it from different types of machines
too.
I'd also bet that crlf behavior of git itself will be the *least* of your
problems in that situation. You'd have all the *other* tools to worry
about, and would probably be very aware indeed of any CRLF issues. So at
that point, the "automatic" or default behaviour is probably not a big
deal, because everything _else_ you do likely needs special effort too!
Linus
^ permalink raw reply
* [PATCH] git-relink.txt: describe more clearly how hard linking occurs
From: Brandon Casey @ 2008-01-11 18:14 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Documentation/git-relink.txt | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-relink.txt b/Documentation/git-relink.txt
index ccbda9f..06a3e32 100644
--- a/Documentation/git-relink.txt
+++ b/Documentation/git-relink.txt
@@ -7,12 +7,13 @@ git-relink - Hardlink common objects in local repositories
SYNOPSIS
--------
-'git-relink' [--safe] <dir> <dir> [<dir>]\*
+'git-relink' [--safe] <dir> [<dir>]\* <master_dir>
DESCRIPTION
-----------
-This will scan 2 or more object repositories and look for common objects, check
-if they are hardlinked, and replace one with a hardlink to the other if not.
+This will scan 1 or more object repositories and look for objects in common
+with a master repository. Objects not already hardlinked to the master
+repository will be replaced with a hardlink to the master repository.
OPTIONS
-------
--
1.5.4.rc2.84.gf85fd-dirty
^ permalink raw reply related
* [PATCH] git-relink.perl: warn() instead of die() on directory open failure
From: Brandon Casey @ 2008-01-11 18:11 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Sometimes the repository to link to is not under your control.
If it contains files or unreadable directories, git-relink will
die without this patch.
-brandon
git-relink.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-relink.perl b/git-relink.perl
index f6b4f6a..391b12d 100755
--- a/git-relink.perl
+++ b/git-relink.perl
@@ -69,7 +69,7 @@ sub do_scan_directory($$$) {
my $dfulldir = sprintf("%sobjects/%s/",$dstdir,$subdir);
opendir(S,$sfulldir)
- or die "Failed to opendir $sfulldir: $!";
+ or (warn "Failed to opendir $sfulldir: $!" and return);
foreach my $file (grep(!/\.{1,2}$/, readdir(S))) {
my $sfilename = $sfulldir . $file;
--
1.5.4.rc2.84.gf85fd-dirty
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-11 18:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Gregory Jefferis, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801111005360.3148@woody.linux-foundation.org>
On Jan 11, 2008, at 7:10 PM, Linus Torvalds wrote:
>
>
> On Fri, 11 Jan 2008, Steffen Prohaska wrote:
>>
>> Ah sorry, I misunderstood you in [1]. I thought your last point
>> "Mixed Windows usage" meant what I have in mind: A user working
>> in a mixed Windows/Unix environment who creates a file using
>> Windows tools and commits it in the Unix environment. In this
>> case the CRLF file will be transferred from Windows to Unix
>> without git being involved. The right thing for git on Unix is
>> to remove CRLF during a commit but still write only LF during
>> check out. So autocrlf=input is the right choice.
>
> Oh, ok, I didn't realize.
>
> But yes, if you use a network share across windows and Unixand
> actually
> *share* the working tree over it, then yes, you'd want
> "autocrlf=input" on
> the unix side.
>
> However, I think that falls under the "0.1%" case, not the "99.9%"
> case.
>
> I realize that people probably do that more often with centralized
> systems, but with a distributed thing, it probably makes a *ton* more
> sense to have separate trees. But I could kind of see having a shared
> development directory and accessing it from different types of
> machines
> too.
It just happens yesterday that I copied a file from Unix to Windows
(lucky I am ;) for a quite simple reason. I fetched and merged and
realized that another developer forgot to check in a new file. He
had already left. So I just looked into his workspace and copied
the file. This has nothing to do with centralized system or not.
We're just working in a mixed OS environment with shared filesystems.
I didn't even think about the line endings in this situation because
everything just worked. Actually I like the idea that I do not
need to think about the endings because git will care about them.
Actually many other tools work well with CRLF. For example, vi
just displays [dos] in its status bar; but besides this everything
is just fine.
> I'd also bet that crlf behavior of git itself will be the *least*
> of your
> problems in that situation. You'd have all the *other* tools to worry
> about, and would probably be very aware indeed of any CRLF issues.
> So at
> that point, the "automatic" or default behaviour is probably not a big
> deal, because everything _else_ you do likely needs special effort
> too!
I don't think so. In the setting I described above, the questions I
receive
are not about the other tools but about git. I already started to teach
everyone the new "autocrlf=input" policy to avoid these questions. I
don't
care that much about potential file corruption (though I'd feel more
comfortable if I knew git would have stronger guarantees). During
the next
checkout on Windows file corruption would happen anyway.
Steffen
^ permalink raw reply
* [PATCH 1/6] Better error handling in compress_all()
From: Marco Costalba @ 2008-01-11 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Also let the caller to xmalloc() the buffer
int compress_start()
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
This patch belong to the previous compression series,
not the decompression one that I'm publishing right now.
Anyhow next patches depends on this, so that's the reason
why is the first.
compress.c | 19 +++++++++----------
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/compress.c b/compress.c
index be771a9..a8f46d5 100644
--- a/compress.c
+++ b/compress.c
@@ -12,7 +12,7 @@ int compress_start(z_stream *stream,
unsigned char *in, unsigned long in_size,
unsigned char *out, unsigned long out_size)
{
- stream->next_out = (out ? out : xmalloc(out_size));
+ stream->next_out = out;
stream->avail_out = out_size;
stream->next_in = in;
stream->avail_in = in_size;
@@ -36,19 +36,18 @@ unsigned long compress_free(z_stream
return stream->total_out;
}
-unsigned long compress_all(int level, unsigned char *data,
- unsigned long size, unsigned char **out)
+unsigned long compress_all(int level, unsigned char *in,
+ unsigned long in_size, unsigned char **out)
{
- int bound, result;
+ unsigned long out_size;
z_stream stream;
- bound = compress_alloc(&stream, level, size);
- compress_start(&stream, data, size, NULL, bound);
+ out_size = compress_alloc(&stream, level, in_size);
+ *out = xmalloc(out_size);
- *out = stream.next_out;
- result = compress_next(&stream, Z_FINISH);
-
- if (result != Z_STREAM_END) {
+ if ( compress_start(&stream, in, in_size, *out, out_size) != Z_OK
+ || compress_next(&stream, Z_FINISH) != Z_STREAM_END)
+ {
compress_free(&stream);
free(*out);
*out = NULL;
--
1.5.4.rc2.90.gf158-dirty
^ permalink raw reply related
* [PATCH 2/6] Introduce stream decompress helpers
From: Marco Costalba @ 2008-01-11 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Decompressing turns out to be more difficult then
comrpessing.
Helpers are more because more are the way
zlib deflate() is used in git.
This patch just introduces the helpers,
still no code change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
This patch will probably be wrapped at the bottom lines
by the mailer (gmail), sorry in advance for this.
compress.c | 81 ++++++++++++++++++++++++++++++++
compress.h | 17 ++++++++++++-
2 files changed, 97 insertions(+), 1 deletions(-)
diff --git a/compress.c b/compress.c
index a8f46d5..f73cf2c 100644
--- a/compress.c
+++ b/compress.c
@@ -1,6 +1,10 @@
#include "cache.h"
#include "compress.h"
+/*
+ * Compression helpers
+ */
+
unsigned long compress_alloc(z_stream *stream, int level, unsigned long size)
{
memset(stream, 0, sizeof(*stream));
@@ -55,3 +59,80 @@ unsigned long compress_all(int level, unsigned
}
return compress_free(&stream);
}
+
+
+/*
+ * Decompression helpers
+ */
+
+int decompress_alloc(z_stream *stream)
+{
+ memset(stream, 0, sizeof(*stream));
+ return inflateInit(stream);
+}
+
+int decompress_from(z_stream *stream, unsigned char *in, unsigned long in_size)
+{
+ stream->next_in = in;
+ stream->avail_in = in_size;
+ return Z_OK;
+}
+
+int decompress_into(z_stream *stream, unsigned char *out, unsigned
long out_size)
+{
+ stream->next_out = out;
+ stream->avail_out = out_size;
+ return Z_OK;
+}
+
+int decompress_next(z_stream *stream, int flush)
+{
+ return inflate(stream, flush);
+}
+
+int decompress_next_from(z_stream *stream, unsigned char *in,
unsigned long in_size, int flush)
+{
+ decompress_from(stream, in, in_size);
+ return inflate(stream, flush);
+}
+
+int decompress_next_into(z_stream *stream, unsigned char *out,
unsigned long out_size, int flush)
+{
+ decompress_into(stream, out, out_size);
+ return inflate(stream, flush);
+}
+
+unsigned long decompress_free(z_stream *stream)
+{
+ inflateEnd(stream);
+ return stream->total_out;
+}
+
+unsigned long decompress_all(unsigned char *in, unsigned long in_size,
+ unsigned char *out, unsigned long out_size)
+{
+/* caller should check for return value != 0 */
+
+ z_stream stream;
+ int st;
+
+ if (decompress_alloc(&stream) != Z_OK)
+ return 0;
+
+ if ( decompress_from(&stream, in, in_size) != Z_OK
+ || decompress_into(&stream, out, out_size) != Z_OK)
+ goto fail;
+
+ do {
+ st = decompress_next(&stream, Z_FINISH);
+ } while (st == Z_OK);
+
+ if (st != Z_STREAM_END)
+ goto fail;
+
+ return decompress_free(&stream);
+
+fail:
+ decompress_free(&stream);
+ return 0;
+}
diff --git a/compress.h b/compress.h
index 16b0147..a81d006 100644
--- a/compress.h
+++ b/compress.h
@@ -6,7 +6,22 @@ extern int compress_start(z_stream *stream, unsigned char *in,
unsigned char *out, unsigned long out_size);
extern int compress_next(z_stream *stream, int flush);
extern unsigned long compress_free(z_stream *stream);
-extern unsigned long compress_all(int level, unsigned char *data,
unsigned long size,
+extern unsigned long compress_all(int level, unsigned char *in,
unsigned long in_size,
unsigned char **out);
+
+extern int decompress_alloc(z_stream *stream);
+
+extern int decompress_from(z_stream *stream, unsigned char *in,
unsigned long in_size);
+extern int decompress_into(z_stream *stream, unsigned char *out,
unsigned long out_size);
+
+extern int decompress_next(z_stream *stream, int flush);
+extern int decompress_next_from(z_stream *stream, unsigned char *in,
unsigned long in_size, int flush);
+extern int decompress_next_into(z_stream *stream, unsigned char *out,
unsigned long out_size, int flush);
+
+extern unsigned long decompress_free(z_stream *stream);
+
+extern unsigned long decompress_all(unsigned char *in, unsigned long in_size,
+ unsigned char *out, unsigned long
out_size);
+
#endif
--
1.5.4.rc2.90.gf158-dirty
^ permalink raw reply related
* [PATCH 3/6] Use new decompress_all() helper in git
From: Marco Costalba @ 2008-01-11 18:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Only in two places is possible to really simplify
deflate code with the all_in_one decompress_all()
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
builtin-apply.c | 23 +++++++++--------------
index-pack.c | 30 +++++++-----------------------
2 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index d57bb6e..6dd2b8c 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -8,6 +8,7 @@
*/
#include "cache.h"
#include "cache-tree.h"
+#include "compress.h"
#include "quote.h"
#include "blob.h"
#include "delta.h"
@@ -1105,23 +1106,17 @@ static inline int metadata_changes(struct
static char *inflate_it(const void *data, unsigned long size,
unsigned long inflated_size)
{
- z_stream stream;
- void *out;
- int st;
+ unsigned char *out;
+ unsigned long out_size;
- memset(&stream, 0, sizeof(stream));
+ out = xmalloc(inflated_size);
+ out_size = decompress_all((unsigned char *)data, size, out, inflated_size);
- stream.next_in = (unsigned char *)data;
- stream.avail_in = size;
- stream.next_out = out = xmalloc(inflated_size);
- stream.avail_out = inflated_size;
- inflateInit(&stream);
- st = inflate(&stream, Z_FINISH);
- if ((st != Z_STREAM_END) || stream.total_out != inflated_size) {
+ if (out_size != inflated_size) {
free(out);
return NULL;
}
- return out;
+ return (char *)out;
}
static struct fragment *parse_binary_hunk(char **buf_p,
diff --git a/index-pack.c b/index-pack.c
index 880088e..30d7837 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -169,24 +169,18 @@ static void *unpack_entry_data(unsigned long offset,
z_stream stream;
void *buf = xmalloc(size);
- memset(&stream, 0, sizeof(stream));
- stream.next_out = buf;
- stream.avail_out = size;
- stream.next_in = fill(1);
- stream.avail_in = input_len;
- inflateInit(&stream);
+ decompress_alloc(&stream);
+ decompress_into(&stream, buf, size);
for (;;) {
- int ret = inflate(&stream, 0);
+ int ret = decompress_next_from(&stream, fill(1), input_len, Z_NO_FLUSH);
use(input_len - stream.avail_in);
if (stream.total_out == size && ret == Z_STREAM_END)
break;
if (ret != Z_OK)
- bad_object(offset, "inflate returned %d", ret);
- stream.next_in = fill(1);
- stream.avail_in = input_len;
+ bad_object(offset, "decompress returned %d", ret);
}
- inflateEnd(&stream);
+ decompress_free(&stream);
return buf;
}
@@ -261,8 +255,6 @@ static void *get_data_from_pack(struct object_entry
unsigned long len = obj[1].idx.offset - from;
unsigned long rdy = 0;
unsigned char *src, *data;
- z_stream stream;
- int st;
src = xmalloc(len);
data = src;
@@ -273,16 +265,8 @@ static void *get_data_from_pack(struct object_entry
rdy += n;
} while (rdy < len);
data = xmalloc(obj->size);
- memset(&stream, 0, sizeof(stream));
- stream.next_out = data;
- stream.avail_out = obj->size;
- stream.next_in = src;
- stream.avail_in = len;
- inflateInit(&stream);
- while ((st = inflate(&stream, Z_FINISH)) == Z_OK);
- inflateEnd(&stream);
- if (st != Z_STREAM_END || stream.total_out != obj->size)
- die("serious inflate inconsistency");
+ if (decompress_all(src, len, data, obj->size) != obj->size)
+ die("serious decompress inconsistency");
free(src);
return data;
}
--
1.5.4.rc2.90.gf158-dirty
^ permalink raw reply related
* [PATCH 4/6] Convert http-push.c and http-walker.c
From: Marco Costalba @ 2008-01-11 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Conversion for both files is very similar
and in both cases I have added a FIXME where
I would have added an additional decompress_free()
The corresponding deflateEnd() call is not present in
the original code, so I left the line commented out.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
http-push.c | 21 +++++++++------------
http-walker.c | 22 +++++++++-------------
2 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/http-push.c b/http-push.c
index b7fe57f..ec0568c 100644
--- a/http-push.c
+++ b/http-push.c
@@ -203,12 +203,11 @@ static size_t fwrite_sha1_file(void *ptr, size_t eltsize,
posn += retval;
} while (posn < size);
- request->stream.avail_in = size;
- request->stream.next_in = ptr;
+ decompress_from(&request->stream, ptr, size);
+
do {
- request->stream.next_out = expn;
- request->stream.avail_out = sizeof(expn);
- request->zret = inflate(&request->stream, Z_SYNC_FLUSH);
+ request->zret = decompress_next_into(&request->stream, expn,
+ sizeof(expn), Z_SYNC_FLUSH);
SHA1_Update(&request->c, expn,
sizeof(expn) - request->stream.avail_out);
} while (request->stream.avail_in && request->zret == Z_OK);
@@ -266,9 +265,7 @@ static void start_fetch_loose(struct transfer_request
return;
}
- memset(&request->stream, 0, sizeof(request->stream));
-
- inflateInit(&request->stream);
+ decompress_alloc(&request->stream);
SHA1_Init(&request->c);
@@ -305,11 +302,11 @@ static void start_fetch_loose(struct transfer_request
}
unlink(prevfile);
- /* Reset inflate/SHA1 if there was an error reading the previous temp
+ /* Reset decompress/SHA1 if there was an error reading the previous temp
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
- memset(&request->stream, 0, sizeof(request->stream));
- inflateInit(&request->stream);
+ // FIXME should we need decompress_free() here?
+ decompress_alloc(&request->stream);
SHA1_Init(&request->c);
if (prev_posn>0) {
prev_posn = 0;
@@ -735,7 +732,7 @@ static void finish_request(struct transfer_request *request)
if (request->http_code == 416)
fprintf(stderr, "Warning: requested range invalid; we may already
have all the data.\n");
- inflateEnd(&request->stream);
+ decompress_free(&request->stream);
SHA1_Final(request->real_sha1, &request->c);
if (request->zret != Z_STREAM_END) {
unlink(request->tmpfile);
diff --git a/http-walker.c b/http-walker.c
index 2c37868..b1d2a28 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "commit.h"
+#include "compress.h"
#include "pack.h"
#include "walker.h"
#include "http.h"
@@ -77,12 +78,10 @@ static size_t fwrite_sha1_file(void *ptr, size_t
eltsize, size_t
posn += retval;
} while (posn < size);
- obj_req->stream.avail_in = size;
- obj_req->stream.next_in = ptr;
+ decompress_from(&obj_req->stream, ptr, size);
do {
- obj_req->stream.next_out = expn;
- obj_req->stream.avail_out = sizeof(expn);
- obj_req->zret = inflate(&obj_req->stream, Z_SYNC_FLUSH);
+ obj_req->zret = decompress_next_into(&obj_req->stream, expn,
+ sizeof(expn), Z_SYNC_FLUSH);
SHA1_Update(&obj_req->c, expn,
sizeof(expn) - obj_req->stream.avail_out);
} while (obj_req->stream.avail_in && obj_req->zret == Z_OK);
@@ -140,10 +139,7 @@ static void start_object_request(struct walker *walker,
return;
}
- memset(&obj_req->stream, 0, sizeof(obj_req->stream));
-
- inflateInit(&obj_req->stream);
-
+ decompress_alloc(&obj_req->stream);
SHA1_Init(&obj_req->c);
url = xmalloc(strlen(obj_req->repo->base) + 51);
@@ -179,11 +175,11 @@ static void start_object_request(struct walker *walker,
}
unlink(prevfile);
- /* Reset inflate/SHA1 if there was an error reading the previous temp
+ /* Reset decompress/SHA1 if there was an error reading the previous temp
file; also rewind to the beginning of the local file. */
if (prev_read == -1) {
- memset(&obj_req->stream, 0, sizeof(obj_req->stream));
- inflateInit(&obj_req->stream);
+ // FIXME should we need decompress_free() here?
+ decompress_alloc(&obj_req->stream);
SHA1_Init(&obj_req->c);
if (prev_posn>0) {
prev_posn = 0;
@@ -243,7 +239,7 @@ static void finish_object_request(struct object_request
return;
}
- inflateEnd(&obj_req->stream);
+ decompress_free(&obj_req->stream);
SHA1_Final(obj_req->real_sha1, &obj_req->c);
if (obj_req->zret != Z_STREAM_END) {
unlink(obj_req->tmpfile);
--
1.5.4.rc2.90.gf158-dirty
^ permalink raw reply related
* [PATCH 5/6] Convert builtin-pack/unpack
From: Marco Costalba @ 2008-01-11 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Also in this case decompression helper conversion
is quite similar and not too complex, so they go
together.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
builtin-pack-objects.c | 14 ++++++--------
builtin-unpack-objects.c | 20 +++++++-------------
2 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 66dedf9..d2865fe 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -302,19 +302,17 @@ static int check_pack_inflate(struct
{
z_stream stream;
unsigned char fakebuf[4096], *in;
+ unsigned int in_size = 0;
int st;
- memset(&stream, 0, sizeof(stream));
- inflateInit(&stream);
+ decompress_alloc(&stream);
do {
- in = use_pack(p, w_curs, offset, &stream.avail_in);
- stream.next_in = in;
- stream.next_out = fakebuf;
- stream.avail_out = sizeof(fakebuf);
- st = inflate(&stream, Z_FINISH);
+ decompress_into(&stream, fakebuf, sizeof(fakebuf));
+ in = use_pack(p, w_curs, offset, &in_size);
+ st = decompress_next_from(&stream, in, in_size, Z_FINISH);
offset += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
- inflateEnd(&stream);
+ decompress_free(&stream);
return (st == Z_STREAM_END &&
stream.total_out == expect &&
stream.total_in == len) ? 0 : -1;
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 1e51865..f1a4883 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -1,5 +1,6 @@
#include "builtin.h"
#include "cache.h"
+#include "compress.h"
#include "object.h"
#include "delta.h"
#include "pack.h"
@@ -61,23 +62,18 @@ static void use(int bytes)
static void *get_data(unsigned long size)
{
z_stream stream;
- void *buf = xmalloc(size);
+ unsigned char *buf = xmalloc(size);;
- memset(&stream, 0, sizeof(stream));
-
- stream.next_out = buf;
- stream.avail_out = size;
- stream.next_in = fill(1);
- stream.avail_in = len;
- inflateInit(&stream);
+ decompress_alloc(&stream);
+ decompress_into(&stream, buf, size);
for (;;) {
- int ret = inflate(&stream, 0);
+ int ret = decompress_next_from(&stream, fill(1), len, Z_NO_FLUSH);
use(len - stream.avail_in);
if (stream.total_out == size && ret == Z_STREAM_END)
break;
if (ret != Z_OK) {
- error("inflate returned %d\n", ret);
+ error("decompress returned %d\n", ret);
free(buf);
buf = NULL;
if (!recover)
@@ -85,10 +81,8 @@ static void *get_data(unsigned long size)
has_errors = 1;
break;
}
- stream.next_in = fill(1);
- stream.avail_in = len;
}
- inflateEnd(&stream);
+ decompress_free(&stream);
return buf;
}
--
1.5.4.rc2.90.gf158-dirty
^ permalink raw reply related
* Re: [PATCH] Use commit template when cherry picking
From: Junio C Hamano @ 2008-01-11 18:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Deepak Saxena, git, Perry Wagle
In-Reply-To: <alpine.LSU.1.00.0801111208020.31053@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I would do a combination of "cherry-pick -n", "cat-file commit <commit> |
> sed '1,/^$/d'" and "commit -F" or "commit -f".
Doesn't cherry-pick have -e switch to allow you further edit the
message?
^ permalink raw reply
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