* RE: [QGit] Some suggestion
From: Li Frank-B20596 @ 2008-09-26 1:55 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550809250934l47c48440m332764491ff5391@mail.gmail.com>
Thank you for your support!
Can I compare with other version at file view?
I think highlight author at file view is not high light, can use
different color?
-----Original Message-----
From: Marco Costalba [mailto:mcostalba@gmail.com]
Sent: Friday, September 26, 2008 12:34 AM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: [QGit] Some suggestion
On Thu, Sep 25, 2008 at 4:20 PM, Li Frank-B20596
<Frank.Li@freescale.com> wrote:
> Marco:
>
> Ctrl +/- change font size, but how to change source code view
> font size.
>
Edit->Settings->Fixed width font
You can choose size, font family, bolding, etc...
File view and diff view are optimized for source code viewing so use
fixed pitch fonts, not system default one that normally it is not fixed
pitch.
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: SZEDER Gábor @ 2008-09-26 1:03 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1222389359-22191-1-git-send-email-vmiklos@frugalware.org>
Szia Miklós,
On Fri, Sep 26, 2008 at 02:35:59AM +0200, Miklos Vajna wrote:
> reduce_heads() can filter "duplicated" parents, where "duplicated"
> means: A is duplicated if both A and B are parent candidates and A is
> reachable from B. Doing so in builtin-merge makes sense, but not in
> builtin-commit, because this breaks git merge --no-commit --no-ff.
> Here is a patch that fixes the problem for me.
Thanks for the quick response. While your patch does fix the bug I
reported, unfortunately it introduces a new one: t7502-commit.sh
fails at me with the following:
* ok 17: a SIGTERM should break locks
* expecting success:
git rev-parse second master >expect &&
test_must_fail git merge second master &&
git checkout master g &&
EDITOR=: git commit -a &&
git cat-file commit HEAD | sed -n -e "s/^parent //p" -e
"/^$/q" >actual &&
test_cmp expect actual
Already up-to-date with 1ae92d674ba95768a00bace571f5ef295ff1696b
Trying simple merge with 9af21aa779d9e148680be525ce161baa37e4bdec
Simple merge did not work, trying automatic merge.
Auto-merging g
ERROR: Merge conflict in g
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.
Created commit 45a4b2b: Merge branches 'second' and 'master' into
second
--- expect 2008-09-26 00:59:42.000000000 +0000
+++ actual 2008-09-26 00:59:42.000000000 +0000
@@ -1,2 +1,3 @@
1ae92d674ba95768a00bace571f5ef295ff1696b
+1ae92d674ba95768a00bace571f5ef295ff1696b
9af21aa779d9e148680be525ce161baa37e4bdec
* FAIL 18: Hand committing of a redundant merge removes dups
git rev-parse second master >expect &&
test_must_fail git merge second master &&
git checkout master g &&
EDITOR=: git commit -a &&
git cat-file commit HEAD | sed -n -e "s/^parent //p"
-e "/^$/q" >actual &&
test_cmp expect actual
* failed 1 among 18 test(s)
make: *** [t7502-commit.sh] Error 1
Regards,
Gábor
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Linus Torvalds @ 2008-09-26 0:37 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.1.10.0809251657080.3265@nehalem.linux-foundation.org>
On Thu, 25 Sep 2008, Linus Torvalds wrote:
>
> And the thing I wanted to work was to have the abbreviated SHA1's that
> have started to get more common in the kernel commit logs work as links in
> gitk too, just the way a full 40-character SHA1 link works.
For a test-case, I just pushed out my current top-of-tree that finally
pushed me over the edge. I've seen this before, but I couldn't really
force me to do anything about it until now.
So to see this in action, do
gitk v2.6.26..6ef190c
on the current kernel repo, and notice that "Commit ee1e2c82 ("IPoIB:
Refresh paths .." thing, where we want that 'ee1e2c82' to be a link even
though it's not a full SHA1.
Of course, the matching could be better, it will now accept any random 6+
character sequence of hex characters, even if they are surrounded by
characters that make it clear that it's not a SHA1 ("Haahahhaaaaaa!"
would find the 'aaaaaa' and if you have a commit that starts with that,
link to it ;)
And because it's the top commit, you can also easily see the behavior that
it doesn't turn out to be a link immediately, and you have to do
cursor-down + cursor-up to get the link. The "it points to the wrong line"
bug is much harder to trigger, and possibly impossible with that
particular case (to trigger it, you need a setup where the first layout of
the target commit then gets changed by the topo-sort, I'm not sure that
will happen at all, and if it does, I'm not sure you could time it just
right either, but I _have_ seen it in real life).
Linus
^ permalink raw reply
* [PATCH] builtin-commit: avoid using reduce_heads()
From: Miklos Vajna @ 2008-09-26 0:35 UTC (permalink / raw)
To: SZEDER Gabor; +Cc: git
In-Reply-To: <20080925235029.GA15837@neumann>
reduce_heads() can filter "duplicated" parents, where "duplicated"
means: A is duplicated if both A and B are parent candidates and A is
reachable from B. Doing so in builtin-merge makes sense, but not in
builtin-commit, because this breaks git merge --no-commit --no-ff.
Test case by SZEDER Gabor <szeder@ira.uka.de>
---
Here is a patch that fixes the problem for me. In fact I think it would
be nice if somehow git-merge could tell git-commit that 'do not reduce
heads now' and in other cases it could still do so, but:
1) This is not something git-commit did in the past, either.
2) I have no idea what would be the right interface to do so
(maybe a new MERGE_FOO file under .git?)
builtin-commit.c | 1 -
t/t7600-merge.sh | 9 +++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 55e1087..9daab0a 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -988,7 +988,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
reflog_msg = "commit";
pptr = &commit_list_insert(lookup_commit(head_sha1), pptr)->next;
}
- parents = reduce_heads(parents);
/* Finally, get the commit message */
strbuf_init(&sb, 0);
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 9516f54..98cfc53 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -511,4 +511,13 @@ test_expect_success 'in-index merge' '
test_debug 'gitk --all'
+test_expect_success 'merge --no-ff --no-commit && commit' '
+ git reset --hard c0 &&
+ git merge --no-ff --no-commit c1 &&
+ EDITOR=: git commit &&
+ verify_parents $c0 $c1
+'
+
+test_debug 'gitk --all'
+
test_done
--
1.6.0.2
^ permalink raw reply related
* gitk: Turn short SHA1 names into links too
From: Linus Torvalds @ 2008-09-26 0:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
Ok, so I'm a newbie when it comes to tcl/tk, but I can do copy-paste and
make things work.
And the thing I wanted to work was to have the abbreviated SHA1's that
have started to get more common in the kernel commit logs work as links in
gitk too, just the way a full 40-character SHA1 link works.
This patch does seem to work, but it's also buggy in exactly the same ways
the regular 40-character links are buggy, and while I find those bugs
very irritating _too_, I can't cut-and-paste myself to a solution for
that.
The pre-existing bugs that this shares with the long links are:
- since gitk started doing incremental showing of the graph, the whole
"check if it exists" doesn't work right if the target hasn't been
loaded yet. And when it _does_ end up being loaded one second later,
nothing re-does the scanning.
This is just a small irritation, but it's quite common when the first
commit that is displayed has a link. You can fix it by moving to the
next commit and moving right back (cursor-down + cursor-up), which will
re-display the commit and now find the link that wasn't available
initially, but it's still irritating.
I think gitk could re-display the commit it is on when the whole list
of commits has been parsed, and at least then show the links it missed
initially after a few seconds.
- slightly related to the above: when we _do_ find a link, we create it
to be a link to line so-and-so, but since we now don't just
incrementally parse the commits that come in, but gitk _also_ actually
reflows the commits to be in topological order, the link we just
created may actually no longer point to the right line by the time the
link is then clicked on, so clicking on a link can actually take you to
the wrong commit!
Again, re-displaying the current commit after we have gotten and
parsed all commits will fix it, but this is a more fundamental problem:
if we redisplay at the end, there is still a window when the link may
simply be wrong, because we've redone the topo sort, but we haven't
seen _all_ commits yet.
But again, you can work around it by going back and retrying, and at
some time it will stabilize. But this one is _really_ irritating when
it triggers, because it can make you look at the wrong commit without
necessarily realizing it was wrong!
I suspect that the correct fix is to always do the link, whether we
actually see it or not, and not make it point to a line number, but simply
keep it as a SHA1, and then do the equivalent of "gotocommit" when
clicking it. But I don't know how links workin tcl/tk, so I'm not going to
be able to do that.
In the meantime, this patch introduces no new bugs, and the workarounds
are the same for abbreviated SHA1's as they are for the full ones.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
I'm sure it could have been done better. In particular, I think the
"short->long" translation could/should probably be a function of its own.
But I'm so uncomfortable with wish programming that I'm not starting to
write any new functions..
Comments? Paul?
Linus
gitk-git/gitk | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 2eaa2ae..f79643a 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -5759,7 +5759,7 @@ proc appendwithlinks {text tags} {
set start [$ctext index "end - 1c"]
$ctext insert end $text $tags
- set links [regexp -indices -all -inline {[0-9a-f]{40}} $text]
+ set links [regexp -indices -all -inline {[0-9a-f]{6,40}} $text]
foreach l $links {
set s [lindex $l 0]
set e [lindex $l 1]
@@ -5773,7 +5773,18 @@ proc appendwithlinks {text tags} {
}
proc setlink {id lk} {
- global curview ctext pendinglinks commitinterest
+ global curview ctext pendinglinks commitinterest varcid
+
+ # Turn a short ID into a full one
+ if {[regexp {^[0-9a-f]{4,39}$} $id]} {
+ set matches [array names varcid "$curview,$id*"]
+ if {$matches ne {}} {
+ if {[llength $matches] > 1} {
+ return
+ }
+ set id [lindex [split [lindex $matches 0] ","] 1]
+ }
+ }
if {[commitinview $id $curview]} {
$ctext tag conf $lk -foreground blue -underline 1
^ permalink raw reply related
* [BUG] merge --no-ff --no-commit && commit
From: SZEDER Gábor @ 2008-09-25 23:50 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
Hi,
after today's update on master, the merge commit generated by 'git
merge --no-ff --no-commit branch && git commit' has only one parent if
the merge can be resolved as a fast forward. The test case below
demonstrates this behaviour.
Bisecting showed that the regression was introduced by commit 6bb6b034
(builtin-commit: use commit_tree(), 2008-09-10).
Regards,
Gábor
-- >8 --
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 9516f54..98cfc53 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -511,4 +511,13 @@ test_expect_success 'in-index merge' '
test_debug 'gitk --all'
+test_expect_success 'merge --no-ff --no-commit && commit' '
+ git reset --hard c0 &&
+ git merge --no-ff --no-commit c1 &&
+ EDITOR=: git commit &&
+ verify_parents $c0 $c1
+'
+
+test_debug 'gitk --all'
+
test_done
^ permalink raw reply related
* Re: having to pull twice
From: Miklos Vajna @ 2008-09-25 23:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: Shawn O. Pearce, Michael P. Soulier, git
In-Reply-To: <200809250905.09646.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On Thu, Sep 25, 2008 at 09:05:02AM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> On the other hand, as near as I can tell this is a regression in
> builtin-merge. Miklos, do you know if/how this can be fixed?
I think Junio already fixed this in 446247d (merge: fix numerus bugs
around "trivial merge" area, 2008-08-23), so 1.6.0.1 or 1.6.0.2 should
not have this bug.
Michael, could you please upgrade frm 1.6.0 and confirm your problem
goes away?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Add OS X support to the pre-auto-gc example hook
From: Miklos Vajna @ 2008-09-25 23:20 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git
In-Reply-To: <1222209803-4401-1-git-send-email-jon.delStrother@bestbefore.tv>
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
On Tue, Sep 23, 2008 at 11:43:23PM +0100, Jonathan del Strother <jon.delStrother@bestbefore.tv> wrote:
> Shell scripting isn't my fortĂŠ, suggestions for improvements would be
> welcome.
>
> +elif test -x /usr/bin/pmset && (! /usr/bin/pmset -g batt | grep -q 'Battery Power' )
What about
+elif test -x /usr/bin/pmset && /usr/bin/pmset -g batt | grep -q 'AC Power'
?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] detection of directory renames
From: Jakub Narebski @ 2008-09-25 23:19 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20080925213819.27029.47944.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> This is a first very preliminar patch, mostly so people can comment
> early on the big picture. It has a number of limitations, many but
> not all already listed as FIXME's in the patch itself. If anything in
> this patch seems so wrong it is not worth polishing it, it's the
> perfect time to say so :)
>
> The idea is to add a new pass to diffcore-rename, to group file renames
> looking like a full directory move, and then to hide those file
> renames which do not carry any additionnal information.
>
> Here is a sample run:
>
> $ ./git-diff-tree ee491 --factorize-renames -r
> [DBG] possible rename from arm/ to bar/
> [DBG] possible rename from ppc/ to moved/
> [DBG] discarding dir rename of arm/, mixing moved/ and bar/
> [DBG] ppc/* -> moved/* makes ppc/sha1ppc.S -> moved/sha1ppc.S uninteresting
> [DBG] ppc/* -> moved/* makes ppc/sha1.c -> moved/sha1.c uninteresting
> ee491a42190ec6e716f46a55fa0a7f4e307f1629
> :040000 040000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 R100 ppc/ moved/
> :100644 100644 9e3ae038e818f4e21bc50f864fc5204f6fa44daa 9e3ae038e818f4e21bc50f864fc5204f6fa44daa R100 arm/sha1.c bar/sha1.c
> :100644 100644 3952646349cf9d033177e69ba9433652a378c0e9 3952646349cf9d033177e69ba9433652a378c0e9 R100 arm/sha1.h bar/sha1.h
> :100644 100644 c3c51aa4d487f2e85c02b0257c1f0b57d6158d76 c065eeef7d68ea91863431788e20cd814c5ac52c R099 ppc/sha1.h moved/sha1.h
> :100644 100644 8c1cb99fb403875af85e4d1524d21f7eb818f59b 8c1cb99fb403875af85e4d1524d21f7eb818f59b R100 arm/sha1_arm.S moved/sha1_arm.S
Wonderfull!!!
I like it very much, and hope that it would get improved. And that you
would be able to use it in merges too, to allow for example for new
files to be created in renamed directory instead of old one which does
not exist any longer (c.f. http://www.markshuttleworth.com/archives/123
and following articles).
For the future, could you show examples with --abbrev option in use? TIA.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git log and utf-u in filenames
From: Jakub Narebski @ 2008-09-25 23:15 UTC (permalink / raw)
To: Joey Hess; +Cc: Git Mailing List
In-Reply-To: <20080925224354.GA6072@kodama.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> Joey Hess wrote:
> > And did earlier versions of git (circa 2006) perhaps not do that
> > escaping? I have code in ikiwiki that apparently used to work, but
> > is certianly not working with current git, due to this escaping.
>
> No, I guess it's always done that, perhaps something broke on my side
> in the meantime.
>
> But it doesn't seem right somehow that gitweb, ikiwiki, and seemingly
> any other program that needs to look at git log / commits and figure out
> what filename is being changed needs to include their own nasty code[1] to
> convert the escaped characters back to normal characters.
Well, in gitweb we could use '-z' option for git-diff-tree and git-ls-tree,
but it has its disadvantages, like having to do actual parsing record after
record instead of simplys splitting outout on end of line ("\n") characters.
> Would making git-log and git-commit display de-escaped filenames be likely
> to break something?
core.quotepath limits filename escaping, but you still _have_ to quote
"\n", "\t", and of course '"' and '\', if you want for filename to have
in single line in text format.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git log and utf-u in filenames
From: Jakub Narebski @ 2008-09-25 23:11 UTC (permalink / raw)
To: Joey Hess; +Cc: Git Mailing List
In-Reply-To: <20080925215002.GA30810@kodama.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> Git, particularly git-log seems to not display utf-8 characters in filenames,
> instead showing an escaped representation. On the other hand, commit messages,
> as git-log(1) notes, are assumed to be utf-8, and the same utf-8 character
> used in a commit message is not escaped, and displays ok.
>
> Can anyone point me at the documentation for this utf-8 filename
> escaping, assuming it's not a bug? And did earlier versions of git
> (circa 2006) perhaps not do that escaping? I have code in ikiwiki
> that apparently used to work, but is certianly not working with
> current git, due to this escaping.
Err... it always worked like this, mainly I think to have 7bit safe
patches for sending via email. Now in the time of 8bit transfer
and using single utf-8 encoding instead of multitude of different
filesystem encodings, you can set core.quotepath to false, although
this would eliminate only octal escaping for >127 ASCII characters;
TAB, CR etc. would still be quoted (and they have to be).
gitconfig(7):
core.quotepath::
The commands that output paths (e.g. 'ls-files',
'diff'), when not given the `-z` option, will quote
"unusual" characters in the pathname by enclosing the
pathname in a double-quote pair and with backslashes the
same way strings in C source code are quoted. If this
variable is set to false, the bytes higher than 0x80 are
not quoted but output as verbatim. Note that double
quote, backslash and control characters are always
quoted without `-z` regardless of the setting of this
variable.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: having to pull twice
From: Michael P. Soulier @ 2008-09-25 21:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: Thomas Rast, Shawn O. Pearce, Miklos Vajna, git
In-Reply-To: <20080925184942.GA3959@blimp.localhost>
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
On 25/09/08 Alex Riesen said:
> Maybe set "core.trustctime" for this repo to false?
I can certainly try that, and mention it if it happens again.
Mike
--
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a lot of courage to move in the opposite
direction." --Albert Einstein
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git log and utf-u in filenames
From: Joey Hess @ 2008-09-25 22:43 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20080925215002.GA30810@kodama.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]
Joey Hess wrote:
> And did earlier versions of git (circa 2006) perhaps
> not do that escaping? I have code in ikiwiki that apparently used to work, but
> is certianly not working with current git, due to this escaping.
No, I guess it's always done that, perhaps something broke on my side
in the meantime.
But it doesn't seem right somehow that gitweb, ikiwiki, and seemingly
any other program that needs to look at git log / commits and figure out
what filename is being changed needs to include their own nasty code[1] to
convert the escaped characters back to normal characters.
And it seems that anyone who uses a lot of utf-8 in filenames would shortly
get tired of git commit, git log, etc displaying obfuscated versions of their
filenames.
I'm sure it makes sense to use this format internally in git to represent
filenames, to avoid needing to worry about encoding issues. But it's a shame
that that internal detail is exposed so that everything around git has to
worry about it.
Would making git-log and git-commit display de-escaped filenames be likely
to break something?
--
see shy jo
[1] Such as this from gitweb:
# git may return quoted and escaped filenames
sub unquote {
my $str = shift;
sub unq {
my $seq = shift;
my %es = ( # character escape codes, aka escape sequences
't' => "\t", # tab (HT, TAB)
'n' => "\n", # newline (NL)
'r' => "\r", # return (CR)
'f' => "\f", # form feed (FF)
'b' => "\b", # backspace (BS)
'a' => "\a", # alarm (bell) (BEL)
'e' => "\e", # escape (ESC)
'v' => "\013", # vertical tab (VT)
);
if ($seq =~ m/^[0-7]{1,3}$/) {
# octal char sequence
return chr(oct($seq));
} elsif (exists $es{$seq}) {
# C escape sequence, aka character escape code
return $es{$seq};
}
# quoted ordinary character
return $seq;
}
if ($str =~ m/^"(.*)"$/) {
# needs unquoting
$str = $1;
$str =~ s/\\([^0-7]|[0-7]{1,3})/unq($1)/eg;
}
return $str;
}
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Introduce patch factorization in diffcore.
From: Andreas Ericsson @ 2008-09-25 22:39 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20080925214707.27029.36260.stgit@gandelf.nowhere.earth>
Yann Dirson wrote:
> " try unchanged files as candidate for copy detection.\n" \
> +" --factorize_renames\n" \
> +" factorize renames of all files of a directory.\n" \
Use dashes to separate words in arguments, please.
>
> +#include <libgen.h>
> +
+#ifdef basename
+# undef basename
+#endif
We might as well use the GNU version of basename() at least. Even if
you don't use it, I'd rather not see this bite some unwary programmer
coming along after you. Worst case scenario, sha1's won't add up if
POSIX basename alters its argument, making for one fiendishly tricky
bug to find.
> +/*
> + * FIXME: we could optimize the 100%-rename case by preventing
> + * recursion to unfold what we know we would refold here.
> + * FIXME: do we want to replace linked list with sorted array ?
Either that or a hash. Most of the time seems to be spent in lookups.
With a hash you get quick lookups and reasonably quick inserts. With
a sorted array you get lower memory footprint than anything else and
can bisect your way to the right entry, which performs reasonably
close to skiplists. The sort overhead might be a deterrant factor,
but insofar as I understand it trees are always sorted in git anyway,
so perhaps that'd be the best solution.
Apart from that, I'd need to apply the patch to review it properly,
and I'm far too tired for that now.
I like the direction this is going though, so thanks a lot for doing
it :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list (templating)
From: Jakub Narebski @ 2008-09-25 22:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Wincent Colaiuta, git
In-Reply-To: <20080925171029.GQ10360@machine.or.cz>
Dnia czwartek 25. września 2008 19:10, Petr Baudis napisał:
> On Thu, Sep 25, 2008 at 06:52:22PM +0200, Jakub Narebski wrote:
> >
> > I think that making gitweb use something like Gitweb::Template, where
> > action appearance is governed by templates, be it something like
> > git-for-each-ref --format or StGit *.tmpl files, or XSLT / XSL,
> > could be a good idea. But I think _that_ would require almost writing
> > from scratch, certainly making it long-term gitweb fork, perhaps even
> > with different name (and not residing inside git.git repository).
> >
> > We can discuss this idea here in this subthread. For example: do
> > create Gitweb::Template like HTML::Template or use Template Toolkit;
> > which parts put in template and which in "gitweb" driver, etc.
>
> Actually, my implementation works quite differently - the idea of the
> templates is that you just specify data from which files to show and
> whether to take them right away or tabulate them in some way - so it is
> something very abstract, and agnostic to _presentation_ layer, which is
> still provided by gitweb. An example of made-up template configuration
> file would look something like:
>
> [action "summary"]
> sections = metadata overview README shortlog forks
>
> [section "overview"]
> type = csv
> row = Project Title,(info.txt:title)
> row = Project Authors,(info.txt:authors)
> row = Bussiness Impact,(info.txt:bizimpact)
> row = Base Equation,[formula.png]
>
> [section "README"]
> type = html
> content = (README.html)
Gaaaah. I think this is heavy abuse of _configuration_ mini-language
git uses (extended ini-like syntax); it can be done, but it is IMVHO
on par of writing A.I. (Artificial Intelligence) in COBOL:
http://ars.userfriendly.org/cartoons/?id=20001018
--
Jakub Narebski
Poland
^ permalink raw reply
* git log and utf-u in filenames
From: Joey Hess @ 2008-09-25 21:50 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
Git, particularly git-log seems to not display utf-8 characters in filenames,
instead showing an escaped representation. On the other hand, commit messages,
as git-log(1) notes, are assumed to be utf-8, and the same utf-8 character
used in a commit message is not escaped, and displays ok.
Can anyone point me at the documentation for this utf-8 filename escaping,
assuming it's not a bug? And did earlier versions of git (circa 2006) perhaps
not do that escaping? I have code in ikiwiki that apparently used to work, but
is certianly not working with current git, due to this escaping.
Here's an example of the inconsistent handling of the same utf-8 character
("ö") in commit messages and filenames.
joey@kodama:~/tmp>mkdir utf8; cd utf8; git-init
Initialized empty Git repository in /home/joey/tmp/utf8/.git/
joey@kodama:~/tmp/utf8>echo hi > ö
joey@kodama:~/tmp/utf8>git add ö; git commit -m 'adding file: ö'
Created initial commit ee7d809: adding file: ö
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 "\303\266"
joey@kodama:~/tmp/utf-8>git log --stat
commit ee7d809d1811b1e1ad485ce3e7274316257029ae
Author: Joey Hess <joey@kodama.kitenet.net>
Date: Thu Sep 25 17:34:10 2008 -0400
adding file: ö
"\303\266" | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Introduce patch factorization in diffcore.
From: Yann Dirson @ 2008-09-25 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <20080925213819.27029.47944.stgit@gandelf.nowhere.earth>
---
diff-lib.c | 6 +-
diff.c | 5 +
diff.h | 3 +
diffcore-rename.c | 194 +++++++++++++++++++++++++++++++++++++++++++++++++++--
diffcore.h | 1
tree-diff.c | 4 +
6 files changed, 202 insertions(+), 11 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index ae96c64..dcc4c2c 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -179,7 +179,8 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
changed = ce_match_stat(ce, &st, ce_option);
if (!changed) {
ce_mark_uptodate(ce);
- if (!DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER))
+ if (!DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER) &&
+ !DIFF_OPT_TST(&revs->diffopt, FACTORIZE_RENAMES))
continue;
}
oldmode = ce->ce_mode;
@@ -310,7 +311,8 @@ static int show_modified(struct oneway_unpack_data *cbdata,
oldmode = old->ce_mode;
if (mode == oldmode && !hashcmp(sha1, old->sha1) &&
- !DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER))
+ !DIFF_OPT_TST(&revs->diffopt, FIND_COPIES_HARDER) &&
+ !DIFF_OPT_TST(&revs->diffopt, FACTORIZE_RENAMES))
return 0;
diff_change(&revs->diffopt, oldmode, mode,
diff --git a/diff.c b/diff.c
index 9053d4d..2315980 100644
--- a/diff.c
+++ b/diff.c
@@ -2599,6 +2599,11 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_OPT_SET(options, REVERSE_DIFF);
else if (!strcmp(arg, "--find-copies-harder"))
DIFF_OPT_SET(options, FIND_COPIES_HARDER);
+ else if (!strcmp(arg, "--factorize-renames")) {
+ DIFF_OPT_SET(options, FACTORIZE_RENAMES);
+ if (!options->detect_rename)
+ options->detect_rename = DIFF_DETECT_RENAME;
+ }
else if (!strcmp(arg, "--follow"))
DIFF_OPT_SET(options, FOLLOW_RENAMES);
else if (!strcmp(arg, "--color"))
diff --git a/diff.h b/diff.h
index 1ca4f46..7b862c6 100644
--- a/diff.h
+++ b/diff.h
@@ -64,6 +64,7 @@ typedef void (*diff_format_fn_t)(struct diff_queue_struct *q,
#define DIFF_OPT_RELATIVE_NAME (1 << 17)
#define DIFF_OPT_IGNORE_SUBMODULES (1 << 18)
#define DIFF_OPT_DIRSTAT_CUMULATIVE (1 << 19)
+#define DIFF_OPT_FACTORIZE_RENAMES (1 << 20)
#define DIFF_OPT_TST(opts, flag) ((opts)->flags & DIFF_OPT_##flag)
#define DIFF_OPT_SET(opts, flag) ((opts)->flags |= DIFF_OPT_##flag)
#define DIFF_OPT_CLR(opts, flag) ((opts)->flags &= ~DIFF_OPT_##flag)
@@ -219,6 +220,8 @@ extern void diffcore_std(struct diff_options *);
" -C detect copies.\n" \
" --find-copies-harder\n" \
" try unchanged files as candidate for copy detection.\n" \
+" --factorize_renames\n" \
+" factorize renames of all files of a directory.\n" \
" -l<n> limit rename attempts up to <n> paths.\n" \
" -O<file> reorder diffs according to the <file>.\n" \
" -S<string> find filepair whose only one side contains the string.\n" \
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 1b2ebb4..2757204 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -6,6 +6,8 @@
#include "diffcore.h"
#include "hash.h"
+#include <libgen.h>
+
/* Table of rename/copy destinations */
static struct diff_rename_dst {
@@ -52,6 +54,32 @@ static struct diff_rename_dst *locate_rename_dst(struct diff_filespec *two,
return &(rename_dst[first]);
}
+static struct diff_rename_dst *locate_rename_dst_dir(struct diff_filespec *dir)
+{
+ /* code mostly duplicated from locate_rename_dst - not sure we
+ * could merge them efficiently,though
+ */
+ int first, last;
+ int dirlength = strlen(dir->path);
+
+ first = 0;
+ last = rename_dst_nr;
+ while (last > first) {
+ int next = (last + first) >> 1;
+ struct diff_rename_dst *dst = &(rename_dst[next]);
+ int cmp = strncmp(dir->path, dst->two->path, dirlength);
+ if (!cmp)
+ return dst;
+ if (cmp < 0) {
+ last = next;
+ continue;
+ }
+ first = next+1;
+ }
+ /* not found */
+ return NULL;
+}
+
/* Table of rename/copy src files */
static struct diff_rename_src {
struct diff_filespec *one;
@@ -409,6 +437,130 @@ static void record_if_better(struct diff_score m[], struct diff_score *o)
m[worst] = *o;
}
+struct diff_dir_rename {
+ struct diff_filespec *one;
+ struct diff_filespec *two;
+ int discarded;
+ struct diff_dir_rename* next;
+};
+
+/*
+ * Marks as such file_rename if it is made uninteresting by dir_rename.
+ * Returns -1 if the file_rename is outside of the range in which given
+ * renames concerned by dir_rename are to be found (ie. end of loop),
+ * 0 otherwise.
+ */
+static int maybe_mark_uninteresting(struct diff_rename_dst* file_rename,
+ struct diff_dir_rename* dir_rename,
+ int one_len, int two_len) {
+ if (strncmp(file_rename->two->path,
+ dir_rename->two->path, two_len))
+ return -1;
+ if (strncmp(file_rename->pair->one->path,
+ dir_rename->one->path, one_len) ||
+ !basename_same(file_rename->pair->one, file_rename->two) ||
+ file_rename->pair->score != MAX_SCORE)
+ return 0;
+
+ file_rename->pair->uninteresting_rename = 1;
+ printf ("[DBG] %s* -> %s* makes %s -> %s uninteresting\n",
+ dir_rename->one->path, dir_rename->two->path,
+ file_rename->pair->one->path, file_rename->two->path);
+ return 0;
+}
+
+/*
+ * FIXME: we could optimize the 100%-rename case by preventing
+ * recursion to unfold what we know we would refold here.
+ * FIXME: do we want to replace linked list with sorted array ?
+ * FIXME: this prototype only handles renaming of dirs without
+ * a subdir.
+ * FIXME: leaks like hell.
+ * FIXME: ideas to evaluate a similarity score, anyone ?
+ * 10% * tree similarity + 90% * moved files similarity ?
+ */
+static struct diff_dir_rename* factorization_candidates = NULL;
+static void diffcore_factorize_renames(void)
+{
+ char buffer[PATH_MAX], one_parent_path[PATH_MAX], two_parent_path[PATH_MAX];
+ int i;
+
+ for (i = 0; i < rename_dst_nr; i++) {
+ if (!rename_dst[i].pair)
+ continue;
+ strcpy(buffer, rename_dst[i].pair->one->path);
+ strcpy(one_parent_path, dirname(buffer));
+ strcat(one_parent_path, "/");
+
+ struct diff_filespec* one_parent = alloc_filespec(one_parent_path);
+ fill_filespec(one_parent, null_sha1 /*FIXME*/, S_IFDIR);
+
+ if (!locate_rename_dst_dir(one_parent)) {
+ // one_parent_path is empty in result tree
+
+ // already considered ?
+ struct diff_dir_rename* seen;
+ for (seen=factorization_candidates; seen; seen = seen->next)
+ if (!strcmp(seen->one->path, one_parent_path)) break;
+ if (!seen) {
+ // record potential dir rename
+ strcpy(buffer, rename_dst[i].pair->two->path);
+ strcpy(two_parent_path, dirname(buffer));
+ strcat(two_parent_path, "/");
+
+ seen = xmalloc(sizeof(*seen));
+ seen->one = one_parent;
+ seen->two = alloc_filespec(two_parent_path);
+ fill_filespec(seen->two, null_sha1 /*FIXME*/, S_IFDIR);
+ seen->discarded = 0;
+ seen->next = factorization_candidates;
+ factorization_candidates = seen;
+ printf("[DBG] possible rename from %s to %s\n",
+ one_parent_path, two_parent_path);
+ continue;
+ }
+ if (seen->discarded)
+ continue;
+ // check that seen entry matches this rename
+ strcpy(buffer, rename_dst[i].pair->two->path);
+ strcpy(two_parent_path, dirname(buffer));
+ strcat(two_parent_path, "/");
+ if (strcmp(two_parent_path, seen->two->path)) {
+ printf("[DBG] discarding dir rename of %s, mixing %s and %s\n",
+ one_parent_path, two_parent_path, seen->two->path);
+ seen->discarded = 1;
+ }
+
+ /* all checks ok, we keep that entry */
+ }
+ }
+
+ // turn candidates into real renames
+ struct diff_dir_rename* candidate;
+ for (candidate=factorization_candidates; candidate; candidate = candidate->next) {
+ int two_idx, i, one_len, two_len;
+ if (candidate->discarded)
+ continue;
+
+ // any entry within candidate dst dir
+ two_idx = locate_rename_dst_dir(candidate->two) - rename_dst;
+
+ // now remove extraneous 100% files inside.
+ one_len = strlen(candidate->one->path);
+ two_len = strlen(candidate->two->path);
+ for (i = two_idx; i < rename_dst_nr; i++)
+ if (maybe_mark_uninteresting (rename_dst+i, candidate,
+ one_len, two_len) < 0)
+ break;
+ for (i = two_idx-1; i >= 0; i--)
+ if (maybe_mark_uninteresting (rename_dst+i, candidate,
+ one_len, two_len) < 0)
+ break;
+ }
+
+ return;
+}
+
void diffcore_rename(struct diff_options *options)
{
int detect_rename = options->detect_rename;
@@ -446,13 +598,22 @@ void diffcore_rename(struct diff_options *options)
p->one->rename_used++;
register_rename_src(p->one, p->score);
}
- else if (detect_rename == DIFF_DETECT_COPY) {
- /*
- * Increment the "rename_used" score by
- * one, to indicate ourselves as a user.
- */
- p->one->rename_used++;
- register_rename_src(p->one, p->score);
+ else {
+ if (detect_rename == DIFF_DETECT_COPY) {
+ /*
+ * Increment the "rename_used" score by
+ * one, to indicate ourselves as a user.
+ */
+ p->one->rename_used++;
+ register_rename_src(p->one, p->score);
+ }
+ if (DIFF_OPT_TST(options, FACTORIZE_RENAMES)) {
+ /* similarly, rename factorization needs to
+ * see all files from second tree
+ */
+ //p->two->rename_used++; // FIXME: would we need that ?
+ locate_rename_dst(p->two, 1);
+ }
}
}
if (rename_dst_nr == 0 || rename_src_nr == 0)
@@ -561,8 +722,24 @@ void diffcore_rename(struct diff_options *options)
/* At this point, we have found some renames and copies and they
* are recorded in rename_dst. The original list is still in *q.
*/
+
+ /* Now possibly factorize those renames and copies. */
+ if (DIFF_OPT_TST(options, FACTORIZE_RENAMES))
+ diffcore_factorize_renames();
+
outq.queue = NULL;
outq.nr = outq.alloc = 0;
+
+ // first, turn factorization_candidates into real renames
+ struct diff_dir_rename* candidate;
+ for (candidate=factorization_candidates; candidate; candidate = candidate->next) {
+ struct diff_filepair* pair;
+ if (candidate->discarded) continue;
+ pair = diff_queue(&outq, candidate->one, candidate->two);
+ pair->score = MAX_SCORE;
+ pair->renamed_pair = 1;
+ }
+
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
struct diff_filepair *pair_to_free = NULL;
@@ -577,7 +754,8 @@ void diffcore_rename(struct diff_options *options)
struct diff_rename_dst *dst =
locate_rename_dst(p->two, 0);
if (dst && dst->pair) {
- diff_q(&outq, dst->pair);
+ if (!dst->pair->uninteresting_rename)
+ diff_q(&outq, dst->pair);
pair_to_free = p;
}
else
diff --git a/diffcore.h b/diffcore.h
index 8ae3578..e4aa099 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -62,6 +62,7 @@ struct diff_filepair {
unsigned broken_pair : 1;
unsigned renamed_pair : 1;
unsigned is_unmerged : 1;
+ unsigned uninteresting_rename : 1;
};
#define DIFF_PAIR_UNMERGED(p) ((p)->is_unmerged)
diff --git a/tree-diff.c b/tree-diff.c
index 9f67af6..872f757 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -49,7 +49,9 @@ static int compare_tree_entry(struct tree_desc *t1, struct tree_desc *t2, const
show_entry(opt, "+", t2, base, baselen);
return 1;
}
- if (!DIFF_OPT_TST(opt, FIND_COPIES_HARDER) && !hashcmp(sha1, sha2) && mode1 == mode2)
+ if (!DIFF_OPT_TST(opt, FIND_COPIES_HARDER) &&
+ !DIFF_OPT_TST(opt, FACTORIZE_RENAMES) &&
+ !hashcmp(sha1, sha2) && mode1 == mode2)
return 0;
/*
^ permalink raw reply related
* [RFC PATCH] detection of directory renames
From: Yann Dirson @ 2008-09-25 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vfxojtr9t.fsf@gitster.siamese.dyndns.org>
This is a first very preliminar patch, mostly so people can comment
early on the big picture. It has a number of limitations, many but
not all already listed as FIXME's in the patch itself. If anything in
this patch seems so wrong it is not worth polishing it, it's the
perfect time to say so :)
The idea is to add a new pass to diffcore-rename, to group file renames
looking like a full directory move, and then to hide those file
renames which do not carry any additionnal information.
Here is a sample run:
$ ./git-diff-tree ee491 --factorize-renames -r
[DBG] possible rename from arm/ to bar/
[DBG] possible rename from ppc/ to moved/
[DBG] discarding dir rename of arm/, mixing moved/ and bar/
[DBG] ppc/* -> moved/* makes ppc/sha1ppc.S -> moved/sha1ppc.S uninteresting
[DBG] ppc/* -> moved/* makes ppc/sha1.c -> moved/sha1.c uninteresting
ee491a42190ec6e716f46a55fa0a7f4e307f1629
:040000 040000 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 R100 ppc/ moved/
:100644 100644 9e3ae038e818f4e21bc50f864fc5204f6fa44daa 9e3ae038e818f4e21bc50f864fc5204f6fa44daa R100 arm/sha1.c bar/sha1.c
:100644 100644 3952646349cf9d033177e69ba9433652a378c0e9 3952646349cf9d033177e69ba9433652a378c0e9 R100 arm/sha1.h bar/sha1.h
:100644 100644 c3c51aa4d487f2e85c02b0257c1f0b57d6158d76 c065eeef7d68ea91863431788e20cd814c5ac52c R099 ppc/sha1.h moved/sha1.h
:100644 100644 8c1cb99fb403875af85e4d1524d21f7eb818f59b 8c1cb99fb403875af85e4d1524d21f7eb818f59b R100 arm/sha1_arm.S moved/sha1_arm.S
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* mysterious error message
From: Tom Sgouros @ 2008-09-25 21:33 UTC (permalink / raw)
To: git
Hello all:
I receive the following error message when I try to do a 'git push':
tomfool@toms-box:hpl$ git push
updating 'refs/heads/master'
from ad4ae7925d3dd23798e7c5b733d2d8f930f7410f
to 5b5f5fae014a4f3535fa10b0f6e28b4bf3225dc3
Also local refs/remotes/origin/master
Generating pack...
Done counting 10 objects.
Deltifying 10 objects...
error: pack-objects died with strange error
unpack eof before pack header was fully read
ng refs/heads/master n/a (unpacker error)
error: failed to push to 'ssh://tomfool@as220.org/home/tomfool/hpl.git'
tomfool@toms-box:hpl$
I haven't been able to interpret this message, and haven't found it in
the documentation, and google has let me down, too. Can anyone tell me
what is causing it?
I'm a new git user, and this is a new git archive. I've successfully
done a couple of git push operations before, though. The connection I'm
making is via ssh. I'm working on a Mac OS X (10.4.9) machine over here
and the server to which I'm trying to push is a Linux box
(2.6.22-gentoo-r6).
Many thanks,
-tom
--
------------------------
tomfool at as220 dot org
http://sgouros.com
http://whatcheer.net
^ permalink raw reply
* [PATCH] git-gui: Help identify aspell version on Windows too
From: Gustaf Hendeby @ 2008-09-25 21:31 UTC (permalink / raw)
To: git; +Cc: spearce, Gustaf Hendeby
On windows, git gui fails to correctly extract the aspell version
(experienced with aspell version 0.50.3) due to scilent white space at
the end of the version string. Trim the obtained version string to
work around this.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
---
lib/spellcheck.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/spellcheck.tcl b/lib/spellcheck.tcl
index 78f344f..c8cc030 100644
--- a/lib/spellcheck.tcl
+++ b/lib/spellcheck.tcl
@@ -80,7 +80,7 @@ method _connect {pipe_fd} {
error_popup [strcat [mc "Unrecognized spell checker"] ":\n\n$s_version"]
return
}
- set s_version [string range $s_version 5 end]
+ set s_version [string range [string trim $s_version] 5 end]
regexp \
{International Ispell Version .* \(but really (Aspell .*?)\)$} \
$s_version _junk s_version
--
1.6.0.2.509.g4def
^ permalink raw reply related
* Re: [PATCH 0/5] git-gui: Support for "Locators" - address templates
From: Daniel Barkalow @ 2008-09-25 21:26 UTC (permalink / raw)
To: pasky; +Cc: git, spearce
In-Reply-To: <20080924221249.037449176@suse.cz>
On Thu, 25 Sep 2008, pasky@suse.cz wrote:
> This patch allows "locators" to be configured and used in the GUI,
> basically as URL templates the input string is subsituted into.
> The default operation of git-gui is not much affected (only some
> labels change to be less confusing).
>
> This is aimed mainly at corporate Git deployments - the integrator
> might want to configure the central corporate repository store as
> the default locator so that people do not need to type the same
> URL over and over but can instead just type the repository name
> on the server. Or avid repo.or.cz users might set up a 'repo'
> locator pointing at 'git://repo.or.cz/%s'.
Can this be set up to use the "url.<base>.insteadOf" configuration? Part
of my goal with that feature was to make it easy for me to reference
projects on my work's central repository store. That is, put in your
~/gitconfig:
[url "git://repo.or.cz/"]
insteadOf = repo:
And "git clone repo:alt-git" works.
It'd be nice to share the config somehow so that the same settings can be
used both in git-gui and on the command line. (I wrote the code so that a
user can swap patterns of URLs work for other people but aren't good for
that particular user, but it also applies to user-provided shorthand
URLs.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2008-09-25 21:23 UTC (permalink / raw)
To: Pedro Melo; +Cc: git, Petr Baudis
In-Reply-To: <BC7F2CB5-A31A-40C8-A22F-F0AAECB091C6@simplicidade.org>
Pedro Melo wrote:
> While researching HTTP::Engine (I use Catalyst and they where talking
> about moving to it), I also came across a new HTTP layer, called
> Mango. Also on CPAN, so same conditional code applies.
>
> Right now, I'm not sure what the Cat team is thinking, HTTP::Engine or
> Mango, or other, but I suggest the use of the stack then end up
> choosing. The Cat team has a very good test-driven way-of-doing
> things, and the modules they use tend to stabilize very quickly.
I think I'll wait for results of your/Catalyst research then... ;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH RFC 3/6] Docs: send-email usage text much sexier
From: Michael Witten @ 2008-09-25 20:44 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1222375476-32911-2-git-send-email-mfwitten@mit.edu>
All of the descriptions are aligned, and no
line is greater than 78 columns.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 94 +++++++++++++++++++++++++++------------------------
1 files changed, 50 insertions(+), 44 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index d390364..b86a3f3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -40,74 +40,80 @@ sub usage {
print <<EOT;
git send-email [options] <file | directory>...
Options:
- --from Specify the "From:" line of the email to be sent.
+ --from Specify the "From:" line of the email to be sent.
- --to Specify the primary "To:" line of the email.
+ --to Specify the primary "To:" line of the email.
- --cc Specify an initial "Cc:" list for the entire series
- of emails.
+ --cc Specify an initial "Cc:" list for the entire series
+ of emails.
- --cc-cmd Specify a command to execute per file which adds
- per file specific cc address entries
+ --cc-cmd Specify a command to execute per file which adds
+ per file specific cc address entries
- --bcc Specify a list of email addresses that should be Bcc:
- on all the emails.
+ --bcc Specify a list of email addresses that should be
+ Bcc: on all the emails.
- --compose Use \$GIT_EDITOR, core.editor, \$EDITOR, or \$VISUAL to edit
- an introductory message for the patch series.
+ --compose Use \$GIT_EDITOR, core.editor, \$EDITOR, or
+ \$VISUAL to edit an introductory message for the
+ patch series.
- --subject Specify the initial "Subject:" line.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+ --subject Specify the initial "Subject:" line. Only necessary
+ if --compose is also set. If --compose is not set,
+ this will be prompted for.
- --in-reply-to Specify the first "In-Reply-To:" header line.
- Only used if --compose is also set. If --compose is not
- set, this will be prompted for.
+ --in-reply-to Specify the first "In-Reply-To:" header line. Only
+ used if --compose is also set. If --compose is not
+ set, this will be prompted for.
- --[no-]chain-reply-to If set, the replies will all be to the previous
- email sent, rather than to the first email sent.
- Defaults to on.
+ --[no-]chain-reply-to If set, the replies will all be to the previous
+ email sent, rather than to the first email sent.
+ Defaults to on.
--[no-]signed-off-by-cc Automatically add email addresses that appear in
- Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
+ Signed-off-by: or Cc: lines to the cc: list.
+ Defaults to on.
- --identity The configuration identity, a subsection to prioritise over
- the default section.
+ --identity The configuration identity to use.
- --smtp-server If set, specifies the outgoing SMTP server to use.
- Defaults to localhost. Port number can be specified here with
- hostname:port format or by using --smtp-server-port option.
+ --smtp-server If set, specifies the outgoing SMTP server to use.
+ Defaults to localhost. Port number can be
+ specified here with hostname:port format or by
+ using --smtp-server-port option.
- --smtp-server-port Specify a port on the outgoing SMTP server to connect to.
+ --smtp-server-port Specify a port on the outgoing SMTP server to
+ connect to.
- --smtp-user The username for SMTP-AUTH.
+ --smtp-user The username for SMTP-AUTH.
- --smtp-pass The password for SMTP-AUTH.
+ --smtp-pass The password for SMTP-AUTH.
- --smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for SSL.
- Any other value disables the feature.
+ --smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for
+ SSL. Any other value disables the feature.
- --smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
+ --smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
- --suppress-cc Suppress the specified category of auto-CC. The category
- can be one of 'author' for the patch author, 'self' to
- avoid copying yourself, 'sob' for Signed-off-by lines,
- 'cccmd' for the output of the cccmd, or 'all' to suppress
- all of these.
+ --suppress-cc Suppress the specified category of auto-CC. The
+ category can be one of 'author' for the patch
+ author, 'self' to avoid copying yourself, 'sob'
+ for Signed-off-by lines, 'cccmd' for the output
+ of the cccmd, or 'all' to suppress all of these.
+ (Note: Linus uses 'self' and 'sob' interchangeably)
- --[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
+ --[no-]suppress-from Suppress sending emails to yourself. Defaults to
+ off.
- --[no-]thread Specify that the "In-Reply-To:" header should be set on all
- emails. Defaults to on.
+ --[no-]thread Specify that the "In-Reply-To:" header should be
+ set on all emails. Defaults to on.
- --quiet Make git-send-email less verbose. One line per email
- should be all that is output.
+ --quiet Make git-send-email less verbose. One line per
+ email should be all that is output.
- --dry-run Do everything except actually send the emails.
+ --dry-run Do everything except actually send the emails.
- --envelope-sender Specify the envelope sender used to send the emails.
+ --envelope-sender Specify the envelope sender used to send the
+ emails.
- --no-validate Don't perform any sanity checks on patches.
+ --no-validate Don't perform any sanity checks on patches.
EOT
exit(1);
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 2/6] Docs: send-email usage cleanup 1
From: Michael Witten @ 2008-09-25 20:44 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1222375476-32911-1-git-send-email-mfwitten@mit.edu>
The usage text mainly uses spaces to layout the text,
so I replaced the few tabs that exit with spaces.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
git-send-email.perl | 36 ++++++++++++++++++------------------
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9f56162..d390364 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -51,25 +51,25 @@ Options:
per file specific cc address entries
--bcc Specify a list of email addresses that should be Bcc:
- on all the emails.
+ on all the emails.
--compose Use \$GIT_EDITOR, core.editor, \$EDITOR, or \$VISUAL to edit
- an introductory message for the patch series.
+ an introductory message for the patch series.
--subject Specify the initial "Subject:" line.
Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+ is not set, this will be prompted for.
--in-reply-to Specify the first "In-Reply-To:" header line.
Only used if --compose is also set. If --compose is not
- set, this will be prompted for.
+ set, this will be prompted for.
--[no-]chain-reply-to If set, the replies will all be to the previous
- email sent, rather than to the first email sent.
- Defaults to on.
+ email sent, rather than to the first email sent.
+ Defaults to on.
--[no-]signed-off-by-cc Automatically add email addresses that appear in
- Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
+ Signed-off-by: or Cc: lines to the cc: list. Defaults to on.
--identity The configuration identity, a subsection to prioritise over
the default section.
@@ -85,29 +85,29 @@ Options:
--smtp-pass The password for SMTP-AUTH.
--smtp-encryption Specify 'tls' for STARTTLS encryption, or 'ssl' for SSL.
- Any other value disables the feature.
+ Any other value disables the feature.
--smtp-ssl Synonym for '--smtp-encryption=ssl'. Deprecated.
--suppress-cc Suppress the specified category of auto-CC. The category
- can be one of 'author' for the patch author, 'self' to
- avoid copying yourself, 'sob' for Signed-off-by lines,
- 'cccmd' for the output of the cccmd, or 'all' to suppress
- all of these.
+ can be one of 'author' for the patch author, 'self' to
+ avoid copying yourself, 'sob' for Signed-off-by lines,
+ 'cccmd' for the output of the cccmd, or 'all' to suppress
+ all of these.
--[no-]suppress-from Suppress sending emails to yourself. Defaults to off.
--[no-]thread Specify that the "In-Reply-To:" header should be set on all
- emails. Defaults to on.
+ emails. Defaults to on.
- --quiet Make git-send-email less verbose. One line per email
- should be all that is output.
+ --quiet Make git-send-email less verbose. One line per email
+ should be all that is output.
- --dry-run Do everything except actually send the emails.
+ --dry-run Do everything except actually send the emails.
- --envelope-sender Specify the envelope sender used to send the emails.
+ --envelope-sender Specify the envelope sender used to send the emails.
- --no-validate Don't perform any sanity checks on patches.
+ --no-validate Don't perform any sanity checks on patches.
EOT
exit(1);
--
1.6.0.2.302.ge6cbd1
^ permalink raw reply related
* [PATCH RFC 6/6] Docs: send-email: --chain_reply_to -> --[no-]chain-reply-to
From: Michael Witten @ 2008-09-25 20:44 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <1222375476-32911-5-git-send-email-mfwitten@mit.edu>
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index fe53e9b..76a525a 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -228,7 +228,7 @@ sendemail.bcc::
Email address (or alias) to always bcc.
sendemail.chainreplyto::
- Boolean value specifying the default to the '--chain_reply_to'
+ Boolean value specifying the default to the '--[no-]chain-reply-to'
parameter.
sendemail.smtpserver::
--
1.6.0.2.302.ge6cbd1
^ 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