* Re: [PATCH] builtin-verify-tag: fix -v option parsing
From: Johannes Schindelin @ 2008-07-28 12:10 UTC (permalink / raw)
To: Olivier Marin; +Cc: Junio C Hamano, Michele Ballabio, git
In-Reply-To: <488DB0BD.2060406@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 637 bytes --]
Hi,
On Mon, 28 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
> >>
> >> Since the C rewrite, "git verify-tag -v" just does nothing instead of
> >> printing the usage message with an error. This patch fix the
> >> regression.
> >
> > Maybe a better solution would be to convert (trivially) to
> > parse-options...
>
> I am very puzzled.
>
> You first asked me to do a separate commit with just the fix and now you
> seem to want the fix with the conversion...
Sorry. It was not obvious to myself when I asked for a separate patch
that the fix would fall out of the conversion to parse-options.
My fault,
Dscho
^ permalink raw reply
* Re: Adding custom hooks to a bare repository.
From: Thomas Adam @ 2008-07-28 12:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git mailing list
In-Reply-To: <alpine.DEB.1.00.0807281324350.2725@eeepc-johanness>
2008/7/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Yes. Hooks, just as the config and reflogs, are supposed to be local
> things. Rationale being: it is rude, and also insecure, to install
> something that potentially calls other programs without the user saying
> so.
Oh absolutely, I agree with that.
> All you can do is checking in a copy of the hook, and ask your users/check
> in your build system that it is installed.
Hmm -- perhaps I am being unintentionally dense, but I am assuming
that when you say "checking in a copy" you mean anywhere other than
.git/hooks/ since that isn't tracked by git. I have no problem with
the rationale you've just described -- but it would be handy to add
this post-merge hook script into hooks/ (exec bit removed) such that
on a clone, all one would need to do is chmod +x it. If that's
possible, I'm clearly missing the steps to enable this.
Thanks,
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH] Remove references to git-fetch-pack from "git clone" documentation.
From: Steve Haslam @ 2008-07-28 12:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807260523520.26810@eeepc-johanness>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 25 Jul 2008, Steve Haslam wrote
>> "git clone" no longer calls "git-fetch-pack",
>>
>
> So it calls it internally, avoiding fork() and exec(). But the code is
> still git-fetch-pack's. The difference should be lost on the regular Git
> user.
>
Well, I would say that the git-clone command uses code that is also used
by the git-fetch-pack command; but as you indicate, this is a minor
implementation detail.
I think that the documentation was perhaps too explicit and as a result
stale: git-clone certainly does not work any more by creating a
"--exec=..." argument to pass to the git-fetch-pack command even
internally, it calls code in transport.c. As you say, the difference is
immaterial to most users, and a simplified version of the documentation
should be adequate (and possibly clearer).
SRH
^ permalink raw reply
* Re: Adding custom hooks to a bare repository.
From: Johannes Schindelin @ 2008-07-28 12:40 UTC (permalink / raw)
To: Thomas Adam; +Cc: git mailing list
In-Reply-To: <18071eea0807280532l69d12e3ehb8377da9d24e035@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Thomas Adam wrote:
> 2008/7/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > Yes. Hooks, just as the config and reflogs, are supposed to be local
> > things. Rationale being: it is rude, and also insecure, to install
> > something that potentially calls other programs without the user
> > saying so.
>
> Oh absolutely, I agree with that.
>
> > All you can do is checking in a copy of the hook, and ask your
> > users/check in your build system that it is installed.
>
> Hmm -- perhaps I am being unintentionally dense, but I am assuming
> that when you say "checking in a copy" you mean anywhere other than
> .git/hooks/ since that isn't tracked by git. I have no problem with
> the rationale you've just described -- but it would be handy to add
> this post-merge hook script into hooks/ (exec bit removed) such that
> on a clone, all one would need to do is chmod +x it. If that's
> possible, I'm clearly missing the steps to enable this.
No, as you said, anything in .git/ is not meant to be tracked. Besides,
if a user would change the executable bit (as advised), Git would always
show this file as modified, making the tree permanently dirty (or worse,
it could be accidentally be committed as executable).
For all those reasons, it is better to just commit an executable script in
your <toplevel>/githooks/post-merge and ask your users to copy it to
.git/hooks/.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Remove references to git-fetch-pack from "git clone" documentation.
From: Johannes Schindelin @ 2008-07-28 12:41 UTC (permalink / raw)
To: Steve Haslam; +Cc: git
In-Reply-To: <488DBC72.8040204@lastminute.com>
Hi,
On Mon, 28 Jul 2008, Steve Haslam wrote:
> I think that the documentation was perhaps too explicit and as a result
> stale: git-clone certainly does not work any more by creating a
> "--exec=..." argument to pass to the git-fetch-pack command even
> internally, it calls code in transport.c.
Ah, that is a valid concern which I missed.
Thanks,
Dscho
^ permalink raw reply
* Re: Adding custom hooks to a bare repository.
From: Thomas Adam @ 2008-07-28 12:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git mailing list
In-Reply-To: <alpine.DEB.1.00.0807281438220.2725@eeepc-johanness>
2008/7/28 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> For all those reasons, it is better to just commit an executable script in
> your <toplevel>/githooks/post-merge and ask your users to copy it to
> .git/hooks/.
Grand. Thank you very much. :)
-- Thomas Adam
^ permalink raw reply
* Re: New mailmap file for the kernel
From: Jon Smirl @ 2008-07-28 12:47 UTC (permalink / raw)
To: sverre, Linus Torvalds; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <bd6139dc0807280453rbfc28ffid8314e74cc19b7f7@mail.gmail.com>
On 7/28/08, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Mon, Jul 28, 2008 at 13:23, Johannes Schindelin
>
> <Johannes.Schindelin@gmx.de> wrote:
>
> > And how exactly do you plan to make sure everybody has that hook
> > installed?
>
>
> It needn't be installed with everybody, only at the people that form
> 'upstream' (in the git case that'd be Junio, in the Linux case that'd
> be Linus and his lieutenants).
That's the idea. The lieutenants would have the hook and stop anything
that introduced new errors into the file. checkpatch.pl would get the
same hook. And we'd make it available to all developers too. Someone
want to help out are write the hook? My hands hurt from editing the
mailmap file for too long.
We really need a hook to start the validation process. Putting all of
the existing names in the file makes it easier to write the hook. I
was surprised that 12% of all names in the log had errors in them.
That's a terrible error rate.
Making sure nothing slips through is not that bad. Use git log to
extract all email addresses. Run a script to ensure that they are all
in the mail map file.Add the missing ones, there should only be a few.
If the commit validation process works there shouldn't be any.
It's not just statistics, what it we had to contact everyone because
of some licensing or patent mess? Mozilla has had to contact everyone
three times now.
Bottom line this is Linus' call. Does he want a validation mechanism
for names and email addresses in the log?
> > Also, it would be a major hassle, just for the benefits of statistics
> > (which, funnily enough, not everybody cares about).
>
>
> Hmmm, I'm not sure if it would be a major hassle once it's set up?
> Once everybody has their name correctly in the mailmap nobody will
> have to care?
>
>
> > But we are not truly distributed. Our community is small enough, and our
> > maintainer good enough, that we do have a single upstream essentially. We
> > do not even have lieutenants through which new developers could come (and
> > therefore would be old developers once they hit master).
>
>
> Ah, I did not realize that. Thanks for explaining.
>
> --
> Cheers,
>
>
> Sverre Rabbelier
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 5/6] builtin-merge: avoid non-strategy git-merge commands in error message
From: Johannes Schindelin @ 2008-07-28 13:06 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <42e8615f6cbd236e40b19f2a754807f08e4b85a6.1217207602.git.vmiklos@frugalware.org>
Hi,
On Mon, 28 Jul 2008, Miklos Vajna wrote:
> - list_commands("git-merge-", "strategies");
> + list_commands("git-merge-", "strategies", ¬_strategies);
The change in the signature of list_commands() is not part of this patch.
So at least one of your commits should result in an uncompileable
revision...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Johannes Schindelin @ 2008-07-28 13:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <03fa2187a72957d98d63ab899b39e9adc2edfe99.1217207602.git.vmiklos@frugalware.org>
Hi,
On Mon, 28 Jul 2008, Miklos Vajna wrote:
> Testing is done by creating a simple git-merge-theirs strategy which is
> the opposite of ours. Using this in real merges is not recommended but
> it's perfect for our testing needs.
Note that what was asked for, and what Junio implemented before deciding
that it would do more harm than good in git.git, is not the same as what
you provide.
Your -theirs is a strict opposite of -ours, i.e. the tree after the
merge will be identical to the "merged" branch's tip's.
The -theirs which was asked for (and which I truly think is insane) wanted
to do a merge, and in case of merge conflicts take the "upstream" version
_only of the conflicting hunks_.
Just to make sure everyone grasps why this is bad:
- there is not only a real chance, but a high probability that a merge
conflict means that some related, unconflicting change relies on _one_
version of the conflicting hunk which might very well be "ours", and
- since we have a _recursive_ merge, the notion of "upstream" is
completely bogus when working on any merge that has more than one merge
base. This merge would succeed, but actively be wrong.
Just to make sure people do not have to ask for that version of
"-theirs" again,
Dscho
^ permalink raw reply
* Branch renaming not updating the configuration correctly.
From: Jurko Gospodnetić @ 2008-07-28 13:36 UTC (permalink / raw)
To: git
Hi.
I noticed that the .git/config file is not updated completely in case
you create two branches aaa and bbb, set the repository up so it
automatically merges changes from bbb into aaa and then rename the branches:
Here is an exact list of commands and config file contents
illustrating the problem:
> git branch aaa
> git branch bbb
> git config --add branch.aaa.remote .
> git config --add branch.aaa.merge bbb
-- .git/config: --
[branch "aaa"]
remote = .
merge = bbb
------------------
> git branch -m aaa patched
> git branch -m bbb original
-- .git/config: --
[branch "patched"]
remote = .
merge = bbb
------------------
And as you can see above, the branch.patched.merge configuration
setting did not get updated and still holds the old branch name 'bbb'.
Hope this helps.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: Branch renaming not updating the configuration correctly.
From: Johannes Schindelin @ 2008-07-28 13:49 UTC (permalink / raw)
To: Jurko Gospodnetić; +Cc: git
In-Reply-To: <g6ki09$81c$1@ger.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 841 bytes --]
Hi,
On Mon, 28 Jul 2008, Jurko Gospodnetić wrote:
> -- .git/config: --
> [branch "aaa"]
> remote = .
> merge = bbb
> ------------------
>
> > git branch -m aaa patched
> > git branch -m bbb original
>
> -- .git/config: --
> [branch "patched"]
> remote = .
> merge = bbb
> ------------------
>
> And as you can see above, the branch.patched.merge configuration setting
> did not get updated and still holds the old branch name 'bbb'.
I deem this not an "important" bug.
We usually do not set up tracking information for local branches, and I
still do not know valid common scenarios for that workflow.
But hey, if it really bothers you, and you can come up with a
non-intrusive patch (i.e. a patch that does not punish all users that do
_not_ set up locally-tracking branches), I am sure it will be welcomed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow building without any git installed
From: Shawn O. Pearce @ 2008-07-28 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vsktutrh5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> This is a follow-up patch to 49fa65a (Allow the built-in exec path to be
> relative to the command invocation path, 2008-07-23). Without specific
> gitexecdir passed from the command line, git-gui's build procedure would
> try to figure out the value for it by running an installed git.
Ack. I noticed this yesterday while looking at the git Makefile but
forgot to send a patch for it myself. Thanks Junio.
> diff --git a/Makefile b/Makefile
> index 798a2f2..7e30b30 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1067,7 +1067,7 @@ endif
>
> all::
> ifndef NO_TCLTK
> - $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all
> + $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
> $(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
> endif
> $(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
--
Shawn.
^ permalink raw reply
* Re: Branch renaming not updating the configuration correctly.
From: Jurko Gospodnetić @ 2008-07-28 14:06 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807281445340.8986@racer>
Hi Johannes.
>> -- .git/config: --
>> [branch "aaa"]
>> remote = .
>> merge = bbb
>> ------------------
>>
>> > git branch -m aaa patched
>> > git branch -m bbb original
>>
>> -- .git/config: --
>> [branch "patched"]
>> remote = .
>> merge = bbb
>> ------------------
>>
>> And as you can see above, the branch.patched.merge configuration setting
>> did not get updated and still holds the old branch name 'bbb'.
>
> I deem this not an "important" bug.
Just wanted to chip in and report... not comfortable enough yet with
git from the user side to contribute with much else...
> We usually do not set up tracking information for local branches, and I
> still do not know valid common scenarios for that workflow.
I was playing around with setting up a local branch containing Boost
library sources as there is no official git repository for that project.
They hold their main repository under subversion and have currently
closed down their main development branch for changes while a new
release is being prepared. As I do _hate_ svn branching/merging I
thought git should be perfect for the task of tracking my own changes to
the project and this whole 'project' would give me a chance to get
better acquainted with the tool :-).
Crossing the SVN/Git boundary however is causing a problem since I
use Windows and 'git svn' does not seem to be supported here. My initial
idea was to manually update my own personal 'origin/master' branch (svn
checkout & then manually commit to the my git branch) and then update
other branches containing my patches from there. Locally-tracking
branches seemed like a perfect fit for that.
Any other suggested patterns/organizations/solutions I should try out
in this case?
> But hey, if it really bothers you, and you can come up with a
> non-intrusive patch (i.e. a patch that does not punish all users that do
> _not_ set up locally-tracking branches), I am sure it will be welcomed.
Heh... it'll take a little more time for me to get comfortable enough
with git to attempt something like that. :-) Still an infant user here,
happy with reporting what I find and hoping I don't miss something too
obvious or find & report something already reported. :-)
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: SZEDER Gábor @ 2008-07-28 14:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v8wvpm9cl.fsf@gitster.siamese.dyndns.org>
Hi,
there is a race somewhere in these 'git-mv: Keep moved index entries
inact' changes.
The test cases 'git mv should overwrite symlink to a file' or 'git mv
should overwrite file with a symlink' fail occasionaly. It's quite
non-deterministic: I have run t7001-mv.sh in a loop (see below) and
one or the other usually fails around 50 runs (but sometimes only
after 150). Adding some tracing echos to the tests shows that both
tests fail when running 'git diff-files' at the end.
Regards,
Gábor
---
#!/bin/bash
ret=0
i=0
while test $ret = 0 ; do
GIT_TEST_OPTS='--verbose --debug' make t7001-mv.sh
ret=$?
i=$((i+1))
done
echo "Failed at ${i}th run"
^ permalink raw reply
* theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 14:54 UTC (permalink / raw)
To: Git Mailinglist; +Cc: Miklos Vajna, Johannes Schindelin
On Mon, Jul 28, 2008 at 15:12, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Note that what was asked for, and what Junio implemented before deciding
> that it would do more harm than good in git.git, is not the same as what
> you provide.
>
> Your -theirs is a strict opposite of -ours, i.e. the tree after the
> merge will be identical to the "merged" branch's tip's.
I've been wanting to mail about this for a few days now, but didn't
really know how to bring it up, this seems a good opportunity.
It has happened a few times on #git already that someone asked for the
merge strategies described above (e.g., _not_ the insane ones) for
what I deemed to be valid use cases. (The main reason was that they
wanted to merge with a conflicting branch, discarding the current
master, but still allowing people to 'git pull'.)
I was wondering what to tell those people? Will there ever be such a
version of 'merge theirs' (that is the strict opposite of 'ours')? Or
should they do:
$git checkout otherbranch
$git merge -s ours master
$git checkout master
$git merge otherbranch
Thus resulting in a 'wrong way around' merge as part of master? It
would say "Merge branch 'master' into otherbranch", while what
happened was "Merge branch 'otherbranch' into master".
So, in short: what does the list think about adding
"git-merge-theirs", that does (although possibly less 'hackish'):
cat > git-merge-theirs << EOF
#!/bin/sh
eval git read-tree --reset -u \\\$\$#
EOF
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* gitk crashing on Windows.
From: Jurko Gospodnetić @ 2008-07-28 14:58 UTC (permalink / raw)
To: git
Hi.
When you run gitk from a git repository on Windows it starts up and
starts updating its 'Row X/Y' output labels. This lasts for a few
seconds but if you terminate the application before this updating is
complete you get a Windows message stating:
'Wish Application has encountered a problem and needs to close. We
are sorry for the inconvenience.'
and the standard 'Send Error Report'/'Don't Send' buttons.
Hope this helps.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 15:06 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080728142023.GC6701@neumann>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1086 bytes --]
Hi,
On Mon, 28 Jul 2008, SZEDER Gábor wrote:
> there is a race somewhere in these 'git-mv: Keep moved index entries
> inact' changes.
>
> The test cases 'git mv should overwrite symlink to a file' or 'git mv
> should overwrite file with a symlink' fail occasionaly. It's quite
> non-deterministic: I have run t7001-mv.sh in a loop (see below) and
> one or the other usually fails around 50 runs (but sometimes only
> after 150). Adding some tracing echos to the tests shows that both
> tests fail when running 'git diff-files' at the end.
To make it more convenient to test: with this patch it fails all the time:
-- snipsnap --
t/t7001-mv.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b0fa407..6699abd 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -180,6 +180,7 @@ test_expect_success 'git mv should overwrite symlink to a file' '
echo 1 >moved &&
ln -s moved symlink &&
git add moved symlink &&
+ sleep 1 &&
test_must_fail git mv moved symlink &&
git mv -f moved symlink &&
! test -e moved &&
^ permalink raw reply related
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 15:14 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807281605330.8986@racer>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1132 bytes --]
Hi,
On Mon, 28 Jul 2008, Johannes Schindelin wrote:
> On Mon, 28 Jul 2008, SZEDER Gábor wrote:
>
> > there is a race somewhere in these 'git-mv: Keep moved index entries
> > inact' changes.
> >
> > The test cases 'git mv should overwrite symlink to a file' or 'git mv
> > should overwrite file with a symlink' fail occasionaly. It's quite
> > non-deterministic: I have run t7001-mv.sh in a loop (see below) and
> > one or the other usually fails around 50 runs (but sometimes only
> > after 150). Adding some tracing echos to the tests shows that both
> > tests fail when running 'git diff-files' at the end.
>
> To make it more convenient to test: with this patch it fails all the time:
Ooops. Seems like I changed the test 23 to fail, instead of test 24.
However, I think it is the same bug: the index is newer by one second, so
it seems that the patch for builtin-mv.c did not really keep the data
"intact".
Note that a test case should use test-chmtime to force this scenario, not
sleep a second.
Unfortunately, I already spent my Git time budget for today, so the ball
is out of my half for now.
Ciao,
Dscho
^ permalink raw reply
* q: git-fetch a tad slow?
From: Ingo Molnar @ 2008-07-28 16:01 UTC (permalink / raw)
To: git
here's another possibly stupid question.
Setup/background: distributed kernel testing cluster, there's a central
box with a git repo of the kernel, and lots of of testboxes that track
that repo over ssh transport. In each "iteration" a random kernel config
is generated, built and booted, and the booted up kernel is checked.
Performance of each iteration matters to total testing throughput, so i
try to optimize the critical path.
Problem: i noticed that git-fetch is a tad slow:
titan:~/tip> time git-fetch
real 0m2.372s
user 0m0.814s
sys 0m0.951s
There are hundreds of branches, so i thought fetching a single branch
alone would improve things:
titan:~/tip> time git-fetch origin master
real 0m0.942s
user 0m0.285s
sys 0m0.109s
But that's still slow - so i use a (lame) ad-hoc script instead:
titan:~/tip> time tip-fetch
real 0m0.246s
user 0m0.024s
sys 0m0.019s
... which ssh's to the repo to check tip/master by hand:
HEAD=$(git-log -1 --pretty=format:"%H" HEAD)
RHEAD=$(ssh server "cd tip; git-log master -1 --pretty=format:'%H'")
[ "$RHEAD" != "$HEAD" ] && {
[...]
}
... which script is lame/expensive on multiple levels but still is much
faster.
I'm wondering, am i missing something obvious? It seems most of the
overhead is local CPU overhead, so it's something in Git's domain and
not the expense of the ssh protocol. (which expense should be about 200
msecs)
Ingo
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: David Brown @ 2008-07-28 16:04 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Johannes Sixt, git
In-Reply-To: <20080728063128.GA4234@blimp.local>
On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
>because there are situations where it produces too much false
>positives. Like when file system crawlers keep changing it when
>scanning and using the ctime for marking scanned files.
That's interesting, since most backup software uses the ctime to determine
file changes.
David
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Linus Torvalds @ 2008-07-28 16:09 UTC (permalink / raw)
To: David Brown
Cc: Alex Riesen, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
git
In-Reply-To: <20080728160446.GA16351@old.davidb.org>
On Mon, 28 Jul 2008, David Brown wrote:
> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
>
> > because there are situations where it produces too much false
> > positives. Like when file system crawlers keep changing it when
> > scanning and using the ctime for marking scanned files.
>
> That's interesting, since most backup software uses the ctime to determine
> file changes.
It really is just Beagle that is (was? I can dream) a piece of
unbelievable crap.
Anybody who uses extended attributes as part of a indexing scheme is just
insane. Modifying the file you are indexing is not just fundamentally
wrong to begin with, but it will then also be incredibly inefficient to
read those entries one at a time.
And no other sane model would ever touch 'ctime'.
Oh, well. Making ctime configurable is not wrong per se. But if it's
Beagle that triggers this, the fix is sadly in the wrong place.
Linus
^ permalink raw reply
* git submodules
From: Pierre Habouzit @ 2008-07-28 16:20 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]
While trying to sum up some things I'd like submodules to do, and things
like that, I came to ask myself why the heck we were doing things the
way we currently do wrt submodules.
This question is related to the `.git` directories of submodules. I
wonder why we didn't chose to use a new reference namespace
(refs/submodules/$path/$remote/$branch).
This would have the net benefit that most of the plumbing tasks would be
easier if they have to deal with submodules, because they aren't in this
uncomfortable situation where they have to recurse into another git
directory to know what to do.
It also has the absolutely nice property to share objects, so that
projects that replaced a subdirectory with a submodule don't see their
checkouts grow too large.
We probably still want submodules to act like plain independant git
repositories, but one can still *fake* that this way: submodules have
only a .git/config file (also probably an index and a couple of things
like that, but that's almost a different issue for what I'm considering
now) that has the setting:
[core]
submodule = true
This could make all the builtins look for the real $GIT_DIR up, which in
turn gives the submodule "name". Then, for this submodule, every
reference, remote name, ... would be virtualized using the
"remote/$submodule_name" prefix. IOW, in a submodule "some/sub/module"
the branch "origin/my/topic/branch" is under:
refs/submodules/some/sub/module/origin/my/topic/branch
<-- submod. --><-- submod. --><-- --><-- branch -->
namespace path/name remote
Note that this doesn't mean that we must rip out .gitmodules, because
it's needed to help splitting the previous reference name properly, and
for bootstrapping purposes.
Having that, one can probably extend most of the porcelains in _very_
straightforward ways. For example, a local topic branch `topic` would be
the union of the supermodule `topic` branch, and all the
`refs/submodules/$names/topic` ones.
Most importantly, it would help implementing that tries to make your
submodules stay _on branch_. One irritating problem with submodules, is
that when someone else commited, and that you git submodule update,
you're on a detached head. Absolutely horrible. If you see your current
branch (assume it's master), then when you do that, you would update
your `refs/submodules/$name/master` references instead and keep the
submodule HEADs `on branch`. Of course we can _probably_ hack something
together along those lines with the current setup, but it would be _so_
much more convenient this way...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Petr Baudis @ 2008-07-28 16:20 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Johannes Sixt, git
In-Reply-To: <20080728063128.GA4234@blimp.local>
On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 1a13abc..552c134 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -149,6 +149,13 @@ core.safecrlf::
> `core.autocrlf`, git will reject the file. The variable can
> be set to "warn", in which case git will only warn about an
> irreversible conversion but continue the operation.
> +
> +core.trustctime::
> + If false, the ctime differences between the index and the
> + working copy are ignored; useful when the inode change time
> + is regularly modified by something outside Git (file system
> + crawlers and some backup systems).
> + See linkgit:git-update-index[1]. True by default.
> +
> CRLF conversion bears a slight chance of corrupting data.
> autocrlf=true will convert CRLF to LF during commit and LF to
Somehow, this particular position of the new hunk does not feel like the
best choice. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 16:23 UTC (permalink / raw)
To: Git ML
In-Reply-To: <20080728162003.GA4584@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
On Mon, Jul 28, 2008 at 04:20:03PM +0000, Pierre Habouzit wrote:
> It also has the absolutely nice property to share objects, so that
> projects that replaced a subdirectory with a submodule don't see their
> checkouts grow too large.
Especially it "fixes" git-new-workdir, which becomes really
inefficient (storage and typing-wise) when submodules are in use, since
it doesn't share git_dir's for the submodules (this could also be hacked
together, but again, it's so much more convenient if we have only _one_
git_dir per repository that ... oh well)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitk crashing on Windows.
From: Eric Raible @ 2008-07-28 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <g6kmqf$q9p$1@ger.gmane.org>
Jurko Gospodnetić <jurko.gospodnetic <at> docte.hr> writes:
>
> Hi.
>
> When you run gitk from a git repository on Windows it starts up and
> starts updating its 'Row X/Y' output labels. This lasts for a few
> seconds but if you terminate the application before this updating is
> complete you get a Windows message stating:
>
> 'Wish Application has encountered a problem and needs to close. We
> are sorry for the inconvenience.'
>
> and the standard 'Send Error Report'/'Don't Send' buttons.
>
> Hope this helps.
>
> Best regards,
> Jurko Gospodnetić
Though I can't find the relevant commit at the moment
I believe that this is one already fixed in the latest
from git://repo.or.cz/git/mingw/4msysgit.git.
- Eric
^ 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