* Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?
From: Jan Wielemaker @ 2008-07-09 20:20 UTC (permalink / raw)
To: Git Mailing List
Hi,
After upgrade to SuSE 11.0 I was forced to update GIT (changed libcurl).
I did (with some trickery) a pull of the latest git and built it using
make prefix=/usr/local ..., to find out that /usr/local/bin/git-daemon
starts /usr/sbin/git-upload-pack.
After creating a symlink to /usr/local/bin/git-upload-pack all works fine
again, but I guess this is a mistake?
Cheers --- Jan
P.s. This is quite nasty to debug. I was forced to to run git-daemon
stand-alone (not xinetd) another port and run strace -f -p <pid>
to discover the cause of this problem. Even with --verbose, the
only error response was the client complaining on unexpected EOF.
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Junio C Hamano @ 2008-07-09 18:48 UTC (permalink / raw)
To: Sylvain Joyeux; +Cc: git
In-Reply-To: <20080709101330.GA3525@joyeux>
Sylvain Joyeux <sylvain.joyeux@dfki.de> writes:
> * changing the output format of git-submodules is not right either,
> because it would break existing tools which parses it at the moment.
On other two points I do agree with people who objected, but I do not
think this one is particularly bad. If 'git submodule status' is similar
in spirit to 'git status', then it is more important to make it useful for
human consumption than to keep the wording of the output set in stone.
^ permalink raw reply
* Re: git protocol specification
From: Johannes Schindelin @ 2008-07-09 18:45 UTC (permalink / raw)
To: Tom Werner; +Cc: Git Mailing List
In-Reply-To: <48750231.4020805@rubyisawesome.com>
Hi,
On Wed, 9 Jul 2008, Tom Werner wrote:
> I'm working on a flexible Erlang replacement for git-daemon and would
> like to know if there is a specification available for the protocol that
> git-upload-pack and git-receive-pack use.
How about Documentation/technical/pack-protocol.txt?
Ciao,
Dscho
^ permalink raw reply
* Re: Merging a foreign tree into a bare repository.
From: Johannes Schindelin @ 2008-07-09 18:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Dave Quigley, Git Mailing List
In-Reply-To: <m3lk0bdkyl.fsf@localhost.localdomain>
Hi,
On Wed, 9 Jul 2008, Jakub Narebski wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 8 Jul 2008, Dave Quigley wrote:
> >
> > > I tried to then merge them but you need a working directory to merge the
> > > changes which makes sense.
> >
> > Of course it does. Merging runs the risk of conflicts, and you need a
> > working directory for that.
> >
> > > How would one go about doing this with a bare repository?
> >
> > Very easy: clone it ("non-barely"), merge, and push back the results.
> >
> > You _need_ a working directory for the merge.
>
> Or, alternatively, you can tell git where you want to have working
> directory with '--work-tree' parameter to git wrapper,
... which runs the risk of you forgetting to specify the same working
directory all the time.
Which is the reason I did not suggest it.
> You can also set core.worktree configuration variable...
... effectively turning it into a non-bare repository. Was that the
question, how to turn a bare repository into a non-bare one?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/4] git-imap-send: Add support for SSL.
From: Junio C Hamano @ 2008-07-09 18:28 UTC (permalink / raw)
To: Rob Shearman; +Cc: git
In-Reply-To: <1096648c0807090502x772fdaa4o59bf9932dc364de5@mail.gmail.com>
"Rob Shearman" <robertshearman@gmail.com> writes:
> 2008/7/9 Junio C Hamano <gitster@pobox.com>:
> ...
>> Don't we also want to keep a vanilla configuration in the example, or is
>> imaps the norm and unencrypted imap is exception these days?
>
> Good point. I'll fix the documentation to use imap:// instead of
> imaps:// and not change the port number. However, I'm not sure the
> examples should be telling the user what they should do, but rather
> what they can do.
My comment was purely about losing the basic example by replacing it with
something more advanced. Nobody prevents you from having _more_ examples.
"You can do this, you can do that, also here is an example of how to use
SSL".
^ permalink raw reply
* Re: [PATCH] rerere: Separate libgit and builtin functions
From: Junio C Hamano @ 2008-07-09 18:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Stephan Beyer, git
In-Reply-To: <alpine.DEB.1.00.0807091356050.5277@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 9 Jul 2008, Stephan Beyer wrote:
>
>> Makefile | 2 +
>> builtin-rerere.c | 324 +++---------------------------------------
>> builtin-rerere.c => rerere.c | 133 +-----------------
>> rerere.h | 9 ++
>> 4 files changed, 32 insertions(+), 436 deletions(-)
>
> Heh, that sounds nice! Deleting way more lines than adding! :-)
>
>> copy builtin-rerere.c => rerere.c (66%)
>
> Oh, well :-)
We may want to fix this, though. I haven't verified by looking at the
diffstat summary code, but what I think is happening is that the bogus 436
is the result of counting the lines removed from builtin-rerere.c (that
lost many of its lines to rerere.c), and also counting the lines that were
remove from rerere.c pretending as if rerere.c had full contents of
builtin-rerere.c initially (i.e., counting the lines that were _not_ moved
to rerere.c).
It may just be the matter of subtracting the size of the preimage of
copied files (in this case, builtin-rerere.c that was used to initialize
rerere.c) from the grand total of deleted lines. I dunno.
^ permalink raw reply
* git protocol specification
From: Tom Werner @ 2008-07-09 18:23 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
I'm working on a flexible Erlang replacement for git-daemon and would
like to know if there is a specification available for the protocol that
git-upload-pack and git-receive-pack use. I've reverse engineered it but
have come across some points that seem inconsistent. Before I dig into
the C code in earnest I wanted to see if there's anything like spec
document for the system. Thanks!
--
Tom Preston-Werner
github.com/mojombo
[-- Attachment #2: pubsub.vcf --]
[-- Type: text/x-vcard, Size: 152 bytes --]
begin:vcard
fn:Tom Preston-Werner
n:Preston-Werner;Tom
email;internet:tom@mojombo.com
tel;cell:760.672.0832
x-mozilla-html:FALSE
version:2.1
end:vcard
^ permalink raw reply
* [PATCH/RFC] git-request-pull: replace call to deprecated peek-remote
From: Ramsay Jones @ 2008-07-08 23:32 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Junio C Hamano
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
I don't even recall how I noticed this ...
Only very lightly tested, but since git-peek-remote and
git-ls-remote are implemented in git.c as synonyms, it should
be quite safe ...
git-request-pull.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 068f5e0..073a314 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -26,7 +26,7 @@ merge_base=`git merge-base $baserev $headrev` ||
die "fatal: No commits in common between $base and $head"
url=$(get_remote_url "$url")
-branch=$(git peek-remote "$url" \
+branch=$(git ls-remote "$url" \
| sed -n -e "/^$headrev refs.heads./{
s/^.* refs.heads.//
p
--
1.5.6
^ permalink raw reply related
* [PATCH] t9113-*.sh: provide user feedback when test skipped
From: Ramsay Jones @ 2008-07-08 23:18 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Junio C Hamano
Currently this test simply exits without providing any
feedback at all. Tell user if the test is being skipped
and provide a hint as to how the test may be enabled.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
t/t9113-git-svn-dcommit-new-file.sh | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/t/t9113-git-svn-dcommit-new-file.sh b/t/t9113-git-svn-dcommit-new-file.sh
index 31c929b..8da8ce5 100755
--- a/t/t9113-git-svn-dcommit-new-file.sh
+++ b/t/t9113-git-svn-dcommit-new-file.sh
@@ -7,12 +7,18 @@
# I don't like the idea of taking a port and possibly leaving a
# daemon running on a users system if the test fails.
# Not all git users will need to interact with SVN.
-test -z "$SVNSERVE_PORT" && exit 0
test_description='git-svn dcommit new files over svn:// test'
. ./lib-git-svn.sh
+if test -z "$SVNSERVE_PORT"
+then
+ say 'skipping svnserve test. (set $SVNSERVE_PORT to enable)'
+ test_done
+ exit
+fi
+
start_svnserve () {
svnserve --listen-port $SVNSERVE_PORT \
--root "$rawsvnrepo" \
--
1.5.6
^ permalink raw reply related
* [PATCH] t9100-git-svn-basic.sh: Fix determination of utf-8 locale
From: Ramsay Jones @ 2008-07-08 22:59 UTC (permalink / raw)
To: GIT Mailing-list; +Cc: Junio C Hamano
When setting the GIT_SVN_LC_ALL variable, default to the $LANG
environment variable, when the $LC_ALL override is not set.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
It took some time before I noticed this because the message
"UTF-8 locale not set, ..." did not stand-out when flying past on
the console. After noticing it, however, it surprised me (then
irritated me) because I most definitely did have a UTF-8 locale
set ...
The two hunks which s/echo/say/ are not strictly part of the fix
and should perhaps be in a separate patch ... Dunno. (but it
certainly makes the message stand out more ;-)
t/t9100-git-svn-basic.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 242cdf0..3bc6164 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -4,9 +4,9 @@
#
test_description='git-svn basic tests'
-GIT_SVN_LC_ALL=$LC_ALL
+GIT_SVN_LC_ALL=${LC_ALL:-$LANG}
-case "$LC_ALL" in
+case "$GIT_SVN_LC_ALL" in
*.UTF-8)
have_utf8=t
;;
@@ -17,7 +17,7 @@ esac
. ./lib-git-svn.sh
-echo 'define NO_SVN_TESTS to skip git-svn tests'
+say 'define NO_SVN_TESTS to skip git-svn tests'
test_expect_success \
'initialize git-svn' '
@@ -183,7 +183,7 @@ then
git-svn set-tree HEAD"
unset LC_ALL
else
- echo "UTF-8 locale not set, test skipped ($GIT_SVN_LC_ALL)"
+ say "UTF-8 locale not set, test skipped ($GIT_SVN_LC_ALL)"
fi
name='test fetch functionality (svn => git) with alternate GIT_SVN_ID'
--
1.5.6
^ permalink raw reply related
* Re: "make test" works again (sort-of) on cygwin.
From: Ramsay Jones @ 2008-07-08 22:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: GIT Mailing-list, Junio C Hamano
In-Reply-To: <20080706231146.GE17659@steel.home>
Alex Riesen wrote:
> Ramsay Jones, Sat, Jul 05, 2008 22:09:31 +0200:
>> Alex Riesen wrote:
>>> Ramsay Jones, Thu, Jul 03, 2008 19:44:28 +0200:
>>>
>>>> Anyhow, the "sort-of" in the subject line, relates to the fact that
>>>> I am seeing some test failures. In particular, all tests in
>>>> t0004-unwritable.sh and tests 21->24 in t3700-add.sh. All of these
>>>> tests involve chmod/permissions ...
>>> Don't run "make test" as root (or "backup operator" on windows).
>>> OTOH, a windows machine is almost useless, unless you're a member of
>>> local administrators group (which includes "backup" permission).
>>>
>> Ah, yes... I am a "Computer administator" aren't I ;-) I totally forgot!
>>
>> Hmm, but is that really the reason for these failures? After all, (referring
>> to the example you snipped) the permissions are respected for creating
>> files in the directory, just not directories. Is the "root" user on
>> windows only selectively omnipotent?
>
> It is (it is the backup operators who can read open, even locked,
> files), but it is boringly hard to find when and where. You can try
> reading MSDN (or better don't, you'll live longer if you don't).
>
>
Yeah, I'm afraid I've had to serve that sentence (several times) in
the past; I'm still trying to figure out what my crime was... ;P
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH/RFC] Fix some warnings (on cygwin) to allow -Werror
From: Ramsay Jones @ 2008-07-08 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7vhcb3rfro.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> Junio C Hamano wrote:
>> ...
>>>> @@ -1718,7 +1720,8 @@ static int add_ref_tag(const char *path, const unsigned char *sha1, int flag, vo
>>>> static void prepare_pack(int window, int depth)
>>>> {
>>>> struct object_entry **delta_list;
>>>> - uint32_t i, n, nr_deltas;
>>>> + uint32_t i, nr_deltas;
>>>> + unsigned n;
>>> Hmm. Is this change necessary?
>> Yes, otherwise:
>>
>> builtin-pack-objects.c: In function `prepare_pack':
>> builtin-pack-objects.c:1760: warning: passing arg 2 of `find_deltas' from incompatible pointer type
>> make: *** [builtin-pack-objects.o] Error 1
>>
>> Note that ll_find_deltas() is #defined to find_deltas() in the #else arm
>> of #ifdef THREADED_DELTA_SEARCH, and find_deltas() takes an "unsigned *"
>
> Ah, I missed that. So it is not just warning squelch but is a bugfix in
> case unsigned and uint32_t are of different sizes.
>
Yes, but I didn't think about that when I "fixed" it ;-)
ATB,
Ramsay Jones
^ permalink raw reply
* Re: Merging a foreign tree into a bare repository.
From: Jakub Narebski @ 2008-07-09 17:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dave Quigley, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807090238561.5277@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 8 Jul 2008, Dave Quigley wrote:
>
> > I tried to then merge them but you need a working directory to merge the
> > changes which makes sense.
>
> Of course it does. Merging runs the risk of conflicts, and you need a
> working directory for that.
>
> > How would one go about doing this with a bare repository?
>
> Very easy: clone it ("non-barely"), merge, and push back the results.
>
> You _need_ a working directory for the merge.
Or, alternatively, you can tell git where you want to have working
directory with '--work-tree' parameter to git wrapper, for example
1451:jnareb@roke:/tmp/jnareb> git clone --bare test/ test-clone.git
Initialize test-clone.git
Initialized empty Git repository in /tmp/jnareb/test-clone.git/
(Hmmm... I hope the last message, which is unnecessary and I think
is just spillage from git-init, would vanish in builting git-clone)
1453:jnareb@roke:/tmp/jnareb/test-clone.git> ls
branches config description HEAD hooks info objects refs
1454:jnareb@roke:/tmp/jnareb/test-clone.git> cat config
[core]
repositoryformatversion = 0
filemode = true
bare = true
(It is bare repository)
1461:jnareb@roke:/tmp/jnareb/test-clone.git> git checkout
fatal: This operation must be run in a work tree
(You would get the same error with merge and with rebase)
1458:jnareb@roke:/tmp/jnareb/test-clone.git> git --work-tree=../test-workdir/ checkout
1459:jnareb@roke:/tmp/jnareb/test-clone.git> ls ../test-workdir/
foo
It works!
You can also set core.worktree configuration variable... although
I don't know what git would do if core.bare is true and core.worktree
is set.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git over rsync+ssh
From: Teemu Likonen @ 2008-07-09 17:17 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Michael J Gruber, git
In-Reply-To: <32541b130807090902q2cdc9fcbg6f685dcb96407644@mail.gmail.com>
Avery Pennarun wrote (2008-07-09 12:02 -0400):
> I don't know if this will help in your case, but if it will be only
> you pushing to this repository, one option is to simply create a bare
> push repository on your local machine, and then manually just
> rsync+ssh it to the remote machine from the command line as
> a so-called "push" operation.
Again, I don't know if this is helpful for Michael, but this "manual"
rsyncing can be done automatically via hooks/post-receive. Just like
Avery said, "git push" to a bare repository in a local machine and this
bare repo has post-receive hook which does "git update-server-info" and
the rsyncing (or "sitecopy --update" or similar).
^ permalink raw reply
* Re: Idea: "live branches"?
From: Johannes Schindelin @ 2008-07-09 17:00 UTC (permalink / raw)
To: Jan Rychter; +Cc: git
In-Reply-To: <m28wwbz8h7.fsf@tnuctip.rychter.com>
Hi,
On Wed, 9 Jul 2008, Jan Rychter wrote:
> Which brings me to my point. I think we need a system that can maintain
> "live branches". We already have impressive systems for dealing with
> patches and we have made the patch into a first-class citizen of our
> software development world. Now, instead of statically tracking commits
> and following a one-way development history, let's have live branches --
> branches that can change, causing code that depends on them to change.
>
> The way this would work is I would have one or two long-term development
> branches, and each of those would depend on a list of "live branches",
> managed by a tool similar to StGIT. I should be able to commit to either
> the main development branch, or to one of the "live branches", in which
> case I should be able to easily "resync" the main development branch (do
> a merge or a rebase, but I would prefer the tool to first remove old
> merge commits, so as not to clutter history).
It should be very easy to write a small shell script which expects some
config variable
branch.<currentBranchName>.liveBranches
which contains a list of (local) branches. It would then just look which
of those branches contains newer commits, finds the merges that pulled
those branches in, and redoes those merges (and the commits). It would
rely heavily on "git reset" and on an untampered-with merge message.
The main loop would look a little bit like this:
git rev-list --parents <first-merge-to-be-replaced>^ |
while read commit parent otherparents
do
case "$otherparents" in
'')
git cherry-pick $commit
;;
*)
case " $commit " in
" $mergestoberedone ")
;;
*)
message="$(git cat-file commit $commit |
sed '/^$/q')"
git merge -m "$message" $otherparents
;;
esac
done
# merge changes branches
No wizardry required.
> The tool should also let me pick a commit I've made and move it to one
> of the live branches easily (similar to stgit).
That is relatively simple, using "git checkout <branch> && git cherry-pick
<commit> && git checkout <formerBranch> && git resync-live-branches".
I strongly suggest writing that script, and seeing if it is useful for
you. If it is, just submit it and earn all the glory.
Hth,
Dscho
^ permalink raw reply
* Re: Idea: "live branches"?
From: Avery Pennarun @ 2008-07-09 16:48 UTC (permalink / raw)
To: Jan Rychter; +Cc: git
In-Reply-To: <m28wwbz8h7.fsf@tnuctip.rychter.com>
On 7/9/08, Jan Rychter <jan@rychter.com> wrote:
> The way this would work is I would have one or two long-term development
> branches, and each of those would depend on a list of "live branches",
> managed by a tool similar to StGIT. I should be able to commit to either
> the main development branch, or to one of the "live branches", in which
> case I should be able to easily "resync" the main development branch (do
> a merge or a rebase, but I would prefer the tool to first remove old
> merge commits, so as not to clutter history).
Hmm, git rebase already removes old merge commits. In my own
workflow, I tend to do repeated merges of the "live branch" into my
feature branches during development, then do a rebase occasionally to
clean up the patch set, especially right before merging it into
master. This seems pretty painless to me. What specific problem are
you having that prevents this from working?
Have fun,
Avery
^ permalink raw reply
* Re: Merging a foreign tree into a bare repository.
From: Alejandro Riveira @ 2008-07-09 14:25 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807090238561.5277@eeepc-johanness>
El Wed, 09 Jul 2008 02:40:52 +0200, Johannes Schindelin escribió:
>
> Hth,
> Dscho "who wonders what No Such Agency does with Git..."
SELinux development ?? :P
^ permalink raw reply
* Idea: "live branches"?
From: Jan Rychter @ 2008-07-09 9:56 UTC (permalink / raw)
To: git
I've been trying out a number of DVCS tools recently and finally found
that git is the best fit for me. There is one thing I found missing,
though.
The problem is that there are usually two distinct concepts:
-- topic branches, representing longer-term ongoing development in a
certain direction, large-scale features, etc,
-- patches that represent complete functionality, to be committed
upstream, but continuously improved.
My local repositories are usually a combination of both. I will often
have a number of feature patches that I don't want to push upstream just
yet. These patches change often. My topic branches will all want to use
them, in their latest form/revision. This is not a workflow that you can
easily represent with any of today's DVCS tools. One can do this with
careful cherry-picking and merging, but it is a lot of manual work and
clutters up history with lots of merge commits.
StGIT is *almost* there. It lets you manage a pile of patches, modify
them, apply them selectively, as well as update the mainstream
repository and reapply local patches. It fails in two ways: 1) when you
want to reuse the same patches on multiple branches. One-way migration
is doable (not pleasant, but doable), but if you modify a patch in one
of your branches, your other branches which use the same patch will not
see the change. And 2) StGIT patches are simple by design, and you can't
have internal commit history within a patch, which is a problem for
larger features.
Which brings me to my point. I think we need a system that can maintain
"live branches". We already have impressive systems for dealing with
patches and we have made the patch into a first-class citizen of our
software development world. Now, instead of statically tracking commits
and following a one-way development history, let's have live branches --
branches that can change, causing code that depends on them to change.
The way this would work is I would have one or two long-term development
branches, and each of those would depend on a list of "live branches",
managed by a tool similar to StGIT. I should be able to commit to either
the main development branch, or to one of the "live branches", in which
case I should be able to easily "resync" the main development branch (do
a merge or a rebase, but I would prefer the tool to first remove old
merge commits, so as not to clutter history).
The tool should also let me pick a commit I've made and move it to one
of the live branches easily (similar to stgit).
Does this make sense, or am I missing something very obvious?
--J.
PS: I am obviously aware that this is something which is suitable for
local development work only.
^ permalink raw reply
* Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Petr Baudis @ 2008-07-09 16:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Lea Wiemann
In-Reply-To: <200807031824.55958.jnareb@gmail.com>
Hi!
On Thu, Jul 03, 2008 at 06:24:53PM +0200, Jakub Narebski wrote:
> There are also a few things which I'd like some comments about:
>
> * Do config_val_to_bool and config_val_to_int should be exported
> by default?
Yes with the current API, not with object API (see below). But if
exported by default, there should be definitely a git_ prefix.
> * Should config_val_to_bool and config_val_to_int throw error or
> just return 'undef' on invalid values? One can check if variable
> is defined using "exists($config_hash{'varname'})".
I think that it's more reasonable to throw an error here (as long as
you don't throw an error on undef argument). This particular case is
clearly a misconfiguration by the user and you rarely need to handle
this more gracefully, I believe.
> * How config_val_to_bool etc. should be named? Perhaps just
> config_to_bool, like in gitweb?
What about Git::Config::bool()? ;-) (See below.)
> * Is "return wantarray ? %config : \%config;" DWIM-mery good style?
> I am _not_ a Perl hacker...
I maybe wouldn't be as liberal myself, but I can't tell if it's a bad
style either.
> * Should ->get_config() use ->command_output_pipe, or simpler
> ->command() method, reading whole config into array?
You have the code written already, I'd stick with it.
> * What should ->get_config() have as an optional parameter:
> PREFIX (/^$prefix/o), or simply SECTION (/^(?:$section)\./o)?
Do we even _need_ a parameter like that? I don't understand what is
this interface trying to address.
> * Should we perltie hash?
I agree with Lea that we should actually bless it. :-) Returning a
Git::Config object provides a more flexible interface, and you can also
do $repo->get_config()->bool('key') which is quite more elegant way than
the val_ functions, I think. Also, having accessors for special types
lets you return undef when the type really isn't defined, instead of
e.g. true with current config_val_bool, which is clearly bogus and
requires complicated code on the user side.
> As this is an RFC I have not checked if manpage (generated from
> embedded POD documentation) renders correctly.
By the way, unless you know already, you can do that trivially by
issuing:
perldoc perl/Git.pm
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: git over rsync+ssh
From: Avery Pennarun @ 2008-07-09 16:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g52gbg$si9$1@ger.gmane.org>
On 7/9/08, Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
> I want to put a git repo on a server where I have ssh access but failed to
> compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
> prerequisite zlib failed, probably due to a botched build environment).
>
> As far as I can see my only option for a private repo is using rsync over
> ssh.
>
> Alas, the rsync:// transport of git seems to imply an rsync daemon
> connection.
>
> How can I specify rsync over ssh as the git transport?
I don't know if this will help in your case, but if it will be only
you pushing to this repository, one option is to simply create a bare
push repository on your local machine, and then manually just
rsync+ssh it to the remote machine from the command line as a
so-called "push" operation.
You would then make the repo available to others over http or
something, which presumably you have available.
Would that work?
Have fun,
Avery
^ permalink raw reply
* Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Petr Baudis @ 2008-07-09 15:23 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Jakub Narebski, git
In-Reply-To: <48726D5C.9080801@gmail.com>
On Mon, Jul 07, 2008 at 09:24:12PM +0200, Lea Wiemann wrote:
> Jakub Narebski wrote:
> > Git::Repo / Git::Config could use methods / subroutines from Git.pm;
>
> I don't think that's possible, since Git.pm has a pretty long-running
> (and complicated) instantiation method, whereas Git::Repo has (and must
> have) instantaneous instantiation (without system calls).
There can be an alternative instantiation method that is faster.
> Also, Git.pm is so strange (design-wise) that I'm not very happy with
> depending on it as it is. I'll write more about that later though.
I'm curious to hear about your reservations to Git.pm design when you
get to writing up something. But I think you should have _very_ good
reasons for introducing a completely separate alternative API and show
convincingly why the current one cannot be extended and build upon,
since going that way is bound to get quite messy. Please avoid the NIH
syndrome and don't reinvent the wheel needlessly. ;-)
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: [PATCH 2/4] git-imap-send: Add support for SSL.
From: Josh Triplett @ 2008-07-09 15:14 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <1215555496-21335-2-git-send-email-robertshearman@gmail.com>
On Tue, 2008-07-08 at 23:18 +0100, Robert Shearman wrote:
> --- a/Documentation/git-imap-send.txt
> +++ b/Documentation/git-imap-send.txt
> @@ -37,10 +37,11 @@ configuration file (shown with examples):
> Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
>
> [imap]
> - Host = imap.server.com
> + Host = imaps://imap.example.com
> User = bob
> Pass = pwd
> - Port = 143
> + Port = 993
> + sslverify = false
[...]
> @@ -1280,6 +1411,8 @@ git_imap_config(const char *key, const char *val, void *cb)
> server.port = git_config_int( key, val );
> else if (!strcmp( "tunnel", key ))
> server.tunnel = xstrdup( val );
> + else if (!strcmp( "ssl_verify", key ))
> + server.ssl_verify = git_config_bool( key, val );
The example and the code disagree on the name of the
sslverify/ssl_verify option. Also, ssl_verify needs explanation.
- Josh Triplett
^ permalink raw reply
* Re: git over rsync+ssh
From: Mike Ralphson @ 2008-07-09 15:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g52gbg$si9$1@ger.gmane.org>
2008/7/9 Michael J Gruber <michaeljgruber+gmane@fastmail.fm>:
> I want to put a git repo on a server where I have ssh access but failed to
> compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
> prerequisite zlib failed, probably due to a botched build environment).
I can send you a binary to try if you'd like. It would be compiled on
AIX 5.3 but I have to jump through hoops on several non-identically
set-up servers here, so one might work for you.
# ldd /usr/local/bin/git
/usr/local/bin/git needs:
/usr/lib/libc.a(shr.o)
/usr/lib/libz.a(libz.so.1)
/usr/lib/libiconv.a(shr4.o)
/unix
/usr/lib/libcrypt.a(shr.o)
# ar -t /usr/lib/libz.a
libz.so.1
shr.o
Alternatively I can send you what gets installed from zlib-devel.rpm
[1] which you might be able to install in your account's home
directory, and then ./configure --with-zlib=PATH ; gmake might work
for you.
> As far as I can see my only option for a private repo is using rsync over
> ssh.
>
> ... [snipped the bits I know not]
>
> Alternatively, can I maybe compile the bits that git over ssh needs on the
> server side without zlib?
I don't think any git is going to get very far without zlib, as it
won't understand (be able to verify) the object/pack format at all. I
might be wrong about that though.
Mike
[1] ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/zlib/zlib-1.2.3-4.aix5.2.ppc.rpm
^ permalink raw reply
* git over rsync+ssh
From: Michael J Gruber @ 2008-07-09 14:01 UTC (permalink / raw)
To: git
I want to put a git repo on a server where I have ssh access but failed
to compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
prerequisite zlib failed, probably due to a botched build environment).
As far as I can see my only option for a private repo is using rsync
over ssh.
Alas, the rsync:// transport of git seems to imply an rsync daemon
connection.
How can I specify rsync over ssh as the git transport?
Alternatively, can I maybe compile the bits that git over ssh needs on
the server side without zlib?
Michael
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-09 13:54 UTC (permalink / raw)
To: Sylvain Joyeux; +Cc: git
In-Reply-To: <20080709134629.GA3848@joyeux>
Hi,
On Wed, 9 Jul 2008, Sylvain Joyeux wrote:
> [Sylvain quoted somebody, but found it funny to let the reader guess]
>
> > On a related note, the long commit name has been a constant nuisance
> > for me. A short commit name is perfectly enough, methinks.
>
> I also think so. The commit ID is completely useless for humans.
> Nonetheless, that would change the git-submodules output which
> (according to someone-that-I-dont-remember) would be a Bad Thing(tm).
Is git-submodule supposed to be plumbing? I don't think so.
Ciao,
Dscho
^ 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