* Git, Mac OS X and German special characters
From: Albert Zeyer @ 2011-10-01 12:44 UTC (permalink / raw)
To: git
Hi,
There are problems on MacOSX with different UTF8 encodings of
filenames. A unicode string has multiple ways to be represented as
UTF8 and Git treats them as different filenames. This is the actual
bug. It should treat them all as the same filename. In some cases (as
on MacOSX), the underlying operating system may use a normalized UTF8
representation in some sort, i.e. change the actual UTF8 filename
representation.
Similar problems also exists in SVN, for example. This was reported
[here](http://subversion.tigris.org/issues/show_bug.cgi?id=2464).
There you can find also lengthy discussions about the topic. And also
[here](http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames).
This was already reported for Git earlier and there is also a patch
for Git [here](http://lists-archives.org/git/719832-git-mac-os-x-and-german-special-characters.html).
I wonder about the state of this. This hasn't been applied yet. Why?
Regards,
Albert
^ permalink raw reply
* Re: Dealing with rewritten upstream
From: Philip Oakley @ 2011-10-01 11:34 UTC (permalink / raw)
To: Jay Soffian, Michael Witten; +Cc: git
In-Reply-To: <CAG+J_Dw9Oa=LH1CSE3Dr_B6de8X-SQfrWGbayPy3OD-UqB6siA@mail.gmail.com>
From: "Jay Soffian" <jaysoffian@gmail.com>
> On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten <mfwitten@gmail.com>
> wrote:
>>> Pictorially:
>>>
>>> ---A---B---C---D---E... new-upstream/master
>>>
>>> ---a---b---c---d---e... old-upstream/master
>>> \ \ \
>>> 1---2---3---4---5 master
>>>
>>> The obvious way do deal with this situation is:
>>>
>>> $ git merge -s ours -m "Splice in new-upstream/master" E
>>>
>>> Are there any other/better options I'm missing?
>>>
>>> (Eventually upstream plans to migrate entirely to git, so I can't just
>>> run git-svn myself.)
>>
>> Surely, you'd rather have your master rewritten such that the relevant
>> commits of new-upstream/master are used IN PLACE of the corresponding
>> old-upstream/master. Have you considered ways to achieve that?
>
> My master has over two years of history with its commit-IDs referenced
> in our bug tracker, in old emails, in archived binaries, etc. So no, I
> do not want to rewrite my master.
>
> Now, if you mean, do I want to use something like replacement refs to
> try to more cleanly splice the new upstream into my existing master,
> no I haven't really explored that. git-replace isn't very well
> documented with examples of its intended use case.
>
> I've considered setting up a new repo at a different URL that is
> rewritten to be based on the new upstream, and migrating to that,
> making the old repo read-only.
>
> But I'm not sure that's worth the trouble. There doesn't seem to be
> too much downside to splicing in the new upstream via merge -s ours.
> It barely increases the repo size since the trees are the same. Maybe
> there's some other downsides I'm missing.
>
Surely; one method is to simply create a merge between the Old_master and
New_master (i.e. have two parallel branches of identical content) at the
point where the new approach starts. Git-filter-branch (if used) already
provides the ref to the original, so it's easy to create that special merge.
You have already noted that all the trees for the commits are identical, so
the storage overhead is minimal for just the new commit objects (though the
cognitive overhead can be large for some - plan for often/early
explanations!)
I'm presuming that you will have at some point in the past, a common commit
(it maybe the initial commit), so that there is still a single root.
The key question is to decide which 'branch' is Parent1, and which is
Parent2 (at the merge) for any history traversals that may be required in
the future. After the merge you can rename the branch back to Master if
required (more cognitive discussions..)
This slightly differs from your original diagram in that you do not have any
one-to-one links between the old and new commits. The date/time would be the
same for the old & new so it shouldn't be hard to find one from the other.
Philip
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Jeff King @ 2011-10-01 10:54 UTC (permalink / raw)
To: Philip Oakley
Cc: Carlos Martín Nieto, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <BED2B875AEDF4E52843F1C9211A8D2A1@PhilipOakley>
On Sat, Oct 01, 2011 at 11:38:08AM +0100, Philip Oakley wrote:
> Is there a write up of the the git testing method and how to use
> bin-wrappers etc. I didn't see anything in the Documentation, but I
> may not have looked carefully enough
Bin-wrappers (and the alternative, which is setting up the exec-path
yourself) are mentioned briefly in INSTALL. Running tests is described
in t/README.
Other than that, you're left on your own to read the code and the commit
messages. :)
-Peff
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Philip Oakley @ 2011-10-01 10:38 UTC (permalink / raw)
To: Jeff King, Carlos Martín Nieto; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20111001060353.GA25228@sigill.intra.peff.net>
From: "Jeff King" <peff@peff.net>
> On Sat, Oct 01, 2011 at 01:54:08AM +0200, Carlos Martín Nieto wrote:
>
>> > Have you tried
>> >
>> > $ ./git fetch git://repo.or.cz/git
>>
>> But this would execute /usr/local/libexec/git-fetch, wouldn't it? That
>> is precisely what I don't want to execute, because I changed some code
>> in builtin/fetch.c that I want to test.
>
> No, but only because fetch is a builtin. However, it still doesn't set
> up exec_path correctly, so your rev-list problem would not go away.
>
>> I guess I'll have to either properly install git from 'next' or base my
>> changed on 'maint'
>
> Just use bin-wrappers/git. That's exactly what it's there for (and it's
> what the test scripts use to make sure we are testing what is compiled).
>
> Your change isn't the problem; only your testing method.
>
> -Peff
Peff,
Is there a write up of the the git testing method and how to use
bin-wrappers etc. I didn't see anything in the Documentation, but I may not
have looked carefully enough
Philip
^ permalink raw reply
* Re: [PATCH] gitk: Show patch for initial commit
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-01 9:54 UTC (permalink / raw)
To: Marcus Karlsson; +Cc: git, gitster
In-Reply-To: <20110930215021.GA3005@kennedy.acc.umu.se>
On 09/30/2011 11:50 PM, Marcus Karlsson wrote:
> Make gitk show the patch for the initial commit.
>
> Signed-off-by: Marcus Karlsson<mk@acc.umu.se>
> ---
> gitk-git/gitk | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 4cde0c4..20aeae6 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -7436,7 +7436,7 @@ proc diffcmd {ids flags} {
> lappend cmd HEAD
> }
> } else {
> - set cmd [concat | git diff-tree -r $flags $ids]
> + set cmd [concat | git diff-tree -r --root $flags $ids]
> }
> return $cmd
> }
Cool, this works for me! But I think I would be really nice if gitk
respected the configuration value of log.showroot. This would give nice
consistency amongst the various tools.
Zbyszek
^ permalink raw reply
* Re: Fwd: Release notes link problem
From: Junio C Hamano @ 2011-10-01 6:58 UTC (permalink / raw)
To: Jeff King; +Cc: Eugene Sajine, git
In-Reply-To: <20111001061004.GA25700@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Sep 30, 2011 at 05:06:50PM -0400, Eugene Sajine wrote:
>
>> The release notes link on http://git-scm.com/ is pointing to a page
>> which doesn't seem to exist. I'm getting error 404 when trying to
>> access it. Does anybody see the same issue?
>>
>> the link is
>> https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.6.4.txt
>
> This was due to some breakage on github this afternoon, but I believe it
> has since been fixed.
I guess the link should be
https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.7.txt
instead ;-).
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: John Szakmeister @ 2011-10-01 6:57 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <CAG+J_DyhcA7RmHwgGJBw4r9JRij0_ONp3ZMD6oMTJ_f4dvYW8w@mail.gmail.com>
On Fri, Sep 30, 2011 at 3:33 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 6:03 AM, John Szakmeister <john@szakmeister.net> wrote:
>>
>> I've been working on a version of the keychain credential cache as
>> well. I did create a gui, although it's a bit painful.
>
> I still don't understand why a CLI app should have a GUI credential prompt.
For one, I saw it more as being useful to things other than the git
command line. And the Mac already presents a GUI for unlocking the
keychain if necessary. It's not like there isn't any precedent for
it.
[snip]
>> I think that makes sense. I think one thing we have to be careful
>> about partial matches. I wouldn't want the credential cache to send
>> off the wrong password to a service. This may be me being cautious,
>> but if I don't have all the necessary bits, I'd rather we fail that to
>> guess which entry is right.
>
> The credential helper I wrote doesn't work that way. To do so would
> mean using a rather more complicated form of the OS X Security API. It
> asks for an entry using whatever fields it has, and OS X returns the
> first match that satisfies. It's up to the user to yea/nay that match
> if the credential helper isn't on the entry's ACL.
True, the user would at least have to acknowledge it.
>>>> + /* "GitHub for Mac" compatibility */
>>>> + if (!strcmp(hostname, "github.com"))
>>>> + hostname = "github.com/mac";
>>>
>>> Nice touch. :)
>>
>> I honestly don't understand why this needs to be done.
>
> Because GitHub for Mac stores its entries using "github.com/mac" as
> the hostname.
>
>> I don't use GitHub for Mac... does that mean this is busted for me?
>
> No. It just means that the credential helper and GitHub for Mac store
> their entry in a compatible fashion. (So that each can locate the
> entry stored by the other.)
Ah, interesting. But it does mean that it won't pick up the password
I've cached via my browser, right?
>> [snip]
>>> My series will also produce "cert:/path/to/certificate" when unlocking a
>>> certificate. The other candidates for conversion are smtp-auth (for
>>> send-email) and imap (for imap-send). I guess for certs, you'd want to
>>> use the "generic" keychain type.
>>
>> There is a method for adding a certificate to the keychain:
>> <http://developer.apple.com/library/mac/#documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/doc/uid/TP30000157>
>>
>> I'm not sure what that does exactly, but I do have a cert, and it
>> shows up as "certificate" in the keychain.
>
> That's for storing a certificate itself. In this case, I think we're
> just talking about storing the passphrase which protects the
> certificate's private key.
I could've sworn the docs mentioned storing the private key, but I
don't see it. SecIdentityCreateWithCertificate() can get you the
private key from a cert, once added. It's not clear how to go from
cert to password in a manner that's compatible with other Mac apps.
[snip]
>> By the time you get Keychain involved, the decision has been made.
>> Most applications offer that ability... and you're right, this should
>> probably offer the same capability. That also means stashing that
>> data somewhere. :-( OTOH, it does make for a better user experience.
>
> What, no? If you don't want git to store usernames/passwords stored in
> the OS X Keychain, don't use the git-osx-keychain credential helper.
I want *some* cached, and others not. I don't want to be forced to
remember to take git-osx-keychain out of my credentials list, or
something silly like that. That doesn't help on the user-friendliness
front. Having a check box and storing the fact that we shouldn't
cache the password in the repo's config seems like a reasonable
approach. But I agree with Jeff in another part of this thread: I
think the prompting of the username and password should be a separate
mechanism. It could prompt about whether or not to store the
password, and git could take care of whether or not to call the
credential store.
-John
^ permalink raw reply
* Re: Fwd: Release notes link problem
From: Jeff King @ 2011-10-01 6:10 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <CAPZPVFY9O2VC7TS9ASReD5LYiqfDwLY5M2vxE97M+7BsYvAoqg@mail.gmail.com>
On Fri, Sep 30, 2011 at 05:06:50PM -0400, Eugene Sajine wrote:
> The release notes link on http://git-scm.com/ is pointing to a page
> which doesn't seem to exist. I'm getting error 404 when trying to
> access it. Does anybody see the same issue?
>
> the link is
> https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.6.4.txt
This was due to some breakage on github this afternoon, but I believe it
has since been fixed.
-Peff
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Jeff King @ 2011-10-01 6:03 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <1317426849.4331.29.camel@centaur.lab.cmartin.tk>
On Sat, Oct 01, 2011 at 01:54:08AM +0200, Carlos Martín Nieto wrote:
> > Have you tried
> >
> > $ ./git fetch git://repo.or.cz/git
>
> But this would execute /usr/local/libexec/git-fetch, wouldn't it? That
> is precisely what I don't want to execute, because I changed some code
> in builtin/fetch.c that I want to test.
No, but only because fetch is a builtin. However, it still doesn't set
up exec_path correctly, so your rev-list problem would not go away.
> I guess I'll have to either properly install git from 'next' or base my
> changed on 'maint'
Just use bin-wrappers/git. That's exactly what it's there for (and it's
what the test scripts use to make sure we are testing what is compiled).
Your change isn't the problem; only your testing method.
-Peff
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 5:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vwrcpoozk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> I think in general our documentation aims to spell out _all_ that happens,
...
> I am wondering if there is a systemic failure...
> ,,,If so are there things that we could
> do better without going through individual description?
Yes, I would say that there is one obvious
systemic failure.
Nowhere is it documented (as far as I am aware) that
this is the way the git documentation should be read.
Since, in this regard, it differs from most software
documentation, it ought itself to be documented,
perhaps on the top-level git man page.
-P.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 5:40 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1BsTKBPArRF-LxoNOJcQarMWx-2a2UBoVjWN-96xJ3Ad8A@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> Well, you're missing the fact that it not only causes those to
> be downloaded, but it also causes the defaults to be ignored,
> which is why you don't get the other stuff. You can still tell
> git to fetch anything else you want in addition.
I was no longer missing it at the time I posted.
But that is indeed what I was missing when I first encountered
the behavior. The purpose of posting was to point out that
with a very small change in the documentation, I would not
have missed it.
-P.
^ permalink raw reply
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Jonathan Nieder @ 2011-10-01 5:29 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Ilari Liusvaara, git
In-Reply-To: <20111001022544.GA31036@LK-Perkele-VI.localdomain>
Ilari Liusvaara wrote:
> What about sticking code to return an error to git daemon instead of this?
The code has even been written:
http://thread.gmane.org/gmane.comp.version-control.git/145456/focus=145573
Testing and other improvements would be very welcome.
^ permalink raw reply
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Nguyen Thai Ngoc Duy @ 2011-10-01 4:27 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20111001022544.GA31036@LK-Perkele-VI.localdomain>
2011/10/1 Ilari Liusvaara <ilari.liusvaara@elisanet.fi>:
> What about sticking code to return an error to git daemon instead of this?
>
> Here's what happens if I try to push to one of repos on this computer
> over git://:
>
> $ git push git://localhost/foobar
> fatal: remote error: W access for foobar DENIED to anonymous
>
> So send-pack can deal with ERR packet (and yes, that error message
> is really from Gitolite).
I'm dealing with git.gnome.org and not sure what's the server behind.
I had a look at git-daemon and it does allow push, but disabled by
default. So yes, maybe updating git-daemon is better.
> Aside: git archive seemingly can't deal with ERR packets. And worse
> yet, it doesn't even print what it received, resulting this:
>
> $ git archive --remote=git://localhost/foobar HEAD
> fatal: git archive: protocol error
Yes, builtin/archive.c seems only recognize either ACK or NACK.
pack-protocol.txt does not mention about ERR either, which seems to be
introduced in a807328 (connect.c: add a way for git-daemon to pass an
error back to client).
--
Duy
^ permalink raw reply
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Ilari Liusvaara @ 2011-10-01 2:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1317432415-9459-1-git-send-email-pclouds@gmail.com>
On Sat, Oct 01, 2011 at 11:26:55AM +1000, Nguyễn Thái Ngọc Duy wrote:
> This protocol has never been designed for pushing. Attempts to push
> over git:// usually result in
>
> fatal: The remote end hung up unexpectedly
>
> That message does not really point out the reason. With this patch, we get
>
> error: this protocol does not support pushing
> error: failed to push some refs to 'git://some-host.com/my/repo'
What about sticking code to return an error to git daemon instead of this?
Here's what happens if I try to push to one of repos on this computer
over git://:
$ git push git://localhost/foobar
fatal: remote error: W access for foobar DENIED to anonymous
So send-pack can deal with ERR packet (and yes, that error message
is really from Gitolite).
Aside: git archive seemingly can't deal with ERR packets. And worse
yet, it doesn't even print what it received, resulting this:
$ git archive --remote=git://localhost/foobar HEAD
fatal: git archive: protocol error
-Ilari
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: david @ 2011-10-01 2:09 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw1-Edb5PdoTzJz38vJOjjXVAg6F24XgHpTi+3e5C7yxfQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1965 bytes --]
On Fri, 30 Sep 2011, Grant wrote:
>>> I have a series of files containing server-side code which make up a
>>> website. The entire layout contains only a few folders, but those
>>> folders contain many files. I want to be able to allow access to only
>>> certain files at a time, sometimes only a single file. Can that be
>>> done in the way you describe?
>>
>> If you can gather all sensitive files in a subdirectory, then you can
>> split that directory into its own repository (see git-submodule man
>> page) and grant limited access to that repo.
>> --
>> Duy
>
> I thought about separating files the dev has had access to into a
> separate folder from files the dev hasn't had access to, but it would
> mean constantly changing the code as files move around, plus it would
> be too complicated if I have multiple devs and want to give them
> access to different stuff. It's not that some files are more
> sensitive than others, it's just that I don't want to give anyone
> access to more than I have to.
the thing to think about is why would you want to give a dev access to a
file or restrict their access.
Remember that the Dev should be able to test their changes, so you really
need to give them access to enough stuff to be a complete, working set.
If you make each set of things it's own repository, then you should have
the granularity you are looking for.
If you think you will need more granularity, please explain what you are
thinking of?
Also remember that you don't want to have your development files on your
production site, so you probably don't want to deploy directly from your
repository to the production site. If you use a filter to make a new git
repository that only contains the pieces that you are wanting to publish,
and keep that repository clean, only submitting the files that you want
there, but treat it as a read-only repository (i.e. no development work
done there), you should be in good shape.
David Lang
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Grant @ 2011-10-01 1:43 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8Dm-vSoki9Fr7s=DH7oRYL-a=kF7q9mBwo55ZxsLg5DTA@mail.gmail.com>
>> I have a series of files containing server-side code which make up a
>> website. The entire layout contains only a few folders, but those
>> folders contain many files. I want to be able to allow access to only
>> certain files at a time, sometimes only a single file. Can that be
>> done in the way you describe?
>
> If you can gather all sensitive files in a subdirectory, then you can
> split that directory into its own repository (see git-submodule man
> page) and grant limited access to that repo.
> --
> Duy
I thought about separating files the dev has had access to into a
separate folder from files the dev hasn't had access to, but it would
mean constantly changing the code as files move around, plus it would
be too complicated if I have multiple devs and want to give them
access to different stuff. It's not that some files are more
sensitive than others, it's just that I don't want to give anyone
access to more than I have to.
- Grant
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Nguyen Thai Ngoc Duy @ 2011-10-01 1:34 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw0+v9qscJ+isQdwJOHT4Ajsk-96QK8gQFsu9E87a3j+Ww@mail.gmail.com>
On Sat, Oct 1, 2011 at 11:31 AM, Grant <emailgrant@gmail.com> wrote:
> I have a series of files containing server-side code which make up a
> website. The entire layout contains only a few folders, but those
> folders contain many files. I want to be able to allow access to only
> certain files at a time, sometimes only a single file. Can that be
> done in the way you describe?
If you can gather all sensitive files in a subdirectory, then you can
split that directory into its own repository (see git-submodule man
page) and grant limited access to that repo.
--
Duy
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Grant @ 2011-10-01 1:31 UTC (permalink / raw)
To: git
In-Reply-To: <1317427503.4331.37.camel@centaur.lab.cmartin.tk>
>> Hello, I'm trying to decide between git and subversion. Subversion
>> has "Path-Based Authorization" so I can give a developer access to
>> only specific files instead of everything. Does git have something
>> similar?
>
> Git's model does not allow the same type "Path-Based Authorization" that
> Subversion uses, because git uses secure hash sums to make sure that
> people don't try to sneak changes into a pull request or merge, and you
> can't selectively download parts of the tree because then you couldn't
> check that one of your remotes isn't trying to lie to you.
>
> You can do something that is (or can be) similar with git and
> gitolite[0] so a developer (or set of developers) only has access to a
> particular set of branches. Depending on what exactly you're trying to
> do, this can be more or less complicated to set up. If you only want a
> set of developers to access the subdirectory
> clients/importantsecretclient, then you create that directory only in
> the branch or branches that developer can read. There are many examples
> int he gitolite wiki.
I have a series of files containing server-side code which make up a
website. The entire layout contains only a few folders, but those
folders contain many files. I want to be able to allow access to only
certain files at a time, sometimes only a single file. Can that be
done in the way you describe?
- Grant
> [0] https://github.com/sitaramc/gitolite/wiki/
>
> HTH
>
> cmn
^ permalink raw reply
* [PATCH] transport: do not allow to push over git:// protocol
From: Nguyễn Thái Ngọc Duy @ 2011-10-01 1:26 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
This protocol has never been designed for pushing. Attempts to push
over git:// usually result in
fatal: The remote end hung up unexpectedly
That message does not really point out the reason. With this patch, we get
error: this protocol does not support pushing
error: failed to push some refs to 'git://some-host.com/my/repo'
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
I wanted to advise using remote.*.pushurl too, more friendly. But then I
had to detect if url comes from command line or config, and I gave up.
transport.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/transport.c b/transport.c
index fa279d5..b109145 100644
--- a/transport.c
+++ b/transport.c
@@ -933,7 +933,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->set_option = NULL;
ret->get_refs_list = get_refs_via_connect;
ret->fetch = fetch_refs_via_pack;
- ret->push_refs = git_transport_push;
+ if (prefixcmp(url, "git://"))
+ ret->push_refs = git_transport_push;
ret->connect = connect_git;
ret->disconnect = disconnect_git;
ret->smart_options = &(data->options);
@@ -1075,6 +1076,8 @@ int transport_push(struct transport *transport,
return ret;
}
+ else
+ return error("this protocol does not support pushing");
return 1;
}
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Re: Does git have "Path-Based Authorization"?
From: Carlos Martín Nieto @ 2011-10-01 0:05 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw0QXkNSF8+qGu+pCrv5dgy1OEvtq-53f23GRd4RrZ1GcQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
On Fri, 2011-09-30 at 16:43 -0700, Grant wrote:
> Hello, I'm trying to decide between git and subversion. Subversion
> has "Path-Based Authorization" so I can give a developer access to
> only specific files instead of everything. Does git have something
> similar?
Git's model does not allow the same type "Path-Based Authorization" that
Subversion uses, because git uses secure hash sums to make sure that
people don't try to sneak changes into a pull request or merge, and you
can't selectively download parts of the tree because then you couldn't
check that one of your remotes isn't trying to lie to you.
You can do something that is (or can be) similar with git and
gitolite[0] so a developer (or set of developers) only has access to a
particular set of branches. Depending on what exactly you're trying to
do, this can be more or less complicated to set up. If you only want a
set of developers to access the subdirectory
clients/importantsecretclient, then you create that directory only in
the branch or branches that developer can read. There are many examples
int he gitolite wiki.
[0] https://github.com/sitaramc/gitolite/wiki/
HTH
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Carlos Martín Nieto @ 2011-09-30 23:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <m3y5x8o527.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
On Wed, 2011-09-28 at 12:12 -0700, Jakub Narebski wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > Hello,
> >
> > Whilst trying to do some work related to fetch, I came across a
> > regression in the 'next' branch. Bisecting gave me this commit as
> > breaking point (and I tried with the parent and there it worked). When
> > doing 'git fetch', rev-list will complain about usage, and fetch will
> > say that we didn't receive enough, even though earlier versions of git
> > have no problems. This fails both on github and on git.or.cz and for git
> > and http transports:
> >
> > $ ./git-fetch git://repo.or.cz/git
>
> Have you tried
>
> $ ./git fetch git://repo.or.cz/git
But this would execute /usr/local/libexec/git-fetch, wouldn't it? That
is precisely what I don't want to execute, because I changed some code
in builtin/fetch.c that I want to test.
But yes, the problem was that the local git-fetch was trying to pass an
option to rev-list that my older installed binary didn't understand. In
this particular case I don't want to run the older git-fetch, but
otherwise, that would work.
I guess I'll have to either properly install git from 'next' or base my
changed on 'maint'
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Carlos Martín Nieto @ 2011-09-30 23:48 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20110928185327.GB1482@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
On Wed, 2011-09-28 at 14:53 -0400, Jeff King wrote:
> On Wed, Sep 28, 2011 at 06:04:27PM +0200, Carlos Martín Nieto wrote:
>
> > Whilst trying to do some work related to fetch, I came across a
> > regression in the 'next' branch. Bisecting gave me this commit as
> > breaking point (and I tried with the parent and there it worked). When
> > doing 'git fetch', rev-list will complain about usage, and fetch will
> > say that we didn't receive enough, even though earlier versions of git
> > have no problems. This fails both on github and on git.or.cz and for git
> > and http transports:
> >
> > $ ./git-fetch git://repo.or.cz/git
> > usage: git rev-list [OPTION] <commit-id>... [ -- paths... ]
>
> Hmm. I notice you're running a not-installed version of fetch. Might
> this be a problem with a new git fetch running an older, installed
> version of rev-list?
Yes, this seems indeed to be the case.
>
> The commit you mention calls rev-list with --verify-objects, but that
> feature is only added in the parent commit. So I can reproduce your
> issue with:
>
> $ git checkout 6d4bb38~2 ;# or anything before --verify-objects
> $ make install
> $ git checkout 6d4bb38
> $ make
> $ ./git-fetch git://repo.or.cz/git
>
> but this works (because it sets the exec path properly):
>
> $ ./bin-wrappers/git fetch git://repo.or.cz/git
>
> as does this:
>
> $ make install
> $ ./git-fetch git://repo.or.cz/git
>
> So I don't think there's a bug. It's just that running compiled programs
> straight out of the build directory isn't supported. It works _most_ of
> the time, but as you can see, you may end up calling older, installed
> versions of git. The bin-wrappers scripts set up the exec path properly
> to let you test.
Indeed, as both you and Junio pointed out (within three minutes of each
other :) I was running git from the build directory and expected it to
work, as I was testing a few changed I had made to the fetch code.
Mea culpa, I tend to forget that git tends to behave like a bunch of
shell scripts that happen to be written in C. Thanks to both.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Does git have "Path-Based Authorization"?
From: Grant @ 2011-09-30 23:43 UTC (permalink / raw)
To: git
Hello, I'm trying to decide between git and subversion. Subversion
has "Path-Based Authorization" so I can give a developer access to
only specific files instead of everything. Does git have something
similar?
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
- Grant
^ permalink raw reply
* Re: Dealing with rewritten upstream
From: Jay Soffian @ 2011-09-30 23:28 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <CAMOZ1Bu-1hq1UN+UQs9HreR4bhJAoxGFLA=jdW8jgoC9g3DJHQ@mail.gmail.com>
On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten <mfwitten@gmail.com> wrote:
>> Pictorially:
>>
>> ---A---B---C---D---E... new-upstream/master
>>
>> ---a---b---c---d---e... old-upstream/master
>> \ \ \
>> 1---2---3---4---5 master
>>
>> The obvious way do deal with this situation is:
>>
>> $ git merge -s ours -m "Splice in new-upstream/master" E
>>
>> Are there any other/better options I'm missing?
>>
>> (Eventually upstream plans to migrate entirely to git, so I can't just
>> run git-svn myself.)
>
> Surely, you'd rather have your master rewritten such that the relevant
> commits of new-upstream/master are used IN PLACE of the corresponding
> old-upstream/master. Have you considered ways to achieve that?
My master has over two years of history with its commit-IDs referenced
in our bug tracker, in old emails, in archived binaries, etc. So no, I
do not want to rewrite my master.
Now, if you mean, do I want to use something like replacement refs to
try to more cleanly splice the new upstream into my existing master,
no I haven't really explored that. git-replace isn't very well
documented with examples of its intended use case.
I've considered setting up a new repo at a different URL that is
rewritten to be based on the new upstream, and migrating to that,
making the old repo read-only.
But I'm not sure that's worth the trouble. There doesn't seem to be
too much downside to splicing in the new upstream via merge -s ours.
It barely increases the repo size since the trees are the same. Maybe
there's some other downsides I'm missing.
j.
^ permalink raw reply
* Re: Updated tag 'junio-gpg-pub' ?
From: Junio C Hamano @ 2011-09-30 23:18 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Stefan Näwe, Git List
In-Reply-To: <m2zkhlkgv2.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> You might want to update the tag message the next time with
> s/git-/git /.
Heh, good idea ;-).
^ 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