Michael Witten | 1 Oct 2011 01:04
Picon

Re: Dealing with rewritten upstream

On Fri, Sep 30, 2011 at 22:09, Jay Soffian <jaysoffian <at> gmail.com> wrote:
> I have a repo w/over two years of history whose upstream repo is a
> git-svn mirror.
>
> The upstream folks recently announced they need to retire the existing
> repo and replace it with a new repo. The new repo is identical to the
> old repo tree wise (commit for commit), but some of the commits in the
> old repo had incorrect authorship which is corrected in the new repo,
> so the new repo has different commit IDs than the old.
>
> (i.e., it's as if they've run filter-branch --env-filter on the old repo.)
>
> My repo has many merge points with the old history.
>
> 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.)
(Continue reading)

Junio C Hamano | 1 Oct 2011 01:18
Picon
Picon
Favicon
Gravatar

Re: Updated tag 'junio-gpg-pub' ?

Andreas Schwab <schwab <at> linux-m68k.org> writes:

> You might want to update the tag message the next time with
> s/git-/git /.

Heh, good idea ;-).
Jay Soffian | 1 Oct 2011 01:28
Picon

Re: Dealing with rewritten upstream

On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten <mfwitten <at> 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.
(Continue reading)

Grant | 1 Oct 2011 01:43
Picon

Does git have "Path-Based Authorization"?

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
Carlos Martín Nieto | 1 Oct 2011 01:48
Picon

Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch

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
(Continue reading)

Carlos Martín Nieto | 1 Oct 2011 01:54
Picon

Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch

On Wed, 2011-09-28 at 12:12 -0700, Jakub Narebski wrote:
> Carlos Martín Nieto <cmn <at> 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'
(Continue reading)

Carlos Martín Nieto | 1 Oct 2011 02:05
Picon

Re: Does git have "Path-Based Authorization"?

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

Nguyễn Thái Ngọc Duy | 1 Oct 2011 03:26
Picon
Gravatar

[PATCH] transport: do not allow to push over git:// protocol

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 <at> 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
 <at>  <at>  -933,7 +933,8  <at>  <at>  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;
(Continue reading)

Grant | 1 Oct 2011 03:31
Picon

Re: Does git have "Path-Based Authorization"?

>> 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/
>
(Continue reading)

Nguyen Thai Ngoc Duy | 1 Oct 2011 03:34
Picon
Gravatar

Re: Does git have "Path-Based Authorization"?

On Sat, Oct 1, 2011 at 11:31 AM, Grant <emailgrant <at> 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

Gmane