* Re: [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Johannes Schindelin @ 2007-05-09 11:04 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <0056A63A-D511-4FDD-82A6-A13B06E237E9@zib.de>
Hi,
On Wed, 9 May 2007, Steffen Prohaska wrote:
> The old implementation executed 'cvs status' for each file touched by
> the patch to be applied.
I did not follow development of that script closely, but could it be that
this is a safety valve, to make it unlikely to commit something which was
changed by somebody else in the meantime?
Ciao,
Dscho
^ permalink raw reply
* Re: quick bare clones taking longer?
From: Johannes Schindelin @ 2007-05-09 11:09 UTC (permalink / raw)
To: David Miller; +Cc: git
In-Reply-To: <20070509.020916.80034730.davem@davemloft.net>
Hi,
On Wed, 9 May 2007, David Miller wrote:
> master.kernel.org just upgraded to git-1.5.1.4 and I notice
> that doing something like this:
>
> git clone --bare -n -l -s ../torvalds/linux-2.6.git test-2.6.git
>
> is no longer an instantaneous operation, it seems to be doing a lot
> of stuff now:
>
> Initialized empty Git repository in /home/davem/git/test-2.6.git/
> remote: Generating pack...
> remote: Done counting 480025 objects.
> remote: Deltifying 480025 objects.
> remote: 100% (480025/480025) done
> Indexing 480025 objects.
> remote: Total 480025 (delta 385878), reused 473265 (delta 379369)
> 100% (480025/480025) done
> Resolving 385878 deltas.
> 100% (385878/385878) done
>
> Is there a new way to get a quick clone?
I just checked out 1.5.1.4, built it, and cannot reproduce this behaviour.
It's as fast as ever.
Ciao,
Dscho
^ permalink raw reply
* Re: Other compression?, was Re: [PATCH] Add --no-reuse-delta option to git-gc
From: Johannes Schindelin @ 2007-05-09 11:35 UTC (permalink / raw)
To: Steven Grimm; +Cc: Git Mailing List
In-Reply-To: <46418E24.9020309@midwinter.com>
Hi,
On Wed, 9 May 2007, Steven Grimm wrote:
> On that note, has any thought been given to looking at other compression
> algorithms?
I think you could do that. But you would lose compatibility with all
existing Git clients. IOW nobody could pull from you.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Steffen Prohaska @ 2007-05-09 11:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705091303280.4167@racer.site>
Hello,
On May 9, 2007, at 1:04 PM, Johannes Schindelin wrote:
> On Wed, 9 May 2007, Steffen Prohaska wrote:
>
>> The old implementation executed 'cvs status' for each file touched by
>> the patch to be applied.
>
> I did not follow development of that script closely, but could it
> be that
> this is a safety valve, to make it unlikely to commit something
> which was
> changed by somebody else in the meantime?
Right. My patch doesn't change the functionality of the safety check.
It's just a magnitude faster if you commit a lot of files. I'm now
able to apply a patch that changes 900 files to a cvs working copy
using ssh over DSL. I wasn't before, at least not in reasonable time.
Another solution would be to make the safety checks optional as they
are not needed for the core functionality. If you have a clean, up-to-
date cvs working copy you're fine.
- Steffen
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-09 12:19 UTC (permalink / raw)
To: J. Bruce Fields, kha, barkalow; +Cc: junio, git
In-Reply-To: <20070509031803.GA27980@fieldses.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3662 bytes --]
Hi,
for your reviewing pleasure, I made a patch on top of the original one,
but I can easily provide a full patch for application.
--
[PATCH] user-manual: Touch ups on the birdview section
... as suggested by J. Bruce Fields, Karl Hasselström and Daniel Barkalow.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/user-manual.txt | 31 +++++++++++++++++++++++++++----
1 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 2d58bb0..55934db 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3197,7 +3197,15 @@ basically _the_ header file which is included by _all_ of Git's C sources.
If you grasp the ideas in that initial commit (it is really small and you
can get into it really fast, and it will help you recognize things in the
much larger code base we have now), you should go on skimming `cache.h`,
-`object.h` and `commit.h`.
+`object.h` and `commit.h` in the current version.
+
+In the early days, Git (in the tradition of UNIX) was a bunch of programs
+which were extremely simple, and which you used in scripts, piping the
+output of one into another. This turned out to be good for initial
+development, since it was easier to test new things. However, recently
+many of these parts have become builtins, and some of the core has been
+"libified", i.e. put into libgit.a for performance, portability reasons,
+and to avoid code duplication.
By now, you know what the index is (and find the corresponding data
structures in `cache.h`), and that there are just a couple of object types
@@ -3236,9 +3244,22 @@ options that were relevant for the different plumbing commands that were
called by the script.
Most of what `git-rev-list` did is contained in `revision.c` and
-`revision.h`. It wraps the options in a struct named rev_info, which
+`revision.h`. It wraps the options in a struct named `rev_info`, which
controls how and what revisions are walked, and more.
+The original job of `git-rev-parse` is now taken by the function
+`setup_revisions()`, which parses the revisions and the common command line
+options for the revision walker. This information is stored in the struct
+`rev_info` for later consumption. You can do your own command line option
+parsing after calling `setup_revisions()`. After that, you have to call
+`prepare_revision_walk()` for initialization, and then you can get the
+commits one by one with the function `get_revision()`.
+
+If you are interested in more details of the revision walking process,
+just have a look at the first implementation of `cmd_log()`; call
+`git-show v1.3.0~155^2~4` and scroll down to that function (note that you
+no longer need to call `setup_pager()` directly).
+
Nowadays, `git log` is a builtin, which means that it is _contained_ in the
command `git`. The source side of a builtin is
@@ -3300,8 +3321,10 @@ Two things are interesting here:
- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
char *`, but is actually expected to be a pointer to `unsigned
- char[20]`. This variable will contain the big endian version of the
- 40-character hex string representation of the SHA-1.
+ char[20]`. This variable will contain the 160-bit SHA-1 of the given
+ commit. Note that whenever a SHA-1 is passed as "unsigned char *", it
+ is the binary representation (big-endian), as opposed to the ASCII
+ representation in hex characters, which is passed as "char *".
You will see both of these things throughout the code.
--
1.5.2.rc2.2502.g46b5cb
^ permalink raw reply related
* Re: [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Johannes Schindelin @ 2007-05-09 12:25 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <4BA4CF7D-40CB-4A55-ADDC-56DE179FD6C1@zib.de>
Hi,
On Wed, 9 May 2007, Steffen Prohaska wrote:
> On May 9, 2007, at 1:04 PM, Johannes Schindelin wrote:
>
> > On Wed, 9 May 2007, Steffen Prohaska wrote:
> >
> > > The old implementation executed 'cvs status' for each file touched by
> > > the patch to be applied.
> >
> > I did not follow development of that script closely, but could it be that
> > this is a safety valve, to make it unlikely to commit something which was
> > changed by somebody else in the meantime?
>
> Right. My patch doesn't change the functionality of the safety check. It's
> just a magnitude faster if you commit a lot of files. I'm now able to apply a
> patch that changes 900 files to a cvs working copy using ssh over DSL. I
> wasn't before, at least not in reasonable time.
What I was trying to get at: if you commit 900 files, and after the 450th
file somebody _else_ commits a file, which just so happens to be one of
your 450 remaining files, that safety check no longer holds.
CVS is slow.
Ciao,
Dscho
^ permalink raw reply
* GIT on Windows
From: Panagiotis Issaris @ 2007-05-09 12:29 UTC (permalink / raw)
To: git
Hi,
As someone in the FFmpeg project asked about GIT's availability on other
operating systems, and it was mentioned that Mercurial worked fine
on Windows, I wanted to have a look whether it was already possible to run GIT
on Windows.
I first had a go at getting it working on MSys/MinGW, but as no binaries
appeared to be available and compilation wasn't trivial, I figured I'd
take the easier path using CygWin. When looking for packages to resolve the GIT
build dependencies, I noticed that a GIT package was
already available from within the CygWin installer! :-)
I tried some basic stuff, creating a repository, adding files, committing,
diffing and found out all this worked fine. I noticed that gitk also works fine.
Then I wanted to try the same on some real repository (meaning with more then
the 10 commits my testrepository contained).
I tried cloning a repository of my own but this resulted in a crash:
git clone http://lumumba.uhasselt.be/takis/git/ffmpeg-pi.git/
...
walk 5c90e2f63a0d46c6f2ab6c30bdfe1e0212ca46ff
walk 77a6e87c60a59b9aea1d2441b7092a55a66f5f6e
walk bb588b310f6d4313b7e979a7291dda5ed7150f24
walk 43ede2c8f98a8d089be1d94a03ad25a442aaf70a
walk 7c8107ced46b499daaac7b31e9316b3ce02d5b97
walk 645d04783e96d519b04aa079152330ca583c06e1
walk 2a4b277efcaa4ccb2ce0c4e2db1359d4d9de50b3
walk a364a4c1b3dfcaa65b39a09162f71dbdedcdaa9d
walk a4ba211235ab711a6d626c6b1c58762067d24308
walk 6ba58730a9d61bcac2a1585d646670a50a75acb0
walk a805a8dc64b86bb1235b1a0016647f604f145441
walk b12275479b67093f8b399e6e1461c14b55889b3f
walk 8400d62a2dc5242baf76a47ffb2705a0809dbeaa
walk 64f8fbdfe9a4810987bf22ce1255cfdb9772e07a
walk 9ac44cb9aa52e0b2befa5e54c78ea36ff85bfa71
walk 41f92f338d79cd404e430832a6cbba601b00ad08
8 [main] git-http-fetch 3436 _cygtls::handle_exceptions: Error while dumpi
ng state (probably corrupted stack)
/usr/bin/git-clone: line 33: 3436 Segmentation fault (core dumped) git-htt
p-fetch $v -a -w "$tname" "$sha1" "$1"
rm: cannot remove directory `/cygdrive/c/Documents and Settings/pissaris/src/ffm
peg-pi/.git/clone-tmp': Directory not empty
The resulting directory contains only the following:
pissaris@pissaris ~/src/ffmpeg-pi$ ls .git/ -la
total 0
drwxr-xr-x+ 3 pissaris mkgroup-l-d 0 May 9 14:02 .
drwxr-xr-x+ 3 pissaris mkgroup-l-d 0 May 9 14:02 ..
drwxr-xr-x+ 2 pissaris mkgroup-l-d 0 May 9 14:02 clone-tmp
pissaris@pissaris ~/src/ffmpeg-pi
pissaris@pissaris ~/src/ffmpeg-pi
$ git --version
git version 1.5.1.3
I'll see if 1.5.1.4 solves this crash, and will most likely have a go at getting
the MinGW version compiled too.
Any clues on the reason for this crash? Is anyone already using GIT on Windows
on real repositories?
With friendly regards,
Takis
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Petr Baudis @ 2007-05-09 12:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: J. Bruce Fields, kha, barkalow, junio, git
In-Reply-To: <Pine.LNX.4.64.0705091414280.4167@racer.site>
On Wed, May 09, 2007 at 02:19:03PM CEST, Johannes Schindelin wrote:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 2d58bb0..55934db 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -3197,7 +3197,15 @@ basically _the_ header file which is included by _all_ of Git's C sources.
> If you grasp the ideas in that initial commit (it is really small and you
> can get into it really fast, and it will help you recognize things in the
> much larger code base we have now), you should go on skimming `cache.h`,
> -`object.h` and `commit.h`.
> +`object.h` and `commit.h` in the current version.
> +
> +In the early days, Git (in the tradition of UNIX) was a bunch of programs
> +which were extremely simple, and which you used in scripts, piping the
> +output of one into another. This turned out to be good for initial
> +development, since it was easier to test new things. However, recently
> +many of these parts have become builtins, and some of the core has been
> +"libified", i.e. put into libgit.a for performance, portability reasons,
> +and to avoid code duplication.
>
> By now, you know what the index is (and find the corresponding data
> structures in `cache.h`), and that there are just a couple of object types
I disagree, especially with the past tense of the first half of the
paragraph. Git is _still_ a bunch of programs you use in scripts, piping
the output of one into another. Another point is that
implementation-wise many of the code is currently shared in an internal
library, etc.
I'd be a bit careful to talk about libgit.a so leisurely since it might
give the reader an impression that there really _is_ "the git library",
with API and everything, that they can use externally. Of course you
need to mention libgit.a, but I'd also mention that it is so far meant
only for internal git's use and has no solidified API.
> @@ -3300,8 +3321,10 @@ Two things are interesting here:
>
> - the variable `sha1` in the function signature of `get_sha1()` is `unsigned
> char *`, but is actually expected to be a pointer to `unsigned
> - char[20]`. This variable will contain the big endian version of the
> - 40-character hex string representation of the SHA-1.
> + char[20]`. This variable will contain the 160-bit SHA-1 of the given
> + commit. Note that whenever a SHA-1 is passed as "unsigned char *", it
> + is the binary representation (big-endian), as opposed to the ASCII
> + representation in hex characters, which is passed as "char *".
>
> You will see both of these things throughout the code.
To be honest, I wouldn't even be *thinking* about the endianity of SHA-1
octet representation (you don't usually really deal with the hash as
with a number, so expecting to have it in native endianity is not very
natural; you just deal with it as with a data blob) and the
"(big-endian)" would only confuse me and get me thinking about "huh, do
they swap the bytes, or wait, they don't, ...?!".
But that's maybe just me.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref
From: Petr Baudis @ 2007-05-09 12:39 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070509103320.GA7257MdfPADPa@greensroom.kotnet.org>
On Wed, May 09, 2007 at 12:33:20PM CEST, Sven Verdoolaege wrote:
> git-checkout is also adapted to make use of this new option
> instead of the handcrafted command sequence.
>
> Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Isn't this what git-symbolic-ref is about?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: GIT on Windows
From: Johannes Sixt @ 2007-05-09 12:41 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20070509T142518-558@post.gmane.org>
Panagiotis Issaris wrote:
> I'll see if 1.5.1.4 solves this crash, and will most likely have a go at getting
> the MinGW version compiled too.
I don't think that the MinGW version can clone via http out of the box.
If you can, use native git protocol or ssh. They are much preferred over
http anyway (not only on Windows).
-- Hannes
^ permalink raw reply
* Re: GIT on Windows
From: Panagiotis Issaris @ 2007-05-09 12:42 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20070509T142518-558@post.gmane.org>
Panagiotis Issaris <takis.issaris <at> uhasselt.be> writes:
[...]
> pissaris <at> pissaris ~/src/ffmpeg-pi
> $ git --version
> git version 1.5.1.3
>
> I'll see if 1.5.1.4 solves this crash, and will most likely
> have a go at getting the MinGW version compiled too.
Please ignore this bugreport as GIT 1.5.1.4 indeed seems to solve
this crash! :-) (That or the CygWin binary GIT 1.5.1.3 package
might be broken).
With friendly regards,
Takis
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: Johannes Schindelin @ 2007-05-09 12:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: J. Bruce Fields, kha, barkalow, junio, git
In-Reply-To: <20070509123205.GN4489@pasky.or.cz>
Hi,
On Wed, 9 May 2007, Petr Baudis wrote:
> On Wed, May 09, 2007 at 02:19:03PM CEST, Johannes Schindelin wrote:
> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> > index 2d58bb0..55934db 100644
> > --- a/Documentation/user-manual.txt
> > +++ b/Documentation/user-manual.txt
> > @@ -3197,7 +3197,15 @@ basically _the_ header file which is included by _all_ of Git's C sources.
> > If you grasp the ideas in that initial commit (it is really small and you
> > can get into it really fast, and it will help you recognize things in the
> > much larger code base we have now), you should go on skimming `cache.h`,
> > -`object.h` and `commit.h`.
> > +`object.h` and `commit.h` in the current version.
> > +
> > +In the early days, Git (in the tradition of UNIX) was a bunch of programs
> > +which were extremely simple, and which you used in scripts, piping the
> > +output of one into another. This turned out to be good for initial
> > +development, since it was easier to test new things. However, recently
> > +many of these parts have become builtins, and some of the core has been
> > +"libified", i.e. put into libgit.a for performance, portability reasons,
> > +and to avoid code duplication.
> >
> > By now, you know what the index is (and find the corresponding data
> > structures in `cache.h`), and that there are just a couple of object types
>
> I disagree, especially with the past tense of the first half of the
> paragraph. Git is _still_ a bunch of programs you use in scripts, piping
> the output of one into another. Another point is that
> implementation-wise many of the code is currently shared in an internal
> library, etc.
No. Many parts are _not_ simple programs piped into each other. git-log,
git-show, git-mv come to mind. That is why I wrote "many" and not "all".
> I'd be a bit careful to talk about libgit.a so leisurely since it might
> give the reader an impression that there really _is_ "the git library",
> with API and everything, that they can use externally. Of course you
> need to mention libgit.a, but I'd also mention that it is so far meant
> only for internal git's use and has no solidified API.
Frankly, this is just a birdview thing. If you want to go and make a
hacker's manual, go ahead!
> > @@ -3300,8 +3321,10 @@ Two things are interesting here:
> >
> > - the variable `sha1` in the function signature of `get_sha1()` is `unsigned
> > char *`, but is actually expected to be a pointer to `unsigned
> > - char[20]`. This variable will contain the big endian version of the
> > - 40-character hex string representation of the SHA-1.
> > + char[20]`. This variable will contain the 160-bit SHA-1 of the given
> > + commit. Note that whenever a SHA-1 is passed as "unsigned char *", it
> > + is the binary representation (big-endian), as opposed to the ASCII
> > + representation in hex characters, which is passed as "char *".
> >
> > You will see both of these things throughout the code.
>
> To be honest, I wouldn't even be *thinking* about the endianity of SHA-1
> octet representation (you don't usually really deal with the hash as
> with a number, so expecting to have it in native endianity is not very
> natural; you just deal with it as with a data blob) and the
> "(big-endian)" would only confuse me and get me thinking about "huh, do
> they swap the bytes, or wait, they don't, ...?!".
>
> But that's maybe just me.
But then, maybe it is just me? I got it completely wrong the first time,
fully expecting the calculations to be carried out in host endianness for
performance reasons.
Ciao,
Dscho
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Petr Baudis @ 2007-05-09 12:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vvef5c0fw.fsf@assigned-by-dhcp.cox.net>
On Sun, May 06, 2007 at 07:43:31PM CEST, Junio C Hamano wrote:
> A single liner "-m" is handy for "Oops, typofix in foo.c" kind
> of commit, but in such a case you literally would be changing
> only the typofix and won't have "edit foo.c; git add foo.c; edit
> foo.c; git commit" sequence anyway.
I don't get this argument - I frequently write quite long descriptions
inside the -m argument(s), since I just find it more convenient than
having to edit it in an editor, for various reasons. So there is really
no reason why the "-m is only for short single-liner commit messages"
hypothesis could hold true.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] git-update-ref: add --no-deref option for overwriting/detaching ref
From: Sven Verdoolaege @ 2007-05-09 12:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20070509123914.GO4489@pasky.or.cz>
On Wed, May 09, 2007 at 02:39:14PM +0200, Petr Baudis wrote:
> On Wed, May 09, 2007 at 12:33:20PM CEST, Sven Verdoolaege wrote:
> > git-checkout is also adapted to make use of this new option
> > instead of the handcrafted command sequence.
> >
> > Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
>
> Isn't this what git-symbolic-ref is about?
You certainly can't use git-symbolic-ref now to overwrite a symbolic
ref by a non-symbolic ref. It allows you to do the equivalent
of symlink/readlink, while we want to _remove_ the link here.
skimo
^ permalink raw reply
* Re: [PATCH] Optimized cvsexportcommit: calling 'cvs status' only once instead of once per changed file.
From: Steffen Prohaska @ 2007-05-09 13:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705091424190.4167@racer.site>
On May 9, 2007, at 2:25 PM, Johannes Schindelin wrote:
> What I was trying to get at: if you commit 900 files, and after the
> 450th
> file somebody _else_ commits a file, which just so happens to be
> one of
> your 450 remaining files, that safety check no longer holds.
>
> CVS is slow.
I know. I'd probably apply my patch late at night or on the weekend,
when the chance is lower to conflict with other commits.
You can't remove the race conditions that you have when interacting
with cvs. We can only decrease the chance of being hit by making the
time window smaller. This is a side benefit of my patch. The main
purpose is to lower the overall time needed to apply patch that
modifies lots of files.
- Steffen
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Petr Baudis @ 2007-05-09 13:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0705071301230.4167@racer.site>
Hi,
On Mon, May 07, 2007 at 01:05:44PM CEST, Johannes Schindelin wrote:
> On Mon, 7 May 2007, Matthieu Moy wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > Just another reason to hate CVS. Because it trained people to do that. If
> > > it was not for the training by CVS, I would have strongly opposed to the
> > > introduction of the "-m" switch to commit. It _encourages_ bad commit
> > > messages.
> >
> > Well, this really depends on the use-case, size of commit, ...
>
> Okay, so I use "-m" myself sometimes.
I'm maybe somewhat standing out of the crowd, but I sometimes use -m
for *very* long commit messages - just using separate -m parameters for
paragraphs and writing on; I tend to find it much more natural than
spawning an editor. Only when I find later that I've made an ugly typo
in the middle of 250-characters commandline or I figure out that I
should add some figure to the message, I throw in -e at the end and add
the final touches.
..snip..
> Commit messages, BTW, are somewhat of an artform. You cannot imagine how
> slow I am writing them, because they should be helpful not only for the
> reviewer, but also for the casual git-blame user, who wants to find out
> the rationale of a change.
But I agree that commit messages are somewhat of an artform, and
just finding a good headline can be quite difficult sometime. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Petr Baudis @ 2007-05-09 13:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Guilhem Bonnefille, git
In-Reply-To: <Pine.LNX.4.64.0705071453120.4167@racer.site>
Hi,
On Mon, May 07, 2007 at 02:55:13PM CEST, Johannes Schindelin wrote:
> On Mon, 7 May 2007, Guilhem Bonnefille wrote:
>
> > As a newbie, I'm agree with Matthieu: the Git's index is surprising for
> > people coming from CVS/SVN (mindless?) world. So a good documentation
> > about this, even in tutorials, is really important.
>
> So, you are not only a newbie, but you have to unlearn some CVS
> braindamage.
>
> I don't know how to make it even more prominent that CVS users should read
> a special introduction first. AFAICT such a hint is in all the appropriate
> places. (I mean, you would not expect to be able to fly a plane, just
> because you have learnt to drive a car, wouldn't you?)
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html does not
talk about anything like that (it links to "Git for CVS users" but
that's really just about importing from CVS and the shared repository
workflow).
On the other hand, I think the tutorial linked above gives quite a
clear explanation of git commit -a, git add etc. Guilhem, what do you
find missing in the tutorial about this topic?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] Add a birdview-on-the-source-code section to the user manual
From: J. Bruce Fields @ 2007-05-09 13:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: kha, barkalow, junio, git
In-Reply-To: <Pine.LNX.4.64.0705091414280.4167@racer.site>
On Wed, May 09, 2007 at 02:19:03PM +0200, Johannes Schindelin wrote:
> [PATCH] user-manual: Touch ups on the birdview section
Those all look like sensible changes to me, thanks!
--b.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Petr Baudis @ 2007-05-09 13:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git
In-Reply-To: <alpine.LFD.0.98.0705072137450.3974@woody.linux-foundation.org>
On Tue, May 08, 2007 at 06:45:32AM CEST, Linus Torvalds wrote:
> Git used explicit index updates from day 1, even before it did the first
> merge. It's simply how I've always worked. I tend to have dirty trees,
> with some random patch in my tree that I do *not* want to commit, because
> it's just a Makefile update for the next version (to remind me - I've
> released kernel versions too many times with an old version number, just
> because I forgot to update the Makefile).
>
> Or other things like that - I have small test-patches in my tree that I
> want to build, but that I don't want to commit, and I end up doing big
> merges and whole patch-application sequences with such a dirty tree
> (obviously if the patch or merge wants to change that file, I then need to
> do something about that dirty state, but it happens surprisingly seldom).
Hmm, does this really work so well for you guys? Because thanks to Mr.
Murphy, in my case, when I have some custom Makefile tweak, I always
need to commit some unrelated changes involving Makefile more often than
usual, and so on; so in general case, file-level changes exclusion
doesn't really work so well for me.
So this use of index seems to me really as a workaround for more
fine-grained change control (in a similar way that rename following
would be a workaround for lack of more fine-grained content moves
tracking). I will have to look into git-gui's hunk-level control and
maybe reimplement it in tig.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] gitweb: Do not use absolute font sizes
From: Petr Baudis @ 2007-05-09 13:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvef2y21o.fsf@assigned-by-dhcp.cox.net>
On Wed, May 09, 2007 at 07:54:43AM CEST, Junio C Hamano wrote:
> [12, 18, 10] / 12 * 100 = [100, 150, 83.33]
>
> why not use 83% for what were originally 10px?
It seemed to me that the small parts were way too large then (this is
also why I decided not to use 'large', 'medium' and 'small' - large was
too small and small was too large, I felt), but I don't particularily
care about this detail.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ permalink raw reply
* Re: [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50
From: Theodore Tso @ 2007-05-09 13:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Schindelin, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0705081439140.24220@xanadu.home>
On Tue, May 08, 2007 at 02:46:35PM -0400, Nicolas Pitre wrote:
> The window size has absolutely no effect on the runtime pack access,
> except maybe for the increased number of deltas. It is really a pack
> time cost. The delta depth is the opposite: it has no effect on the
> packing time, but it has the potential to slow down runtime access. But
> the delta base cache is apparently working really well to mitigate that
> cost, as long as it is big enough of course.
Exactly, and the numbers bear out with the theory. Junio's already
applied the change to up the default to 50, but for the record, here
are the results using a kernel git repository, with times for doing a
git-gc (with the --no-reuse-delta, although I like the suggestion to
change it to just be "--hard", or maybe "--agressive"), and with a git
pickaxe and a git-log with pathname restrictions. It essentially
confirms that the delta base cache is doing the job just fine, up to
even a depth of 100. However, there isn't much difference in pack
size between a depth of 50 and 100.
Increasing the window size from 10 to 30 increases the pack run time
by roughly 40%, and saves an extra 5% or so on the pack size.
Increasing the window beyond 30 has ever-smaller diminishing returns,
while the time to repack gets bigger and bigger.
The timing information is real/user/system/minor pagefaults, and as
before, the results are done using a hot cache. Apologies in advance
for the long lines in the benchmark results. These results were
generated using a relatively recent, post-2.6.21 kernel git tree on a
Thinkpad T60p laptop with a 2GHz T2500 Intel Core Duo processor.
Regards,
git-gc pack size git-log -S'object' git-log include/scsi drivers/scsi
w=10,d=10 5:08.70/293.20/5.56/1027802 162316k 5:31.12/322.20/4.14/153298 0:01.80/1.72/0.03/19077
w=10,d=30 4:14.79/245.46/2.57/398754 149636k 5:41.56/331.21/4.86/517220 0:01.83/1.74/0.05/17880
w=10,d=50 4:31.89/257.16/3.50/576538 146608k 5:51.58/336.63/5.07/259643 0:01.88/1.80/0.04/17658
w=10,d=100 4:35.93/262.77/4.08/715195 144152k 5:58.23/341.26/6.22/624510 0:01.89/1.80/0.04/17571
w=30,d=10 7:23.06/424.08/6.35/1222640 153752k 5:32.85/323.96/2.13/213150 0:01.73/1.64/0.06/18429
w=30,d=30 6:15.76/364.27/3.53/407546 141200k 5:42.29/333.53/2.10/338301 0:01.81/1.71/0.04/17237
w=30,d=50 6:26.85/372.24/5.38/578343 139408k 5:42.21/336.65/1.30/260234 0:01.77/1.70/0.05/17108
w=30,d=100 6:34.31/381.72/5.40/744886 138040k 5:59.03/342.65/4.90/607681 0:01.93/1.79/0.06/17043
w=50,d=10 8:51.08/508.80/5.75/1050358 152168k 5:35.43/327.48/3.70/209655 0:01.70/1.64/0.04/18264
w=50,d=30 8:04.53/471.65/5.58/423755 139000k 5:42.06/335.67/1.55/335333 0:01.78/1.72/0.04/17046
w=50,d=50 8:14.87/479.93/7.09/617310 137244k 5:47.22/339.26/2.73/462412 0:01.79/1.72/0.04/16871
w=50,d=100 8:23.13/490.09/4.10/751742 136152k 5:51.10/343.89/2.29/503573 0:01.83/1.73/0.06/16920
w=100,d=10 12:00.34/702.07/6.27/1167403 150736k 5:34.42/328.88/1.09/207522 0:01.72/1.63/0.07/18024
w=100,d=30 11:56.34/702.36/2.93/436950 137240k 5:42.64/335.82/2.07/422743 0:01.77/1.67/0.05/16852
w=100,d=50 12:20.39/722.99/3.94/671655 135488k 5:47.20/339.38/2.44/468974 0:01.78/1.68/0.03/16621
w=100,d=100 12:37.69/740.63/4.12/733593 134492k 5:52.26/344.16/3.00/636120 0:01.85/1.80/0.03/16681
- Ted
^ permalink raw reply
* Re: [PATCH v2] Custom compression levels for objects and packs
From: Theodore Tso @ 2007-05-09 13:56 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4640FBDE.1000609@gmail.com>
I noticed that the patch didn't include additions to
Documentation/config.txt; could those be added, so that as much as
possible all of the various configuration knobs are documented in one
place, please?
Thanks!!
- Ted
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Johannes Schindelin @ 2007-05-09 13:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Matthieu Moy, git
In-Reply-To: <20070509125225.GP4489@pasky.or.cz>
Hi,
On Wed, 9 May 2007, Petr Baudis wrote:
> On Sun, May 06, 2007 at 07:43:31PM CEST, Junio C Hamano wrote:
> > A single liner "-m" is handy for "Oops, typofix in foo.c" kind
> > of commit, but in such a case you literally would be changing
> > only the typofix and won't have "edit foo.c; git add foo.c; edit
> > foo.c; git commit" sequence anyway.
>
> I don't get this argument - I frequently write quite long descriptions
> inside the -m argument(s), since I just find it more convenient than
> having to edit it in an editor, for various reasons. So there is really
> no reason why the "-m is only for short single-liner commit messages"
> hypothesis could hold true.
:-) You yourself provided a reason in another reply: typos.
Another reason is that you can see how the end result will look like in an
editor. For example, you'll have a hard time making sure in the
command line that the lines are no longer than 76 characters.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add pack.depth option to git-pack-objects and change default depth to 50
From: Johannes Schindelin @ 2007-05-09 14:17 UTC (permalink / raw)
To: Theodore Tso; +Cc: Nicolas Pitre, Junio C Hamano, Git Mailing List
In-Reply-To: <20070509134958.GA21489@thunk.org>
Hi,
On Wed, 9 May 2007, Theodore Tso wrote:
> [...] here are the results using a kernel git repository [...]
Thank you very much,
Dscho
^ permalink raw reply
* [PATCH] git-commit: Reformat log messages provided on commandline
From: Petr Baudis @ 2007-05-09 14:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0705091513360.4167@racer.site>
Hi,
On Wed, May 09, 2007 at 03:57:28PM CEST, Johannes Schindelin wrote:
> Another reason is that you can see how the end result will look like in an
> editor. For example, you'll have a hard time making sure in the
> command line that the lines are no longer than 76 characters.
oh, indeed - good point. cg-commit uses fmt to format the message, I
think git-commit should do the same; let's see how controversial such a
change would be.
---
This makes git-commit filter log messages provided on commandline by fmt,
thus making nice paragraphs from them. This makes it possible to specify
even long commit messages on command line without worrying about this, akin
to cg-commit.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-commit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index f28fc24..28cbb55 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -432,7 +432,7 @@ fi
if test "$log_message" != ''
then
- echo "$log_message"
+ echo "$log_message" | fmt
elif test "$logfile" != ""
then
if test "$logfile" = -
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
-- Samuel Beckett
^ 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