* [PATCH][resend 2] git-svn: Use GIT_SSH setting if SVN_SSH is not set
From: Karthik R @ 2009-08-18 20:31 UTC (permalink / raw)
To: git
If SVN_SSH is defined, it will be used; else value in
GIT_SSH is copied to SVN_SSH & then, only on Windows,
the \s are escaped.
On Windows, the shell-variables must be set as follows
GIT_SSH="C:\Program Files\PuTTY\plink.exe"
SVN_SSH="C:\\Program Files\\PuTTY\\plink.exe"
See http://code.google.com/p/msysgit/issues/detail?id=305
---
Trying again following Dscho's comment (removed MSWin32) & using
logic from Junio (don't muck with user's SVN_SSH; else use GIT_SSH
to seed SVN_SSH & adjust the \s on Windows)
Previous life of patch:
[PATCH] GIT_SSH does not override ssh in git-svn
[PATCH][resend] git-svn: Respect GIT_SSH setting
git-svn.perl | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index b0bfb74..ef86d10 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -21,6 +21,15 @@ $Git::SVN::default_ref_id = $ENV{GIT_SVN_ID} ||
'git-svn';
$Git::SVN::Ra::_log_window_size = 100;
$Git::SVN::_minimize_url = 'unset';
+if (! exists $ENV{SVN_SSH}) {
+ if (exists $ENV{GIT_SSH}) {
+ $ENV{SVN_SSH} = $ENV{GIT_SSH};
+ if ($^O eq 'msys') {
+ $ENV{SVN_SSH} =~ s/\\/\\\\/g;
+ }
+ }
+}
+
$Git::SVN::Log::TZ = $ENV{TZ};
$ENV{TZ} = 'UTC';
$| = 1; # unbuffer STDOUT
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 20:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <7v7hx0c1at.fsf@alter.siamese.dyndns.org>
On Tue, 18 Aug 2009, Junio C Hamano wrote:
> Meh, our mails crossed. I'll chuck this one and use your
>
> [PATCH] make sure byte swapping is optimal for git
>
> patch. Do you want default_swab32 be mmoved inside the
>
> #if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
>
> block?
Not necessarily. It is generic code that other compilers/architectures
might use as well.
Nicolas
^ permalink raw reply
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-18 21:02 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git
In-Reply-To: <alpine.LFD.2.00.0908181537360.6044@xanadu.home>
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Jakub Narebski wrote:
>> Nicolas Pitre <nico@cam.org> writes:
>>> That won't buy you much. You should realize that a pack is made of:
>>>
>>> 1) Commit objects. Yes they're all put together at the front of the pack,
>>> but they roughly are the equivalent of:
>>>
>>> git log --pretty=raw | gzip | wc -c
>>>
>>> For the Linux repo as of now that is around 32 MB.
>>
>> For my clone of Git repository this gives 3.8 MB
>>
>>> 2) Tree and blob objects. Those are the bulk of the content for the top
>>> commit. [...] You can estimate the size of this data with:
>>>
>>> git archive --format=tar HEAD | gzip | wc -c
>>>
>>> On the same Linux repo this is currently 75 MB.
>>
>> On the same Git repository this gives 2.5 MB
>
> Interesting to see that the commit history is larger than the latest
> source tree. Probably that would be the same with the Linux kernel as
> well if all versions since the beginning with adequate commit logs were
> included in the repo.
Note that having reflog and/or patch management interface like StGit,
and frequently reworking commits (e.g. using rebase) means more commit
objects in repository.
Also Git repository has 3 independent branches: 'man', 'html' and 'todo',
from whose branches objects are not included in "git archive HEAD".
>
>>> 3) Delta objects. Those are making the rest of the pack, plus a couple
>>> tree/blob objects that were not found in the top commit and are
>>> different enough from any object in that top commit not to be
>>> represented as deltas. Still, the majority of objects for all the
>>> remaining commits are delta objects.
>>
>> You forgot that delta chains are bound by pack.depth limit, which
>> defaults to 50. You would have then additional full objects.
>
> Sure, but that's probably not significant. the delta chain depth is
> limited, but not the width. A given base object can have unlimited
> delta "children", and so on at each depth level.
You can probably get number and size taken by delta and non-delta (base)
objects in the packfile somehow. Neither "git verify-pack -v <packfile>"
nor contrib/stats/packinfo.pl did help me arrive at this data.
>> The single packfile for this (just gc'ed) Git repository is 37 MB.
>> Much more than 3.8 MB + 2.5 MB = 6.3 MB.
>
> What I'm saying is that most of that 37 MB - 6.3 MB = 31 MB is likely to
> be occupied by deltas.
True.
>> [cut]
>>
>> There is another way which we can go to implement resumable clone.
>> Let's git first try to clone whole repository (single pack; BTW what
>> happens if this pack is larger than file size limit for given
>> filesystem?).
>
> We currently fail. Seems that no one ever had a problem with that so
> far. We'd have to split the pack stream into multiple packs on the
> receiving end. But frankly, if you have a repository large enough to
> bust your filesystem's file size limit then maybe you should seriously
> reconsider your choice of development environment.
Do we fail gracefully (with an error message), or does git crash then?
If I remember correctly FAT28^W FAT32 has maximum file size of 2 GB.
FAT is often used on SSD, on USB drive. Although if you have 2 GB
packfile, you are doing something wrong, or UGFWIINI (Using Git For
What It Is Not Intended).
>> If it fails, client ask first for first half of of
>> repository (half as in bisect, but it is server that has to calculate
>> it). If it downloads, it will ask server for the rest of repository.
>> If it fails, it would reduce size in half again, and ask about 1/4 of
>> repository in packfile first.
>
> Problem people with slow links have won't be helped at all with this.
> What if the network connection gets broken only after 49% of the
> transfer and that took 3 hours to download? You'll attempt a 25% size
> transfer which would take 1.5 hour despite the fact that you already
> spent that much time downloading that first 1/4 of the repository
> already. And yet what if you're unlucky and now the network craps on
> you after 23% of that second attempt?
A modification then.
First try ordinary clone. If it fails because network is unreliable,
check how much we did download, and ask server for packfile of slightly
smaller size; this means that we are asking server for approximate pack
size limit, not for bisect-like partitioning revision list.
> I think it is better to "prime" the repository with the content of the
> top commit in the most straight forward manner using git-archive which
> has the potential to be fully restartable at any point with little
> complexity on the server side.
But didn't it make fully restartable 2.5 MB part out of 37 MB packfile?
A question about pack protocol negotiation. If clients presents some
objects as "have", server can and does assume that client has all
prerequisites for such objects, e.g. for tree objects that it has
all objects for files and directories inside tree; for commit it means
all ancestors and all objects in snapshot (have top tree, and its
prerequisites). Do I understand this correctly?
If we have partial packfile which crashed during downloading, can we
extract from it some full objects (including blobs)? Can we pass
tree and blob objects as "have" to server, and is it taken into account?
Perhaps instead of separate step of resumable-downloading of top commit
objects (in snapshot), we can pass to server what we did download in
full?
BTW. because of compression it might be more difficult to resume
archive creation in the middle, I think...
--
Jakub Narebski
Poland
^ permalink raw reply
* RE: interaction between --graph and --simplify-by-decoration
From: Adam Simpkins @ 2009-08-18 20:55 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
On Friday, July 31, 2009 4:11am, "Santi Béjar" <santi@agolina.net> said:
> Hello,
>
> I've found that in some cases the --graph and
> --simplify-by-decoration don't work well together. If you do this in
> the git.git repository:
Thanks for reporting the problem, I apologize for taking so long to
investigate and respond.
> * | | f29ac4f (tag: v1.6.3-rc2) GIT 1.6.3-rc2
> / /
> | | * 66996ec Sync with 1.6.2.4
> you can see that f29ac4f looks like it does not have any parents while
> the correct parent is 66996ec which seems to have no children. But if
> you omit the --oneline you can see that there are a lot of "root"-like
> commits (f01f109, a48f5d7, f29ac4f,...).
Yes, there's a bug in graph_is_interesting(). When processing
f29ac4f, the graph code thinks that 66996ec isn't interesting and
won't get displayed in the output, so it doesn't prepare the graph
lines to show lines to 66996ec.
I'll submit a patch shortly.
--
Adam Simpkins
adam@adamsimpkins.net
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-18 21:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git
In-Reply-To: <200908182302.10619.jnareb@gmail.com>
On Tue, 18 Aug 2009, Jakub Narebski wrote:
> You can probably get number and size taken by delta and non-delta (base)
> objects in the packfile somehow. Neither "git verify-pack -v <packfile>"
> nor contrib/stats/packinfo.pl did help me arrive at this data.
Documentation for verify-pack says:
|When specifying the -v option the format used is:
|
| SHA1 type size size-in-pack-file offset-in-packfile
|
|for objects that are not deltified in the pack, and
|
| SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
|
|for objects that are deltified.
So a simple script should be able to give you the answer.
> >> (BTW what happens if this pack is larger than file size limit for
> >> given filesystem?).
> >
> > We currently fail. Seems that no one ever had a problem with that so
> > far. We'd have to split the pack stream into multiple packs on the
> > receiving end. But frankly, if you have a repository large enough to
> > bust your filesystem's file size limit then maybe you should seriously
> > reconsider your choice of development environment.
>
> Do we fail gracefully (with an error message), or does git crash then?
If the filesystem is imposing the limit, it will likely return an error
on the write() call and we'll die(). If the machine has a too small
off_t for the received pack then we also die("pack too large for current
definition of off_t").
> If I remember correctly FAT28^W FAT32 has maximum file size of 2 GB.
> FAT is often used on SSD, on USB drive. Although if you have 2 GB
> packfile, you are doing something wrong, or UGFWIINI (Using Git For
> What It Is Not Intended).
Hopefully you're not performing a 'git clone' off of a FAT filesystem.
For physical transport you may repack with the appropriate switches.
> >> If it fails, client ask first for first half of of
> >> repository (half as in bisect, but it is server that has to calculate
> >> it). If it downloads, it will ask server for the rest of repository.
> >> If it fails, it would reduce size in half again, and ask about 1/4 of
> >> repository in packfile first.
> >
> > Problem people with slow links have won't be helped at all with this.
> > What if the network connection gets broken only after 49% of the
> > transfer and that took 3 hours to download? You'll attempt a 25% size
> > transfer which would take 1.5 hour despite the fact that you already
> > spent that much time downloading that first 1/4 of the repository
> > already. And yet what if you're unlucky and now the network craps on
> > you after 23% of that second attempt?
>
> A modification then.
>
> First try ordinary clone. If it fails because network is unreliable,
> check how much we did download, and ask server for packfile of slightly
> smaller size; this means that we are asking server for approximate pack
> size limit, not for bisect-like partitioning revision list.
If the download didn't reach past the critical point (75 MB in my linux
repo example) then you cannot validate the received data and you've
wasted that much bandwidth.
> > I think it is better to "prime" the repository with the content of the
> > top commit in the most straight forward manner using git-archive which
> > has the potential to be fully restartable at any point with little
> > complexity on the server side.
>
> But didn't it make fully restartable 2.5 MB part out of 37 MB packfile?
The front of the pack is the critical point. If you get enough to
create the top commit then further transfers can be done incrementally
with only the deltas between each commits.
> A question about pack protocol negotiation. If clients presents some
> objects as "have", server can and does assume that client has all
> prerequisites for such objects, e.g. for tree objects that it has
> all objects for files and directories inside tree; for commit it means
> all ancestors and all objects in snapshot (have top tree, and its
> prerequisites). Do I understand this correctly?
That works only for commits.
> If we have partial packfile which crashed during downloading, can we
> extract from it some full objects (including blobs)? Can we pass
> tree and blob objects as "have" to server, and is it taken into account?
No.
> Perhaps instead of separate step of resumable-downloading of top commit
> objects (in snapshot), we can pass to server what we did download in
> full?
See above.
> BTW. because of compression it might be more difficult to resume
> archive creation in the middle, I think...
Why so? the tar+gzip format is streamable.
Nicolas
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-18 21:35 UTC (permalink / raw)
To: Pau Garcia i Quiles
Cc: Marius Storm-Olsen, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <3af572ac0908181007q7622091eqc78861e00c3a9e45@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1081 bytes --]
Hi,
On Tue, 18 Aug 2009, Pau Garcia i Quiles wrote:
> On Tue, Aug 18, 2009 at 4:11 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>
> > On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> >
> >> So, instead of rely on these vcproj files which *will* go stale, we
> >> can simply use the same Makefile system which everyone else is
> >> using. :) After all, we're just compiling with a different compiler.
> >> The end result will still rely on the *msysGit environment* to
> >> function, so we already require it. Thus, GNU Make is present, and
> >> we can use it.
> >
> > We can also use sed or perl to generate/modify the .vcproj files, or
> > run CMake (once Pau got it to build), and package the stuff using zip
> > (once I got that to build).
>
> Re: package the stuff using ZIP, it's trivial to do with CPack (part of
> the CMake chain). Just tell me what you want to get and I'll implement
> it.
Well, I tried to tell you already what I want. A simple and unsupervised
script that downloads, compiles, installs and commits CMake.
Ciao,
Dscho
^ permalink raw reply
* Re: Null deref in recursive merge in df73af5f667a479764d2b2195cb0cb60b0b89e3d
From: Fredrik Kuivinen @ 2009-08-18 21:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin <johannes.schindelin@gmx.de> Alex Riesen,
Git, Josh ben Jore
In-Reply-To: <7viqhaipg0.fsf@alter.siamese.dyndns.org>
On Thu, Jul 30, 2009 at 9:45 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> The codepath saw that one branch renamed dev-ubuntu/ stuff to dev/ at that
>> "unmerged" path, while the other branch added something else to the same
>> path, and decided to add that at an alternative path, and the intent of
>> that is so that it can safely resolve the "renamed" side to its final
>> destination. The added update_file() call is about finishing that
>> conflict resolution the code forgets to do.
>
> By the way, (I am CC'ing Fredrik, the author of the merge-recursive.py,
> the original implementation, even though I haven't seen him around here
> for a long time. Two "thieves" are also CC'ed), I think the way recursive
> strategy tries to handle rename/add and rename/rename conflicts by coming
> up with a temporary pathname is fundamentally wrong.
It was a long time ago I looked at the merge stuff (or any git code in
fact) so I
may have forgotten some things. However, as far as I can see your analysis is
correct and the temporary pathname stuff can be avoided when the conflicts
only involve files (and no directories). As you wrote, for D/F
conflicts one need
the temporary pathnames in order to build a tree which is used in the virtual
ancestor.
[Nice analysis of when temporary pathnames are needed and when they are not
needed snipped.]
- Fredrik
PS. I am sorry for the late reply.
^ permalink raw reply
* Re: x86 SHA1: Faster than OpenSSL
From: Andy Polyakov @ 2009-08-18 21:26 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20090803034741.23415.qmail@science.horizon.com>
George Spelvin wrote:
> (Work in progress, state dump to mailing list archives.)
>
> This started when discussing git startup overhead due to the dynamic
> linker. One big contributor is the openssl library, which is used only
> for its optimized x86 SHA-1 implementation. So I took a look at it,
> with an eye to importing the code directly into the git source tree,
> and decided that I felt like trying to do better.
>
> The original code was excellent, but it was optimized when the P4 was new.
Even though last revision took place when "the P4 was new" and even
triggered by its appearance, *all-round* performance was and will always
be the prime goal. This means that improvements on some particular
micro-architecture is always weighed against losses on others [and
compromise is considered of so required]. Please note that I'm *not*
trying to diminish George's effort by saying that proposed code is
inappropriate, on the contrary I'm nothing but grateful! Thanks, George!
I'm only saying that it will be given thorough consideration. Well, I've
actually given the consideration and outcome is already committed:-) See
http://cvs.openssl.org/chngview?cn=18513. I don't deliver +17%, only
+12%, but at the cost of Intel Atom-specific optimizations. I used this
opportunity to optimize even for Intel Atom core, something I was
planning to do at some point anyway...
> http://www.openssl.org/~appro/cryptogams/cryptogams-0.tar.gz
> - "tar xz cryptogams-0.tar.gz"
If there is interest I can pack new tar ball with updated modules.
> An open question is how to add appropriate CPU detection to the git
> build scripts. (Note that `uname -m`, which it currently uses to select
> the ARM code, does NOT produce the right answer if you're using a 32-bit
> compiler on a 64-bit platform.)
It's not only that. As next subscriber noted problem on MacOS X, it
[MacOS X] uses slightly different assembler convention and ELF modules
can't be compiled on MacOS X. OpenSSL perlasm takes care of several
assembler flavors and executable formats, including MacOS X. I'm talking
about
> +++ Makefile 2009-08-02 06:44:44.000000000 -0400
> +%.s : %.pl x86asm.pl x86unix.pl
> + perl $< elf > $@
^^^ this argument.
Cheers. A.
^ permalink raw reply
* [PATCH 1/3] stash: accept -k as a shortcut for --keep-index
From: Matthieu Moy @ 2009-08-18 21:38 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1250631523-10524-1-git-send-email-Matthieu.Moy@imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-stash.txt | 4 ++--
git-stash.sh | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 4b15459..1b5392a 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -13,7 +13,7 @@ SYNOPSIS
'git stash' drop [-q|--quiet] [<stash>]
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
'git stash' branch <branchname> [<stash>]
-'git stash' [save [--patch] [--[no-]keep-index] [-q|--quiet] [<message>]]
+'git stash' [save [--patch] [--[no-]keep-index|-k] [-q|--quiet] [<message>]]
'git stash' clear
'git stash' create
@@ -42,7 +42,7 @@ is also possible).
OPTIONS
-------
-save [--patch] [--[no-]keep-index] [-q|--quiet] [<message>]::
+save [--patch] [--[no-]keep-index|-k] [-q|--quiet] [<message>]::
Save your local modifications to a new 'stash', and run `git reset
--hard` to revert them. This is the default action when no
diff --git a/git-stash.sh b/git-stash.sh
index 567aa5d..856a2d5 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -7,7 +7,7 @@ USAGE="list [<options>]
or: $dashless drop [-q|--quiet] [<stash>]
or: $dashless ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: $dashless branch <branchname> [<stash>]
- or: $dashless [save [--keep-index] [-q|--quiet] [<message>]]
+ or: $dashless [save [-k|--keep-index] [-q|--quiet] [<message>]]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -132,7 +132,7 @@ save_stash () {
while test $# != 0
do
case "$1" in
- --keep-index)
+ -k|--keep-index)
keep_index=t
;;
--no-keep-index)
--
1.6.4.rc2.31.g2d7d7
^ permalink raw reply related
* [PATCH 2/3] stash: accept options also when subcommand 'save' is omitted
From: Matthieu Moy @ 2009-08-18 21:38 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1250631523-10524-2-git-send-email-Matthieu.Moy@imag.fr>
This allows in particular 'git stash -k which is shorter than
'git stash save -k', and not ambiguous.
Testcase taken from Johannes Schindelin <johannes.schindelin@gmx.de>.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-stash.txt | 2 +-
git-stash.sh | 8 +++++++-
t/t3903-stash.sh | 8 ++++++++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 1b5392a..7e515ce 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -13,7 +13,7 @@ SYNOPSIS
'git stash' drop [-q|--quiet] [<stash>]
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
'git stash' branch <branchname> [<stash>]
-'git stash' [save [--patch] [--[no-]keep-index|-k] [-q|--quiet] [<message>]]
+'git stash' [save] [--patch] [--[no-]keep-index|-k] [-q|--quiet] [<message>]
'git stash' clear
'git stash' create
diff --git a/git-stash.sh b/git-stash.sh
index 856a2d5..bb36bc7 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -7,7 +7,7 @@ USAGE="list [<options>]
or: $dashless drop [-q|--quiet] [<stash>]
or: $dashless ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: $dashless branch <branchname> [<stash>]
- or: $dashless [save [-k|--keep-index] [-q|--quiet] [<message>]]
+ or: $dashless [save] [-k|--keep-index] [-q|--quiet] [<message>]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -354,6 +354,12 @@ apply_to_branch () {
drop_stash $stash
}
+case "$1" in
+ -*)
+ set "save" "$@"
+ ;;
+esac
+
# Main command set
case "$1" in
list)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 7a3fb67..0e831e0 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -200,4 +200,12 @@ test_expect_success 'drop -q is quiet' '
test ! -s output.out
'
+test_expect_success 'stash -k' '
+ echo bar3 > file &&
+ echo bar4 > file2 &&
+ git add file2 &&
+ git stash -k &&
+ test bar,bar4 = $(cat file),$(cat file2)
+'
+
test_done
--
1.6.4.rc2.31.g2d7d7
^ permalink raw reply related
* [PATCH] graph API: use a new color when starting a brand new column
From: Adam Simpkins @ 2009-08-18 21:41 UTC (permalink / raw)
To: git; +Cc: Allan Caffee, Junio C Hamano
Use a new color for commits that don't have any previously printed
children. The following command demonstrates the changes:
git log --graph --pretty=tformat:'%h %s%n' -7 481c7a6 18b0793
Now the two independent lines of development are displayed with
different colors, instead of both using the same color.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
---
graph.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/graph.c b/graph.c
index e466770..f3226ec 100644
--- a/graph.c
+++ b/graph.c
@@ -225,7 +225,12 @@ struct git_graph *graph_init(struct rev_info *opt)
graph->num_columns = 0;
graph->num_new_columns = 0;
graph->mapping_size = 0;
- graph->default_column_color = 0;
+ /*
+ * Start the column color at the maximum value, since we'll
+ * always increment it for the first commit we output.
+ * This way we start at 0 for the first commit.
+ */
+ graph->default_column_color = COLUMN_COLORS_MAX - 1;
/*
* Allocate a reasonably large default number of columns
@@ -499,11 +504,14 @@ static void graph_update_columns(struct git_graph *graph)
parent;
parent = next_interesting_parent(graph, parent)) {
/*
- * If this is a merge increment the current
+ * If this is a merge, or the start of a new
+ * childless column, increment the current
* color.
*/
- if (graph->num_parents > 1)
+ if (graph->num_parents > 1 ||
+ !is_commit_in_columns) {
graph_increment_column_color(graph);
+ }
graph_insert_into_new_columns(graph,
parent->item,
&mapping_idx);
--
1.6.4.314.g5667f
^ permalink raw reply related
* [PATCH 0/3] short syntaxes for 'git stash'
From: Matthieu Moy @ 2009-08-18 21:38 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <7vbpmcc1sc.fsf@alter.siamese.dyndns.org>
This small patch serie is based on the following commit in pu:
dda1f2a Implement 'git stash save --patch'
It is meant to replace two commits already there:
ea41cfc Make 'git stash -k' a short form for 'git stash save --keep-index'
f300fab DWIM 'git stash save -p' for 'git stash -p'
The first (git stash -k) has the drawback of forcing one to use one
and only one option when the 'save' command is ommited. My approach is
mostly based on the simple hack:
+case "$1" in
+ -*)
+ set "save" "$@"
+ ;;
+esac
+
and accepts an arbitrary number of options.
The second (DWIM git stash save -p) becomes unnecessary afterwards.
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Johannes Schindelin @ 2009-08-18 21:42 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20090818174509.GA27518@coredump.intra.peff.net>
Hi,
On Tue, 18 Aug 2009, Jeff King wrote:
> On Tue, Aug 18, 2009 at 03:01:52PM +0200, Matthieu Moy wrote:
>
> > Hmm, googling a bit, I just noticed that there's already something in
> > pu:
> > ea41cfc4f (Make 'git stash -k' a short form for 'git stash save --keep-index')
> > which also does the trick, while adding a -k alias for --keep-index.
> >
> > [...]
> >
> > Mine has at least two advantages:
> >
> > * It won't require changing the code again when new options are added
> > to 'git stash save'.
> >
> > * It works with 'git stash -k -q' for example, while the other
> > proposal checks that $# == 1, which won't work if there are more
> > than one option.
>
> I think yours is nicer, especially as we have just added the
> '-p|--patch' option, as well. With what is there now, you can do "git
> stash -p", but not "git stash -p -k".
But it is sloppy, in that it blindly accepts options that might be valid
for several subcommands, not just "save".
That was the reason I did not implement it this way.
But we do not have such ambiguous options yet.
Or do we? Look at what "list" accepts!
So please register my objection.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 3/3] stash: reject stash name starting with a dash.
From: Matthieu Moy @ 2009-08-18 21:38 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1250631523-10524-3-git-send-email-Matthieu.Moy@imag.fr>
This avoids typos like 'git stash save --invalid-option', particularly
nasty since one can omit the 'save' subcommand. The syntax
'git stash save -- "-name starting with dash" still allows such stash name.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Jeff King <peff@peff.net> writes:
>> But I may have missed its drawbacks ;-)
>
> The only I can think of is that bogus input will provoke 'save'. So
> something like:
>
> git stash --apply
>
> will invoke "git stash save --apply", which doesn't even complain. It
> just tries to make a stash with message --apply. Now of course this
> input is obviously bogus, but probably the right thing to do is
> complain.
>
> OTOH, I think it is the fault of "git stash save --apply" for not doing
> the complaining, so your patch really isn't making it worse. Probably it
> should barf on anything unrecognized starting with a '-', and allow '--'
> to separate the message from the rest of the options (in the rare case
> that you want a message starting with '-').
>
> -Peff
So, here it is!
Documentation/git-stash.txt | 2 +-
git-stash.sh | 10 +++++++++-
t/t3903-stash.sh | 10 ++++++++++
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 7e515ce..ded62e0 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -13,7 +13,7 @@ SYNOPSIS
'git stash' drop [-q|--quiet] [<stash>]
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
'git stash' branch <branchname> [<stash>]
-'git stash' [save] [--patch] [--[no-]keep-index|-k] [-q|--quiet] [<message>]
+'git stash' [save] [--patch] [--[no-]keep-index|-k] [-q|--quiet] [--] [<message>]
'git stash' clear
'git stash' create
diff --git a/git-stash.sh b/git-stash.sh
index bb36bc7..642e265 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -7,7 +7,7 @@ USAGE="list [<options>]
or: $dashless drop [-q|--quiet] [<stash>]
or: $dashless ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: $dashless branch <branchname> [<stash>]
- or: $dashless [save] [-k|--keep-index] [-q|--quiet] [<message>]
+ or: $dashless [save] [-k|--keep-index] [-q|--quiet] [--] [<message>]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -145,6 +145,14 @@ save_stash () {
-q|--quiet)
GIT_QUIET=t
;;
+ --)
+ shift
+ break
+ ;;
+ -*)
+ echo "error: unknown option for 'stash save': $1"
+ usage
+ ;;
*)
break
;;
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 0e831e0..87e5a14 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -208,4 +208,14 @@ test_expect_success 'stash -k' '
test bar,bar4 = $(cat file),$(cat file2)
'
+test_expect_success 'stash --invalid-option' '
+ echo bar5 > file &&
+ echo bar6 > file2 &&
+ git add file2 &&
+ ! git stash --invalid-option &&
+ test bar5,bar6 = $(cat file),$(cat file2) &&
+ git stash -- -message-starting-with-dash &&
+ test bar,bar2 = $(cat file),$(cat file2)
+'
+
test_done
--
1.6.4.rc2.31.g2d7d7
^ permalink raw reply related
* Re: x86 SHA1: Faster than OpenSSL
From: Andy Polyakov @ 2009-08-18 21:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: George Spelvin, git
In-Reply-To: <alpine.LFD.2.01.0908031938280.3270@localhost.localdomain>
> On Mon, 3 Aug 2009, Linus Torvalds wrote:
>> The thing that I'd prefer is simply
>>
>> git fsck --full
>>
>> on the Linux kernel archive. For me (with a fast machine), it takes about
>> 4m30s with the OpenSSL SHA1, and takes 6m40s with the Mozilla SHA1 (ie
>> using a NO_OPENSSL=1 build).
>>
>> So that's an example of a load that is actually very sensitive to SHA1
>> performance (more so than _most_ git loads, I suspect), and at the same
>> time is a real git load rather than some SHA1-only microbenchmark.
I couldn't agree more that real-life benchmarks are of greater value
than specific algorithm micro-benchmark. And given the provided
profiling data one can argue that +17% (or my +12%) improvement on
micro-benchmark aren't really worth bothering about. But it's kind of
sport [at least for me], so don't judge too harshly:-)
>> It also
>> shows very clearly why we default to the OpenSSL version over the Mozilla
>> one.
As George implicitly mentioned most OpenSSL assembler modules are
available under more permissive license and if there is interest I'm
ready to assist...
> "perf report --sort comm,dso,symbol" profiling shows the following for
> 'git fsck --full' on the kernel repo, using the Mozilla SHA1:
>
> 47.69% git /home/torvalds/git/git [.] moz_SHA1_Update
> 22.98% git /lib64/libz.so.1.2.3 [.] inflate_fast
> 7.32% git /lib64/libc-2.10.1.so [.] __GI_memcpy
> 4.66% git /lib64/libz.so.1.2.3 [.] inflate
> 3.76% git /lib64/libz.so.1.2.3 [.] adler32
> 2.86% git /lib64/libz.so.1.2.3 [.] inflate_table
> 2.41% git /home/torvalds/git/git [.] lookup_object
> 1.31% git /lib64/libc-2.10.1.so [.] _int_malloc
> 0.84% git /home/torvalds/git/git [.] patch_delta
> 0.78% git [kernel] [k] hpet_next_event
>
> so yeah, SHA1 performance matters. Judging by the OpenSSL numbers, the
> OpenSSL SHA1 implementation must be about twice as fast as the C version
> we use.
And given /lib64 path this is 64-bit C compiler-generated code compared
to 32-bit assembler? Either way in this context I have extra comment
addressing previous subscriber, Mark Lodato, who effectively wondered
how would 64-bit assembler compare to 32-bit one. First of all there
*is* even 64-bit assembler version. But as SHA1 is essentially 32-bit
algorithm, 64-bit implementation is only nominally faster, +20% at most.
Faster thanks to larger register bank facilitating more efficient
instruction scheduling.
Cheers. A.
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Matthieu Moy @ 2009-08-18 21:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0908182337200.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But it is sloppy, in that it blindly accepts options that might be valid
> for several subcommands, not just "save".
I wouldn't call that sloppy. 'save' is the default command, if you
don't provide any command, then 'save' will be used.
So, "git stash -p" means "git stash save -p" regardless of the fact
that there exists somewhere else a "git stash list -p". Actually, in
the current form of pu, it is already the case since
f300fab (Thomas Rast, DWIM 'git stash save -p' for 'git stash -p')
which came right after your patch.
> So please register my objection.
I will if you register my objection to yours ;-).
Jokes aside, if you insist in rejecting 'git stash -p', then my patch
can be slightly modified to say something like
+case "$1" in
+ -k|--keep-index|--patch)
+ set "save" "$@"
+ ;;
+esac
instead, which also allows multiple arguments (unlike your initial
proposal), and can control more precisely the list of options for
which 'save' is a default.
--
Matthieu
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-18 21:53 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johan 't Hart, Junio C Hamano, msysgit, git, lznuaa, bonzini,
kusmabite
In-Reply-To: <4A8AED8B.9080604@gmail.com>
Hi,
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> Johan 't Hart said the following on 18.08.2009 19:41:
> > Junio C Hamano schreef:
> > > Since use of make implies use of shell, this makes me wonder if it
> > > would make sense to go one step further by giving msvc users a thin
> > > shell wrapper mcvc-cc that turns bog-standard cc command line into
> > > whatever cl uses.
> >
> > Just using the msvc toolchain for building git misses the whole
> > purpose of what VC is used for. MSVC would be used because of the
> > IDE, not for the compiler IMO.
>
> Bull. MSVC produces superior code on Windows compared to MinGW, I'm afraid.
> Add the /LTGC (Link Time Code Generation), and MSVC generates very good cross
> compile-unit optimized code. (I know gcc has the option, but it's not as good,
> by far)
> Coupled now with built-in static code analysis, these are only two reasons why
> *I* would want to build it directly from the command line without worrying
> that my .vcproj is out-of-sync with the main development.
> You can still debug with the MSVC debugger if you'd like, and the MSVC IDE
> allows you to wrap Makefile project too, so you can *still* use the IDE..
Well, "you can *still* use the IDE" is a bit exaggerated, no? At least
unless you misunderstand "IDE" to mean "Integrated Debugging environment".
You'll lose not only the ability to follow definitions/declarations in the
code, you'll also lose the ability to compile incrementally _while_
debuggin, and Visual Studio's feature to move to the next/previous compile
error.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-18 21:57 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Marius Storm-Olsen, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <alpine.LNX.2.00.0908181420330.7195@iabervon.org>
Hi,
On Tue, 18 Aug 2009, Daniel Barkalow wrote:
> On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
>
> > Johannes Schindelin said the following on 18.08.2009 16:11:
> > > On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> > > > So, instead of rely on these vcproj files which *will* go stale,
> > > > we can simply use the same Makefile system which everyone else is
> > > > using. :) After all, we're just compiling with a different
> > > > compiler. The end result will still rely on the *msysGit
> > > > environment* to function, so we already require it. Thus, GNU Make
> > > > is present, and we can use it.
> > >
> > > We can also use sed or perl to generate/modify the .vcproj files, or
> > > run CMake (once Pau got it to build), and package the stuff using
> > > zip (once I got that to build).
> >
> > Really? That would be some script being able to parse the Makefile,
> > and create something reasonable as a vcproj script :) Keeping all the
> > options in sync, conditional files/libs, all the various end
> > executables (a separate .vcproj for each of them, and a solution file
> > (.sln)to tie them all together into a .. "solution", a complete
> > product blah blah blah) etc.
>
> I think it wouldn't be impossible to split the Makefile into an
> easy-to-parse part and an irrelevant-to-vcproj part.
What? That is pretty fragile.
It would be _much_ better to just add another Makefile target that outputs
the files needed for the targets.
We do not need to keep the Makefile as-is! If the change is not
intrusive, I am sure our friendly maintainer will not see a problem
either.
No need for fragile parsing at all.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Erik Faye-Lund @ 2009-08-18 22:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marius Storm-Olsen, Johan 't Hart, Junio C Hamano, msysgit,
git, lznuaa, bonzini
In-Reply-To: <alpine.DEB.1.00.0908182349220.8306@pacific.mpi-cbg.de>
On Tue, Aug 18, 2009 at 11:53 PM, Johannes
Schindelin<Johannes.Schindelin@gmx.de> wrote:
> debuggin, and Visual Studio's feature to move to the next/previous compile
> error.
Nope, you're still able to skip through the erros (with F4) as ususal.
I've been using a sed-script to translate gcc-style errors to
msvc-style errors for makefile projects before with great success. In
this case, the errors are already in msvc-style, so that part should
really not be any issue.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Continue git clone after interruption
From: Johannes Schindelin @ 2009-08-18 22:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Tomasz Kontusz, git
In-Reply-To: <alpine.LFD.2.00.0908181537360.6044@xanadu.home>
Hi,
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Jakub Narebski wrote:
>
> > There is another way which we can go to implement resumable clone.
> > Let's git first try to clone whole repository (single pack; BTW what
> > happens if this pack is larger than file size limit for given
> > filesystem?).
>
> We currently fail. Seems that no one ever had a problem with that so
> far.
They just went away, most probably.
But seriously, I miss a very important idea in this discussion: we control
the Git source code. So we _can_ add a upload_pack feature that a client
can ask for after the first failed attempt.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Jeff King @ 2009-08-18 22:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, git
In-Reply-To: <alpine.DEB.1.00.0908182337200.8306@pacific.mpi-cbg.de>
On Tue, Aug 18, 2009 at 11:42:58PM +0200, Johannes Schindelin wrote:
> > I think yours is nicer, especially as we have just added the
> > '-p|--patch' option, as well. With what is there now, you can do "git
> > stash -p", but not "git stash -p -k".
>
> But it is sloppy, in that it blindly accepts options that might be valid
> for several subcommands, not just "save".
>
> That was the reason I did not implement it this way.
>
> But we do not have such ambiguous options yet.
>
> Or do we? Look at what "list" accepts!
>
> So please register my objection.
I don't see the problem. Either the option works for "stash save" or it
does not. If I say "git stash --quiet", then it _must_ be "git stash
save --quiet", and not "git stash pop --quiet", because "save" is the
only default command. If I say "git stash --foobar", it is translated
to "git stash save --foobar", which should generate an error (it doesn't
right now, but that is a separate issue). I don't see any confusion:
"save" is always the default command, unless one is given as the first
argument.
The place where I would see a potential problem is if stash grew any
"global" options (e.g., in the same way that "git" can take options
before its subcommand name).
-Peff
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Johannes Schindelin @ 2009-08-18 22:37 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, git
In-Reply-To: <vpqtz0423jk.fsf@bauges.imag.fr>
Hi,
On Tue, 18 Aug 2009, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > But it is sloppy, in that it blindly accepts options that might be
> > valid for several subcommands, not just "save".
>
> I wouldn't call that sloppy. 'save' is the default command, if you don't
> provide any command, then 'save' will be used.
'save' might be the default command, but we don't trigger it with _any_
crap, for a very good reason. Read the commit log for git-stash.sh to
know why.
> > So please register my objection.
>
> I will if you register my objection to yours ;-).
>
> Jokes aside,
If you think that's funny, I don't. I actually put a lot of thought into
the issue whether to allow _any_ parameter with looks like an option to
trigger "save". And I very much had to come to the decision that no, that
is too dangerous.
So I cannot take your objection seriously.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Johannes Schindelin @ 2009-08-18 22:38 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Marius Storm-Olsen, Johan 't Hart, Junio C Hamano, msysgit,
git, lznuaa, bonzini
In-Reply-To: <40aa078e0908181502v32cbd223xcde1cd363dc76345@mail.gmail.com>
Hi,
On Wed, 19 Aug 2009, Erik Faye-Lund wrote:
> On Tue, Aug 18, 2009 at 11:53 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > debuggin, and Visual Studio's feature to move to the next/previous
> > compile error.
>
> Nope, you're still able to skip through the erros (with F4) as ususal.
> I've been using a sed-script to translate gcc-style errors to msvc-style
> errors for makefile projects before with great success. In this case,
> the errors are already in msvc-style, so that part should really not be
> any issue.
At this point you are just piling work-around on work-around.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] graph API: fix bug in graph_is_interesting()
From: Adam Simpkins @ 2009-08-18 21:18 UTC (permalink / raw)
To: Git Mailing List; +Cc: Santi Béjar, Junio C Hamano
In-Reply-To: <1250628954.114121983@192.168.1.201>
Updated graph_is_interesting() to use simplify_commit() to determine if
a commit is interesting, just like get_revision() does. Previously, it
would sometimes incorrectly treat an interesting commit as
uninteresting. This resulted in incorrect lines in the graph output.
This problem was reported by Santi Béjar. The following command
would exhibit the problem before, but now works correctly:
git log --graph --simplify-by-decoration --oneline v1.6.3.3
Previously git graph did not display the output for this command
correctly between f29ac4f and 66996ec, among other places.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
---
Note that simplify_commit() may modify the revision list. Calling it
in graph_is_interesting() can modify the revision list earlier than it
otherwise would be (in get_revision()). I don't think this should
cause any problems, but figured I'd point it out in case anyone more
familiar with the code thinks otherwise.
graph.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/graph.c b/graph.c
index e466770..ea21e91 100644
--- a/graph.c
+++ b/graph.c
@@ -286,9 +286,10 @@ static int graph_is_interesting(struct git_graph *graph, struct commit *commit)
}
/*
- * Uninteresting and pruned commits won't be printed
+ * Otherwise, use simplify_commit() to see if this commit is
+ * interesting
*/
- return (commit->object.flags & (UNINTERESTING | TREESAME)) ? 0 : 1;
+ return simplify_commit(graph->revs, commit) == commit_show;
}
static struct commit_list *next_interesting_parent(struct git_graph *graph,
--
1.6.4.314.ge5db
^ permalink raw reply related
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Johannes Schindelin @ 2009-08-18 22:46 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20090818223028.GB31176@coredump.intra.peff.net>
Hi,
On Tue, 18 Aug 2009, Jeff King wrote:
> On Tue, Aug 18, 2009 at 11:42:58PM +0200, Johannes Schindelin wrote:
>
> > > I think yours is nicer, especially as we have just added the
> > > '-p|--patch' option, as well. With what is there now, you can do
> > > "git stash -p", but not "git stash -p -k".
> >
> > But it is sloppy, in that it blindly accepts options that might be
> > valid for several subcommands, not just "save".
> >
> > That was the reason I did not implement it this way.
> >
> > But we do not have such ambiguous options yet.
> >
> > Or do we? Look at what "list" accepts!
> >
> > So please register my objection.
>
> I don't see the problem. Either the option works for "stash save" or it
> does not. If I say "git stash --quiet", then it _must_ be "git stash
> save --quiet", and not "git stash pop --quiet", because "save" is the
> only default command.
So if I say "git stash -q" by mistake, but wanted to say "git stash drop
-q", then I am borked?
Bah! I say: bah!
You're basically reintroducing at least part of the DWIMery that was
reverted in 9488e875 and I have the distinct feeling that some people in
this thread do not think hard enough about what would adher to the
principle of least surprise even in the future (or even for people
introducing other stash save options).
Well, you just go ahead and push through your patch, and I do what I
promised on my blog.
^ 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