* qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-02 19:01 UTC (permalink / raw)
To: git
Currently in qgit one can git-format-patch a commit. It woul be nice if one
would be able to git-cherry-pick and git-cherry-pick -n a commit (denoting
the head, i.e. where cherry pick would be applied to). It would be very
usefull in reordering patches (cleaning up history).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Git.pm: Avoid ppport.h
From: Junio C Hamano @ 2006-07-02 19:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Petr Baudis
In-Reply-To: <Pine.LNX.4.63.0607021141260.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> This makes us not include ppport.h which seems not to give us anything real
>> anyway; it is useful for checking for portability warts but since Devel::PPPort
>> is a portability wart itself, we shouldn't require it for build.
>
> Why do people introduce a "portability enhancer" like that? This is soo
> dumb.
I think that statement is a bit too harsh.
My understanding is that it's more for use by developers working
with later version to produce portability headers, so used that
way it is very sane. From its manual page:
How to use ppport.h
Don't direct the users of your module to download "Devel::PPPort".
They are most probably no XS writers. Also, don't make ppport.h
optional. Rather, just take the most recent copy of ppport.h that you
can find (e.g. by generating it with the latest "Devel::PPPort" release
from CPAN), copy it into your project, adjust your project to use it,
and distribute the header along with your module.
But in the case of source distribution, and if the source
distribution wants to be compatible with older versions, the
above advice does not apply.
> Error: 'const char *' not in typemap in Git.xs, line 69
> Error: 'const char *' not in typemap in Git.xs, line 79
> make: *** [Git.c] Error 1
>
> It seems like my typemap starts like this:
>...
> So, no "const char *". See next mail for a minimal patch.
An alternative would be to carry our own typemap but I think
your fix is less intrusive and fine. Pasky?
> The warning
> (IIRC that was mentioned already on the list) still persists:
>
> cc -c -I. -I.. -g -pipe -pipe -fno-common -no-cpp-precomp -flat_namespace
> -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -Os -DVERSION=\"0.01\"
> -DXS_VERSION=\"0.01\" -I/System/Library/Perl/darwin/CORE -I/sw/include
> -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY
> -DGIT_VERSION='"1.4.1.g3b26"' Git.c
> In file included from /System/Library/Perl/darwin/CORE/perl.h:500,
> from Git.xs:15:
> /System/Library/Perl/darwin/CORE/embed.h:156:1: warning: "die" redefined
> Git.xs:11:1: warning: this is the location of the previous definition
I see the same here.
^ permalink raw reply
* Re: [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_bases()
From: Linus Torvalds @ 2006-07-02 20:44 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <44A8051D.6040605@lsrfire.ath.cx>
On Sun, 2 Jul 2006, Rene Scharfe wrote:
>
> No and yes. Patch 1 in the 3+1 series changes the flags used in
> commit.c to not conflict with the ones in revision.h[*]. So we have two
> different UNINTERESTINGs, and get_merge_bases() doesn't mess up the
> show/no-show markings.
Gaah. So UNINTERESTING in commit.c needs something else than everywhere
else? That's a bug waiting to happen.
Please give it a name of its own.
Linus
^ permalink raw reply
* Re: Quick merge status updates.
From: Petr Baudis @ 2006-07-02 20:49 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <1151489103.28036.6.camel@dv>
Dear diary, on Wed, Jun 28, 2006 at 12:05:03PM CEST, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> I think the BEGIN block has priority over other statements. My solution
> was to put the @INC change in the BEGIN block as well.
>
> This patch is working for me:
>
> diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
> index e8fad02..1b23fa1 100755
> --- a/git-fmt-merge-msg.perl
> +++ b/git-fmt-merge-msg.perl
> @@ -5,7 +5,7 @@ #
> # Read .git/FETCH_HEAD and make a human readable merge message
> # by grouping branches and tags together to form a single line.
>
> -unshift @INC, '@@INSTLIBDIR@@';
> +BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
> use strict;
> use Git;
> use Error qw(:try);
I feel that it is time for another stupid question of mine - why can't
you just use lib?
use lib ('@@INSTLIBDIR@@');
Looks a lot better than some @INC unshifting, and it should be
equivalent.
Let's pour in to the confusion:
The unshifting was introduced w/o BEGIN{} in
From: Junio C Hamano <junkio@cox.net>
Subject: Re: [PATCH 01/12] Introduce Git.pm (v4)
Date: Sat, 24 Jun 2006 04:57:31 -0700
but that patch is not in pu anymore while the description of the new
patch implicitly refers to it, which made it all a bit confusing.
So the purpose of the original patch was to make it play nicely with
$PERLLIB, but unshifting helps nothing, since:
There's default @INC
Perl spots PERLLIB and unshifts @INC
We then unshift @INC too, taking precedence
So didn't the original patch rather want to do push?
$ PERL5LIB=perl perl -le "BEGIN { unshift @INC, '/home/xpasky/lib/perl5/site_perl/5.8.8/i686-linux'; } use Git; print Git::hash_object('blob','Makefile');"
17842a3657ae8e5b4fd3ddfeb69268a4b94cb97a
$ PERL5LIB=perl perl -le "use Git; print Git::hash_object('blob','Makefile');"
syntax error at perl/Git.pm line 44, near "h>"
(after inserting random junk to perl/Git.pm)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* [PATCH] Git.pm: Don't #define around die
From: Petr Baudis @ 2006-07-02 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v4pxz4yki.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jul 02, 2006 at 09:05:33PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Error: 'const char *' not in typemap in Git.xs, line 69
> > Error: 'const char *' not in typemap in Git.xs, line 79
> > make: *** [Git.c] Error 1
> >
> > It seems like my typemap starts like this:
> >...
> > So, no "const char *". See next mail for a minimal patch.
>
> An alternative would be to carry our own typemap but I think
> your fix is less intrusive and fine. Pasky?
Yes, it should be fine.
> > The warning
> > (IIRC that was mentioned already on the list) still persists:
> >
> > cc -c -I. -I.. -g -pipe -pipe -fno-common -no-cpp-precomp -flat_namespace
> > -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -Os -DVERSION=\"0.01\"
> > -DXS_VERSION=\"0.01\" -I/System/Library/Perl/darwin/CORE -I/sw/include
> > -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRCASESTR -DNO_STRLCPY
> > -DGIT_VERSION='"1.4.1.g3b26"' Git.c
> > In file included from /System/Library/Perl/darwin/CORE/perl.h:500,
> > from Git.xs:15:
> > /System/Library/Perl/darwin/CORE/embed.h:156:1: warning: "die" redefined
> > Git.xs:11:1: warning: this is the location of the previous definition
>
> I see the same here.
-8<-
Back in the old days, we called Git's die() from the .xs code, but we had to
hijack Perl's die() for that. Now we don't call Git's die() so no need to do
the hijacking and it silences a compiler warning.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
perl/Git.xs | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/perl/Git.xs b/perl/Git.xs
index 51bfac3..1e6c1eb 100644
--- a/perl/Git.xs
+++ b/perl/Git.xs
@@ -8,15 +8,11 @@ #include <ctype.h>
#include "../cache.h"
#include "../exec_cmd.h"
-#define die perlyshadow_die__
-
/* XS and Perl interface */
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
-#undef die
-
static char *
report_xs(const char *prefix, const char *err, va_list params)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply related
* Re: [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_bases()
From: Rene Scharfe @ 2006-07-02 20:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Johannes Schindelin
In-Reply-To: <7vmzbr50b3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>>> I suspect the only way to fix that is to make "get_merge_bases()" not use
>>> UNINTERESTING at all, but instead just explicitly use something like
>> No and yes. Patch 1 in the 3+1 series changes the flags used in
>> commit.c to not conflict with the ones in revision.h[*]. So we have two
>> different UNINTERESTINGs, and get_merge_bases() doesn't mess up the
>> show/no-show markings.
>
> Gaah. commit.c defines its own UNINTERESTING and you rely on
> not including revision.h which is ... gasp ... #$@#$!!!
You mean crap? Yes, it is. That's why I said we should centralize the
commit flags. There are several duplicate names for different commit
flags in different files. I couldn't come up with a clean solution, though.
I have an idea. Would it help to gather a list of all commit object
flags from the different files? And then we would come up with unique
names? And then move the definition of all of them to commit.h?
René
^ permalink raw reply
* Re: [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_bases()
From: Rene Scharfe @ 2006-07-02 21:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Johannes Schindelin
In-Reply-To: <44A8339B.7070608@lsrfire.ath.cx>
Rene Scharfe schrieb:
> Junio C Hamano schrieb:
>> Gaah. commit.c defines its own UNINTERESTING and you rely on
>> not including revision.h which is ... gasp ... #$@#$!!!
> I have an idea. Would it help to gather a list of all commit object
> flags from the different files? And then we would come up with unique
> names? And then move the definition of all of them to commit.h?
Err, I mean object flags (not only commit flags) and object.h instead of
commit.h.
René
^ permalink raw reply
* Re: [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_bases()
From: Linus Torvalds @ 2006-07-02 21:17 UTC (permalink / raw)
To: Rene Scharfe; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <44A8339B.7070608@lsrfire.ath.cx>
On Sun, 2 Jul 2006, Rene Scharfe wrote:
>
> I have an idea. Would it help to gather a list of all commit object
> flags from the different files? And then we would come up with unique
> names? And then move the definition of all of them to commit.h?
We already did that once, for a subset of the programs. Except we put them
in revision.h instead ;)
And yes, we should probably do it for most of the rest.
Some of them (git-show-branch) have really special flags usage, and don't
want to pollute their magic flags with anybody else at all, but most of
the rest (fetch.c etc) have just a few flags and could in fact mostly
re-use the standard ones.
Linus
^ permalink raw reply
* Re: [POSSIBLE REGRESSION] Spurious revs after patch "revision.c: --full-history fix"
From: Marco Costalba @ 2006-07-02 21:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: junkio, git
In-Reply-To: <Pine.LNX.4.64.0607021012180.12404@g5.osdl.org>
>
> Gaah. Does this trivial patch fix it for you?
>
Yes. It works.
Thanks
Marco
^ permalink raw reply
* Re: Quick merge status updates.
From: Junio C Hamano @ 2006-07-02 21:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060702204906.GG29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> So the purpose of the original patch was to make it play nicely with
> $PERLLIB, but unshifting helps nothing, since:
>
> There's default @INC
> Perl spots PERLLIB and unshifts @INC
> We then unshift @INC too, taking precedence
I tried this:
0. check out the branch that has the Perly git ("pu"). build
and install normally to have a perfectly working version
accessible on your usual $PATH.
1. apply the patch [1] below to make it use "use lib" instead of
"unshift".
2. break perl/Git.pm being built to pretend we introduced a bug
in the work in progress by applying the patch [2] below.
3. without installing the broken Git.pm, run "make test", and
see a test that uses "git pull" and needs to create a true
merge succeed. It tells me that everything including
perl/Git.pm is GOOD, and I'd find the breakage only after
installing and running the test again.
If you make the freshly built script to say "use lib" to use
Git.pm and its friends from the installed location, it defeats
the attempt by test-lib.sh to override it to test what we
freshly built -- the use of "unshift @INC" is to work that
around and is parallel to the way Python stuff works around the
same problem.
[Footnotes]
*1* "use lib" patch.
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index 1b23fa1..3a42950 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -5,7 +5,7 @@ #
# Read .git/FETCH_HEAD and make a human readable merge message
# by grouping branches and tags together to form a single line.
-BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
+use lib '@@INSTLIBDIR@@';
use strict;
use Git;
use Error qw(:try);
*2* "break Git.pm" patch.
diff --git a/perl/Git.pm b/perl/Git.pm
index b4ee88b..34b4f12 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -6,6 +6,7 @@ Git - Perl interface to the Git version
package Git;
+syntax error -- kill me
use strict;
^ permalink raw reply related
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-02 21:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8954u$srh$1@sea.gmane.org>
On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Currently in qgit one can git-format-patch a commit. It woul be nice if one
> would be able to git-cherry-pick and git-cherry-pick -n a commit (denoting
> the head, i.e. where cherry pick would be applied to). It would be very
> usefull in reordering patches (cleaning up history).
>
> --
Currently in qgit you can git-format-patch a commit series and git-am
a given patch file series.
This can be done transparently with a drag & drop mechanic:
1) Open the source repository
2) Then open a new qgit instance (File->Open in a new window...)
3) Open the destination repository in the new qgit window
4) Drag & drop selected commits (multi selection in supported) from
source to destination.
I normally use this instead of git-cherry-pick that, I admit, I don't
know very well, so please I need some more hints on how to upgrade
this behaviour introducing git.cherry-pick support.
Marco
^ permalink raw reply
* Making perl scripts include the correct Git.pm
From: Petr Baudis @ 2006-07-02 21:40 UTC (permalink / raw)
To: git
Hi,
the discussion of the topic became so scatterred that it's rather
difficult to follow now and I get a feeling that we are kind of running
in circles now, so this is my attempt to summarize it:
Desired behaviour when running Git's perl scripts (ordered by
degree of necessity):
(D1) When running installed script, it should include Git.pm from the
same installation.
(D2) When running the testsuite, it should include Git.pm from the
source tree.
(D3) When running script directly from source tree, it should include
Git.pm from the source tree.
(i) The original solution passed -I on the #!/usr/bin/perl line, but
that was ugly, was prone to hit various OS limits on the shebang line
and violated both (D2) and (D3).
(ii) My proposed second solution was to add an autogenerated line to
the Git's perl scripts saying something like:
use lib ('instlibdir', 'srclibdir');
This fulfills all (D1), (D2) and (D3), but is perceived by Junio as
"disgusting".
(iii) The currently used solution is to effectively
use lib ('instlibdir');
to the Git's perl scripts. This violated (D3) and (D2) too, since
use lib is the last from all the @INC modifiers to be seen and thus
overrides and $PERL5LIB set in the testsuite.
(iv) Variation of (iii), probably Junio's original intention when
implementing it:
push @INC, 'instlibdir';
This fulfills (D2). It does not fulfill (D3) per se since the user
has to set $PERL5LIB manually when running Git without installing it,
but it is at least fulfillable. However, most importantly this does
not even fulfill (D1) since if you e.g. consider user-local installation
of Git over system-wide installation of Git, local perl scripts will
use the globally installed Git.pm.
(v) If you throw away user-friendly (D3) requirement and insist
on (iii) being disgusting, this is a newly proposed possible variation
"(iv) meets (i)":
#!/usr/bin/perl -Imarker
@INC = map { $_ eq 'marker' ? 'instlibdir' : $_ } @INC;
(I think this is more disgusting than (iii), but tastes differ. ;)
So, what's the way out?
PS: Is this the only remaining problem with Git.pm or do we have
anything else to cope with, esp. before it gets considered to be a
next material?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: A note on merging conflicts..
From: Daniel Barkalow @ 2006-07-02 21:42 UTC (permalink / raw)
To: Rene Scharfe
Cc: Linus Torvalds, J. Bruce Fields, Junio C Hamano, git,
Johannes Schindelin
In-Reply-To: <20060702113133.GA11529@lsrfire.ath.cx>
On Sun, 2 Jul 2006, Rene Scharfe wrote:
> On Sat, Jul 01, 2006 at 07:45:33PM -0400, Daniel Barkalow wrote:
> > That is: (this only has the logic portion, and it's against master, so it
> > isn't actually a really working patch or anything; also, it doesn't handle
> > "--not a...b" correctly, whatever that should mean)
>
> [concept patch snipped]
>
> You mean something like the patch below? It seems to work, but in my
> unscientific tests it's significant slower than the version based on
> get_merge_bases() (0.17s vs 0.05s for
> "git-rev-list 89719209...262a6ef7 66ae0c77...ced9456a"). Did I do
> something wrong?
>
> You had no mark_parents_left_right() in your patch. I added it because
> otherwise it wouldn't remove any common commits. Was this supposed to
> work some other way?
I'd been assuming that there was something that would propagate flags to
parents in general in add_parents_to_list(). Of course, that doesn't make
sense for arbitrary flags. It might be better to handle it there, and
avoid traversing parent lists twice.
I'm surprised that it isn't faster than using get_merge_bases(); I'd
expect it to be faster than the call to get_merge_bases(), let alone
get_merge_bases() plus the processing of output candidates. It should be
doing less work that get_merge_bases() ultimately does (since
get_merge_bases() has to do the boundary calculation after doing
practically everything that the left and right addition to revision.c
does), so there's clearly something strange going on.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-02 21:46 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607021433l1987c32apf4453b52fc2f3e63@mail.gmail.com>
Marco Costalba wrote:
> On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Currently in qgit one can git-format-patch a commit. It woul be nice
>> if one would be able to git-cherry-pick and git-cherry-pick -n a commit
>> (denoting the head, i.e. where cherry pick would be applied to). It would
>> be very usefull in reordering patches (cleaning up history).
>
> Currently in qgit you can git-format-patch a commit series and git-am
> a given patch file series.
> This can be done transparently with a drag & drop mechanic:
>
> 1) Open the source repository
> 2) Then open a new qgit instance (File->Open in a new window...)
> 3) Open the destination repository in the new qgit window
> 4) Drag & drop selected commits (multi selection in supported) from
> source to destination.
Does multi selection commits all selected commits as one merged commit?
> I normally use this instead of git-cherry-pick that, I admit, I don't
> know very well, so please I need some more hints on how to upgrade
> this behaviour introducing git.cherry-pick support.
I use git-cherry-pick -n to join few patches into one, or with editing the
result to split one patch/commit into few smaller.
git-cherry-pick [-n] <commit> picks up a commit and drops it on top of
current branch. I'd like to see it in context menu for current commit,
i.e. "cherry-pick to <head>", where <head> will be replaced by current
branch name, or/and "cherry-pick -n to <head>".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Quick merge status updates.
From: Petr Baudis @ 2006-07-02 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64if3d50.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jul 02, 2006 at 11:33:47PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I tried this:
>
> 0. check out the branch that has the Perly git ("pu"). build
> and install normally to have a perfectly working version
> accessible on your usual $PATH.
>
> 1. apply the patch [1] below to make it use "use lib" instead of
> "unshift".
>
> 2. break perl/Git.pm being built to pretend we introduced a bug
> in the work in progress by applying the patch [2] below.
>
> 3. without installing the broken Git.pm, run "make test", and
> see a test that uses "git pull" and needs to create a true
> merge succeed. It tells me that everything including
> perl/Git.pm is GOOD, and I'd find the breakage only after
> installing and running the test again.
So, just to clarify and make sure we understand each other perfectly,
you claim that when skipping (1), (3) _does_ FAIL for you? Because it
really doesn't for me and I can't see how could it ever fail without
installing the broken version first.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH] Git.xs: older perl do not know const char *
From: Petr Baudis @ 2006-07-02 21:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0607021152200.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Sun, Jul 02, 2006 at 11:53:03AM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> Both of these casts _should_ be safe, since you do not want to muck around
> with the version or the path anyway.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Petr Baudis <pasky@suse.cz>
It isn't all that great but it seems everything xs does with this is to
feed it to sv_setpv() which AFAIK copies it around.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-02 22:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e89eqj$npu$1@sea.gmane.org>
On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Marco Costalba wrote:
>
> > On 7/2/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >> Currently in qgit one can git-format-patch a commit. It woul be nice
> >> if one would be able to git-cherry-pick and git-cherry-pick -n a commit
> >> (denoting the head, i.e. where cherry pick would be applied to). It would
> >> be very usefull in reordering patches (cleaning up history).
> >
> > Currently in qgit you can git-format-patch a commit series and git-am
> > a given patch file series.
> > This can be done transparently with a drag & drop mechanic:
> >
> > 1) Open the source repository
> > 2) Then open a new qgit instance (File->Open in a new window...)
> > 3) Open the destination repository in the new qgit window
> > 4) Drag & drop selected commits (multi selection in supported) from
> > source to destination.
>
> Does multi selection commits all selected commits as one merged commit?
>
No. Currently it's just a shortcut for git-format-patch --> git-am
> > I normally use this instead of git-cherry-pick that, I admit, I don't
> > know very well, so please I need some more hints on how to upgrade
> > this behaviour introducing git.cherry-pick support.
>
> I use git-cherry-pick -n to join few patches into one, or with editing the
> result to split one patch/commit into few smaller.
>
> git-cherry-pick [-n] <commit> picks up a commit and drops it on top of
> current branch. I'd like to see it in context menu for current commit,
> i.e. "cherry-pick to <head>", where <head> will be replaced by current
> branch name, or/and "cherry-pick -n to <head>".
>
>
>From the git-cherry-pick documentation I see -n option "applies the
change necessary to cherry-pick the named commit to your working tree,
but does not make the commit"
What do you think about this:
When dropping the selected commits, instead of creating new commits,
appears a message box with something like "Do you want to apply the
commits on top of your current branch or on your working directory?"
Sounds good for you? Or you still prefer the context menu?
In the latter case, if I have understood correctly, you are limited to
cherry-pick among branches and/or working directory of the _same_
repository.
Marco
^ permalink raw reply
* [PATCH] Empty author may be presented by svn as an empty string or a null value.
From: Robin Rosenberg @ 2006-07-02 22:21 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
---
git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 38ac732..26dc454 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -534,7 +534,7 @@ sub commit {
my($author_name,$author_email,$dest);
my(@old,@new,@parents);
- if (not defined $author) {
+ if (not defined $author or $author eq "") {
$author_name = $author_email = "unknown";
} elsif (defined $users_file) {
die "User $author is not listed in $users_file\n"
^ permalink raw reply related
* Re: [PATCH] Git.xs: older perl do not know const char *
From: Junio C Hamano @ 2006-07-02 22:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20060702215249.GK29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Jul 02, 2006 at 11:53:03AM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
>> Both of these casts _should_ be safe, since you do not want to muck around
>> with the version or the path anyway.
>>
>> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> Acked-by: Petr Baudis <pasky@suse.cz>
>
> It isn't all that great but it seems everything xs does with this is to
> feed it to sv_setpv() which AFAIK copies it around.
Thanks. Already applied but not pushed out yet (I am working on
tracking down unrelated breakage in tests).
^ permalink raw reply
* Re: Quick merge status updates.
From: Junio C Hamano @ 2006-07-02 22:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060702214931.GJ29115@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Jul 02, 2006 at 11:33:47PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> I tried this:
>>
>> 0. check out the branch that has the Perly git ("pu"). build
>> and install normally to have a perfectly working version
>> accessible on your usual $PATH.
>>
>> 1. apply the patch [1] below to make it use "use lib" instead of
>> "unshift".
>>
>> 2. break perl/Git.pm being built to pretend we introduced a bug
>> in the work in progress by applying the patch [2] below.
>>
>> 3. without installing the broken Git.pm, run "make test", and
>> see a test that uses "git pull" and needs to create a true
>> merge succeed. It tells me that everything including
>> perl/Git.pm is GOOD, and I'd find the breakage only after
>> installing and running the test again.
>
> So, just to clarify and make sure we understand each other perfectly,
> you claim that when skipping (1), (3) _does_ FAIL for you? Because it
> really doesn't for me and I can't see how could it ever fail without
> installing the broken version first.
Gaah. You are right.
PERL5LIB does not seem to just do a push (and that was I thought
why unshift was a way to defeat it) but do something more evil.
With this:
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index 1b23fa1..5d1ae44 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -6,9 +6,11 @@ # Read .git/FETCH_HEAD and make a human
# by grouping branches and tags together to form a single line.
BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
+use lib '@@INSTLIBDIR@@';
use strict;
use Git;
use Error qw(:try);
+print STDERR "\@INC is @INC\n";
my $repo = Git->repository();
It spits this out:
@INC is /home/junio/git-pu/lib/perl/5.8.8 /opt/git/git.git/t/../perl/blib/lib /opt/git/git.git/t/../perl/blib/arch/auto/Git /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .
So "BEGIN { unshift }" is JUST AS WRONG as "use lib".
I thought we killed this showstopper and was hoping now the
series is mergeable to "next" but apparently not yet X-<.
Sigh....
^ permalink raw reply related
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-02 22:54 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607021504l6e7fc8b8ja61f20f630c0f3f@mail.gmail.com>
Marco Costalba wrote:
> What do you think about this:
>
> When dropping the selected commits, instead of creating new commits,
> appears a message box with something like "Do you want to apply the
> commits on top of your current branch or on your working directory?"
>
> Sounds good for you? Or you still prefer the context menu?
> In the latter case, if I have understood correctly, you are limited to
> cherry-pick among branches and/or working directory of the _same_
> repository.
Yes, git-cherry-pick works only between commits in the same repository,
as it use merge (first "simple", i.e. git-read-tree -m -u --aggresive, if
fails tries "automatic" i.e. git-merge-index -o git-merge-one-file -a, then
git-write-tree), as opposed to git-format-patch and git-am or git-apply,
which can work across repositories.
What I really want is "no-commit" of drag'n'dropped, or exported and applied
commits/patches (although interface to cherry-pick would be nice, even if
cherry-pick is limited), so I'd like message box with "Do you want to
commit selected patches?" when dropping commits, or something like that.
Unfortunately git-am doesn't have --no-commit flag, but one could emulate it
with git-reset after git-am a patch, I think.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] send-email: do not barf when Term::ReadLine does not like your terminal
From: Junio C Hamano @ 2006-07-02 23:03 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
As long as we do not need to readline from the terminal, we
should not barf when starting up the program. Without this
patch, t9001 test on Cygwin occasionally died with the following
error message:
Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and LINES environment variables didn't work. The resize program didn't work. at /usr/lib/perl5/vendor_perl/5.8/cygwin/Term/ReadKey.pm line 362.
Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8/Term/ReadLine/Perl.pm line 58.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I do not use send-email myself that often so extra sets of
eyeballs are appreciated.
git-send-email.perl | 18 +++++++++++++++++-
t/t9001-send-email.sh | 11 +++++++----
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index c5d9e73..b04b8f4 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -22,6 +22,17 @@ use Term::ReadLine;
use Getopt::Long;
use Data::Dumper;
+package FakeTerm;
+sub new {
+ my ($class, $reason) = @_;
+ return bless \$reason, shift;
+}
+sub readline {
+ my $self = shift;
+ die "Cannot use readline on FakeTerm: $$self";
+}
+package main;
+
# most mail servers generate the Date: header, but not all...
$ENV{LC_ALL} = 'C';
use POSIX qw/strftime/;
@@ -46,7 +57,12 @@ my $smtp_server;
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
-my $term = new Term::ReadLine 'git-send-email';
+my $term = eval {
+ new Term::ReadLine 'git-send-email';
+};
+if ($@) {
+ $term = new FakeTerm "$@: going non-interactive";
+}
# Begin by accumulating all the variables (defined above), that we will end up
# needing, first, from the command line:
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index a61da1e..e9ea33c 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -25,10 +25,13 @@ test_expect_success \
git add fake.sendmail
GIT_AUTHOR_NAME="A" git commit -a -m "Second."'
-test_expect_success \
- 'Extract patches and send' \
- 'git format-patch -n HEAD^1
- git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt'
+test_expect_success 'Extract patches' '
+ patches=`git format-patch -n HEAD^1`
+'
+
+test_expect_success 'Send patches' '
+ git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
+'
cat >expected <<\EOF
!nobody@example.com!
--
1.4.1.gc92a
^ permalink raw reply related
* Make other men envy you and girls worship you Most efficient products for men
From: Ebony @ 2006-07-02 23:38 UTC (permalink / raw)
To: git
Dear valued customer.
Enhanced male power and unlimited prowess with your girl The best products for the winning guys
Achieve astounding results in bed with these products designed to make any man a winner
http://www.syllabhd.com
A sprat to catch a mackerel. All is for the best in the best of the possible worlds A proverb is a true word. Two things a man should never be angry at: what he can help and what he cannot help
Yuh tel tara and tara tell tara.
^ permalink raw reply
* Re: Quick merge status updates.
From: Junio C Hamano @ 2006-07-02 23:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vveqf1v05.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Gaah. You are right.
>
> PERL5LIB does not seem to just do a push (and that was I thought
> why unshift was a way to defeat it) but do something more evil.
> ...
> I thought we killed this showstopper and was hoping now the
> series is mergeable to "next" but apparently not yet X-<.
>
> Sigh....
Yuck; that means we would need to have something evil like this.
-- >8 --
Perly Git: make sure we do test the freshly built one.
We could BEGIN { push @INC, '@@INSTLIBDIR@@'; } but that is not
a good idea for normal execution. The would prevent a
workaround for a user who is trying to override an old, faulty
Git.pm installed on the system path with a newer version
installed under $HOME/.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-fmt-merge-msg.perl b/git-fmt-merge-msg.perl
index 1b23fa1..a9805dd 100755
--- a/git-fmt-merge-msg.perl
+++ b/git-fmt-merge-msg.perl
@@ -5,7 +5,11 @@ #
# Read .git/FETCH_HEAD and make a human readable merge message
# by grouping branches and tags together to form a single line.
-BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
+BEGIN {
+ unless (exists $ENV{'RUNNING_GIT_TESTS'}) {
+ unshift @INC, '@@INSTLIBDIR@@';
+ }
+}
use strict;
use Git;
use Error qw(:try);
diff --git a/git-mv.perl b/git-mv.perl
index a604896..5134b80 100755
--- a/git-mv.perl
+++ b/git-mv.perl
@@ -6,7 +6,11 @@ #
# This file is licensed under the GPL v2, or a later version
# at the discretion of Linus Torvalds.
-BEGIN { unshift @INC, '@@INSTLIBDIR@@'; }
+BEGIN {
+ unless (exists $ENV{'RUNNING_GIT_TESTS'}) {
+ unshift @INC, '@@INSTLIBDIR@@';
+ }
+}
use warnings;
use strict;
use Getopt::Std;
diff --git a/t/test-lib.sh b/t/test-lib.sh
index fba0c51..298c6ca 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -206,8 +206,9 @@ PYTHON=`sed -e '1{
PYTHONPATH=$(pwd)/../compat
export PYTHONPATH
}
+RUNNING_GIT_TESTS=YesWeAre
PERL5LIB=$(pwd)/../perl/blib/lib:$(pwd)/../perl/blib/arch/auto/Git
-export PERL5LIB
+export PERL5LIB RUNNING_GIT_TESTS
test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
^ permalink raw reply related
* [PATCH 1] autoconf: Use autoconf to write installation directories to config.mak.autogen
From: Jakub Narebski @ 2006-07-02 23:56 UTC (permalink / raw)
To: git
This is beginning of patch series introducing installation configuration
using autoconf (and no other autotools) to git. The idea is to generate
config.mak.autogen using ./configure (generated from configure.ac by running
autoconf) from config.mak.in, so one can use autoconf as an _alternative_ to
ordinary Makefile, and creating one's own config.mak. Local settings in
config.mak override generated settings in config.mak.autogen
This patch includes minimal configure.ac and config.mak.in, so one can set
installation directories using autoconf generated ./configure script
e.g. ./configure --prefix=/usr
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch is to be applied on top of 'next', because to work as intended
(especially for --mandir=<path> option to ./configure) it needs
Allow INSTALL, bindir, mandir to be set in main Makefile
e14421b9aa85f11853a0dacae09498515daab7b8
patch (commit) to be present.
For now the following options do actually something:
$ ./configure
--prefix=<prefix> # [/usr/local]
--exec_prefix=<prefix> # [PREFIX]
--bindir=<bindir> # [EPREFIX/bin]
--datadir=<datadir> # [PREFIX/share]
--mandir=<mandir> # [PREFIX/man]
$ ./configure --help # hardcoded version 1.4.1
QUESTION: how to make autoconf _generate_ correct version string?
Next patch will show how this infrastructure can be used.
.gitignore | 6 ++++++
INSTALL | 9 +++++++++
Makefile | 1 +
config.mak.in | 18 ++++++++++++++++++
configure.ac | 14 ++++++++++++++
5 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 2bcc604..616aa98 100644
--- a/.gitignore
+++ b/.gitignore
@@ -136,4 +136,10 @@ git-core.spec
*.[ao]
*.py[co]
config.mak
+autom4te.cache
+config.log
+config.status
+config.mak.in
+config.mak.autogen
+configure
git-blame
diff --git a/INSTALL b/INSTALL
index f8337e2..28245b3 100644
--- a/INSTALL
+++ b/INSTALL
@@ -13,6 +13,15 @@ that uses $prefix, the built results hav
which are derived from $prefix, so "make all; make prefix=/usr
install" would not work.
+Alternatively you can use autoconf generated ./configure script to
+set up install paths (via config.mak.autogen), so you can write instead
+
+ $ autoconf ;# as yourself if ./configure doesn't exist yet
+ $ ./configure --prefix=/usr ;# as yourself
+ $ make all doc ;# as yourself
+ # make install install-doc ;# as root
+
+
Issues of note:
- git normally installs a helper script wrapper called "git", which
diff --git a/Makefile b/Makefile
index 7dbb883..3c2c257 100644
--- a/Makefile
+++ b/Makefile
@@ -333,6 +333,7 @@ ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
+-include config.mak.autogen
-include config.mak
ifdef WITH_OWN_SUBPROCESS_PY
diff --git a/config.mak.in b/config.mak.in
new file mode 100644
index 0000000..82c9781
--- /dev/null
+++ b/config.mak.in
@@ -0,0 +1,18 @@
+# git Makefile configuration, included in main Makefile
+# @configure_input@
+
+prefix = @prefix@
+exec_prefix = @exec_prefix@
+bindir = @bindir@
+#gitexecdir = @libexecdir@/git-core/
+template_dir = @datadir@/git-core/templates/
+GIT_PYTHON_DIR = @datadir@/git-core/python
+
+mandir=@mandir@
+
+srcdir = @srcdir@
+VPATH = @srcdir@
+
+export exec_prefix mandir
+export srcdir VPATH
+
diff --git a/configure.ac b/configure.ac
new file mode 100644
index 0000000..a54b164
--- /dev/null
+++ b/configure.ac
@@ -0,0 +1,14 @@
+# -*- Autoconf -*-
+# Process this file with autoconf to produce a configure script.
+
+AC_PREREQ(2.59)
+AC_INIT([git], [1.4.1], [git@vger.kernel.org])
+
+AC_CONFIG_SRCDIR([git.c])
+
+config_file=config.mak.autogen
+config_in=config.mak.in
+
+# Output files
+AC_CONFIG_FILES(["${config_file}":"${config_in}"])
+AC_OUTPUT
--
1.4.0
^ 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