* Application to install man pages.
From: Evan Carroll @ 2007-10-18 18:59 UTC (permalink / raw)
To: git
This is a one liner but might help for simply a quick install of the
git manpages.
>From f5797d786fd4a6f9633054bb0f0ce894a06d6650 Mon Sep 17 00:00:00 2001
From: root <root@x60s.(none)>
Date: Thu, 18 Oct 2007 13:45:16 -0500
Subject: [PATCH] install_man.sh script which installs the man pages
---
install_man.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
create mode 100755 install_man.sh
diff --git a/install_man.sh b/install_man.sh
new file mode 100755
index 0000000..b722425
--- /dev/null
+++ b/install_man.sh
@@ -0,0 +1,2 @@
+#/bin/sh
+ cp -R --copy-contents ./man* /usr/local/man
--
1.5.3.4.206.g58ba4
I was also wondering if it might be useful to have a command in the
master branch of the git repo that switches branches and installs the
man pages.. possibly as run in the makefile if .git exists then switch
branches, and run install_man.sh. Just an idea.
--
Evan Carroll
System Lord of the Internets
me@evancarroll.com
832-445-8877
^ permalink raw reply related
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Jan Hudec @ 2007-10-18 18:54 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Morten Welinder, git, spearce
In-Reply-To: <DC3D43FD-F03D-4E0A-9C2B-DE56F9C16D60@silverinsanity.com>
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
On Wed, Oct 17, 2007 at 11:16:34 -0400, Brian Gernhardt wrote:
>
> On Oct 17, 2007, at 10:39 AM, Morten Welinder wrote:
>
>>> made it into your repo. It fixes test failures on my machine that have
>>> been plauging me for months.
>>
>> That sounds more like a reason to fix the test. "die" is the perl
>> standard way of reporting an error. It will print the error message
>> on stderr, not on stdout like your version does.
>>
>> IMHO, of course.
>
> The problem is that die can exit with varying exit codes, and exit codes >=
> 128 make the test suite assume something has gone wrong with the test. In
> particular, because $! (errcode) and $? (previous shell command return) are
> both 0, it returns 255. Or at least that's how it works out on my system.
> I'm not sure why it doesn't do that on others.
>
> But the test is expecting a failure here and it appears to be failing in
> the correct way, just with an error code test-lib.sh doesn't like. I asked
> on list the best way to fix it and Frank Lichtenheld said (and nobody
> objected until now) that this was the best way to fix it.
>
> Also, the not printing on STRERR is identical to another section of code
> just below mine:
>
>> unless ($line eq 'anonymous') {
>> print "E Only anonymous user allowed via pserver\n";
>> print "I HATE YOU\n";
>> exit 1;
>> }
>
> However, amending my patch to print to STDERR is not difficult.
Hm. There are two kinds of errors in git-cvsserver and they should be handled
differently.
If the error is an invalid request (like the quoted one), there should be
normal print, to STDOUT, starting with "E", because it's an error message
that should be sent to the client.
On the other hand if the error is internal error in the script or it's
configuration, than the error should probably be reported via die, *without*
E at the begining (it will be prefixed with location anyway). Such message
will probably end up in the log rather than sent to the client.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Subversion developer: svn is for dumb people
From: Jeff King @ 2007-10-18 18:33 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <47176CE0.7030609@midwinter.com>
On Thu, Oct 18, 2007 at 07:25:36AM -0700, Steven Grimm wrote:
> Okay, my summary is slightly facetious, but that's basically the gist of
> what he's saying: you should choose Subversion rather than a DVCS because
> most of your users won't be smart enough to use the better tool.
An interesting point he brings up (which I think is totally bogus) is
(paraphrased): "DVCS systems encourage people to work in isolation and
then patch-bomb the upstream."
But I think it's quite the opposite. He compares two scenarios: in
$DVCS, the user forks, works quietly in their cave for a few weeks, and
then produces a result. With a centralized VCS, the user gets a private
branch, and people keep up with their work as it progresses.
This isn't realistic for two reasons:
1. Contributors to projects now using DVCS systems _weren't_ using SVN
or CVS in this way before (presumably because the effort in getting
private branches set up in a central repository was too much -- if
I want to hack on a project, I want to do it _now_, not after I
have gotten approval to use the VCS by the maintainer). Instead,
they sat in their cave using primitive tools like 'diff' and
'patch' until they patch-bombed the upstream.
2. DVCS systems (well, git, at least) focus on workflows that allow
for quick communication and code review. Patches are a first-class
item in git, which means that
- every change is on the mailing list for review
- work-in-progress patches are easy to post, easy for reviewers
to read, easy for reviewers to apply, and, if accepted,
easy for the maintainer to apply
-Peff
^ permalink raw reply
* Re: Problem with git-svnimport
From: Jan Hudec @ 2007-10-18 18:09 UTC (permalink / raw)
To: VAUCHER Laurent; +Cc: git
In-Reply-To: <55DDB08CC9CD2941A70E8D626789A2C906A4031A@ec8l7ljvo9h5dde.hosting.exch>
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
On Tue, Oct 16, 2007 at 14:30:30 +0200, VAUCHER Laurent wrote:
> Hi.
>
> Trying to convert a svn repository to git, I encountered the following
> error:
>
> Use of uninitialized value in hash element at /usr/bin/git-svnimport
> line 534.
>
> Line 534 reads:
> my $gitrev = $branches{$srcbranch}{$therev};
>
> I have installed packages git-core and git-svn on Ubuntu. These
> package have versions: "1:1.5.2.5-2-feisty1"
>
> The tool seems to choke on tags or branches with special characters
> (underscore, for instance).
git-svnimport is obsoleted (or mostly so) by git-svn. Look at that, please.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Jeff King @ 2007-10-18 18:08 UTC (permalink / raw)
To: Steven Grimm
Cc: Brian Gernhardt, Linus Torvalds, Luke Lu, Christer Weinigel,
Tom Tobin, git
In-Reply-To: <47176AB9.7010409@midwinter.com>
On Thu, Oct 18, 2007 at 07:16:25AM -0700, Steven Grimm wrote:
>> installed in the first place. Perhaps a message more along the lines of
>> "To avoid this, run "git gc" manually on a regular basis. See 'git help
>> gc' for more information."
>
> That's a good point. Jeff / Shawn, do you agree with that? I'll come up with
> an alternate patch if so.
Yes, that seems reasonable. I think the most important thing is that
they realize that "git-gc" is responsible for what is happening. That
should allow them to find more information in the documentation if they
want (and Brian's suggestion points directly to the documentation, which
is great).
-Peff
^ permalink raw reply
* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-18 16:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0710181720010.25221@racer.site>
On Thu, 2007-10-18 at 17:21 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
>
> > Seems like it is a bit too easy to make mistakes here. Why can I delete
> > a branch with :linus but not create one with linus:linus?
>
> I wonder why you bother with the colon at all. Just
>
> git push <remote> linus
>
> and be done with it. The colon is only there to play interesting games,
> not something as simple as "push this branch" or "push this tag".
First, I didn't know that I could do that.
Secondly, I was also looking do v2.6.23:linus refspecs
Jocke
^ permalink raw reply
* NI_MAXSERV trivial patch
From: Patrick Welche @ 2007-10-18 17:17 UTC (permalink / raw)
To: git
I found I needed
--- daemon.c.orig 2007-09-02 06:57:44.000000000 +0100
+++ daemon.c 2007-10-18 16:04:00.000000000 +0100
@@ -9,6 +9,10 @@
#define HOST_NAME_MAX 256
#endif
+#ifndef NI_MAXSERV
+#define NI_MAXSERV 32
+#endif
+
static int log_syslog;
static int verbose;
static int reuseaddr;
to compile git, as for me NI_MAXSERV is defined in netdb.h, and it
doesn't seem worthwhile to include the whole header.
Cheers,
Patrick
^ permalink raw reply
* Splitting a repository
From: Gonzalo Garramuno @ 2007-10-18 17:35 UTC (permalink / raw)
To: git
I have a project I have been working on for some time and one of its
libraries has grown too much.
I'm now wanting to split that library into a separate git repository.
I'm wondering what's the best way to go around this. Ideally I would
like to have:
* all history on those library files be moved to the new repository.
* all history on those library files be removed from the original
repository.
or:
* have the original repository library directory be "linked" to the new
repository.
--
Gonzalo Garramuño
Film Aura
A New Dawn in Media Companies
gga@filmaura.com
http://www.filmaura.com
^ permalink raw reply
* Re: [PATCH] Make the output of "git svn clone" less confusing.
From: Eric Wong @ 2007-10-18 17:14 UTC (permalink / raw)
To: David Kågedal; +Cc: Shawn O.Pearce, git
In-Reply-To: <87abqgiqsj.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> >> David Kågedal <davidk@lysator.liu.se> wrote:
> >> > The problem is that the first thing it prints is
> >> >
> >> > Initialized empty Git repository in .git/
> >> >
> >> > even if actually created a subdirectory and changed into it first. But to the
> >> > user, it looks like it is creating a .git/ dir in the directory he/she is
> >> > started git from.
> >>
> >> Eric, ack/nack?
> >
> > Nack, here's (hopefully) a better patch.
> >
> > David: agree/disagree?
>
> I don't really like this. Now you added a dependency on exactly how
> git-init-db will format its output. So if e.g. it is updated to use
> the absolute path your patch will create bogus output.
Yes, it's quite ugly :/ I think the best solution would be to fix all
GIT_DIR= setting issues and getting git-svn to always respect it for
init/clone/fetch (and tests, of course!). I probably won't get around
to doing any of this until Friday night or Saturday (PST), however...
Shawn: feel free to ignore this series for now
> Did you consider my suggestion of not doing the chdir befor running
> git-init-db?
That would likely break clone, and also this (from my message
under the commit message).
> I've actually just noticed that setting GIT_DIR= before running
> git-svn clone is very broken, and I probably won't get a chance
> to fix it for at least 24 hours (if I'm even awake)...
--
Eric Wong
^ permalink raw reply
* Re: Subversion developer: svn is for dumb people
From: David Brown @ 2007-10-18 16:57 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <47176CE0.7030609@midwinter.com>
On Thu, Oct 18, 2007 at 07:25:36AM -0700, Steven Grimm wrote:
> I can't say he's completely wrong, especially about the 20/80% idea (though
> I think "20%" is generous), but some of his specific arguments about DVCS
> are on the bogus side. "Centralized systems encourage code reviews," for
> one -- I challenge him to find a project with a more pervasive and
> effective code-reviewing culture than the git project. I find code reviews
> *harder* in a centralized system because you end up building external tools
> to help people try out each other's changes.
The review comment is completely bogus. Centralized systems, at least like
SVN and P4 encourage a check-it-in-deal-with-the-problems-later attitude.
The tool discourages you from trying out other's changes, whereas a DVCS
tends to have lots of little branches and easy migration between them.
I think this is less an issue of distributed or not, but more that branches
are just so expensive in most other revision control systems. Whether that
is expensive in resource, or just in understanding what is going on (for
example, requiring users to track merge ancestors is rediculous).
David
^ permalink raw reply
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-18 16:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Joakim Tjernlund, git
In-Reply-To: <Pine.LNX.4.64.0710181720010.25221@racer.site>
On Oct 18, 2007, at 6:21 PM, Johannes Schindelin wrote:
> On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
>
>> Seems like it is a bit too easy to make mistakes here. Why can I
>> delete
>> a branch with :linus but not create one with linus:linus?
>
> I wonder why you bother with the colon at all. Just
>
> git push <remote> linus
>
> and be done with it. The colon is only there to play interesting
> games,
> not something as simple as "push this branch" or "push this tag".
But you need a full refspec starting with 'refs/heads/' if you want to
create a new branch on the remote side.
Steffen
^ permalink raw reply
* [PATCH] cvs export: ensure we add directories in order
From: Alex Bennee @ 2007-10-18 16:15 UTC (permalink / raw)
To: git
Hi,
CVS gets understandably upset if you try and add a subdirectory before
it's parent directory. This patch fixes that.
>From d99d4e7eb0ce7b85fb84d3c57f57abbb100baa5e Mon Sep 17 00:00:00 2001
From: Alex Bennee <alex@bennee.com>
Date: Thu, 18 Oct 2007 17:12:13 +0100
Subject: [PATCH] Ensure we add directories in the correct order
---
git-cvsexportcommit.perl | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 0a21215..a70c583 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -234,6 +234,17 @@ print "Applying\n";
print "Patch applied successfully. Adding new files and directories to CVS\n";
my $dirtypatch = 0;
+
+#
+# We have to add the directories in order otherwise we will have
+# problems when we try and add the sub-directory of a directory we
+# have not added yet.
+#
+# Luckily this is easy to deal with by sorting the directories and
+# dealing with the shortest ones first.
+#
+@dirs = sort { length $a <=> length $b} @dirs;
+
foreach my $d (@dirs) {
if (system(@cvs,'add',$d)) {
$dirtypatch = 1;
--
1.5.2.5
--
Alex, homepage: http://www.bennee.com/~alex/
Business is a good game -- lots of competition and minimum of rules. You
keep score with money. -- Nolan Bushnell, founder of Atari
^ permalink raw reply related
* Re: git push bug?
From: Johannes Schindelin @ 2007-10-18 16:21 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Steffen Prohaska, git
In-Reply-To: <1192723269.9433.21.camel@gentoo-jocke.transmode.se>
Hi,
On Thu, 18 Oct 2007, Joakim Tjernlund wrote:
> Seems like it is a bit too easy to make mistakes here. Why can I delete
> a branch with :linus but not create one with linus:linus?
I wonder why you bother with the colon at all. Just
git push <remote> linus
and be done with it. The colon is only there to play interesting games,
not something as simple as "push this branch" or "push this tag".
Ciao,
Dscho
^ permalink raw reply
* git-merge: need a tap with the cluestick, please
From: walt @ 2007-10-18 16:17 UTC (permalink / raw)
To: git
I just tried my first local modification to Linus's tree, and I
can't get the merge to work. Maybe my whole approach is wrong?
I wanted start compiling the kernel out-of-tree, so I added my
own 'obj' directory at the top level.
I then got conflicts when trying to pull from Linus, so I added
my 'obj' directory to my toplevel .gitignore file and committed
the local change to my 'master' branch. (This is my only local
modification because I'm only tracking Linus, not developing the
kernel.)
Now when I pull from Linus the merge stops in the middle because of
conflicts with my .gitignore file <sigh>. Anything I try now with
git-merge tells me I can't do that in the middle of a conflicted
merge. Yes, I know that now, but what should I do instead?
I could move my 'obj' out-of-tree but then I wouldn't learn anything.
This has to be bone-head easy, but not for me :)
Clues most welcome.
^ permalink raw reply
* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-18 16:10 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1192723269.9433.21.camel@gentoo-jocke.transmode.se>
On Thu, 2007-10-18 at 18:01 +0200, Joakim Tjernlund wrote:
> On Thu, 2007-10-18 at 17:14 +0200, Steffen Prohaska wrote:
> > On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
> >
> > >
> > > I thougth I could create a new branch on the server using:
> > >
> > > # > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> > > Warning: No xauth data; using fake authentication data for X11
> > > forwarding.
> > > updating 'refs/linus' using 'refs/heads/linus'
> > > from 0000000000000000000000000000000000000000
> > > to bbf25010f1a6b761914430f5fca081ec8c7accd1
> > > Generating pack...
> > > Done counting 0 objects.
> > > Writing 0 objects...
> > > Total 0 (delta 0), reused 0 (delta 0)
> > > error: refusing to create funny ref 'refs/linus' locally
> > > ng refs/linus funny refname
> > > error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
> > >
> > > but that doesn't work. Am I doing this wrong?
> >
> > Include 'heads' in your remote refspec:
> >
> > git push ssh://devsrv/var/git/os2kernel.git linus:refs/heads/linus
>
> Now the push went OK:
> git push ssh://devsrv/var/git/os2kernel.git linus:refs/head/linus
> Warning: No xauth data; using fake authentication data for X11 forwarding.
> updating 'refs/head/linus' using 'refs/heads/linus'
> from 0000000000000000000000000000000000000000
> to bbf25010f1a6b761914430f5fca081ec8c7accd1
> Generating pack...
> Done counting 0 objects.
> Writing 0 objects...
> Total 0 (delta 0), reused 0 (delta 0)
> refs/head/linus: 0000000000000000000000000000000000000000 -> bbf25010f1a6b761914430f5fca081ec8c7accd1
>
> but there is no linus branch in the server repo!
>
> However:
> git push ssh://devsrv/var/git/os2kernel.git linus
>
> creates a linus branch in the server and
>
> git push ssh://devsrv/var/git/os2kernel.git :linus
> Warning: No xauth data; using fake authentication data for X11 forwarding.
> deleting 'refs/heads/linus'
> refs/heads/linus: bbf25010f1a6b761914430f5fca081ec8c7accd1 -> deleted
> Everything up-to-date
>
> deletes the linus branch on the server and so does
> git push ssh://devsrv/var/git/os2kernel.git :refs/heads/linus
>
> ahh, now I see. When creating the branch the refspec needs to be refs/heads/linus,
> not refs/head/linus
>
> refs/head/linus will create just that on the server. git branch does not look
> there, only in refs/heads
>
> Seems like it is a bit too easy to make mistakes here. Why can I delete
> a branch with :linus but not create one with linus:linus?
> Also confusing that git lets me create refs/head/linus when git branch
> cannot find it.
>
> Jocke
BTW this does not work either:
git reset --hard HEAD^
git push -f ssh://devsrv/var/git/os2kernel.git +master:master
updating 'refs/heads/master'
from 9c344d18d01221c8f25080cb58910e6b09efbf55
to 5761a9e5924b34615c748fba2dcb977ed04c1243
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
error: denying non-fast forward refs/heads/master (you should pull first)
ng refs/heads/master non-fast forward
error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
I thought the + in +master:master and the -f option should let me
do that.
^ permalink raw reply
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-18 16:13 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: git
In-Reply-To: <1192723269.9433.21.camel@gentoo-jocke.transmode.se>
On Oct 18, 2007, at 6:01 PM, Joakim Tjernlund wrote:
> Seems like it is a bit too easy to make mistakes here. Why can I
> delete
> a branch with :linus but not create one with linus:linus?
> Also confusing that git lets me create refs/head/linus when git branch
> cannot find it.
I absolutely agree. But I'm not sure if those who use git since the
ancient days do agree too.
Steffen
^ permalink raw reply
* Re: [BUG] git remote add failure
From: Johannes Schindelin @ 2007-10-18 16:09 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: Git Mailing List
In-Reply-To: <1192697719.31199.1216526739@webmail.messagingengine.com>
Hi,
On Thu, 18 Oct 2007, Guido Ostkamp wrote:
> I think I've found a bug in "git remote add". I tried the following:
>
> $ git remote add -f spearce2 http://repo.or.cz/git/spearce.git
> Cannot get the repository state from http://repo.or.cz/git/spearce.git
> fetch spearce2: command returned error: 1
>
> Obviously I used the wrong URI. Then I tried again:
>
> $ git remote add -f spearce2 http://repo.or.cz/r/git/spearce.git
> remote spearce2 already exists.
>
> I think Git should not store the bad info and block the name when the
> first call wasn't successfull.
The problem there is of course that the fetch could fail because you are
offline. In that case, you do not want git remote to throw the
information away.
BTW you missed the trailing slash in the HTTP URL, I guess.
Ciao,
Dscho
^ permalink raw reply
* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-18 16:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <0DAC53EF-021D-441C-9520-9795AAB6DE54@zib.de>
On Thu, 2007-10-18 at 17:14 +0200, Steffen Prohaska wrote:
> On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
>
> >
> > I thougth I could create a new branch on the server using:
> >
> > # > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> > Warning: No xauth data; using fake authentication data for X11
> > forwarding.
> > updating 'refs/linus' using 'refs/heads/linus'
> > from 0000000000000000000000000000000000000000
> > to bbf25010f1a6b761914430f5fca081ec8c7accd1
> > Generating pack...
> > Done counting 0 objects.
> > Writing 0 objects...
> > Total 0 (delta 0), reused 0 (delta 0)
> > error: refusing to create funny ref 'refs/linus' locally
> > ng refs/linus funny refname
> > error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
> >
> > but that doesn't work. Am I doing this wrong?
>
> Include 'heads' in your remote refspec:
>
> git push ssh://devsrv/var/git/os2kernel.git linus:refs/heads/linus
Now the push went OK:
git push ssh://devsrv/var/git/os2kernel.git linus:refs/head/linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
updating 'refs/head/linus' using 'refs/heads/linus'
from 0000000000000000000000000000000000000000
to bbf25010f1a6b761914430f5fca081ec8c7accd1
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
refs/head/linus: 0000000000000000000000000000000000000000 -> bbf25010f1a6b761914430f5fca081ec8c7accd1
but there is no linus branch in the server repo!
However:
git push ssh://devsrv/var/git/os2kernel.git linus
creates a linus branch in the server and
git push ssh://devsrv/var/git/os2kernel.git :linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
deleting 'refs/heads/linus'
refs/heads/linus: bbf25010f1a6b761914430f5fca081ec8c7accd1 -> deleted
Everything up-to-date
deletes the linus branch on the server and so does
git push ssh://devsrv/var/git/os2kernel.git :refs/heads/linus
ahh, now I see. When creating the branch the refspec needs to be refs/heads/linus,
not refs/head/linus
refs/head/linus will create just that on the server. git branch does not look
there, only in refs/heads
Seems like it is a bit too easy to make mistakes here. Why can I delete
a branch with :linus but not create one with linus:linus?
Also confusing that git lets me create refs/head/linus when git branch
cannot find it.
Jocke
> You may need to cleanup though. I'm not sure if the remote side
> already created 'refs/linus'. The error message only indicates that
> locally git refused to create the "funny refname". Pushing a refspec
> with an empty local part should delete the "funny refname" on the
> remote:
>
> git push ssh://devsrv/var/git/os2kernel.git :refs/linus
>
> Did this solve your problem?
>
> Steffen
>
^ permalink raw reply
* Proposed git mv behavioral change
From: lmage11 @ 2007-10-18 15:47 UTC (permalink / raw)
To: git
Hey, all...
Based on a question I asked on freenode's #git channel a few days ago, it seems that most
people only use git
mv when the file they're moving is clean. Those that don't have become accustomed to the
behavior that git-mv
uses when the file is dirty - to pull all unstaged changes into the index. As far as I can tell,
this behavior is
largely historical. When git-mv was written in bash (or perl, or whatever it was initially written
in), it was most
convenient to implement it as "mv oldname newname; git add newname;", or something
similar, which would
result in pulling in all wd changes. However, it seems to me that this behavior violates git's
consistency. Usually
when I do something with git, I expect it to do only what it says it will do, and nothing more.
The
documentation for git-mv says "The index is updated after successful completion", but I
would tend to assume
that this was referring to the name change and not the change in the actual contents of the
file.
In my situation, I have some changes to a file that I'm not yet ready to commit. In the
meantime, I've started
working on another unrelated change that involves renaming one of the files which contain
unstaged changes.
I'd like to be able to perform this move without having my unstaged changes implicitly
staged without my
knowledge. When I want information put into the index, I either use git update-index if I
want to explicitly
stage an entire file or I use git add -i's patch command to explicitly stage individual chunks. I
like having very
fine-grained control over what goes into the index and what doesn't.
Therefore, I propose that git mv's behavior be changed. I think it would make far more sense
for a move to only
change the actual name of the file and to not pull in unstaged changes. In other words, I'd
like the index entry
for the original file name to be removed and an index entry to be added with a different
name, but using the
exact same blob hash as the original file. I don't know exactly how git manages the index
internally, but a
shortcut for this would be to simply rename the index entry in place.
I'm willing to look into what changes would need to be made to the code for this change to
happen; I'm not
asking for someone to do all the work for me. :)
So... Yeah. I'd like to know what people think about this before I put a significant amount of
effort into it. After
all, we know how lazy programmers are... :)
Thanks,
Ari
^ permalink raw reply
* Re: [PATCH] Remove link to the survey from the git home page.
From: Paolo Ciarrocchi @ 2007-10-18 15:30 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: pasky, git
In-Reply-To: <2c6b72b30710180525s3924c720rb7cb715dc7b43c3b@mail.gmail.com>
On 10/18/07, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> On 10/16/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > As far as I know the survey is close so it makes sense to remove the link/text from the home page.
>
> Pasky has provided me with write access to git-homepage.git and to test
> the setup I have applied this change, which seemed to have been overlooked.
>
> Pasky, maybe you can update git.or.cz and perhaps also remove the link
> from the front page of repo.or.cz? :)
Pasky, Jonas,
I cannot enter IRC at the moment so I'm sending here a note with my proposal.
I recently got interested in drupal and I wondered whether it would a
good idea to try to play in a sandbox with a drupal installation and
somehow compare the actual static homepage with an alternative drupal
based portal.
What do you think?
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-18 15:14 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: git
In-Reply-To: <1192719040.9433.5.camel@gentoo-jocke.transmode.se>
On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
>
> I thougth I could create a new branch on the server using:
>
> # > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> Warning: No xauth data; using fake authentication data for X11
> forwarding.
> updating 'refs/linus' using 'refs/heads/linus'
> from 0000000000000000000000000000000000000000
> to bbf25010f1a6b761914430f5fca081ec8c7accd1
> Generating pack...
> Done counting 0 objects.
> Writing 0 objects...
> Total 0 (delta 0), reused 0 (delta 0)
> error: refusing to create funny ref 'refs/linus' locally
> ng refs/linus funny refname
> error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
>
> but that doesn't work. Am I doing this wrong?
Include 'heads' in your remote refspec:
git push ssh://devsrv/var/git/os2kernel.git linus:refs/heads/linus
You may need to cleanup though. I'm not sure if the remote side
already created 'refs/linus'. The error message only indicates that
locally git refused to create the "funny refname". Pushing a refspec
with an empty local part should delete the "funny refname" on the
remote:
git push ssh://devsrv/var/git/os2kernel.git :refs/linus
Did this solve your problem?
Steffen
^ permalink raw reply
* git push bug?
From: Joakim Tjernlund @ 2007-10-18 14:50 UTC (permalink / raw)
To: git
I thougth I could create a new branch on the server using:
# > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
updating 'refs/linus' using 'refs/heads/linus'
from 0000000000000000000000000000000000000000
to bbf25010f1a6b761914430f5fca081ec8c7accd1
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
error: refusing to create funny ref 'refs/linus' locally
ng refs/linus funny refname
error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
but that doesn't work. Am I doing this wrong?
git 1.5.3.4
Jocke
^ permalink raw reply
* Subversion developer: svn is for dumb people
From: Steven Grimm @ 2007-10-18 14:25 UTC (permalink / raw)
To: 'git'
Thought folks here might get a kick out of this:
http://blog.red-bean.com/sussman/?p=79
Okay, my summary is slightly facetious, but that's basically the gist of
what he's saying: you should choose Subversion rather than a DVCS
because most of your users won't be smart enough to use the better tool.
I can't say he's completely wrong, especially about the 20/80% idea
(though I think "20%" is generous), but some of his specific arguments
about DVCS are on the bogus side. "Centralized systems encourage code
reviews," for one -- I challenge him to find a project with a more
pervasive and effective code-reviewing culture than the git project. I
find code reviews *harder* in a centralized system because you end up
building external tools to help people try out each other's changes.
-Steve
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Nicolas Pitre @ 2007-10-18 14:21 UTC (permalink / raw)
To: Brian Gernhardt
Cc: koreth, Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel,
Tom Tobin, git
In-Reply-To: <3391BADA-B5B4-4A8E-A6C0-42169AFC0331@silverinsanity.com>
On Thu, 18 Oct 2007, Brian Gernhardt wrote:
>
> On Oct 18, 2007, at 12:41 AM, koreth@midwinter.com wrote:
>
> > And as an added bonus, we can tell people how to turn off automatic GC
> > and how to invoke it by hand.
>
> > + fprintf(stderr, "Packing your repository for optimum "
> > + "performance. If you would rather run\n"
> > + "\"git gc\" by hand, run \"git config gc.auto 0\" "
> > + "to disable automatic cleanup.\n");
>
> I'm not sure telling the users how to disable it every time it shows up is a
> good idea. gc --auto exists for the naive user, and suggesting they turn it
> off each time it happens will just result in... people turning it off,
> leading back to the performance issues that caused the feature to be installed
> in the first place. Perhaps a message more along the lines of "To avoid this,
> run "git gc" manually on a regular basis. See 'git help gc' for more
> information."
This is indeed a good point.
And for those who start repacking manually then the automatic repacking
will very rarely trigger, reducing the need for turning automatic
repacking off anyway.
Nicolas
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Steven Grimm @ 2007-10-18 14:16 UTC (permalink / raw)
To: Brian Gernhardt
Cc: Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin,
git
In-Reply-To: <3391BADA-B5B4-4A8E-A6C0-42169AFC0331@silverinsanity.com>
Brian Gernhardt wrote:
> I'm not sure telling the users how to disable it every time it shows
> up is a good idea. gc --auto exists for the naive user, and
> suggesting they turn it off each time it happens will just result
> in... people turning it off, leading back to the performance issues
> that caused the feature to be installed in the first place. Perhaps a
> message more along the lines of "To avoid this, run "git gc" manually
> on a regular basis. See 'git help gc' for more information."
That's a good point. Jeff / Shawn, do you agree with that? I'll come up
with an alternate patch if so.
-Steve
^ 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