* Re: On Tabs and Spaces
From: Jan-Benedict Glaw @ 2007-10-16 18:34 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jeffrey C. Ollie, Adam Piatyszek, Lars Hjemli, Michael Witten,
git
In-Reply-To: <4714F3A2.3080103@op5.se>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Tue, 2007-10-16 19:23:46 +0200, Andreas Ericsson <ae@op5.se> wrote:
> Jeffrey C. Ollie wrote:
> > On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:
> > > And if one change the tab size, it will result in a messy alignment in
> > > line 5.
> >
> > Which is why one should never should change the tab size from anything
> > but 8.
>
> I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's
You fir 768 lines of text and 1024 chars per line to such a small
display and still argue about too large tabs?
SCNR, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck.
the second : Langsam möchte ich mal wieder weiterträumen können.
-- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-16 18:51 UTC (permalink / raw)
To: Jan-Benedict Glaw
Cc: Jeffrey C. Ollie, Adam Piatyszek, Lars Hjemli, Michael Witten,
git
In-Reply-To: <20071016183401.GR16774@lug-owl.de>
Jan-Benedict Glaw wrote:
> On Tue, 2007-10-16 19:23:46 +0200, Andreas Ericsson <ae@op5.se> wrote:
>> Jeffrey C. Ollie wrote:
>>> On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:
>>>> And if one change the tab size, it will result in a messy alignment in
>>>> line 5.
>>> Which is why one should never should change the tab size from anything
>>> but 8.
>> I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's
>
> You fir 768 lines of text and 1024 chars per line to such a small
> display and still argue about too large tabs?
>
If by "char" you mean "pixel", then yes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: On Tabs and Spaces
From: Jari Aalto @ 2007-10-16 17:06 UTC (permalink / raw)
To: git
In-Reply-To: <B2F6DB0C-4EFE-4C56-8E7A-31820320CA02@mit.edu>
* Tue 2007-10-16 Michael Witten <mfwitten AT MIT.EDU>
* Message-Id: B2F6DB0C-4EFE-4C56-8E7A-31820320CA02 AT mit.edu
> On 16 Oct 2007, at 11:26:07 AM, Jeffrey C. Ollie wrote:
>
>> Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-
>> mode
>> nil)". This will force emacs to always use spaces to indent.
>
> However, 8 spaces per tab is a lot of wasted
> information to be bandying about.
Spaces are guaranteed to interpreted correctly in all environments. TABs
are the source of too many problems.
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Re: git-merge performance
From: Andrew Morton @ 2007-10-16 18:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4714F612.2010905@op5.se>
On Tue, 16 Oct 2007 19:34:10 +0200
Andreas Ericsson <ae@op5.se> wrote:
> Andrew Morton wrote:
> > My git-pulling script (git-1.4.2) seems to have got quite a bit slower
> > since the post-2.6.23 patchflood. I just did a bit of poking and it's
> > git-merge which is taking most of the time.
> >
>
> That's odd. If it had been the remote fetching it would have been
> understandable. Is this also happening with more recent gits? I know there
> are some significant performance-improvements in 1.5.3.4 (or below).
>
1.5.0 is no faster, but 1.5.3 appears to be seven times quicker. Neato.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Christopher Faylor @ 2007-10-16 18:06 UTC (permalink / raw)
To: 'Andreas Ericsson', barkalow, raa.lkml, make-w32, git,
'Eli Zaretskii', Dave Korn, Joh
In-Reply-To: <03f401c81010$d8833de0$2e08a8c0@CAM.ARTIMI.COM>
On Tue, Oct 16, 2007 at 05:23:11PM +0100, Dave Korn wrote:
>On 16 October 2007 16:56, David Brown wrote:
>
>> On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:
>>
>>> On the other hand, what packages have 100K files? If there's only one
>>> -- the Linux kernel -- then I think this kind of performance is for
>>> all practical purposes unimportant on Windows, because while it is
>>> reasonable to assume that someone would like to use git on Windows,
>>> assuming that someone will develop the Linux kernel on Windows is --
>>> how should I put it -- _really_ far-fetched ;-)
>>
>> Oh, I wish others could think this clearly. Quoting a serious line off of
>> a task list at an unnamed company:
>>
>> - Make Linux kernel compile under windows.
>>
>> I don't think it will move past just being a wish list item, but there seem
>> to be people that think it should be done.
>>
>> Admittedly, they don't want developers doing it on windows, but want to
>> integrate kernel building into a windows-heavy build and release process.
>
> Do that kind of thing here all the time, hence my previous post. Apart from
>the netfilter stuff with the filenames-that-match-in-all-but-case, no real
>problems, took me a couple of hours one afternoon.
Ditto.
Coincidentially enough this is the reason I wrote managed mode for cygwin's
mount.
But, we're pretty far off-topic aren't we?
cgf
^ permalink raw reply
* Re: [PATCH 04/25] Rework make_usage to print the usage message immediately
From: Alex Riesen @ 2007-10-16 17:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Shawn O. Pearce
In-Reply-To: <1192523998-19474-4-git-send-email-madcoder@debian.org>
Pierre Habouzit, Tue, Oct 16, 2007 10:39:37 +0200:
> From: Alex Riesen <raa.lkml@gmail.com>
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
> parse-options.c | 48 ++++++++++++++++++++++--------------------------
> 1 files changed, 22 insertions(+), 26 deletions(-)
Got it three times: you put git@kernel.org into To: and Cc:
Why stderr, BTW? For instance, the output from "git help" is on
stdout. To be fair, I don't know why it is stdout there either.
^ permalink raw reply
* [PATCH] GIT home page. Mentioning that Cogito is no longer maintained.
From: Paolo Ciarrocchi @ 2007-10-16 17:54 UTC (permalink / raw)
To: pasky, git
As discussed on the git mailing list
http://marc.info/?l=git&m=119252168629733&w=2
it seems to be a good idea to mention on the git home page that cogito
is no longer maintained.
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
index.html | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/index.html b/index.html
index 340aee0..5d14acf 100644
--- a/index.html
+++ b/index.html
@@ -289,12 +289,12 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
<dt id="cogito">Cogito</dt>
<dd>
<a href="http://git.or.cz/cogito/">Cogito</a>
-is a popular version control system on top of Git.
-It aims at seamless user interface and ease of use, providing
-generally smoother user experience than the "raw" Git interface
-and indeed also many other version control systems. However, it
-also lacks many advanced capabilities of Git and is currently
-being slowly phased out.</dd>
+ Cogito was a popular version control system on top of Git. It aims
+at seamless user interface and ease of use, providing generally
+smoother user experience than the "raw" Git interface and indeed also
+many other version control systems. However, it also lacks many
+advanced capabilities of Git and is not actively maintained any
+longer.</dd>
<dt id="stgit">StGIT</dt>
<dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Sam Ravnborg @ 2007-10-16 17:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Michael Witten, Shawn O. Pearce, git
In-Reply-To: <4714F2CA.5000509@op5.se>
General comment about the <tab> versus spaces debate.
The root problem is stupid editors that does not show when a tab is used
and when spaces are used.
So people continue to mix tabs and spaces.
In linux people generally think that 8 aligned spaces equal a tab
which is IMHO stupid.
Tabs should be used for indent and not general alignment.
Consider:
<tab>if (some long condition that
<tab>....&& spans two lines) {
<tab><tab>my_private_printf("bla bla bla"
<tab><tab>.................."more bla bla\n");
<tab><tab>}
This will look good and align "more bla bla\n" as
intended no matter your tab setting.
But replacing the 8 spaces with a tab will
cause it to look bad.
And using tabs let me use the tabsetting I like (8) and other
use the tab setting they like (2,3,4,5,6,7) and all is good.
And why a tab is 8 spaces and in considered good.
Thats to teach people to write small independent functions
that does _one_ thing and does it well.
Mega functions with 6 times indent or more usually needs to
be breaked up anyway.
Sam
^ permalink raw reply
* Re: Some git mv questions
From: Linus Torvalds @ 2007-10-16 17:34 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jan Wielemaker, git list
In-Reply-To: <8c5c35580710160905v69787856m7ed11b037c1adef1@mail.gmail.com>
On Tue, 16 Oct 2007, Lars Hjemli wrote:
> On 10/16/07, Jan Wielemaker <wielemak@science.uva.nl> wrote:
> > * On a somewhat bigger test I moved a large directory using
> > "git mv dir newdir" (where newdir is an existing directory).
> > Now "git status" gives a lot of new and deleted files!?
>
> You could try to adjust diff.renameLimit in .git/config
Yes. The default rename limit I did has turned out to be a disaster. It's
quite common to have more than a 100x100 matrix of deleted files.
For people with any kind of beefy hardware, I'd just suggest doing a
git config --global diff.renamelimit 0
which disables the rename limiting entirely.
There's a related (embarrassing) problem, namely that I think that the
current released versions (1.5.3.3 and 1.5.3.4) don't honor the
renamelimit configuration for merging, so if you do merges across renames
with changes to the renamed files, you need to use either an older git
that didn't have the rename limit at all (nor any of the speed-ups) or you
need to use current git from the 'master' branch.
Linus
^ permalink raw reply
* Re: git-merge performance
From: Andreas Ericsson @ 2007-10-16 17:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20071016101748.ff132685.akpm@linux-foundation.org>
Andrew Morton wrote:
> My git-pulling script (git-1.4.2) seems to have got quite a bit slower
> since the post-2.6.23 patchflood. I just did a bit of poking and it's
> git-merge which is taking most of the time.
>
That's odd. If it had been the remote fetching it would have been
understandable. Is this also happening with more recent gits? I know there
are some significant performance-improvements in 1.5.3.4 (or below).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-16 17:23 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: Adam Piatyszek, Lars Hjemli, Michael Witten, git
In-Reply-To: <1192548367.3821.4.camel@lt21223.campus.dmacc.edu>
Jeffrey C. Ollie wrote:
> On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:
>> And if one change the tab size, it will result in a messy alignment in
>> line 5.
>
> Which is why one should never should change the tab size from anything
> but 8.
>
I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's
not as if I've got much choice if I want to be able to see anything on
the screen. Some whitespace-damaged places look ugly, but it's usually
not too bad.
>> I guess there is no ideal solution for this in Emacs.
>
> Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-mode
> nil)". This will force emacs to always use spaces to indent.
>
... but don't do this when hacking on Linux or git. Thanks
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Nicolas Pitre @ 2007-10-16 17:21 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, René Scharfe, git, Shawn O. Pearce
In-Reply-To: <20071016165319.GC13946@artemis.corp>
On Tue, 16 Oct 2007, Pierre Habouzit wrote:
> On Tue, Oct 16, 2007 at 04:44:44PM +0000, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 16 Oct 2007, Ren? Scharfe wrote:
> >
> > > Pierre Habouzit schrieb:
> > > > This bit is to allow to aggregate options with arguments together when
> > > > the argument is numeric.
> > > >
> > > > +#if 0
> > > > + /* can be used to understand -A1B1 like -A1 -B1 */
> > > > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > > > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > > > + return 0;
> > > > + }
> > > > +#endif
> > >
> > > I don't like it, it complicates number options with unit suffixes (e.g.
> > > --windows-memory of git-pack-objects).
> >
> > Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
> >
> > Remember: this is a special case for OPT_INTEGER. Nothing to do with
> > OPT_SIZE, which you'd probably implement as a callback.
>
> Yeah but the point is that you can't migrate an option currently being
> an integer to an OPT_SIZE because of that (see my other mail). Meaning
> that once an argument is of type OPT_INTEGER you can't change it's type
> in the future _AT ALL_ without breaking backward compatibility badly.
> I'd say it's a rather sucky design.
And what's the point of supporting so criptic arguments?
It doesn't have to go that far.
Nicolas
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-16 17:20 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, git
In-Reply-To: <11F85069-1013-4685-9D56-C53F0F8231BF@MIT.EDU>
Michael Witten wrote:
> On 16 Oct 2007, at 3:04:21 AM, Shawn O. Pearce wrote:
>
>> The C code is all tabs, with the tabs set at 8 spaces, but the
>> actual tab width isn't too important here as we never use the tab
>> for alignment beyond the left indent.
>
> Consider this from diff-lib.c:
>
>> /* A file entry went away or appeared */
>> static void diff_index_show_file(struct rev_info *revs,
>> const char *prefix,
>> struct cache_entry *ce,
>> unsigned char *sha1, unsigned int mode)
>> {
>> diff_addremove(&revs->diffopt, prefix[0], ntohl(mode),
>> sha1, ce->name, NULL);
>> }
>
> There are mixed tabs and spaces for alignment.
>
Function declarations don't count ;-)
> I suppose I'll be fine if I just set tab widths to 8.
> But 8 spaces! Good Lord. ;-)
>
> I really hate tabs.
>
Well, using hard tabs is the only way we can let everyone have
different levels of indentation while still having things look
sort of sane.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] tail -n not supported in all OSs
From: Johannes Schindelin @ 2007-10-16 17:19 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
Hi,
On Tue, 16 Oct 2007, Jari Aalto wrote:
>
> SunOS/Solaris tail(1) does not support option '-n'.
This belongs into the commit message.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-commit.sh: Remove option -n from tail
From: Johannes Schindelin @ 2007-10-16 17:18 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <1192553837-18302-3-git-send-email-jari.aalto@cante.net>
Hi,
On Tue, 16 Oct 2007, Jari Aalto wrote:
> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Rationale?
And also, can't this wait for the builtin-commit, which will solve this
problem?
Ciao,
Dscho
^ permalink raw reply
* git-merge performance
From: Andrew Morton @ 2007-10-16 17:17 UTC (permalink / raw)
To: git
My git-pulling script (git-1.4.2) seems to have got quite a bit slower
since the post-2.6.23 patchflood. I just did a bit of poking and it's
git-merge which is taking most of the time.
Using git-watchdog as an example:
box:/usr/src/git26> cat .git/branches/git-watchdog
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git
box:/usr/src/git26> git reset --hard origin
box:/usr/src/git26> git fetch git-watchdog
box:/usr/src/git26> time git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
Automatic merge failed; fix conflicts and then commit the result.
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null 47.03s user 26.53s system 97% cpu 1:15.67 total
Try git-md-accel:
box:/usr/src/git26> cat .git/branches/git-md-accel
git://lost.foo-projects.org/~dwillia2/git/iop#md-for-linus
box:/usr/src/git26> time git reset --hard origin
git reset --hard origin 0.51s user 0.11s system 100% cpu 0.615 total
box:/usr/src/git26> time git fetch git-md-accel
git fetch git-md-accel 0.12s user 0.05s system 11% cpu 1.379 total
box:/usr/src/git26> time git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
Automatic merge failed; fix conflicts and then commit the result.
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null 42.52s user 24.18s system 96% cpu 1:08.93 total
And git-unionfs:
box:/usr/src/git26> cat .git/branches/git-unionfs
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ezk/unionfs.git
box:/usr/src/git26> time git reset --hard origin
git reset --hard origin 0.52s user 0.09s system 100% cpu 0.611 total
box:/usr/src/git26> time git fetch git-unionfs
git fetch git-unionfs 0.16s user 0.03s system 8% cpu 2.285 total
box:/usr/src/git26> time git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
Automatic merge went well; stopped before committing as requested
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null 42.81s user 24.86s system 96% cpu 1:09.98 total
Everything is in pagecache, and I just did git-repack -a -d;git
prune;git-fsck-objects --full.
Pulling 70-80 trees at a minute and a half each gets a bit dull ;)
^ permalink raw reply
* Re: [PATCH] tail -n not supported in all OSs
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-10-16 17:16 UTC (permalink / raw)
To: jari.aalto; +Cc: git, yoshfuji
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
In article <1192553837-18302-1-git-send-email-jari.aalto@cante.net> (at Tue, 16 Oct 2007 19:57:14 +0300), Jari Aalto <jari.aalto@cante.net> says:
>
> SunOS/Solaris tail(1) does not support option '-n'. The
> following patches change occurrances of:
>
> tail -n <N>
>
> to
>
> tail <N>
You should say "tail -<N>".
--yoshfuji
^ permalink raw reply
* Re: [PATCH] tail -n not supported in all OSs
From: David Brown @ 2007-10-16 17:12 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
On Tue, Oct 16, 2007 at 07:57:14PM +0300, Jari Aalto wrote:
>
>SunOS/Solaris tail(1) does not support option '-n'. The
>following patches change occurrances of:
>
> tail -n <N>
>
>to
>
> tail <N>
On Linux, I get
tail: cannot open `1' for reading: No such file or directory
Did you want
tail -<N>
David
^ permalink raw reply
* [PATCH] tail -n not supported in all OSs
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git
SunOS/Solaris tail(1) does not support option '-n'. The
following patches change occurrances of:
tail -n <N>
to
tail <N>
---------------------------------------------------------------------
REFERENCES:
User Commands TAIL(1)
NAME
tail - output the last part of files
SYNOPSIS
tail [OPTION]... [FILE]...
- - -
$ uname -a
SunOS host 5.9 Generic_118558-35 sun4u sparc SUNW,Serverblade1
$ echo | tail -n 1
usage: tail [+/-[n][lbc][f]] [file]
tail [+/-[n][l][r|f]] [file]
^ permalink raw reply
* [PATCH] git-am.sh: Remove option -n from tail
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
git-am.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b02ae6a..09a991c 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -2,6 +2,8 @@
#
# Copyright (c) 2005, 2006 Junio C Hamano
+TAIL="tail"
+
USAGE='[--signoff] [--dotest=<dir>] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
@@ -321,7 +323,7 @@ do
LAST_SIGNED_OFF_BY=`
sed -ne '/^Signed-off-by: /p' \
"$dotest/msg-clean" |
- tail -n 1
+ $TAIL 1
`
ADD_SIGNOFF=`
test "$LAST_SIGNED_OFF_BY" = "$SIGNOFF" || {
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* [PATCH] git-rebase--interactive.sh: Remove option -n from tail
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
In-Reply-To: <1192553837-18302-3-git-send-email-jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
git-rebase--interactive.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 050140d..58e164c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -10,6 +10,8 @@
# The original idea comes from Eric W. Biederman, in
# http://article.gmane.org/gmane.comp.version-control.git/22407
+TAIL="tail"
+
USAGE='(--continue | --abort | --skip | [--preserve-merges] [--verbose]
[--onto <branch>] <upstream> [<branch>])'
@@ -204,7 +206,7 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
- < "$SQUASH_MSG" | tail -n 1)+1))
+ < "$SQUASH_MSG" | $TAIL 1)+1))
echo "# This is a combination of $COUNT commits."
sed -n "2,\$p" < "$SQUASH_MSG"
else
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* [PATCH] git-commit.sh: Remove option -n from tail
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
In-Reply-To: <1192553837-18302-2-git-send-email-jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
git-commit.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..637cf48 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,6 +3,8 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
+TAIL="tail"
+
USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [--template <file>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -442,10 +444,10 @@ t)
s/^/Signed-off-by: /
')
blank_before_signoff=
- tail -n 1 "$GIT_DIR"/COMMIT_EDITMSG |
+ $TAIL 1 "$GIT_DIR"/COMMIT_EDITMSG |
grep 'Signed-off-by:' >/dev/null || blank_before_signoff='
'
- tail -n 1 "$GIT_DIR"/COMMIT_EDITMSG |
+ $TAIL 1 "$GIT_DIR"/COMMIT_EDITMSG |
grep "$sign"$ >/dev/null ||
printf '%s%s\n' "$blank_before_signoff" "$sign" \
>>"$GIT_DIR"/COMMIT_EDITMSG
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* Re: How to Import a bitkeeper repo into git
From: Andreas Ericsson @ 2007-10-16 17:05 UTC (permalink / raw)
To: Marco Costalba; +Cc: pete, Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <e5bfff550710160211g5dbfa7fai95386b173edc45c3@mail.gmail.com>
Marco Costalba wrote:
> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
>> Would it be worthwhile
>> to install Qt4 from src and try to use qgit-2.0?
>>
>
> Yes it is. There are a lot of new featrures, is almost as stable as
> the previous and if you are interested in file history (annotations)
> in qgit-2.0 this feature has been greatly speeded up.
>
The only thing I really, really, really don't like about qgit4 is the
fact that it fudges up the commit-message. I've been trying for two
days to get rid of the HTML output, but I just can't get it done
without the signed-off-by email being enclosed in <> tags.
Marco, is there any chance you could make the old commit-message view
an option? Especially, the subject line should really, really be at the
bottom, with the rest of the message-text (although I liked the other
view without the colored box a lot more). The little arrows in the
commit window are also fairly annoying, as one quite quickly understands
that up-/down-arrows work much better for that sort of stuff anyway.
I'm at my wits end wrt c++ and qt, and can't for the life of me think of
how to make it an option :(
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: René Scharfe @ 2007-10-16 17:04 UTC (permalink / raw)
To: Johannes Schindelin, Pierre Habouzit; +Cc: git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0710161742040.25221@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 16 Oct 2007, Ren? Scharfe wrote:
>
>> Pierre Habouzit schrieb:
>>> This bit is to allow to aggregate options with arguments together when
>>> the argument is numeric.
>>>
>>> +#if 0
>>> + /* can be used to understand -A1B1 like -A1 -B1 */
>>> + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
>>> + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
>>> + return 0;
>>> + }
>>> +#endif
>> I don't like it, it complicates number options with unit suffixes (e.g.
>> --windows-memory of git-pack-objects).
>
> Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
>
> Remember: this is a special case for OPT_INTEGER. Nothing to do with
> OPT_SIZE, which you'd probably implement as a callback.
You mean I need to take a look at the actual patch to get a bit more
context? ;-) Now that I did, I retract my comment.
Pierre, FYI: I didn't see your patches coming through the NNTP gateway
of gmane.org, which is my way of reading this list. Its web interface
doesn't show them, either, so it's probably not caused by my news reader.
René
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Daniel Barkalow @ 2007-10-16 17:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eli Zaretskii, raa.lkml, ae, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161335260.25221@racer.site>
On Tue, 16 Oct 2007, Johannes Schindelin wrote:
> Hi,
>
> [culled make-w32, as per explicit request]
>
> On Tue, 16 Oct 2007, Eli Zaretskii wrote:
>
> > > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
> > > From: Daniel Barkalow <barkalow@iabervon.org>
> > > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se,
> > > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
> > >
> > > Ah, that's helpful. We don't actually care too much about the
> > > particular info in stat; we just want to know quickly if the file has
> > > changed, so we can hash only the ones that have been touched and get
> > > the actual content changes.
> >
> > As I wrote in my other message, using native APIs improves performance
> > by at least a factor of two.
>
> Somehow this does not appeal to my "portability is good" side. You know,
> if we had to do such trickeries for every platform we support, we'd soon
> be as big as Subversion *cough*.
I think that it would be a worthwhile project, from the point of view of
making the code easier to follow and making the internal APIs clearer, to
organize git's source to abstract the object database to read_sha1_file(),
has_sha1_file(), hash_sha1_file(), and write_sha1_file() as the arbiters
of what is in the local database (with other functions public as support
for over-the-wire protocols, which may, by not-really-coincidence, by used
for local storage as well); then Windows could have an entirely different
storage mechanism that doesn't rely on filesystem metadata speed.
It would also be worthwhile to untangle the index's stat cache aspects and
its tree-object-related aspects, so that there can be a platform- and
repository-specific concept of how to handle the working area, and then
Windows could do different stuff for the default case of setting up a
directory on the local filesystem.
-Daniel
*This .sig left intentionally blank*
^ 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