* Re: wishlist: git info
From: Alex Riesen @ 2007-11-13 21:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Neumann, git
In-Reply-To: <Pine.LNX.4.64.0711131111220.4362@racer.site>
Johannes Schindelin, Tue, Nov 13, 2007 12:13:59 +0100:
> > I use an alias with the commands proposed by Alex Riessen for now, but a
> > more general command would be nice.
>
> His name is "Riesen", just like in the German translation of the famous
> Newton statement.
now I am misspelled. How should I feel?...
^ permalink raw reply
* Re: Strange "beagle" interaction..
From: Linus Torvalds @ 2007-11-13 21:30 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, Git Mailing List, Johannes Schindelin
In-Reply-To: <20071113210354.GD22590@fieldses.org>
On Tue, 13 Nov 2007, J. Bruce Fields wrote:
>
> Last I ran across this, I believe I found it was adding extended
> attributes to the file.
Yeah, I just straced it and found the same thing. It's saving fingerprints
and mtimes to files in the extended attributes.
> Yeah, I just turned off beagle. It looked to me like it was doing
> something wrongheaded.
Gaah. The problem is, setting xattrs does actually change ctime. Which
means that if we want to make git play nice with beagle, I guess we have
to just remove the comparison of ctime.
Oh, well. Git doesn't *require* it, but I like the notion of checking the
inode really really carefully. But it looks like it may not be an option,
because of file indexers hiding stuff behind our backs.
Or we could just tell people not to run beagle on their git trees, but I
suspect some people will actually *want* to. Even if it flushes their disk
caches.
Linus
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Johannes Sixt @ 2007-11-13 21:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vlk91svgf.fsf@gitster.siamese.dyndns.org>
On Tuesday 13 November 2007 22:10, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > On Tuesday 13 November 2007 21:04, Johannes Sixt wrote:
> >> [PATCH 09/11] Allow a relative builtin template directory.
> >> [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
> >> of ETC_GITCONFIG.
> >> [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
> >>
> >> These need probably some discussion. They avoid that $(prefix) is
> >> hardcoded and so allows that an arbitrary installation directory.
> >
> > ... and so allow that the compiled binaries are installed in any
> > directory that the user chooses.
>
> If you can do that without breaking the tests (specifically, the
> test script should pick up the version of git you just built,
> not from /usr/bin nor /usr/local/stow/git/bin) that would be
> great.
Sorry, I don't understand your statement. Do you see any tests breaking?
These changes are only about where git-init looks up the templates and where
the system configuration is looked for. They change git's behavior only if
config.mak contains relative paths like this:
sysconfdir = ../etc
template_dir = ../share/git-core
It has nothing to do with where the test suite looks for the executables.
-- Hannes
^ permalink raw reply
* Re: [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
From: Johannes Sixt @ 2007-11-13 21:35 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711132121440.4362@racer.site>
On Tuesday 13 November 2007 22:22, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 13 Nov 2007, Johannes Sixt wrote:
> > diff --git a/config.c b/config.c
> > index dc3148d..dd7e9ad 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -452,6 +452,11 @@ int git_config_from_file(config_fn_t fn, const char
> > *filename) return ret;
> > }
> >
> > +const char *git_etc_gitconfig(void)
> > +{
> > + return ETC_GITCONFIG;
> > +}
> > +
>
> Wouldn't this logically belong into environment.c?
I don't think so. environment.c is about things that concern the repository.
This is really only about configuration.
-- Hannes
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Michael Smith @ 2007-11-13 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtznqrlrb.fsf@gitster.siamese.dyndns.org>
On Tue, 13 Nov 2007, Junio C Hamano wrote:
> > +$ git checkout master
> > +$ git merge --strategy=ours \
> > + -m "Tie old v1.1 into our history by merging with strategy=ours." \
> > + v1.1
> This would work only when your 'master' happens to be at v1.1
> (and identical to it) isn't it?
>
> People would want to know "But my 'master' is _not_ at v1.1 but
> is _based_ on v1.1. How would I handle that case?"
That was actually my case - my master was based on v1.1. The command
worked for me - I was able to merge in v1.2 from Git afterward - but maybe
I just got lucky, so I'd be interested to know the right thing to do.
I think --strategy=ours just leaves the files as is on master and creates
a merge commit with two parents: master and v1.1. So anything between v1.1
and v1.2, on the upstream branch, is fair game to be merged next time.
So, say I started with this:
---------------
old snapshot branch: snap-v1.0---snap-v1.1
\ \
master: o---o---o---o--o-o
new Git upstream: o--o-v1.0-o-o-o-o-o-o-v1.1-o-o-v1.2
---------------
I could make the merge with --strategy=ours:
---------------
old snapshot branch: snap-v1.0---snap-v1.1
\ \
master: o---o---o---o--o-o--o
/
new Git upstream: o--o-v1.0-o-o-o-o-o-o-v1.1-o-o-v1.2
---------------
Then I'd free to merge in v1.2:
---------------
master: o---o---o---o--o-o--o------o
/ /
new Git upstream: o--o-v1.0-o-o-o-o-o-o-v1.1-o-o-v1.2
---------------
Hmm, looks like a toothbrush. But is it right?
Mike
^ permalink raw reply
* Re: [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
From: Johannes Schindelin @ 2007-11-13 21:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1194984306-3181-6-git-send-email-johannes.sixt@telecom.at>
Hi,
On Tue, 13 Nov 2007, Johannes Sixt wrote:
> diff --git a/sha1_file.c b/sha1_file.c
> index f007874..560c0e0 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -86,7 +86,7 @@ int safe_create_leading_directories(char *path)
> char *pos = path;
> struct stat st;
>
> - if (*pos == '/')
> + if (is_absolute_path(path))
> pos++;
Is this enough? On Windows, certain "absolute" paths would need "pos +=
3", no?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
From: Johannes Sixt @ 2007-11-13 21:43 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711132138360.4362@racer.site>
On Tuesday 13 November 2007 22:39, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 13 Nov 2007, Johannes Sixt wrote:
> > diff --git a/sha1_file.c b/sha1_file.c
> > index f007874..560c0e0 100644
> > --- a/sha1_file.c
> > +++ b/sha1_file.c
> > @@ -86,7 +86,7 @@ int safe_create_leading_directories(char *path)
> > char *pos = path;
> > struct stat st;
> >
> > - if (*pos == '/')
> > + if (is_absolute_path(path))
> > pos++;
>
> Is this enough? On Windows, certain "absolute" paths would need "pos +=
> 3", no?
True, but this series is not yet about the MinGW port itself. It will be
changed eventually, but not at this time.
-- Hannes
^ permalink raw reply
* Re: [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
From: Johannes Schindelin @ 2007-11-13 21:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <200711132235.13463.johannes.sixt@telecom.at>
Hi,
On Tue, 13 Nov 2007, Johannes Sixt wrote:
> On Tuesday 13 November 2007 22:22, Johannes Schindelin wrote:
>
> > On Tue, 13 Nov 2007, Johannes Sixt wrote:
> > > diff --git a/config.c b/config.c
> > > index dc3148d..dd7e9ad 100644
> > > --- a/config.c
> > > +++ b/config.c
> > > @@ -452,6 +452,11 @@ int git_config_from_file(config_fn_t fn, const char
> > > *filename) return ret;
> > > }
> > >
> > > +const char *git_etc_gitconfig(void)
> > > +{
> > > + return ETC_GITCONFIG;
> > > +}
> > > +
> >
> > Wouldn't this logically belong into environment.c?
>
> I don't think so. environment.c is about things that concern the
> repository. This is really only about configuration.
I thought that environment.c is about getting certain settings from the
environment. In that sense, git_etc_gitconfig() would live a happier life
there.
But I do not care all that deeply. I know _I_ would have looked for it in
environment.c first, but then, there's always good ole' git-grep.
Ciao,
Dscho
^ permalink raw reply
* Re: Strange "beagle" interaction..
From: Jon Smirl @ 2007-11-13 21:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: J. Bruce Fields, Junio C Hamano, Git Mailing List,
Johannes Schindelin
In-Reply-To: <alpine.LFD.0.9999.0711131326310.2786@woody.linux-foundation.org>
On 11/13/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Tue, 13 Nov 2007, J. Bruce Fields wrote:
> >
> > Last I ran across this, I believe I found it was adding extended
> > attributes to the file.
>
> Yeah, I just straced it and found the same thing. It's saving fingerprints
> and mtimes to files in the extended attributes.
Things like Beagle need a guaranteed log of global inotify events.
That would let them efficiently find changes made since the last time
they updated their index.
Right now every time Beagle starts it hasn't got a clue what has
changed in the file system since it was last run. This forces Beagle
to rescan the entire filesystem every time it is started. The xattrs
are used as cache to reduce this load somewhat.
A better solution would be for the kernel to log inotify events to
disk in a manner that survives reboots. When Beagle starts it would
locate its last checkpoint and then process the logged inotify events
from that time forward. This inotify logging needs to be bullet proof
or it will mess up your Beagle index.
Logged files systems already contain the logged inotify data (in their
own internal form). There's just no universal API for retrieving it in
a file system independent manner.
>
> > Yeah, I just turned off beagle. It looked to me like it was doing
> > something wrongheaded.
>
> Gaah. The problem is, setting xattrs does actually change ctime. Which
> means that if we want to make git play nice with beagle, I guess we have
> to just remove the comparison of ctime.
>
> Oh, well. Git doesn't *require* it, but I like the notion of checking the
> inode really really carefully. But it looks like it may not be an option,
> because of file indexers hiding stuff behind our backs.
>
> Or we could just tell people not to run beagle on their git trees, but I
> suspect some people will actually *want* to. Even if it flushes their disk
> caches.
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Johannes Schindelin @ 2007-11-13 21:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <200711132232.11730.johannes.sixt@telecom.at>
Hi,
On Tue, 13 Nov 2007, Johannes Sixt wrote:
> On Tuesday 13 November 2007 22:10, Junio C Hamano wrote:
> > Johannes Sixt <johannes.sixt@telecom.at> writes:
> > > On Tuesday 13 November 2007 21:04, Johannes Sixt wrote:
> > >> [PATCH 09/11] Allow a relative builtin template directory.
> > >> [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
> > >> of ETC_GITCONFIG.
> > >> [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
> > >>
> > >> These need probably some discussion. They avoid that $(prefix) is
> > >> hardcoded and so allows that an arbitrary installation directory.
> > >
> > > ... and so allow that the compiled binaries are installed in any
> > > directory that the user chooses.
> >
> > If you can do that without breaking the tests (specifically, the
> > test script should pick up the version of git you just built,
> > not from /usr/bin nor /usr/local/stow/git/bin) that would be
> > great.
>
> Sorry, I don't understand your statement. Do you see any tests breaking?
I guess what Junio is getting at: if your changes could lead to our not
needing to hard code defaults, that would be awesome.
For example, a very unhappy camper reported recently that installing git
with a different prefix triggers a complete rebuild.
Ciao,
Dscho
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Alex Riesen @ 2007-11-13 21:48 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18233.47472.890658.729250@lisa.zopyra.com>
Bill Lear, Tue, Nov 13, 2007 15:49:20 +0100:
> >> >> We have an NFS-mounted filesystem, and git pull is choking on it.
> >> >>
> >> >> % uname -a
> >> >> Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
> >
> >It is a really old kernel... Maybe you could try with some of the
> >recent ones?
>
> I'll see if we can: the machine in question is a high security one,
> and not easy to change. We haven't seen this sort of problem
> elsewhere on our newer systems as far as I know.
Suspected that :)
> >I extend the part you quoted. The file is opened here:
> >...
> >This is strange. The current git should not produce anything like
> >this (and does not, here). ...
>
> You are absolutely correct. My comrade ran this with 1.5.0.1 by
> mistake. He reran the strace with 1.5.3.5, and I have replaced
> the tarball on my server:
>
> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
Still looks like v1.5.0.1:
write(2, "fatal: ", 7) = 7
write(2, "cannot pread pack file: No such "..., 49) = 49
> With this minor correction (!), here is the last part from
> the last file (strace.out.26001):
I think it got worse:
> write(3, "\360]|\204\205\317|\352\336C\342\316\206\334\326\201\211"..., 4096) = 4096
> write(3, "\20\t\33if (cached_vias.insert(die,\227\17"..., 4096) = 4096
The data in packs is zlib-compressed. I don't think you should be able
to see any readable strings in them (except for "PACK" in the header).
I believe you have a data corruption now.
Does git-fsck --all say anything about that, BTW?
Besides, could you try with a git compiled with NO_PREAD?
^ permalink raw reply
* Re: [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
From: Johannes Schindelin @ 2007-11-13 21:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <200711132243.05877.johannes.sixt@telecom.at>
Hi,
On Tue, 13 Nov 2007, Johannes Sixt wrote:
> On Tuesday 13 November 2007 22:39, Johannes Schindelin wrote:
>
> > On Tue, 13 Nov 2007, Johannes Sixt wrote:
> > > diff --git a/sha1_file.c b/sha1_file.c
> > > index f007874..560c0e0 100644
> > > --- a/sha1_file.c
> > > +++ b/sha1_file.c
> > > @@ -86,7 +86,7 @@ int safe_create_leading_directories(char *path)
> > > char *pos = path;
> > > struct stat st;
> > >
> > > - if (*pos == '/')
> > > + if (is_absolute_path(path))
> > > pos++;
> >
> > Is this enough? On Windows, certain "absolute" paths would need "pos +=
> > 3", no?
>
> True, but this series is not yet about the MinGW port itself. It will be
> changed eventually, but not at this time.
Okay, fair enough.
Ciao,
Dscho
^ permalink raw reply
* git-clean won't read global ignore
From: shunichi fuji @ 2007-11-13 21:49 UTC (permalink / raw)
To: git
hi, i setup git to use with eclipse through global excludesfile config.
git-status report just ignore files, but git-clean deleted ignore files.
----
$ git-config -l
core.excludesfile=/home/pal/.gitignore
$ cat /home/pal/.gitignore
# ignore for eclipse
.project
.cproject
$ git-status
# On branch master
nothing to commit (working directory clean)
$ git-clean
Removing .project
^ permalink raw reply
* Re: Strange "beagle" interaction..
From: David Brown @ 2007-11-13 21:49 UTC (permalink / raw)
To: Jon Smirl
Cc: Linus Torvalds, J. Bruce Fields, Junio C Hamano, Git Mailing List,
Johannes Schindelin
In-Reply-To: <9e4733910711131344t381b939dg47b5e078c52be3b2@mail.gmail.com>
On Tue, Nov 13, 2007 at 04:44:33PM -0500, Jon Smirl wrote:
>A better solution would be for the kernel to log inotify events to
>disk in a manner that survives reboots. When Beagle starts it would
>locate its last checkpoint and then process the logged inotify events
>from that time forward. This inotify logging needs to be bullet proof
>or it will mess up your Beagle index.
Perhaps something similar to FsEvents on OSX which is a daemon that
interfaces with the OS to record this very information.
It only works across clean reboots, but it does work there. Do a bad
shutdown, and your next backup or index take a long time to go scan
everything.
It would also be wonderful to have this for backups as well.
Dave
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-13 21:48 UTC (permalink / raw)
To: Brian Gernhardt
Cc: Shawn O. Pearce, Junio C Hamano, Johannes Schindelin, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <CBAEC42B-9F50-4723-9847-640D9832532E@silverinsanity.com>
Brian Gernhardt <benji@silverinsanity.com> writes:
> On Nov 13, 2007, at 5:50 AM, Matthieu Moy wrote:
>
>> While clone normally does a bit more:
>>
>> [remote "origin"]
>> url = /tmp/git1/.git
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>
> But how is clone expected to do that when the origin is an empty
> repo? There is no branch for it to track, and automagically setting
> it to master is bogus because then it's tracking something that
> doesn't exist.
An implementation of that would probably need to special-case the
empty repository. But an empty repository is already a special case.
HEAD already points to master, and master is already hardcoded here:
$ cat .git/HEAD
ref: refs/heads/master
So, it's possible for HEAD to point to a branch which doesn't exist
yet, it's possible to commit to a branch which doesn't exist yet. It
would make sense to extend that to allow a remote to point to a branch
which doesn't exist either.
But don't get me wrong: I probably won't implement that myself, so I
can't _ask_ people to do it for me. I would just appreciate if people
stopped calling me (and other users interested in a sane empty clone
behavior) idiot because I think it would make sense to do it.
--
Matthieu
^ permalink raw reply
* Re: Strange "beagle" interaction..
From: J. Bruce Fields @ 2007-11-13 21:50 UTC (permalink / raw)
To: Jon Smirl
Cc: Linus Torvalds, Junio C Hamano, Git Mailing List,
Johannes Schindelin
In-Reply-To: <9e4733910711131344t381b939dg47b5e078c52be3b2@mail.gmail.com>
On Tue, Nov 13, 2007 at 04:44:33PM -0500, Jon Smirl wrote:
> On 11/13/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >
> > On Tue, 13 Nov 2007, J. Bruce Fields wrote:
> > >
> > > Last I ran across this, I believe I found it was adding extended
> > > attributes to the file.
> >
> > Yeah, I just straced it and found the same thing. It's saving fingerprints
> > and mtimes to files in the extended attributes.
>
> Things like Beagle need a guaranteed log of global inotify events.
> That would let them efficiently find changes made since the last time
> they updated their index.
Wouldn't a simple change-attribute get you most of the way there? All
you need is a number that's guaranteed to increase any time a file is
updated.
Lacking that, git's current approach (snapshot all the stat data, then
look closer at any files that appear to have been touched within a
second of the stat) seems pretty sensible.
--b.
> Right now every time Beagle starts it hasn't got a clue what has
> changed in the file system since it was last run. This forces Beagle
> to rescan the entire filesystem every time it is started. The xattrs
> are used as cache to reduce this load somewhat.
>
> A better solution would be for the kernel to log inotify events to
> disk in a manner that survives reboots. When Beagle starts it would
> locate its last checkpoint and then process the logged inotify events
> from that time forward. This inotify logging needs to be bullet proof
> or it will mess up your Beagle index.
>
> Logged files systems already contain the logged inotify data (in their
> own internal form). There's just no universal API for retrieving it in
> a file system independent manner.
^ permalink raw reply
* Re: [PATCH 1/2] t/t3404: fix test for a bogus todo file.
From: Johannes Schindelin @ 2007-11-13 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcjpsv9a.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 13 Nov 2007, Junio C Hamano wrote:
> The test wants to see if there are still remaining tasks, but checked a
> wrong file.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> t/t3404-rebase-interactive.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 1113904..f1039d1 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -149,7 +149,7 @@ test_expect_success 'stop on conflicting pick' '
> diff -u expect .git/.dotest-merge/patch &&
> diff -u expect2 file1 &&
> test 4 = $(grep -v "^#" < .git/.dotest-merge/done | wc -l) &&
> - test 0 = $(grep -v "^#" < .git/.dotest-merge/todo | wc -l)
> + test 0 = $(grep -v "^#" < .git/.dotest-merge/git-rebase-todo | wc -l)
Oh well, another fallout of my brilliant name picking.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Johannes Sixt @ 2007-11-13 21:54 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711132145400.4362@racer.site>
On Tuesday 13 November 2007 22:46, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 13 Nov 2007, Johannes Sixt wrote:
> > On Tuesday 13 November 2007 22:10, Junio C Hamano wrote:
> > > Johannes Sixt <johannes.sixt@telecom.at> writes:
> > > > On Tuesday 13 November 2007 21:04, Johannes Sixt wrote:
> > > >> [PATCH 09/11] Allow a relative builtin template directory.
> > > >> [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
> > > >> of ETC_GITCONFIG.
> > > >> [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
> > > >>
> > > >> These need probably some discussion. They avoid that $(prefix) is
> > > >> hardcoded and so allows that an arbitrary installation directory.
> > > >
> > > > ... and so allow that the compiled binaries are installed in any
> > > > directory that the user chooses.
> > >
> > > If you can do that without breaking the tests (specifically, the
> > > test script should pick up the version of git you just built,
> > > not from /usr/bin nor /usr/local/stow/git/bin) that would be
> > > great.
> >
> > Sorry, I don't understand your statement. Do you see any tests breaking?
>
> I guess what Junio is getting at: if your changes could lead to our not
> needing to hard code defaults, that would be awesome.
>
> For example, a very unhappy camper reported recently that installing git
> with a different prefix triggers a complete rebuild.
[PATCH 10/11] is one step into this direction.
-- Hannes
^ permalink raw reply
* Re: [PATCH 4/2] Fix parent rewriting in --early-output
From: Paul Mackerras @ 2007-11-13 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Marco Costalba, Git Mailing List
In-Reply-To: <7vbq9yt1te.fsf@gitster.siamese.dyndns.org>
Junio C Hamano writes:
> I suspect that a "-" in place of a commit object name may not be
> enough for your purpose, as the _number_ of parents can later
> change in the later re-output.
I don't mind if a commit that has "-" as one of its parents later
turns out to have more parents (i.e. the "-" can stand for zero or
more unknown parents). I would be perturbed if a commit that didn't
have any "-" in its parent list later turned out to have a different
number of parents - but I don't think that's what you're implying, is
it?
> I wonder if the presense of "incomplete" on the "Final output"
> line is a good enough indication for that. That is, until you
> see "Final output: $N done", you will treat the parent
> information as unreliable.
The easiest way for me to handle an unreliable parent is just to
ignore it. But I can't ignore all the parents, because then I
wouldn't have a graph at all.
In other words, the presence of "incomplete" doesn't give me any clue
as to which particular parent ids are reliable. As far as I can see,
git log internally knows when a parent id is unreliable (it's one
where it had to terminate the history simplification early), so it
shouldn't be hard to tell gitk about that. And it would make my job a
lot easier.
Paul.
^ permalink raw reply
* Re: Strange "beagle" interaction..
From: Mike Hommey @ 2007-11-13 21:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, Johannes Schindelin
In-Reply-To: <alpine.LFD.0.9999.0711131241050.2786@woody.linux-foundation.org>
On Tue, Nov 13, 2007 at 12:56:19PM -0800, Linus Torvalds wrote:
>
> Ok, I've made a bugzilla entry for this for the Fedora people, but I
> thought I'd mention something I noticed yesterday but only tracked down
> today: it seems like the beagle file indexing code is able to screw up git
> in subtle ways.
>
> I do not know exactly what happens, but the symptoms are random (and
> quite hard-to-trigger) dirty index contents where git believes that some
> set of files are not clean in the index.
>
> I *suspect* that beagle is playing games with the file access times,
> causing the ctime on disk to not match the ce_ctime in the index file. But
> that's just a guess.
(...)
IIRC, beagle stores a bunch of useful information for itself in extended
attributes on indexed files. It is likely that it's that that is
tampering with the file stats.
Mike
^ permalink raw reply
* Re: Strange "beagle" interaction..
From: Jon Smirl @ 2007-11-13 21:58 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Linus Torvalds, Junio C Hamano, Git Mailing List,
Johannes Schindelin
In-Reply-To: <20071113215047.GG22590@fieldses.org>
On 11/13/07, J. Bruce Fields <bfields@fieldses.org> wrote:
> On Tue, Nov 13, 2007 at 04:44:33PM -0500, Jon Smirl wrote:
> > On 11/13/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > >
> > >
> > > On Tue, 13 Nov 2007, J. Bruce Fields wrote:
> > > >
> > > > Last I ran across this, I believe I found it was adding extended
> > > > attributes to the file.
> > >
> > > Yeah, I just straced it and found the same thing. It's saving fingerprints
> > > and mtimes to files in the extended attributes.
> >
> > Things like Beagle need a guaranteed log of global inotify events.
> > That would let them efficiently find changes made since the last time
> > they updated their index.
>
> Wouldn't a simple change-attribute get you most of the way there? All
> you need is a number that's guaranteed to increase any time a file is
> updated.
You still need to look at every file in the file system. People can
have many millions of files in their file systems (I have two million
in mine and that's small). The inotify log is the most efficient
solution.
I've turned Beagle off simply because it beats on my disk for an hour
after I reboot.
>
> Lacking that, git's current approach (snapshot all the stat data, then
> look closer at any files that appear to have been touched within a
> second of the stat) seems pretty sensible.
>
> --b.
>
> > Right now every time Beagle starts it hasn't got a clue what has
> > changed in the file system since it was last run. This forces Beagle
> > to rescan the entire filesystem every time it is started. The xattrs
> > are used as cache to reduce this load somewhat.
> >
> > A better solution would be for the kernel to log inotify events to
> > disk in a manner that survives reboots. When Beagle starts it would
> > locate its last checkpoint and then process the logged inotify events
> > from that time forward. This inotify logging needs to be bullet proof
> > or it will mess up your Beagle index.
> >
> > Logged files systems already contain the logged inotify data (in their
> > own internal form). There's just no universal API for retrieving it in
> > a file system independent manner.
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-13 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <7vir46t2cc.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> To create an initial commit in a bare repository, the most natural way
>> for me is to clone it, create the commit in the clone, and then push.
>>
>> Bare-ness _does_ matter for that.
>
> You are still wrong.
>
> The most natural is to create a commit in a non-bare repository
> you create, and push into a bare empty repository.
Yes, we agree on that point.
But I do find (incorrect with current git)
(1)
$ mkdir ~/bare-repo
$ cd ~/bare-repo
$ git --bare init
$ cd
$ git clone bare-repo local/non-bare
$ cd local/non-bare
<put files, git add, git commit>
$ git push
Simpler than (valid with current git)
(2)
$ mkdir ~/bare-repo
$ cd ~/bare-repo
$ git --bare init
$ cd
$ mkdir local/non-bare
$ cd local/non-bare
$ git init
<put files, git add, git commit>
$ git push ~/bare-repo
$ git remote add origin ~/bare-repo
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master
Where the bare-ness of ~/bare-repo matters is that with a bare
repository, I could have actually created the initial commit there
(valid with current git too):
(3)
$ mkdir ~/non-bare-repo
$ cd ~/non-bare-repo
$ git init
<put files, git add, git commit>
$ cd
$ git clone bare-repo local/non-bare
> The repository that is pushed into can be non-bare, but bareness of
> that does _NOT_ matter.
Either there is a way to achive (3) above with a bare repository which
I don't know, or bare-ness does matter in this case.
--
Matthieu
^ permalink raw reply
* Trivial patch to git-svn
From: David Reiss @ 2007-11-13 21:56 UTC (permalink / raw)
To: git
From d9f93dc1c503c5f42b27485b2c35b38e8c9bca44 Mon Sep 17 00:00:00 2001
From: David Reiss <dreiss@dreiss-vmware.(none)>
Date: Tue, 13 Nov 2007 13:47:26 -0800
Subject: [PATCH] Fix a typo and add a comma in an error message in git-svn
Signed-off-by: David Reiss <dreiss@facebook.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index e3e00fd..981cdd6 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -391,7 +391,7 @@ sub cmd_set_tree {
sub cmd_dcommit {
my $head = shift;
git_cmd_try { command_oneline(qw/diff-index --quiet HEAD/) }
- 'Cannot dcommit with a dirty index. Commit your changes first'
+ 'Cannot dcommit with a dirty index. Commit your changes first, '
. "or stash them with `git stash'.\n";
$head ||= 'HEAD';
my @refs;
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Junio C Hamano @ 2007-11-13 22:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0711132145400.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 13 Nov 2007, Johannes Sixt wrote:
>> On Tuesday 13 November 2007 22:10, Junio C Hamano wrote:
>> > Johannes Sixt <johannes.sixt@telecom.at> writes:
>> > > On Tuesday 13 November 2007 21:04, Johannes Sixt wrote:
>> > > ... and so allow that the compiled binaries are installed in any
>> > > directory that the user chooses.
>> >
>> > If you can do that without breaking the tests (specifically, the
>> > test script should pick up the version of git you just built,
>> > not from /usr/bin nor /usr/local/stow/git/bin) that would be
>> > great.
>>
>> Sorry, I don't understand your statement. Do you see any tests breaking?
>
> I guess what Junio is getting at: if your changes could lead to our not
> needing to hard code defaults, that would be awesome.
Yes. Another thing I said was that it would be grave regression
for testability if the change leads git to look at somewhere
else other than it was told to look via GIT_EXEC_PATH
environment,
^ permalink raw reply
* Re: wishlist: git info
From: Andreas Ericsson @ 2007-11-13 22:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Thomas Neumann, git
In-Reply-To: <20071113212259.GG3268@steel.home>
Alex Riesen wrote:
> Johannes Schindelin, Tue, Nov 13, 2007 12:13:59 +0100:
>>> I use an alias with the commands proposed by Alex Riessen for now, but a
>>> more general command would be nice.
>> His name is "Riesen", just like in the German translation of the famous
>> Newton statement.
>
> now I am misspelled. How should I feel?...
>
Better than if you'd done it yourself in a patch that was allowed to endure
for more than 10000 commits ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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