* Re: [QUESTION] about .git/info/grafts file
From: Franck @ 2006-01-19 13:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <43CF739F.2030204@op5.se>
2006/1/19, Andreas Ericsson <ae@op5.se>:
> Junio C Hamano wrote:
> > Franck <vagabon.xyz@gmail.com> writes:
> >
> >
> >>I'm wondering why the "grafts" files is not involved during
> >>push/pull/clone operations ?
> >
> >
> > Commit ancestry grafting is a local repository issue and even if
> > you manage to lie to your local git that 300,000th commit is the
> > epoch, the commit object you send out to the downloader would
> > record its true parent (or parents, if it is a merge), so the
> > downloader would want to go further back. And no, rewriting
> > that commit and feeding a parentless commit to the downloader is
> > not an option, because such a commit object would have different
> > object name and unpack-objects would be unhappy.
> >
>
>
> I'm a bit curious about how this was done for the public kernel repo.
> I'd like to import glibc to git, but keeping history since 1972 seems a
> bloody waste, really.
>
That's exactly my point. Futhermore make your downloaders import that
useless history spread this waste.
I guess kernel repo will encounter this problem in short term. It's
being bigger and bigger and developpers may be borred to deal with so
many useless objects. But I'm not saying that it's bad thing to keep
that history. It just would be nice to allow developpers that don't
care about old history to get rid of it.
Thanks
--
Franck
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Petr Baudis @ 2006-01-19 13:09 UTC (permalink / raw)
To: Franck; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <cda58cb80601190251v5251c8bdh@mail.gmail.com>
Dear diary, on Thu, Jan 19, 2006 at 11:51:22AM CET, I got a letter
where Franck <vagabon.xyz@gmail.com> said that...
> well, dealing with a repo that has more than 300,000 objects becomes a
> burden. A lots of git commands are slow, and cloning it take a while !
Were the objects packed? It would be interesting to have some data about
how GIT performs with that much objects...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Petr Baudis @ 2006-01-19 13:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Franck, Git Mailing List
In-Reply-To: <43CF739F.2030204@op5.se>
Dear diary, on Thu, Jan 19, 2006 at 12:10:23PM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> Junio C Hamano wrote:
> >Franck <vagabon.xyz@gmail.com> writes:
> >
> >
> >>I'm wondering why the "grafts" files is not involved during
> >>push/pull/clone operations ?
> >
> >
> >Commit ancestry grafting is a local repository issue and even if
> >you manage to lie to your local git that 300,000th commit is the
> >epoch, the commit object you send out to the downloader would
> >record its true parent (or parents, if it is a merge), so the
> >downloader would want to go further back. And no, rewriting
> >that commit and feeding a parentless commit to the downloader is
> >not an option, because such a commit object would have different
> >object name and unpack-objects would be unhappy.
>
> I'm a bit curious about how this was done for the public kernel repo.
> I'd like to import glibc to git, but keeping history since 1972 seems a
> bloody waste, really.
FWIW, with the ELinks GIT repository we just started from scratch and
then converted the old CVS repository, and provided this script in
contrib/grafthistory.sh:
#!/bin/sh
#
# Graft the ELinks development history to the current tree.
#
# Note that this will download about 80M.
if [ -z "`which wget 2>/dev/null`" ]; then
echo "Error: You need to have wget installed so that I can fetch the history." >&2
exit 1
fi
[ "$GIT_DIR" ] || GIT_DIR=.git
if ! [ -d "$GIT_DIR" ]; then
echo "Error: You must run this from the project root (or set GIT_DIR to your .git directory)." >&2
exit 1
fi
cd "$GIT_DIR"
echo "[grafthistory] Downloading the history"
mkdir -p objects/pack
cd objects/pack
wget -c http://elinks.cz/elinks-history.git/objects/pack/pack-0d6c5c67aab3b9d5d9b245da5929c15d79124a48.idx
wget -c http://elinks.cz/elinks-history.git/objects/pack/pack-0d6c5c67aab3b9d5d9b245da5929c15d79124a48.pack
echo "[grafthistory] Setting up the grafts"
cd ../..
mkdir -p info
# master
echo 0f6d4310ad37550be3323fab80456e4953698bf0 06135dc2b8bb7ed2e441305bdaa82048396de633 >>info/grafts
# REL_0_10
echo 43a9a406737fd22a8558c47c74b4ad04d4c92a2b 730242dcf2cdeed13eae7e8b0c5f47bb03326792 >>info/grafts
echo "[grafthistory] Refreshing the dumb server info wrt. new packs"
cd ..
git-update-server-info
So you checkout the ELinks repository and if you want the full history
you just run this script and it does everything for you.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Petr Baudis @ 2006-01-19 13:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com>
I actually forgot to look at the patch.
Dear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> Makefile | 2 +-
> daemon.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> 59379c380a6c2829c5614aadd4a5492abb8d14c8
> diff --git a/Makefile b/Makefile
> index f6d9e0a..5782e2a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -342,7 +342,7 @@ ifdef NO_MMAP
> COMPAT_OBJS += compat/mmap.o
> endif
> ifdef NO_IPV6
> - ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
> + ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_stg_git=sockaddr_in
+else
+ ALL_CFLAGS += -Dsockaddr_stg_git=sockaddr_storage
> endif
>
> ifdef PPC_SHA1
But of course when this goes on, soon the gcc commandline will get
really awfully ugly. This is why something _like_ autoconf is a good
thing - you can just detect if the system headers provide the type and
#define it only when they don't.
Of course, inserting the #define to some .h file might work; I'm not
sure if any of the relevant socket routines is permitted to be a macro
which could expand to something - but even then, it's probably not very
likely that it would break stuff in practice.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Petr Baudis @ 2006-01-19 12:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com>
Dear diary, on Wed, Jan 18, 2006 at 02:47:00PM CET, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> For reasons unknown, cygwin decided to use our sockaddr_storage.
> As it is redefined to sockaddr_in it'd cause compilation errors in
> cygwin headers. Fixed by first patch, which uses a more git-related
> name (can we claim rights for the symbol, being first to use it? :-)
Huh? "Our"? See RFC 2553 and e.g.:
http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html
You have no business meddling with this identifier except working around
platforms which do not support it, but then do not complain that things
break when the platforms actually start supporting it. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] Lower priority of Cogito's default exclude patterns
From: Petr Baudis @ 2006-01-19 12:42 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060119100712.GA12154@diana.vm.bytemark.co.uk>
Dear diary, on Thu, Jan 19, 2006 at 11:07:12AM CET, I got a letter
where Karl Hasselström <kha@treskal.com> said that...
> On 2006-01-07 23:19:31 +0100, Karl Hasselström wrote:
>
> > Put the default exclude patterns in a file referenced with
> > --exclude-from, instead of on the command line with --exclude. (The
> > existing behavior was bad since --exclude has higher priority than
> > --exclude-from and --exclude-per-directory, which made it impossible
> > for the user to override the default patterns.)
> >
> > Signed-off-by: Karl Hasselström <kha@treskal.com>
> >
> > ---
> >
> > Makefile | 15 +++++++++++++--
> > cg-Xlib | 6 +++++-
> > cg-default-exclude | 6 ++++++
> > 3 files changed, 24 insertions(+), 3 deletions(-)
>
> Did you miss this patch, or just not like it?
Just postponed for next sweep through my patch queue, due today or
tomorrow. ;) I will rename cg-default-exclude to default-exclude,
though.
Oh, now I remember - one my major concern is that now Cogito will not
work if not make install'd, which is how I actually primarily use it on
my machine.
Sorry for the delay,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: New ref generates 8MB mail message
From: Andreas Ericsson @ 2006-01-19 12:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthew Wilcox, git
In-Reply-To: <Pine.LNX.4.64.0601180810330.3240@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 18 Jan 2006, Matthew Wilcox wrote:
>
>>Based on the idea that a new branch is probably a branch off master, and
>>if it isn't, then at least sending a log vs master is better than a log
>>vs the beginning of time, I propose this patch:
>
>
> Actually, since the update hook _should_ be called before the ref has
> actually been updated, it's probably much better to instead of this:
>
>
>>- git-rev-list --pretty "$3"
>>+ git-rev-list --pretty "$3" ^master
>
>
> do something like this:
>
> git-rev-list --pretty "$3" $(git-rev-parse --not --all)
>
> which basically says: show any commits that are in the new ref, but are
> not in _any_ other ref.
>
> Untested, of course.
>
Tested. It works fine and is, surprisingly, insanely fast.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Joining Repositories
From: Mathias Waack @ 2006-01-19 11:36 UTC (permalink / raw)
To: git
In-Reply-To: <20060118141442.GP28365@pasky.or.cz>
Hello Petr,
On Wednesday 18 January 2006 03:14 pm, Petr Baudis wrote:
> > ...git-read-tree doesn't know the parameter --prefix (just downloaded and
> > tried it on 0.99.9i). What version shall I use?
>
> oops, it seems this is only in the latest pu branch of git. If you are
> not brave enough for that,
I think I am;)
> you will need to use the prefix facility of
> checkout-index instead, and it'll take much longer:
>
> git-read-tree $commit
> git-checkout-index -a --prefix=r1/
> rm .git/index
> cg-add -r r1/
> rm -rf r1
> .. then proceed with git-cat-file etc ..
Time doesn't matter (in this case). This solution seems to work.
> Note that I'm not sure when which feature was introduced. Your best
> bet is to just use the latest stable GIT/Cogito versions.
Thanks for your suggestions, I've got a working solution. Now I'm going to
spend the remaining days of this week by trying to understand why it works.
Mathias
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Andreas Ericsson @ 2006-01-19 11:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck, Git Mailing List
In-Reply-To: <7v8xtdrqwg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Franck <vagabon.xyz@gmail.com> writes:
>
>
>>I'm wondering why the "grafts" files is not involved during
>>push/pull/clone operations ?
>
>
> Commit ancestry grafting is a local repository issue and even if
> you manage to lie to your local git that 300,000th commit is the
> epoch, the commit object you send out to the downloader would
> record its true parent (or parents, if it is a merge), so the
> downloader would want to go further back. And no, rewriting
> that commit and feeding a parentless commit to the downloader is
> not an option, because such a commit object would have different
> object name and unpack-objects would be unhappy.
>
I'm a bit curious about how this was done for the public kernel repo.
I'd like to import glibc to git, but keeping history since 1972 seems a
bloody waste, really.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Franck @ 2006-01-19 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v8xtdrqwg.fsf@assigned-by-dhcp.cox.net>
Thanks Junio for answering
2006/1/19, Junio C Hamano <junkio@cox.net>:
> Franck <vagabon.xyz@gmail.com> writes:
>
> > I'm wondering why the "grafts" files is not involved during
> > push/pull/clone operations ?
>
> Commit ancestry grafting is a local repository issue and even if
> you manage to lie to your local git that 300,000th commit is the
> epoch, the commit object you send out to the downloader would
> record its true parent (or parents, if it is a merge), so the
> downloader would want to go further back. And no, rewriting
> that commit and feeding a parentless commit to the downloader is
> not an option, because such a commit object would have different
> object name and unpack-objects would be unhappy.
>
> If you choose not to have full history in your public repository
> for whatever reason (ISP server diskquota comes to mind)
well, dealing with a repo that has more than 300,000 objects becomes a
burden. A lots of git commands are slow, and cloning it take a while !
> that is
> OK, but be honest about it to your downloaders. Tell them that
> you do not have the full history, and they first need to clone
> from some other repository you started your development upon, in
> order to use what you added upon. "This repository does not
> have all the history -- please first clone from XX repository
> (you need at least xxx commit), and then do another 'git pull'
> from here", or something like that.
>
I don't try to hide or lie to my downloaders. I just want them to
avoid to deal with totaly pointless history. My work have been started
recently and is based on current XX repository. IMHO storing, dealing
with objects which are more than 10 years old is useless.
I don't see why it is so bad to create a "grafted" repository ? I want
it to be small but still want to merge by using git-resolve with XX
repository.
>
> > $ git-merge-base master origin
> > # nothing
>
> Maybe you did not use grafts properly to cauterize?
Well in my graft file I did:
$ cat > .git/info/grafts
<shaid> <shaid>
$
By reading "Documentation/repository-layout.txt", I thought it would
have been the right thing to do. If I did the same like you did ie:
$ cat > .git/info/grafts
<shaid>
$
It works.
Thanks
--
Franck
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Alex Riesen @ 2006-01-19 10:42 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060119052914.GC8121@trixie.casa.cgf.cx>
On 1/19/06, Christopher Faylor <me@cgf.cx> wrote:
> "They" probably don't like it when people treat an open source project as
> if it was some unresponsive proprietary enterprise which does not listen
> to or accept patches.
Please, accept my appologies for the sarcasm in the original post.
Sometimes I get an impression of cygwin being not maintained at
all, and that, if not justifies my behavior, but at least is an attempt
to explain it.
> >And on top of that, they removed dirent->d_ino (or probably replaced it
> >by __ino32, if at all). BTW, can we somehow avoid using d_ino? It is
> >referenced only in fsck-objects.c Anyway, to workaround this I put
> >
> >COMPAT_CFLAGS += -Dd_ino=__ino32
> >
> >It helps, but surely is not the solution.
>
> I don't see how it could help since __ino32 is not actually filled in
> with anything. In fact, I'll rename the field to __invalid_ino32 to
> make that clear.
But why keep the DT_-macros?! And why there is two fields
hinting at d_ino, and why there is 3 (!) "struct dirent"
definitions in dirent.h (sys/dirent.h)?
Some with different names (d_reserved?).
And if cygwin is aiming for posix, what would d_fd or d_version
be (Open Group Specs v6[1] mention only d_ino and d_name)?
[1] http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
^ permalink raw reply
* [PATCH] Support precise tracking of file modes
From: Petr Baudis @ 2006-01-19 9:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, Adam Hunt, git
In-Reply-To: <7vvewgirlt.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jan 19, 2006 at 08:50:22AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Ryan Anderson <ryan@michonline.com> writes:
>
> > Junio C Hamano wrote:
> >> Adam Hunt <kinema@gmail.com> writes:
> >>
> >>
> >>>Do you have any more details by chance? Does it work? Does it work
> >>>well? How does one do it?
> >>
> >>
> >> I personally feel it is a horrible and stupid thing to do, if by
> >> "version control /etc" you mean to have /.git which controls
> >> /etc/hosts and stuff in place. It would work (git does not
> >> refuse to run as root). But being a *source* control system, we
> >> deliberately refuse to store the full permission bits, so if
> >> your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
> >> have to make sure they stay that way after checking things out.
> >
> > This is, admittedly, a major problem.
>
> An SCM is not a replacement of a backup.
It seems that this is mostly an artificial imposition and it's annoying.
Hey, I need to leave for an exam in 15 minutes and I have few urgent
items in my Cogito TODO (sorry, Pavel!), but I couldn't resist.
Taking "quick'n'dirty" to the extreme _and_ combining it with Linus'
attitude to testing and documentation... ;-)
diff --git a/cache.h b/cache.h
index 29c9e81..0311066 100644
--- a/cache.h
+++ b/cache.h
@@ -94,7 +94,9 @@ struct cache_entry {
#define ce_size(ce) cache_entry_size(ce_namelen(ce))
#define ce_stage(ce) ((CE_STAGEMASK & ntohs((ce)->ce_flags)) >> CE_STAGESHIFT)
-#define ce_permissions(mode) (((mode) & 0100) ? 0755 : 0644)
+extern int track_filemode;
+
+#define ce_permissions(mode) (track_filemode ? (mode) : (((mode) & 0100) ? 0755 : 0644))
static inline unsigned int create_ce_mode(unsigned int mode)
{
if (S_ISLNK(mode))
diff --git a/checkout-index.c b/checkout-index.c
index 53dd8cb..b073baa 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -115,6 +115,8 @@ int main(int argc, char **argv)
int newfd = -1;
int all = 0;
+ git_config(git_default_config);
+
prefix = setup_git_directory();
prefix_length = prefix ? strlen(prefix) : 0;
diff --git a/config.c b/config.c
index 8355224..a92ee0f 100644
--- a/config.c
+++ b/config.c
@@ -222,6 +222,11 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.trackallfilemodes")) {
+ track_filemode = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "core.symrefsonly")) {
only_use_symrefs = git_config_bool(var, value);
return 0;
diff --git a/entry.c b/entry.c
index 410b758..493f2b9 100644
--- a/entry.c
+++ b/entry.c
@@ -87,6 +87,11 @@ static int write_entry(struct cache_entr
return error("git-checkout-index: unable to create file %s (%s)",
path, strerror(errno));
}
+ if (track_filemode) {
+ if (fchmod(fd, ntohl(ce->ce_mode)) < 0)
+ return error("git-checkout-index: unable to chmod file %s (%s)",
+ path, strerror(errno));
+ }
wrote = write(fd, new, size);
close(fd);
free(new);
diff --git a/environment.c b/environment.c
index 0596fc6..53248ec 100644
--- a/environment.c
+++ b/environment.c
@@ -12,6 +12,7 @@
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int trust_executable_bit = 1;
+int track_filemode = 0;
int only_use_symrefs = 0;
int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
diff --git a/fsck-objects.c b/fsck-objects.c
index 90e638e..719add2 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -174,7 +174,8 @@ static int fsck_tree(struct tree *item)
if (!check_strict)
break;
default:
- has_bad_modes = 1;
+ if (!track_filemode || (entry->mode & ~(S_IFREG|0777)))
+ has_bad_modes = 1;
}
if (last) {
diff --git a/read-cache.c b/read-cache.c
index c5474d4..624d2c3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -98,7 +98,7 @@ static int ce_match_stat_basic(struct ca
* "mode changes"
*/
if (trust_executable_bit &&
- (0100 & (ntohl(ce->ce_mode) ^ st->st_mode)))
+ ((track_filemode ? 0777 : 0100) & (ntohl(ce->ce_mode) ^ st->st_mode)))
changed |= MODE_CHANGED;
break;
case S_IFLNK:
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply related
* Re: Something wrong with pickaxe?
From: Andreas Ericsson @ 2006-01-19 9:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Linus Torvalds
In-Reply-To: <7v3bjlt66q.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>>... Junio would be open to
>>more friendly pickaxe semantics if the suggested semantics change was
>>accompanied by an actual diff to implement them.
>
>
> True again. It is hard to be "more friendly" without actually
> generating a diff ;-).
>
I thought generating diffs was fairly cheap. I agree with Linus somewhat
though. I've been puzzled more than once with the pickaxe behaviour when
I give it a function name to search for and want to know when the
calling semantics changed for that function. I usually also end up doing
a whatchanged -p and search it.
It would be neat if the current behaviour could be kept with
--pickaxe-exact but all commits containing changes to lines matching the
string was returned by default. Or possibly --pickaxe-thourough to do
the other way around.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Joining Repositories
From: Petr Baudis @ 2006-01-19 9:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Ryan Anderson, Mathias Waack, git
In-Reply-To: <7v64ohotjj.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jan 19, 2006 at 03:12:00AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> (2) letting a subproject keep its own independent history that
> does not know about other subprojects even after combination
> happens (as opposed to the coolest merge, after which there is
> no git history that does not have gitk as its part).
Which can be an advantage or disadvantage depending on the situation,
but I suspect that it would be rather a disadvantage here.
> So would Cogito subprojects support (will it be in the 0.17?),
Probably in 0.18. I would have the subprojects support complete when
it's already in, and it will be some work, while I don't want to
postpone 0.17 much anymore. But we'll see. ;)
> but it might look less powerful when compared with the "bind" or
> "gitlink", if it comes in the form of the patch Pasky sent to
> the list, since it does not attempt to tie the versions of two
> projects together. Certainly that makes it the easiest to use
> and understand what is going on, though.
By now (I wanted to note that in the original thread when I get to make
a new patch), I've decided to extend the format to allow extra
information stored for the subprojects:
path\t...
This means that I will have to do preprocessing when using this as an
exclude file, but it will let me do the stuff like read-only
subprojects. I could also tie it to a specific version here, but if
gitlink/binds are after all going to get included in Git, I'd rather use
that when it is ready (although the single-git-directory approach does
not make sense to me; but I didn't read part of the thread very
carefully yet).
I think the approaches might be complementary, Cogito subprojects are
just designed for different scenarios than gitlinks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Junio C Hamano @ 2006-01-19 8:59 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060119052914.GC8121@trixie.casa.cgf.cx>
Christopher Faylor <me@cgf.cx> writes:
> "They" probably would like to hear about any irregularities that are found.
> "They" probably don't like it when people treat an open source project as
> if it was some unresponsive proprietary enterprise which does not listen
> to or accept patches.
First of all, thanks for joining our discussion. Being able to
hear from somebody from other project firsthand (not just listen
to somebody talking in his own changelogs and code comments, but
in actual e-mail exchange discussion) lets us put faces and
names to the entity "so far just one of the external projects to
us".
>>For reasons unknown, cygwin decided to use our sockaddr_storage.
I haven't looked at the proposed patch by Alex, so would not
comment on this part, but I'd appreciate your input.
>>For the other, probably unrelated, reasons, they decided to leave
>>declarations of DT_* macros in dirent.h without providing dirent->d_type.
I was wondering what the justification for keeping DT_* without
d_type myself. What is the preferred resolution on this one
from your point of view? I suspect removing d_type while
leaving DT_* was just a transient error and you would want to
remove DT_* as well, in which case the patch on this issue by
Alex would become unnecessary.
>>And on top of that, they removed dirent->d_ino (or probably replaced it
>>by __ino32, if at all). BTW, can we somehow avoid using d_ino? It is
>>referenced only in fsck-objects.c Anyway, to workaround this I put
>>
>>COMPAT_CFLAGS += -Dd_ino=__ino32
>>
>>It helps, but surely is not the solution.
>
> I don't see how it could help since __ino32 is not actually filled in
> with anything. In fact, I'll rename the field to __invalid_ino32 to
> make that clear.
I think renaming __invalid_* makes sense. I'll see how we would
work this around on the git side to make things more portable.
^ permalink raw reply
* Re: /etc in git?
From: Junio C Hamano @ 2006-01-19 7:50 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Adam Hunt, git
In-Reply-To: <43CF3061.2030504@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Junio C Hamano wrote:
>> Adam Hunt <kinema@gmail.com> writes:
>>
>>
>>>Do you have any more details by chance? Does it work? Does it work
>>>well? How does one do it?
>>
>>
>> I personally feel it is a horrible and stupid thing to do, if by
>> "version control /etc" you mean to have /.git which controls
>> /etc/hosts and stuff in place. It would work (git does not
>> refuse to run as root). But being a *source* control system, we
>> deliberately refuse to store the full permission bits, so if
>> your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
>> have to make sure they stay that way after checking things out.
>
> This is, admittedly, a major problem.
An SCM is not a replacement of a backup.
>> You are much better off to keep /usr/src/rootstuff/.git (and
>> working tree files are /usr/src/rootstuff/etc/hosts and
>> friends), have a build procedure (read: Makefile) there, and
>> version control that source directory. I usually have 'install'
>> and 'diff' target in that Makefile, so that I can do this:
>>...
> If you're doing this, especially if you're doing this on multiple
> machines, creating a package is probably a worthwhile thing to
> contemplate as well.
In my workplace environment, the equivalent of the above
/usr/src/rootstuff is accessible throughout the networked
machines (mostly NFS mounted); for things that needs per-host
customization, we do not have /usr/src/rootstuff/etc/hosts but
keep /usr/src/rootstuff/etc/hosts.in as the source, and Makefile
customizes that into a form suitable for installation for each
machine. Especially useful is vfstab.in --- a single source
builds fstab for local mounting and nfs exports, while other
machines have mountpoints and project symlinks pointing into
location automounted from that machine with disk, generated
automatically. This does not match typical "package" use.
^ permalink raw reply
* Re: /etc in git?
From: Ryan Anderson @ 2006-01-19 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Hunt, git
In-Reply-To: <7v64ogkdtu.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
Junio C Hamano wrote:
> Adam Hunt <kinema@gmail.com> writes:
>
>
>>Do you have any more details by chance? Does it work? Does it work
>>well? How does one do it?
>
>
> I personally feel it is a horrible and stupid thing to do, if by
> "version control /etc" you mean to have /.git which controls
> /etc/hosts and stuff in place. It would work (git does not
> refuse to run as root). But being a *source* control system, we
> deliberately refuse to store the full permission bits, so if
> your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
> have to make sure they stay that way after checking things out.
This is, admittedly, a major problem.
If you instead take the viewpoint that the /etc/.git/ repository is for
tracking textual diffs and not for serving as a backup, it should be an
acceptable tool however. In my opinion, to be truly useful, it would
need to also automatically commit changes during package installation,
upgrade, and removal. (To be incredibly useful, it would 3-way merge
changes. That, I think, is a fantasy at this time.)
>
> You are much better off to keep /usr/src/rootstuff/.git (and
> working tree files are /usr/src/rootstuff/etc/hosts and
> friends), have a build procedure (read: Makefile) there, and
> version control that source directory. I usually have 'install'
> and 'diff' target in that Makefile, so that I can do this:
>
> $ cd /usr/src/rootstuff
> $ make diff ;# to see if somebody edited any targets by hand
> $ edit etc/hosts
> $ git diff ;# to see the source change
> $ make diff ;# to see the change I am going to install
> $ su
> # make install; exit
> $ git commit -a -m 'Add a new host.'
>
> Being able to run "diff" before actually doing it is very handy
> and useful safety/sanity measure.
>
> Obviously, /usr/src/rootstuff/ should be mode 0770 or stricter,
> owned by the operator group; it would contain some sensitive
> information.
If you're doing this, especially if you're doing this on multiple
machines, creating a package is probably a worthwhile thing to
contemplate as well.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 5:29 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com>
On Wed, Jan 18, 2006 at 02:47:00PM +0100, Alex Riesen wrote:
>For reasons unknown, cygwin decided to use our sockaddr_storage.
>As it is redefined to sockaddr_in it'd cause compilation errors in
>cygwin headers. Fixed by first patch, which uses a more git-related
>name (can we claim rights for the symbol, being first to use it? :-)
>
>For the other, probably unrelated, reasons, they decided to leave
>declarations of DT_* macros in dirent.h without providing dirent->d_type.
>This is what NO_DTYPE in the 0002-patch is all about.
"They" probably would like to hear about any irregularities that are found.
"They" probably don't like it when people treat an open source project as
if it was some unresponsive proprietary enterprise which does not listen
to or accept patches.
>And on top of that, they removed dirent->d_ino (or probably replaced it
>by __ino32, if at all). BTW, can we somehow avoid using d_ino? It is
>referenced only in fsck-objects.c Anyway, to workaround this I put
>
>COMPAT_CFLAGS += -Dd_ino=__ino32
>
>It helps, but surely is not the solution.
I don't see how it could help since __ino32 is not actually filled in
with anything. In fact, I'll rename the field to __invalid_ino32 to
make that clear.
cgf
(cygwin project lead)
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Christopher Faylor @ 2006-01-19 5:20 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Alex Riesen, git
In-Reply-To: <7vmzhtqakl.fsf@assigned-by-dhcp.cox.net>
On Wed, Jan 18, 2006 at 05:18:50PM -0800, Junio C Hamano wrote:
>Alex Riesen <raa.lkml@gmail.com> writes:
>
>> this is probable unsafe too: not all systems export inodes
>> (the recent cygwin breakage comes to mind).
>
>Hmph. I thought that breakage was about struct dirent, not what
>we read from struct stat; d_ino is XSI extension so that may
>have been the reason cygwin folks removed it, but st_ino is in
>BASE --- did they remove that as well?
No, we didn't. We (i.e., I) removed d_ino in cygwin because it couldn't
be reliably calculated without slowing things down. st_ino will always
be there.
cgf
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Christopher Faylor @ 2006-01-19 5:18 UTC (permalink / raw)
To: Junio C Hamano, Alex Riesen, git
In-Reply-To: <7vvewi2typ.fsf@assigned-by-dhcp.cox.net>
On Tue, Jan 17, 2006 at 05:41:34PM -0800, Junio C Hamano wrote:
>Alex Riesen <raa.lkml@gmail.com> writes:
>>Probably another one windows quirk, or just the moon phases, but I have
>>to make damn sure it sleeps long enough.
>
>IIRC, DOS file timestamps have 2 seconds granularity, so sleeping for
>one second might not be enough to begin with. Also I run my cygwin
>test on sufficiently slow machine, so that may explain why I have not
>notice the problem ;-).
Cygwin really does sleep a second if you tell it to, but on FAT
filesystems, you're right, the granularity something like 2 seconds.
cgf
^ permalink raw reply
* Re: /etc in git?
From: Junio C Hamano @ 2006-01-19 5:05 UTC (permalink / raw)
To: Adam Hunt; +Cc: git
In-Reply-To: <b476569a0601182040w581b72b7xbb99845da4085646@mail.gmail.com>
Adam Hunt <kinema@gmail.com> writes:
> Do you have any more details by chance? Does it work? Does it work
> well? How does one do it?
I personally feel it is a horrible and stupid thing to do, if by
"version control /etc" you mean to have /.git which controls
/etc/hosts and stuff in place. It would work (git does not
refuse to run as root). But being a *source* control system, we
deliberately refuse to store the full permission bits, so if
your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
have to make sure they stay that way after checking things out.
You are much better off to keep /usr/src/rootstuff/.git (and
working tree files are /usr/src/rootstuff/etc/hosts and
friends), have a build procedure (read: Makefile) there, and
version control that source directory. I usually have 'install'
and 'diff' target in that Makefile, so that I can do this:
$ cd /usr/src/rootstuff
$ make diff ;# to see if somebody edited any targets by hand
$ edit etc/hosts
$ git diff ;# to see the source change
$ make diff ;# to see the change I am going to install
$ su
# make install; exit
$ git commit -a -m 'Add a new host.'
Being able to run "diff" before actually doing it is very handy
and useful safety/sanity measure.
Obviously, /usr/src/rootstuff/ should be mode 0770 or stricter,
owned by the operator group; it would contain some sensitive
information.
^ permalink raw reply
* Re: /etc in git?
From: H. Peter Anvin @ 2006-01-19 4:59 UTC (permalink / raw)
To: Adam Hunt; +Cc: git, Junio C Hamano
In-Reply-To: <b476569a0601182040w581b72b7xbb99845da4085646@mail.gmail.com>
Adam Hunt wrote:
> Do you have any more details by chance? Does it work? Does it work
> well? How does one do it?
I've put my home directory dot files into git, and I'm assuming it's
going to be a similar issue for /etc. I've found git to be unusually
suitable for this, for the following reasons:
- git can deal with only managing a handful of files from a large
hierarchy, without an insane performance penalty.
- git only needs one repository directory at the root of the tree, not
in each subdirectory.
The biggest *problem* with git is that it doesn't handle files which
need to have their permissions maintained.
-hpa
^ permalink raw reply
* Re: /etc in git?
From: Adam Hunt @ 2006-01-19 4:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vlkxckf7o.fsf@assigned-by-dhcp.cox.net>
Do you have any more details by chance? Does it work? Does it work
well? How does one do it?
--adam
On 1/18/06, Junio C Hamano <junkio@cox.net> wrote:
> Adam Hunt <kinema@gmail.com> writes:
>
> > ... Has anyone ever tried to version their /ect with
> > git?
>
> Yes.
>
>
^ permalink raw reply
* Re: /etc in git?
From: Junio C Hamano @ 2006-01-19 4:35 UTC (permalink / raw)
To: Adam Hunt; +Cc: git
In-Reply-To: <b476569a0601181943y6a14e703k1b521a7edb9e2e2@mail.gmail.com>
Adam Hunt <kinema@gmail.com> writes:
> ... Has anyone ever tried to version their /ect with
> git?
Yes.
^ permalink raw reply
* [RFC/PATCH] Revert "check_packed_git_idx(): check integrity of the idx file itself."
From: Junio C Hamano @ 2006-01-19 4:34 UTC (permalink / raw)
To: git; +Cc: romieu, Andrew Morton
Andrew noticed that this format-patch in the linux-2.6
repository runs very very very slowly. I tried it myself and
found it to be 4x slowdown in a repository where I have both
commits still not packed:
$ git format-patch 7c5c220e 7c4d3367
0.99.9m ran this with 20 seconds wallclock on a Duron 850, while
1.1.3 (and the master) took 47 seconds wallclock. Comparing
user time is worse: 10 seconds vs 37 seconds.
It turns out that this is due to the pack idx file integrity
check I added about a month ago (bisect is cool -- thanks
Linus):
commit c5ced64578a82b9d172aceb2f67c6fb9e639f6d9
Author: Junio C Hamano <junkio@cox.net>
Date: Thu Dec 22 22:57:20 2005 -0800
check_packed_git_idx(): check integrity of the idx file itself.
Although pack-check.c had routine to verify the checksum for the
pack index file itself, the core did not check it before using
it.
The potential problem I saw with the core before this fix was
that after mapping the pack idx file and did some sanity
checks, we did not check the checksum we had in the idx file
that made sure the idx file itself is not corrupt. Doing it
everytime turned out to be quite expensive as illustrated by
this problem. With the revert, the same test runs as fast as
0.99.9m used to.
git-fsck-objects should catch it if idx file is corrupt, so this
is removing suspender while we still have belt.
So I am going to propose reverting this "safety measure";
objections?
-- >8 --
Date: Wed Jan 18 20:26:14 2006 -0800
This reverts c5ced64578a82b9d172aceb2f67c6fb9e639f6d9 commit.
It turns out that doing this check every time we map the idx file
is quite expensive. A corrupt idx file is caught by git-fsck-objects,
so this check is not strictly necessary.
In one unscientific test, 0.99.9m spent 10 seconds usertime for
the same task 1.1.3 takes 37 seconds usertime. Reverting this gives
us the performance of 0.99.9 back.
---
sha1_file.c | 16 +---------------
1 files changed, 1 insertions(+), 15 deletions(-)
a53f669407a76d01c7271124d06366a2dbd5a12d
diff --git a/sha1_file.c b/sha1_file.c
index 8bebbb2..20f6419 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -349,16 +349,12 @@ struct packed_git *packed_git;
static int check_packed_git_idx(const char *path, unsigned long *idx_size_,
void **idx_map_)
{
- SHA_CTX ctx;
- unsigned char sha1[20];
void *idx_map;
unsigned int *index;
unsigned long idx_size;
int nr, i;
- int fd;
+ int fd = open(path, O_RDONLY);
struct stat st;
-
- fd = open(path, O_RDONLY);
if (fd < 0)
return -1;
if (fstat(fd, &st)) {
@@ -396,16 +392,6 @@ static int check_packed_git_idx(const ch
if (idx_size != 4*256 + nr * 24 + 20 + 20)
return error("wrong index file size");
- /*
- * File checksum.
- */
- SHA1_Init(&ctx);
- SHA1_Update(&ctx, idx_map, idx_size-20);
- SHA1_Final(sha1, &ctx);
-
- if (memcmp(sha1, idx_map + idx_size - 20, 20))
- return error("index checksum mismatch");
-
return 0;
}
--
1.1.3.gce7b
^ permalink raw reply related
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