* Re: Cogito: cg-clone doesn't like packed tag objects
From: Linus Torvalds @ 2005-09-27 18:04 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Petr Baudis, H. Peter Anvin, Git Mailing List
In-Reply-To: <20050927173445.GC23034@mythryan2.michonline.com>
On Tue, 27 Sep 2005, Ryan Anderson wrote:
>
> $ cat .git/refs/tags/v2.6.13-rc4
> 7eab951de91d95875ba34ec4c599f37e1208db93
> $ git-rev-parse v2.6.13-rc4
> 7eab951de91d95875ba34ec4c599f37e1208db93
> $ git-rev-parse v2.6.13-rc4^0
> 63953523341bcafe5928bf6e99bffd7db94b471e
> $ git-rev-parse 63953523341bcafe5928bf6e99bffd7db94b471e^0
> 63953523341bcafe5928bf6e99bffd7db94b471e
The point being that if you want to test whether you have the thing the
tag _points_ to, you should verify it.
And that's where the "--verify" flag comes in:
[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
v2.6.11^0
0
and if the object the tag points to didn't exist at _all_ in your object
store, you'd have silently gotten
[torvalds@g5 linux]$ git-rev-parse v2.6.11^0 ; echo $?
v2.6.11^0
0
but if you used "--verify", you'd have at least gotten
[torvalds@g5 linux]$ git-rev-parse --verify v2.6.11^0 ; echo $?
fatal: Needed a single revision
1
which is what you want, I thought.
Linus
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Linus Torvalds @ 2005-09-27 17:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Tom Prince, git
In-Reply-To: <7v64sm30dh.fsf@assigned-by-dhcp.cox.net>
On Tue, 27 Sep 2005, Junio C Hamano wrote:
>
> This is a bit hard and needs some thinking to do cleanly,
> because what is in info/refs is what is sent from the publisher
> side over git-native protocol at the beginning of the handshake,
> and it is not easy to add that to git-native protocol cleanly
> and backward-compatibly (I think I know how without breaking
> existing clients, but it is not clean).
Argh.
"git-upload-pack" very much on purpose never sends partial object stores:
it really doesn't want to send a tag-object for you to even _look_ at
unless it also sends all the objects that you are missing that the tag
refers to.
I'd really be much happier with the tag fetching being separate.
For example, making
git fetch --tags <dest>
fetch all tags _and_ the objects that they depend on would seem a _lot_
more appropriate.
The thing is, tags really may be totally private. For example, it makes
sense to fetch tags when you pull an official tree (ie my kernel tree, or
your git tree), but it does NOT make sense for me to fetch tags
(automatically or not) when I pull from a developers tree.
That's why git fetch doesn't get the tags by default. It's WRONG.
But we could certainly make it _easier_ to get tags when you want them.
"git-ls-remote" already helps you, and
git-ls-remote ... | cut -f2 | grep '^refs/tags/'
completes the picture. No protocol changes necessary, just some added
magic to git-fetch.sh.
Actually, here's a simple and stupid patch.
Untested as usual, but hey, how hard can it be?
Linus
----
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,6 +5,7 @@
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+tags=
append=
force=
update_head_ok=
@@ -17,6 +18,9 @@ do
-f|--f|--fo|--for|--forc|--force)
force=t
;;
+ --tags)
+ tags=t
+ ;;
-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
--update-he|--update-hea|--update-head|--update-head-|\
--update-head-o|--update-head-ok)
@@ -151,7 +155,12 @@ case "$update_head_ok" in
;;
esac
-for ref in $(get_remote_refs_for_fetch "$@")
+taglist=
+if [ "$tags" ]; then
+ taglist=$(git-ls-remote "$remote" | awk '/refs\/tags/ { print $2":"$2 }')
+fi
+
+for ref in $(get_remote_refs_for_fetch "$@" $taglist)
do
refs="$refs $ref"
^ permalink raw reply
* [PATCH] Support for more CURL SSL settings via environment variables
From: Nick Hengeveld @ 2005-09-27 17:45 UTC (permalink / raw)
To: git
Added support for additional CURL SSL settings via environment variables.
Client certificate/key files can be specified as well as alternate CA
information.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-fetch.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
8ce3710b0b838d6f4c9813ad3631afced80ce346
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -35,6 +35,10 @@ static int local;
static int zret;
static int curl_ssl_verify;
+static char *ssl_cert;
+static char *ssl_key;
+static char *ssl_capath;
+static char *ssl_cainfo;
struct buffer
{
@@ -512,6 +516,21 @@ int main(int argc, char **argv)
curl_easy_setopt(curl, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
#endif
+ if ((ssl_cert = getenv("GIT_SSL_CERT")) != NULL) {
+ curl_easy_setopt(curl, CURLOPT_SSLCERT, ssl_cert);
+ }
+ if ((ssl_key = getenv("GIT_SSL_KEY")) != NULL) {
+ curl_easy_setopt(curl, CURLOPT_SSLKEY, ssl_key);
+ }
+#if LIBCURL_VERSION_NUM >= 0x070908
+ if ((ssl_capath = getenv("GIT_SSL_CAPATH")) != NULL) {
+ curl_easy_setopt(curl, CURLOPT_CAPATH, ssl_capath);
+ }
+#endif
+ if ((ssl_cainfo = getenv("GIT_SSL_CAINFO")) != NULL) {
+ curl_easy_setopt(curl, CURLOPT_CAINFO, ssl_cainfo);
+ }
+
alt = xmalloc(sizeof(*alt));
alt->base = url;
alt->got_indices = 0;
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Ryan Anderson @ 2005-09-27 17:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0509270821590.3308@g5.osdl.org>
On Tue, Sep 27, 2005 at 08:34:22AM -0700, Linus Torvalds wrote:
> On Tue, 27 Sep 2005, Ryan Anderson wrote:
> >
> > git-rev-parse $tagname^0
>
> You need "--verify". Otherwise git-rev-parse will think that you just have
> a strange filename or other random thing:
>
> prompt$ git-rev-parse 000^0
> 000^0
Hmm:
$ cat .git/refs/tags/v2.6.13-rc4
7eab951de91d95875ba34ec4c599f37e1208db93
$ git-rev-parse v2.6.13-rc4
7eab951de91d95875ba34ec4c599f37e1208db93
$ git-rev-parse v2.6.13-rc4^0
63953523341bcafe5928bf6e99bffd7db94b471e
$ git-rev-parse 63953523341bcafe5928bf6e99bffd7db94b471e^0
63953523341bcafe5928bf6e99bffd7db94b471e
# The typo that demonstrates what you did:
$ git-rev-parse 7eab951de91d95875ba34ec4c599f37e1208db93^-
7eab951de91d95875ba34ec4c599f37e1208db93^-
$ git-rev-parse 7eab951de91d95875ba34ec4c599f37e1208db93^0
63953523341bcafe5928bf6e99bffd7db94b471e
So I think --verify is beneficial if you want errors returned, but if
you know you have real tags or commits, git-rev-parse without the
--verify seems to do the right thing.
Or, at the very least, in the case where I used this
(linux/scripts/setlocalversion), this behavior is fine.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Nick Hengeveld @ 2005-09-27 17:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x3a309u.fsf@assigned-by-dhcp.cox.net>
On Tue, Sep 27, 2005 at 10:09:49AM -0700, Junio C Hamano wrote:
> True. What I meant by "interesting" is that two is reading from
> what one is writing.
Excellent point. Given the potential for problems related to this
issue or to compressed representation, would it make sense to enable
partial transfers via a command-line option and leave the feature
disabled by default?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Junio C Hamano @ 2005-09-27 17:09 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: git
In-Reply-To: <20050927153636.GA1377@reactrix.com>
Nick Hengeveld <nickh@reactrix.com> writes:
> The way I understand this sequence, one and two will not be writing to
> the same file. When two unlinks tmpfile, one will still be able to
> write to its local, but the body of the file that one is writing will
> be removed when it closes local.
True. What I meant by "interesting" is that two is reading from
what one is writing.
>> 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.
>
> True, is that something I should include with the partial patch?
No.
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-27 17:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Tom Prince, git
In-Reply-To: <20050927094029.GA30889@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Yes, that's perhaps a fine solution for the core GIT plumbing, but in
> Cogito, I _really_ want to have this working automagically.
I agree that would be nice. If you are only interested in tags
that refer to commits that anchor points in published branches,
maybe we should have something along the lines of info/refs to
help the downloaders? Perhaps info/refs showing the SHA1 id of
the non-tag object each tag dereferences to in addition to the
current output?
This is a bit hard and needs some thinking to do cleanly,
because what is in info/refs is what is sent from the publisher
side over git-native protocol at the beginning of the handshake,
and it is not easy to add that to git-native protocol cleanly
and backward-compatibly (I think I know how without breaking
existing clients, but it is not clean).
^ permalink raw reply
* Re: More Porcelains?
From: Mariano Videla @ 2005-09-27 17:02 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxll1jvsc8.fsf@arm.com>
Mmm...It's no porcelain.
I setup a git repository for gipy... Didn't upload any files in
sourceforge because I don't think is ready.
http://24.232.198.9:7978/gipy.git
http://24.232.198.9:7978/cgi/gitweb.cgi
By the way... you can 'steel' it all!
Mariano
On mar, 2005-09-27 at 09:16 +0100, Catalin Marinas wrote:
> 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 ;-)
>
^ permalink raw reply
* Re: git-daemon: path validation, export all option
From: Junio C Hamano @ 2005-09-27 16:56 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43396FF9.1000900@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> I have restored this and make the requested RPM changes. I have left a
> pullable tree at:
>
> master.kernel.org:/home/hpa/git/daemon.git
>
> ... in order to preserve the commit structure.
Thanks. Will pull tonight.
^ permalink raw reply
* Re: git-daemon: path validation, export all option
From: H. Peter Anvin @ 2005-09-27 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslvr6t1u.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> A microNit. You could lose 'int ok' and return 1 directly where
> you assign 1 to it and break.
>
I guess I personally prefer the coding style where the straigh-line flow
of control is the normal one. It prevents the "oops" of someone wanting
to add code to it later.
>
>>- 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.
I have restored this and make the requested RPM changes. I have left a
pullable tree at:
master.kernel.org:/home/hpa/git/daemon.git
... in order to preserve the commit structure.
-hpa
^ permalink raw reply
* Re: [PATCH 3/3] Return CURL error message when object transfer fails
From: Nick Hengeveld @ 2005-09-27 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsqv2g3p.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 26, 2005 at 11:13:14PM -0700, Junio C Hamano wrote:
> ... 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?
Looks great, thanks.
> ------------
> 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>
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH 2/3] Support for partial HTTP transfers
From: Nick Hengeveld @ 2005-09-27 15:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyrr3vwp.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 26, 2005 at 10:46:30PM -0700, Junio C Hamano wrote:
> 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
> ???
The way I understand this sequence, one and two will not be writing to
the same file. When two unlinks tmpfile, one will still be able to
write to its local, but the body of the file that one is writing will
be removed when it closes 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.
True, is that something I should include with the partial patch?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: git-daemon: path validation, export all option
From: H. Peter Anvin @ 2005-09-27 15:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0509270802140.3308@g5.osdl.org>
Linus Torvalds wrote:
>
> Removing the "chdir(".git")" thing is very wrong, though. Why do it?
>
> It's very much on purpose: you can export even "regular" git trees (ie
> trees you have checked out) without the other side having to say
>
> git clone machine.com:/home/torvalds/v2.6/linux/.git
>
> where the final "/.git" is just stupid.
>
Agreed. I wasn't thinking too hard about it, and it doesn't do any harm
since failure is ignored.
-hpa
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Linus Torvalds @ 2005-09-27 15:34 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Petr Baudis, H. Peter Anvin, Git Mailing List
In-Reply-To: <4338F3F6.8040401@michonline.com>
On Tue, 27 Sep 2005, Ryan Anderson wrote:
>
> git-rev-parse $tagname^0
You need "--verify". Otherwise git-rev-parse will think that you just have
a strange filename or other random thing:
prompt$ git-rev-parse 000^0
000^0
prompt$ git-rev-parse --verify 000^0
fatal: Needed a single revision
Now, if the tag doesn't point to a commit, then the "^0" thing will fail.
What you could use instead is
git-rev-list --max-count=1 "$tag"
since git-rev-list will actually follow the tag. Of course, whether it
does so correctly or not if the tagged object doesn't exist, I dunno.
Testing needed.
Finally, you might just do it by hand
type=$(git-cat-file -t "$obj") || exit
if [ "$type" == "$tag" ]; then
tagged=$(git-cat-file tag "$obj" |
sed 's/object // ; q')
git-rev-parse --verify "$tagged"
fi
untested, of course.
Linus
^ permalink raw reply
* Re: shared GIT repos
From: Linus Torvalds @ 2005-09-27 15:21 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Junio C Hamano, git
In-Reply-To: <20050927084513.GU31276@kiste.smurf.noris.de>
On Tue, 27 Sep 2005, Matthias Urlichs wrote:
>
> 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.
Hmm.
What you _can_ do is to make your object and refs directories sticky.
That automatically means that only the owner of a file can remove it.
Now, people can still cover up their _own_ mistakes in that case, but they
can't change other peoples branches (since that involves overwriting
somebody elses ref), and they can't remove objects that somebody else has
written.
But they can, for example, change their _own_ branch to not have a ref to
that object, of course.
A more draconian option is to make the git programs setgid to a "git"
group, and making the object and ref directories only writable by the git
group. And then you change all the git programs to verify whatever rules
you have. That requires pretty big changes, though.
For example, you'd have to make all the scripts use the new git-update-ref
thing, and if you want to enforce that any new ref is a proper child of
the old ref, then you'd have to make git-update-ref test that one
explicitly (instead of leaving it to the scripts).
Quite frankly, I'd rather avoid that.
Oh. One thing you can do: don't allow direct filesystem access at _all_.
Use ssh to log in (even if it's on the same machine) as a special user
which is the only one that is allowed to touch the repo, and make that
special users login shell only accept git-receive-pack.
I wrote and posted an untested "git-sh" that did that some time ago,
holler if you want it again.
Add logging, and testing, and it should give you a safe write-only
alternative to "git-daemon" that only allows people to append to the git
history (oh, you'd still have to add some _small_ code to git-receive-pack
to not allow the "ignore old ref contents" case, but that's like two lines
of code).
Linus
^ permalink raw reply
* Re: git-daemon: path validation, export all option
From: Linus Torvalds @ 2005-09-27 15:03 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <4338AACC.1050305@zytor.com>
On Mon, 26 Sep 2005, H. Peter Anvin wrote:
>
> 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.
Removing the "chdir(".git")" thing is very wrong, though. Why do it?
It's very much on purpose: you can export even "regular" git trees (ie
trees you have checked out) without the other side having to say
git clone machine.com:/home/torvalds/v2.6/linux/.git
where the final "/.git" is just stupid.
Linus
^ permalink raw reply
* Re: [PATCH] Fix default pull not to do an unintended Octopus.
From: Josef Weidendorfer @ 2005-09-27 14:35 UTC (permalink / raw)
To: git
In-Reply-To: <20050927125434.GF30889@pasky.or.cz>
On Tuesday 27 September 2005 14:54, you wrote:
> Yes. I'm actually inclined to keep this setup, simply because it is
>
> * easy
> * simple
> * sufficient in most of the cases
I would almost say: sufficient for all cases.
The .git/remotes stuff is about providing a shortcut for remote
repositories and about defaults for this repository.
I am not really sure this is needed, and this second use of a name
(additionally to head names) can be confusing.
> > 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.
>
> No. If you are in the branches/ playground, please keep it strictly
> one-to-one mapping. That's what makes it easy and simple and that's what
> makes it good.
Ah, no. Any line in a branches/ file is a pure attribute for the given
head, and does not change its 1:1 relationship.
E.g. a branches/master file with
Push: git:/.../git.git#public-master
Merge: origin
would specify:
- If the current head is master, a cg-merge will merge with
head origin
- If the current head is master, a cg-push will publish the
local master to the given remote URL
The branches/master does nothing say about the origin branch/head.
> > 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?
>
> Yes.
>
> > 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.
>
> If ever doing that, this should be done at some other place than
> branches/.
Hmm, perhaps. We could go with .git/push-defaults and .git/merge-defaults.
But then, IMHO .git/branches should be renamed to .git/fetch-defaults,
as it holds the remote URL needed for fetching changes.
By creating the needed defaults on a cg-clone, you can get rid of the
above mentioned hardcoded things.
> And I'm sceptical about it anyway. Really, introducing some
> new configuration mechanism just to tell Cogito what default branch name
> should it pick up when you call fetch/update/merge without a parameter?
It is about storing pull/push remote URLs for a given head.
Ok, in the case "merge", it is about defaults (useful to
get rid of the hardcoding of merging origin into master on a cg-update).
I really think that the "push" URL currently is missing in Cogito.
Pushing the master by using the origin URL works, but I would like to
see this working for arbitrary heads.
By the way, am I correct than cogito currently misses a command to
switch the branch? cg-seek is only for temporal switching. What are
the prefered options? A "cg-seek -f", a "cg-jump" or "cg-switch"?
Josef
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Josef Weidendorfer @ 2005-09-27 13:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050927123455.GE30889@pasky.or.cz>
On Tuesday 27 September 2005 14:34, Petr Baudis wrote:
> But we don't need any global tags or heads. You just have some heads in
> your refs/heads (it doesn't matter if they are public or remote, that's
> a "social" issue what you tell people to fetch). And based on your heads
> you have in your refs/heads, there would be directories in your
> refs/tags/ corresponding to those.
Ah, ok.
Let me see if I understand:
1) These tags are bound to a head, and they have the invariant that they
appear in the commit history of the head.
2) They are updated automatically.
3) When someone rebases a head, the bound tags should be synced to the
rebased head's history.
4) Tags can appear multiple times, if they happen to be in the commit
history of multiple heads?
How to make sure that the invariant mentioned in (1) always holds?
> If you fetch remote head, its local subdirectory in refs/tags/ is
> populated with the new tags, and if you merge two heads, the public tags
> are copied around.
Ok, this is the "automatically updated" feature I talked about above.
So missing here is:
- If you want to get rid of a head, the tags should be removed
- If a head is rebased, this has to be detected and the tags recreated,
possibly removing some
Probably there should be a "cg-tag --recover" to resync these volatile
tags with tag objects appearing in the histories of heads?
As for lightweight tags of remote repositories, you probably need some
space to recover them e.g. on a rebase or creation of a new head without
running git-ls-remote all the time.
> Then if you are resolving a tag, we should first look
> at refs/tags/$(readlink HEAD)/tagname, and if it doesn't exist, we would
> look at refs/tags/tagname (so if you wanted to reference a tag not in
> your head, you'd have to use a "head/tag" form).
Sounds nice.
> > Perhaps interpret tag objects as global branch names, similar to
> > the "mixture" in .git/refs ?
>
> I don't understand.
Tag objects in a repository could be interpreted as branch names
for commits based on it. When creating a new branch point, I first
would put a tag object on this branch, thus renaming it.
I think this would be quite handy for navigation in histories.
Josef
^ permalink raw reply
* Re: [PATCH] Fix default pull not to do an unintended Octopus.
From: Petr Baudis @ 2005-09-27 12:54 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200509271152.42963.Josef.Weidendorfer@gmx.de>
Dear diary, on Tue, Sep 27, 2005 at 11:52:42AM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> 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.
Yes. I'm actually inclined to keep this setup, simply because it is
* easy
* simple
* sufficient in most of the cases
Cogito's fetch/update should certainly support the remotes stuff, since
they are obviously much more useful and practical for more complicated
setup, but I think I will keep the branches/ setup (the name of the
directory is the only thing I don't like on it ;) as the primary mean of
configuring remote branches. I will only have to add possibility to
cg-fetch multiple branches at once, which could also make branches/
significantly more practical.
> 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.
No. If you are in the branches/ playground, please keep it strictly
one-to-one mapping. That's what makes it easy and simple and that's what
makes it good.
> 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?
Yes.
> 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.
If ever doing that, this should be done at some other place than
branches/. And I'm sceptical about it anyway. Really, introducing some
new configuration mechanism just to tell Cogito what default branch name
should it pick up when you call fetch/update/merge without a parameter?
I don't know if that wouldn't make more evil than good.
Well, if you _really_ _really_ badly want it, we can make
.git/default-origin/ or something... duh, what a stupid name. :)
--
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: [PATCH] Added an option to cvsimport to specify email domain
From: David Mansfield @ 2005-09-27 12:54 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: git
In-Reply-To: <200509270834.55486.snake@penza-gsm.ru>
On Tue, 2005-09-27 at 08:34 +0400, Alexey Nezhdanov wrote:
> (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?
I apologize that I probably won't have time to look at this right now...
David
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-09-27 12:34 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200509271214.31933.Josef.Weidendorfer@gmx.de>
Dear diary, on Tue, Sep 27, 2005 at 12:14:31PM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> 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.
But we don't need any global tags or heads. You just have some heads in
your refs/heads (it doesn't matter if they are public or remote, that's
a "social" issue what you tell people to fetch). And based on your heads
you have in your refs/heads, there would be directories in your
refs/tags/ corresponding to those.
If you fetch remote head, its local subdirectory in refs/tags/ is
populated with the new tags, and if you merge two heads, the public tags
are copied around. Then if you are resolving a tag, we should first look
at refs/tags/$(readlink HEAD)/tagname, and if it doesn't exist, we would
look at refs/tags/tagname (so if you wanted to reference a tag not in
your head, you'd have to use a "head/tag" form). Optionally, you could
also look for refs/tags/*/tagname and if it gives you a unique match,
use that - but I'm not sure how good idea this is since it already makes
the lookup way too heuristical.
> Perhaps interpret tag objects as global branch names, similar to
> the "mixture" in .git/refs ?
I don't understand.
--
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: [PATCH 2/3] Support for partial HTTP transfers
From: sf @ 2005-09-27 10:35 UTC (permalink / raw)
To: git
In-Reply-To: <20050926175204.GC9410@reactrix.com>
Nick Hengeveld wrote:
> Support for partial HTTP transfers - if a previous temp file is detected,
> read it in and start the HTTP transfer from where the previous left off.
Please read my recent posting:
http://permalink.gmane.org/gmane.comp.version-control.git/8991.
Regards
Stephan
^ permalink raw reply
* Re: shared GIT repos
From: Matthias Urlichs @ 2005-09-27 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <20050927135903.6b20a76b.vsu@altlinux.ru>
Hi, Sergey Vlasov wrote:
> 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.
Sure. I plan to; "committer" at least should match one of the user's known
email addresses. In addition to that, the files will belong to the user.
--
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
- -
Never count your chickens before they rip your lips off.
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Petr Baudis @ 2005-09-27 10:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tom Prince, git
In-Reply-To: <7vll1jh8zr.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Sep 26, 2005 at 10:25:28PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > ... Either way, git-pull won't be equivalent to git-fetch &&
> > git-merge (or git-resolve or whatever is the core porcelain
> > command) anymore.
>
> "pull = fetch + merge" is a reasonable approximation to use when
> you explain what they are to somebody, but taking it literally
> would harm usefulness.
>
> It is what you have already lived with for a while. "git pull
> .../linux/2.6.git v2.6.11-tree v2.6.12" would fetch both heads
> but merges v2.6.12 head only (because v2.6.11-tree is not
> something you can merge with).
Yes, but that's a rather obscure case. :-) But well, your use cases
convinced me that the behaviour to fetch multiple heads even if you are
going to merge just one of them is useful enough. However, I still think
that the user should be required to specify the to-be-merged head
manually if the default choice isn't explicitly written in the remotes
file.
--
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: 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
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