* gitwiki/EclipsePlugin
From: M @ 2008-06-25 16:34 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi list,
I felt quite helpless when trying to get egit running as neither
http://git.or.cz/gitwiki/EclipsePlugin nor the README/INSTALL aren't
overly verbose.
I put the idiot-proof recipe on
http://wiki.jcurl.org/index.php5?title=GitSvn#Eclipse_Plugin - maybe you
can weave it into either wiki or INSTALL?
Greetings,
M
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhic34ACgkQO26gbdBiJqZiCwCeMFLgBKVR1Gl6U7WDDMHr/ogN
H3YAnApFMSrY56+9bT4bJOb99kjZuv0P
=Xz9D
-----END PGP SIGNATURE-----
^ permalink raw reply
* update-index --assume-unchanged doesn't make things go fast
From: Avery Pennarun @ 2008-06-25 16:44 UTC (permalink / raw)
To: Git Mailing List
Hi all,
Using git 1.5.6.64.g85fe, but this applies to various other versions I've tried.
I have a git repo with about 17000+ files in 1000+ directories. In
Linux, "git status" runs in under a second, which is perfectly fine.
But on Windows, which can apparently only stat() about 1000 files per
second, "git status" takes at least 17 seconds to run, even with a hot
cache. (I've confirmed that stat() is so slow on Windows by writing a
simple program that just runs stat() in a tight loop. The slowness
may be cygwin-related, as I found some direct Win32 calls that seem to
go more than twice as fast... which is still too slow.)
"git status" is not so important, since I can choose not to run it.
But it turns out that every git checkout and git commit does all the
same stuff, which is really not so great. Even worse if you consider
that "git status" is almost always what I do by hand anyway to check
things before I commit.
So anyway, I read about the git-update-index --assume-unchanged
option, and thought that might be just what I want. So I did this
(back in Linux, where things are easier to debug):
$ strace -fe lstat64 git status 2>&1 | wc -l
17869
$ git ls-files | xargs -d '\n' git update-index --assume-unchanged
$ strace -fe lstat64 git status 2>&1 | wc -l
33
So far, so good, and "git status" is now noticeably faster on my Linux
system (maybe twice as fast). It's also noticeably faster on my
Windows system, but not as fast as I would have hoped. I've tracked
it down to this:
$ strace -fe getdents64 git status 2>&1 | wc -l
2729
"git status" still checks all the *directories* to see if there are
any new files. Of course! --assume-unchanged can't be applied to a
directory, so there's no way to tell it not to do so.
Also, "git diff" is still as slow as ever:
$ strace -fe lstat64 git diff 2>&1 | wc -l
23199
It seems to be stat()ing the files even though they are
--assume-unchanged, which is probably a simple bug.
And while we're here, "git checkout" seems to be working a lot harder
than it should be:
$ strace -fe lstat64 git checkout -b boo 2>&1 | wc -l
23227
Note that I'm just creating a new branch name here, not even checking
out any new files, so I can't think of any situation where the
checkout would fail. Is there one?
Even if I checkout a totally different branch, presumably it should
only need to stat() the files that changed between the old and new
versions, right? And that would normally be very fast.
I don't mind doing some of the work to improve things here, as long as
people can give me some advice. Specifically:
1) What's a sensible way to tell git to *not* opendir() specific
directories to look for unexpected files in "git status"? (I don't
think I know enough to implement this myself.)
2) Do you think git-diff should honour --assume-unchanged? If not, why not?
3) Do you think git-checkout can be optimized here? I can see why it
might want to disregard --assume-unchanged (for safety reasons), but
presumably it only needs to look at all at files that it's planning to
change, right?
4) My idea is to eventually --assume-unchanged my whole repository,
then write a cheesy daemon that uses the Win32 dnotify-equivalent to
watch for files that get updated and then selectively
--no-assume-unchanged files that it gets notified about. That would
avoid the need to ever synchronously scan the whole repo for changes,
thus making my git-Win32 experience much faster and more enjoyable.
(This daemon ought to be possible to run on Linux as well, for similar
improvements on gigantic repositories. Also note that TortoiseSVN for
Windows does something similar to track file status updates, so this
isn't *just* me being crazy.)
Thoughts?
Thanks,
Avery
^ permalink raw reply
* Fix t5303 (the test case for pack corruptions) on Windows
From: Alex Riesen @ 2008-06-25 16:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nicolas Pitre
In-Reply-To: <alpine.LFD.1.10.0806232123420.2979@xanadu.home>
The perldiag(1) has following to say about this:
"Can't do inplace edit without backup"
(F) You're on a system such as MS-DOS that gets confused if
you try reading from a deleted (but still opened) file. You
have to say -i.bak, or some such.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5303-pack-corruption-resilience.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5303-pack-corruption-resilience.sh b/t/t5303-pack-corruption-resilience.sh
index b0f5693..31b20b2 100755
--- a/t/t5303-pack-corruption-resilience.sh
+++ b/t/t5303-pack-corruption-resilience.sh
@@ -90,7 +90,7 @@ test_expect_success \
'create_new_pack &&
git prune-packed &&
chmod +w ${pack}.pack &&
- perl -i -pe "s/ base /abcdef/" ${pack}.pack &&
+ perl -i.bak -pe "s/ base /abcdef/" ${pack}.pack &&
test_must_fail git cat-file blob $blob_1 > /dev/null &&
test_must_fail git cat-file blob $blob_2 > /dev/null &&
test_must_fail git cat-file blob $blob_3 > /dev/null'
@@ -138,7 +138,7 @@ test_expect_success \
'create_new_pack &&
git prune-packed &&
chmod +w ${pack}.pack &&
- perl -i -pe "s/ delta1 /abcdefgh/" ${pack}.pack &&
+ perl -i.bak -pe "s/ delta1 /abcdefgh/" ${pack}.pack &&
git cat-file blob $blob_1 > /dev/null &&
test_must_fail git cat-file blob $blob_2 > /dev/null &&
test_must_fail git cat-file blob $blob_3 > /dev/null'
--
1.5.6.28.g6f71b
^ permalink raw reply related
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-25 17:22 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Johannes Sixt, Boaz Harrosh, Steven Walter,
git, jeske
In-Reply-To: <20080625135100.GF20361@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> I used to argue for this, but gave up, because no one seemed to agree
> with me. So now I just have the following in
> /home/tytso/bin/git-revert-file and I am very happy:
>
> #!/bin/sh
> #
> prefix=$(git rev-parse --show-prefix)
>
> for i in $*
> do
> git show HEAD:$prefix$i > $i
> done
Isn't that this?
#!/bin/sh
exec git checkout HEAD -- "$@"
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Junio C Hamano @ 2008-06-25 17:34 UTC (permalink / raw)
To: Theodore Tso; +Cc: David Jeske, git
In-Reply-To: <20080625133458.GE20361@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> And when you have shared push repositories, as long as users don't use
> the '+', in practice they can only add new changes. And if you don't
> trust them not to use the '+' character in refspecs, are you really
> going to trust them not to introduce either bone-headed mistakes into
> the code?
Well, if you do not trust them, just set receive.denynonfastforwards
and they won't be able to.
^ permalink raw reply
* Re: update-index --assume-unchanged doesn't make things go fast
From: Michael J Gruber @ 2008-06-25 17:38 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130806250944x717cf609x7aa520c77a7c6911@mail.gmail.com>
Avery Pennarun venit, vidit, dixit 25.06.2008 18:44:
...
> 4) My idea is to eventually --assume-unchanged my whole repository,
> then write a cheesy daemon that uses the Win32 dnotify-equivalent to
> watch for files that get updated and then selectively
> --no-assume-unchanged files that it gets notified about. That would
> avoid the need to ever synchronously scan the whole repo for changes,
> thus making my git-Win32 experience much faster and more enjoyable.
> (This daemon ought to be possible to run on Linux as well, for similar
> improvements on gigantic repositories. Also note that TortoiseSVN for
> Windows does something similar to track file status updates, so this
> isn't *just* me being crazy.)
Looks like users on slow NFS would profit, too. Hate to say it, but hg
feels faster on (slow) NFS than git. Yet I use git, for other reasons ;)
Michael
^ permalink raw reply
* Re: Fix t5303 (the test case for pack corruptions) on Windows
From: Junio C Hamano @ 2008-06-25 17:42 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nicolas Pitre
In-Reply-To: <20080625164438.GA4039@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> The perldiag(1) has following to say about this:
>
> "Can't do inplace edit without backup"
>
> (F) You're on a system such as MS-DOS that gets confused if
> you try reading from a deleted (but still opened) file. You
> have to say -i.bak, or some such.
Thanks. By the way, there are others.
t/t9106-git-svn-dcommit-clobber-series.sh:23: perl -i -p -e "s/^58$/5588/" file &&
t/t9106-git-svn-dcommit-clobber-series.sh:24: perl -i -p -e "s/^61$/6611/" file &&
t/t9106-git-svn-dcommit-clobber-series.sh:43: perl -i -p -e 's/^4\$/4444/' file &&
t/t9106-git-svn-dcommit-clobber-series.sh:44: perl -i -p -e 's/^7\$/7777/' file &&
templates/hooks--prepare-commit-msg.sample:25: perl -i -ne 's/^/# /, s/^# #/#/ if /^Conflicts/ .. /#/; print' "$1" ;;
templates/hooks--prepare-commit-msg.sample:28:# perl -i -pe '
^ permalink raw reply
* Re: [PATCH] Ask for "git program" when asking for "git-program" over SSH connection
From: Junio C Hamano @ 2008-06-25 17:42 UTC (permalink / raw)
To: Theodore Tso
Cc: Shawn O. Pearce,
しらいしななこ,
Miklos Vajna, pclouds, Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080625130646.GD20361@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Tue, Jun 24, 2008 at 10:27:07PM -0700, Junio C Hamano wrote:
> ...
>> The above 6 and 12 are yanked out of thin air and I am of course open to
>> tweaking them, but I think the above order of events would be workable.
>
> Is that really 6 and 12 months, or "6/12 months or at the next major
> release boundary, whichever is later".
Sigh... I thought you by now knew me better than that...
Yes, I didn't say it explicitly because I thought it was too obvious,
which was a mistake. These except for the ones that are preparation (such
as "prepare daemon so that future clients can ask with non-dash forms")
need to happen at release boundaries, but these 6/12 months figures set
the minimums. E.g. even if we had 6 week release cycles and 1.7.0 were to
be done 6 weeks after 1.6.0, that is still too early for the client side
to switch asking for "git program".
^ permalink raw reply
* RE: Windows symlinks
From: Patrick.Higgins @ 2008-06-25 17:50 UTC (permalink / raw)
To: apenwarr; +Cc: jnareb, git
In-Reply-To: <32541b130806241704y3befda90j78329af2f30d95d2@mail.gmail.com>
> From: Avery Pennarun [mailto:apenwarr@gmail.com]
>
> > Agreed. The first thing we started working on was getting
> symlinks out of our repositories.
> > Unfortunately, we chose to use them because we are using
> broken development tools that
> > don't support proper modularity. We found the best way to
>
> Perhaps git-submodule would do what you're looking for.
We might be able to get by with them, but submodules appear to be significantly more complex than symlinks, and we sometimes symlink just a file or two if that's all we need. Splitting up submodules to that level of granularity would be hard to manage.
My understanding of the submodule workflow is:
Projects A, B, and C (we actually have about 17 of these) all share common code in project Common. Then, each of A, B, and C adds Common as a submodule. While working on project A, the need arises to modify Common, so the developer changes it there, commits, pushes the change to Common, then commits and pushes the change to A. To update B and C, they would have to change to each of those projects, run a git pull, then git submodule update, and compile and test.
Is that correct? If so, it's a lot more work than letting a symlink propagate the change to all the other projects. Of course, since Windows doesn't have symlinks...
^ permalink raw reply
* Re: Errors building git-1.5.6 from source on Mac OS X 10.4.11
From: Alex Riesen @ 2008-06-25 17:53 UTC (permalink / raw)
To: Ifejinelo Onyiah; +Cc: git
In-Reply-To: <2eb980790806250620t73ae0ff7heedb65780a66ad00@mail.gmail.com>
Ifejinelo Onyiah, Wed, Jun 25, 2008 15:20:39 +0200:
>
> They all run fine but when I issue the make test command, it dies at
> the following:
>
> % make test
>
> ... TRUNCATED OUTPUT ...
>
> *** t2004-checkout-cache-temp.sh ***
> * FAIL 1: preparation
>
If you don't mind helping the investigation a bit, could you please go
into the t/ directory and run
bash -x t2004-checkout-cache-temp.sh -d -v -i
and post the output here? This diagnostics are much more useful
(well, essential, in this case). Are running the tests on HFS+, BTW?
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Jing Xue @ 2008-06-25 17:56 UTC (permalink / raw)
To: David Jeske; +Cc: git
In-Reply-To: <willow-jeske-01l5xqJDFEDjCftd>
Quoting David Jeske <jeske@google.com>:
> - add "checkout" to the git-gui history right-click menu, and make the
> danger of
> "reset --hard" more obvious and require a confirmation dialog (the gui
> equivilant of -f)
Is that really necessary? The way it works now, when I choose "reset
foo branch to here", a dialog prompts me to pick from the three reset
modes, with 'Mixed' being the default. So I'd have to explicitly pick
'Hard', which has a message "discards ALL local changes" right next to
it. If people are so conditioned to ignore that, I doubt it'll take
very long for them to be conditioned to just automatically confirm the
confirmation dialog.
The same applies to the command line as well I guess - if having to
manually type "--hard" does not make one stop and think about what
they are doing, I can hardly see how "--hard --force" would do any
better.
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: update-index --assume-unchanged doesn't make things go fast
From: Avery Pennarun @ 2008-06-25 18:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g3tvqd$2jj$1@ger.gmane.org>
On 6/25/08, Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
> > 4) My idea is to eventually --assume-unchanged my whole repository,
> > then write a cheesy daemon that uses the Win32 dnotify-equivalent to
> > watch for files that get updated and then selectively
> > --no-assume-unchanged files that it gets notified about. That would
> > avoid the need to ever synchronously scan the whole repo for changes,
> > thus making my git-Win32 experience much faster and more enjoyable.
> > (This daemon ought to be possible to run on Linux as well, for similar
> > improvements on gigantic repositories. Also note that TortoiseSVN for
> > Windows does something similar to track file status updates, so this
> > isn't *just* me being crazy.)
>
> Looks like users on slow NFS would profit, too. Hate to say it, but hg
> feels faster on (slow) NFS than git. Yet I use git, for other reasons ;)
Hmm, can you do dnotify over NFS?
I'd like to know how hg goes any faster. As far as I can see, git is
going as fast as can be without some kind of daemon or other magic.
(Except for my point #3, which seems relatively minor.)
Thanks,
Avery
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Dmitry Potapov @ 2008-06-25 18:06 UTC (permalink / raw)
To: David Jeske; +Cc: Brandon Casey, Jakub Narebski, Boaz Harrosh, git
On Tue, Jun 24, 2008 at 10:13:13PM -0000, David Jeske wrote:
>
> Two things I'd like to make it easy for users to never do are:
> - delete data
> - cause refs to be dangling
Why? Let's suppose you work with CVS and you started to edit some
file and then realize than the change that you make is stupid, would
not you want just to discard these change without committing them to
CVS?
Perhaps, you are confused by thinking that git commit and cvs commit
are conceptually same commands. IMHO, far better to analogue to cvs
commit would be git push to a repository with denyNonFastForwards
policy. Git commit allows you to save your changes locally as series
of patches, but until you have not pushed them, they are not in a
permanent storage. You can change these patches, which implies that
old versions may become dangling and will be removed after reflog
expired. The idea of making of making difficult to remove some local
commits is alike the idea of an editor making difficult to remove a
line... You gain nothing from that. What editors do instead is to
provide the Undo action. Similarly, Git allows you to get back to an
old state using the reflog.
Dmitry
^ permalink raw reply
* Re: [PATCH v2] pre-commit hook should ignore carriage returns at EOL
From: Alex Riesen @ 2008-06-25 18:14 UTC (permalink / raw)
To: Christian Holtje; +Cc: git, Junio C Hamano
In-Reply-To: <3BA781AD-4C44-4F43-902A-07580B6CA075@gmail.com>
Christian Holtje, Tue, Jun 24, 2008 21:21:22 +0200:
> diff --git a/t/t7503-template-hook--pre-commit.sh b/t/t7503-template-
> hook--pre-commit.sh
Your patch has long lines wrapped.
> diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
> index b25dce6..335ca09 100644
> --- a/templates/hooks--pre-commit
> +++ b/templates/hooks--pre-commit
> @@ -55,8 +55,14 @@ perl -e '
> if (s/^\+//) {
> $lineno++;
> chomp;
> - if (/\s$/) {
> - bad_line("trailing whitespace", $_);
> + if (/\r$/) {
> + if (/\s\r$/) {
> + bad_line("trailing whitespace", $_);
> + }
> + } else {
> + if (/\s$/) {
> + bad_line("trailing whitespace", $_);
> + }
You coud just strip the trailing (cr)lf, instead of chomp:
if (s/^\+//) {
$lineno++;
- chomp;
+ s/\r?\n$//so;
if (/\s$/) {
bad_line("trailing whitespace", $_);
Makes for a shorter patch and less code.
^ permalink raw reply
* [PATCH] Fix t5303 (the test case for pack corruptions) on Windows
From: Alex Riesen @ 2008-06-25 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <7vskv11keo.fsf@gitster.siamese.dyndns.org>
The perldiag(1) has following to say about this:
"Can't do inplace edit without backup"
(F) You're on a system such as MS-DOS that gets confused if
you try reading from a deleted (but still opened) file. You
have to say -i.bak, or some such.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Wed, Jun 25, 2008 19:42:07 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > The perldiag(1) has following to say about this:
> >
> > "Can't do inplace edit without backup"
> >
> > (F) You're on a system such as MS-DOS that gets confused if
> > you try reading from a deleted (but still opened) file. You
> > have to say -i.bak, or some such.
>
> Thanks. By the way, there are others.
>
> t/t9106-git-svn-dcommit-clobber-series.sh:23: perl -i -p -e "s/^58$/5588/" file &&
> t/t9106-git-svn-dcommit-clobber-series.sh:24: perl -i -p -e "s/^61$/6611/" file &&
> t/t9106-git-svn-dcommit-clobber-series.sh:43: perl -i -p -e 's/^4\$/4444/' file &&
> t/t9106-git-svn-dcommit-clobber-series.sh:44: perl -i -p -e 's/^7\$/7777/' file &&
> templates/hooks--prepare-commit-msg.sample:25: perl -i -ne 's/^/# /, s/^# #/#/ if /^Conflicts/ .. /#/; print' "$1" ;;
> templates/hooks--prepare-commit-msg.sample:28:# perl -i -pe '
Ouch, I have the svn tests disabled, so I couldn't notice.
FWIW, resending with the rest corrected.
t/t5303-pack-corruption-resilience.sh | 4 ++--
t/t9106-git-svn-dcommit-clobber-series.sh | 8 ++++----
templates/hooks--prepare-commit-msg.sample | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t5303-pack-corruption-resilience.sh b/t/t5303-pack-corruption-resilience.sh
index b0f5693..31b20b2 100755
--- a/t/t5303-pack-corruption-resilience.sh
+++ b/t/t5303-pack-corruption-resilience.sh
@@ -90,7 +90,7 @@ test_expect_success \
'create_new_pack &&
git prune-packed &&
chmod +w ${pack}.pack &&
- perl -i -pe "s/ base /abcdef/" ${pack}.pack &&
+ perl -i.bak -pe "s/ base /abcdef/" ${pack}.pack &&
test_must_fail git cat-file blob $blob_1 > /dev/null &&
test_must_fail git cat-file blob $blob_2 > /dev/null &&
test_must_fail git cat-file blob $blob_3 > /dev/null'
@@ -138,7 +138,7 @@ test_expect_success \
'create_new_pack &&
git prune-packed &&
chmod +w ${pack}.pack &&
- perl -i -pe "s/ delta1 /abcdefgh/" ${pack}.pack &&
+ perl -i.bak -pe "s/ delta1 /abcdefgh/" ${pack}.pack &&
git cat-file blob $blob_1 > /dev/null &&
test_must_fail git cat-file blob $blob_2 > /dev/null &&
test_must_fail git cat-file blob $blob_3 > /dev/null'
diff --git a/t/t9106-git-svn-dcommit-clobber-series.sh b/t/t9106-git-svn-dcommit-clobber-series.sh
index a400dc7..f8f4718 100755
--- a/t/t9106-git-svn-dcommit-clobber-series.sh
+++ b/t/t9106-git-svn-dcommit-clobber-series.sh
@@ -20,8 +20,8 @@ test_expect_success '(supposedly) non-conflicting change from SVN' '
test x"`sed -n -e 61p < file`" = x61 &&
svn co "$svnrepo" tmp &&
cd tmp &&
- perl -i -p -e "s/^58$/5588/" file &&
- perl -i -p -e "s/^61$/6611/" file &&
+ perl -i.bak -p -e "s/^58$/5588/" file &&
+ perl -i.bak -p -e "s/^61$/6611/" file &&
poke file &&
test x"`sed -n -e 58p < file`" = x5588 &&
test x"`sed -n -e 61p < file`" = x6611 &&
@@ -40,8 +40,8 @@ test_expect_success 'some unrelated changes to git' "
test_expect_success 'change file but in unrelated area' "
test x\"\`sed -n -e 4p < file\`\" = x4 &&
test x\"\`sed -n -e 7p < file\`\" = x7 &&
- perl -i -p -e 's/^4\$/4444/' file &&
- perl -i -p -e 's/^7\$/7777/' file &&
+ perl -i.bak -p -e 's/^4\$/4444/' file &&
+ perl -i.bak -p -e 's/^7\$/7777/' file &&
test x\"\`sed -n -e 4p < file\`\" = x4444 &&
test x\"\`sed -n -e 7p < file\`\" = x7777 &&
git commit -m '4 => 4444, 7 => 7777' file &&
diff --git a/templates/hooks--prepare-commit-msg.sample b/templates/hooks--prepare-commit-msg.sample
index aa42acf..3652424 100755
--- a/templates/hooks--prepare-commit-msg.sample
+++ b/templates/hooks--prepare-commit-msg.sample
@@ -22,10 +22,10 @@
case "$2,$3" in
merge,)
- perl -i -ne 's/^/# /, s/^# #/#/ if /^Conflicts/ .. /#/; print' "$1" ;;
+ perl -i.bak -ne 's/^/# /, s/^# #/#/ if /^Conflicts/ .. /#/; print' "$1" ;;
# ,|template,)
-# perl -i -pe '
+# perl -i.bak -pe '
# print "\n" . `git diff --cached --name-status -r`
# if /^#/ && $first++ == 0' "$1" ;;
--
1.5.6.91.geb23
^ permalink raw reply related
* Re: [PATCH v2] pre-commit hook should ignore carriage returns at EOL
From: Christian Holtje @ 2008-06-25 18:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20080625181422.GC4039@steel.home>
On Jun 25, 2008, at 2:14 PM, Alex Riesen wrote:
> Christian Holtje, Tue, Jun 24, 2008 21:21:22 +0200:
>> diff --git a/t/t7503-template-hook--pre-commit.sh b/t/t7503-template-
>> hook--pre-commit.sh
>
> Your patch has long lines wrapped.
>
>> diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-
>> commit
>> index b25dce6..335ca09 100644
>> --- a/templates/hooks--pre-commit
>> +++ b/templates/hooks--pre-commit
>> @@ -55,8 +55,14 @@ perl -e '
>> if (s/^\+//) {
>> $lineno++;
>> chomp;
>> - if (/\s$/) {
>> - bad_line("trailing whitespace", $_);
>> + if (/\r$/) {
>> + if (/\s\r$/) {
>> + bad_line("trailing whitespace", $_);
>> + }
>> + } else {
>> + if (/\s$/) {
>> + bad_line("trailing whitespace", $_);
>> + }
>
> You coud just strip the trailing (cr)lf, instead of chomp:
>
> if (s/^\+//) {
> $lineno++;
> - chomp;
> + s/\r?\n$//so;
> if (/\s$/) {
> bad_line("trailing whitespace", $_);
>
> Makes for a shorter patch and less code.
That's a good idea! However, this patch is not going anyplace, I
think. Junio submitted a different patch to disable the pre-commit
example.
Junio, do you want me to make this change anyway? It does make
sense. The unittests for the pre-commit hook may or may not still be
useful.
Ciao!
^ permalink raw reply
* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Nicolas Pitre @ 2008-06-25 18:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vd4m66rfp.fsf@gitster.siamese.dyndns.org>
On Tue, 24 Jun 2008, Junio C Hamano wrote:
> For the other "usedeltabaseoffset" change, I think the insn in the
> documentation Nico added is reasonable:
>
> + By default, linkgit:git-repack[1] creates packs that use
> + delta-base offset. If you need to share your repository with
> + git older than version 1.4.4, either directly or via a dumb
> + protocol such as http, then you need to set this option to
> + "false" and repack. Access from old git versions over the
> + native protocol are unaffected by this option.
>
> except perhaps that the "set false and repack" should be clarified
> further, perhaps like:
>
> ... then you need to set this option to "false" and repack using
> git that is newer than (and including) v1.5.0.
Actually the first release to support this is v1.4.4 not v1.5.0.
> I am basing the above 1.5.0 on description of b6945f5 (git-repack:
> repo.usedeltabaseoffset, 2006-10-13).
$ git describe --contains b6945f5
v1.4.4-rc1~77^2~2
> On the "indexVersion" change, the documentation reads:
>
> pack.indexVersion::
> Specify the default pack index version. Valid values are 1 for
> legacy pack index used by Git versions prior to 1.5.2, and 2 for
> the new pack index with capabilities for packs larger than 4 GB
> as well as proper protection against the repacking of corrupted
> + packs. Version 2 is the default. Note that version 2 is enforced
> + and this config option ignored whenever the corresponding pack is
> + larger than 2 GB.
>
> which lacks the recovery insn (and it is int strictly the fault of this
> patch, but we should have done this when we introduced the v2 idx). I
> think a separate paragraph after the above would be necessary and
> sufficient:
>
> If you have an ancient git that does not understand the version 2
> `*.idx` file, cloning or fetching over a non native protocol
> (e.g. "http" and "rsync") which will copy both `*.pack` file and
> corresponding `*.idx` file from the other side may give you a
> repository that cannot be accessed with your old git. If the
> `*.pack` file is smaller than 2 GB, however, you can use
> `git-index-pack` on the `*.pack` to regenerate the `*.idx` file.
Looks fine to me. Will you amend the patches or do you want me to
repost them?
Nicolas
^ permalink raw reply
* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Nicolas Pitre @ 2008-06-25 18:53 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20080625055605.GD28563@glandium.org>
On Wed, 25 Jun 2008, Mike Hommey wrote:
> On Tue, Jun 24, 2008 at 09:59:06PM -0700, Junio C Hamano wrote:
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > > On Wed, 25 Jun 2008, Nicolas Pitre wrote:
> > >>
> > >> Git older than version 1.5.2 (or any other git version with this option
> > >> set to 1) may revert to version 1 of the pack index by manually deleting
> > >> all .idx files and recreating them using 'git index-pack'. Communication
> > >> over the git native protocol is unaffected since the pack index is never
> > >> transferred.
> > >
> > > Rather than talk about when it does _not_ matter, wouldn't it be better to
> > > talk about when it _can_ matter?
> > >
> > > Namely when using dumb protocols, either http or rsync, with the other end
> > > being some ancient git thing (and it is worth mentioning version of what
> > > counts as 'ancient' too, I can't remember, probably means that pretty much
> > > nobody else can either).
> >
> > I agree with you that the description of the change (in the commit log)
> > and the instruction (in the documentation) could be more helpful and
> > explicit.
> (...)
>
> Wouldn't it be a good idea to add a warning in git update-server-info
> when it detects pack.indexVersion is not 1, too ?
That would give the idea that index v2 is not good, while what we want
is to encourage everyone to move to index v2 ASAP.
Nicolas
^ permalink raw reply
* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Mike Hommey @ 2008-06-25 18:58 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0806251449530.2979@xanadu.home>
On Wed, Jun 25, 2008 at 02:53:41PM -0400, Nicolas Pitre wrote:
> On Wed, 25 Jun 2008, Mike Hommey wrote:
>
> > On Tue, Jun 24, 2008 at 09:59:06PM -0700, Junio C Hamano wrote:
> > > Linus Torvalds <torvalds@linux-foundation.org> writes:
> > >
> > > > On Wed, 25 Jun 2008, Nicolas Pitre wrote:
> > > >>
> > > >> Git older than version 1.5.2 (or any other git version with this option
> > > >> set to 1) may revert to version 1 of the pack index by manually deleting
> > > >> all .idx files and recreating them using 'git index-pack'. Communication
> > > >> over the git native protocol is unaffected since the pack index is never
> > > >> transferred.
> > > >
> > > > Rather than talk about when it does _not_ matter, wouldn't it be better to
> > > > talk about when it _can_ matter?
> > > >
> > > > Namely when using dumb protocols, either http or rsync, with the other end
> > > > being some ancient git thing (and it is worth mentioning version of what
> > > > counts as 'ancient' too, I can't remember, probably means that pretty much
> > > > nobody else can either).
> > >
> > > I agree with you that the description of the change (in the commit log)
> > > and the instruction (in the documentation) could be more helpful and
> > > explicit.
> > (...)
> >
> > Wouldn't it be a good idea to add a warning in git update-server-info
> > when it detects pack.indexVersion is not 1, too ?
>
> That would give the idea that index v2 is not good, while what we want
> is to encourage everyone to move to index v2 ASAP.
The warning could just say that people with older git won't be able to
clone over dumb protocols. Nothing more.
Mike
^ permalink raw reply
* Re: gitwiki/EclipsePlugin
From: Robin Rosenberg @ 2008-06-25 18:55 UTC (permalink / raw)
To: M; +Cc: git
In-Reply-To: <4862737E.6010502@gmx.de>
onsdagen den 25 juni 2008 18.34.06 skrev M:
> Hi list,
> I felt quite helpless when trying to get egit running as neither
> http://git.or.cz/gitwiki/EclipsePlugin nor the README/INSTALL aren't
> overly verbose.
>
> I put the idiot-proof recipe on
> http://wiki.jcurl.org/index.php5?title=GitSvn#Eclipse_Plugin - maybe you
> can weave it into either wiki or INSTALL?
You mean they *are* overly verbose? Our INSTALL has a lot more details
than your wiki, so I'm not sure I understand your problem.
) 7: uncheck all *.test projects
not important
) 10: restart eclipse with parameter -clean
probably a good idea, though I have never needed it
>
> Greetings,
> M
We're going to set up an official update site in the not too distant future.
Cheers,
-- robin
^ permalink raw reply
* Re: how to rewalk the commit list after rename detection
From: Alex Riesen @ 2008-06-25 19:04 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <20080623153814.GD15773@redhat.com>
Don Zickus, Mon, Jun 23, 2008 17:38:14 +0200:
> I am trying to find a way to handle a situation where I am looking for a
> change in a particular file, but the filename is old and has since been
> renamed.
>
> Processing the commit list internally (using init_revisions,
> setup_revisions, get_revision), I can easily find the rename of the file,
> but that is usually the start of the walk for that file (as it was just
> deleted for the rename). I do not know how to re-walk the commits list
> armed with the new file name.
Try looking at git log --follow <name>
^ permalink raw reply
* Re: [Bug] for-each-ref: %(object) and %(type) unimplemented
From: Mikael Magnusson @ 2008-06-25 19:08 UTC (permalink / raw)
To: Jeff King; +Cc: Lea Wiemann, Junio C Hamano, Git Mailing List
In-Reply-To: <20080625161433.GA6612@sigill.intra.peff.net>
2008/6/25 Jeff King <peff@peff.net>:
> On Wed, Jun 25, 2008 at 12:08:15PM -0400, Jeff King wrote:
>
>> Since you seem to be testing for-each-ref, maybe it would make sense to
>> put together a test script that exercises each of the atoms?
>
> Hmm. Actually, there is a test in t6300 that runs with each atom name.
> Unfortunately, it doesn't bother actually checking the output for
> sanity, so the fact that these atoms returned the empty string was
> missed.
The documentation also says "tree" and "parent" should work (which they
also don't).
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH v2] pre-commit hook should ignore carriage returns at EOL
From: Junio C Hamano @ 2008-06-25 19:14 UTC (permalink / raw)
To: Christian Holtje; +Cc: Alex Riesen, git
In-Reply-To: <5B163827-204D-4F76-88C9-8F0C93E60AF3@gmail.com>
Christian Holtje <docwhat@gmail.com> writes:
> On Jun 25, 2008, at 2:14 PM, Alex Riesen wrote:
>> Christian Holtje, Tue, Jun 24, 2008 21:21:22 +0200:
>>> diff --git a/t/t7503-template-hook--pre-commit.sh b/t/t7503-template-
>>> hook--pre-commit.sh
>>
>> Your patch has long lines wrapped.
>>
>>> diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-
>>> commit
>>> index b25dce6..335ca09 100644
>>> --- a/templates/hooks--pre-commit
>>> +++ b/templates/hooks--pre-commit
>>> @@ -55,8 +55,14 @@ perl -e '
>>> if (s/^\+//) {
>>> $lineno++;
>>> chomp;
>>> - if (/\s$/) {
>>> - bad_line("trailing whitespace", $_);
>>> + if (/\r$/) {
>>> + if (/\s\r$/) {
>>> + bad_line("trailing whitespace", $_);
>>> + }
>>> + } else {
>>> + if (/\s$/) {
>>> + bad_line("trailing whitespace", $_);
>>> + }
>>
>> You coud just strip the trailing (cr)lf, instead of chomp:
>>
>> if (s/^\+//) {
>> $lineno++;
>> - chomp;
>> + s/\r?\n$//so;
>> if (/\s$/) {
>> bad_line("trailing whitespace", $_);
>>
>> Makes for a shorter patch and less code.
>
> That's a good idea! However, this patch is not going anyplace, I
> think. Junio submitted a different patch to disable the pre-commit
> example.
>
> Junio, do you want me to make this change anyway? It does make sense.
> The unittests for the pre-commit hook may or may not still be useful.
"disable" is not an issue. The intention has always been that these are
samples, and it was an accident that some packaging shipped them enabled
by mistake. The patch was to make that mistake harder to make.
The issue now is about keeping the example hooks _relevant_. The one we
have does not work well with projects that want to check in files with
CRLF line endings (iow, without using autocrlf to attempt to make the
project files cross-platform), so it is irrelevant for such projects with
Windows origin.
The "solution" you are proposing to strip out \r makes the check less
useful for projects that want to keep files with LF line endings in the
commited history, because your patch would stop catching such a mistake of
adding an CR before LF. It is robbing from Peter to pay Paul, and I am
afraid it would make the sample even more irrelevant in the end. I do not
think we would want to go there.
I suggested using "diff --check" (and possibly teaching "diff --check"
other things the scripted example checks, such as conflict markers),
which would know to honor the line endings specified per path via
gitattributes(5), instead of building on top of the big Perl script, and I
had an impression that you agreed to the approach.
^ permalink raw reply
* Re: policy and mechanism for less-connected clients
From: Daniel Barkalow @ 2008-06-25 19:17 UTC (permalink / raw)
To: David Jeske; +Cc: Theodore Tso, git
In-Reply-To: <willow-jeske-01l6Cy0dFEDjCVqc>
On Wed, 25 Jun 2008, David Jeske wrote:
> Yes, so I'd have the same thing, except instead of a remote repository, it
> would be a pattern of the branch namespace, such as /origin/users/jeske/*. It
> doesn't seem like the current remote tracking branch stuff can do this, but it
> would be easy to provide a client wrapper that would. Users who tracked the
> whole repository would just get everything, which is also fine. Maybe a client
> patch to make this better would be accepted.
Git actually has good support for large numbers of repositories sharing
the same object storage. It's actually more efficient (in terms of
server load) to have thousands of repositories with the same contents than
one repository with thousands of branches.
> > > (c) grant and enforce permission for certain users to submit _merges
> > > only_ onto certain sub-portions of the "well-named branches"
> >
> > This is the wierd one. *** Why ***? There is nothing magical about
> > merges; all a merge is a commit that contains more than one parent.
> > You can put anything into a merge, and in theory the result of a merge
> > could have nothing to do with either parent. It would be a very
> > perverse merge, but it's certainly possible. So what's the point of
> > trying to enforce rules about "merges only"?
>
> I'll explain why I wrote this, but I admit it's a strange roundabout way to get
> what I was hoping for. I hope there is a better way. One better way is to just
> change the client, but I was hoping not to have to do that. let me explain..
>
> Think about using CVS. user does "cvs up; hack hack hack; cvs commit (to
> server)". In git, this workflow is "git pull; hack; commit; hack; commit; git
> push (to server)". I want those interum "commits" to share the changes with the
> server. I want to change this to "git pull; hack; commit-and-share; hack;
> commit-and-share; git-push (to shared branch tag)"
>
> It would be nice if "commit-and-share" could just use "git-push". However,
> because users are going to do this habitually every commit, probably through a
> script or merged command, I didn't want users who are accidentally working
> directly in the master to accidentally fast-forward origin/master. (everyone
> seems to discourage working on master anyhow). I was hoping to enforce this
> only with server policy, so any git client works. That leaves me with the
> challenge of figuring out which commits on origin/master are actually intended
> to move the pointer, and which are accidents because someone forgot to branch
> before hacking in their client. One simple way to do this is to require any
> origin/master commit to have two children, one on the master, one somewhere
> else. If you have a commit that is directly hanging off of master in this
> design, you are doing the wrong thing. The server would tell you to "git
> checkout master; git branch -b mymaster; git reset origin/master; git push".
> This would put their local changes onto their private branch where they should
> be. When they wanted to do the equivilant of "cvs commit;" or current "git
> push;", they would do a merge to the master, and push again. The server would
> allow it, because it sees the merge.
You have a fundamental misconception about git's data model. A commit
doesn't have a particular branch it is on. There is only the DAG, where
each node is a commit that is structured identically to all of the other
commits. Branches pick out particular nodes in the DAG at particular
times.
You can even think of there being a single theoretical universal DAG,
independant of the actual development that gets done, and developers work
to find the interesting portions, which are ones that contain trees that
contain working code and useful messages and history that is informative.
And they use branches to hold references to worthwhile parts of the DAG,
and not (as in systems like SVN) to partition the DAG, which makes no
reference to branches.
It therefore doesn't make any sense to ask if a commit is directly hanging
off of master. If your local branch is up to date, and you commit, your
commit's parent is the current master. If you now check out master and
merge your local branch, master gets the same (non-merge) commit.
> I recognize this is a bit strange. I'd love to have a better solution, but this
> is the solution I can think of which only involves server enforcement.
You fundamentally can't do what you want with only server enforcement,
because git doesn't provide the history of what local operations were used
to prepare to ask the server to change something. It fundamentally can't,
because there's no room in its data model of changes to hold that, and
because its design is to allow flexibility in this preparation.
> Other solutions I thought of would all require client changes that would
> change everyone's behavior. The candidate I liked best was: disallowing
> changes to tracking branches, including master, probably by implicitly
> creating a branch on commit to a tracking branch... However, I don't get
> the impression this will fit into current git very well, because users
> would need to turn their current "git push", into a "git merge
> master;git push"
Git prevents you from committing to tracking branches at all. Any branch
you can commit to is inherently a local branch, because that's what it
means for a branch to be local. The "push" operation updates a remote
branch from a local branch.
Now, what might be good would be to introduce a type of ref that you can
update with "merge" but not with "commit". Of course, this has to be
client-side, because the final state doesn't depend on whether you commit
in a temporary branch and merge into a publishing branch or commit
directory in the publishing branch.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] pack.indexversion config option now defaults to 2
From: Junio C Hamano @ 2008-06-25 19:19 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, git
In-Reply-To: <alpine.LFD.1.10.0806251442500.2979@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 24 Jun 2008, Junio C Hamano wrote:
> ...
> Actually the first release to support this is v1.4.4 not v1.5.0.
>
>> I am basing the above 1.5.0 on description of b6945f5 (git-repack:
>> repo.usedeltabaseoffset, 2006-10-13).
>
> $ git describe --contains b6945f5
> v1.4.4-rc1~77^2~2
I know, as I did that myself; but I wanted to be conservative and gave a
release after a major release bump.
>> On the "indexVersion" change, the documentation reads:
>>
>> pack.indexVersion::
>> Specify the default pack index version. Valid values are 1 for
>> legacy pack index used by Git versions prior to 1.5.2, and 2 for
>> the new pack index with capabilities for packs larger than 4 GB
>> as well as proper protection against the repacking of corrupted
>> + packs. Version 2 is the default. Note that version 2 is enforced
>> + and this config option ignored whenever the corresponding pack is
>> + larger than 2 GB.
>>
>> which lacks the recovery insn (and it is int strictly the fault of this
>> patch, but we should have done this when we introduced the v2 idx). I
>> think a separate paragraph after the above would be necessary and
>> sufficient:
>>
>> If you have an ancient git that does not understand the version 2
>> `*.idx` file, cloning or fetching over a non native protocol
>> (e.g. "http" and "rsync") which will copy both `*.pack` file and
>> corresponding `*.idx` file from the other side may give you a
>> repository that cannot be accessed with your old git. If the
>> `*.pack` file is smaller than 2 GB, however, you can use
>> `git-index-pack` on the `*.pack` to regenerate the `*.idx` file.
>
> Looks fine to me. Will you amend the patches or do you want me to
> repost them?
No worries. After re-reading what you wrote I think both are fine as they
are. I do not mind adding the above 7 lines to the indexVersion one
myself.
^ 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