* Re: [PATCH] Enable git rev-list to parse --quiet
From: Junio C Hamano @ 2008-07-20 18:31 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <20080720120437.GC15586@mail.local.tull.net>
Nick Andrew <nick@nick-andrew.net> writes:
> Exiting a process from within a callback function seems to me to violate
> the principle of least surprise.
Huh? Who is surprised?
I do not know who taught you that "do not exit in a callback" dogma, but I
suspect it was misrepresented when it was taught to you.
A library that calls your function back could be structured this way:
lib() {
perform some set-up that affects external world;
call your callback function;
clean-up the effect of previous set-up action;
}
and exiting from your callback function is not a good idea as it prevents
the library from doing the necessary clean-up in such a case.
But that is true just in a(n extremely) general case. Your generalization
is not particularly useful, methinks, and use of exit(0) in the patch is
very well justified (rather, I do not think they even need justifying).
- The callback you are looking at is not a general purpose callback for
other program's use, but written for a specific use of rev-list;
- The purpose of that exit(0) is to signal "there is something" as
quickly as possible, which was what you wanted out of rev-list;
- Revision traversal is a read-only operation and we know that there is
no externally visible set-up done in the function you are calling to
get your callback called, that needs cleaning up later --- this is not
expected to change, as there are longstanding existing callback
functions supplied to traverse_commit_list() that die() upon seeing
errors already.
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Junio C Hamano @ 2008-07-20 18:30 UTC (permalink / raw)
To: Jay Soffian
Cc: Johannes Schindelin, Tarmigan, Junio C Hamano, git,
Michael J Gruber
In-Reply-To: <76718490807200545l653bbda1l4d13f1e1e698c855@mail.gmail.com>
"Jay Soffian" <jaysoffian@gmail.com> writes:
> On Sun, Jul 20, 2008 at 6:56 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Two things:
>>
>> - add and commit are two _different_ operations, not only in name, but
>> also in nature. The fact that "commit -a" calls "add" is a _pure_
>> convenience. It does not change the fact that "add" and "commit" are
>> completely, utterly different.
>>
>> - if you are a heavy user of "commit -a", chances are that your history is
>> not really useful, because you committed unrelated changes accidentally
>> in the same commit.
>>
>> The latter point, BTW, is the reason I _never_ teach the "-a" option
>> (actually, I teach no option at all) in my first two Git lessons.
>
> I don't like "commit -a" and never use it and wonder why a
> short-option was wasted on it.
>
> I do like the new "add -a" (thank you Junio) but I will rarely use it.
I do not understand either of you. If for whatever reason "add -A" makes
sense in your workflow, it's a sign that you are extremely disciplined
that changes in your working tree at one point of time where you would
issue "add -A" are concentrated on a single topic, and at one of such
points you may want to commit. For such a disciplined person, "commit -a"
would make perfect sense there.
So for such people who would find "add -A" useful, "commit -a" will not be
"unrelated changes in the same commit". And for such people, I would even
say "commit -A" would be even more useful, too.
I'll never be in that camp of perfect people myself, though..
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <20080720130407.GF10347@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples;...
I personally think -sstrategy=string1,string2,... is simply a bad taste.
Why force yourself to parse things by having the users to concatenate
something that the user could give us separated? If you care about the
order and association between strategy and their options, you can always
do:
-s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
-s strategy2 -X option-1-for-strategy-2 ...
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2008-07-20 18:27 UTC (permalink / raw)
To: Lars Noschinski; +Cc: git
In-Reply-To: <20080720112034.GA27984@lars.home.noschinski.de>
Lars Noschinski <lars-2008-1@usenet.noschinski.de> writes:
> * Junio C Hamano <gitster@pobox.com> [08-07-20 03:59]:
>>Lars Noschinski (2):
>> cvsserver: Add support for packed refs
>> cvsserver: Add cvs co -c support
>
> Any specific reason why you did not merge the test for packed refs
> support? Was it considered superfluous?
No, it was not even considered. This phenomenon is called "lost in the
noise" ;-)
Thanks for reminding. Applied.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Junio C Hamano @ 2008-07-20 18:23 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Fredrik Tolf, Keith Packard, git, Edward Z. Yang,
Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807201214060.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Ah, right. Would it be OK to add the `-x' flag to ssh instead?
>
> I think this would be the correct way, together with "-T".
>
>> I imagine that that might make git less portable to SSH implementations
>> other than OpenSSH, but I don't know if that is considered a problem.
>
> Well, this was to be expected, after what I wrote in response to 3. in
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
>
> Reality always catches up with you, and here again we see that plink and
> other siblings of OpenSSH should be best handled with scripts, preferably
> ones that strip out options they do not recognize.
>
> IOW something like
>
> -- snip --
> #!/bin/bash
>
> plinkopt=
> while test $# != 0
> do
> case "$1" in
> -p)
> plinkopt="$plinkopt -P $2"
> shift
> ;;
> -*)
> # unrecognized; strip out
> ;;
> *)
> break
> ;;
> esac
> shift
> done
>
> exec plink $plinkopt "$@"
> -- snap --
I think that is a very sensible approach, but just like we have a few
"built-in" function-header regexps with customization possibilities for
the user, we might want to:
* Have that "-x", "-T" in the command line we generate for OpenSSH;
* Allow users to specify OpenSSH substitute via a configuration and/or
environment variable, and have them use your script; and
* Have a built-in logic for selected and common "OpenSSH substitute",
e.g. plink.
There is no reason to make users suffer an extra redirection for common
enough alternatives.
Here is to get it started...
connect.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/connect.c b/connect.c
index 574f42f..c72dd9e 100644
--- a/connect.c
+++ b/connect.c
@@ -599,12 +599,36 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
conn->argv = arg = xcalloc(6, sizeof(*arg));
if (protocol == PROTO_SSH) {
const char *ssh = getenv("GIT_SSH");
+ const char *ssh_basename;
if (!ssh) ssh = "ssh";
+ ssh_basename = strrchr(ssh, '/');
+ ssh_basename = ssh_basename ? (ssh_basename + 1) : ssh;
+
*arg++ = ssh;
- if (port) {
- *arg++ = "-p";
- *arg++ = port;
+ /*
+ * Make sure to enlarge conn->argv if you add more
+ * paremeters here.
+ *
+ * We know how to invoke a few ssh implementations
+ * ourselves.
+ */
+ if (!strcmp(ssh_basename, "plink")) {
+ if (port) {
+ *arg++ = "-P";
+ *arg++ = port;
+ }
+ } else {
+ /*
+ * This is for stock OpenSSH, but you can have
+ * your custom wrapper script to parse this
+ * and invoke other ssh implementations after
+ * rearranging parameters as well.
+ */
+ if (port) {
+ *arg++ = "-p";
+ *arg++ = port;
+ }
}
*arg++ = host;
}
^ permalink raw reply related
* Re: git cvsimport and deleted files
From: Lars Noschinski @ 2008-07-20 18:05 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807201448020.3305@eeepc-johanness>
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [08-07-20 14:49]:
>>I just tried importing the CVS repository for a long-running project
>>(ppp) into git using git cvsimport. It looks like git cvsimport
>>doesn't notice when files have been deleted, so files that used to be
>>present and were subsequently deleted are present in the git tree for
>>the most recent commit.
>
>I never had that problem. See
>http://repo.or.cz/w/libvncserver.git?a=commit;h=8dead0759febaa7176507e1bde13ebd9d2a30720
>for a commit that was imported with cvsimport.
>
>So your issue must lie somewhere else.
I encountered such an issue some time ago in incremental mode, when
another person did some cvs branch stuff. The error persisted even as I
did a clean checkout, but disappeared, after I deleted all the cvsps
cache files.
I failed to report the error, because I had not much time for debugging
at that time and I would not have been able to publish the repository.
That's when I switched to fromcvs, which seems to work reliably so far
(and much faster), but requires a local repository.
^ permalink raw reply
* Re: git cvsimport and deleted files
From: Lars Noschinski @ 2008-07-20 18:04 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807201448020.3305@eeepc-johanness>
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [08-07-20 14:49]:
>> I just tried importing the CVS repository for a long-running project
>> (ppp) into git using git cvsimport. It looks like git cvsimport
>> doesn't notice when files have been deleted, so files that used to be
>> present and were subsequently deleted are present in the git tree for
>> the most recent commit.
>
>I never had that problem. See
>http://repo.or.cz/w/libvncserver.git?a=commit;h=8dead0759febaa7176507e1bde13ebd9d2a30720
>for a commit that was imported with cvsimport.
>
>So your issue must lie somewhere else.
I encountered such an issue some time ago in incremental mode, when
another person did some cvs branch stuff. The error persisted even as I
did a clean checkout, but disappeared, after I deleted all the cvsps
cache files.
I failed to report the error, because I had not much time for debugging
at that time and I would not have been able to publish the repository.
That's when I switched to fromcvs, which seems to work reliably so far (and
much faster), but requires a local repository.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-20 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807201214060.3305@eeepc-johanness>
On Sun, 2008-07-20 at 12:27 +0200, Johannes Schindelin wrote:
> Well, this was to be expected, after what I wrote in response to 3. in
> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
>
> Reality always catches up with you, and here again we see that plink and
> other siblings of OpenSSH should be best handled with scripts, preferably
> ones that strip out options they do not recognize.
Otherwise, an alternative may be to always install a script, say
`git-ssh', that would invoke the real SSH in a manner specific for the
platform. The exact script installed could even be parametrized by the
Makefile. For systems using OpenSSH, it would probably just consist of
`ssh -xT "$@"'.
What do you think?
Fredrik Tolf
^ permalink raw reply
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: André Goddard Rosa @ 2008-07-20 14:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080720112957.GE32184@machine.or.cz>
On Sun, Jul 20, 2008 at 8:29 AM, Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Jul 20, 2008 at 12:48:21AM -0700, Junio C Hamano wrote:
>> "git update-index --refresh", "git reset" and "git add --refresh" have
>> reported paths that have local modifications as "needs update" since the
>> beginning of git.
>>
>> Although this is logically correct in that you need to update the index at
>> that path before you can commit that change, it is now becoming more and
>> more clear, especially with the continuous push for user friendliness
>> since 1.5.0 series, that the message is suboptimal. After all, the change
>> may be something the user might want to get rid of, and "updating" would
>> be absolutely a wrong thing to do if that is the case.
>>
>> I prepared two alternatives to solve this. Both aim to reword the message
>> to more neutral "locally modified".
>>
>> This patch is a more straightforward variant that changes the message not
>> only for Porcelain commands ("add" and "reset") but also changes the
>> output from the plumbing command "update-index".
>>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> I believe this is a good thing. Scripts need to be modified for the
Thanks for doing that. I hope this goes mainline soon.
--
[]s,
André Goddard
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Johannes Schindelin @ 2008-07-20 13:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <20080720125841.GD10151@machine.or.cz>
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
> On Sun, Jul 20, 2008 at 02:33:46PM +0200, Johannes Schindelin wrote:
> > On Sun, 20 Jul 2008, Petr Baudis wrote:
> >
> > > On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
> > >
> > > > Pasky tried to convert all Perl scripts at once IIRC, and my
> > > > numerous problems just _making_ the Git scripts led me to rewrite
> > > > a few Perl scripts in C, so I could safely exclude the Perl
> > > > scripts from my personal fork.
> > >
> > > I don't remember any concrete report of such problems ever reaching
> > > me; exactly what trouble are you hitting with the Perl scripts using
> > > Git.pm? I will be glad to try to fix it.
> >
> > They reached you:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/23153
>
> running Git in-place without correctly setting the prefix is not
> supported anyway; git wrapper will still be using non-builtin commands
> from the prefix location instead of your fresh build.
There were none. Anyway, because Git makes it _really_ hard to run
in-place, I gave in. I run Git from $HOME/bin now.
> > http://thread.gmane.org/gmane.comp.version-control.git/22764/focus=22778
>
> It seems I fixed this right away?
That is not what I remember. I remember that I had the next issue right
away. I remember that there were problems with ActiveState Perl+Cygwin.
And I remember that the Git.xs was not merged in the end.
Anyway, this whole discussion is moot, methinks.
Let's concentrate back on the real issue: merging the two as-of-now
incompatible Perl modules. It really would be nice to have one pony with
one saddle in the end, so that the use of Lea's GSoC project is not
limited to gitweb with enabled caching.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-20 13:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20080720130407.GF10347@genesis.frugalware.org>
Hi,
On Sun, 20 Jul 2008, Miklos Vajna wrote:
> First, currently you can specify multiple strategies in the config
> (pull.twohead, pull.octopus) using a space separated list.
Oh, I did not mean to change that. I just misremembered.
> Second, we could allow custom strategies, as we started to discuss here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684
In my opinion, this would make it easier for interested parties to start
implementing that blame-based merge strategy I mentioned.
> Third, it would be nice to allow passing extra parameter(s) to the
> backends, but I do not know what concept is the best here. The
> strategy1=foo,stategy2=bar limits the input to a single string. Is that
> enough? Given that recursive=theirs was considered harmful, we don't
> have too much examples; for subtree the only parameter I could think of
> is the path, so a string there is enough.
>
> However, further strategies, like blame, could take more parameters,
> like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)
The common solution is like with gcc's -Wl option, which translates
commata into spaces, like so: "-Wl,--machine,i386" is added as "--machine
i386" to the linker command line.
Our own cvsimport implements the same principle:
$ git cvsimport -p -b,HEAD
will only update the main branch.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-merge.c: Fix option parsing
From: Miklos Vajna @ 2008-07-20 13:08 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, Junio C Hamano
In-Reply-To: <200807201434.47545.barra_cuda@katamail.com>
[-- Attachment #1: Type: text/plain, Size: 281 bytes --]
On Sun, Jul 20, 2008 at 02:34:47PM +0200, Michele Ballabio <barra_cuda@katamail.com> wrote:
> Now "git merge -m" needs a message, and errors out with the usage
> text if none is given.
> This way, t7600-merge.sh is fixed.
Thanks, I was about to fix this, but you were faster. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miklos Vajna @ 2008-07-20 13:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807191311220.3305@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Sat, Jul 19, 2008 at 01:19:46PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I still feel that "-s subtree=<blabla>,recursive=theirs" would be a
> viable way to go. And more intuitive than "-X".
>
> I'll just ask Miklos what he thinks of the idea, and to write the patch if
> he likes it, once he's back from the saddle. :-)
I think there are three steps here.
First, currently you can specify multiple strategies in the config
(pull.twohead, pull.octopus) using a space separated list. If we want to
change it to a coma-separated list, should we care about backwards
compatibility? There are tests for this, but it's undocumented (and my
patch to document it was rejected, saying we should not encourage people
to use it).
Second, we could allow custom strategies, as we started to discuss here:
http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=87684
Third, it would be nice to allow passing extra parameter(s) to the
backends, but I do not know what concept is the best here. The
strategy1=foo,stategy2=bar limits the input to a single string. Is that
enough? Given that recursive=theirs was considered harmful, we don't
have too much examples; for subtree the only parameter I could think of
is the path, so a string there is enough.
However, further strategies, like blame, could take more parameters,
like git blame -C<num> -M<othernum>. Or do I just overcomplicate it? ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Petr Baudis @ 2008-07-20 12:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <alpine.DEB.1.00.0807201420500.3305@eeepc-johanness>
Hi,
On Sun, Jul 20, 2008 at 02:33:46PM +0200, Johannes Schindelin wrote:
> On Sun, 20 Jul 2008, Petr Baudis wrote:
>
> > On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
> >
> > > Pasky tried to convert all Perl scripts at once IIRC, and my numerous
> > > problems just _making_ the Git scripts led me to rewrite a few Perl
> > > scripts in C, so I could safely exclude the Perl scripts from my
> > > personal fork.
> >
> > I don't remember any concrete report of such problems ever reaching me;
> > exactly what trouble are you hitting with the Perl scripts using Git.pm?
> > I will be glad to try to fix it.
>
> They reached you:
>
> http://article.gmane.org/gmane.comp.version-control.git/23153
running Git in-place without correctly setting the prefix is not
supported anyway; git wrapper will still be using non-builtin commands
from the prefix location instead of your fresh build.
> http://thread.gmane.org/gmane.comp.version-control.git/22764/focus=22778
It seems I fixed this right away?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: git cvsimport and deleted files
From: Johannes Schindelin @ 2008-07-20 12:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18563.10979.379533.580413@cargo.ozlabs.ibm.com>
Hi,
On Sun, 20 Jul 2008, Paul Mackerras wrote:
> I just tried importing the CVS repository for a long-running project
> (ppp) into git using git cvsimport. It looks like git cvsimport
> doesn't notice when files have been deleted, so files that used to be
> present and were subsequently deleted are present in the git tree for
> the most recent commit.
I never had that problem. See
http://repo.or.cz/w/libvncserver.git?a=commit;h=8dead0759febaa7176507e1bde13ebd9d2a30720
for a commit that was imported with cvsimport.
So your issue must lie somewhere else.
BTW do you have the repository locally? Then you should import with
cvs2svn or parsecvs instead. These programs are both faster and more
accurate than cvsimport. And AFAIK you can use cvsimport on the generated
repositories to update them incrementally.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Jay Soffian @ 2008-07-20 12:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tarmigan, Junio C Hamano, git, Michael J Gruber
In-Reply-To: <alpine.DEB.1.00.0807201250530.3305@eeepc-johanness>
On Sun, Jul 20, 2008 at 6:56 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Two things:
>
> - add and commit are two _different_ operations, not only in name, but
> also in nature. The fact that "commit -a" calls "add" is a _pure_
> convenience. It does not change the fact that "add" and "commit" are
> completely, utterly different.
>
> - if you are a heavy user of "commit -a", chances are that your history is
> not really useful, because you committed unrelated changes accidentally
> in the same commit.
>
> The latter point, BTW, is the reason I _never_ teach the "-a" option
> (actually, I teach no option at all) in my first two Git lessons.
I don't like "commit -a" and never use it and wonder why a
short-option was wasted on it.
I do like the new "add -a" (thank you Junio) but I will rarely use it.
I had the "addremove" alias in my .gitconfig specifically because I
used it so infrequently that it was hard for me to remember when I did
need it. So I think that "add --addremove" would be fine and we don't
need to spend a short-option ("-a") on it.
Lastly, I point out that when I started with git, it became much
clearer when I began reading "git add" as "git stage". I think my
first alias was "staged => diff --cached". But I am someone who likes
to learn how the things I use work early on.
j.
^ permalink raw reply
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: Johannes Schindelin @ 2008-07-20 12:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080720112957.GE32184@machine.or.cz>
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
> Scripts need to be modified for the reorganization anyway,
No. They do not, if the 1st variant is applied.
> and I'm not sure if there are any actually depening on this particular
> string.
That is the question, isn't it? You would never know. Many people,
strange as it sounds, do not write to this list when they encounter
problems with Git. They vent on their blogs, not giving us a chance, and
other people comment "Me too"s.
One of the most important features of Git used to be its scriptability,
and I think that many hackers just love Git for it, even new hackers.
So it is probably not unheard of that someone wrote an update hook or a
cronjob using the output of "update-index --refresh".
But those people are probably not on this list, or not following every
thread, or they even forgot how/that they implemented such a hook/cronjob.
Ergo: we would not know if scripts break. Until it is too late.
Ciao,
Dscho
^ permalink raw reply
* Re: Statictics on Git.pm usage in git commands (was: [PATCH 2/3] add new Git::Repo API)
From: Johannes Schindelin @ 2008-07-20 12:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, Lea Wiemann, git, John Hawley
In-Reply-To: <20080720104935.GB10151@machine.or.cz>
Hi,
On Sun, 20 Jul 2008, Petr Baudis wrote:
> On Sun, Jul 20, 2008 at 12:38:07PM +0200, Johannes Schindelin wrote:
>
> > Pasky tried to convert all Perl scripts at once IIRC, and my numerous
> > problems just _making_ the Git scripts led me to rewrite a few Perl
> > scripts in C, so I could safely exclude the Perl scripts from my
> > personal fork.
>
> I don't remember any concrete report of such problems ever reaching me;
> exactly what trouble are you hitting with the Perl scripts using Git.pm?
> I will be glad to try to fix it.
They reached you:
http://article.gmane.org/gmane.comp.version-control.git/23153
http://thread.gmane.org/gmane.comp.version-control.git/22764/focus=22778
Yes, those are very old mails, but they _do_ explain why the old Perl
scripts avoided Git.pm.
> > But your mention of git-add--interactive actually brings up my
> > pet-peeve: this script is the only Perl script needed for common
> > operations, i.e. the only reason msysGit has to ship bloated with
> > Perl.
>
> _Many_ people seem to be using git-svn, whether we like it or not. ;-)
Well, they will just stop using it on msysGit, since nobody fixes git-svn
on msysGit.
> Also, isn't git-send-mail rather commonly used? (I wouldn't know, me
> using stg mail.)
send-mail does not work on Windows. See
http://code.google.com/p/msysgit/issues/detail?id=27
Yes, you read correctly. The issue exists since almost the birth of
msysGit. Torgil seems to have stopped working on it altogether. Two
other people have "starred" the issue, wanting to be notified of fixes but
not wanting to work on them.
To me, it seems that either the Windows folk is a lazy bunch of bums, or
they just do not care enough. Or both.
Note: I want to express very loudly here that I do not count Hannes Sixt
as Windows folk. Even if he seems to like cmd.exe for some perverse
reason, it is undisputable that his effort, and his effort alone, brought
the MinGW port to where it is now.
To sum it up, I think we can safely remove Perl from the msysGit installer
once add--interactive is a builtin. The download will be substantially
smaller, and Perl on msysGit was never exactly a speed demon, so it's
probably a good change from several angles.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-merge.c: Fix option parsing
From: Michele Ballabio @ 2008-07-20 12:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Now "git merge -m" needs a message, and errors out with the usage
text if none is given.
This way, t7600-merge.sh is fixed.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-merge.c | 5 +++--
t/t7600-merge.sh | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 129b4e6..84a541d 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -68,10 +68,11 @@ static int option_parse_message(const struct option *opt,
if (unset)
strbuf_setlen(buf, 0);
- else {
+ else if (arg) {
strbuf_addf(buf, "%s\n\n", arg);
have_message = 1;
- }
+ } else
+ return error("switch `m' requires a value");
return 0;
}
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index 26cf8dc..5eeb6c2 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -221,7 +221,7 @@ test_expect_success 'setup' '
test_debug 'gitk --all'
-test_expect_failure 'test option parsing' '
+test_expect_success 'test option parsing' '
test_must_fail git merge -$ c1 &&
test_must_fail git merge --no-such c1 &&
test_must_fail git merge -s foobar c1 &&
--
1.5.6.3
^ permalink raw reply related
* [PATCH] Teach 'git merge' that 'recur' merge strategy no longer exists
From: Miklos Vajna @ 2008-07-20 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <20080720192125.6117@nanako3.lavabit.com>
It co-existed with 'recursive' when rewriting it in C, but it no longer
available.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sun, Jul 20, 2008 at 07:21:25PM +0900, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> - { "stupid", 0 },
If we are at it, recur is also something unnecessary here.
builtin-merge.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 129b4e6..beba635 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,7 +50,6 @@ static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
static struct strategy all_strategy[] = {
- { "recur", NO_TRIVIAL },
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
{ "octopus", DEFAULT_OCTOPUS },
{ "resolve", 0 },
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* git cvsimport and deleted files
From: Paul Mackerras @ 2008-07-20 12:09 UTC (permalink / raw)
To: git
I just tried importing the CVS repository for a long-running project
(ppp) into git using git cvsimport. It looks like git cvsimport
doesn't notice when files have been deleted, so files that used to be
present and were subsequently deleted are present in the git tree for
the most recent commit.
Is this a known problem? Is it a limitation of cvsps? I know that
cvs doesn't represent deletions explicitly anywhere, so I guess it's
not surprising, but it is a bit annoying.
Paul.
^ permalink raw reply
* Re: [RFC PATCH v2] Support gitlinks in fast-import.
From: Johannes Schindelin @ 2008-07-20 12:07 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Shawn O. Pearce
In-Reply-To: <200807191621.25654.angavrilov@gmail.com>
Hi,
On Sat, 19 Jul 2008, Alexander Gavrilov wrote:
> Links can be represented by two forms of the
> Modify command:
>
> M 160000 SHA1 some/path
>
> which sets the link target explicitly, or
>
> M 160000 :mark some/path
>
> where the mark refers to a commit. The latter
> form can be used by importing tools to build
> all submodules simultaneously in one physical
> repository, and then simply fetch them apart.
It seems that people like to do this, have their submodule branches in the
superproject. I wonder if we should bless this by installing an alternate
in the "git submodule init"ed submodules, or even do it during a "git
submodule update".
> + /* Links refer to objects in another repositories, so
s/another/other/
Thanks, especially for the tests,
Dscho
^ permalink raw reply
* Re: [PATCH] Enable git rev-list to parse --quiet
From: Nick Andrew @ 2008-07-20 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsjhc7kj.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 12:56:28AM -0700, Junio C Hamano wrote:
> Nick Andrew <nick@nick-andrew.net> writes:
>
> > ...Without
> > a working "--quiet" nor exit code I can pipe the output to "wc -l"
> > but is there a more efficient/reliable way to implement the requirement?
>
> Did you read the whole thread before asking the above question?
I took your answer to mean that I shouldn't be using git-rev-list
for this purpose, so I asked whether there's a better way to do
it. Johannes Schindelin gave a good answer to that.
> IOW, does this answer the above question?
>
> http://mid.gmane.org/7vy73zd8ok.fsf@gitster.siamese.dyndns.org
I'm not happy with that patch due to this:
static void finish_commit(struct commit *commit)
{
+ if (check_empty)
+ exit(0);
Exiting a process from within a callback function seems to me to violate
the principle of least surprise. If the return code should be zero then
the cmd_rev_list function should return zero, and run_command will
return zero and handle_internal_command will exit zero. There must be
a better way to avoid redundant processing for the empty set case.
Nick.
^ permalink raw reply
* Re: [PATCH] builtin-merge-recursive.c: make merge_recursive() static
From: Johannes Schindelin @ 2008-07-20 12:03 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Junio C Hamano
In-Reply-To: <20080720192127.6117@nanako3.lavabit.com>
Hi,
On Sun, 20 Jul 2008, Nanako Shiraishi wrote:
> This function is not used by any other file.
And I thought it would be, in a future version of builtin-merge...
Of course, we could apply this patch now, and revert it later, increasing
your commit count in the process :-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-push.c: Cleanup - use OPT_BIT() and remove some variables
From: Michele Ballabio @ 2008-07-20 12:02 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
builtin-push.c | 29 ++++++++---------------------
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 03db28c..c1ed68d 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -14,7 +14,7 @@ static const char * const push_usage[] = {
NULL,
};
-static int thin, verbose;
+static int thin;
static const char *receivepack;
static const char **refspec;
@@ -84,7 +84,7 @@ static int do_push(const char *repo, int flags)
if (thin)
transport_set_option(transport, TRANS_OPT_THIN, "yes");
- if (verbose)
+ if (flags & TRANSPORT_PUSH_VERBOSE)
fprintf(stderr, "Pushing to %s\n", remote->url[i]);
err = transport_push(transport, refspec_nr, refspec, flags);
err |= transport_disconnect(transport);
@@ -101,22 +101,19 @@ static int do_push(const char *repo, int flags)
int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
- int all = 0;
- int mirror = 0;
- int dry_run = 0;
- int force = 0;
int tags = 0;
int rc;
const char *repo = NULL; /* default repository */
struct option options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BIT('v', "verbose", &flags, "be verbose", TRANSPORT_PUSH_VERBOSE),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
- OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
- OPT_BOOLEAN( 0 , "mirror", &mirror, "mirror all refs"),
+ OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
+ OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
+ (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
- OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
- OPT_BOOLEAN('f', "force", &force, "force updates"),
+ OPT_BIT( 0 , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
+ OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
@@ -125,18 +122,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, options, push_usage, 0);
- if (force)
- flags |= TRANSPORT_PUSH_FORCE;
- if (dry_run)
- flags |= TRANSPORT_PUSH_DRY_RUN;
- if (verbose)
- flags |= TRANSPORT_PUSH_VERBOSE;
if (tags)
add_refspec("refs/tags/*");
- if (all)
- flags |= TRANSPORT_PUSH_ALL;
- if (mirror)
- flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
if (argc > 0) {
repo = argv[0];
--
1.5.6.3
^ permalink raw reply related
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