* Re: [PATCH] bundle, fast-import: detect write failure
From: Jakub Narebski @ 2008-01-11 9:14 UTC (permalink / raw)
To: git
In-Reply-To: <20080110162526.GB27808@artemis.madism.org>
Pierre Habouzit wrote:
> On Thu, Jan 10, 2008 at 01:00:15PM +0000, Jim Meyering wrote:
>> However, even if it's not technically required to fail at that point,
>> if it were my choice, I'd prefer to know when a .keep file whose
>> contents are unimportant just happens to reside on a bad spot on my
>> disk. I/O errors should never be ignored.
>
> Actually I think .keep files are empty, so the write() should not be
> there in the first place, and we should only check for close() right ?
> not that it matters that much.
In theory the .keep file should contain description _why_ the pack
is made kept. In practice git creates IIRC empty .kep files.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] bundle, fast-import: detect write failure
From: David Tweed @ 2008-01-11 9:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, Johannes Schindelin, git list
In-Reply-To: <7vejco4xv5.fsf@gitster.siamese.dyndns.org>
On Jan 11, 2008 7:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> In this case, a failure while closing that small .keep file is
> highly unlikely, and if we ever mange to trigger such a highly
> unlikely failure, I think we would rather want to *know* about
> it, as it is likely there is something more seriously wrong
> going on.
On a slightly related note: I've got a patch that handles the issue
that I reported a couple of months back that tmp pack/index objects
where a write fails partway through are not deleted by any git
processing, ie, when for example during git gc --prune we get
fatal: sha1 file '/media/usbdiskc/v.git/objects/tmp_pack_QCYYAi' write
error (No space left on device)
error: failed to run repack
but the tmp_pack_* isn't deleted. I put my patch on the back burner
when Junio declared a moratorium on new behaviours until after 1.5.4
gets released, but will post once things open up again.
As it relates to this discussion: one of the awkward things is that
the die stuff doesn't leave any programatic indication (ie, not just a
message to stderr) that a file is malformed due to a writing failure.
Per Nicolas Pitre's suggestion to delete failed tmp_ files during a
"git gc --prune", I just delete ALL tmp_ files at that time. This
approach seems a bit risky -- can something like a git-svn fetch which
generated tmp_ files by a different route be going on at the same time
as a git gc? -- but I couldn't think of another way to do it.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Pierre Habouzit @ 2008-01-11 9:45 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Git Mailing List, Johannes Schindelin, Marco Costalba,
Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101332150.3054@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 5671 bytes --]
On Thu, Jan 10, 2008 at 08:39:07PM +0000, Nicolas Pitre wrote:
> On Thu, 10 Jan 2008, Pierre Habouzit wrote:
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index a39cb82..252b03e 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -433,7 +433,10 @@ static unsigned long write_object(struct sha1file *f,
> }
> /* compress the data to store and put compressed length in datalen */
> memset(&stream, 0, sizeof(stream));
> - deflateInit(&stream, pack_compression_level);
> + if (obj_type == OBJ_REF_DELTA || obj_type == OBJ_OFS_DELTA)
> + deflateInit(&stream, 0);
> + else
> + deflateInit(&stream, pack_compression_level);
> maxsize = deflateBound(&stream, size);
> out = xmalloc(maxsize);
> /* Compress it */
>
> You then only need to run 'git repack -a -f -d' with and without the
> above patch.
Using as a PoC a test that is if (size <= 512) instead, I get:
vanilla git:
$ du -k .git/**/*.pack
180808 .git/objects/pack/pack-7bc9f383c92cbffe366da2d2a62b67bb33a53365.pack
$ repeat 5 time git blame MAINTAINERS >|/dev/null
git blame MAINTAINERS >| /dev/null 7,34s user 0,09s system 99% cpu 7,433 total
git blame MAINTAINERS >| /dev/null 7,31s user 0,16s system 100% cpu 7,475 total
git blame MAINTAINERS >| /dev/null 7,35s user 0,08s system 100% cpu 7,431 total
git blame MAINTAINERS >| /dev/null 7,30s user 0,18s system 99% cpu 7,482 total
git blame MAINTAINERS >| /dev/null 7,33s user 0,16s system 99% cpu 7,492 total
With a compression disabled for sizes <= 512:
$ du -k .git/**/*.pack
188840.git/objects/pack/pack-7bc9f383c92cbffe366da2d2a62b67bb33a53365.pack
$ repeat 5 time git blame MAINTAINERS >|/dev/null
git blame MAINTAINERS >| /dev/null 7,06s user 0,09s system 100% cpu 7,150 total
git blame MAINTAINERS >| /dev/null 7,08s user 0,13s system 99% cpu 7,209 total
git blame MAINTAINERS >| /dev/null 7,07s user 0,08s system 99% cpu 7,168 total
git blame MAINTAINERS >| /dev/null 7,02s user 0,15s system 99% cpu 7,177 total
git blame MAINTAINERS >| /dev/null 7,07s user 0,13s system 99% cpu 7,243 total
Okay, the size doesn't even budge, it's not even near being fun. Though
we gain 3% of wall clock time
Let's try with a limit of 1024 then !
$ du -k .git/**/*.pack
201725 .git/objects/pack/pack-7bc9f383c92cbffe366da2d2a62b67bb33a53365.pack
$ repeat 5 time git blame MAINTAINERS >|/dev/null
git blame MAINTAINERS >| /dev/null 6,93s user 0,16s system 77% cpu 9,109 total
git blame MAINTAINERS >| /dev/null 6,88s user 0,08s system 99% cpu 6,965 total
git blame MAINTAINERS >| /dev/null 6,84s user 0,10s system 99% cpu 6,952 total
git blame MAINTAINERS >| /dev/null 6,86s user 0,12s system 99% cpu 6,983 total
git blame MAINTAINERS >| /dev/null 6,81s user 0,18s system 99% cpu 6,994 total
Okay, the packs grows 10%, and the blame takes 6% less time.
Okay the numbers are still not that impressive, but my patch doesn't
touches _only_ deltas, but also log comments I said, so I've redone my
tests with git log and *TADAAAA*:
vanilla git:
repeat 5 time git log >|/dev/null
git log >| /dev/null 2,54s user 0,12s system 99% cpu 2,660 total
git log >| /dev/null 2,52s user 0,12s system 99% cpu 2,653 total
git log >| /dev/null 2,57s user 0,07s system 99% cpu 2,637 total
git log >| /dev/null 2,56s user 0,09s system 99% cpu 2,659 total
git log >| /dev/null 2,54s user 0,10s system 99% cpu 2,660 total
with the 512 octets limit:
$ repeat 5 time git log >|/dev/null
git log >| /dev/null 2,10s user 0,10s system 99% cpu 2,193 total
git log >| /dev/null 2,08s user 0,10s system 99% cpu 2,189 total
git log >| /dev/null 2,06s user 0,11s system 100% cpu 2,162 total
git log >| /dev/null 2,04s user 0,13s system 100% cpu 2,172 total
git log >| /dev/null 2,06s user 0,13s system 99% cpu 2,198 total
That's already a 20% time reduction.
with the 1024 octets limits:
$ repeat 5 time git log >|/dev/null
git log >| /dev/null 1,39s user 0,12s system 99% cpu 1,512 total
git log >| /dev/null 1,38s user 0,12s system 100% cpu 1,498 total
git log >| /dev/null 1,41s user 0,10s system 99% cpu 1,514 total
git log >| /dev/null 1,41s user 0,10s system 100% cpu 1,506 total
git log >| /dev/null 1,40s user 0,10s system 100% cpu 1,504 total
Yes that's 43% time reduction !
As a side note, repacking with the 1024 octets limits takes 4:06 here,
and 4:26 without the limit at all, which is 8% less time. I know it
doesn't matters a lot as repack is a once time operation, but still, it
would speed up git gc --auto which is not something to neglect
completely.
I say it's worth investigating a _lot_, and the patch is that complicated:
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index a39cb82..f454929 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -433,7 +433,7 @@ static unsigned long write_object(struct sha1file *f,
}
/* compress the data to store and put compressed length in datalen */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, pack_compression_level);
+ deflateInit(&stream, size > 1024 ? pack_compression_level : 0);
maxsize = deflateBound(&stream, size);
out = xmalloc(maxsize);
/* Compress it */
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* [RFH] how to know if a cherry-picked patch has been applied already?
From: Michal Vitecek @ 2008-01-11 10:47 UTC (permalink / raw)
To: git list
Hello everyone,
I'm managing a git repository where I include my and my co-workers'
work. With some co-workers I can use 'git merge' but with some I use
'git cherry-pick'. However, cherry-picking leads to problems because a
new commit ID is generated and I must remember which patches I have
cherry-picked to my tree. Is there any easy way to tell which patches
have and have not been applied?
Thanks,
Michal
--
fuf (fuf@mageo.cz)
^ permalink raw reply
* Re: [PATCH] gitweb: Change feeds from commit to commitdiff output.
From: Jakub Narebski @ 2008-01-11 11:12 UTC (permalink / raw)
To: Florian La Roche; +Cc: git
In-Reply-To: <20080110130900.GA9395@dudweiler.stuttgart.redhat.com>
Florian La Roche <laroche@redhat.com> writes:
> [PATCH] gitweb: Change feeds from commit to commitdiff output.
>
> Change feeds from displaying the commit to displaying the commitdiff
> output. This way the patches are shown directly and code review is
> done more easily via watching feeds.
First, this changes _link_, and not display (change summary), so the
commit message IMHO should read rather:
gitweb: Change feeds link from commit view to commitdiff view.
Change feed link from link to commit view to link to commitdiff
view. This way the patches are shown directly and code review is
done more easily via watching feeds.
I personally do not use gitweb feeds not feed readers, so I cannot say
if this change truly helps. I just don't know what the "feed watcher"
workflow looks like.
Second, at least for Atom format it is possible to give both 'commit'
and 'commitdiff' view links as alternate links for a feed. That is
something to consider.
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5566,7 +5566,7 @@ XML
> or next;
>
> # print element (entry, item)
> - my $co_url = href(-full=>1, action=>"commit", hash=>$commit);
> + my $co_url = href(-full=>1, action=>"commitdiff", hash=>$commit);
> if ($format eq 'rss') {
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] additional help when editing during interactive rebase
From: Johannes Schindelin @ 2008-01-11 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, William Morgan
In-Reply-To: <7vprw83g8z.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 11 Jan 2008, Junio C Hamano wrote:
> Do you mean you would instead suggest "git rebase --continue" in
> the insn, and make the workflow like this:
>
> $ git rebase -i ...
> Now do whatever you want and say "rebase --continue"
> $ edit foo.c
> $ git add foo.c
> $ git rebase --continue
>
> and have "rebase --continue" to continue with the modified
> contents recorded in the index, invoking "git commit --amend",
> but doing so only if the user hasn't run "git commit" with or
> without --amend yet?
Yes, exactly.
> It feels like a better automation than what we currently have,
> but I somewhat worry how that would change the user experience
> for using 'edit' to split a commit into two or more.
If you want to split a commit into two or more, you will already have
committed twice when you say "--continue", and all is fine.
However, if you do the first commit, and then only add the files for the
second commit, the HEAD's commit name has changed! And so, rebase can
pick up on that, and avoid the --amend.
IOW something like below. However, this patch does not yet make "rebase
-i" call "commit --amend" automatically when both the index and HEAD are
unchanged.
-- snipsnap --
[PATCH] rebase -i: only ever commit --amend when HEAD is untouched
When a commit is marked to edit, and the index is dirty when "rebase
--continue" is called, that state will be committed with the "--amend"
option.
However, this is wrong when the user wanted to split the commit.
Luckily, we can pick up on that, by recording the HEAD's name in the
file "amend", and only --amend when no commit was made in the interim.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-rebase--interactive.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index acdcc54..4a8a980 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -257,7 +257,7 @@ do_next () {
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
make_patch $sha1
- : > "$DOTEST"/amend
+ git rev-parse HEAD > "$DOTEST"/amend
warn
warn "You can amend the commit now, with"
warn
@@ -378,7 +378,9 @@ do
else
. "$DOTEST"/author-script ||
die "Cannot find the author identity"
- if test -f "$DOTEST"/amend
+ if test -f "$DOTEST"/amend &&
+ test $(git rev-parse HEAD) = \
+ $(cat "$DOTEST"/amend)
then
git reset --soft HEAD^ ||
die "Cannot rewind the HEAD"
^ permalink raw reply related
* Re: [PATCH] bundle, fast-import: detect write failure
From: Johannes Schindelin @ 2008-01-11 11:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jim Meyering, git list
In-Reply-To: <7vejco4xv5.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 10 Jan 2008, Junio C Hamano wrote:
> In this case, a failure while closing that small .keep file is highly
> unlikely, and if we ever mange to trigger such a highly unlikely
> failure, I think we would rather want to *know* about it, as it is
> likely there is something more seriously wrong going on.
>
> So let's keep that check on close().
My comment was not about that _check_, but about having this die() instead
of just printing out a warning.
If that close fails, strange things are going on, alright. But neither
the open() nor the write() failed at that point, so IMO it would be a
mistake to error out _here_. If later stages fail also, well, we can
die() there, no?
Ciao,
Dscho
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Johannes Schindelin @ 2008-01-11 12:03 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, git
In-Reply-To: <1200022189-2400-1-git-send-email-mlevedahl@gmail.com>
Hi,
On Thu, 10 Jan 2008, Mark Levedahl wrote:
> git's current support for remote nicknames other than
> "origin" is restricted to tracking branches where
> branch.<name>.remote is defined.
IIUC your patch only replaces the term "origin" by something
user-specifiable. I fail to see the use of it; care to explain what
workflow is easier with your patches than without?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use commit template when cherry picking
From: Johannes Schindelin @ 2008-01-11 12:10 UTC (permalink / raw)
To: Deepak Saxena; +Cc: git, Perry Wagle
In-Reply-To: <20080111074505.GC14022@plexity.net>
Hi,
On Thu, 10 Jan 2008, Deepak Saxena wrote:
> We are using git to manage our kernel tree and we often cherry-pick
> patches from upstream and while we want to save the original commit
> message, we also want to apply our default commit header to the log. If
> this patch is not the ideal solution, please let me know how I should go
> about this.
I would do a combination of "cherry-pick -n", "cat-file commit <commit> |
sed '1,/^$/d'" and "commit -F" or "commit -f".
You can make this an alias, too.
Hth,
Dscho
^ permalink raw reply
* Re: [RFH] how to know if a cherry-picked patch has been applied already?
From: Johannes Schindelin @ 2008-01-11 12:12 UTC (permalink / raw)
To: Michal Vitecek; +Cc: git list
In-Reply-To: <20080111104737.GA7332@mageo.cz>
Hi,
On Fri, 11 Jan 2008, Michal Vitecek wrote:
> Is there any easy way to tell which patches have and have not been
> applied?
If the patches are not too different, "git log --cherry-pick a...b" (note
the three dots instead of two) shows only those patches in b that are not
yet in a.
Hth,
Dscho
^ permalink raw reply
* Re: [RFH] how to know if a cherry-picked patch has been applied already?
From: Peter Baumann @ 2008-01-11 12:14 UTC (permalink / raw)
To: Michal Vitecek; +Cc: git list
In-Reply-To: <20080111104737.GA7332@mageo.cz>
On Fri, Jan 11, 2008 at 11:47:37AM +0100, Michal Vitecek wrote:
> Hello everyone,
>
> I'm managing a git repository where I include my and my co-workers'
> work. With some co-workers I can use 'git merge' but with some I use
> 'git cherry-pick'. However, cherry-picking leads to problems because a
> new commit ID is generated and I must remember which patches I have
> cherry-picked to my tree. Is there any easy way to tell which patches
> have and have not been applied?
>
> Thanks,
> Michal
Have a look at the manpage of git-cherry, which will tell you if you
already applied a commit/patch.
-Peter
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Baz @ 2008-01-11 12:19 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Douglas Stockwell, git
In-Reply-To: <4d8e3fd30801101449u11aabd73mba233301df157160@mail.gmail.com>
On Jan 10, 2008 10:49 PM, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On Jan 10, 2008 4:45 AM, Douglas Stockwell <doug@11011.net> wrote:
> > Paolo Ciarrocchi wrote:
> >
> > > Well, it would be nice to add this information to the wiki, it's still
> > > mentioning
> > > that you require an external program for supporting the TLS connection.
> > > I'll do that when I'll get my box working with the configuration you suggested,
> > >
> > > What I'm getting at the moment is:
> > > paolo@paolo-desktop:~/git$ git-send-email -compose -to
> > > paolo.ciarrocchi@gmail.com /home/paolo/Desktop/patch/
> > > snip
> > > snip
> > > Can't locate Net/SMTP/SSL.pm in @INC (@INC contains:
> >
> > As indicated, the module you need is Net::SMTP::SSL, if there is no
> > package for ubuntu, you can install it using CPAN:
> >
> > perl -MCPAN -e 'install Net::SMTP::SSL'
>
> I'm now getting:
> Unable to initialize SMTP properly. Is there something wrong with
> your config? at /home/paolo/bin/git-send-email line 638.
You also need to have Authen::SASL installed. Do you have that? As I
recall I needed to edit the code to even see that error.
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.
There was a patch offered a while back from Simon Sasburg to add
starttls support to git-send-email. At the time I questioned it but I
hadn't seen the 1-patch-at-a-time limit then. Thread:
http://kerneltrap.org/mailarchive/git/2007/10/31/373400
(nb the key thing added by this patch is starttls, not tls)
>
> I tried to get help on #git but I failed, it looks like other people
> are getting the same error.
Hope this helps,
Baz
>
> Ciao,
> --
> Paolo
> http://paolo.ciarrocchi.googlepages.com/
> -
>
> 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
* [PATCH] gitk: make Ctrl "+" really increase the font size
From: Johannes Schindelin @ 2008-01-11 12:39 UTC (permalink / raw)
To: Stephan Hennig, paulus-eUNUBHrolfbYtjvyW6yDsg
Cc: msysgit-/JYPxA39Uh5TLH3MbocFFw, git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <fm5oln$ahq$1@ger.gmane.org>
Only Ctrl "=" was bound to increase the font size, probably because
English keyboards have the plus on the same key as the equal sign.
However, not the whole world is English, and at least with some
other keyboard layouts, Ctrl "+" did not work as documented.
Noticed by Stephan Hennig.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
---
On Thu, 10 Jan 2008, Stephan Hennig wrote:
>
> Hi,
>
> reducing font size in gitk with CTRL-- works, but enlarging font
> size fails. Typing CTRL-+ just doesn't have any effect here.
This is no bug in msysgit, but in gitk.
Paul, please apply.
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 1da0b0a..462f6aa 100644
--- a/gitk
+++ b/gitk
@@ -996,6 +996,7 @@ proc makewindow {} {
bind . <$M1B-r> dosearchback
bind . <$M1B-s> dosearch
bind . <$M1B-equal> {incrfont 1}
+ bind . <$M1B-plus> {incrfont 1}
bind . <$M1B-KP_Add> {incrfont 1}
bind . <$M1B-minus> {incrfont -1}
bind . <$M1B-KP_Subtract> {incrfont -1}
^ permalink raw reply related
* Re: [PATCH] gitk: make Ctrl "+" really increase the font size
From: Johannes Sixt @ 2008-01-11 12:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Stephan Hennig, public-paulus-eUNUBHrolfbYtjvyW6yDsg, msysGit,
Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0801111238150.31053@racer.site>
Johannes Schindelin schrieb:
> Only Ctrl "=" was bound to increase the font size, probably because
> English keyboards have the plus on the same key as the equal sign.
> However, not the whole world is English, and at least with some
> other keyboard layouts, Ctrl "+" did not work as documented.
>
> Noticed by Stephan Hennig.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
^^^^^^^^^^^^^^...
WTF is going on these days?
[note: yours, git ML and msysgit ML adresses corrected manually]
-- Hannes
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Mark Levedahl @ 2008-01-11 13:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0801111301360.14355@wbgn129.biozentrum.uni-wuerzburg.de>
On Jan 11, 2008 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> IIUC your patch only replaces the term "origin" by something
> user-specifiable. I fail to see the use of it; care to explain what
> workflow is easier with your patches than without?
>
> Ciao,
> Dscho
Consider a project with several servers, each of which is *supposed*
is host the same project but due to lags in mirroring across airgaps,
etc., are never quite in sync. Now, we get on a teleconference and
discuss issues, find differences, and everyone reports that "origin"
has x, but in fact "origin" means different servers to almost
everyone. Also consider that only a small subset of the group really
understands git, most just follow cook-book recipes to get their work
done and don't understand what is going on.
This is my problem: "origin" is an abstraction that hides the
different server names in use and makes communication difficult,
having everyone use nicknames related to their particular upstream
server reduces the confusion.
Mark
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-11 13:12 UTC (permalink / raw)
To: Peter Harris
Cc: Johannes Schindelin, Junio C Hamano, Linus Torvalds,
J. Bruce Fields, Steffen Prohaska, Robin Rosenberg, Jeff King,
Git Mailing List, msysGit
In-Reply-To: <eaa105840801100631p6b95ed86j153d70244d474b03-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Peter Harris:
> > 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 about tar? rsync?
Sure.
> NFS and SMB copies from network shares?
I'd say that might not be as obvious, but it would be nice to have,
yes. A typed network file system that stores text as character streams
and binary data as octet streams.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* gitk dev branch: F5 problem again
From: Johannes Sixt @ 2008-01-11 13:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
I'm using gitk's dev branch (476ca63d Index [fnvr]highlights by id...) on
Windows.
Start gitk like this:
gitk somefile.c
while on a branch whose tip touches somefile.c.
Now:
git commit --amend
Then press F5 in gitk. I get these error reports after which gitk is
unresponsive:
can't read "children(1,)": no such element in array
can't read "children(1,)": no such element in array
while executing
"lindex $children($curview,$id) 0"
(procedure "ordertoken" line 15)
invoked from within
"ordertoken $id"
(procedure "idcol" line 2)
invoked from within
"idcol $idlist $id"
(procedure "layoutrows" line 51)
invoked from within
"layoutrows $rl1 $r"
(procedure "drawcommits" line 36)
invoked from within
"drawcommits $row $endrow"
(procedure "drawvisible" line 51)
invoked from within
"drawvisible"
(procedure "scrollcanv" line 3)
invoked from within
"scrollcanv .tf.histframe.csb 0.00852273 0.146591"
... same as above ...
"drawvisible"
(procedure "scrollcanv" line 3)
invoked from within
"scrollcanv .tf.histframe.csb 0.0170455 0.155114"
... same as above ...
"drawvisible"
("eval" body line 1)
invoked from within
"eval $script"
(procedure "dorunq" line 9)
invoked from within
"dorunq"
("after" script)
-- Hannes
^ permalink raw reply
* Re: [PATCH] gitk: make Ctrl "+" really increase the font size
From: Julio Espinoza-Sokal @ 2008-01-11 13:22 UTC (permalink / raw)
To: Johannes Sixt
Cc: Johannes Schindelin, Stephan Hennig,
public-paulus-eUNUBHrolfbYtjvyW6yDsg, msysGit, Git Mailing List
In-Reply-To: <47876823.1070800@viscovery.net>
On Jan 11, 2008 7:59 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Johannes Schindelin schrieb:
> > Only Ctrl "=" was bound to increase the font size, probably because
> > English keyboards have the plus on the same key as the equal sign.
> > However, not the whole world is English, and at least with some
> > other keyboard layouts, Ctrl "+" did not work as documented.
> >
> > Noticed by Stephan Hennig.
> >
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
> ^^^^^^^^^^^^^^...
> WTF is going on these days?
>
> [note: yours, git ML and msysgit ML adresses corrected manually]
>
> -- Hannes
>
I don't know if this is new, but it seems that's a feature of Gmane to
prevent spam.
http://gmane.org/tmda.php
^ permalink raw reply
* Re: [PATCH] gitk: make Ctrl "+" really increase the font size
From: Johannes Schindelin @ 2008-01-11 13:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysGit, Git Mailing List
In-Reply-To: <47876823.1070800@viscovery.net>
On Fri, 11 Jan 2008, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
>
> > Signed-off-by: Johannes Schindelin
> > <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
> ^^^^^^^^^^^^^^...
> WTF is going on these days?
>
> [note: yours, git ML and msysgit ML adresses corrected manually]
Umm. The copy of my mail _I_ got via vger.kernel.org was _not_ corrupted.
So I think the problem is on the viewer's side (IOW gmane), not the sender
or the mailing list...
Ciao,
Dscho
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Johannes Schindelin @ 2008-01-11 13:52 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, git
In-Reply-To: <30e4a070801110506h19b77488sbfa6ae48701f30f9@mail.gmail.com>
Hi,
On Fri, 11 Jan 2008, Mark Levedahl wrote:
> On Jan 11, 2008 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > IIUC your patch only replaces the term "origin" by something
> > user-specifiable. I fail to see the use of it; care to explain what
> > workflow is easier with your patches than without?
>
> Consider a project with several servers, each of which is *supposed* is
> host the same project but due to lags in mirroring across airgaps, etc.,
> are never quite in sync. Now, we get on a teleconference and discuss
> issues, find differences, and everyone reports that "origin" has x, but
> in fact "origin" means different servers to almost everyone. Also
> consider that only a small subset of the group really understands git,
> most just follow cook-book recipes to get their work done and don't
> understand what is going on.
Okay, I now understand your intention much better than before.
> This is my problem: "origin" is an abstraction that hides the different
> server names in use and makes communication difficult, having everyone
> use nicknames related to their particular upstream server reduces the
> confusion.
Unfortunately, I think this will just lead to even more confusion.
Because those people following recipes without thinking will now use a
name that does not even say the role, let alone the server.
IOW I think that your patch worsens the situation you describe.
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").
Ciao,
Dscho
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Morten Welinder @ 2008-01-11 14:18 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pierre Habouzit, Sam Vilain, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101332150.3054@xanadu.home>
> This is really the big point here. Git uses _lots_ of *small* objects,
> usually much smaller than 12KB. For example, my copy of the gcc
> repository has an average of 270 _bytes_ per compressed object, and
> objects must be individually compressed.
>
> Performance with really small objects should be the basis for any
> Git compression algorithm comparison.
If it so happens that one algorithm does much better on small objects
while another does better on large objects, there really is nothing that
prevents using both in a repository. It's a bit of code bloat, of course.
Morten
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Nicolas Pitre @ 2008-01-11 14:27 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Sam Vilain, Git Mailing List, Johannes Schindelin, Marco Costalba,
Junio C Hamano
In-Reply-To: <20080111094516.GD20141@artemis.madism.org>
On Fri, 11 Jan 2008, Pierre Habouzit wrote:
> Okay the numbers are still not that impressive, but my patch doesn't
> touches _only_ deltas, but also log comments I said, so I've redone my
> tests with git log and *TADAAAA*:
>
> vanilla git:
> repeat 5 time git log >|/dev/null
> git log >| /dev/null 2,54s user 0,12s system 99% cpu 2,660 total
> git log >| /dev/null 2,52s user 0,12s system 99% cpu 2,653 total
> git log >| /dev/null 2,57s user 0,07s system 99% cpu 2,637 total
> git log >| /dev/null 2,56s user 0,09s system 99% cpu 2,659 total
> git log >| /dev/null 2,54s user 0,10s system 99% cpu 2,660 total
>
> with the 512 octets limit:
>
> $ repeat 5 time git log >|/dev/null
> git log >| /dev/null 2,10s user 0,10s system 99% cpu 2,193 total
> git log >| /dev/null 2,08s user 0,10s system 99% cpu 2,189 total
> git log >| /dev/null 2,06s user 0,11s system 100% cpu 2,162 total
> git log >| /dev/null 2,04s user 0,13s system 100% cpu 2,172 total
> git log >| /dev/null 2,06s user 0,13s system 99% cpu 2,198 total
>
> That's already a 20% time reduction.
Well, sorry but that doesn't count to me. The whole 'git log' taking
around 2 seconds is already hell fast for what it does, and IMHO this is
not worth increasing the repository storage size for this particular
work load.
> with the 1024 octets limits:
> $ repeat 5 time git log >|/dev/null
> git log >| /dev/null 1,39s user 0,12s system 99% cpu 1,512 total
> git log >| /dev/null 1,38s user 0,12s system 100% cpu 1,498 total
> git log >| /dev/null 1,41s user 0,10s system 99% cpu 1,514 total
> git log >| /dev/null 1,41s user 0,10s system 100% cpu 1,506 total
> git log >| /dev/null 1,40s user 0,10s system 100% cpu 1,504 total
>
> Yes that's 43% time reduction !
If that was 43% reduction of a 10 second operation then sure I would
agree, like the blame operation typically is. But otherwise the
significant storage size increase is not worth the reduction of less
than a second in absolute time.
> As a side note, repacking with the 1024 octets limits takes 4:06 here,
> and 4:26 without the limit at all, which is 8% less time. I know it
> doesn't matters a lot as repack is a once time operation, but still, it
> would speed up git gc --auto which is not something to neglect
> completely.
No, I doubt it would. The bulk of 'git gc --auto' will reuse existing
pack data which is way different from 'git repack -f'.
> I say it's worth investigating a _lot_,
Well, I was initially entousiastic about this avenue, but the speed
performance difference is far from impressive IMHO, given the tradeoff.
Nicolas
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Mark Levedahl @ 2008-01-11 14:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.LSU.1.00.0801111348230.31053@racer.site>
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.
Mark
^ permalink raw reply
* Re: Allowing override of the default "origin" nickname
From: Johannes Schindelin @ 2008-01-11 15:03 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, git
In-Reply-To: <30e4a070801110653n61a826c0y33ed13f95cddf25d@mail.gmail.com>
Hi,
On Fri, 11 Jan 2008, Mark Levedahl wrote:
> 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.
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.
Ciao,
Dscho
^ permalink raw reply
* 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
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