Re: Git push failure in the case of SSH to localhost

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 11, 2009 at 9:22 PM, Jeff King <peff@xxxxxxxx> wrote:
> On Wed, Feb 11, 2009 at 09:20:51PM +0200, Ciprian Dorin, Craciun wrote:
>
>>     But I find it easier to just create a bin folder and drop my
>> scripts there... (For example git-branch-import that takes a new
>> branch name and an URL and creates the branch with no ancestry and
>> knows http, ftp, svn, tar.{gz,bz2}, zip, etc...)
>
> I don't see what is per-repo about that. That is, why not put it in a
> PATH directory accessible by all repos. And if there is some
> repo-specific data, you can have the script read it from the current
> repo by "git config".
>
> -Peff

    Well, it is per-repo because I've left out to tell you that the
git-branch-import command I use to track non-git source code
distributions for other projects... And my command constructs the
branch name in a certain way...

    Anyway, I don't see why it's wrong to have such a bin folder per
repository... Let's for a moment assume that there is a use case for
such a thing, I'm wondering what is wrong with this solution from a
Git perspective???

    Ciprian.

    P.S.: It seems that indeed setup_git_directory_gently (or
something in the setup system) is kind of broken if I call it twice...
So I'm trying to solve the problem from another angle... It seems that
setup_paths is called only from git.c, builtin-receive-pack.c,
upload-pack.c and shell.c... Thus I'll just work-around the problem by
adding the bin path only when it is called from git.c (which it has
worked for almost a year...)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux