* [PATCH 1/4] test-suite: adding a test for fast-export with tag variants
From: Erik Faye-Lund @ 2009-03-23 12:53 UTC (permalink / raw)
To: git; +Cc: gitster, Erik Faye-Lund
The first two new tests are crashing, so I'm adding them commented out as they
exit with unpredictable return-codes.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
t/t9301-fast-export.sh | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index 86c3760..db4b0b3 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -28,7 +28,12 @@ test_expect_success 'setup' '
git commit -m sitzt file2 &&
test_tick &&
git tag -a -m valentin muss &&
- git merge -s ours master
+ git merge -s ours master &&
+ HEAD_TREE=`git show -s --pretty=raw HEAD | grep tree | sed "s/tree //"` &&
+ git tag tree_tag -m "tagging a tree" $HEAD_TREE &&
+ git tag -a tree_tag-obj -m "tagging a tree" $HEAD_TREE &&
+ git tag tag-obj_tag -m "tagging a tag" tree_tag-obj &&
+ git tag -a tag-obj_tag-obj -m "tagging a tag" tree_tag-obj
'
@@ -259,4 +264,11 @@ test_expect_success 'cope with tagger-less tags' '
'
+# NEEDSWORK: not just check return status, but validate the output
+# two tests commented out due to crash and thus unreliable return code
+#test_expect_success 'tree_tag' 'git fast-export tree_tag'
+#test_expect_success 'tree_tag-obj' 'git fast-export tree_tag-obj'
+test_expect_failure 'tag-obj_tag' 'git fast-export tag-obj_tag'
+test_expect_failure 'tag-obj_tag-obj' 'git fast-export tag-obj_tag-obj'
+
test_done
--
1.6.2.1.225.g9a4a0.dirty
^ permalink raw reply related
* Re: .gitk should created hidden in windows
From: Steve Wagner @ 2009-03-23 12:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18887.26239.115820.450313@cargo.ozlabs.ibm.com>
Seems to work here. Thanks for fixing it!
Steve
Paul Mackerras schrieb:
> Steve Wagner writes:
>
>> The problem is that windows dose not hides files beginning with a dot as
>> it is in unix. So the .gitk file is created as visible in the windows
>> user profile. Problematic too is that i can no set the hidden attribute
>> to this file, because it is recreated every time i start gitk, so the
>> hidden attribute gets lost.
>>
>> Can you control this and create the file with the hidden attribute on
>> windows?
>
> Please try this patch and let me know if it does what you want.
>
> Paul.
>
> diff --git a/gitk b/gitk
> index d7de27e..54f3f2b 100755
> --- a/gitk
> +++ b/gitk
> @@ -2487,6 +2487,9 @@ proc savestuff {w} {
> if {![winfo viewable .]} return
> catch {
> set f [open "~/.gitk-new" w]
> + if {$::tcl_platform(platform) eq {windows}} {
> + file attributes "~/.gitk-new" -hidden true
> + }
> puts $f [list set mainfont $mainfont]
> puts $f [list set textfont $textfont]
> puts $f [list set uifont $uifont]
>
^ permalink raw reply
* Re: Importing Bzr revisions
From: David Reitter @ 2009-03-23 12:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiwo8xz7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
On Mar 23, 2009, at 4:06 AM, Junio C Hamano wrote:
> David Reitter <david.reitter@gmail.com> writes:
>
>> Suppose I have a bzr branch that has been converted (somehow) to a
>> git
>> branch, is it then possible to merge new revisions from the bzr
>> branch
>> into the git one?
>
> It entirely depends on how that "somehow" goes.
>
> If that "somehow" procedure performs a reliably reproducible
> conversion
> (i.e. not only it will produce the identical git history when you
> feed the
The question is then: How would one reliably convert a Bzr branch to
git? One branch is enough for me, but we're talking >100k revisions,
so if the procedure involves Bzr tools, it will take longer then is
practicable.
Also, my impression is that not many people are doing this, because
the fast-export/import combination hasn't seen a lot of development
activity. I'm a bit wary to set up my project in git when I don't
just need to convert once, but in future convert and merge pretty much
every day... (The upstream project is going to use Bzr, while I am
trying to see if Git is an option for me downstream.)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply
* Re: Minimum libCurl version for git
From: Mike Ralphson @ 2009-03-23 11:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list, Daniel Stenberg, Nick Hengeveld, Mike Hommey
In-Reply-To: <7vy6uzg98v.fsf@gitster.siamese.dyndns.org>
2009/3/20 Junio C Hamano <gitster@pobox.com>:
> We can have these two macro definitions on our side
>
> #if curl older than 7.10.8
> #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE
> #endif
>
> #if curl older than 7.9.7
> #define CURLOPT_READDATA CURLOPT_INFILE
> #endif
>
> for backward compatibility, while writing our code to the recent API by
> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older
> curl would not have to suffer a bit.
See? That's why they pay you the big maintainer-bucks... 8-)
> Mike, I'd say we declare 7.9.3 as the floor and go from there. That's
> your #3, I think.
Short patch series to follow, though maybe not today.
Mike
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Wincent Colaiuta @ 2009-03-23 11:09 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530903230407i2c858a5dk2c2e0703608e42d3@mail.gmail.com>
El 23/3/2009, a las 12:07, Felipe Contreras escribió:
> On Mon, Mar 23, 2009 at 2:07 AM, Wincent Colaiuta <win@wincent.com>
> wrote:
>>
>> El 23/3/2009, a las 0:01, Felipe Contreras escribió:
>>
>>> On Mon, Mar 23, 2009 at 12:42 AM, Wincent Colaiuta <win@wincent.com>
>>> wrote:
>>>>
>>>> El 22/3/2009, a las 19:05, Felipe Contreras escribió:
>>>>
>>>>> This is shorter, avoids the burder to think about the format of
>>>>> the
>>>>> configuration file, and git config is already used in other
>>>>> places in
>>>>> the manual.
>>>>>
>>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>>> ---
>>>>> Documentation/user-manual.txt | 8 +++-----
>>>>> 1 files changed, 3 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/user-manual.txt
>>>>> b/Documentation/user-manual.txt
>>>>> index b7678aa..c6ed940 100644
>>>>> --- a/Documentation/user-manual.txt
>>>>> +++ b/Documentation/user-manual.txt
>>>>> @@ -1015,13 +1015,11 @@ Telling git your name
>>>>> ---------------------
>>>>>
>>>>> Before creating any commits, you should introduce yourself to
>>>>> git. The
>>>>> -easiest way to do so is to make sure the following lines appear
>>>>> in a
>>>>> -file named `.gitconfig` in your home directory:
>>>>> +easiest way is to use the linkgit:git-config[1] command:
>>>>>
>>>>> ------------------------------------------------
>>>>> -[user]
>>>>> - name = Your Name Comes Here
>>>>> - email = you@yourdomain.example.com
>>>>> +$ git config --global user.name "Your Name Comes Here"
>>>>> +$ git config --global user.email you@yourdomain.example.com
>>>>> ------------------------------------------------
>>>>>
>>>>> (See the '"CONFIGURATION FILE"' section of linkgit:git-config[1]
>>>>> for
>>>>> --
>>>>> 1.6.2.1.352.gae594
>>>>
>>>> See this lengthy thread:
>>>>
>>>> http://article.gmane.org/gmane.comp.version-control.git/106634
>>>
>>> I've obviously seen that thread because I started it.
>>
>> Yeah, I noticed that only after sending my message. I hadn't
>> realised at
>> first because the patch really looked like it was written by
>> someone who
>> hadn't ever seen the thread, as it doesn't address the points
>> raised in the
>> thread at all.
>
> I am addressing the points.
Sorry for not noticing the other patch in the series. I fired off the
email because when I read 8/8 I thought, "This looks almost exactly
like a patch that was previously rejected".
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-03-23 11:07 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <984D312E-12B8-4A8C-B567-EF5AF1DDD3D6@wincent.com>
On Mon, Mar 23, 2009 at 2:07 AM, Wincent Colaiuta <win@wincent.com> wrote:
>
> El 23/3/2009, a las 0:01, Felipe Contreras escribió:
>
>> On Mon, Mar 23, 2009 at 12:42 AM, Wincent Colaiuta <win@wincent.com>
>> wrote:
>>>
>>> El 22/3/2009, a las 19:05, Felipe Contreras escribió:
>>>
>>>> This is shorter, avoids the burder to think about the format of the
>>>> configuration file, and git config is already used in other places in
>>>> the manual.
>>>>
>>>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>>>> ---
>>>> Documentation/user-manual.txt | 8 +++-----
>>>> 1 files changed, 3 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/Documentation/user-manual.txt
>>>> b/Documentation/user-manual.txt
>>>> index b7678aa..c6ed940 100644
>>>> --- a/Documentation/user-manual.txt
>>>> +++ b/Documentation/user-manual.txt
>>>> @@ -1015,13 +1015,11 @@ Telling git your name
>>>> ---------------------
>>>>
>>>> Before creating any commits, you should introduce yourself to git. The
>>>> -easiest way to do so is to make sure the following lines appear in a
>>>> -file named `.gitconfig` in your home directory:
>>>> +easiest way is to use the linkgit:git-config[1] command:
>>>>
>>>> ------------------------------------------------
>>>> -[user]
>>>> - name = Your Name Comes Here
>>>> - email = you@yourdomain.example.com
>>>> +$ git config --global user.name "Your Name Comes Here"
>>>> +$ git config --global user.email you@yourdomain.example.com
>>>> ------------------------------------------------
>>>>
>>>> (See the '"CONFIGURATION FILE"' section of linkgit:git-config[1] for
>>>> --
>>>> 1.6.2.1.352.gae594
>>>
>>> See this lengthy thread:
>>>
>>> http://article.gmane.org/gmane.comp.version-control.git/106634
>>
>> I've obviously seen that thread because I started it.
>
> Yeah, I noticed that only after sending my message. I hadn't realised at
> first because the patch really looked like it was written by someone who
> hadn't ever seen the thread, as it doesn't address the points raised in the
> thread at all.
I am addressing the points.
>> Can you write more than one line to explain your point?
>
> I was thinking mostly of Junio's comments:
>
> http://article.gmane.org/gmane.comp.version-control.git/106667
>
> 'I am moderately against changing this part to use "git config". We
> traditionally introduced how to set configuration variables first by editing
> it in an editor, and this was quite deliberate, in order to show how the
> configuration file looks like, to demonstrate that there is no deep magic in
> the file format, and to explain that it is perfectly Ok to edit it without
> using "git config" command. I actually wish this section appeared a lot
> earlier in the document, but
> that is a separate issue.'
Like patch 7/8 patch does?
http://article.gmane.org/gmane.comp.version-control.git/114163
The 'git config' howto section is the very first chapter.
> If you expect him to apply your patch, you'll probably want to address those
> concerns (and possibly others raised in referenced thread) in the commit
> message.
Yeah, I probably need to update the commit message to make that extra
clear, I just cherry-picked the old patch. This is still RFC anyway.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH 8/8] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-03-23 11:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, git
In-Reply-To: <7viqm1az1k.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 23, 2009 at 2:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> See this lengthy thread:
>>>
>>> http://article.gmane.org/gmane.comp.version-control.git/106634
>>
>> I've obviously seen that thread because I started it.
>>
>> Can you write more than one line to explain your point?
>
> The "lengthy thread" look lengthier than necessary because it has a
> more-or-less unrelated side topic ("where is $HOME on Windows"), but I
> think the main point by WIncent is that onus lies on whoever repeats the
> previous discussion to provide what is different in this round to convince
> others to read the patch. For example, this
>
> http://article.gmane.org/gmane.comp.version-control.git/106657
>
> was not answered by you in the previous round, and I do not think this
> round is any different.
Was I supposed to answer it? I am trying to address the points raised
in those discussions in this patch series.
> I personally find that between what Wincent presented in
>
> http://article.gmane.org/gmane.comp.version-control.git/106673
>
> as "Something like either ... or ...", the first one that shows the actual
> configuration file contents and then mention 'git config' a good enough
> compromise.
Except that in the previous patch[1] (#7) I'm adding a new global
section that explains how to configure git in different ways:
I don't think it makes sense to explain "either ... or ..." each time
we deal with 'git config' in the manual if it's explained in the very
beginning.
[1] http://article.gmane.org/gmane.comp.version-control.git/114163
--
Felipe Contreras
^ permalink raw reply
* Re: .gitk should created hidden in windows
From: Paul Mackerras @ 2009-03-23 10:37 UTC (permalink / raw)
To: Steve Wagner; +Cc: git
In-Reply-To: <49BFA97A.1030203@lanwin.de>
Steve Wagner writes:
> The problem is that windows dose not hides files beginning with a dot as
> it is in unix. So the .gitk file is created as visible in the windows
> user profile. Problematic too is that i can no set the hidden attribute
> to this file, because it is recreated every time i start gitk, so the
> hidden attribute gets lost.
>
> Can you control this and create the file with the hidden attribute on
> windows?
Please try this patch and let me know if it does what you want.
Paul.
diff --git a/gitk b/gitk
index d7de27e..54f3f2b 100755
--- a/gitk
+++ b/gitk
@@ -2487,6 +2487,9 @@ proc savestuff {w} {
if {![winfo viewable .]} return
catch {
set f [open "~/.gitk-new" w]
+ if {$::tcl_platform(platform) eq {windows}} {
+ file attributes "~/.gitk-new" -hidden true
+ }
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
puts $f [list set uifont $uifont]
^ permalink raw reply related
* Re: [PATCH 0/2] gitk window icons
From: Paul Mackerras @ 2009-03-23 10:59 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Giuseppe Bilotta
In-Reply-To: <cover.1237451887.git.bebarino@gmail.com>
Stephen Boyd writes:
> These two patches set the git logo, three red minus signs and three green plus
> signs below on a white background, as the window icon for gitk.
Thanks, applied. (I adjusted the indentation in both and wrote a
brief commit message for the second.)
Paul.
^ permalink raw reply
* Re: Git for Windows 1.6.2.1-preview20090322
From: Johannes Schindelin @ 2009-03-23 10:59 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git, msysgit
In-Reply-To: <20090323025358.GA19717@coredump.intra.peff.net>
Hi,
On Sun, 22 Mar 2009, Jeff King wrote:
> On Mon, Mar 23, 2009 at 12:25:57AM +0100, Johannes Schindelin wrote:
>
> > > A few people have asked about filter-branch on Windows recently;
> >
> > I am not aware of any. But then, I think nobody mentioned it on the
> > msysgit list (which would be the correct place), and I am likely to
> > have missed it if it was sent elsewhere.
>
> They were less feature request and more mentioned in the middle of other
> discussions. I am thinking specifically of:
>
> http://thread.gmane.org/gmane.comp.version-control.git/112253/focus=112439
> http://thread.gmane.org/gmane.comp.version-control.git/111722/focus=112103
Well, I will miss such in-the-middle-of-unrelated-discussions remarks.
Even if some people think I ridicule them when I say that I do not have
much time, it is a fact. If I did not like Git as much as I do, I would
have stopped long time ago for sanity reasons.
> > Actually, not only Hannes' version runs the test t7003 okay, but also
> > 4msysgit's version.
> >
> > But let's reduce the differences between git.git and 4msysgit.git
> > further first.
>
> OK. I just wanted to make you aware of the existing threads and Hannes'
> message, since as you mentioned they _weren't_ on the msysgit list.
FWIW I ran the test while replying to your mail yesterday, and created the
'filter-branch' branch in msysgit.git. I'll probably just merge it into
our 'master' later today.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH 1/8] user-manual: remove some git-foo usage
From: Felipe Contreras @ 2009-03-23 10:54 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090323063141.GA1119@coredump.intra.peff.net>
On Mon, Mar 23, 2009 at 8:31 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Mar 22, 2009 at 08:05:14PM +0200, Felipe Contreras wrote:
>
>> Every commit has a 40-hexdigit id, sometimes called the "object name" or the
>> -"SHA1 id", shown on the first line of the "git-show" output. You can usually
>> +"SHA1 id", shown on the first line of the "git show" output. You can usually
>
> I think some of these were intentionally left in the original mass
> dashes to spaces conversion. The intent was that one could use the
> git-show form in talking about the command in text.
>
> However, I think I actually prefer the version given by your patch. I
> just wanted to point out that this is a decision to change how we
> mention these in the documentation and not simply a fix for things that
> got missed in the conversion. Others may disagree on how it looks.
>
> It seems like you added monospace backticks in most locations. Is there
> a reason not to standardize on that and use `git show` here?
>
>> [[Updating-a-repository-With-git-fetch]]
>> -Updating a repository with git-fetch
>> +Updating a repository with git fetch
>> ------------------------------------
>
> I think this one should probably be `git fetch`.
A subsequent patch is adding the monospace backticks and a lot more
quotation stuff.
In this patch I tried to focus on git-foo, and add the backticks only
when there are no delimiters, so I replaced "git-foo" with "git foo"
and git-foo with `git foo`. I also didn't add backticks on the titles
because I thought it was a bit controversial and was probably better
in a separate patch.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH 3/8] docbook: radical style change
From: Felipe Contreras @ 2009-03-23 10:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090323065004.GC1119@coredump.intra.peff.net>
On Mon, Mar 23, 2009 at 8:50 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Mar 22, 2009 at 08:05:16PM +0200, Felipe Contreras wrote:
>
>> Use smaller 'sans-serial' font. Sans-Serial fonts are supposed to be
>> easier to read in screens. This format is similar to the one of
>> Wikipedia.
>
> I started to look up "sans-serial" before I realized it seems to be just
> a typo for "sans-serif" (or is there something I'm missing)?
Right, I meant sans-serif.
> Is there a reason to apply this style change just to docbook-generated
> HTML? Most of the HTML documentation is generated directly from
> asciidoc.
Nope, it's just the one I'm working right now.
>> html body {
>> margin: 1em 5% 1em 5%;
>> - line-height: 1.2;
>> + line-height: 1em;
>> + font-family: sans-serif;
>> + font-size: small;
>
> Personally, I think collapsing the line spacing looks worse.
>
> I'm not sure I see the point of putting "small" text for the entire
> body. Since it covers the whole page, you are not "small" with respect
> to anything else, but are basically just overriding the user's choice
> through their browser of what is a reasonable default text size.
Well, Google, Gmail and even Wikipedia have a 'small' font-size. I'm
sure people don't find Wikipedia hard to read :)
The only difference with the user manual is that it actually takes the
whole screen, so it might be difficult to follow such big lines with a
small font. I haven't made up my mind yet... I think a 'normal'
font-size also looks good.
--
Felipe Contreras
^ permalink raw reply
* git rebase + fuzz = possible bad merge
From: Benny Halevy @ 2009-03-23 10:41 UTC (permalink / raw)
To: Git List
I'm hitting bad merges with (non interactive) git rebase
when a hunk is merged pre-maturely into an inexact match
when there's fuzz.
The following shell script reproduce this with
git version 1.6.2.1:
#!/bin/sh
rm -rf test_file .git
git init
cat >test_file <<EOF
struct one {
line 1;
line 2;
line 3;
line 4;
line 5;
line 6;
line 7;
};
struct two {
line 1;
line 2;
line 3;
line 4;
line 5;
line 6;
line 7;
};
EOF
git add test_file
git commit -m test_file
git am <<EOF
From: Benny Halevy <bhalevy@panasas.com>
Subject: change struct two
diff --git a/test_file b/test_file
--- a/test_file
+++ b/test_file
@@ -12,7 +12,7 @@ struct two {
line 1;
line 2;
line 3;
- line 4;
+ LINE 4;
line 5;
line 6;
line 7;
EOF
git checkout -b test_branch HEAD^
{ for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
mv fuzz_file test_file
git commit -a -m fuzz
git rebase --onto test_branch master^ master
if [ $(awk '/LINE/ {print NR}' test_file) != 26 ]; then
echo 1>&2 $0: test failed
exit 1
else
echo 1>&2 $0: test succeeded
fi
^ permalink raw reply
* should "git describe" include info about not already committed patches ?
From: Toralf Förster @ 2009-03-23 10:37 UTC (permalink / raw)
To: git
I'm wondering, if there's a option for "git describe" to point out the changes
(as seen with git diff) which are made w/o a commit to a current trunk.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: [RFC with a proof of concept PATCH] Add Bonsai-like query options to gitk
From: Paul Mackerras @ 2009-03-23 10:07 UTC (permalink / raw)
To: newren; +Cc: git, angavrilov
In-Reply-To: <1236627747-32107-1-git-send-email-newren@gmail.com>
Elijah Newren <newren@gmail.com> writes:
> (If you like screenshots, I've got some before & after ones up at
> http://www.gnome.org/~newren/temp/gitk/gitk-edit-view.html, but
> remember that this is just a proof of concept and call for comments.)
Looks reasonable... have you developed the patch any further?
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Handle blobs containing a DOS end-of-file marker.
From: Paul Mackerras @ 2009-03-23 10:33 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <87y6v5ojdj.fsf@users.sourceforge.net>
Pat Thoyts writes:
> If a patchset contains an EOF marker (Ctrl-Z) the blob diff terminates
> at that point. This patch permits gitk to ignore the eof and continue to
> display any subsequent blobs and also displays a sensible representation
> of the eof char.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: put all startup code into a proc to enable re-sourcing
From: Paul Mackerras @ 2009-03-23 10:04 UTC (permalink / raw)
To: Pat Thoyts; +Cc: git
In-Reply-To: <87prh3e7p2.fsf@users.sourceforge.net>
Pat Thoyts writes:
> All the startup code is moved into a procedure. All the variables
> get initialized using 'variable' to ensure they are in the global
> namespace. This makes it possible to re-source the script during
> development from the Tk console or a tkcon interactive session.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The patch does other stuff as well, that should be mentioned in the
patch description or split out into a separate patch - namely it
changes error_popup on win32 (why?) and it introduces some ttk widget
use into confirm_popup.
Paul.
^ permalink raw reply
* Re: [PATCH JGIT] Method invokes inefficient Number constructor; use static valueOf instead
From: Yann Simon @ 2009-03-23 10:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Robin Rosenberg, git
In-Reply-To: <20090319154958.GP23521@spearce.org>
2009/3/19 Shawn O. Pearce <spearce@spearce.org>:
> Why I box with new Long() over Long.valueOf():
>
> The standard only requires -128..127 to be cached. A JRE can
> cache value outside of this range if it chooses, but long has a
> huge range, its unlikely to cache much beyond this required region.
>
> Most pack files are in the 10 MB...100+ MB range. Most objects
> take more than 100 bytes in a pack, even compressed delta encoded.
> Thus any object after the first is going to have its offset outside
> of the cached range.
>
> In other words, why waste the CPU cycles on the "cached range
> bounds check" when I'm always going to fail and allocate. I might
> as well just allocate
>
> These sections of code are rather performance critical for the
> indexing phase of a pack receive, on either side of a connection.
> I need to shave even more instructions out of the critical paths,
> as its not fast enough as-is. Using new Long() is quicker than
> using Long.valueOf(), so new Long() it is.
It makes sense.
Thank you for the explanation.
Yann
^ permalink raw reply
* [bug?] git-format-patch produces a 0-byte long patch for the first commit
From: Guennadi Liakhovetski @ 2009-03-23 10:34 UTC (permalink / raw)
To: git
Hi,
I noticed some special "features" of the first git commit, which seem at
least inconsistent to me, even though I've got some explanations on IRC.
E.g., the sequence
mkdir x
cd x
git-init
echo hi > greating
git-commit -a
git-format-patch -1
produces a 0-byte long patch. git-format-patch HEAD^ produces an error,
whereas with more than one commit it produces tha last patch. Yes, I know
about "--root" and that it does allow to extract the very first commit.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-23 10:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090323064242.GB1119@coredump.intra.peff.net>
On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>
>> tt.literal, code.literal {
>> color: navy;
>> + font-size: 1em;
>> +}
>
> Isn't 1em already the default size? Or are you trying to override some
> other size specification elsewhere? It's hard to tell what the goal is
> because your commit message merely says "improve".
That's correct.
The problem is that when the user has a different size for the
sans-serif and monospace fonts it looks horrible when they are on the
same paragraph. I thought 1em did the trick, but you are right, it
doesn't.
It looks like the only way to fix this is to set absolute sizes.
--
Felipe Contreras
^ permalink raw reply
* [PATCH 3/3] completion: add --thread=deep/shallow to format-patch
From: Stephen Boyd @ 2009-03-23 10:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1237804011-15419-3-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b96458f..1c6b0e2 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -930,9 +930,15 @@ _git_format_patch ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
+ --thread=*)
+ __gitcomp "
+ deep shallow
+ " "" "${cur##--thread=}"
+ return
+ ;;
--*)
__gitcomp "
- --stdout --attach --no-attach --thread
+ --stdout --attach --no-attach --thread --thread=
--output-directory
--numbered --start-number
--numbered-files
--
1.6.2
^ permalink raw reply related
* [PATCH 2/3] completion: add --cc and --no-attachment option to format-patch
From: Stephen Boyd @ 2009-03-23 10:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1237804011-15419-2-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8719242..b96458f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -932,13 +932,13 @@ _git_format_patch ()
case "$cur" in
--*)
__gitcomp "
- --stdout --attach --thread
+ --stdout --attach --no-attach --thread
--output-directory
--numbered --start-number
--numbered-files
--keep-subject
--signoff
- --in-reply-to=
+ --in-reply-to= --cc=
--full-index --binary
--not --all
--cover-letter
--
1.6.2
^ permalink raw reply related
* [PATCH 0/3] completion updates
From: Stephen Boyd @ 2009-03-23 10:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Stephen Boyd (3):
completion: add --annotate option to send-email
completion: add --cc and --no-attachment option to format-patch
completion: add --thread=deep/shallow to format-patch
contrib/completion/git-completion.bash | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH 1/3] completion: add --annotate option to send-email
From: Stephen Boyd @ 2009-03-23 10:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1237804011-15419-1-git-send-email-bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 10e36a7..8719242 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1264,8 +1264,8 @@ _git_send_email ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
- __gitcomp "--bcc --cc --cc-cmd --chain-reply-to --compose
- --dry-run --envelope-sender --from --identity
+ __gitcomp "--annotate --bcc --cc --cc-cmd --chain-reply-to
+ --compose --dry-run --envelope-sender --from --identity
--in-reply-to --no-chain-reply-to --no-signed-off-by-cc
--no-suppress-from --no-thread --quiet
--signed-off-by-cc --smtp-pass --smtp-server
--
1.6.2
^ permalink raw reply related
* [PATCH] Documentation: git-format-patch.txt rewordings and cleanups
From: Stephen Boyd @ 2009-03-23 10:21 UTC (permalink / raw)
To: git
Clarify --no-binary description using some words from the original
commit 37c22a4b (add --no-binary, 2008-05-9). Cleanup --suffix and
--thread descriptions. Add --thread style option to synopsis. Clarify
renaming patches example.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Is the synopsis getting too heavy? Maybe it should be changed to:
git format-patch [<options>] [<common diff options>] [<revision range>]
Documentation/git-format-patch.txt | 34 +++++++++++++++++-----------------
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c2eb5fa..f31098b 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,9 +9,9 @@ git-format-patch - Prepare patches for e-mail submission
SYNOPSIS
--------
[verse]
-'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
+'git format-patch' [-k] [-o <dir> | --stdout] [--thread[=<style>]]
[--attach[=<boundary>] | --inline[=<boundary>] |
- [--no-attach]]
+ --no-attach]
[-s | --signoff] [<common diff options>]
[-n | --numbered | -N | --no-numbered]
[--start-number <n>] [--numbered-files]
@@ -132,9 +132,9 @@ include::diff-options.txt[]
the Message-Id header to reference.
+
The optional <style> argument can be either `shallow` or `deep`.
-'Shallow' threading makes every mail a reply to the head of the
+'shallow' threading makes every mail a reply to the head of the
series, where the head is chosen from the cover letter, the
-`\--in-reply-to`, and the first patch mail, in this order. 'Deep'
+`\--in-reply-to`, and the first patch mail, in this order. 'deep'
threading makes every mail a reply to the previous one. If not
specified, defaults to the 'format.thread' configuration, or `shallow`
if that is not set.
@@ -169,24 +169,24 @@ if that is not set.
--suffix=.<sfx>::
Instead of using `.patch` as the suffix for generated
filenames, use specified suffix. A common alternative is
- `--suffix=.txt`.
+ `--suffix=.txt`. Leaving this empty will remove the `.patch`
+ suffix.
+
-Note that you would need to include the leading dot `.` if you
-want a filename like `0001-description-of-my-change.patch`, and
-the first letter does not have to be a dot. Leaving it empty would
-not add any suffix.
+Note the first letter is not required to be a dot, you will need to
+include the leading dot `.` if you want a filename like
+`0001-description-of-my-change.patch`.
--no-binary::
- Don't output contents of changes in binary files, just take note
- that they differ. Note that this disable the patch to be properly
- applied. By default the contents of changes in those files are
- encoded in the patch.
+ Do not output contents of changes in binary files, instead
+ display a notice that those files changed. Patches generated
+ using this option cannot be applied properly, but they are
+ still useful for code review.
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each message
-in the repository configuration, new defaults for the subject prefix
-and file suffix, control attachements, and number patches when outputting
+in the repository configuration, defaults for the subject prefix
+and file suffix, configure attachments, and number patches when outputting
more than one.
------------
@@ -234,8 +234,8 @@ $ git format-patch -M -B origin
+
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
-the amount of text output, and generally makes it easier to review it.
-Note that the "patch" program does not understand renaming patches, so
+the amount of text output, and generally makes it easier to review.
+Note that non-git "patch" programs won't understand renaming patches, so
use it only when you know the recipient uses git to apply your patch.
* Extract three topmost commits from the current branch and format them
--
1.6.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox