* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Johannes Schindelin @ 2008-06-24 14:55 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080624144254.GG5528@leksak.fem-net>
Hi,
On Tue, 24 Jun 2008, Stephan Beyer wrote:
> > So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
>
> Are they intentionally undocumented to not raise confusion?
Umm. Which part of "TOY" is unclear?
Ciao,
Dscho
^ permalink raw reply
* Re: git-fetch remote tag to local branch fails
From: Michael J Gruber @ 2008-06-24 14:57 UTC (permalink / raw)
To: git
In-Reply-To: <33f4f4d70806240701o1c00cef2g688a188970964b0f@mail.gmail.com>
Klas Lindberg venit, vidit, dixit 24.06.2008 16:01:
> Hello
>
>> git tag -l
> foo_tag
> test_tag
>
>> git branch -a
>>
>
> At this point, I can create the branch "b" from "foo_tag", so the
> fetch did get me a remote tag. It just didn't update a local branch
> with the contents (or create a new one).
>
> Something that also confuses me is that if branch "b" already exists, then
>
>> git-pull bogustree refs/tags/foo_tag:refs/heads/b
>
> actually does update branch "b". I find the behaviour quite inconsistent.
You tell git to fetch everything up to the tag you specify, to store
those refs into branch b, and then to merge into the current branch.
This is what git did (assuming you see the merge in the current branch;
if it's b then it has been fast forwarded already).
> Unfortunately it isn't a solution for me to fetch tags and then create
> branches from the tags. I need to be able to update existing branches,
> and I have to do that without first making such a branch the current
> branch.
If I try what you described (using git 1.5.6) in a fresh repo (with one
empty commit) I get:
git fetch ../fromrepo refs/tags/testtag:refs/heads/newbranch
warning: no common commits
remote: Counting objects: 18, done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 18 (delta 9), reused 0 (delta 0)
Unpacking objects: 100% (18/18), done.
From ../fromrepo
* [new branch] testtag -> newbranch
* [new tag] testtag -> testtag
I see a new branch, disconnected from master (no common commits), and a
new tag pointing to the head of newbranch. All is well here. Maybe you
can set-up a minimal example or share a repo which exposes your problem?
Michael
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Erez Zilber @ 2008-06-24 14:45 UTC (permalink / raw)
To: Robert Haines; +Cc: Matthias Kestenholz, git
In-Reply-To: <BC8F2A2A-9817-401B-BAC3-F36ED42976E5@manchester.ac.uk>
On Tue, Jun 24, 2008 at 5:08 PM, Robert Haines <rhaines@manchester.ac.uk> wrote:
>>> So your clone address for git:// is wrong, you don't need the /pub/git:
>>> git clone git://erez.zilber@kites/erez.zilber/my_test.git
>>> As you've moved the root of the filesystem as far as git-daemon is
>>> concerned
>>> to /pub/git with the --base-path option.
>>
>> I understand. However, when I try to run it according to your suggestion:
>>
>> [root@kd001 t]# git clone git://erez.zilber@kites/erez.zilber/my_test.git
>> Initialized empty Git repository in
>> /home/erez.zilber/work/tmp/t/my_test/.git/
>> fatal: Unable to look up erez.zilber@kites (port 9418) (Name or
>> service not known)
>> fetch-pack from 'git://erez.zilber@kites/erez.zilber/my_test.git' failed.
>
> That error is saying that the name of the service is wrong, so you're right
> to do it without the "erez.zilber@" bit.
>
>> I also tried to run it without "erez.zilber@":
>>
>> [root@kd001 t]# git clone git://kites/erez.zilber/my_test.git
>> Initialized empty Git repository in
>> /home/erez.zilber/work/tmp/t/my_test/.git/
>> kites[0: 172.16.1.11]: errno=Connection refused
>> fatal: unable to connect a socket (Connection refused)
>> fetch-pack from 'git://kites/erez.zilber/my_test.git' failed.
>
> This looks like that either there is nothing listening (if you're running
> though xinetd have you restarted it? And have you added the right bits to
> /etc/services?) or there's a firewall in the way... git defaults to 9418 so
> check that it's open.
The problem was that it listened to requests coming from the local
machine. Now (after fixing that), everything seems to work. Thanks for
the help.
BTW - I'm currently running git-daemon in the following way:
sudo git-daemon --base-path=/pub/git/ --export-all
Is there any advantage to run it through xinetd? How do you run it?
Thanks,
Erez
^ permalink raw reply
* Re: [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Stephan Beyer @ 2008-06-24 14:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0806241515460.9925@racer>
Hi,
> So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
Are they intentionally undocumented to not raise confusion?
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: git-fetch remote tag to local branch fails
From: Santi Béjar @ 2008-06-24 14:27 UTC (permalink / raw)
To: Klas Lindberg; +Cc: git
In-Reply-To: <33f4f4d70806240701o1c00cef2g688a188970964b0f@mail.gmail.com>
On Tue, Jun 24, 2008 at 16:01, Klas Lindberg <klas.lindberg@gmail.com> wrote:
> Hello
>
>> git tag -l
> foo_tag
> test_tag
>>
>
>> git branch -a
>>
empty?
>
> At this point, I can create the branch "b" from "foo_tag", so the
> fetch did get me a remote tag. It just didn't update a local branch
> with the contents (or create a new one).
>
> Something that also confuses me is that if branch "b" already exists, then
>
>> git-pull bogustree refs/tags/foo_tag:refs/heads/b
>
> actually does update branch "b". I find the behaviour quite inconsistent.
You asked explicitly to update branch b with :refs/heads/b.
>
> Unfortunately it isn't a solution for me to fetch tags and then create
> branches from the tags. I need to be able to update existing branches,
> and I have to do that without first making such a branch the current
> branch.
>
If you have to update existing branches from remote branches you can:
git fetch <remote> refs/heads/<remotebranch>:refs/heads/<localbranch>
But normally you have some remote tracking branches, such as how the
"origin" remote repository is configured.
Updating from remote tags is not normal, since tags are not supposed to change.
Can you explain why you have to do it this way? Or the whole workflow?
Santi
P.D.: Please, do not toppost.
^ permalink raw reply
* [TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Johannes Schindelin @ 2008-06-24 14:17 UTC (permalink / raw)
To: git
When you look for a fix instead of a regression, it can be quite hard
to twist your brain into choosing the correct bisect command between
'git bisect bad' and 'git bisect good'.
So introduce the commands 'git bisect fixed' and 'git bisect unfixed'.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
When Randal talked about this on IRC, I laughed. But I just had
the case where it took me _three_ attempts at a bisection, only
to give up and write this patchlet.
May it help someone else, too.
git-bisect.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 8b11107..d833e21 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -501,6 +501,8 @@ case "$#" in
*)
cmd="$1"
shift
+ test $cmd = fixed && cmd=bad
+ test $cmd = unfixed && cmd=good
case "$cmd" in
help)
git bisect -h ;;
--
1.5.6.127.g3fb9f
^ permalink raw reply related
* Re: git-clone works with ssh but not with http/https/git
From: Erez Zilber @ 2008-06-24 14:16 UTC (permalink / raw)
To: Anton Gladkov
Cc: Jakub Narebski, Johannes Schindelin, Matthias Kestenholz,
git@vger.kernel.org
In-Reply-To: <20080624135429.GA6905@atn.sw.ru>
On Tue, Jun 24, 2008 at 4:54 PM, Anton Gladkov <agladkov@parallels.com> wrote:
> On Tue, Jun 24, 2008 at 05:42:14PM +0400, Erez Zilber wrote:
>> I guess that the problem is that no proper mapping exists. That's why
>> I see the following in /var/log/httpd/error_log:
>>
>> [Tue Jun 24 16:31:52 2008] [error] [client 172.16.0.7] File does not
>> exist: /var/www/html/pub
>>
>> What do I need to add in /etc/httpd/conf.d/ in order to set the
>> mapping to /pub/git instead of /var/www/html/pub ? Is there an example
>> that shows how to map?
>
> IMO the simplest way is to create a symlink 'pub' in /var/www/html directory
> pointing to /pub and to add 'Options FollowSymLinks' to <Directory /> in httpd.conf.
Adding the symlink solved the cloning with http problem.
Thanks,
Erez
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Matthieu Moy @ 2008-06-24 14:05 UTC (permalink / raw)
To: Erez Zilber; +Cc: Jakub Narebski, Johannes Schindelin, Matthias Kestenholz, git
In-Reply-To: <ce513bcc0806240642g56ca5450t4edd24fd88ce79c7@mail.gmail.com>
"Erez Zilber" <erezzi.list@gmail.com> writes:
> I guess that the problem is that no proper mapping exists. That's why
> I see the following in /var/log/httpd/error_log:
>
> [Tue Jun 24 16:31:52 2008] [error] [client 172.16.0.7] File does not
> exist: /var/www/html/pub
>
> What do I need to add in /etc/httpd/conf.d/ in order to set the
> mapping to /pub/git instead of /var/www/html/pub ? Is there an example
> that shows how to map?
Try to access the repository from a web browser first. If you don't
have directory listing enabled, opening a file like HEAD should work.
--
Matthieu
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Robert Haines @ 2008-06-24 14:08 UTC (permalink / raw)
To: Erez Zilber; +Cc: Matthias Kestenholz, git
In-Reply-To: <ce513bcc0806240653i45044297t3b963940c5b3daf0@mail.gmail.com>
>> So your clone address for git:// is wrong, you don't need the /pub/
>> git:
>> git clone git://erez.zilber@kites/erez.zilber/my_test.git
>> As you've moved the root of the filesystem as far as git-daemon is
>> concerned
>> to /pub/git with the --base-path option.
>
> I understand. However, when I try to run it according to your
> suggestion:
>
> [root@kd001 t]# git clone git://erez.zilber@kites/erez.zilber/
> my_test.git
> Initialized empty Git repository in /home/erez.zilber/work/tmp/t/
> my_test/.git/
> fatal: Unable to look up erez.zilber@kites (port 9418) (Name or
> service not known)
> fetch-pack from 'git://erez.zilber@kites/erez.zilber/my_test.git'
> failed.
That error is saying that the name of the service is wrong, so you're
right to do it without the "erez.zilber@" bit.
> I also tried to run it without "erez.zilber@":
>
> [root@kd001 t]# git clone git://kites/erez.zilber/my_test.git
> Initialized empty Git repository in /home/erez.zilber/work/tmp/t/
> my_test/.git/
> kites[0: 172.16.1.11]: errno=Connection refused
> fatal: unable to connect a socket (Connection refused)
> fetch-pack from 'git://kites/erez.zilber/my_test.git' failed.
This looks like that either there is nothing listening (if you're
running though xinetd have you restarted it? And have you added the
right bits to /etc/services?) or there's a firewall in the way... git
defaults to 9418 so check that it's open.
> Is there any log file on the server that can help me trace this
> problem (something like /var/log/httpd/error_log but for the git
> protocol)?
on my machine (running via xinetd) it goes straight into /var/log/
messages. A grep -i git on that file should produce something.
Cheers,
Rob
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Matthias Kestenholz @ 2008-06-24 14:02 UTC (permalink / raw)
To: Anton Gladkov
Cc: Erez Zilber, Jakub Narebski, Johannes Schindelin,
git@vger.kernel.org
In-Reply-To: <20080624135911.GB6905@atn.sw.ru>
On Tue, 2008-06-24 at 17:59 +0400, Anton Gladkov wrote:
> On Tue, Jun 24, 2008 at 05:54:29PM +0400, Anton Gladkov wrote:
> > On Tue, Jun 24, 2008 at 05:42:14PM +0400, Erez Zilber wrote:
> > > I guess that the problem is that no proper mapping exists. That's why
> > > I see the following in /var/log/httpd/error_log:
> > >
> > > [Tue Jun 24 16:31:52 2008] [error] [client 172.16.0.7] File does not
> > > exist: /var/www/html/pub
> > >
> > > What do I need to add in /etc/httpd/conf.d/ in order to set the
> > > mapping to /pub/git instead of /var/www/html/pub ? Is there an example
> > > that shows how to map?
> >
> > IMO the simplest way is to create a symlink 'pub' in /var/www/html directory
> > pointing to /pub and to add 'Options FollowSymLinks' to <Directory /> in httpd.conf.
>
> But, I think it will not help you.
> AFAIK you need a gitweb.
>
To be able to use the HTTP git transport? No. If you use the HTTP
transport to clone a repository, gitweb is not used in any way.
--
http://spinlock.ch/blog/
^ permalink raw reply
* Re: git-fetch remote tag to local branch fails
From: Klas Lindberg @ 2008-06-24 14:01 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <8aa486160806240638o221b01d2i2f46cc8f0f3760a3@mail.gmail.com>
Hello
> git tag -l
foo_tag
test_tag
>
> git branch -a
>
At this point, I can create the branch "b" from "foo_tag", so the
fetch did get me a remote tag. It just didn't update a local branch
with the contents (or create a new one).
Something that also confuses me is that if branch "b" already exists, then
> git-pull bogustree refs/tags/foo_tag:refs/heads/b
actually does update branch "b". I find the behaviour quite inconsistent.
Unfortunately it isn't a solution for me to fetch tags and then create
branches from the tags. I need to be able to update existing branches,
and I have to do that without first making such a branch the current
branch.
Any suggestions?
/Klas
On Tue, Jun 24, 2008 at 3:38 PM, Santi Béjar <sbejar@gmail.com> wrote:
> On Tue, Jun 24, 2008 at 14:17, Klas Lindberg <klas.lindberg@gmail.com> wrote:
>> Hi
>>
>> I have a repository "bogustree" that contains tags "test_tag" and
>> "foo_tag" (both on the same branch, with "test_tag" pointing to an
>> older commit).
>> I also have repository "R", which contains "test_tag" from "bogustree"
>> and a branch "b" created from "test_tag". The active branch in R is
>> "master".
>>
>> Now I want to do the following from R:
>>
>> git-fetch bogustree refs/tags/foo_tag:refs/heads/b
>>
>> but this fails with the message given below. The interesting part is
>> that git-fetch tries to write a "non-commit object" and indeed I have
>> no idea what this thing is (the commit pointed to by "foo_tag" has
>> commit ID cab0a25388f1884a1ab16bd0d66f877c0b36f1d5).
>
> non-commit object is an object that is not a commit, like a tag, a
> blob or a tree, and you are trying to write a tag in refs/heads/. Only
> commits objects (no tags) are allowed in refs/heads/.
>
>
>> Another
>> interesting detail is that the command fails and then continues
>> anyway. That seems wrong in itself.
>>
>> # remote: Counting objects: 6, done.
>> # remote: Compressing objects: 100% (2/2), done.
>> # remote: Total 4 (delta 0), reused 0 (delta 0)
>> # Unpacking objects: 100% (4/4), done.
>> # error: Trying to write non-commit object
>> 5f61233bc5dad0f3e25ecea65457f5bb528174d2 to branch refs/heads/B
>> # From /home/qliklas/bogustree/b/b
>> # 72f0622..5f61233 foo_tag -> b
>> # From /home/qliklas/bogustree/b/b
>> # * [new tag] foo_tag -> foo_tag
>> # * [new tag] test_tag -> test_tag
>
> Are you sure it is written as a branch? What is the output of "git tag
> -l" and "git branch -a"?
>
>
>>
>> Why can't I fetch like this? The manual page for git-fetch says that
>>
>> <refspec>
>> The canonical format of a <refspec> parameter is +?<src>:<dst>;
>> that is, an optional plus +, followed by the source ref,
>> followed by a colon :, followed by the destination ref.
>>
>> The remote ref that matches <src> is fetched, and if <dst> is
>> not empty string, the local ref that matches it is fast
>> forwarded using <src>. Again, if the optional plus + is used,
>> the local ref is updated even if it does not result in a fast
>> forward update.
>>
>> so I think it should be OK?
>
> as long as <src> are commit objects.
>
> Santi
>
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Anton Gladkov @ 2008-06-24 13:59 UTC (permalink / raw)
To: Erez Zilber
Cc: Jakub Narebski, Johannes Schindelin, Matthias Kestenholz,
git@vger.kernel.org
In-Reply-To: <20080624135429.GA6905@atn.sw.ru>
On Tue, Jun 24, 2008 at 05:54:29PM +0400, Anton Gladkov wrote:
> On Tue, Jun 24, 2008 at 05:42:14PM +0400, Erez Zilber wrote:
> > I guess that the problem is that no proper mapping exists. That's why
> > I see the following in /var/log/httpd/error_log:
> >
> > [Tue Jun 24 16:31:52 2008] [error] [client 172.16.0.7] File does not
> > exist: /var/www/html/pub
> >
> > What do I need to add in /etc/httpd/conf.d/ in order to set the
> > mapping to /pub/git instead of /var/www/html/pub ? Is there an example
> > that shows how to map?
>
> IMO the simplest way is to create a symlink 'pub' in /var/www/html directory
> pointing to /pub and to add 'Options FollowSymLinks' to <Directory /> in httpd.conf.
But, I think it will not help you.
AFAIK you need a gitweb.
--
Best regards,
Anton
mailto:agladkov@parallels.com
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Anton Gladkov @ 2008-06-24 13:54 UTC (permalink / raw)
To: Erez Zilber
Cc: Jakub Narebski, Johannes Schindelin, Matthias Kestenholz,
git@vger.kernel.org
In-Reply-To: <ce513bcc0806240642g56ca5450t4edd24fd88ce79c7@mail.gmail.com>
On Tue, Jun 24, 2008 at 05:42:14PM +0400, Erez Zilber wrote:
> I guess that the problem is that no proper mapping exists. That's why
> I see the following in /var/log/httpd/error_log:
>
> [Tue Jun 24 16:31:52 2008] [error] [client 172.16.0.7] File does not
> exist: /var/www/html/pub
>
> What do I need to add in /etc/httpd/conf.d/ in order to set the
> mapping to /pub/git instead of /var/www/html/pub ? Is there an example
> that shows how to map?
IMO the simplest way is to create a symlink 'pub' in /var/www/html directory
pointing to /pub and to add 'Options FollowSymLinks' to <Directory /> in httpd.conf.
--
Best regards,
Anton
mailto:agladkov@parallels.com
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Erez Zilber @ 2008-06-24 13:53 UTC (permalink / raw)
To: Robert Haines; +Cc: Matthias Kestenholz, git
In-Reply-To: <A3460448-8007-4E02-AC20-85C1A8C85786@manchester.ac.uk>
On Tue, Jun 24, 2008 at 3:35 PM, Robert Haines <rhaines@manchester.ac.uk> wrote:
>> I ran git-daemon on the server side like this:
>>
>> sudo git-daemon --base-path=/pub/git/ --export-all --listen=kites
>
> So your clone address for git:// is wrong, you don't need the /pub/git:
> git clone git://erez.zilber@kites/erez.zilber/my_test.git
> As you've moved the root of the filesystem as far as git-daemon is concerned
> to /pub/git with the --base-path option.
I understand. However, when I try to run it according to your suggestion:
[root@kd001 t]# git clone git://erez.zilber@kites/erez.zilber/my_test.git
Initialized empty Git repository in /home/erez.zilber/work/tmp/t/my_test/.git/
fatal: Unable to look up erez.zilber@kites (port 9418) (Name or
service not known)
fetch-pack from 'git://erez.zilber@kites/erez.zilber/my_test.git' failed.
I also tried to run it without "erez.zilber@":
[root@kd001 t]# git clone git://kites/erez.zilber/my_test.git
Initialized empty Git repository in /home/erez.zilber/work/tmp/t/my_test/.git/
kites[0: 172.16.1.11]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
fetch-pack from 'git://kites/erez.zilber/my_test.git' failed.
Is there any log file on the server that can help me trace this
problem (something like /var/log/httpd/error_log but for the git
protocol)?
Thanks,
Erez
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Erez Zilber @ 2008-06-24 13:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, Matthias Kestenholz, git
In-Reply-To: <m3abhbkoe2.fsf@localhost.localdomain>
On Tue, Jun 24, 2008 at 3:25 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Erez Zilber" <erezzi.list@gmail.com> writes:
>
>> I think that I'm using the right repository for git-clone because it's
>> the same path that I used for git push:
>>
>> [root@kd001 my_test.git]# git-push --all
>> ssh://erez.zilber@kites/pub/git/erez.zilber/my_test.git
>
> [...]
>> looks like git-update-server-info did some work (added the refs file).
>>
>> Back to the client:
>>
>> [root@kd001 t]# git-clone http://kites/pub/git/erez.zilber/my_test.git
>> Initialized empty Git repository in /home/erez.zilber/work/tmp/t/my_test/.git/
>> Cannot get remote repository information.
>> Perhaps git-update-server-info needs to be run there?
>>
>> The path is the same path that was used for pushing the repository.
>> What did I miss here?
>
> First, obvious question: do you have web server enabled?
>
Yes
> Second, less obvious: how this server maps pathname information from
> URL into path in the filesystem?
I guess that the problem is that no proper mapping exists. That's why
I see the following in /var/log/httpd/error_log:
[Tue Jun 24 16:31:52 2008] [error] [client 172.16.0.7] File does not
exist: /var/www/html/pub
What do I need to add in /etc/httpd/conf.d/ in order to set the
mapping to /pub/git instead of /var/www/html/pub ? Is there an example
that shows how to map?
Thanks,
Erez
^ permalink raw reply
* Re: git-fetch remote tag to local branch fails
From: Santi Béjar @ 2008-06-24 13:38 UTC (permalink / raw)
To: Klas Lindberg; +Cc: git
In-Reply-To: <33f4f4d70806240517h5e3ae420h263dd0c2d6bae459@mail.gmail.com>
On Tue, Jun 24, 2008 at 14:17, Klas Lindberg <klas.lindberg@gmail.com> wrote:
> Hi
>
> I have a repository "bogustree" that contains tags "test_tag" and
> "foo_tag" (both on the same branch, with "test_tag" pointing to an
> older commit).
> I also have repository "R", which contains "test_tag" from "bogustree"
> and a branch "b" created from "test_tag". The active branch in R is
> "master".
>
> Now I want to do the following from R:
>
> git-fetch bogustree refs/tags/foo_tag:refs/heads/b
>
> but this fails with the message given below. The interesting part is
> that git-fetch tries to write a "non-commit object" and indeed I have
> no idea what this thing is (the commit pointed to by "foo_tag" has
> commit ID cab0a25388f1884a1ab16bd0d66f877c0b36f1d5).
non-commit object is an object that is not a commit, like a tag, a
blob or a tree, and you are trying to write a tag in refs/heads/. Only
commits objects (no tags) are allowed in refs/heads/.
> Another
> interesting detail is that the command fails and then continues
> anyway. That seems wrong in itself.
>
> # remote: Counting objects: 6, done.
> # remote: Compressing objects: 100% (2/2), done.
> # remote: Total 4 (delta 0), reused 0 (delta 0)
> # Unpacking objects: 100% (4/4), done.
> # error: Trying to write non-commit object
> 5f61233bc5dad0f3e25ecea65457f5bb528174d2 to branch refs/heads/B
> # From /home/qliklas/bogustree/b/b
> # 72f0622..5f61233 foo_tag -> b
> # From /home/qliklas/bogustree/b/b
> # * [new tag] foo_tag -> foo_tag
> # * [new tag] test_tag -> test_tag
Are you sure it is written as a branch? What is the output of "git tag
-l" and "git branch -a"?
>
> Why can't I fetch like this? The manual page for git-fetch says that
>
> <refspec>
> The canonical format of a <refspec> parameter is +?<src>:<dst>;
> that is, an optional plus +, followed by the source ref,
> followed by a colon :, followed by the destination ref.
>
> The remote ref that matches <src> is fetched, and if <dst> is
> not empty string, the local ref that matches it is fast
> forwarded using <src>. Again, if the optional plus + is used,
> the local ref is updated even if it does not result in a fast
> forward update.
>
> so I think it should be OK?
as long as <src> are commit objects.
Santi
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Theodore Tso @ 2008-06-24 13:13 UTC (permalink / raw)
To: David Jeske; +Cc: Fedor Sergeev, git
In-Reply-To: <e80d075a0806240324j79f872d3t1db9dfb87dc2d37c@mail.gmail.com>
On Tue, Jun 24, 2008 at 03:24:00AM -0700, David Jeske wrote:
> Odd. I've never been a gatekeeper. I'm just a developer who has burned
> himself enough times that I want a tool (i.e. source control) to help
> prevent me from ever destroying anything I create.
It sounds like the main problem is that you need to learn more about
how to use the your tools. If you use the tools right, the number of
times that you you'll accidentally overwrite a branch pointer is quite
rare; and generally you notice right away; the default GC period of 30
days is a L-O-N-G time, and in practice its more than enough time for
someone to notice that they screwed up.
So a couple of tips
1) "git reflog show <branch name>" is a great way to only look at
changes to a particular branch. ("git log -g" or "git reflog show"
defaults to showing the reflog for HEAD)
2) A number of accidents with "git rebase" happen because people
forget which branch they are on. So having your command line prompt
tell you which branch you are on is really helpful. Google "git
prompt shell" for some examples of how to do this.
I do something like this:
function __prompt_git()
{
local git_dir ref br top;
git_dir=$(git-rev-parse --git-dir 2> /dev/null) || return
ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
br=${ref#refs/heads/}
top=$(cat $git_dir/patches/$br/current 2>/dev/null) \
&& top="/$top"
echo "[$br$top]"
}
if [ $UID = 0 ]; then
u="${LOGNAME}.root"
p="#"
else
u="$LOGNAME";
p="%"
fi
if [ $SHLVL != 1 ]; then
s=", level $SHLVL"
fi
PS1="<${u}@${HOSTNAME}> {\${PWD}}$s \$(__prompt_git)\n\!$p "
unset u s
- Ted
^ permalink raw reply
* Segmentation fault on http clone, post-1.5.6
From: Teemu Likonen @ 2008-06-24 13:04 UTC (permalink / raw)
To: git
With the current "master" branch version (29b0d0191) I get segmentation
fault when trying to clone a git repo with http protocol. Tried a couple
of times and it's always reproducible. You can test with the following
repository (about 5.5 MB):
git clone http://www.iki.fi/tlikonen/voikko.git
I also build git from the tag v1.5.6 and it seems to work fine, so
I guess the bug was introduced after 1.5.6.
^ permalink raw reply
* Re: MinGW port pull request
From: Johannes Sixt @ 2008-06-24 13:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, msysGit
In-Reply-To: <7vskv79l37.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> * There is an interaction with dr/ceiling topic that is already in 'next'
> that needs to be resolved before we merge this in 'next'.
>
> Parked in 'pu' for now but with a broken merge resolution.
Please amend the merge commit by this to get the correct resolution:
minoffset in the MinGW port and ceil_offset in dr/ceiling are used for the
same purpose where always ceil_offset == minoffset-1.
We need to adjust ceil_offset only if longest_ancestor_length() returned
-1 (i.e. "there is no prefix") to skip the drive prefix ("C:"); because if
there was some prefix, then the return value will already have accounted
for the drive prefix.
-- Hannes
diff --git a/setup.c b/setup.c
index 531f852..39f1648 100644
--- a/setup.c
+++ b/setup.c
@@ -382,7 +382,6 @@ const char *setup_git_directory_gently(int *nongit_ok)
const char *gitdirenv;
const char *gitfile_dir;
int len, offset, ceil_offset;
- int minoffset = 0;
/*
* Let's assume that we are in a git repository.
@@ -433,12 +432,10 @@ const char *setup_git_directory_gently(int
if (!getcwd(cwd, sizeof(cwd)-1))
die("Unable to read current working directory");
- if (has_dos_drive_prefix(cwd))
- minoffset = 2;
ceil_offset = longest_ancestor_length(cwd, env_ceiling_dirs);
- if (ceil_offset < minoffset)
- ceil_offset = minoffset;
+ if (ceil_offset < 0 && has_dos_drive_prefix(cwd))
+ ceil_offset = 1;
/*
* Test in the following order (relative to the cwd):
^ permalink raw reply related
* Re: why is git destructive by default? (i suggest it not be!)
From: Rogan Dawes @ 2008-06-24 12:46 UTC (permalink / raw)
To: Johannes Gilger
Cc: David Jeske, Jakub Narebski, Avery Pennarun, Nicolas Pitre, git
In-Reply-To: <20080624123527.GA6149@dualtron.vpn.rwth-aachen.de>
Johannes Gilger wrote:
> On 24/06/08 14:19, Rogan Dawes wrote:
>> One thing that I haven't seen addressed in this thread is the fact that if
>> you have a dirty working directory, and you "git reset --hard", whatever
>> was dirty (not yet in the index, or committed) will be blown away, and no
>> amount of reflog archeology will help you get it back.
>
> I think the name of the command "reset" itself is a name which should
> prompt everyone to read a manpage before using it. I could understand
> that if "status" did something destructive people would get upset.
> Other than that, git reset itself doesn't do anything destructive. Yeah,
> git reset --hard does, but hello, this is *reset* and *hard*, someone
> using this must really want what's about to happen. Nobody complaines
> about rm --force or anything.
>
> As for putting safety-measure everywhere, I think that any further
> restricting of commands would be nonsense and just hindering the
> workflow. git is not something with a GUI and a recycle-bin. And it
> still is really hard to accidentaly lose anything in git.
>
> Regards,
> Jojo
>
Right. I was simply pointing out to the original poster that for all the
talk about reflogs, if you use "reset --hard", all bets are off. I was
not complaining about the existence of that option, or its name . . .
I agree that adding nanny-guards to git would be counter productive.
Rogan
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Johannes Sixt @ 2008-06-24 12:41 UTC (permalink / raw)
To: Erez Zilber; +Cc: Johannes Schindelin, Matthias Kestenholz, git
In-Reply-To: <ce513bcc0806240507q58c2a3y5fe8f0e8033353ad@mail.gmail.com>
Erez Zilber schrieb:
> [root@kd001 my_test.git]# git-push --all
> ssh://erez.zilber@kites/pub/git/erez.zilber/my_test.git
> erez.zilber@kites's password:
> Counting objects: 9, done.
> Compressing objects: 100% (5/5), done.
> Writing objects: 100% (9/9), 740 bytes, done.
> Total 9 (delta 0), reused 0 (delta 0)
> To ssh://erez.zilber@kites/pub/git/erez.zilber/my_test.git
> * [new branch] master -> master
>
> Now, on the server side:
>
> -sh-3.1$ cd my_test.git/
> -sh-3.1$ ls info/
> exclude
> -sh-3.1$ git-update-server-info
> -sh-3.1$ ls info/
> exclude refs
>
> looks like git-update-server-info did some work (added the refs file).
>
> Back to the client:
>
> [root@kd001 t]# git-clone http://kites/pub/git/erez.zilber/my_test.git
> Initialized empty Git repository in /home/erez.zilber/work/tmp/t/my_test/.git/
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
>
> The path is the same path that was used for pushing the repository.
No, it's not. You pushed via ssh, but you clone via http.
When you point your web browser to
http://kites/pub/git/erez.zilber/my_test.git
what do you see? Error 404 or a directory listing?
-- Hannes
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Johannes Gilger @ 2008-06-24 12:35 UTC (permalink / raw)
To: Rogan Dawes
Cc: David Jeske, Jakub Narebski, Avery Pennarun, Nicolas Pitre, git
In-Reply-To: <4860E63B.6040709@dawes.za.net>
On 24/06/08 14:19, Rogan Dawes wrote:
> One thing that I haven't seen addressed in this thread is the fact that if
> you have a dirty working directory, and you "git reset --hard", whatever
> was dirty (not yet in the index, or committed) will be blown away, and no
> amount of reflog archeology will help you get it back.
I think the name of the command "reset" itself is a name which should
prompt everyone to read a manpage before using it. I could understand
that if "status" did something destructive people would get upset.
Other than that, git reset itself doesn't do anything destructive. Yeah,
git reset --hard does, but hello, this is *reset* and *hard*, someone
using this must really want what's about to happen. Nobody complaines
about rm --force or anything.
As for putting safety-measure everywhere, I think that any further
restricting of commands would be nonsense and just hindering the
workflow. git is not something with a GUI and a recycle-bin. And it
still is really hard to accidentaly lose anything in git.
Regards,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Robert Haines @ 2008-06-24 12:35 UTC (permalink / raw)
To: Erez Zilber; +Cc: Matthias Kestenholz, git
In-Reply-To: <ce513bcc0806240445x6d00323g303f218504d2df53@mail.gmail.com>
> I ran git-daemon on the server side like this:
>
> sudo git-daemon --base-path=/pub/git/ --export-all --listen=kites
So your clone address for git:// is wrong, you don't need the /pub/git:
git clone git://erez.zilber@kites/erez.zilber/my_test.git
As you've moved the root of the filesystem as far as git-daemon is
concerned to /pub/git with the --base-path option. I suspect a similar
problem for http[s] depending on how you've mapped /pub/git into your
webserver.
rather than:
git clone ssh://erez.zilber@kites/pub/git/erez.zilber/my_test.git
for ssh which does start at the root of the filesystem.
Cheers,
Rob
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Olivier Galibert @ 2008-06-24 12:21 UTC (permalink / raw)
To: David Jeske; +Cc: Jakub Narebski, Avery Pennarun, Nicolas Pitre, git
On Tue, Jun 24, 2008 at 11:29:43AM -0000, David Jeske wrote:
> -- Jakub Narebski wrote:
> > If they are using '-f', i.e. force, they should know and be sure what
> > they are doing; it is not much different from 'rm -f *'.
>
> Sure, no problem. I don't want the ability to "rm -f *". I'm raising my hand
> and saying "I don't want the power to do these things, so just turn off all the
> git commands that could be destructive and give me an alternate way to do the
> workflows I need to do". Just like a normal user on a unix machine doesn't run
> around with the power to rm -f /etc all the time, even though they may be able
> to su to root.
But you still have the power to /bin/rm -rf ~, which tends to have
worse results. The root/user separation just tries to protect the
system's integrity from the user. This is similar to git, whch tries
to protect the repository's integrity, which is not the same thing as
the contents.
--force exists because it is sometimes useful. It you block it behind
some config setting, whoever is concerned will just change the config
when he needs the command and never change it back. And windows, fsck
and other things of the kind pretty much ruined the efficiency of
confirmations before dangerous/destructive operations. So there isn't
much left beside engaging your brain before using --force on a
command.
OG.
^ permalink raw reply
* Re: git-clone works with ssh but not with http/https/git
From: Jakub Narebski @ 2008-06-24 12:25 UTC (permalink / raw)
To: Erez Zilber; +Cc: Johannes Schindelin, Matthias Kestenholz, git
In-Reply-To: <ce513bcc0806240507q58c2a3y5fe8f0e8033353ad@mail.gmail.com>
"Erez Zilber" <erezzi.list@gmail.com> writes:
> I think that I'm using the right repository for git-clone because it's
> the same path that I used for git push:
>
> [root@kd001 my_test.git]# git-push --all
> ssh://erez.zilber@kites/pub/git/erez.zilber/my_test.git
[...]
> looks like git-update-server-info did some work (added the refs file).
>
> Back to the client:
>
> [root@kd001 t]# git-clone http://kites/pub/git/erez.zilber/my_test.git
> Initialized empty Git repository in /home/erez.zilber/work/tmp/t/my_test/.git/
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
>
> The path is the same path that was used for pushing the repository.
> What did I miss here?
First, obvious question: do you have web server enabled?
Second, less obvious: how this server maps pathname information from
URL into path in the filesystem?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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