* Re: [PATCH 0/8] VCS helpers
From: Daniel Barkalow @ 2009-09-04 16:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johan Herland
In-Reply-To: <7v63bz198j.fsf@alter.siamese.dyndns.org>
On Fri, 4 Sep 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This is the next version of the db/vcs-helper series in pu.
>
> Thanks.
>
> > The first patch is new, a rework of the remote-curl build to produce
> > "remote-curl" and call it as a special case for the sorts of URLs that
> > we accept as indicating something that it now handled by this helper.
> >
> > The series is rebased onto current next, with some conflicts resolved.
>
> Because the theme of the topic does not have anything to do with fixing
> the deepening of shallow clones nor giving an extended error message from
> non-fast-forward git-push, I queued the series after reverse-rebasing onto
> old db/vcs-helper~8, in order to keep the topic branch pure, instead of
> merging unrelated topics from maint, master or next into it. The result
> merged in 'pu' obviously has to match what you expected by applying the
> patches on top of 'next', and I am reasonably sure it does.
I'd thought that topics in pu were carried as based on next, particularly
once they depend on something (e.g., the beginning of the series) in next.
I suppose there's better options, but what do you do to find them? (Feel
free to refer me to the "note from the maintainer" if it's there, but I
don't remember that detail)
FWIW, there was a semantic mismerge in the original basing of this series
on 07a4a3b496, which I finally fixed in this version; the code to handle
NULL urls in builtin-fetch was after a new conversion of the url.
In any case, I think both the reverse-rebase and merge are correct.
> > Two patches have been dropped: a memory leak fix for code that was
> > removed entirely by the first patch, and the "mark" helper capability,
> > which is not needed (I believe) due to the "option" fast-import command.
>
> Johan's cvs-helper series were depending on the previous iteration of this
> series, but I thought it is being rerolled, so I'd drop it from pu for now.
You could probably stick the "mark" patch into the start of the cvs-helper
series until it gets rerolled if you want to keep that series in pu
meanwhile; it was at the end of the series, and doesn't have subtle
interactions or interact with anything that's changed.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Do not scramble password read from .cvspass
From: Junio C Hamano @ 2009-09-04 16:21 UTC (permalink / raw)
To: Dirk Hoerner; +Cc: git list, pascal
In-Reply-To: <4AA100E8.9030806@obry.net>
Pascal Obry <pascal@obry.net> writes:
> Passwords stored in .cvspass are already scrambled, we do not
> want to scramble them twice. Only passwords read from the
> command line are scrambled.
>
> This fixes a regression introduced by:
> b2139dbd72d16e40eddfd5b9ad1314703b39fe65
>
> Signed-off-by: Pascal Obry <pascal@obry.net>
> ---
Thanks, Pascal. This bug is not in any tagged release yet, and I am happy
you caught it before -rc0 ;-)
Dirk, does the patch look Ok to you?
> git-cvsimport.perl | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/git-cvsimport.perl b/git-cvsimport.perl
> index 593832d..c5cdcae 100755
> --- a/git-cvsimport.perl
> +++ b/git-cvsimport.perl
> @@ -238,7 +238,10 @@ sub conn {
> }
> my $rr = ":pserver:$user\@$serv:$port$repo";
>
> - unless ($pass) {
> + if ($pass) {
> + $pass = $self->_scramble($pass);
> + } else
> + {
> open(H,$ENV{'HOME'}."/.cvspass") and do {
> #
> :pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
> while (<H>) {
> @@ -253,8 +256,6 @@ sub conn {
> };
> }
>
> - $pass = $self->_scramble($pass);
> -
> my ($s, $rep);
> if ($proxyhost) {
>
> --
> 1.6.4.2.253.g0b1fac
^ permalink raw reply
* Re: Commit to wrong branch. How to fix?
From: Michael J Gruber @ 2009-09-04 16:19 UTC (permalink / raw)
To: Howard Miller; +Cc: git@vger.kernel.org
In-Reply-To: <88A0A7C2-7DCB-45A3-B196-BED2A8AC9405@googlemail.com>
Howard Miller venit, vidit, dixit 04.09.2009 17:54:
> I commited to the wrong branch and I can't figure out what to do. To
> make matters worse I then did 'git reset HEAD^' which has made things
> much worse. It didn't remove the commit and now I can't change
> branches. I'm utterly confused. Any help much appreciated!
>
> Moral - use git status liberally and read it carefully before doing
> anything. A 'git undo" command would be great is someone is feeling
> generous :-)
Whatever happens, don't panic ;)
Let's say "geesh" is the branch on which you committed by mistake, and
which you have reset.
git reflog geesh
which show you what has happened to that branch lately. In particular,
it will list the "lost" commit. (Most probably it is the same as geesh@{1}.)
git tag sigh sha1ofthatcommit
will assign the tag "sigh", so that it won't get lost by doing "git gc"
or such. Now you can lean back!
Next step is committing "sigh" to the right branch. Depends on how you
arrived at that commit. Did you commit the complete tree you wanted, or
did you apply a change to geesh which you rather had wanted applied to
some other branch?
Michael
^ permalink raw reply
* Commit to wrong branch. How to fix?
From: Howard Miller @ 2009-09-04 15:54 UTC (permalink / raw)
To: git@vger.kernel.org
I commited to the wrong branch and I can't figure out what to do. To
make matters worse I then did 'git reset HEAD^' which has made things
much worse. It didn't remove the commit and now I can't change
branches. I'm utterly confused. Any help much appreciated!
Moral - use git status liberally and read it carefully before doing
anything. A 'git undo" command would be great is someone is feeling
generous :-)
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Daniel Barkalow @ 2009-09-04 15:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0909032229k5e6e2ed5mc11e8ff9c16dfcc0@mail.gmail.com>
On Fri, 4 Sep 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Sep 4, 2009 at 04:13, Daniel Barkalow<barkalow@iabervon.org> wrote:
> > Instead of trying to make http://, https://, and ftp:// URLs
> > indicative of some sort of pattern of transport helper usage, make
> > them a special case which runs the "curl" helper, and leave the
> > mechanism by which arbitrary helpers will be chosen entirely to future
> > work.
>
> I'm sorry, I missed a few emails I think :(. Would you mind explaining
> why we chose to special-case the curl helpers instead of the symlink
> scheme?
It turns out that the method used to form URLs that use a helper doesn't
generalize well to other cases, because it interferes with the ssh-style
locations. Instead, some different mechanism needs to be made up to handle
arbitrary handlers that git doesn't know about. Since we want to keep
supporting "http://something", that'll have to be a special case anyway,
and so we might as well handle it by having git know what helpers to use
for things that we've always supported, and use a single descriptive name
for the helper that handles that collection of URLs.
As of this version, the idea is that there will be three ways helpers get
selected:
- git selects a helper based on the URL being something traditionally
supported internally; that is, git recognizes the URL and knows what to
run, if possible, to handle it
- git uses the "vcs" option if it is set
- something with the URL that we don't understand well enough yet to
design, but which doesn't seem to be possible to fit in as a single
rule with the first item.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 14:49 UTC (permalink / raw)
To: Douglas Campos; +Cc: Jonas Fonseca, git, Gabe McArthur
In-Reply-To: <ed88cb980909040744k2fa372fapb7ee457c745b9aa0@mail.gmail.com>
Hi Douglas!
http://github.com/sonatype/JGit
The branch will be called mavenizing or so.
Will post this after I got the tests running.
LieGrue,
strub
--- On Fri, 9/4/09, Douglas Campos <douglas@theros.info> wrote:
> From: Douglas Campos <douglas@theros.info>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: "Jonas Fonseca" <jonas.fonseca@gmail.com>, git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 4:44 PM
> On Fri, Sep 4, 2009
> at 9:47 AM, Mark Struberg <struberg@yahoo.de>
> wrote:
>
>
> as an old saying tells us: how to climb a mountain? step
> after step! ;)
>
>
>
> I suggest we create a fresh branch based on the Shawns
> current version and add all the features incrementally.
>
>
>
> please point out where this branch will happen, I want to
> give some help too.
>
>
^ permalink raw reply
* Re: tracking branch for a rebase
From: Michael J Gruber @ 2009-09-04 14:31 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20090904135414.GA3728@honk.padd.com>
Pete Wyckoff venit, vidit, dixit 04.09.2009 15:54:
> I received an interesting question today.
>
> If "git pull" knows what remote tracking brach to pull from,
> why doesn't "git rebase" automatically know I want to rebase
> on top of my remote tracking branch?
>
> He had done a "git remote update", reviewed the changes, and now
> wants to rebase his changes on top of the new upstream.
>
> I told him about git pull --rebase, and branch.name.rebase,
> but didn't have an easy answer to the "what is my remote tracking
> branch" question in this case.
I guess he knows that branch if he reviewed it... More seriously,
git for-each-ref --format='%(upstream)' refs/heads/hisbranch
will return the upstream of hisbranch.
>
> All the information is in git config branch.name.{remote,merge},
> but I can't find anything that just answers that question. Nor
> did I have a good answer for why "git rebase" doesn't just default
> to rebasing the current branch on top of the tracking branch.
Maybe because nobody has cared. Doing a "git pull --rebase" is not
equivalent (it may fetch more refs), but close enough for many people.
There was an initiative by Dscho a while ago to introduce a shortcut for
the upstream, which was dwarfed by the lack reserved characters for
refnames. Maybe 1.7 time frame would be a good time to change this?
Making this the default for rebase without arguments may meet some
objections (oh no, I didn't mean to rebase), but I guess it's worth trying.
Michael
^ permalink raw reply
* tracking branch for a rebase
From: Pete Wyckoff @ 2009-09-04 13:54 UTC (permalink / raw)
To: git
I received an interesting question today.
If "git pull" knows what remote tracking brach to pull from,
why doesn't "git rebase" automatically know I want to rebase
on top of my remote tracking branch?
He had done a "git remote update", reviewed the changes, and now
wants to rebase his changes on top of the new upstream.
I told him about git pull --rebase, and branch.name.rebase,
but didn't have an easy answer to the "what is my remote tracking
branch" question in this case.
All the information is in git config branch.name.{remote,merge},
but I can't find anything that just answers that question. Nor
did I have a good answer for why "git rebase" doesn't just default
to rebasing the current branch on top of the tracking branch.
Thoughts?
-- Pete
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Tay Ray Chuan @ 2009-09-04 13:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit
In-Reply-To: <7viqfzvwf1.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, Sep 4, 2009 at 6:25 PM, Junio C Hamano<gitster@pobox.com> wrote:
> codesite-noreply@google.com writes:
>
>> Status: New
>> Owner: ----
>>
>> New issue 323 by bjelli: Can't clone over http
>> http://code.google.com/p/msysgit/issues/detail?id=323
Junio, thanks for bringing this issue to the list's and my attention.
> This does not seem to be an msysgit issue. Even on a Linux host, v1.6.2.5
> seems to work Ok but 'maint', 'master', nor 'next' does not clone this one
> correctly.
Releases including and after v1.6.4 will have this issue:
>> error: Unable to verify pack 382c25c935b744e909c749532578112d72a4aff9 is
>> available
>> error: Unable to find 0a41ac04d56ccc96491989dc71d9875cd804fc6b under
>> http://github.com/tekkub/addontemplate.git
The issue at hand is due to git checking the http repository for the
pack file before commencing the transfer; failing which, the transfer
aborts.
Right now, git chokes on the 500 error that github.com gives it, which
shouldn't be the case, even though that's a weird response.
--
Cheers,
Ray Chuan
-- >8 --
Subject: [PATCH] http.c: clarify missing-pack-check
Abort the pack transfer only if the pack is not available in the HTTP-
served repository; otherwise, allow the transfer to continue, even if
the check failed.
This addresses an issue raised by bjelli:
http://code.google.com/p/msysgit/issues/detail?id=323
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
http.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/http.c b/http.c
index 5926c5b..cba7e9a 100644
--- a/http.c
+++ b/http.c
@@ -864,6 +864,7 @@ int http_fetch_ref(const char *base, struct ref *ref)
static int fetch_pack_index(unsigned char *sha1, const char *base_url)
{
int ret = 0;
+ int result;
char *hex = xstrdup(sha1_to_hex(sha1));
char *filename;
char *url;
@@ -874,11 +875,14 @@ static int fetch_pack_index(unsigned char *sha1, const char *base_url)
strbuf_addf(&buf, "objects/pack/pack-%s.pack", hex);
url = strbuf_detach(&buf, 0);
- if (http_get_strbuf(url, NULL, 0)) {
- ret = error("Unable to verify pack %s is available",
+ result = http_get_strbuf(url, NULL, 0);
+ if (result == HTTP_MISSING_TARGET) {
+ ret = error("Unable to find pack %s",
hex);
goto cleanup;
- }
+ } else if (result && http_is_verbose)
+ fprintf(stderr, "Unable to verify pack %s is available\n",
+ hex);
if (has_pack_index(sha1)) {
ret = 0;
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Johannes Schindelin @ 2009-09-04 12:52 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090904124904.22288.qmail@103db479e31ab7.315fe32.mid.smarden.org>
Hi,
On Fri, 4 Sep 2009, Gerrit Pape wrote:
> On Fri, Sep 04, 2009 at 02:35:00PM +0200, Johannes Schindelin wrote:
> > Hi,
> >
> > On Fri, 4 Sep 2009, Gerrit Pape wrote:
> >
> > > On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
> > > > -- snipsnap --
> > > > [PATCH] git help -a: do not look for a repository
> > >
> > > Perfect, thanks.
> > >
> > > Acked-by: Gerrit Pape <pape@smarden.org>
> >
> > Hmm... I haven't checked if 'git help -a' wants to discover the
> > (possibly repository-specific) aliases. Have you?
>
> Yes, it doesn't. Regards, Gerrit.
Thanks.
Junio, I am serious about this patch (i.e. it is meant for inclusion now).
Want me to resend?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Gerrit Pape @ 2009-09-04 12:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909041434310.4605@intel-tinevez-2-302>
On Fri, Sep 04, 2009 at 02:35:00PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 4 Sep 2009, Gerrit Pape wrote:
>
> > On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
> > > -- snipsnap --
> > > [PATCH] git help -a: do not look for a repository
> >
> > Perfect, thanks.
> >
> > Acked-by: Gerrit Pape <pape@smarden.org>
>
> Hmm... I haven't checked if 'git help -a' wants to discover the (possibly
> repository-specific) aliases. Have you?
Yes, it doesn't. Regards, Gerrit.
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 12:47 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Gabe McArthur
In-Reply-To: <2c6b72b30909040541t4c781378g3f35aeb70021050c@mail.gmail.com>
as an old saying tells us: how to climb a mountain? step after step! ;)
I suggest we create a fresh branch based on the Shawns current version and add all the features incrementally.
1.) move the directory structure over to mavens std layout
2.) create the scm section and try releases
3.) improve site generation and documentation
tbc
LieGrue,
strub
--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 2:41 PM
> On Fri, Sep 4, 2009 at 03:33, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> >> From: Gabe McArthur <gabriel.mcarthur@gmail.com>
> > >
> >> I'll try to submit a full patch later, using your
> >> conventions.
>
> I have a question as well:
>
> Support for using find bug is part of the Eclipse
> configuration (see
> org.spearce.jgit/findBugs/), and I know that there's a find
> bug plugin
> for Maven. From looking at sonatype's JGit repositories it
> is not
> integrated. Have you managed to include it?
>
> --
> Jonas Fonseca
>
^ permalink raw reply
* Re: [PATCH 5/8] Allow programs to not depend on remotes having urls
From: Johannes Schindelin @ 2009-09-04 12:45 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909032213290.28290@iabervon.org>
Hi,
On Thu, 3 Sep 2009, Daniel Barkalow wrote:
> For fetch and ls-remote, which use the first url of a remote, have
> transport_get() determine this by passing a remote and passing NULL
> for the url. For push, which uses every url of a remote, use each url
> in turn if there are any, and use NULL if there are none.
>
> This will allow the transport code to do something different if the
> location is not specified with a url.
For the record: you did not convince me. Not that you tried, to...
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT] Request for help
From: Jonas Fonseca @ 2009-09-04 12:41 UTC (permalink / raw)
To: Mark Struberg; +Cc: git, Gabe McArthur
In-Reply-To: <554991.93608.qm@web27807.mail.ukl.yahoo.com>
On Fri, Sep 4, 2009 at 03:33, Mark Struberg<struberg@yahoo.de> wrote:
>> From: Gabe McArthur <gabriel.mcarthur@gmail.com>
> >
>> I'll try to submit a full patch later, using your
>> conventions.
I have a question as well:
Support for using find bug is part of the Eclipse configuration (see
org.spearce.jgit/findBugs/), and I know that there's a find bug plugin
for Maven. From looking at sonatype's JGit repositories it is not
integrated. Have you managed to include it?
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Johannes Schindelin @ 2009-09-04 12:35 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20090904110936.6663.qmail@046e1bfbf7e41d.315fe32.mid.smarden.org>
Hi,
On Fri, 4 Sep 2009, Gerrit Pape wrote:
> On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
> > -- snipsnap --
> > [PATCH] git help -a: do not look for a repository
>
> Perfect, thanks.
>
> Acked-by: Gerrit Pape <pape@smarden.org>
Hmm... I haven't checked if 'git help -a' wants to discover the (possibly
repository-specific) aliases. Have you?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case
From: Johannes Schindelin @ 2009-09-04 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vk50fugpn.fsf@alter.siamese.dyndns.org>
Hi,
On Fri, 4 Sep 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The special case is "http://" and "https://" which might indicate foreign
> > VCS repositories.
> >
> > In all other cases, I am afraid that you are complicating the glove.
> >
> > Remember: the whole purpose of the "foreign VCS" helpers is user
> > convenience.
>
> Sorry, but you completely lost me here.
My point was that the ambiguity _only_ applies to http:// and https://
URLs, as you illustrated yourself:
> Here are two URLs that follows your "user convenience" principle.
>
> http://example.xz/repos/frotz.git/
> http://example.xz/repo/frotz/trunk/
There is no ambiguity about hg://, svn://, etc. None.
Some "URLs" do not look like "URLs" at all, e.g. :ext:user@host:/module
for CVS repositories. I haven't really thought about a convenient way to
specify these, but I could imagine that indeed something like
"cvs::ext:usr@host:/module" would make sense, and still be an intuitive
interface that does not break down with "git clone".
Likewise, I imagine that "svn::http://example.xz/repo/frotz/trunk" (or
even "svn::std::http://example.xz/repo/frotz") are not _too_ unintuitive.
But my real point still stands: "git clone hg://example.xz/repos/blub"
should Just Work.
Oh, and I definitely do not want to expose an _implementation detail_ such
as "we use cURL" in the name of the remote helper. That would just be bad
style in my book.
> How do you tell, without relying on .git and trunk, the former is a git
> repository and wants the dumb walker transport to fetch from, while the
> latter is probably a svn and you would either use "svn checkout", or use
> "git clone" on it via the svn helper?
>
> Well, you don't.
>
> One possible "convenient user interface" would be to say
>
> svn+http://example.xz/repo/frotz/trunk/
>
> (or use :: instead of + as the helper-name separator, as we agreed not to
> decide on it)
Now that you mention it, the main issue was the ambiguity that
svn:/path/to/repo
should actually be an ssh "URL". But I think that the simple fact that a
"://" in the URL (and if that is not sufficient, something like a
"<vcs>::" prefix) make non-ssh URLs distinct enough to decide robustly
what type the URL is.
> This would give us
>
> (1) it is clear that it literally is what you would give to git and
> trigger the svn helper; and
>
> (2) to people who know how canonical git URLs with foreign helper are
> spelled, it also is clear that you can use "svn checkout" on
> everything after "svn+" in it.
The only problem is that you cannot use "git-remote-svn+http" as helper,
as "+" are not valid filename characters on Windows. However, you could
have a "git-remote-svn" handling both "svn://" and "svn+" prefixes.
> Compared to that, if you do not have any such prefix, how would that be
> more convenient to the users?
Indeed, I made myself misunderstood. I think that for _a lot_ of
repository URLs, there are naturally distinctive-enough prefixes. IMHO we
should make use of that, for a substantially improved user experience (as
opposed to, say, the user experience for unfortunate CVS users who would
like to establish a git-svn-like workflow).
Summary: I think that for most URLs, "<protocol>://" is enough to tell
which helper to call ("http://" means Git, tough).
For those URLs, where this is not sufficient, a "<vcs>+" should be good
enough, or if you really want, "<vcs>::". As the helper gets the complete
URL, it can figure out how to proceed from here, without any need for
core Git to know how.
Ciao,
Dscho
^ permalink raw reply
* Re: [JGIT] Request for help
From: Mark Struberg @ 2009-09-04 12:27 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Gabe McArthur
In-Reply-To: <2c6b72b30909040522l4f27ed36u10f47517d42d57a3@mail.gmail.com>
Hi Jonas!
See the following documentation:
http://maven.apache.org/plugins/maven-release-plugin/index.html
http://maven.apache.org/plugins/maven-release-plugin/examples/prepare-release.html
http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html
There is also a freely available book from sonatype [1] which contains all the documemtation you need - plus fn lot more :)
LieGrue,
strub
[1] http://www.sonatype.com/book/
--- On Fri, 9/4/09, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> From: Jonas Fonseca <jonas.fonseca@gmail.com>
> Subject: Re: [JGIT] Request for help
> To: "Mark Struberg" <struberg@yahoo.de>
> Cc: git@vger.kernel.org, "Gabe McArthur" <gabriel.mcarthur@gmail.com>
> Date: Friday, September 4, 2009, 2:22 PM
> On Fri, Sep 4, 2009 at 03:33, Mark
> Struberg<struberg@yahoo.de>
> wrote:
> > .) we don't need a tag.sh any more if we work with
> maven. Maven now has the maven-scm-provider-gitexe activated
> by default (since early 2008), so
> > mvn release:prepare
> > mvn release:perform
> > should work if we set the proper <scm> section.
> Any feedback or bugreporting on the maven-git integration is
> highly welcome btw ;)
>
> If tag_jgit.sh goes away, it could be nice to add a
> document showing
> how releasing/tagging it's done the maven way.
>
> --
> Jonas Fonseca
>
^ permalink raw reply
* Re: [JGIT] Request for help
From: Jonas Fonseca @ 2009-09-04 12:22 UTC (permalink / raw)
To: Mark Struberg; +Cc: git, Gabe McArthur
In-Reply-To: <554991.93608.qm@web27807.mail.ukl.yahoo.com>
On Fri, Sep 4, 2009 at 03:33, Mark Struberg<struberg@yahoo.de> wrote:
> .) we don't need a tag.sh any more if we work with maven. Maven now has the maven-scm-provider-gitexe activated by default (since early 2008), so
> mvn release:prepare
> mvn release:perform
> should work if we set the proper <scm> section. Any feedback or bugreporting on the maven-git integration is highly welcome btw ;)
If tag_jgit.sh goes away, it could be nice to add a document showing
how releasing/tagging it's done the maven way.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 2/9] apply --whitespace=fix: detect new blank lines at eof correctly
From: Johannes Sixt @ 2009-09-04 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1252061718-11579-3-git-send-email-gitster@pobox.com>
Junio C Hamano schrieb:
> The command tries to strip blank lines at the end of the file added by a
> patch. However, if the original ends with blank lines, often the patch
> hunk ends like this:
>
> @@ -l,5 +m,7 @@$
> _context$
> _context$
> -deleted$
> +$
> +$
> +$
> _$
> _$
>
> where _ stands for SP and $ shows a end-of-line. This example patch adds
> three trailing blank lines, but the code fails to notice it, because it
> only pays attention to added blank lines at the very end of the hunk. In
> this example, the three added blank lines do not appear textually at the
> end in the patch, even though you can see that they are indeed added at
> the end, if you rearrange the diff like this:
>
> @@ -l,5 +m,7 @@$
> _context$
> _context$
> -deleted$
> _$
> _$
> +$
> +$
> +$
>
> Fix this by not resetting the number of (candidate) added blank lines at
> the end when the loop sees a context line that is empty.
After reading this explanation, I was worried that added blank lines that
are at the end of a patch but apply in the middle of a file would be
mis-attributed as blank lines at EOF. But appearently, they are not, i.e.
such added blank lines are not removed. Could you squash in this test case
that checks for this condition.
-- Hannes
diff --git a/t/t4124-apply-ws-rule.sh b/t/t4124-apply-ws-rule.sh
index ba2b7f9..fedc8b9 100755
--- a/t/t4124-apply-ws-rule.sh
+++ b/t/t4124-apply-ws-rule.sh
@@ -189,4 +189,16 @@ test_expect_success 'blank at EOF with --whitespace=fix (3)' '
test_cmp expect one
'
+test_expect_success 'blank at end of hunk, not at EOF with --whitespace=fix' '
+ { echo a; echo b; echo; echo; echo; echo; echo; echo d; } >one &&
+ git add one &&
+ { echo a; echo c; echo; echo; echo; echo; echo; echo; echo d; } >expect &&
+ cp expect one &&
+ git diff -- one >patch &&
+
+ git checkout one &&
+ git apply --whitespace=fix patch &&
+ test_cmp expect one
+'
+
test_done
^ permalink raw reply related
* [PATCH] Do not scramble password read from .cvspass
From: Pascal Obry @ 2009-09-04 11:58 UTC (permalink / raw)
To: git list
Passwords stored in .cvspass are already scrambled, we do not
want to scramble them twice. Only passwords read from the
command line are scrambled.
This fixes a regression introduced by:
b2139dbd72d16e40eddfd5b9ad1314703b39fe65
Signed-off-by: Pascal Obry <pascal@obry.net>
---
git-cvsimport.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 593832d..c5cdcae 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -238,7 +238,10 @@ sub conn {
}
my $rr = ":pserver:$user\@$serv:$port$repo";
- unless ($pass) {
+ if ($pass) {
+ $pass = $self->_scramble($pass);
+ } else
+ {
open(H,$ENV{'HOME'}."/.cvspass") and do {
#
:pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
while (<H>) {
@@ -253,8 +256,6 @@ sub conn {
};
}
- $pass = $self->_scramble($pass);
-
my ($s, $rep);
if ($proxyhost) {
--
1.6.4.2.253.g0b1fac
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply related
* Re: [PATCH 2/2] git-completion.bash: prevent 'git help' from searching for git repository
From: Gerrit Pape @ 2009-09-04 11:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909041217370.4605@intel-tinevez-2-302>
On Fri, Sep 04, 2009 at 12:22:36PM +0200, Johannes Schindelin wrote:
> -- snipsnap --
> [PATCH] git help -a: do not look for a repository
Perfect, thanks.
Acked-by: Gerrit Pape <pape@smarden.org>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> builtin-help.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/builtin-help.c b/builtin-help.c
> index e1eba77..719aa23 100644
> --- a/builtin-help.c
> +++ b/builtin-help.c
> @@ -416,9 +416,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
> const char *alias;
> load_command_list("git-", &main_cmds, &other_cmds);
>
> - setup_git_directory_gently(&nongit);
> - git_config(git_help_config, NULL);
> -
> argc = parse_options(argc, argv, prefix, builtin_help_options,
> builtin_help_usage, 0);
>
> @@ -429,6 +426,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
> return 0;
> }
>
> + setup_git_directory_gently(&nongit);
> + git_config(git_help_config, NULL);
> +
> if (!argv[0]) {
> printf("usage: %s\n\n", git_usage_string);
> list_common_cmds_help();
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 8/9] diff --whitespace=warn/error: fix blank-at-eof check
From: Junio C Hamano @ 2009-09-04 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <1252061718-11579-1-git-send-email-gitster@pobox.com>
The "diff --check" logic used to share the same issue as the one fixed for
"git apply" earlier in this series, in that a patch that adds new blank
lines at end could appear as
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. Instead of looking at
each line in the patch in the callback, simply count the blank lines from
the end in two versions, and notice the presence of new ones.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 64 +++++++++++++++++++++++++++++++++-----------
t/t4015-diff-whitespace.sh | 7 +++++
2 files changed, 55 insertions(+), 16 deletions(-)
diff --git a/diff.c b/diff.c
index a693d18..c19c476 100644
--- a/diff.c
+++ b/diff.c
@@ -1149,7 +1149,6 @@ struct checkdiff_t {
struct diff_options *o;
unsigned ws_rule;
unsigned status;
- int trailing_blanks_start;
};
static int is_conflict_marker(const char *line, unsigned long len)
@@ -1193,10 +1192,6 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
if (line[0] == '+') {
unsigned bad;
data->lineno++;
- if (!ws_blank_line(line + 1, len - 1, data->ws_rule))
- data->trailing_blanks_start = 0;
- else if (!data->trailing_blanks_start)
- data->trailing_blanks_start = data->lineno;
if (is_conflict_marker(line + 1, len - 1)) {
data->status |= 1;
fprintf(data->o->file,
@@ -1216,14 +1211,12 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
data->o->file, set, reset, ws);
} else if (line[0] == ' ') {
data->lineno++;
- data->trailing_blanks_start = 0;
} else if (line[0] == '@') {
char *plus = strchr(line, '+');
if (plus)
data->lineno = strtol(plus, NULL, 10) - 1;
else
die("invalid diff");
- data->trailing_blanks_start = 0;
}
}
@@ -1437,6 +1430,44 @@ static const struct funcname_pattern_entry *diff_funcname_pattern(struct diff_fi
return NULL;
}
+static int count_trailing_blank(mmfile_t *mf, unsigned ws_rule)
+{
+ char *ptr = mf->ptr;
+ long size = mf->size;
+ int cnt = 0;
+
+ if (!size)
+ return cnt;
+ ptr += size - 1; /* pointing at the very end */
+ if (*ptr != '\n')
+ ; /* incomplete line */
+ else
+ ptr--; /* skip the last LF */
+ while (mf->ptr < ptr) {
+ char *prev_eol;
+ for (prev_eol = ptr; mf->ptr <= prev_eol; prev_eol--)
+ if (*prev_eol == '\n')
+ break;
+ if (!ws_blank_line(prev_eol + 1, ptr - prev_eol, ws_rule))
+ break;
+ cnt++;
+ ptr = prev_eol - 1;
+ }
+ return cnt;
+}
+
+static int adds_blank_at_eof(mmfile_t *mf1, mmfile_t *mf2, unsigned ws_rule)
+{
+ int l1, l2, at;
+ l1 = count_trailing_blank(mf1, ws_rule);
+ l2 = count_trailing_blank(mf2, ws_rule);
+ if (l2 <= l1)
+ return 0;
+ /* starting where? */
+ at = count_lines(mf1->ptr, mf1->size);
+ return (at - l1) + 1; /* the line number counts from 1 */
+}
+
static void builtin_diff(const char *name_a,
const char *name_b,
struct diff_filespec *one,
@@ -1650,15 +1681,16 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
ecb.priv = &data;
xdi_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
- if ((data.ws_rule & WS_BLANK_AT_EOF) &&
- data.trailing_blanks_start) {
- static char *err;
-
- if (!err)
- err = whitespace_error_string(WS_BLANK_AT_EOF);
- fprintf(o->file, "%s:%d: %s\n",
- data.filename, data.trailing_blanks_start, err);
- data.status = 1; /* report errors */
+ if (data.ws_rule & WS_BLANK_AT_EOF) {
+ int blank_at_eof = adds_blank_at_eof(&mf1, &mf2, data.ws_rule);
+ if (blank_at_eof) {
+ static char *err;
+ if (!err)
+ err = whitespace_error_string(WS_BLANK_AT_EOF);
+ fprintf(o->file, "%s:%d: %s.\n",
+ data.filename, blank_at_eof, err);
+ data.status = 1; /* report errors */
+ }
}
}
free_and_return:
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index a5d4461..e0b481d 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -341,6 +341,13 @@ test_expect_success 'checkdiff detects new trailing blank lines (1)' '
git diff --check | grep "new blank line"
'
+test_expect_success 'checkdiff detects new trailing blank lines (2)' '
+ { echo a; echo b; echo; echo; } >x &&
+ git add x &&
+ { echo a; echo; echo; echo; echo; } >x &&
+ git diff --check | grep "new blank line"
+'
+
test_expect_success 'checkdiff allows new blank lines' '
git checkout x &&
mv x y &&
--
1.6.4.2.313.g0425f
^ permalink raw reply related
* [PATCH 9/9] diff --color: color blank-at-eof
From: Junio C Hamano @ 2009-09-04 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <1252061718-11579-1-git-send-email-gitster@pobox.com>
Since the coloring logic processed the patch output one line at a time, we
couldn't easily color code the new blank lines at the end of file.
Reuse the adds_blank_at_eof() function to find where the runs of such
blank lines start, keep track of the line number in the preimage while
processing the patch output one line at a time, and paint the new blank
lines that appear after that line to implement this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 37 +++++++++++++++++++++++++++----------
t/t4019-diff-wserror.sh | 9 +++++++++
2 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/diff.c b/diff.c
index c19c476..2b285b8 100644
--- a/diff.c
+++ b/diff.c
@@ -491,6 +491,8 @@ struct emit_callback {
struct xdiff_emit_state xm;
int color_diff;
unsigned ws_rule;
+ int blank_at_eof;
+ int lno_in_preimage;
sane_truncate_fn truncate;
const char **label_path;
struct diff_words_data *diff_words;
@@ -547,6 +549,12 @@ static void emit_add_line(const char *reset, struct emit_callback *ecbdata, cons
if (!*ws)
emit_line(ecbdata->file, set, reset, line, len);
+ else if ((ecbdata->ws_rule & WS_BLANK_AT_EOF) &&
+ ecbdata->blank_at_eof &&
+ (ecbdata->blank_at_eof <= ecbdata->lno_in_preimage) &&
+ ws_blank_line(line + 1, len - 1, ecbdata->ws_rule))
+ /* Blank line at EOF */
+ emit_line(ecbdata->file, ws, reset, line, len);
else {
/* Emit just the prefix, then the rest. */
emit_line(ecbdata->file, set, reset, line, 1);
@@ -573,9 +581,16 @@ static unsigned long sane_truncate_line(struct emit_callback *ecb, char *line, u
return allot - l;
}
+static int find_preimage_lno(const char *line)
+{
+ char *p = strchr(line, '-');
+ if (!p)
+ return 0; /* should not happen */
+ return strtol(p+1, NULL, 10);
+}
+
static void fn_out_consume(void *priv, char *line, unsigned long len)
{
- int color;
struct emit_callback *ecbdata = priv;
const char *meta = diff_get_color(ecbdata->color_diff, DIFF_METAINFO);
const char *plain = diff_get_color(ecbdata->color_diff, DIFF_PLAIN);
@@ -598,6 +613,7 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
if (line[0] == '@') {
len = sane_truncate_line(ecbdata, line, len);
+ ecbdata->lno_in_preimage = find_preimage_lno(line);
emit_line(ecbdata->file,
diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO),
reset, line, len);
@@ -611,7 +627,6 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
return;
}
- color = DIFF_PLAIN;
if (ecbdata->diff_words) {
if (line[0] == '-') {
diff_words_append(line, len,
@@ -630,14 +645,13 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
emit_line(ecbdata->file, plain, reset, line, len);
return;
}
- if (line[0] == '-')
- color = DIFF_FILE_OLD;
- else if (line[0] == '+')
- color = DIFF_FILE_NEW;
- if (color != DIFF_FILE_NEW) {
- emit_line(ecbdata->file,
- diff_get_color(ecbdata->color_diff, color),
- reset, line, len);
+
+ if (line[0] != '+') {
+ const char *color =
+ diff_get_color(ecbdata->color_diff,
+ line[0] == '-' ? DIFF_FILE_OLD : DIFF_PLAIN);
+ ecbdata->lno_in_preimage++;
+ emit_line(ecbdata->file, color, reset, line, len);
return;
}
emit_add_line(reset, ecbdata, line, len);
@@ -1557,6 +1571,9 @@ static void builtin_diff(const char *name_a,
ecbdata.color_diff = DIFF_OPT_TST(o, COLOR_DIFF);
ecbdata.found_changesp = &o->found_changes;
ecbdata.ws_rule = whitespace_rule(name_b ? name_b : name_a);
+ if (ecbdata.ws_rule & WS_BLANK_AT_EOF)
+ ecbdata.blank_at_eof =
+ adds_blank_at_eof(&mf1, &mf2, ecbdata.ws_rule);
ecbdata.file = o->file;
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
xecfg.ctxlen = o->context;
diff --git a/t/t4019-diff-wserror.sh b/t/t4019-diff-wserror.sh
index 1517fff..1e75f1a 100755
--- a/t/t4019-diff-wserror.sh
+++ b/t/t4019-diff-wserror.sh
@@ -190,4 +190,13 @@ test_expect_success 'do not color trailing cr in context' '
'
+test_expect_success 'color new trailing blank lines' '
+ { echo a; echo b; echo; echo; } >x &&
+ git add x &&
+ { echo a; echo; echo; echo; echo; } >x &&
+ git diff --color x >output &&
+ cnt=$(grep "${blue_grep}" output | wc -l) &&
+ test $cnt = 2
+'
+
test_done
--
1.6.4.2.313.g0425f
^ permalink raw reply related
* [PATCH 7/9] diff --whitespace=warn/error: obey blank-at-eof
From: Junio C Hamano @ 2009-09-04 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <1252061718-11579-1-git-send-email-gitster@pobox.com>
The "diff --check" code used to conflate trailing-space whitespace error
class with this, but now we have a proper separate error class, we should
check it under blank-at-eof, not trailing-space.
The whitespace error is not about _having_ blank lines at end, but about
adding _new_ blank lines. To keep the message consistent with what is
given by "git apply", call whitespace_error_string() to generate it,
instead of using a hardcoded custom message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 10 +++++++---
t/t4015-diff-whitespace.sh | 4 ++--
t/t4019-diff-wserror.sh | 2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index 1eddd59..a693d18 100644
--- a/diff.c
+++ b/diff.c
@@ -1650,10 +1650,14 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
ecb.priv = &data;
xdi_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
- if ((data.ws_rule & WS_TRAILING_SPACE) &&
+ if ((data.ws_rule & WS_BLANK_AT_EOF) &&
data.trailing_blanks_start) {
- fprintf(o->file, "%s:%d: ends with blank lines.\n",
- data.filename, data.trailing_blanks_start);
+ static char *err;
+
+ if (!err)
+ err = whitespace_error_string(WS_BLANK_AT_EOF);
+ fprintf(o->file, "%s:%d: %s\n",
+ data.filename, data.trailing_blanks_start, err);
data.status = 1; /* report errors */
}
}
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index b1cbd36..a5d4461 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -335,10 +335,10 @@ test_expect_success 'line numbers in --check output are correct' '
'
-test_expect_success 'checkdiff detects trailing blank lines' '
+test_expect_success 'checkdiff detects new trailing blank lines (1)' '
echo "foo();" >x &&
echo "" >>x &&
- git diff --check | grep "ends with blank"
+ git diff --check | grep "new blank line"
'
test_expect_success 'checkdiff allows new blank lines' '
diff --git a/t/t4019-diff-wserror.sh b/t/t4019-diff-wserror.sh
index 84a1fe3..1517fff 100755
--- a/t/t4019-diff-wserror.sh
+++ b/t/t4019-diff-wserror.sh
@@ -165,7 +165,7 @@ test_expect_success 'trailing empty lines (1)' '
rm -f .gitattributes &&
test_must_fail git diff --check >output &&
- grep "ends with blank lines." output &&
+ grep "new blank line at" output &&
grep "trailing whitespace" output
'
--
1.6.4.2.313.g0425f
^ permalink raw reply related
* [PATCH 6/9] diff.c: the builtin_diff() deals with only two-file comparison
From: Junio C Hamano @ 2009-09-04 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <1252061718-11579-1-git-send-email-gitster@pobox.com>
The combined diff is implemented in combine_diff() and fn_out_consume()
codepath never has to deal with anything but two-file comparison.
Drop nparents from the emit_callback structure and simplify the code.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff.c | 32 +++++++++-----------------------
1 files changed, 9 insertions(+), 23 deletions(-)
diff --git a/diff.c b/diff.c
index 6fea3c0..1eddd59 100644
--- a/diff.c
+++ b/diff.c
@@ -489,7 +489,7 @@ typedef unsigned long (*sane_truncate_fn)(char *line, unsigned long len);
struct emit_callback {
struct xdiff_emit_state xm;
- int nparents, color_diff;
+ int color_diff;
unsigned ws_rule;
sane_truncate_fn truncate;
const char **label_path;
@@ -549,9 +549,8 @@ static void emit_add_line(const char *reset, struct emit_callback *ecbdata, cons
emit_line(ecbdata->file, set, reset, line, len);
else {
/* Emit just the prefix, then the rest. */
- emit_line(ecbdata->file, set, reset, line, ecbdata->nparents);
- ws_check_emit(line + ecbdata->nparents,
- len - ecbdata->nparents, ecbdata->ws_rule,
+ emit_line(ecbdata->file, set, reset, line, 1);
+ ws_check_emit(line + 1, len - 1, ecbdata->ws_rule,
ecbdata->file, set, reset, ws);
}
}
@@ -576,7 +575,6 @@ static unsigned long sane_truncate_line(struct emit_callback *ecb, char *line, u
static void fn_out_consume(void *priv, char *line, unsigned long len)
{
- int i;
int color;
struct emit_callback *ecbdata = priv;
const char *meta = diff_get_color(ecbdata->color_diff, DIFF_METAINFO);
@@ -598,13 +596,7 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
ecbdata->label_path[0] = ecbdata->label_path[1] = NULL;
}
- /* This is not really necessary for now because
- * this codepath only deals with two-way diffs.
- */
- for (i = 0; i < len && line[i] == '@'; i++)
- ;
- if (2 <= i && i < len && line[i] == ' ') {
- ecbdata->nparents = i - 1;
+ if (line[0] == '@') {
len = sane_truncate_line(ecbdata, line, len);
emit_line(ecbdata->file,
diff_get_color(ecbdata->color_diff, DIFF_FRAGINFO),
@@ -614,15 +606,12 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
return;
}
- if (len < ecbdata->nparents) {
+ if (len < 1) {
emit_line(ecbdata->file, reset, reset, line, len);
return;
}
color = DIFF_PLAIN;
- if (ecbdata->diff_words && ecbdata->nparents != 1)
- /* fall back to normal diff */
- free_diff_words_data(ecbdata);
if (ecbdata->diff_words) {
if (line[0] == '-') {
diff_words_append(line, len,
@@ -641,13 +630,10 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
emit_line(ecbdata->file, plain, reset, line, len);
return;
}
- for (i = 0; i < ecbdata->nparents && len; i++) {
- if (line[i] == '-')
- color = DIFF_FILE_OLD;
- else if (line[i] == '+')
- color = DIFF_FILE_NEW;
- }
-
+ if (line[0] == '-')
+ color = DIFF_FILE_OLD;
+ else if (line[0] == '+')
+ color = DIFF_FILE_NEW;
if (color != DIFF_FILE_NEW) {
emit_line(ecbdata->file,
diff_get_color(ecbdata->color_diff, color),
--
1.6.4.2.313.g0425f
^ 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