* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-02 15:34 UTC (permalink / raw)
To: Guilhem Bonnefille; +Cc: git, users
In-Reply-To: <8b65902a0708010438s24d16109k601b52c04cf9c066@mail.gmail.com>
[I am CCing this response to the mailing lists.]
Guilhem Bonnefille wrote:
> On 8/1/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> I am the maintainer of cvs2svn[1], which is a program for one-time
>> conversions from CVS to Subversion. cvs2svn is very robust against the
>> many peculiarities of CVS and can convert just about every CVS
>> repository we have ever seen.
>
> What are the differences with cvsps ( http://www.cobite.com/cvsps/ )?
I'm not extremely familiar with cvsps, and I don't really want to get
into a "my-tool-is-better-than-your-tool" kind of argument. Instead I
will mention that the goals of the two projects are somewhat different:
cvs2svn is meant for one-time conversions from CVS, and therefore aims
for maximum conversion accuracy, robustness even in the presence of some
kinds of CVS repository corruption, intelligent translation of CVS
idioms to the idioms of a modern SCM, and scalability to large
repositories (by using on-disk databases instead of RAM for intermediate
data). Conversion speed is not a primary goal of cvs2svn, and
incremental conversions are not supported at all. cvs2svn requires
filesystem access to the CVS repository (it parses the RCS files directly).
cvsps is not a conversion tool at all, though it is used by other
conversion tools to generate the changesets. It appears (I hope I am
not misinterpreting things) to emphasize speed and incremental
operation, for example attempting to make changesets consistent from one
run to the next, even if the CVS repository has been changed prudently
between runs. cvsps does not appear to attempt to create atomic branch
and tag creation commits or handle CVS's special vendorbranch behavior.
cvsps operates via the CVS protocol; you don't need filesystem access
to the CVS repository.
I can also point you to a list of cvs2svn features, which includes a
list of some of the CVS quirks that it knows how to handle:
http://cvs2svn.tigris.org/cvs2svn.html#features
cvs2svn includes a large suite of perverse CVS repositories that we use
for testing. Many of them are derived from real-life CVS repositories
that people have had problems with. It would be very interesting to see
how other conversion tools handle these repositories, but I don't expect
to have time to do so in the near future.
Michael
^ permalink raw reply
* [PATCH] Handle the errors from chdir in set_work_tree
From: Alex Riesen @ 2007-08-02 15:27 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 329 bytes --]
These I haven't seen yet. Wouldn't like such a surprise though.
Also unstatic rel, it seems to be declared static accidentally.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
One gets paranoid when exposed to "commercial"
systems for too long.
setup.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
[-- Attachment #2: 0002-Handle-the-errors-from-chdir-in-set_work_tree.txt --]
[-- Type: text/plain, Size: 1289 bytes --]
From 602d49acd3e5285974cc1b7c4337301b13bb54b8 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 2 Aug 2007 16:51:57 +0200
Subject: [PATCH] Handle the errors from chdir in set_work_tree
These I haven't seen yet. Wouldn't like such a surprise though.
Also unstatic rel, it seems to be declared static accidentally.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
setup.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/setup.c b/setup.c
index 1beba7e..4e6bb76 100644
--- a/setup.c
+++ b/setup.c
@@ -201,8 +201,8 @@ int is_inside_work_tree(void)
*/
const char *set_work_tree(const char *dir)
{
- char dir_buffer[PATH_MAX];
- static char buffer[PATH_MAX + 1], *rel = NULL;
+ char dir_buffer[PATH_MAX], *rel = NULL;
+ static char buffer[PATH_MAX + 1];
int len, postfix_len = strlen(DEFAULT_GIT_DIR_ENVIRONMENT) + 1;
/* strip the variable 'dir' of the postfix "/.git" if it has it */
@@ -220,8 +220,10 @@ const char *set_work_tree(const char *dir)
if (!is_absolute_path(dir))
set_git_dir(make_absolute_path(dir));
dir = dir_buffer;
- chdir(dir);
- strcat(rel, "/");
+ if (chdir(dir))
+ rel = NULL;
+ else
+ strcat(rel, "/");
inside_git_dir = 0;
} else {
rel = NULL;
--
1.5.3.rc3.145.g4d9cdb
^ permalink raw reply related
* [PATCH] Fix set_work_tree on cygwin
From: Alex Riesen @ 2007-08-02 15:25 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
I don't know why, but for some unknown reason the buffer did not
contain zeros. This broke t1500-rev-parse.sh (the test for
GIT_DIR=../.git git rev-parse --show-prefix).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
It could be a memory corruption somewhere, but I really was
unable to find what could that, nor could I reproduce the problem
on a handy linux box.
setup.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-Fix-set_work_tree-on-cygwin.txt --]
[-- Type: text/plain, Size: 1037 bytes --]
From e5e7adb7db0d9c00a938f32281774f6a7532b44a Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 2 Aug 2007 16:33:02 +0200
Subject: [PATCH] Fix set_work_tree on cygwin
I don't know why, but for some unknown reason the buffer did not
contain zeros. This broke t1500-rev-parse.sh (the test for
GIT_DIR=../.git git rev-parse --show-prefix).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
setup.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index 3653092..1beba7e 100644
--- a/setup.c
+++ b/setup.c
@@ -209,7 +209,8 @@ const char *set_work_tree(const char *dir)
len = strlen(dir);
if (len > postfix_len && !strcmp(dir + len - postfix_len,
"/" DEFAULT_GIT_DIR_ENVIRONMENT)) {
- strncpy(dir_buffer, dir, len - postfix_len);
+ strncpy(dir_buffer, dir, len - postfix_len);
+ dir_buffer[len - postfix_len] = '\0';
/* are we inside the default work tree? */
rel = get_relative_cwd(buffer, sizeof(buffer), dir_buffer);
--
1.5.3.rc3.145.g4d9cdb
^ permalink raw reply related
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 15:23 UTC (permalink / raw)
To: Steven Grimm
Cc: Jean-François Veillette, Matthieu Moy, Junio C Hamano, git
In-Reply-To: <46B1F3F4.5030504@midwinter.com>
Hi,
On Thu, 2 Aug 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > This use case has not much to do with new users. A new user _has_ to know
> > that updating all files, even if their content does not change, is not
> > right.
> >
>
> Someone who has used, say, Subversion might have a perfectly reasonable
> expectation that "git diff" will show differences in content, and when there
> are no differences in content, will not mention a file at all. Other version
> control systems have "diff" commands that ignore touched files.
>
> I admit I also thought the empty diffs were a bug (albeit a minor one not
> worth making noise about) until this thread. Now I understand why it happens,
> though I still think we'd be better off just not displaying the filename in
> git-diff until we know there's an actual diff to display.
>
> I certainly don't think the "it's a feature: it reminds you when you've edited
> a file without changing it" argument holds any water at all. If that were
> truly the intent, if we truly considered that to be useful information a
> developer would want to get at after the fact, then why would git-status throw
> away that information?
Okay, I'll answer just this one, instead of pointing you to the thread
that I've been pointing to twice now (because your ideas about how
git should work are usually similar to mine, and by way of saying thanks
for your contributions):
When is the time to say "git status"?
It is just before committing. I.e when you really think that you're done
editing, and want to have the end picture. "git status" only gives you
names, and therefore it _has_ to update the index if it got out of sync,
to show meaningful results.
When is the time to say "git diff"?
Much more often. In the middle of your work. And there it would be
_disruptive_ if it updated the index all the time, especially if you have
a quite large working tree.
But then, normal users do not touch all the files. They don't.
So I doubt that in the common case the subject we are discussing matters
at all.
Yes, "perl -pi" is something I used myself. Yes, I think it is a bug that
it writes new files when it does not really change anything. And yes, I
had a script lying somewhere on my backup hard disk which uses some evil
"git diff --name-only | xargs bla" mantra (it does not even use the
--quiet option, since that was not invented back then) to actually _undo_
the effects by setting the timestamps back, since the full compilation
time in that project _hurt_.
But it is hardly an operation that I use daily. Hardly even twice a
year.
Ciao,
Dscho
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 15:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpq7ioeyosh.fsf@bauges.imag.fr>
Hi,
On Thu, 2 Aug 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> The question remains: why should someone running git-diff get this,
> >> and someone running git-status not get this?
> >
> > Because git-status is an index-updating operation. That's why.
>
> That sounds like "it is this way because it is not the other way
> around".
>
> So, yes, git-status updates the index because it's an index-updating
> operation, while git-diff does not update the index because it's a
> non-index-updating operation.
>
> Then, I'll rephrase my sentence as "*why* is git-status an
> index-updating operation while git-diff is not". But you'll probably
> find another way to avoid answering.
Yes. I do. The issue whether or not git status should be a read-only
operation has been discussed -- in _length_ -- here:
http://thread.gmane.org/gmane.comp.version-control.git/40205/focus=40339
Ciao,
Dscho
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Steven Grimm @ 2007-08-02 15:10 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jean-François Veillette, Matthieu Moy, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021541520.14781@racer.site>
Johannes Schindelin wrote:
> This use case has not much to do with new users. A new user _has_ to know
> that updating all files, even if their content does not change, is not
> right.
>
Someone who has used, say, Subversion might have a perfectly reasonable
expectation that "git diff" will show differences in content, and when
there are no differences in content, will not mention a file at all.
Other version control systems have "diff" commands that ignore touched
files.
I admit I also thought the empty diffs were a bug (albeit a minor one
not worth making noise about) until this thread. Now I understand why it
happens, though I still think we'd be better off just not displaying the
filename in git-diff until we know there's an actual diff to display.
I certainly don't think the "it's a feature: it reminds you when you've
edited a file without changing it" argument holds any water at all. If
that were truly the intent, if we truly considered that to be useful
information a developer would want to get at after the fact, then why
would git-status throw away that information? If I check to see what
files I've modified/added (for which I run git-status) why does that
automatically imply I am no longer interested in being reminded that I
have saved a file without making changes, especially given that such
files *don't* show up in the git-status output? git-status is silently
losing information here; it gives you no indication that it has
refreshed the index for those touched-but-not-edited files.
Now, I happen to think throwing away that information is just fine,
because I don't think I have ever once cared to know that I touched a
file but didn't change it. But fundamentally it's either a piece of
information we care about (in which case we shouldn't go silently
discarding it) or not (in which case it is just clutter in git-diff).
In the meantime, though, it's trivial enough to put a wrapper around
git-diff to filter out the diffless files. I haven't cared enough to
bother, but if I did it'd be just a few lines of Perl, no big deal.
-Steve
^ permalink raw reply
* Re: Git clone error
From: Denis Bueno @ 2007-08-02 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708012211040.14781@racer.site>
On 08/01/2007 15:12, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
wrote:
>> How difficult would it be to create a new git repo which is exactly the same
>> minus the initial condor-uninstall.sh commit? That is, just to pretend the
>> initial import of condor-uninstall.sh never existed, and use the second
>> commit of the old repo the first commit of the new, and preserve the rest of
>> the history of the entire repo?
>
> That would be even easier. Just graft "nothingness" as parent of the
> second commit:
>
> $ git rev-parse <second-commit> >> .git/info/grafts
I must be misunderstanding:
scripts[] > git fsck --full
error: b28b949a1a3c8eb37ca6eefd024508fa8b253429: object corrupt or
missing
missing blob b28b949a1a3c8eb37ca6eefd024508fa8b253429
# b2... should fill in your <second-commit>?
scripts[30] > git rev-parse b28b949a1a3c8eb37ca6eefd024508fa8b253429 >>
.git/info/grafts
scripts[31] > git fsck --full
error: b28b949a1a3c8eb37ca6eefd024508fa8b253429: object corrupt or
missing
missing blob b28b949a1a3c8eb37ca6eefd024508fa8b253429
If I try to clone the repo, I get the same error.
Denis
--
"Program testing can be used to show the presence of bugs, but never to show
their absence." -- Edsger Dijkstra
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 15:05 UTC (permalink / raw)
To: Joel Reed; +Cc: Matthieu Moy, Junio C Hamano, git
In-Reply-To: <20070802132541.GA9247@localdomain>
Hi,
On Thu, 2 Aug 2007, Joel Reed wrote:
> On Thu, Aug 02, 2007 at 01:19:55PM +0100, Johannes Schindelin wrote:
>
> <snip>
>
> > For performance reasons, git always compares the files' stat information
> > with that stored in the index.
> >
> > By updating the file, you make that check fail always.
> >
> > Without updating the index (which is not a read-only operation, and
> > therefore must not be done when doing a read-only operation like diff),
> > you will therefore _destroy_ the main reason of git's kick-ass
> > performance.
>
> The idea that read-only operation like diff shouldn't update the
> index makes a lot of sense.
>
> But, as a user of git and not a git developer, I certainly _thought_
> that git-status was a read-only operation as well. Now I know it
> isn't, but this doesn't seem very consistent.
I'll not go into details again. See
http://thread.gmane.org/gmane.comp.version-control.git/40205/focus=40339
Ciao,
Dscho
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-02 14:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021537490.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> The question remains: why should someone running git-diff get this,
>> and someone running git-status not get this?
>
> Because git-status is an index-updating operation. That's why.
That sounds like "it is this way because it is not the other way
around".
So, yes, git-status updates the index because it's an index-updating
operation, while git-diff does not update the index because it's a
non-index-updating operation.
Then, I'll rephrase my sentence as "*why* is git-status an
index-updating operation while git-diff is not". But you'll probably
find another way to avoid answering.
--
Matthieu
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Bradford Smith @ 2007-08-02 14:48 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqdqkygp.fsf@lola.quinscape.zz>
On 8/2/07, David Kastrup <dak@gnu.org> wrote:
> Hi, I wanted to ask what the general stance towards shell script
> cleanups and simplifications would be. For example, I find the expr
> usage quite inscrutable in commit, and there is no necessity of
> putting "shift" in every case branch instead of once behind it, and a
> lot of conditionals and other manipulations can be made much easier on
> the eye by using parameter expansion patterns that are, as far as I
> can see, available with every reasonable Bourne Shell and clones.
>
> Here is an example context diff (in this case, I find it more readable
> than unified) to illustrate (untested!, please don't apply without a
> regular formatted git patch).
>
> Should I bother doing such cleanups as I read up on code, or should I
> just leave things alone?
I have no authority over the git project, but please consider this argument:
Every time you submit a patch there are three costs:
1. The time you put into making the patch.
2. The time required for the maintainer to review the patch and
possibly merge it into the code base.
3. The risk that you may have accidentally broken something.
Obviously, you aren't too concerned about 1 (the cost to you), because
you're willing to do that work. However, if I were Junio, I wouldn't
be willing to "spend" costs 2 and 3 on a patch that didn't either fix
a problem or provide a new feature.
So, I recommend you do the clean-up that you want to do on your own
local branch. This will no doubt be fun and educational for you. I
know I've learned a lot in the past by experimentally "cleaning up"
old ugly code on other projects, even though the result never made it
into the official code base.
Along the way, you will probably find real bugs. When you do, submit
patches for them based on the current master branch. You can probably
manage to sneak a bit of clean-up into those bug-fixing patches, as
long as you make sure it is all relevant to fixing the bugs and you
keep the patches readable.
Best Wishes,
Bradford C Smith
p.s. I should also point out that writing portable shell scripts is
far from trivial, so it is very difficult to be certain that what
works for you will work for someone with a different shell.
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 14:43 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Matthieu Moy, Junio C Hamano, git
In-Reply-To: <AF1190E2-A0F4-479F-B0A1-50B2C7278995@yahoo.ca>
Hi,
[please do not top-post. Either comment on what you quote, or delete it.]
On Thu, 2 Aug 2007, Jean-Fran?ois Veillette wrote:
> Admin it, git porcelain still has some work to be done.
No need to argue there, I admit it.
> We can't expect new users to know the git internals workflow before they
> can use git effectively.
This use case has not much to do with new users. A new user _has_ to know
that updating all files, even if their content does not change, is not
right.
At least we do not commit empty changes like CVS did all too happily.
Ciao,
Dscho
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 14:39 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqir7y15sr.fsf@bauges.imag.fr>
Hi,
On Thu, 2 Aug 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> I fully agree that git should be optimized for the common case. But
> >> even for the common case, I also find the feature strange. You didn't
> >> answer that part of my message, but I still fail to see a rationale
> >> for making "git-diff; git-status" different from "git-status; git-diff".
> >
> > For performance reasons, git always compares the files' stat information
> > with that stored in the index.
>
> I know that, but how does it answer the part of my message that you
> are citing?
You _acknowledge_ that git is optimized for performance! And therefore
you should also acknowledge that you _throw that away_ if you let your
index go out of sync.
> > So when you do "git diff" and it tells you all those diff lines, while no
> > file was really changed, it tells you "get your act together! You just
> > _willfully_ slowed down git's performance".
>
> The question remains: why should someone running git-diff get this,
> and someone running git-status not get this?
Because git-status is an index-updating operation. That's why.
Ciao,
Dscho
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: David Kastrup @ 2007-08-02 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <20070802140011.GN29424@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> On Thu, Aug 02, 2007 at 12:44:22PM +0200, David Kastrup wrote:
>> ! logfile="${1#-?}"
>
> You can't do something like that on /bin/sh on many systems (for
> instance Solaris).
Sigh. It's in Posix.
I've seen a lot of "modern" constructs in the Shell scripts of git
(not least of all the eval hackery that is currently used instead of
this), so do you actually have positive knowledge that the existing
git stuff runs fine on such systems, and this wouldn't?
I don't have access to Solaris systems, so I have to take your word on
it, but I find it somewhat surprising that they would not follow Posix
here.
--
David Kastrup
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Jean-François Veillette @ 2007-08-02 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021147110.14781@racer.site>
I find comments like this to be counter productive.
Admin it, git porcelain still has some work to be done. We can't
expect new users to know the git internals workflow before they can
use git effectively. We can expect new users to read the man pages,
but not necessarely expect them to understand all the plumbing
implied by what they read. Here I think M.Moy understand the
plumbing and could silently deal with it. But instead he decided to
help improve git and decided to raise a flag about inconsistencies he
faced. We should never answer request for improvement with ' Just do
X and be done with it'. This is a 'geek' answer to a legitime comment.
I know the goal of git is not to reign over the world of vcs, but
it's not a reason to refuse to improve it when constructive comments
are made about it.
- jfv
Le 07-08-02 à 06:48, Johannes Schindelin a écrit :
> Hi,
>
> On Thu, 2 Aug 2007, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Thu, 2 Aug 2007, Matthieu Moy wrote:
>>>
>>>>> If the feature still makes sense in the modern world is a
>>>>> different story, but I do find it useful.
>>>>
>>>> I understand that it can be usefull, but I really don't like
>>>> having it
>>>> by default (is there a way to deactivate it BTW?).
>>>
>>> Yes. Just call "git status" and be done with it.
>>
>> That's not what I mean (my original message mentionned that already
>> BTW). By "deactivate", I mean "make git-diff never show empty diffs".
>> I don't want to run two commands where I need only one.
>
> Then don't touch the files you do not want to touch! Or if you
> want to
> have it convenient, and have a script that touches everything, even
> if it
> does not change the contents, just add "git add -u" at the end of the
> script". Not that difficult.
>
> Ciao,
> Dscho
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Robert Schiele @ 2007-08-02 14:00 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86bqdqkygp.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
On Thu, Aug 02, 2007 at 12:44:22PM +0200, David Kastrup wrote:
> ! logfile="${1#-?}"
You can't do something like that on /bin/sh on many systems (for instance
Solaris).
Robert
--
Robert Schiele
Dipl.-Wirtsch.informatiker mailto:rschiele@gmail.com
"Quidquid latine dictum sit, altum sonatur."
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Joel Reed @ 2007-08-02 13:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021315510.14781@racer.site>
On Thu, Aug 02, 2007 at 01:19:55PM +0100, Johannes Schindelin wrote:
<snip>
> For performance reasons, git always compares the files' stat information
> with that stored in the index.
>
> By updating the file, you make that check fail always.
>
> Without updating the index (which is not a read-only operation, and
> therefore must not be done when doing a read-only operation like diff),
> you will therefore _destroy_ the main reason of git's kick-ass
> performance.
The idea that read-only operation like diff shouldn't update the
index makes a lot of sense.
But, as a user of git and not a git developer, I certainly _thought_
that git-status was a read-only operation as well. Now I know it
isn't, but this doesn't seem very consistent.
jr
^ permalink raw reply
* Re: Git User's Survey 2007 - web survey site
From: Paolo Ciarrocchi @ 2007-08-02 13:04 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Jakub Narebski, git
In-Reply-To: <46a038f90708012151m468bbea0i51b95dc6ca0d9375@mail.gmail.com>
On 8/2/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > When I wrote the first survey Martin Langhoff help me in getting the
> > data into the site.
> > Maybe he can help us this time too (Martin CC'ed ;-)
>
> Did I? ;-)
Yes!
> I don't remember what I did -- survey.net is supposed to be quite
> self-service. Isn't your survey still there? Anyway, let me know what
> I can help with.
>
I still have access to survey.net (you created the account for me ;-),
if you don't mind I'll change the details and share the account with Jakub.
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-02 12:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0708021315510.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I fully agree that git should be optimized for the common case. But
>> even for the common case, I also find the feature strange. You didn't
>> answer that part of my message, but I still fail to see a rationale
>> for making "git-diff; git-status" different from "git-status; git-diff".
>
> For performance reasons, git always compares the files' stat information
> with that stored in the index.
I know that, but how does it answer the part of my message that you
are citing?
> So when you do "git diff" and it tells you all those diff lines, while no
> file was really changed, it tells you "get your act together! You just
> _willfully_ slowed down git's performance".
The question remains: why should someone running git-diff get this,
and someone running git-status not get this?
(I mean, from the user point of view, not the implementation point of
view)
--
Matthieu
^ permalink raw reply
* [PATCH] Fix documentation for core.gitproxy to reflect code
From: David Symonds @ 2007-08-02 12:23 UTC (permalink / raw)
To: git
This is with respect to my earlier email about core.gitproxy. I
figured since 1.5.3 is looming it would be best to get the
documentation correct, then nag about the feature later!
Dave.
---
Documentation/config.txt | 2 +-
Documentation/git-config.txt | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3135cb7..de9e72b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -101,7 +101,7 @@ Example
# Proxy settings
[core]
- gitProxy="ssh" for "ssh://kernel.org/"
+ gitProxy="ssh" for "kernel.org"
gitProxy=default-proxy ; for the rest
Variables
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 8451ccc..c3dffff 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -214,9 +214,7 @@ Given a .git/config like this:
; Proxy settings
[core]
- gitproxy="ssh" for "ssh://kernel.org/"
gitproxy="proxy-command" for kernel.org
- gitproxy="myprotocol-command" for "my://"
gitproxy=default-proxy ; for all the rest
you can set the filemode to true with
@@ -291,7 +289,7 @@ To actually match only values with an exclamation
mark, you have to
To add a new proxy, without altering any of the existing ones, use
------------
-% git config core.gitproxy '"proxy" for example.com'
+% git config core.gitproxy '"proxy-command" for example.com'
------------
--
1.5.2.4
^ permalink raw reply related
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 12:21 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqzm1a2l72.fsf@bauges.imag.fr>
Hi,
On Thu, 2 Aug 2007, Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Quite honestly, a script that indiscriminately touches everybody
> > but only modifies a few is simply broken. Think about "make".
> > "git diff" reporting many cache-dirty files is simply reminding
> > you the brokenness of such a script.
>
> I wouldn't call this "broken", but clearly suboptimal, yes. But for an
> occasionnal one-liner (perl -pi -e ... or so), I lose less time
> recompiling extra-files than I would writting a cleaner script. "make"
> has no way to detect the absence of modification, while git has.
_You_ can afford compiling them extra-files.
That is _exactly_ what Junio meant by "corner case".
Ciao,
Dscho
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 12:19 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpq4pji3zwm.fsf@bauges.imag.fr>
Hi,
On Thu, 2 Aug 2007, Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > The default should be tuned for users who perform manual editing
> > with status checks. And power users like yourself who run "bulk
> > touch indiscriminately but modify only some" scripts should
> > learn to run git-status (or "update-index --refresh") after such
> > operation. Swapping the defaults to optimize for the abnormal
> > case is madness.
>
> I fully agree that git should be optimized for the common case. But
> even for the common case, I also find the feature strange. You didn't
> answer that part of my message, but I still fail to see a rationale
> for making "git-diff; git-status" different from "git-status; git-diff".
For performance reasons, git always compares the files' stat information
with that stored in the index.
By updating the file, you make that check fail always.
Without updating the index (which is not a read-only operation, and
therefore must not be done when doing a read-only operation like diff),
you will therefore _destroy_ the main reason of git's kick-ass
performance.
So when you do "git diff" and it tells you all those diff lines, while no
file was really changed, it tells you "get your act together! You just
_willfully_ slowed down git's performance".
Okay?
Ciao,
Dscho
P.S.: I wish we had something similar for the cases that you did not "git
gc", so that people, posting to their blogs all over the world that they
became benchmark experts overnight and tested git and it sucks, would know
that it is not git that sucks.
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-02 12:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wemxnkk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Quite honestly, a script that indiscriminately touches everybody
> but only modifies a few is simply broken. Think about "make".
> "git diff" reporting many cache-dirty files is simply reminding
> you the brokenness of such a script.
I wouldn't call this "broken", but clearly suboptimal, yes. But for an
occasionnal one-liner (perl -pi -e ... or so), I lose less time
recompiling extra-files than I would writting a cleaner script. "make"
has no way to detect the absence of modification, while git has.
--
Matthieu
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Matthieu Moy @ 2007-08-02 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4y6xnw4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> The default should be tuned for users who perform manual editing
> with status checks. And power users like yourself who run "bulk
> touch indiscriminately but modify only some" scripts should
> learn to run git-status (or "update-index --refresh") after such
> operation. Swapping the defaults to optimize for the abnormal
> case is madness.
I fully agree that git should be optimized for the common case. But
even for the common case, I also find the feature strange. You didn't
answer that part of my message, but I still fail to see a rationale
for making "git-diff; git-status" different from "git-status; git-diff".
IOW, why should people running git-status before git-diff not get a
reminder if you think people running git-diff without or before
git-status should get it?
--
Matthieu
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Johannes Schindelin @ 2007-08-02 10:48 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqbqdq45ua.fsf@bauges.imag.fr>
Hi,
On Thu, 2 Aug 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 2 Aug 2007, Matthieu Moy wrote:
> >
> >> > If the feature still makes sense in the modern world is a
> >> > different story, but I do find it useful.
> >>
> >> I understand that it can be usefull, but I really don't like having it
> >> by default (is there a way to deactivate it BTW?).
> >
> > Yes. Just call "git status" and be done with it.
>
> That's not what I mean (my original message mentionned that already
> BTW). By "deactivate", I mean "make git-diff never show empty diffs".
> I don't want to run two commands where I need only one.
Then don't touch the files you do not want to touch! Or if you want to
have it convenient, and have a script that touches everything, even if it
does not change the contents, just add "git add -u" at the end of the
script". Not that difficult.
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-08-02 10:45 UTC (permalink / raw)
To: Asger Ottar Alstrup; +Cc: git
In-Reply-To: <f8rv65$1b3$1@sea.gmane.org>
Hi,
On Thu, 2 Aug 2007, Asger Ottar Alstrup wrote:
> Johannes Schindelin wrote:
> > On Wed, 25 Jul 2007, Dmitry Kakurin wrote:
> >
> > > How serious are you guys about Windows support?
> >
> > Okay, let's talk business:
> >
> > Pay me decently, and you will have to wait for a few weeks.
>
> I propose that you set up a fundable:
>
> http://fundable.com/
>
> This is a system where anyone can contribute money to the project, but not
> have to pay unless the required amount of money has been contributed in total.
>
> Figure out your price, describe what you will deliver, and announce it.
I am not that much interested in money, really. But I do want to get
something back in return for my efforts. And no, this does not include
whining and complaints.
It includes useful bug reports. It includes a willingness to keep working
with me until the bugs are fleshed out. It possibly includes making (and
maintaining!) an installer.
At the moment, I am happy to say that Git works for me. Even on Windows.
I have no problems with the command line, and both Cygwin and MinGW Git do
their job reliably and joyfully here.
But there might come a time when I get into a position much like Shawn,
when I have to work with Aunt and Uncle Tillies, who are not as
clueful and intelligent^W^W^Wused to the command line as I am.
So I want to exploit Open Source, meaning that I give _you_ something, and
_you_ give me something back. And that might very well be just a
suggestion "make the commit button stick out; I did not find it, since
there are so many buttons". Or a nice comic "how to use git". Also a
beer is appreciated. Or whatever.
My complaint "let's talk business" was some (frustrated) way to get the
attention of people who do _not_ give something back, and are astonished
that just complaining will not get them anywhere.
FWIW I just applied for the project "Git on MSys" on SourceForge. Let's
see how this will work out.
Oh, and I will _not_ do such a thing as think about what you might want,
and then proclaim what would be my price for it. You _know_ what you
want, so why don't you just tell me, as a detailed list?
Ciao,
Dscho
^ 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