* Re: Cogito: cg-clone doesn't like packed tag objects
From: Josef Weidendorfer @ 2005-09-27 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <20050927094029.GA30889@pasky.or.cz>
On Tuesday 27 September 2005 11:40, Petr Baudis wrote:
> Another thing I proposed back then (I think it was in June) was having
> the refs/tags directory further divised based on heads, so all tags for
> head A would be in refs/tags/A/, etc. I didn't pursue this idea now
> because it seemed that there would be way too many duplicate stuff in
> refs/tags/ since most tags are likely to be shared across heads, but
> perhaps it is the beast and cleanest solution after all.
The problem here is that currently there are no global, public branches.
And you should not mix private heads in refs/heads with global tags.
Perhaps interpret tag objects as global branch names, similar to
the "mixture" in .git/refs ?
Josef
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Petr Baudis @ 2005-09-27 10:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vr7bba3lo.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Sep 27, 2005 at 12:03:47AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> - if the merge is not to happen in the current branch, then
> use a temporary index file and a temporary working directory
> to do the merge -- when manual conflict resolution is needed,
> ask the user to go to that temporary working directory and
> resolve conflicts there and make commits there. The
> temporary working directory is actually cheap because we do
> not have to checkout all the paths -- only the paths involved
> in the merge.
By the way, this is how Cogito did merging for some (rather short) time
period (actually, there's perhaps still some remnant of this, I think
Cogito still by default ignores ,,merge* which was the subdirectory
where the merge happenned). I removed it because IIRC the people weren't
eventually all that excited about it after all and Linus changed his
mind too.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: shared GIT repos
From: Sergey Vlasov @ 2005-09-27 9:59 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Junio C Hamano, git
In-Reply-To: <20050927084513.GU31276@kiste.smurf.noris.de>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Tue, 27 Sep 2005 10:45:13 +0200 Matthias Urlichs wrote:
> > If one has commit privileges, then one can already do enough
> > harm to the project without being able to remove objects nor
> > updating a ref with non-fast-forward ref.
>
> But in that case it's traceable what happened and whodunit.
Don't forget that the user who has rights to invoke git-receive-pack
can set the "author" and "committer" fields in his commits to anything
he wants - unless you check these fields in hooks/update.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix default pull not to do an unintended Octopus.
From: Josef Weidendorfer @ 2005-09-27 9:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vu0g72c4y.fsf_-_@assigned-by-dhcp.cox.net>
On Tuesday 27 September 2005 09:38, Junio C Hamano wrote:
> I think it could be modified without too much pain to take
> "which heads to use for merge by default" information from
> separate "Merge: " line as Jon proposed, if enough people like
> that idea better. Personally I do not think it would make much
> practical difference from the end users' point of view, but I've
> been proven wrong more often than not in the past, so...
Hmm...
What is the "intuitive" thing a user would expect when looking at
a remotes file? It looks like including lists of default heads which
are used for git commands when no further head is specified, i.e.
which are automatically appended to the command line.
E.g. with .git/remotes/remoterep looking like
URL: ...
Pull: local1:remote1 local2:remote2
Push: local3:remote3 local4:remote4
a
git push remoterep
expands to (AFAIK)
git push remoterep local3:remote3 local4:remote4
So for
git pull remoterep
the expected command seems to be
git pull local1:remote1 local2:remote2
and of course this does an octopus merge at the end.
It may be a strange thing to do, but if the user does *not* want to do
octopus merges, he probably only will give one default head in the Pull
line of the remotes file.
So I would not change the current behavior.
It seems better to me to support an additional "Fetch:" line.
IMHO, a "Merge:" lines does not make sense, as "git merge" has
nothing to do with remote repositories at all [I just looked up
the man page of git-merge, and confusingly it talks about "remotes",
which are in fact local heads to be merged].
> As Pasky said in another thread, git-fetch is not the most
> elegantly written script on earth, and it is not my favorite
> script either -- it needs to do complex things, like interacting
> with the later git-pull stage.
Like Pasky, I am not really comfortable with this remotes stuff.
AFAIK, it was introduced to shorten some command line by providing defaults
(to be used by the "GIT core porcelain"). But I still have to provide the
remote shortcut on the command line.
As Cogito does, I expect the porcelain to store the mapping of a
local head to a remote head, automatically using the right remote
repository.
I want to type "git fetch maint" to get the maintanance branch of
git, and not specify an additionally introduced arbitrary short name
for the remote git repo (which is used quite less often than my
head names: heads appear in gitk, I switch among heads...).
And using the same name for a remote shortcut and a local head can
confuse people.
So IMHO default actions should be stored for branches, not for shortcuts
of remote positions. The branches stuff matches this better, as one
file in branches/ corresponds exactly to one head with the same name,
and specifies the attributes "remote repository" and "remote head".
This also shortens command lines much better then the remotes stuff,
as you implicity specify a default head: The one you are on.
Perhaps we should have extended the branches file to allow different
remote reps and heads depending on the command (fetch/pull/merge/push).
A "URL:" is not needed, as you probably like to have different repos for pull
and push. And in contrast to the remotes stuff above, a "Merge:" line makes
quite sense here: When on "mybranch", a merge should default to merging
the heads specified on the Merge line in branches/mybranch.
When cloning a remote head, Cogito creates a local "origin" head and
corresponding mapping in branches/origin. Afterwards, it automatically
generates a new local branch "master", which branches of at the
origin. Further "cg-updates" (=git fetch+merge) fetch origin, and merge
origin into master.
I assume that this currently is hardcoded in scripts?
Shouldn't there be created a branches/master, specifying that a default
merge should happen with "origin"? This way, an "cg-update" would look
into "branches/master" on the "Merge:" line. It sees that "origin" is
bound to a remote head, and thus, does a fetch before merging.
Opinions?
Josef
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Petr Baudis @ 2005-09-27 9:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List
In-Reply-To: <1127765852.5735.36.camel@cashmere.sps.mot.com>
Dear diary, on Mon, Sep 26, 2005 at 10:17:32PM CEST, I got a letter
where Jon Loeliger <jdl@freescale.com> told me that...
> Hmmm... Would it make sense to introduce something
> like this instead:
>
> # When fetching, get bits from here:
> URL: http://...../git.git
> # When fetching, grab and map like this:
> Fetch: master:origin maint:maint +pu:pu
> # When merging, merge origin, maint and pu into master
> Merge: master origin maint pu
>
> With the intent that the "Fetch:" line effectively
> limits the fetching operation to git-fetch, and doesn't
> specify how to merge. Then, the "Merge:" line specifies
> how to do the git-merge bits. If you didn't want to
> merge in the maint and pu bits, this would have been
> the line instead:
>
> # Merge into master the just the origin bits
> Merge: master origin
>
> If you want the dual-step fetch+merge, the leave the "Pull:"
> line as originally written:
>
> # Fetch and merge
> Pull: master:origin maint:maint +pu:pu
>
> Syntax can be argued, of course. My point being to
> introduce another line to the remote file that
> distinguishes the default behavior for each step
> along the way.
Yes, this is basically the idea behind my "Default" line, but arguably
nicer and more flexible. I fully agree with Junio that pulling should
merge to your current branch, but I like your idea otherwise.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-09-27 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tom Prince, git
In-Reply-To: <7v4q875bbj.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Sep 27, 2005 at 07:28:16AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Tom Prince <tom.prince@ualberta.net> writes:
>
> > Junio C Hamano <junkio@cox.net> writes:
> >
> >> Now you completely lost me. I really do not understand what you
> >> mean by tags caching and re-slurping.
> >
> > I think Petr is interested in the case where the user hasn't asked for a
> > particular tag. He wants to automatically grab all the tags in a repository,
> > or at least those that refer to a branch being downloaded.
>
> Ah, _automatically_ was the key.
>
> If all you had were tags and there were no branches (the "I
> could have done without maint branch"), that kind of automatic
> grabbing would not work well anyway.
I don't think that's a realistic situation. IMHO it is a reasonable
requirement for Cogito fetch that you are primarily fetching a _head_.
Then, you also grab tags which are meaningful for that head - that's
what I want to do. If you want to also specifically grab some extra
tags, you should be able to tell cg-fetch about that too (cg-fetch -t
tagname) or something. Being able to do this, I'm inclined to agree that
we shouldn't grab even trees and blobs.
> I personally feel that is a lost cause. The user can run 'git
> ls-remote' himself to find out if there are new tags on the remote
> side and ask for them if needed.
Yes, that's perhaps a fine solution for the core GIT plumbing, but in
Cogito, I _really_ want to have this working automagically.
> Also, I feel names under refs/ is local to the repository, but
> if the tags are automatically grabbed, I presume they are stored
> directly under the same name in refs/tags as the remote side has
> them?
Yes. And I certainly don't say that what Cogito does now is perfect, not
even that it's very good. But we (well, rather the users) certainly _do_
need some kind of automatic tags fetching - that's something that has to
Just Work (tm).
As I already said in the past (without much feedback, unfortunately), we
certainly need to distinguish between private tags (specific for given
repository) and public tags (should be propagated by fetching).
Another thing I proposed back then (I think it was in June) was having
the refs/tags directory further divised based on heads, so all tags for
head A would be in refs/tags/A/, etc. I didn't pursue this idea now
because it seemed that there would be way too many duplicate stuff in
refs/tags/ since most tags are likely to be shared across heads, but
perhaps it is the beast and cleanest solution after all.
Dear diary, on Tue, Sep 27, 2005 at 12:37:48AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I think there should be a way to say "I do not care if this
> repository does not have all the history back to root -- as long
> as I can operate on reasonably recent commits, do not complain
> about missing objects" to fsck-objects and various fetch
> engines. We can cauterize commit history chain using the grafts
> file so that 'git log', 'git whatchanged', and 'gitk' would stop
> somewhere. Commit walkers can help you, albeit somewhat
> differently, if you do not give -a flag to them.
Well, this wasn't something I had on my mind in this thread, but it is
actually what I want to do too (I have such a loooong TODO list). Sure,
you can workaround the problem with grafts, but I think that this hack
should be really used only in specific cases (like grafting big history
pack after importing the project to GIT, making it kind of optional
"addon", which is actually very nice). In the general case, I would much
more like if you could say "I want only commits to the depth of 5" or
even CVS-like "I want only the HEAD commit" (actually, I received some
patches to make Cogito support this, but I didn't yet get to have a look
at them). This shifts the policy decision from the repository owner to
the user, and makes it contignuous instead of fragmented to the points
when you have grafts.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: shared GIT repos
From: Matthias Urlichs @ 2005-09-27 8:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0g70yqg.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
Junio C Hamano:
> Do you want to guard the repository from malicious users? Or is
> it enough to guard a casual/careless user from making mistakes?
>
Well, s/malicious users/somebody who wants to cover up an ugly mistake/
would be more accurate.
What I am doing: I'm writing a system management frontend which allows
people to install version-controlled stuff (like, the configuration for
a backup server, or Yet Another PHPBB Installation) on servers -- without
even having a login there.
Some of these contain login scripts that might need root privileges or
similar (like, "restart Apache"). I want people to be unable to simply
remove the commit that included the "rm -rf /" command, move the ref
back, upload a new version, and pretend that nothing happened *la la la*.
> If one has commit privileges, then one can already do enough
> harm to the project without being able to remove objects nor
> updating a ref with non-fast-forward ref.
But in that case it's traceable what happened and whodunit.
> I think most of the pieces are already there and you only need to
> assemble them and write a howto ;-).
> [ list ]
OK, thanks, that helps. I'll write something up.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
When angry, count four; when very angry, swear.
^ permalink raw reply
* Re: git-daemon: path validation, export all option
From: Anton Altaparmakov @ 2005-09-27 8:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: H. Peter Anvin, git
In-Reply-To: <7vslvr6t1u.fsf@assigned-by-dhcp.cox.net>
On Mon, 2005-09-26 at 21:19 -0700, Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
> > A first attempt to make git-daemon a bit more suitable for kernel.org
> > use: it allows the user to specify a whitelist of directories, rejects
> > paths which have . or .. in them (to avoid bypassing the whitelist), and
> > allows for an --export-all option.
> >
> > Signed-off-by: H. Peter Anvin <hpa@zytor.com>
>
> I understand the motivation behind --export-all and directory
> whitelist and these changes look good. Thanks.
>
> > + if ( ok_paths && *ok_paths ) {
> > + int ok = 0;
> > +...
> > + }
> > +
> > + return 1; /* Path acceptable */
> > +}
>
> A microNit. You could lose 'int ok' and return 1 directly where
> you assign 1 to it and break.
>
> > - chdir(".git");
>
> I am unsure about this removal of "minor convenience feature".
> Although I do not think git-daemon is widely used on the field,
> this change breaks existing setup if there is any.
Please drop this one line change. It certainly breaks my personal
setup. And all git tools are happy with being given the "master"
directory or the "master/.git" so there is no reason for git-daemon not
to accept that, too.
If hpa really can't live with the chdir, maybe we could add a
"--strict-git-paths" option or something that will not do the chdir? It
would be only a few lines of code in git-daemon to parse the option and
then the chdir would become
if (!strict_git_paths)
chdir(".git");
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: More Porcelains?
From: Catalin Marinas @ 2005-09-27 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7v64sn8hml.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> How many of you are working on your own Porcelains, announced or
> unannounced? I know about Cogito and StGIT ;-). In a distant
> past I have heard of something called JIT but I think it is now
> defunct. Matthias Urlichs said he is doing something with
> Python. Anybody else?
I just found gipy on sf.net - http://sourceforge.net/projects/gipy.
There are no files uploaded yet but hopefully I can soon 'steal' some
code for StGIT ;-)
--
Catalin
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-27 7:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050926212536.GF26340@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> If it's NOT a commit, well, that's a question. On the assumption that
> it won't be a great deal of data and it's likely to be assumed that we
> have it, I would be inclined to fetching it, but I don't feel strongly
> about it.
v2.6.11 tag is not a commit but presumably it would slurp in a
lot of data.
^ permalink raw reply
* [PATCH] Fix default pull not to do an unintended Octopus.
From: Junio C Hamano @ 2005-09-27 7:38 UTC (permalink / raw)
To: git; +Cc: Jon Loeliger, Petr Baudis
In-Reply-To: <7vr7bba3lo.fsf@assigned-by-dhcp.cox.net>
This is what I ended up doing Sunday night before the discussion
started, and what I still have in the proposed updates branch.
It implements the 'when puling using a shorthand without
explicitly telling which refs to pull, only use the first ref
found from Pull: lines for merging -- creating Octopus using all
default refs is not useful 99.99% of the time' behaviour I
outlined yesterday.
I think it could be modified without too much pain to take
"which heads to use for merge by default" information from
separate "Merge: " line as Jon proposed, if enough people like
that idea better. Personally I do not think it would make much
practical difference from the end users' point of view, but I've
been proven wrong more often than not in the past, so...
As Pasky said in another thread, git-fetch is not the most
elegantly written script on earth, and it is not my favorite
script either -- it needs to do complex things, like interacting
with the later git-pull stage.
------------
The refspecs specified in the .git/remotes/<remote> on the "Pull: "
lines are for fetching multiple heads in one go, but most of the time
making an Octopus out of them is not what is wanted. Make git-fetch
leave the marker in .git/FETCH_HEAD file so that later stages can
tell which heads are for merging and which are not.
Tom Prince made me realize how stupid the original behaviour was.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-fetch.sh | 32 ++++++++++++++++++++++++++++----
git-fmt-merge-msg.perl | 4 +++-
git-parse-remote.sh | 11 +++++++++--
git-pull.sh | 4 +++-
4 files changed, 43 insertions(+), 8 deletions(-)
44dbc712fe3dd045550123e1cc689c41482c62e5
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -54,6 +54,10 @@ append_fetch_head () {
remote_name_="$3"
remote_nick_="$4"
local_name_="$5"
+ case "$6" in
+ t) not_for_merge_='not-for-merge' ;;
+ '') not_for_merge_= ;;
+ esac
# remote-nick is the URL given on the command line (or a shorthand)
# remote-name is the $GIT_DIR relative refs/ path we computed
@@ -78,10 +82,11 @@ append_fetch_head () {
if git-cat-file commit "$head_" >/dev/null 2>&1
then
headc_=$(git-rev-parse --verify "$head_^0") || exit
- echo "$headc_ $note_" >>$GIT_DIR/FETCH_HEAD
+ echo "$headc_ $not_for_merge_ $note_" >>$GIT_DIR/FETCH_HEAD
echo >&2 "* committish: $head_"
echo >&2 " $note_"
else
+ echo "$head_ not-for-merge $note_" >>$GIT_DIR/FETCH_HEAD
echo >&2 "* non-commit: $head_"
echo >&2 " $note_"
fi
@@ -157,6 +162,13 @@ do
# These are relative path from $GIT_DIR, typically starting at refs/
# but may be HEAD
+ if expr "$ref" : '\.' >/dev/null
+ then
+ not_for_merge=t
+ ref=$(expr "$ref" : '\.\(.*\)')
+ else
+ not_for_merge=
+ fi
if expr "$ref" : '\+' >/dev/null
then
single_force=t
@@ -216,7 +228,8 @@ do
continue ;;
esac
- append_fetch_head "$head" "$remote" "$remote_name" "$remote_nick" "$local_name"
+ append_fetch_head "$head" "$remote" \
+ "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done
@@ -241,16 +254,27 @@ http://* | https://* | rsync://* )
case "$ref" in
+$remote_name:*)
single_force=t
+ not_for_merge=
+ found="$ref"
+ break ;;
+ .+$remote_name:*)
+ single_force=t
+ not_for_merge=t
+ found="$ref"
+ break ;;
+ .$remote_name:*)
+ not_for_merge=t
found="$ref"
break ;;
$remote_name:*)
+ not_for_merge=
found="$ref"
break ;;
esac
done
-
local_name=$(expr "$found" : '[^:]*:\(.*\)')
- append_fetch_head "$sha1" "$remote" "$remote_name" "$remote_nick" "$local_name"
+ append_fetch_head "$sha1" "$remote" \
+ "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
done || exit
;;
esac
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -31,6 +31,8 @@ while (<>) {
my ($bname, $tname, $gname, $src);
chomp;
s/^[0-9a-f]* //;
+ next if (/^not-for-merge/);
+ s/^ //;
if (s/ of (.*)$//) {
$src = $1;
} else {
@@ -86,7 +88,7 @@ for my $src (@src) {
$src{$src}{GENERIC});
my $this = join(', ', @this);
if ($src ne '.') {
- $this .= " from $src";
+ $this .= " of $src";
}
push @msg, $this;
}
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -65,8 +65,11 @@ get_remote_default_refs_for_push () {
esac
}
-# Subroutine to canonicalize remote:local notation
+# Subroutine to canonicalize remote:local notation.
canon_refs_list_for_fetch () {
+ # Leave only the first one alone; add prefix . to the rest
+ # to prevent the secondary branches to be merged by default.
+ dot_prefix=
for ref
do
force=
@@ -91,7 +94,8 @@ canon_refs_list_for_fetch () {
heads/* | tags/* ) local="refs/$local" ;;
*) local="refs/heads/$local" ;;
esac
- echo "${force}${remote}:${local}"
+ echo "${dot_prefix}${force}${remote}:${local}"
+ dot_prefix=.
done
}
@@ -107,6 +111,9 @@ get_remote_default_refs_for_fetch () {
echo "refs/heads/${remote_branch}:refs/heads/$1"
;;
remotes)
+ # This prefixes the second and later default refspecs
+ # with a '.', to signal git-fetch to mark them
+ # not-for-merge.
canon_refs_list_for_fetch $(sed -ne '/^Pull: */{
s///p
}' "$GIT_DIR/remotes/$1")
diff --git a/git-pull.sh b/git-pull.sh
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -24,7 +24,9 @@ then
die "You need to first update your working tree."
fi
-merge_head=$(sed -e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | tr '\012' ' ')
+merge_head=$(sed -e '/ not-for-merge /d' \
+ -e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
+ tr '\012' ' ')
case "$merge_head" in
'')
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Ryan Anderson @ 2005-09-27 7:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20050926212536.GF26340@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
Petr Baudis wrote:
> So the strategy I'm thinking of now is to manually (I think no GIT tool
> can do that for me) dereference the possible tag chain until I end up at
> some non-tag object. Now, if it is a commit and I don't have it yet, it
> means that it is not interesting to me because it does not belong to a
> branch I'm following, so I will just ignore the tag (won't download
> anything else and won't record it in the refs/tags directory).
git-rev-parse $tagname^0
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: shared GIT repos
From: Junio C Hamano @ 2005-09-27 7:13 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.09.27.06.35.35.834134@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> Speaking of which -- is anybody working on that one?
>
> I find myself in need of a multiuser shared repository that cannot
> be corrupted (i.e. I want to prevent the users from removing objects,
> and replacing a ref with something that is not a child of the sha1 that's
> already there should also be prevented).
Do you want to guard the repository from malicious users? Or is
it enough to guard a casual/careless user from making mistakes?
If one has commit privileges, then one can already do enough
harm to the project without being able to remove objects nor
updating a ref with non-fast-forward ref. So let's assume for
now that malicious users are not something we worry about. In
that case, "working on" might be too scary a word. I think most
of the pieces are already there and you only need to assemble
them and write a howto ;-).
- Place the users that has write access to the repository in
the same Unix group, and have the repository owned by that
group;
- Give the users ssh access, perhaps with authorized_keys set
up to only allow running git-receive-pack and nothing else
(like normal shell access);
- Set up hooks/update to make sure the ref updates are fast
forward. Additionally, you could set up a mapping that says
which user can/cannot update which refs if you wanted to.
-jc
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Sven Verdoolaege @ 2005-09-27 6:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20050926212536.GF26340@pasky.or.cz>
On Mon, Sep 26, 2005 at 11:25:36PM +0200, Petr Baudis wrote:
> So the strategy I'm thinking of now is to manually (I think no GIT tool
> can do that for me) dereference the possible tag chain until I end up at
> some non-tag object.
If it _is_ a commit, you could use
git-rev-list --max-count=1 $tag
It won't help you though if it isn't.
skimo
^ permalink raw reply
* hared GIT repos (was Re: rsync deprecated but promoted?)
From: Matthias Urlichs @ 2005-09-27 6:35 UTC (permalink / raw)
To: git
In-Reply-To: <20050926133204.GB21019@pasky.or.cz>
Hi, Petr Baudis wrote:
> The thing is, rsync is bad - it will happily put
> duplicate, redundant, and especially unwanted data to your repository,
> especially when the shared GIT repositories happen.
Speaking of which -- is anybody working on that one?
I find myself in need of a multiuser shared repository that cannot
be corrupted (i.e. I want to prevent the users from removing objects,
and replacing a ref with something that is not a child of the sha1 that's
already there should also be prevented).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Beware of bugs in the above code; I have only proved it correct, not tried it.
-- Donald Knuth
^ permalink raw reply
* Re: [PATCH 3/3] Return CURL error message when object transfer fails
From: Junio C Hamano @ 2005-09-27 6:13 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <7v3bnr3vo5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> If that is the case, I'll take your patch verbatim. Thanks.
Oops. I spoke too fast. That "sounds like a good idea" of mine
was a response to your:
> It might be better to extend this to all places that curl_easy_perform
> is called, rather than just in fetch_object.
... so the patch still needed some fixups. It had minor
dependencies on the previous patches in the series as well, so I
tried to fix them up myself.
Could you take a look at it and see if the following is good
enough, please?
------------
Subject: [PATCH] Return CURL error message when object transfer fails
From: Nick Hengeveld <nickh@reactrix.com>
Date: 1127757131 -0700
Return CURL error message when object transfer fails
[jc: added similar curl_errorstr errors to places where we
use curl_easy_perform() to run fetch that _must_ succeed.]
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
http-fetch.c | 24 ++++++++++++++++--------
1 files changed, 16 insertions(+), 8 deletions(-)
4f1da6322aa5d11091005b23716bcc3c65151a32
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -15,6 +15,7 @@
static CURL *curl;
static struct curl_slist *no_pragma_header;
+static char curl_errorstr[CURL_ERROR_SIZE];
static char *initial_base;
@@ -112,10 +113,12 @@ static int fetch_index(struct alt_base *
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite);
curl_easy_setopt(curl, CURLOPT_URL, url);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, no_pragma_header);
+ curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_errorstr);
if (curl_easy_perform(curl)) {
fclose(indexfile);
- return error("Unable to get pack index %s", url);
+ return error("Unable to get pack index %s\n%s", url,
+ curl_errorstr);
}
fclose(indexfile);
@@ -264,10 +267,10 @@ static int fetch_indices(struct alt_base
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(curl, CURLOPT_URL, url);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, NULL);
+ curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_errorstr);
- if (curl_easy_perform(curl)) {
- return -1;
- }
+ if (curl_easy_perform(curl))
+ return error("%s", curl_errorstr);
while (i < buffer.posn) {
switch (data[i]) {
@@ -327,10 +330,12 @@ static int fetch_pack(struct alt_base *r
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite);
curl_easy_setopt(curl, CURLOPT_URL, url);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, no_pragma_header);
-
+ curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_errorstr);
+
if (curl_easy_perform(curl)) {
fclose(packfile);
- return error("Unable to get pack file %s", url);
+ return error("Unable to get pack file %s\n%s", url,
+ curl_errorstr);
}
fclose(packfile);
@@ -373,6 +378,7 @@ int fetch_object(struct alt_base *repo,
curl_easy_setopt(curl, CURLOPT_FILE, NULL);
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite_sha1_file);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, no_pragma_header);
+ curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_errorstr);
url = xmalloc(strlen(repo->base) + 50);
strcpy(url, repo->base);
@@ -388,7 +394,7 @@ int fetch_object(struct alt_base *repo,
if (curl_easy_perform(curl)) {
unlink(filename);
- return -1;
+ return error("%s", curl_errorstr);
}
fchmod(local, 0444);
@@ -453,6 +459,7 @@ int fetch_ref(char *ref, unsigned char *
curl_easy_setopt(curl, CURLOPT_FILE, &buffer);
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, NULL);
+ curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, curl_errorstr);
url = xmalloc(strlen(base) + 6 + strlen(ref));
strcpy(url, base);
@@ -464,7 +471,8 @@ int fetch_ref(char *ref, unsigned char *
curl_easy_setopt(curl, CURLOPT_URL, url);
if (curl_easy_perform(curl))
- return error("Couldn't get %s for %s\n", url, ref);
+ return error("Couldn't get %s for %s\n%s",
+ url, ref, curl_errorstr);
hex[40] = '\0';
get_sha1_hex(hex, sha1);
^ permalink raw reply
* Re: More Porcelains?
From: Daniel Barkalow @ 2005-09-27 6:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7v64sn8hml.fsf_-_@assigned-by-dhcp.cox.net>
On Mon, 26 Sep 2005, Junio C Hamano wrote:
> How many of you are working on your own Porcelains, announced or
> unannounced?
I don't have a porcelain, but I organize my working trees/repository in a
non-standard way, using an additional script (which creates a new working
tree linked to an existing repository).
I've also got a set of scripts for splitting up a patch into a series,
which I've still not gotten around to cleaning up and submitting.
For the way I structure my working trees, it would be really helpful if
all of the miscellaneous things that should stay with a repository (such
as remotes) were in a single subdirectory of .git, so that I could just
have a third symlink and have it all work, rather than needing a bunch of
additional links.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 3/3] Return CURL error message when object transfer fails
From: Junio C Hamano @ 2005-09-27 5:51 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050927001241.GB15615@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> I don't see any indication that CURLOPT_ERRORBUFFER is a new feature.
> The curl_easy_strerror() function is new as of 7.12.0 which is why
> I elected to use the CURLOPT_ERRORBUFFER option instead.
If that is the case, I'll take your patch verbatim. Thanks.
I just needed to get the feel that you did things that way,
knowing what to and what not to worry about; I am no cURL
expert.
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Junio C Hamano @ 2005-09-27 5:46 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050927000931.GA15615@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> How about using mkstemp on the prev file to keep multiple instances
> from stepping on each other? Since O_CREAT | O_EXCL is used to
> open the tmpfile, only one instance will be able to succeed and
> continue.
I think (O_CREAT|O_EXCL) in your code can be easily defeated by
this sequence:
one two
unlink prevfile
rename tmpfile, prevfile
unlink tmpfile
local = open tmpfile
unlink prevfile
rename tmpfile, prevfile
unlink tmpfile
local = open tmpfile
prevlocal = open prevfile
write local
copyfile prevlocal, local
write local
???
Not that I think the multiple instances should be prevented at
this low level --- if they stomp on each other at this level, it
is very likely the they are doing duplicated work on the network
side as well, and should be prevented from doing so at much
higher level than this, I think. That's why I said I do not
mind BKL upfront in git-fetch.sh.
> That's an annoying case, all right... Would it be worth including a
> full retry if a partial failed the SHA1 check?
Probably not. Just failing loudly and asking the upper layer to
retry would be fine, I think.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-27 5:28 UTC (permalink / raw)
To: Tom Prince; +Cc: git, Petr Baudis
In-Reply-To: <8764snyufn.fsf@ualberta.net>
Tom Prince <tom.prince@ualberta.net> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Now you completely lost me. I really do not understand what you
>> mean by tags caching and re-slurping.
>
> I think Petr is interested in the case where the user hasn't asked for a
> particular tag. He wants to automatically grab all the tags in a repository,
> or at least those that refer to a branch being downloaded.
Ah, _automatically_ was the key.
If all you had were tags and there were no branches (the "I
could have done without maint branch"), that kind of automatic
grabbing would not work well anyway. I personally feel that is
a lost cause. The user can run 'git ls-remote' himself to find
out if there are new tags on the remote side and ask for them if
needed.
Also, I feel names under refs/ is local to the repository, but
if the tags are automatically grabbed, I presume they are stored
directly under the same name in refs/tags as the remote side has
them?
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Tom Prince @ 2005-09-27 5:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vr7bb5d8w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Yes - so you can't save the tag objects either, but then
>> you'll re-slurp them again and again, which is kind of
>> silly. Alternatively, you could actually make git-fsck-object
>> silent about the case when an unreachable (not referenced in
>> refs/) tag object references a non-existing object - perhaps
>> unless --strict is passed to it. If you think the rest of my
>> logic is ok, I think this change to facilitate this "tags
>> caching" is not unreasonable.
>
> Now you completely lost me. I really do not understand what you
> mean by tags caching and re-slurping.
>
I think Petr is interested in the case where the user hasn't asked for a
particular tag. He wants to automatically grab all the tags in a repository,
or at least those that refer to a branch being downloaded.
Of course, if somebody asks for a specific tag, then everything necessary
should be downloaded. Somebody is fetching your maint branch, Petr want to
automatically download all the tags v0.99.7[a-d], without the user specifying
them explicitly. Or more complex, somebody is tracking your master but NOT
maint. Then Petr wants to download tags v0.99.[0-9] but not v0.99.7[a-d].
Tom
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-27 4:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050926222944.GG26340@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Yes - so you can't save the tag objects either, but then
> you'll re-slurp them again and again, which is kind of
> silly. Alternatively, you could actually make git-fsck-object
> silent about the case when an unreachable (not referenced in
> refs/) tag object references a non-existing object - perhaps
> unless --strict is passed to it. If you think the rest of my
> logic is ok, I think this change to facilitate this "tags
> caching" is not unreasonable.
Now you completely lost me. I really do not understand what you
mean by tags caching and re-slurping.
If your user _is_ interested in the tag, say v0.99.7d, wouldn't
it make sense to make sure that, after the user fetches the tag,
the user can build v0.99.7d point release as well? What do you
think the reason is when your user says he is interested in
another tag, junio-gpg-pub? Wouldn't it be the most natural
interpretation that he wants to get the blob the tag refers to,
so that he can use it with git-verify-tag? What good does it do
for the user if you get only the tag object and do not get the
blob the tag refers to? Yes, he can say "git cat-file tag
junio-gpg-pub", but that by itself is not that interesting if it
cannot be used to validate the other tags (or itself).
If the users ask for a tag, I think it is easier for them to
understand if you made sure you give them the complete set of
objects that need to support that tag, at least by default.
Giving the user an option to override it to make a sparse,
incomplete, fsck-unclean repository is fine as a spacesaver
option, but I think that should be left for "more advanced
users" who understand the ramification of using the option.
I happen to publish maint branch, but I could have done without.
I can make a temporary branch out of v0.99.7c tag, add fixes to
extend that branch, tag the branch head as v0.99.7d, and delete
the temporary branch without publishing it at all.
The tree needed to build v0.99.7d point release would be only
reachable by fetching that tag (and here, "fetching the tag"
really means "making sure the receiving repository has the tag
object, and all the objects that are reachable from that tag
object"), so "fetching only the tag object and not the object it
refers to" in that case does not make much sense for the end
user. Yes, he can say "git cat-file tag v0.99.7d", but that by
itself is not that interesting if he cannot use it to build that
release.
^ permalink raw reply
* Re: [PATCH] Added an option to cvsimport to specify email domain
From: Alexey Nezhdanov @ 2005-09-27 4:34 UTC (permalink / raw)
To: git; +Cc: David Mansfield
In-Reply-To: <20050914193457.GE2936@pasky.or.cz>
(Re-post. Sorry for any inconvenience.)
On September 14, 2005 23:34 Petr Baudis wrote:
> Dear diary, on Wed, Sep 07, 2005 at 09:18:03PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
>
> > David K?.A?Negedal <davidk@lysator.liu.se> writes:
> > > The authorship info in commits created by git-cvsimport-script
> > > only contains the username of the CVS committer. This patch
> > > adds a flag -e <domain> to git-cvsimport-script that makes it
> > > possible to specify an email domain that is added to all email
> > > addresses in the commit "author" and "committer" fields.
> > >
> > > ---
> > > I have stopped using cvsimport, because cvsps seems to produce bad
> > > output on the repository I'm using it with, but I had already prepared
> > > this patch.
> >
> > Hmph. One reason the original implementation did not do this is
> > because Linus and other people wanted to have a repeatability,
> > so making this an optional thing is good, but if we go this
> > route, I think if it would be nicer to have a --author-map
> > option that lets you feed a list of:
> >
> > <author> ==> "A U Thor <author@author.dom>"
> >
> > mappings, instead of a single -e, which essentially does not add
> > much information to the result.
> >
> > I take that your oob comment indicates that you do not have much
> > incentive/inclination to further hack on this, so I am not
> > asking you to do the above even if you find my suggestion
> > worthwhile.
>
> Various tools use CVSROOT/users to map usernames to realname <email>.
> I actually wanted to send a patch, looked at the cvsimport script and
> got totally scared away (at least for now)... ;-)
git uses cvsps output to determine authorship. Do you think if this problem
should be solved on cvsps side? It should be relatively easy IMHO.
David, can you add another key to output CVSROOT/users mapping result instead
of usernames if available?
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: [PATCH] Parallelize building rpm
From: Junio C Hamano @ 2005-09-27 4:21 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4338B307.7010405@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
Could you also fix COPTS while you are at it, please? I think
it is caleld CFLAGS these days.
> %build
> -make COPTS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
> +make %{_smp_mflags} COPTS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
> prefix=%{_prefix} all %{!?_without_docs: doc}
^ permalink raw reply
* Re: git-daemon: path validation, export all option
From: Junio C Hamano @ 2005-09-27 4:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <4338AACC.1050305@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> A first attempt to make git-daemon a bit more suitable for kernel.org
> use: it allows the user to specify a whitelist of directories, rejects
> paths which have . or .. in them (to avoid bypassing the whitelist), and
> allows for an --export-all option.
>
> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
I understand the motivation behind --export-all and directory
whitelist and these changes look good. Thanks.
> + if ( ok_paths && *ok_paths ) {
> + int ok = 0;
> +...
> + }
> +
> + return 1; /* Path acceptable */
> +}
A microNit. You could lose 'int ok' and return 1 directly where
you assign 1 to it and break.
> - chdir(".git");
I am unsure about this removal of "minor convenience feature".
Although I do not think git-daemon is widely used on the field,
this change breaks existing setup if there is any.
^ 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