* [msysgit] how to detect git.exe directory?
From: Marco Costalba @ 2007-12-23 16:25 UTC (permalink / raw)
To: msysgit, Git Mailing List
Hi all,
I'm progressing on qgit installer for windows, I have switched to
MSVC for compiling Qt4 and qgit sources and I have to say that first
results are very good, qgit.exe now seems to work without problems or
artifacts and the speed is much more similar to what we achieve under
the Linux platform (read much higher).
So it seems Qt+mingw is not the _best_ possible solution.
Anyhow, under Vista you cannot simply copy qgit.exe in the git
directory (OS barfs regarding some administrative rights, note that *I
am* the administartor!), so to make qgit.exe work git.exe file must be
in PATH.
To easy the user and allowing to call qgit.exe double clicking on a
nice desktop icon I need a way to know where git.exe is installed *at
runtime*.
So my question is: "What is the preferred way to detect git directory
at runtime for msysgit files?"
- environment variable ??
- windows registry ??
- others ?
I don't plan to use the cygwin version of git but going directly to
the "long term" solution that is msysgit.
Thanks for your help
Marco
^ permalink raw reply
* Re: sane, stable renames; when a commit should commit twice
From: Jakub Narebski @ 2007-12-23 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <ee77f5c20712221826r5945a6d0x8a84eae98c85b25b@mail.gmail.com>
David Symonds wrote:
> On Dec 23, 2007 1:03 PM, Zenaan Harkness <zen@freedbms.net> wrote:
>> When should a commit, commit twice?
>>
>> When one or more git mv file renames/ moves are involved.
>>
>> In such a case the commit ought to be split into two. Perhaps move the
>> files in the first commit, then make the changes needed to support the
>> move in the build chain (including changes in the moved files) in the
>> second commit.
>>
>> This keeps a clean record of the move, making the move, and the
>> associated changes (as two commits) a clean cherry.
>>
>> Does this make sense?
>
> Not particularly. Git commits are not (conceptually) changes or
> deltas; they are snapshots of a tree of files at a particular time.
> How does the tree state at your above first commit make any sense? It
> is broken. Git's rename/move detection is smart enough to notice that
> a rename + small-changes is close enough to a rename, so just trust
> that to get it right.
Moreover renames detection during merges is based on three states:
ours, theirs and ancestor, and it would not take into account
"pure rename" commit it is there in the middle of one of chains.
Besides broken (not compiling) commit makes it harder for bisect to find
true bug later.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to detect git.exe directory?
From: Johannes Sixt @ 2007-12-23 16:35 UTC (permalink / raw)
To: mcostalba-Re5JQEeQqe8AvxtiuMwx3w; +Cc: msysGit, Git Mailing List
In-Reply-To: <e5bfff550712230825o5e73bd3dm31057847106b8722-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sunday 23 December 2007 17:25, Marco Costalba wrote:
> To easy the user and allowing to call qgit.exe double clicking on a
> nice desktop icon I need a way to know where git.exe is installed *at
> runtime*.
>
> So my question is: "What is the preferred way to detect git directory
> at runtime for msysgit files?"
>
> - environment variable ??
>
> - windows registry ??
>
> - others ?
Running
git --exec-path
should get you close to it. But I have to question why you need that path.
-- Hannes
^ permalink raw reply
* Re: how to detect git.exe directory?
From: Marco Costalba @ 2007-12-23 16:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysGit, Git Mailing List
In-Reply-To: <200712231735.00336.johannes.sixt-dl2ejS2iUSazZXS1Dc/lvw@public.gmane.org>
On Dec 23, 2007 5:35 PM, Johannes Sixt <johannes.sixt-dl2ejS2iUSazZXS1Dc/lvw@public.gmane.org> wrote:
> On Sunday 23 December 2007 17:25, Marco Costalba wrote:
> > To easy the user and allowing to call qgit.exe double clicking on a
> > nice desktop icon I need a way to know where git.exe is installed *at
> > runtime*.
> >
> > So my question is: "What is the preferred way to detect git directory
> > at runtime for msysgit files?"
> >
> > - environment variable ??
> >
> > - windows registry ??
> >
> > - others ?
>
> Running
>
> git --exec-path
>
> should get you close to it. But I have to question why you need that path.
>
What I'm looking for is git.exe itself. If I run "git --exec-path" I
get something along the lines "git executable not found..."
I don't use dashed command inside qgit, so I run "git log ..." not
"git-log ...", but the git.exe should be known to qgit or in path.
Hope it's clear.
Thanks
Marco
^ permalink raw reply
* Re: Problem with git shortlog documentation
From: Jeff King @ 2007-12-23 17:18 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: Git Mailing List
In-Reply-To: <476E6DA0.9000908@isy.liu.se>
On Sun, Dec 23, 2007 at 03:16:00PM +0100, Gustaf Hendeby wrote:
> I was just looking through the documentation for git shortlog, and realized
> there is a problem with FILES section close to the bottom. In the version I
> built of the man page (asciidoc 8.2.1, yes I used the compatibility define)
> the filename .mailmap is missing, and the text starts with "If this file
> exists, ...".
I mentioned this same issue a few weeks ago:
<20071211124220.GA17929@sigill.intra.peff.net>
but got no response. Under modern asciidoc, it the man page looks like
this:
.SH "FILES"
.PP
\.mailmap
.RS 4
If this ...
which I would have thought would render fine, but doesn't (though I
don't really know troff). Doing " .mailmap" looks OK.
However, the version of the manpages in Junio's origin/man has the awful
"Example 1. .mailmap" generated by asciidoc, so it's clearly a bug-prone
construct.
I think re-wording is a fine fix, at least for now.
> Something like this (would we then like to reindent this? it would make the
> change look much bigger), which seems to work with my asciidoc version:
If by "reindent" you mean not just "wrap the long line" but "the whole
paragraph should start at the beginning of the line, since it's no
longer part of the list element", then
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Robert P. J. Day @ 2007-12-23 17:23 UTC (permalink / raw)
To: Dieter Ries; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <476E5CFC.5070301@gmx.de>
On Sun, 23 Dec 2007, Dieter Ries wrote:
> Robert P. J. Day schrieb:
> > just to be clear, i'm not complaining about the quality of the
> > document above, but when i got started with git, what i really
> > wanted was a list of what i (as a simple, non-developer user)
> > could do once i cloned a repository.
> >
> > to that end, i put together my own little reference list of git
> > commands. for example, i collected ways to examine my repository
> > -- git commands like branch, tag, log/shortlog, what-changed,
> > show, grep, blame, that sort of thing. exactly the kind of stuff
> > a new user might want to know about, even without the ability to
> > change anything.
>
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?
if you give me a day or two (or three), i may put an updated version
of that up on my wiki.
rday
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: cvsimport: trying to convert freebsd cvs to git
From: Jeff King @ 2007-12-23 17:29 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Stefan Sperling
In-Reply-To: <20071222171801.GE15286@genesis.frugalware.org>
On Sat, Dec 22, 2007 at 06:18:01PM +0100, Miklos Vajna wrote:
> then i tried:
>
> $ time git cvsimport -d `pwd`/cvs -C src.git src
> Initialized empty Git repository in /home/vmiklos/git/freebsd/src.git/.git/
> malformed revision
This is the actual error; everything else is git-cvsimport failing to
notice the problem and continuing anyway.
I will take a look and see if it is simple to stop the process here and
produce a better error message.
> 1) does cvsimport supports the case when the source if on the local
> filesystem, and not in not on a cvs server?
Yes, it should work fine (it will still call cvsps and CVS, so it should
look the same to git-cvsimport).
> 2) if it supports, then i think the real error message is 'malformed
> revision'. what is the proper way to see where is that revision?
Try git-cvsimport -v.
-Peff
^ permalink raw reply
* Re: Problem with git shortlog documentation
From: Junio C Hamano @ 2007-12-23 18:28 UTC (permalink / raw)
To: Jeff King; +Cc: Gustaf Hendeby, Git Mailing List
In-Reply-To: <20071223171840.GA8799@sigill.intra.peff.net>
I think re-wording is a good enough workaround in this case too.
^ permalink raw reply
* [PATCH] Fix for missing line in man page rendered for git shortlog
From: Gustaf Hendeby @ 2007-12-23 18:34 UTC (permalink / raw)
To: peff, gitster; +Cc: git, Gustaf Hendeby
In-Reply-To: <20071223171840.GA8799@sigill.intra.peff.net>
This is a work around for a asciidoc/xmlto problem with lines starting
with a '.'. Until a proper fix for this is found, rewrite problematic
sections.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Acked-by: Jeff King <peff@peff.net>
---
Jeff King wrote:
> On Sun, Dec 23, 2007 at 03:16:00PM +0100, Gustaf Hendeby wrote:
>
> I mentioned this same issue a few weeks ago:
>
> <20071211124220.GA17929@sigill.intra.peff.net>
Ah, I missed that one. Unfortunately, the lack of answers indicate it isn't
trivial to find a general fix to the problem. :(
> I think re-wording is a fine fix, at least for now.
>
>> Something like this (would we then like to reindent this? it would make the
>> change look much bigger), which seems to work with my asciidoc version:
>
> If by "reindent" you mean not just "wrap the long line" but "the whole
> paragraph should start at the beginning of the line, since it's no
> longer part of the list element", then
>
> Acked-by: Jeff King <peff@peff.net>
I hope I understood corretly when I added your ACK to the patch.
Thanks,
Gustaf
Documentation/git-shortlog.txt | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index e14720b..854bf7a 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -37,16 +37,14 @@ OPTIONS
FILES
-----
-
-.mailmap::
- If this file exists, it will be used for mapping author email
- addresses to a real author name. One mapping per line, first
- the author name followed by the email address enclosed by
- '<' and '>'. Use hash '#' for comments. Example:
-
- # Keep alphabetized
- Adam Morrow <adam@localhost.localdomain>
- Eve Jones <eve@laptop.(none)>
+If the file .mailmap exists, it will be used for mapping author email
+addresses to a real author name. One mapping per line, first the
+author name followed by the email address enclosed by '<' and '>'. Use
+hash '#' for comments. Example:
+
+ # Keep alphabetized
+ Adam Morrow <adam@localhost.localdomain>
+ Eve Jones <eve@laptop.(none)>
Author
------
--
1.5.4.rc1.22.g4b71
^ permalink raw reply related
* Re: [PATCH] Fix for missing line in man page rendered for git shortlog
From: Jeff King @ 2007-12-23 18:46 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: gitster, git
In-Reply-To: <1198434891-25847-1-git-send-email-hendeby@isy.liu.se>
On Sun, Dec 23, 2007 at 07:34:51PM +0100, Gustaf Hendeby wrote:
> I hope I understood corretly when I added your ACK to the patch.
Yes, perfectly.
-Peff
^ permalink raw reply
* Re: [msysgit] how to detect git.exe directory?
From: Abdelrazak Younes @ 2007-12-23 19:45 UTC (permalink / raw)
To: Marco Costalba; +Cc: msysgit, Git Mailing List
In-Reply-To: <e5bfff550712230825o5e73bd3dm31057847106b8722@mail.gmail.com>
Marco Costalba wrote:
> Hi all,
>
> I'm progressing on qgit installer for windows, I have switched to
> MSVC for compiling Qt4 and qgit sources and I have to say that first
> results are very good, qgit.exe now seems to work without problems or
> artifacts and the speed is much more similar to what we achieve under
> the Linux platform (read much higher).
Glad you manage to do it by yourself. Sorry for not going further with
compilation as I promised but the git repository had only a MSVC2008
solution file and I have only MSVC2005 here. I tried to adapt our CMake
files to qgit but failed...
>
> So it seems Qt+mingw is not the _best_ possible solution.
I told you that ;-)
>
> Anyhow, under Vista you cannot simply copy qgit.exe in the git
> directory (OS barfs regarding some administrative rights, note that *I
> am* the administartor!), so to make qgit.exe work git.exe file must be
> in PATH.
>
> To easy the user and allowing to call qgit.exe double clicking on a
> nice desktop icon I need a way to know where git.exe is installed *at
> runtime*.
>
> So my question is: "What is the preferred way to detect git directory
> at runtime for msysgit files?"
If you use QProcess to launch git, maybe you could just use
QProcess::workingDirectory()?
Abdel.
^ permalink raw reply
* Re: how to detect git.exe directory?
From: Abdelrazak Younes @ 2007-12-23 19:51 UTC (permalink / raw)
To: msysgit-/JYPxA39Uh5TLH3MbocFFw; +Cc: git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e5bfff550712230853u1bc0160ap936c2d0a6fe0203b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Marco Costalba wrote:
>
> What I'm looking for is git.exe itself. If I run "git --exec-path" I
> get something along the lines "git executable not found..."
>
> I don't use dashed command inside qgit, so I run "git log ..." not
> "git-log ...", but the git.exe should be known to qgit or in path.
If you're planning to create an installer for qgit, a good solution
would be to ask the user to manually point to the msysgit installation
directory if not found in the path. Then the installer could just save
the directory to an ini file along 'qgit.exe'.
Abdel.
^ permalink raw reply
* Re: [msysgit] how to detect git.exe directory?
From: Marco Costalba @ 2007-12-23 20:04 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: msysgit, Git Mailing List
In-Reply-To: <476EBADE.6080805@free.fr>
On Dec 23, 2007 8:45 PM, Abdelrazak Younes <younes.a@free.fr> wrote:
> Marco Costalba wrote:
> > Hi all,
> >
> Glad you manage to do it by yourself. Sorry for not going further with
> compilation as I promised but the git repository had only a MSVC2008
> solution file and I have only MSVC2005 here. I tried to adapt our CMake
> files to qgit but failed...
>
Don't worry, I have installed MSVC2008, compiled Qt4 (and everithing
went smooth) and bruefly tested qgit: it really seems to work, now
following steps are:
- Detect git.exe directory at runtime also when is not in PATH (see below)
- Manage to package qgit and others needed files in a windows
installer (I know very little about this)
>
> > So my question is: "What is the preferred way to detect git directory
> > at runtime for msysgit files?"
>
> If you use QProcess to launch git, maybe you could just use
> QProcess::workingDirectory()?
>
It's not the repository that I don't find, but the git binary
directory. I explain better. If I open a console under windows with
cmd.exe and type "git" when I hit enter button I have an error message
that says that "command git is not known"
This is because git.exe directory is _not_ (normally) in PATH
environment variable.
So, or msysgit installation *modifies* the user PATH adding the bin
directory, or I have to found git bin directory myself and manage to
add to the PATH of qgit process environment.
The question is: "How I find git.exe??"
Marco
^ permalink raw reply
* Re: Pushing and fetching sha1s directly
From: Johannes Schindelin @ 2007-12-23 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Finn Arne Gangstad, git
In-Reply-To: <7vlk7mwchm.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 22 Dec 2007, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
> > Currently there seems to be no way of pusing a sha1 directly, or to
> > fetch a sha1 directly. When working with submodules, it is convenient
> > to be able to work with detached HEADs, so it would be good if this
> > could be supported also by fetch and push.
>
> For fetch, I would normally say "check the list archives", but it was
> very long time ago that it was proposed and discussed. It has some
> security and performance implications.
To enhance on that: sometimes you need to delete a branch in a hurry,
because you publicised some secret code/file. In that case, you do _not_
want people being able to fetch arbitrary commits.
Ciao,
Dscho
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Stefan Richter @ 2007-12-23 20:14 UTC (permalink / raw)
To: Dieter Ries; +Cc: Robert P. J. Day, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <476E5CFC.5070301@gmx.de>
Dieter Ries wrote:
> Robert P. J. Day schrieb:
>> when i got started with git, what i really wanted
>> was a list of what i (as a simple, non-developer user) could do once i
>> cloned a repository.
>>
>> to that end, i put together my own little reference list of git
>> commands. for example, i collected ways to examine my repository --
>> git commands like branch, tag, log/shortlog, what-changed, show, grep,
>> blame, that sort of thing. exactly the kind of stuff a new user might
>> want to know about, even without the ability to change anything.
>
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?
Here are three out of four things which I do frequently with git repos:
I look at
- commits and blobs in other people's trees with gitweb,
- commits in a local tree with gitk,
- specific changes to source code with qgit, using it as "git blame"
GUI.
(The fourth thing is feeding a driver subsystem git tree at kernel.org
using a minimum number of git commands. Everything else which I do with
git I do so infrequently that I have to reread manuals all the time.)
--
Stefan Richter
-=====-=-=== ==-- =-===
http://arcgraph.de/sr/
^ permalink raw reply
* Re: cvsimport: trying to convert freebsd cvs to git
From: Martin Langhoff @ 2007-12-23 21:13 UTC (permalink / raw)
To: Jeff King; +Cc: Miklos Vajna, git, Stefan Sperling
In-Reply-To: <20071223172913.GA9297@sigill.intra.peff.net>
On Dec 24, 2007 6:29 AM, Jeff King <peff@peff.net> wrote:
> On Sat, Dec 22, 2007 at 06:18:01PM +0100, Miklos Vajna wrote:
>
> > then i tried:
> >
> > $ time git cvsimport -d `pwd`/cvs -C src.git src
> > Initialized empty Git repository in /home/vmiklos/git/freebsd/src.git/.git/
> > malformed revision
>
> This is the actual error; everything else is git-cvsimport failing to
> notice the problem and continuing anyway.
>
> I will take a look and see if it is simple to stop the process here and
> produce a better error message.
Indeed. Running verbose will name the branch name that triggers that
error. One thing I find useful is to capture the commandline passed to
cvsps (using ps), stopping cvsimport+cvsps, and running cvsps by hand
with the same commandline (remember to set TZ=UTC in the
environment!), saving STDOUT to a file.
Once you have the file, you can feed it to cvsimport with the -P
parameter (IIRC). Usually cvsimport errors are all about wonky cvsps
output.
For the record, I normally do my initial imports with Keith's
parsecvs, and then run incrementals using git-cvsimport. These
incrementals aren't 100% perfect, so I routinely check for 'drift'.
cheers,
m
^ permalink raw reply
* Re: Commit a series of patches to SVN without rebase
From: Jörg Sommer @ 2007-12-23 23:59 UTC (permalink / raw)
To: git
In-Reply-To: <20071222045340.GA21524@soma>
Hi Eric,
Eric Wong <normalperson@yhbt.net> wrote:
> Jörg Sommer <joerg@alea.gnuu.de> wrote:
>> I've a number of patches in git I want to send to a SVN repository. git
>> svn dcommit does a rebase after each commit which makes the whole commit
>> takes very long. Is it possible to skip the rebase? All patches are in
>> one branch without merges, a simple chain. Is it save to use --no-rebase
>> in this case?
>
> Right now, only if the changes don't depend on each other (they all
> modify different files).
May I ask you what the rational behind doing a rebase every time is? Is
it needed? Why is it not possible to send all commits and do one rebase
after the last one?
Bye, Jörg.
--
Wer A sagt, muß nicht B sagen. Er kann auch erkennen, daß A falsch war.
(Erich Kästner)
^ permalink raw reply
* Re: [PATCH] builtin-clone: Implement git clone as a builtin command.
From: J. Bruce Fields @ 2007-12-24 1:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristian Høgsberg, Daniel Barkalow, git
In-Reply-To: <7vejdsbo7d.fsf@gitster.siamese.dyndns.org>
On Tue, Dec 11, 2007 at 07:12:54PM -0800, Junio C Hamano wrote:
> * HEAD discovery
>
> The code can be lifted from the scripted version and transplanted to
> git-remote. And to make "origin" and other remotes added by "git
> remote add", this logic needs to be moved to "git remote".
A rough first attempt appended.
Cleaning up in "remote rm" is a bit of a pain once a remote can contain
symbolic-refs. Would it make sense to add something like a "git
update-ref -D <refname>" that deletes anything at that path with no
checking?
Thanks for outlining these remote improvements, by the way, I really
look forward to them. I'll do what I can, but will probably be much too
slow....
--b.
commit fecdb5c0d118767c216302e2c91950cca04f9a26
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date: Fri Dec 21 19:55:09 2007 -0500
git-remote: make add -f guess HEAD, as clone does
Has a few ugly bits.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
diff --git a/git-remote.perl b/git-remote.perl
index d13e4c1..3299029 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -270,12 +270,57 @@ sub show_remote {
return 0;
}
+sub guess_head {
+ my ($subdir, $head_sha1) = @_;
+ my $found = 0;
+
+ for ($git->command('for-each-ref', "$subdir")) {
+ chomp;
+ m|^([0-9a-f]{40})\s[a-z]+\s$subdir/(.*)$| || die();
+ my ($sha1, $ref) = ($1, $2);
+
+ if ($sha1 eq $head_sha1) {
+ $found = $ref;
+ # prefer "master" if it matches:
+ if ($ref eq "master") {
+ last;
+ }
+ }
+ }
+ return $found
+}
+
+sub fix_head {
+ my ($remote) = @_;
+
+ my $subdir = "refs/remotes/$remote";
+ my $head_sha1 = $git->command(qw(rev-parse --verify), "$subdir/HEAD");
+ chomp($head_sha1);
+
+ unlink($git->repo_path."/$subdir/HEAD");
+ my $found = guess_head($subdir, $head_sha1);
+ if (!$found) {
+ # Just leave it as a a bare sha1
+ $git->command("update-ref", "$subdir/HEAD", "$head_sha1");
+ return;
+ }
+ $git->command("symbolic-ref", "$subdir/HEAD", "$subdir/$found");
+ $git->command("config", "branch.$found.remote", "$remote");
+ $git->command("config", "branch.$found.merge", "refs/heads/$found");
+}
+
sub add_remote {
my ($name, $url, $opts) = @_;
if (exists $remote->{$name}) {
print STDERR "remote $name already exists.\n";
exit(1);
}
+
+ # Tricky!: magic HEAD setup should only be done when
+ # "mirror", "master", and "track" options aren't given.
+ # And for orthagonality perhaps we should also provide a
+ # "track head" optio., compatible with "track" but not
+ # the other two....
$git->command('config', "remote.$name.url", $url);
my $track = $opts->{'track'} || ["*"];
@@ -286,7 +331,17 @@ sub add_remote {
"+refs/heads/$_:refs/remotes/$name/$_");
}
if ($opts->{'fetch'}) {
- $git->command('fetch', $name);
+ if (!$opts->{'mirror'} && !$opts->{'master'}
+ && !$opts->{'track'}) {
+ my $refspec = "+refs/heads/*:refs/remotes/$name/*";
+
+ # XXX: can there be a remote refs/heads/HEAD??
+ $git->command('fetch', $name, $refspec,
+ "HEAD:refs/remotes/$name/HEAD");
+ fix_head($name);
+ } else {
+ $git->command('fetch', $name);
+ }
}
if (exists $opts->{'master'}) {
$git->command('symbolic-ref', "refs/remotes/$name/HEAD",
@@ -338,11 +393,11 @@ sub rm_remote {
}
};
- my @refs = $git->command('for-each-ref',
- '--format=%(refname) %(objectname)', "refs/remotes/$name");
- for (@refs) {
- ($ref, $object) = split;
- $git->command(qw(update-ref -d), $ref, $object);
+ # Ugh: update-ref doesn't work on symref (as "HEAD" may be),
+ # but the following won't work on packed refs, for example.
+ for ($git->command('for-each-ref',
+ '--format=%(refname)', "refs/remotes/$name")) {
+ unlink($git->repo_path."/$_");
}
return 0;
}
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 636aec2..5576f2a 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -69,7 +69,7 @@ test_expect_success 'add another remote' '
tokens_match "origin second" "$(git remote)" &&
check_remote_track origin master side &&
check_remote_track second master side another &&
- check_tracking_branch second master side another &&
+ check_tracking_branch second HEAD master side another &&
git for-each-ref "--format=%(refname)" refs/remotes |
sed -e "/^refs\/remotes\/origin\//d" \
-e "/^refs\/remotes\/second\//d" >actual &&
^ permalink raw reply related
* Re: cvsimport: trying to convert freebsd cvs to git
From: Jeff King @ 2007-12-24 3:05 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, Stefan Sperling
In-Reply-To: <20071222171801.GE15286@genesis.frugalware.org>
On Sat, Dec 22, 2007 at 06:18:01PM +0100, Miklos Vajna wrote:
> $ time git cvsimport -d `pwd`/cvs -C src.git src
> Initialized empty Git repository in /home/vmiklos/git/freebsd/src.git/.git/
> malformed revision
> fatal: refs/heads/origin: not a valid SHA1
> fatal: master: not a valid SHA1
> warning: You appear to be on a branch yet to be born.
> warning: Forcing checkout of HEAD.
> fatal: just how do you expect me to merge 0 trees?
> checkout failed: 256
I looked into this a bit more. The error is definitely coming from
cvsps. I can't even get a reasonable cvsps output for this repo
(presumably because of behind-the-scenes hackery on the RCS files).
E.g., try making a module with _just_
"src/release/Attic/MIRROR.SITES,v"; I can't even get a reasonable cvsps
output on that.
You might have better results with one of the other importers that have
been suggested, most of which are more robust in the face of CVS
oddities.
That being said, it's awful that git-cvsimport doesn't stop when cvsps
exits with an error, producing all of those meaningless errors. Patch
will follow.
-Peff
^ permalink raw reply
* [PATCH] cvsimport: die on cvsps errors
From: Jeff King @ 2007-12-24 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git, Stefan Sperling
In-Reply-To: <20071224030551.GA12495@sigill.intra.peff.net>
We were not previously checking the exit status of cvsps at
all. If it exited before producing any useful output, we
ended up with an empty import, which caused a spew of
confusing error messages from other parts of git:
$ git-cvsimport foo
Initialized empty Git repository in ...
some error from cvsps
fatal: refs/heads/origin: not a valid SHA1
fatal: master: not a valid SHA1
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of HEAD.
fatal: just how do you expect me to merge 0 trees?
checkout failed: 256
Now we get:
$ git-cvsimport foo
Initialized empty Git repository in ...
some error from cvsps
git-cvsimport: fatal: cvsps reported error
Signed-off-by: Jeff King <peff@peff.net>
---
On Sun, Dec 23, 2007 at 10:05:51PM -0500, Jeff King wrote:
> That being said, it's awful that git-cvsimport doesn't stop when cvsps
> exits with an error, producing all of those meaningless errors. Patch
> will follow.
And here it is.
git-cvsimport.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 1fa9a22..6d8ff93 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -632,6 +632,7 @@ unless ($opt_P) {
print $cvspsfh $_;
}
close CVSPS;
+ $? == 0 or die "git-cvsimport: fatal: cvsps reported error\n";
close $cvspsfh;
} else {
$cvspsfile = $opt_P;
--
1.5.4.rc1.1119.g1e6bc-dirty
^ permalink raw reply related
* Re: [PATCH] cvsimport: die on cvsps errors
From: Martin Langhoff @ 2007-12-24 3:21 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Miklos Vajna, git, Stefan Sperling
In-Reply-To: <20071224030819.GA15485@sigill.intra.peff.net>
> We were not previously checking the exit status of cvsps
> at all.
Acked. We should have done this ages ago. Thanks!
m
^ permalink raw reply
* [PATCH] Document git rev-list --first-parent
From: Avi Kivity @ 2007-12-24 8:20 UTC (permalink / raw)
To: git
Document git rev-list's --first-parent option. Documentation taken from
git log.
Signed-off-by: Avi Kivity <avi@qumranet.com>
---
Documentation/git-rev-list.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index a03f9fe..b049086 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[ \--min-age=timestamp ]
[ \--sparse ]
[ \--no-merges ]
+ [ \--first-parent ]
[ \--remove-empty ]
[ \--full-history ]
[ \--not ]
@@ -256,6 +257,11 @@ limiting may be applied.
Do not print commits with more than one parent.
+--first-parent::
+ Follow only the first parent commit upon seeing a merge
+ commit. This option gives a better overview of the
+ evolution of a particular branch.
+
--not::
Reverses the meaning of the '{caret}' prefix (or lack thereof)
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] Document git rev-list --first-parent
From: Junio C Hamano @ 2007-12-24 8:30 UTC (permalink / raw)
To: Avi Kivity; +Cc: git
In-Reply-To: <1198484450-16454-1-git-send-email-avi@qumranet.com>
Avi Kivity <avi@qumranet.com> writes:
> Document git rev-list's --first-parent option. Documentation taken from
> git log.
> ...
> +--first-parent::
> + Follow only the first parent commit upon seeing a merge
> + commit. This option gives a better overview of the
> + evolution of a particular branch.
> +
I am afraid that this description is not sufficient. The
history given by --first-parent is useful only in a very limited
use case, and the user needs to be aware of it.
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Avi Kivity @ 2007-12-24 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3atstry4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Avi Kivity <avi@qumranet.com> writes:
>
>
>> Document git rev-list's --first-parent option. Documentation taken from
>> git log.
>> ...
>> +--first-parent::
>> + Follow only the first parent commit upon seeing a merge
>> + commit. This option gives a better overview of the
>> + evolution of a particular branch.
>> +
>>
>
> I am afraid that this description is not sufficient. The
> history given by --first-parent is useful only in a very limited
> use case, and the user needs to be aware of it.
>
I don't know which use case you are referring to; I can describe my own:
I have a post-receive hook which sends all patches since the last push.
To avoid sending the constituent commits of a pull, I use --first-parent
to throw away anything I did not commit directly.
[Initially I used ^origin to cancel out these merges, but that failed as
soon as I merged from some other branch]
I'm not sure this is what you meant. Let me know, and I will update the
patch.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [ANNOUNCE] qgit2.1rc1_win.exe
From: Marco Costalba @ 2007-12-24 9:13 UTC (permalink / raw)
To: msysGit, Git Mailing List
Here
http://digilander.libero.it/mcostalba/qgit2.1rc1_win.exe
You can find an auto-extract zip file with a version of qgit built for
Windows (Vista).
Requires msysgit (http://code.google.com/p/msysgit/)
Is not a real installation, no registry or other Windows resources
touched, just decompress in a directory, read the README and have fun.
Marco
^ 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