* Re: Some advanced index playing
From: Junio C Hamano @ 2006-12-03 19:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Alan Chandler
In-Reply-To: <Pine.LNX.4.64.0612031008360.3476@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think that is actually a misfeature.
>
> This _should_ just work. It's the easy and logical way to do it, and it's
> the one that matches all the other behaviours of "git commit" these days.
>
> The reason for the safety valve is actually not really "safety" any more,
> it's purely "historical behaviour". Ie the sanity check is not there
> because you would be doing anything unsafe, but simply because the
> behaviour in this area _changed_, so the semantics are different from what
> they were originally.
> ...
> Or at _least_ there should be a flag to force it.
>
> Junio?
I agree that if this sequence:
$ edit foo
$ git update-index foo
$ edit foo
$ git commit foo
is what the user actually gives from the command line, after
this commit is made, the user would want to _lose_ the state of
foo at the update-index after this commit is made, 100% of the
time (not "most likely", nor "usually", but "always"). So I am
very in favor of removing that check.
I am a bit worried if the reason behind this safety valve might
have been something else, and we describe the reason as "we
would lose data with this sequence otherwise" only to illustrate
what's happening behind the scene in technical terms.
In other words, while I think no user would ever want to keep
the state of foo at update-index after the above exact sequence
as the end-user action, I am worried if a usage sequence that
involve a group of operations encapsulated in a larger command
(a synthetic command that touches index and working files
without making the user painfully aware of the index -- likes of
git-mv, git-rm, ...) might have been the true motivation of the
safety valve.
I need to be reminded by somebody who went back to the list
discussion around the time we introduced --only, and made sure
that the "you would lose the snapshot you staged in the index if
we allowed it" literally meant only that and nothing else; not
some other common sequence that had the above command sequence
inside, and keeping the state of 'foo' at update-index time made
sense for that usage pattern, although I do not think of
anything offhand...
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-03 19:33 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612021114270.3476@woody.osdl.org>
On Saturday 2006, December 02 19:41, Linus Torvalds wrote:
> Now, I'm not exactly sure who wants to use git modules, so this is the
> time to ask: did you hate the CVS/modules file? Or was it something you
> set up once, and then basically forgot about? People clearly use the
> ability to mark certain modules as depending on each other, and aliases to
> say "if you ask for this module, you actually get a set of _these_
> modules".
Never used CVS/modules, but I used svn:externals. I have a few projects that
are libraries that I use in many other projects. So, my directory tree looks
like this:
projects/
libX/
projectP/
libX/
projectQ/
libX/
The nightmare I had was that I would add a feature to projectP/libX, and
commit it. Great. Then later I'd do "svn update" in projectQ - HAVING MADE
NO CHANGES TO IT - and libX would update to the latest version, which turns
out to be incompatible with projectQ, and I can no longer even build
projectQ. If only libX would stay where it was put. The worst of it is if
you check out an older version, say "stable-release" that you tagged last
year, the svn:external would always just check out the latest version, so
you'd have to go back through the logs to find out what approximate submodule
revision you should really check out, check it out and then remember not to
do svn update, because that would just reset the external to the latest
version. AHHHHHHH! Maddening to say the least.
This fits exactly with what you have described as the primary reason for
wanting submodules. I didn't want seamless integration, I was happy to
change into projectP/libX to make libX commits. All I actually wanted was
the particular checkout of libX for a particular checkin of projectP to be
remembered. That's it. Anything else is just gravy.
I'm doing exactly the same sort of thing now but with git. git hasn't fixed
the problem (yet) but certainly hasn't made it any worse than it was.
svn:externals were nothing more than a way of storing a URL in the
repository - who cares, I wish now I'd never bothered, they serve no version
control purpose and are merely a UI convenience.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: [PATCH] Document git-diff whitespace flags -b and -w
From: Johannes Schindelin @ 2006-12-03 19:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekv5k6$1ih$1@sea.gmane.org>
Hi,
On Sun, 3 Dec 2006, Jakub Narebski wrote:
> Alternate solution would be to fix documentation, to document existing
> code. I used GNU diff documentation, perhaps it is better if we are GNU
> diff compatibile...
Since the whole point of "-w/-b" is to steal the nice feature from GNU
diff, it does not make any sense breaking compatibility.
BTW on top of my patch you need this, if you want the tests to pass
(danger ahead: intentional white space at eol):
-- snip --
make tests pass for recent "diff -b" change
---
Am I the only one finding it funny to read diffs of diffs,
especially when being used to combined diffs?
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 1bc5b7a..adf4993 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -109,12 +109,10 @@ index d99af23..8b32fb5 100644
+ whitespace at beginning
whitespace change
-whitespace in the middle
--whitespace at end
+white space in the middle
-+whitespace at end
+ whitespace at end
unchanged line
--CR at endQ
-+CR at end
+ CR at endQ
EOF
git-diff -b > out
^ permalink raw reply related
* Re: [RFC/PATCH] git-show: also handle blobs
From: Jakub Narebski @ 2006-12-03 19:03 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612031952050.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> DESCRIPTION
> -----------
> -Shows commit log and textual diff for a single commit. The
> -command internally invokes 'git-rev-list' piped to
> -'git-diff-tree', and takes command line options for both of
> -these commands. It also presents the merge commit in a special
> -format as produced by 'git-diff-tree --cc'.
> +Shows a commit or blob. In case of a commit it shows the
> +log message and textual diff for a single commit. It also
> +presents the merge commit in a special format as produced by
> +'git-diff-tree --cc'.
>
> This manual page describes only the most frequently used options.
>
This loses the information that you can use all the options
of git-diff-tree and all the options of git-rev-list in git-show.
But I agre that technical information should not be in DESCRIPTION
section of manpage... perhaps later, if it is needed.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [RFC/PATCH] git-show: also handle blobs
From: Johannes Schindelin @ 2006-12-03 18:54 UTC (permalink / raw)
To: git
Now you can say "git show v1.4.4.1:Makefile" and it pipes the requested
contents into your favourite pager.
While at it, the manpage for -show is updated; it no longer pipes
anything, but rather uses the internal revision walking machinery. Better
not mention it at all.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This combines the "wouldn't it be nice to have git-cat or
git-less" wishes with "we do not want to clutter up the
namespace any more.
If people like this approach, we could easily enhance this patch
to be a synonym for "-p cat-file -p" for _every_ non-commit on the
command line.
Documentation/git-show.txt | 11 +++++------
builtin-log.c | 12 ++++++++++++
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index 4c880a8..9d4e93e 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -3,7 +3,7 @@ git-show(1)
NAME
----
-git-show - Show one commit with difference it introduces
+git-show - Show one blob or one commit with difference it introduces
SYNOPSIS
@@ -12,11 +12,10 @@ SYNOPSIS
DESCRIPTION
-----------
-Shows commit log and textual diff for a single commit. The
-command internally invokes 'git-rev-list' piped to
-'git-diff-tree', and takes command line options for both of
-these commands. It also presents the merge commit in a special
-format as produced by 'git-diff-tree --cc'.
+Shows a commit or blob. In case of a commit it shows the
+log message and textual diff for a single commit. It also
+presents the merge commit in a special format as produced by
+'git-diff-tree --cc'.
This manual page describes only the most frequently used options.
diff --git a/builtin-log.c b/builtin-log.c
index 7acf5d3..c252c40 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -85,6 +85,18 @@ int cmd_show(int argc, const char **argv, const char *prefix)
rev.ignore_merges = 0;
rev.no_walk = 1;
cmd_log_init(argc, argv, prefix, &rev);
+ if (rev.pending.nr == 1
+ && rev.pending.objects[0].item->type == OBJ_BLOB) {
+ unsigned long size;
+ char type[20];
+ void *buf = read_sha1_file(rev.pending.objects[0].item->sha1,
+ type, &size);
+ if (!buf)
+ return error("Could not read blob?");
+ fwrite(buf, size, 1, stdout);
+ free(buf);
+ return 0;
+ }
return cmd_log_walk(&rev);
}
--
1.4.4.1.g317bd
^ permalink raw reply related
* Re: [PATCH] Document git-diff whitespace flags -b and -w
From: Jakub Narebski @ 2006-12-03 18:38 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612031908020.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sun, 3 Dec 2006, Jakub Narebski wrote:
>
>> +--ignore-space-change::
>> + Ignore changes in amount of white space. This ignores white
>> + space at line end, and consider all other sequences of one or
>> + more white space characters to be equivalent.
>
> Thank you for bringing this up. The latter part is correct, but the first
> part not yet. I asked at the time if somebody cares, but got no answer, so
> "-b" does _not_ ignore white space at the end of line ATM, but only white
> space change. So here is a patch to fix that behaviour:
Alternate solution would be to fix documentation, to document existing code.
I used GNU diff documentation, perhaps it is better if we are GNU diff
compatibile...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Some advanced index playing
From: Linus Torvalds @ 2006-12-03 18:34 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200612031701.15594.alan@chandlerfamily.org.uk>
On Sun, 3 Dec 2006, Alan Chandler wrote:
>
> c) Revert the entire index back to the state it was at the last commit so I
> can selectively add back in the files that I have editted.
>
> The command to do that seems to be
>
> git-read-tree HEAD
A side note on this..
It definitely works, but it's not really the right thing to do for a few
reasons:
- it isn't even what you wanted. You didn't want to reset _all_ the index
values, you only really wanted to reset a few of them. So as mentioned
in the previous email, the command sequence you'd wanted for that
operation is
git ls-tree <tree> -- <path pattern list> |
git update-index --index-info
But, that said, if you actually want to reset the whole index,
"git-read-tree HEAD" works, but is not what you should do:
- you really want to keep the index "stat()" cache valid, and
git-read-tree will throw that all out. So you would need to do a
git update-index --refresh
after you've reset the index ("git status" will do it for you, and if
you don't do either "git status" or the above,
- instead of re-reading the index 100% and then having to refresh it back
to mostly the same stat() into it already had, you can _merge_ the old
index with the information in HEAD, by using
git read-tree -m HEAD
which basically does a merge from the old index and the HEAD tree.
- However, that actually fails if the old index wasn't just dirty, but
had unmerged paths etc, because then a "merge" would throw away that
unmerged information. So what you _really_ want to do is
git read-tree --reset HEAD
which (as the flag implies) will _reset_ the index to the tree in HEAD,
and this will do exactly what you were looking for: keep the "stat()"
information alone, but reset the actual index contents.
- HOWEVER. This is exactly what "git reset" does.
So in short, you should just have done "git reset", and you'd have reset
your index back to the state of your last commit.
So "git reset" is generally your friend whenever something goes wrong. If
you also want to reset your checked-out files (which you did NOT want to
do in this case, of course), you would have added the "--hard" flag to git
reset.
And that (finally) concludes this particularly boring "git usage 101"
session.
^ permalink raw reply
* Re: Some advanced index playing
From: Jakub Narebski @ 2006-12-03 18:31 UTC (permalink / raw)
To: git
In-Reply-To: <200612031701.15594.alan@chandlerfamily.org.uk>
Alan Chandler wrote:
> With all the discussion about the index file in the last few days I would have
> thought that this issue would have come up. But I don't think it has.
>
> I have been editing a set of files to make a commit, and after editing each
> one had done a git update-index.
>
> At this point I am just about to commit when I realise that one of the files
> has changes in it that really ought to be a separate commit.
>
> So effectively, I want to do one of three things
>
> a) git-commit <that-file>
>
> Except I can't because there is a safety valve that prevents this and there is
> no force option.
I do wonder what this safety valve is for, and why it acts also if
index version is equal to working directory version...
> b) Revert the index entry for that file back to the previous HEAD commit
> point, whilst leaving the edits in the working tree, so that I can then
> commit without that one file.
>
> I can't find a command to do that. The nearest seems to be
> git-update-index --remove, but the manual says that it will not do anything
> if the file still exists.
There is "git update-index --force-remove <that-file>". Currently there
is no "git reset -- <that-file>", but you can revert index entry to the
one in HEAD using
$ git ls-tree HEAD -- <that-file> | git update-index --index-info
And you can always try "git-rm + git-add".
> c) Revert the entire index back to the state it was at the last commit so I
> can selectively add back in the files that I have editted.
>
> The command to do that seems to be
>
> git-read-tree HEAD
No, the command for that is just "git reset" (which means
"git reset --mixed HEAD"), and touches HEAD and index but not working
directory
> What happened to the text written here
>
> http://marc.theaimsgroup.com/?l=git&m=116406699903565&w=2
"[DRAFT 2] Branching and merging with git"
> I thought this might be a place to put something like this, but having just
> updated my version of git from source, it doesn't seem to have been put in to
> git anywhere yet.
linux@horizon.com, perhaps you should send this text in the form of patch
creating Documentation/tutorial-3.txt file?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Document git-diff whitespace flags -b and -w
From: Johannes Schindelin @ 2006-12-03 18:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11651630814064-git-send-email-jnareb@gmail.com>
Hi,
On Sun, 3 Dec 2006, Jakub Narebski wrote:
> +--ignore-space-change::
> + Ignore changes in amount of white space. This ignores white
> + space at line end, and consider all other sequences of one or
> + more white space characters to be equivalent.
Thank you for bringing this up. The latter part is correct, but the first
part not yet. I asked at the time if somebody cares, but got no answer, so
"-b" does _not_ ignore white space at the end of line ATM, but only white
space change. So here is a patch to fix that behaviour:
-- snip --
diff -b: ignore whitespace at end of line
This is _not_ the same as "treat eol as whitespace", since that would mean
that multiple empty lines would be treated as equal to e.g. a space.
---
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 9e4bb47..1b899f3 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -230,7 +230,8 @@ unsigned long xdl_hash_record(char const **data, char const *top, long flags) {
while (ptr + 1 < top && isspace(ptr[1])
&& ptr[1] != '\n')
ptr++;
- if (flags & XDF_IGNORE_WHITESPACE_CHANGE) {
+ if (flags & XDF_IGNORE_WHITESPACE_CHANGE
+ && ptr[1] != '\n') {
ha += (ha << 5);
ha ^= (unsigned long) ' ';
}
^ permalink raw reply related
* Re: Some advanced index playing
From: Linus Torvalds @ 2006-12-03 18:24 UTC (permalink / raw)
To: Alan Chandler, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <200612031701.15594.alan@chandlerfamily.org.uk>
On Sun, 3 Dec 2006, Alan Chandler wrote:
>
> With all the discussion about the index file in the last few days I would have
> thought that this issue would have come up. But I don't think it has.
>
> I have been editing a set of files to make a commit, and after editing each
> one had done a git update-index.
>
> At this point I am just about to commit when I realise that one of the files
> has changes in it that really ought to be a separate commit.
>
> So effectively, I want to do one of three things
>
> a) git-commit <that-file>
>
> Except I can't because there is a safety valve that prevents this and there is
> no force option.
I think that is actually a misfeature.
This _should_ just work. It's the easy and logical way to do it, and it's
the one that matches all the other behaviours of "git commit" these days.
The reason for the safety valve is actually not really "safety" any more,
it's purely "historical behaviour". Ie the sanity check is not there
because you would be doing anything unsafe, but simply because the
behaviour in this area _changed_, so the semantics are different from what
they were originally.
But those "original" semantics are now so old and so uninteresting that
the safety feature has gone from being a safety feature to just being
annoying, and hindering you from doing what you want to do.
Side note: you -can- do what you want to do, but it's insanely stupid.
Here's what you'd do:
git ls-tree HEAD -- that-file | git update-index --index-info
git commit that-file
but there is no way in hell I will claim that this is a _good_ thing.
[ That said, the whole
git ls-tree <treeish> -- <file-list> | git update-index --index-info
is a useful pattern to know. You can basically insert _any_ part of old
historical state into the index with this, which can be useful if you
want to play games without changing the _other_ parts of the index. ]
So anyway, I would suggest that we just get rid of that partial commit
"safety check" in "git commit" for now. It still makes sense for when
you're in the middle of a _merge_, but the "verify that index matches" is
not worth it.
Or at _least_ there should be a flag to force it.
Junio?
^ permalink raw reply
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Florian Weimer @ 2006-12-03 18:23 UTC (permalink / raw)
To: git
In-Reply-To: <20061128220605.GA1253@localdomain>
* Eric Wong:
> finish_report does seem to return a useful value indicating success
> or failure, so we'll just set a flag when close_edit is called
> (it is not called on failures, nor is abort_edit) and check
> the flag before proceeding.
It seems that this needs some kind of fine-tuning. Now that git-svn
uses HTTP keepalive connections, you get a HTTP request error once you
run into the server-side request limit. It seems a bit excessive to
^ permalink raw reply
* Re: [EGIT PATCH] Convert author and comment on demand.
From: Linus Torvalds @ 2006-12-03 18:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekug7o$35c$1@sea.gmane.org>
On Sun, 3 Dec 2006, Jakub Narebski wrote:
>
> It is easier to comment on patch if it is embedded in the mail, and not
> in attachement.
This is why I _hate_ patches in attachments.
Sure, I can make my mail reader show the attachments. But when I "reply",
I want the patch to be indented with the regular "> " thing and visible in
the reply, so that I can say "I like the patch in general, but <this> part
of it is seriously broken".
And yes, the personal mailreader I have has a "include attachements in
reply" mode. But I don't generally want to include attachments in any
reply, I just want it for _patches_.
[ Side ntoe: besides, many people send broken attachments that aren't
marked as text, but as 8-bit binary data or something, even if it's a
text-patch - so "attachement problems" are almost as common as the
non-attachement "line wrap" or whitespace problems are - people who
think that attachments automatically means that the thing is correct are
just deluding themselves.
The fact is, you can get attachments wrong exactly the same way you get
linewrapping wrong. It's just that the pure binary data is likely to
always make it through correctly with an attachment, but if it gets
marked as a binary MIME-type, that doesn't much help, because while the
data is there, it's still going to act the wrong way for any
_discussion_ about it. ]
In other words: there are lots of things that make sense as true
attachments. It's just that "patch" is not one of them.
Patches, unlike for example full files or tar-balls, by their very design
are (a) text and (b) something where the whole _point_ is discussion and
quoting about them. If we didn't want to discuss the patch contents, we
wouldn't send them as patches in the first place, they'd be git-to-git
transfers.
So this all boils down to one thing:
PATCHES ARE NOT SEPARATE FILES TO BE ATTACHED TO AN EMAIL.
Patches are to be considered part of the discussion, not separate. And
thus they should be in the main body of the email, exactly so that people
(regardless of mailer settings and details like that) will automatically
quote them, and they get passed around as integral to the discussion as
the discussion itself.
I just jumped in because this is a pet peeve of mine. Some people seem to
think that patches are "binary files" just because they have whitespace
requirements and line-wrapping matters. But whitespace and line wrapping
is important even in regular discussion, and patches really _are_ about
the _human_ communication, just as much - and perhaps more so - as they
are about feeding to the "patch" program.
^ permalink raw reply
* Re: jgit performance update
From: Jakub Narebski @ 2006-12-03 17:56 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612030938140.3476@woody.osdl.org>
Linus Torvalds wrote:
> Also, I have to say, one of the reasons I'm interested in your project is
> that I've never done any Java programming, because quite frankly, I've
> never had any reason what-so-ever to do so. But if there is some simple
> setup, and you have jgit exposed somewhere as a git archive, I'd love to
> take a look, if only to finally learn more about Java.
GitWiki tells us about egit/jgit repository at
http://www.spearce.org/projects/scm/egit.git
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-12-03 17:54 UTC (permalink / raw)
To: Torgil Svensson; +Cc: sf-gmane, sf, git, Martin Waitz
In-Reply-To: <e7bda7770612030119v197cbc95h6b3fa9e22b78c058@mail.gmail.com>
On Sun, 3 Dec 2006, Torgil Svensson wrote:
>
> On 12/2/06, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > In other words, I don't think people expect or want something hugely more
> > complicated than the CVS/modules kind of file.
>
> What about the case when you want _everything_, do you then have to
> know the names of all submodules, present and past?
Afaik, the way people do this historically is simply:
- often have an alias for "everything" (eg "all" or "src" or "world"),
and if you want everything, you basically ask for it by checking out
the "src" module.
Ie this is the "upstream" way to let downstream check out everything.
- if you're downstream, and you have a partial repo, and you realize that
you want everything else, you just look at gitweb (assuming it is
extended to show module information, of course ;) or the .gitmodules
(or whatever it would be called) file to get the other pieces manually.
But hey, I also think it would be fine to have "git clone --allmodules" or
something ("fetch" too). I think this whole question will depend more on
how people end up _using_ module support than on any technical issues per
se. Again, I suspect the people who now set up modules in CVS are likely
to have a better idea than I do about how they usually do it (and why).
> If you have an old irrelevant submodule in the history that happens to
> have the same name as one of them you are interested in, do you get
> this as well?
I dunno. Details, details. I'm also not sure this is hugely important.
It could be "solved" by simply having the requirement that all modules
need to be named differently (notice that "module name" is _not_ the same
thing as "the directory name where the module shows up". That's not the
case even in CVS modules, and with a "link" type in the git tree object,
the directory where a module shows up would basically be totally
independent of the "name" of the module).
> During a debugging session it might be convenient to do a "all but X"
> kind of fetch if you have a project dependent on several small modules
> and one of them is the big black sheep.
I suspect it's more common to name the modules you want to fetch
explicitly, rather than make it a "negative" choice, but that sounds
largely like just an interface issue.
^ permalink raw reply
* Re: jgit performance update
From: Linus Torvalds @ 2006-12-03 17:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061203045953.GE26668@spearce.org>
On Sat, 2 Dec 2006, Shawn Pearce wrote:
>
> With the help of Robin Rosenberg I've been able to make jgit's log
> operation run (on average) within a few milliseconds of core Git.
Very good. Are we any closer to actually having an eclipse plugin then?
Not that I've ever actually used eclipse, but maybe I should try it, just
to see what those strange user-land people actually do. I'll be a
veritable Jane Goodall..
> Walking the 50,000 most recent commits from the Mozilla trunk[1]:
>
> $ time git rev-list --max-count=50000 HEAD >/dev/null
>
> core Git: 1.882s (average)
> jgit: 1.932s (average)
>
> (times are with hot cache and from repeated executions)
Now, the _interesting_ case in many ways is not "--max-count", but the
revision limiter. It _should_ be equally fast, but if you've done
something wrong, it won't be.
IOW, try to find a point far enough back in time to get about the same
number of commits, and then do
time git rev-list <thatpoint>..HEAD >/dev/null
because one of the things you want to handle is ranges, more so than
simple counts. And that is not only the much more common case, it also
triggers a few cases that you probably didn't trigger with the regular
"list the first 50 thousand commits" case.
> One of the biggest annoyances has been the fact that although Java
> 1.4 offers a way to mmap a file into the process, the overhead to
> access that data seems to be far higher than just reading the file
> content into a very large byte array, especially if we are going
> to access that file content multiple times.
That must suck for big packed repositories. What JVM and other environment
are you using?
Also, I have to say, one of the reasons I'm interested in your project is
that I've never done any Java programming, because quite frankly, I've
never had any reason what-so-ever to do so. But if there is some simple
setup, and you have jgit exposed somewhere as a git archive, I'd love to
take a look, if only to finally learn more about Java.
^ permalink raw reply
* Some advanced index playing
From: Alan Chandler @ 2006-12-03 17:01 UTC (permalink / raw)
To: git
With all the discussion about the index file in the last few days I would have
thought that this issue would have come up. But I don't think it has.
I have been editing a set of files to make a commit, and after editing each
one had done a git update-index.
At this point I am just about to commit when I realise that one of the files
has changes in it that really ought to be a separate commit.
So effectively, I want to do one of three things
a) git-commit <that-file>
Except I can't because there is a safety valve that prevents this and there is
no force option.
b) Revert the index entry for that file back to the previous HEAD commit
point, whilst leaving the edits in the working tree, so that I can then
commit without that one file.
I can't find a command to do that. The nearest seems to be
git-update-index --remove, but the manual says that it will not do anything
if the file still exists.
c) Revert the entire index back to the state it was at the last commit so I
can selectively add back in the files that I have editted.
The command to do that seems to be
git-read-tree HEAD
I tried this, and it did indeed seem to exactly this - not quite what I
wanted, but actually a reasonable compromise.
However, it took me a long time scanning possible commands before I found it
so I thought I might add some text to one of the tutorials
Any ideas of where?
What happened to the text written here
http://marc.theaimsgroup.com/?l=git&m=116406699903565&w=2
I thought this might be a place to put something like this, but having just
updated my version of git from source, it doesn't seem to have been put in to
git anywhere yet.
--
Alan Chandler
^ permalink raw reply
* Re: [PATCH] git-svn: avoid fetching files twice in the same revision
From: Florian Weimer @ 2006-12-03 16:42 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061203001930.GA468@soma>
* Eric Wong:
> + foreach (keys %amr) {
> + libsvn_get_file($gui, $_, $rev, $amr{$_});
You could throw in a "sort". Perhaps the improved locality helps the
server a bit.
^ permalink raw reply
* [PATCH] Document git-diff whitespace flags -b and -w
From: Jakub Narebski @ 2006-12-03 16:24 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Document git diff options -b / --ignore-space-change and
-w / --ignore-all-space, introduced by Johannes Schindelin
in commit 0d21efa51cc7de5250d5da46bceacda78ba35373:
"Teach diff about -b and -w flags".
The description of options is taken from GNU diff man page and
GNU Diffutils info documentation.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Inspired by kblin (Kai Blin) asking on #git about git-diff option to
ignore whitespace only change.
Documentation/diff-options.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index e112172..9cdd171 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -129,5 +129,21 @@
-a::
Shorthand for "--text".
+--ignore-space-change::
+ Ignore changes in amount of white space. This ignores white
+ space at line end, and consider all other sequences of one or
+ more white space characters to be equivalent.
+
+-b::
+ Shorthand for "--ignore-space-change".
+
+--ignore-all-space::
+ Ignore white space when comparing lines. This ignores
+ difference even if one line has white space where the other
+ line has none.
+
+-w::
+ Shorthand for "--ignore-all-space".
+
For more detailed explanation on these common options, see also
link:diffcore.html[diffcore documentation].
--
1.4.4.1
^ permalink raw reply related
* Re: jgit performance update
From: Robin Rosenberg @ 2006-12-03 15:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekumdo$imo$1@sea.gmane.org>
söndag 03 december 2006 15:19 skrev Jakub Narebski:
> Robin Rosenberg wrote:
> > CVS-induced brain damage, I should track the content. next version.
> > filenames are so much handier to work with).
>
> Git uses <path> as _revision limiter_, not as output filter. Shouldn't
> jgit do the same?
It's egit, i.e. the eclipse plugin I'm referring to so it's a user interface
thing and it uses the path name.
^ permalink raw reply
* Re: jgit performance update
From: Jakub Narebski @ 2006-12-03 14:19 UTC (permalink / raw)
To: git
In-Reply-To: <200612031455.48032.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> söndag 03 december 2006 05:59 skrev Shawn Pearce:
>
>> With the help of Robin Rosenberg I've been able to make jgit's log
>> operation run (on average) within a few milliseconds of core Git.
>>
>> Walking the 50,000 most recent commits from the Mozilla trunk[1]:
>>
>> $ time git rev-list --max-count=50000 HEAD >/dev/null
>>
>> core Git: 1.882s (average)
>> jgit: 1.932s (average)
>>
>> (times are with hot cache and from repeated executions)
> Nice indeed. That was a ten-fold improvement for getting my full history.
>
> So, just go on to the next case. I added filtering on filenames (yes,
> CVS-induced brain damage, I should track the content. next version. filenames
> are so much handier to work with).
Git uses <path> as _revision limiter_, not as output filter. Shouldn't
jgit do the same?
P.S. What is the status of --follow option?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [BUG] git-mv fails with "source directory is empty" when it should not
From: Sergey Vlasov @ 2006-12-03 13:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
Hello!
In some cases git-mv fails with "source directory is empty" when this
is definitely not the case.
Example (run in an empty directory):
$ git init-db
defaulting to local storage area
$ mkdir ab; touch ab.c; touch ab/d
$ git add .
$ git commit -m 'initial'
Committing initial tree f2dd231ec22a1d4376d4a6eadf49d87dd34ac2a0
$ git mv ab a
fatal: source directory is empty, source=ab, destination=a
However, at this point the source directory is definitely not empty:
$ git ls-tree -r HEAD
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ab.c
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 ab/d
$ ls -ogR
.:
total 4
drwxr-xr-x 2 4096 Dec 3 16:47 ab
-rw-r--r-- 1 0 Dec 3 16:47 ab.c
./ab:
total 0
-rw-r--r-- 1 0 Dec 3 16:47 d
$ git status
nothing to commit
This happens both in v1.4.4.1 and in current 'master' (v1.4.4.1-g278fcd7).
--
Sergey Vlasov
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: jgit performance update
From: Robin Rosenberg @ 2006-12-03 13:55 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061203045953.GE26668@spearce.org>
söndag 03 december 2006 05:59 skrev Shawn Pearce:
> With the help of Robin Rosenberg I've been able to make jgit's log
> operation run (on average) within a few milliseconds of core Git.
>
> Walking the 50,000 most recent commits from the Mozilla trunk[1]:
>
> $ time git rev-list --max-count=50000 HEAD >/dev/null
>
> core Git: 1.882s (average)
> jgit: 1.932s (average)
>
> (times are with hot cache and from repeated executions)
Nice indeed. That was a ten-fold improvement for getting my full history.
So, just go on to the next case. I added filtering on filenames (yes,
CVS-induced brain damage, I should track the content. next version. filenames
are so much handier to work with). That gives me 4.5s to retrieve a filtered
history (from 10800 commits).Half of the time is spent in re-sorting tree
entries. Is that really necessary?
> I think that is actually pretty good given that jgit is written
> in Java using a fairly object-oriented design and has to deal with
> some of the limitations of the language.
Most of java's slowness comes from the programmers using it. (Lutz Prechelt.
Technical opinion: comparing Java vs. C/C++ efficiency differences to
interpersonal differences. ACM, Vol 42,#10, 1999)
> One of the biggest annoyances has been the fact that although Java
> 1.4 offers a way to mmap a file into the process, the overhead to
> access that data seems to be far higher than just reading the file
> content into a very large byte array, especially if we are going
> to access that file content multiple times. So jgit performs worse
> than core Git early on while it copies everything from the OS buffer
> cache into the Java process, but then performs reasonably well once
> the internal cache is hot. On the other hand using the mmap call
> reduces early latency but hurts the access times so much that we're
> talking closer to 3s average read times for the same log operation.
Have you tried that with difference JVM's?
^ permalink raw reply
* Re: [EGIT PATCH] Convert author and comment on demand.
From: Jakub Narebski @ 2006-12-03 12:34 UTC (permalink / raw)
To: git
In-Reply-To: <200612031318.33332.robin.rosenberg@dewire.com>
Robin Rosenberg wrote:
> söndag 03 december 2006 03:16 skrev Shawn Pearce:
>>
>> Something's wrong with your mail client... the patch was mangled.
>
> Not really, only the user. KMail by default wraps lines and I didn't turn that
> off before sending. Usually I send patches just using stg mail, but this time
> I used git-format-patch and kmail. Generatig attachements may be better (next
> time).
It is easier to comment on patch if it is embedded in the mail, and not
in attachement. Just remember to turn off word wrapping before sending
the patch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jakub Narebski @ 2006-12-03 12:31 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200612031322.54748.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> söndag 03 december 2006 02:31 skrev Jakub Narebski:
>
>> Actually, rm -rf * is not needed for "git reset --hard" or
>> "git checkout -f" to succeed.
>
> True, but git reset --hard isn't always enough and rm -rf * is the good ol'
> way of resetting things. Typically this comes from make being upset (or too
> content) with something.
$ git clean -d -x -q
$ git reset --hard
(or vice versa) then.
Besides, "rm -rf *" should not remove hidden files and hidden directories,
including .git directory. And you should take great care with "rm -rf .*"
if it doesn't follow '..'
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Robin Rosenberg @ 2006-12-03 12:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612030231.05900.jnareb@gmail.com>
söndag 03 december 2006 02:31 skrev Jakub Narebski:
> Actually, rm -rf * is not needed for "git reset --hard" or
> "git checkout -f" to succeed.
True, but git reset --hard isn't always enough and rm -rf * is the good ol'
way of resetting things. Typically this comes from make being upset (or too
content) with something.
^ 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