* 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
* Re: [PATCH] Document git rev-list --first-parent
From: Junio C Hamano @ 2007-12-24 9:13 UTC (permalink / raw)
To: Avi Kivity; +Cc: git
In-Reply-To: <476F6F95.1030506@qumranet.com>
Avi Kivity <avi@qumranet.com> writes:
> 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...
Please read the commit log message you snarfed the description
again.
First-parent is useful only if you are the primary integrator
and do not fast-forward from other people. Only in that case,
you will see the overview of "the primary integration branch".
Otherwise you will observe the history viewed by whoever
happened to make a merge, which would switch every time you
cross the fast-forward boundary.
Making it sound as if it always will give a better overview is
misleading.
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Avi Kivity @ 2007-12-24 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprwwsbey.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Avi Kivity <avi@qumranet.com> writes:
>
>
>> 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...
>>
>
> Please read the commit log message you snarfed the description
> again.
>
>
[I assume you mean 0053e902; I just copied the output of git log --help]
> First-parent is useful only if you are the primary integrator
> and do not fast-forward from other people. Only in that case,
> you will see the overview of "the primary integration branch".
> Otherwise you will observe the history viewed by whoever
> happened to make a merge, which would switch every time you
> cross the fast-forward boundary.
>
>
Well, my use case is different. All of the development merges are
fast-forwards (or plain patch applications); the only multiple-parent
merges are pulls I do from the main tree in order to advance the
baseline, or from upstream submission branches (which are very
similar). So, for me --first-parent means "show me actual development,
not syncs with upstream or cleanup branches".
> Making it sound as if it always will give a better overview is
> misleading.
>
I'll try to come up with better wording and submit a new patch.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Junio C Hamano @ 2007-12-24 9:58 UTC (permalink / raw)
To: Avi Kivity; +Cc: git
In-Reply-To: <476F7EA4.1030001@qumranet.com>
Avi Kivity <avi@qumranet.com> writes:
> Junio C Hamano wrote:
>> Avi Kivity <avi@qumranet.com> writes:
>>
>>
>>> Junio C Hamano wrote:
>>>
>>>> Avi Kivity <avi@qumranet.com> writes:
>>>>
>>>>
>>>>> Document git rev-list's --first-parent option. Documentation taken from
>>>>> git log.
>> ...
> [I assume you mean 0053e902; I just copied the output of git log --help]
Ahh, sorry, I thought you did "log -S--first-parent".
> Well, my use case is different. All of the development merges are
> fast-forwards (or plain patch applications); the only multiple-parent
> merges are pulls I do from the main tree in order to advance the
> baseline,...
Yeah, that is what I meant as a special case. If you submit
patches and rebase the remainder of your changes to the updated
upstream (as x.org folks seem to do), then the --first-parent
history will not be your own development but "the global trunk
history." If you are the top-level maintainer and your pull
sometimes ends up as a fast forward and sometimes a real merge,
you will sometimes get a full history of a topic done by
somebody else (if that person rebased on top of you) or just a
summary single merge (otherwise), and the distinction between
these two cases does not have anything to do with whose commits
they are (i.e. mine vs others) or the scope of the changes
(i.e. the trunk history vs side branch development). It would
not be as useful as the "looking at the list of one's own
commits while summarizing out others' developments as merge
commits" world view the --first-parent would give you in your
history.
^ permalink raw reply
* Re: [PATCH] Document git rev-list --first-parent
From: Avi Kivity @ 2007-12-24 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejdcs9cb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>> Well, my use case is different. All of the development merges are
>> fast-forwards (or plain patch applications); the only multiple-parent
>> merges are pulls I do from the main tree in order to advance the
>> baseline,...
>>
>
> Yeah, that is what I meant as a special case. If you submit
> patches and rebase the remainder of your changes to the updated
> upstream (as x.org folks seem to do), then the --first-parent
> history will not be your own development but "the global trunk
> history." If you are the top-level maintainer and your pull
> sometimes ends up as a fast forward and sometimes a real merge,
> you will sometimes get a full history of a topic done by
> somebody else (if that person rebased on top of you) or just a
> summary single merge (otherwise), and the distinction between
> these two cases does not have anything to do with whose commits
> they are (i.e. mine vs others) or the scope of the changes
> (i.e. the trunk history vs side branch development). It would
> not be as useful as the "looking at the list of one's own
> commits while summarizing out others' developments as merge
> commits" world view the --first-parent would give you in your
> history.
>
Sorry, I'm confused now. I'll try to explain more carefully what I'm doing.
I'm a mid-level maintainer for a particular subsystem (kvm). I merge
patchsets from others and do my own work, but I am careful to keep
everything linear (no real merges in the git sense). Every once in a
while I merge from upstream or some other tree, but these are never kvm
developments. Every merge window I rebase the development branch to
upstream, removing commits that were later reverted, and merging fixes
into the patches that introduce them and push the result to Linus.
Hopefully that's clear as I'm not much of an ascii artist.
So, for me --first-parent means "commits to the development branch of
kvm", whether by myself or someone else. It specifically excludes kvm
commits to mainline, since that would result in a bunch of duplicated
commits. But it seems to be quite different from what you're describing.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [FIXED PATCH] git-describe: Add a --match option to limit considered tags.
From: Pierre Habouzit @ 2007-12-24 11:18 UTC (permalink / raw)
To: Git ML
In-Reply-To: <20071222180244.GD23262@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 5198 bytes --]
Rework get_rev_name to return NULL rather than "undefined" when a reference
is undefined. If --undefined is passed (default) git-name-rev prints
"undefined" for the name, else it die()s.
Make git-describe use --no-undefined when calling git-name-rev so that
--contains behavior matches the standard git-describe one.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On sam, déc 22, 2007 at 06:02:44 +0000, Pierre Habouzit wrote:
> Like I said on IRC, I saw that git describe --contains has a bad
> behaviour:
>
> $ git describe --match='asd*' HEAD; echo $?
> fatal: cannot describe 'e272415ab7da3bde51af2ce95c88d7be3abfba28'
> 128
> $ git describe --contains HEAD; echo $?
> undefined
> 0
Okay here is a patch to have git-name-rev have a strict mode where
it rejects undefined's. With this patch:
$ git describe --contains HEAD
fatal: cannot describe 'e26a806b93f2f2f2354831ce0f943347a8ba7c3e'
This patch is minimal and looks safe for master to me. A better patch
would probably to have shared some logic between name-rev and
describe, but this would have been a quite larger patch, and I was
uncomfortable with it.
builtin-describe.c | 3 ++-
builtin-name-rev.c | 34 ++++++++++++++++++++++++----------
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/builtin-describe.c b/builtin-describe.c
index 18eab47..3428483 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -271,10 +271,11 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
save_commit_buffer = 0;
if (contains) {
- const char **args = xmalloc((5 + argc) * sizeof(char*));
+ const char **args = xmalloc((6 + argc) * sizeof(char*));
int i = 0;
args[i++] = "name-rev";
args[i++] = "--name-only";
+ args[i++] = "--no-undefined";
if (!all) {
args[i++] = "--tags";
if (pattern) {
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index a0c89a8..f22c8b5 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -125,18 +125,18 @@ static int name_ref(const char *path, const unsigned char *sha1, int flags, void
}
/* returns a static buffer */
-static const char* get_rev_name(struct object *o)
+static const char *get_rev_name(struct object *o)
{
static char buffer[1024];
struct rev_name *n;
struct commit *c;
if (o->type != OBJ_COMMIT)
- return "undefined";
+ return NULL;
c = (struct commit *) o;
n = c->util;
if (!n)
- return "undefined";
+ return NULL;
if (!n->generation)
return n->tip_name;
@@ -159,7 +159,7 @@ static char const * const name_rev_usage[] = {
int cmd_name_rev(int argc, const char **argv, const char *prefix)
{
struct object_array revs = { 0, 0, NULL };
- int all = 0, transform_stdin = 0;
+ int all = 0, transform_stdin = 0, allow_undefined = 1;
struct name_ref_data data = { 0, 0, NULL };
struct option opts[] = {
OPT_BOOLEAN(0, "name-only", &data.name_only, "print only names (no SHA-1)"),
@@ -169,6 +169,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
OPT_GROUP(""),
OPT_BOOLEAN(0, "all", &all, "list all commits reachable from all refs"),
OPT_BOOLEAN(0, "stdin", &transform_stdin, "read from stdin"),
+ OPT_BOOLEAN(0, "undefined", &allow_undefined, "allow to print `undefined` names"),
OPT_END(),
};
@@ -226,7 +227,7 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
else if (++forty == 40 &&
!ishex(*(p+1))) {
unsigned char sha1[40];
- const char *name = "undefined";
+ const char *name = NULL;
char c = *(p+1);
forty = 0;
@@ -240,11 +241,10 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
}
*(p+1) = c;
- if (!strcmp(name, "undefined"))
+ if (!name)
continue;
- fwrite(p_start, p - p_start + 1, 1,
- stdout);
+ fwrite(p_start, p - p_start + 1, 1, stdout);
printf(" (%s)", name);
p_start = p + 1;
}
@@ -260,18 +260,32 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
max = get_max_object_index();
for (i = 0; i < max; i++) {
struct object * obj = get_indexed_object(i);
+ const char *name;
if (!obj)
continue;
if (!data.name_only)
printf("%s ", sha1_to_hex(obj->sha1));
- printf("%s\n", get_rev_name(obj));
+ name = get_rev_name(obj);
+ if (name)
+ printf("%s\n", name);
+ else if (allow_undefined)
+ printf("undefined\n");
+ else
+ die("cannot describe '%s'", sha1_to_hex(obj->sha1));
}
} else {
int i;
for (i = 0; i < revs.nr; i++) {
+ const char *name;
if (!data.name_only)
printf("%s ", revs.objects[i].name);
- printf("%s\n", get_rev_name(revs.objects[i].item));
+ name = get_rev_name(revs.objects[i].item);
+ if (name)
+ printf("%s\n", name);
+ else if (allow_undefined)
+ printf("undefined\n");
+ else
+ die("cannot describe '%s'", sha1_to_hex(revs.objects[i].item->sha1));
}
}
--
1.5.4.rc1.1123.ge26a8
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] cvsimport: die on cvsps errors
From: Miklos Vajna @ 2007-12-24 12:43 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Stefan Sperling
In-Reply-To: <20071224030819.GA15485@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 301 bytes --]
On Sun, Dec 23, 2007 at 10:08:19PM -0500, Jeff King <peff@peff.net> 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.
great, thanks :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Miklos Vajna @ 2007-12-24 12:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <476E42BF.1010300@garzik.org>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
On Sun, Dec 23, 2007 at 06:13:03AM -0500, Jeff Garzik <jeff@garzik.org> wrote:
> Another year, another update! :)
>
> The kernel hacker's guide to git has received some updates:
>
> http://linux.yyz.us/git-howto.html
one minor note:
i would suggest using:
$ git shortlog master..HEAD
instead of
$ git log master..HEAD | git shortlog
to avoid unnecessary complexity :)
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Robert P. J. Day @ 2007-12-24 14:19 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:
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?
FYI, i'm typing in my own reference list as we speak here:
http://www.crashcourse.ca/wiki/index.php/Git
still quite a bit to go, but you can get the overall idea. new
sections should be appearing there as the morning progresses.
rday
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* [PATCH] Force new line at end of commit message
From: Bernt Hansen @ 2007-12-24 14:31 UTC (permalink / raw)
To: Shawn O. Pearce, Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <87ve6ub3u7.fsf@gollum.intra.norang.ca>
git rebase --interactive formats the combined commit log message
incorrectly when squashing 3 or more commits which have no newline on
the last line of the commit message.
Signed-off-by: Bernt Hansen <bernt@alumni.uwaterloo.ca>
---
This may well be the wrong fix for this problem but my attempts to make
git-rebase--interactive.sh append a newline breaks too many tests in the
test suite.
I tried something like this in git-rebase--interactive.sh:
- git cat-file commit HEAD | sed -e '1,/^$/d'
+ git cat-file commit HEAD | sed -e '1,/^$/d' -e '$a\'
Sorry I don't have an automated test for git-gui. Are there any?
git-gui/lib/commit.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index b2d2d53..1c0586c 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -303,7 +303,7 @@ A rescan will be automatically started now.
puts stderr [mc "warning: Tcl does not support encoding '%s'." $enc]
fconfigure $msg_wt -encoding utf-8
}
- puts -nonewline $msg_wt $msg
+ puts $msg_wt $msg
close $msg_wt
# -- Create the commit.
--
1.5.4.rc1.22.g88b9
^ permalink raw reply related
* Re: [FIXED PATCH] git-describe: Add a --match option to limit considered tags.
From: Pierre Habouzit @ 2007-12-24 15:57 UTC (permalink / raw)
To: Git ML
In-Reply-To: <20071224111822.GA10356@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
Woops I borked the mail, the subject was supposed to be:
Subject: [PATCH] Add a --(no-)undefined option to git-name-rev.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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