* Re: Email address from username and hostname preferred over $EMAIL
From: Junio C Hamano @ 2007-07-06 1:17 UTC (permalink / raw)
To: Brandon Casey; +Cc: Linus Torvalds, mkraai, git
In-Reply-To: <468D917F.9090707@nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Linus Torvalds wrote:
>
>> If you want it to prefer $EMAIL, you'd need to change the
>> initialization of git_default_email, methinks.
>>
>> Linus
>
> I just sent an email to the list, and not in reply to this thread
> because I thought I read a comment about not posting a patch deep in
> a thread.
>
> But, I'm thinking I should have just posted it as a reply to the thread
> since I quoted a portion of your message.
Are Brandon Casey and Matt Kraai the same person?
I do not mind threadedness of the patch too much, but the patch
recently posted by the latter does not have any description
other than the title.
Other than that, I think the change itself seems sane.
^ permalink raw reply
* Re: git-apply{,mbox,patch} should default to --unidiff-zero
From: Johannes Schindelin @ 2007-07-06 1:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: git
In-Reply-To: <20070705232210.GR3492@stusta.de>
Hi,
On Fri, 6 Jul 2007, Adrian Bunk wrote:
> git-apply{,mbox,patch} should default to doing --unidiff-zero:
But is that not dangerous? At least now the committer has some safeguard
against this kind of mistakes. Because you can easily introduce mistakes
that way.
Ciao,
Dscho
^ permalink raw reply
* Re: Update local tracking refs when pushing- no way to disable
From: Junio C Hamano @ 2007-07-06 1:31 UTC (permalink / raw)
To: Dan McGee; +Cc: git, Daniel Barkalow
In-Reply-To: <449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com>
"Dan McGee" <dpmcgee@gmail.com> writes:
> In this commit:
> b516968ff62ec153e008d033c153affd7ba9ddc6
>
> I don't know if anyone else has the same way of working as I do, but I
> tend to set the "remote.<name>.skipDefaultUpdate" property to true for
> my publicly visible repository, just so I don't have duplicate branch
> heads lying around in my local repository. Call this peculiar, but I
> like it that way. However, git-push does not respect this property,
> meaning I know have these branches whether I want them or not. In a
> tool such as qgit or even 'git branch -a' output, it starts to get
> awful cluttered.
Actually I do not think git-push nor git-fetch are related to
what that configuration variable tries to control at all. The
variable controls what "git remote update" does.
Do you fetch from your 'publicly visible repository', and do you
use tracking branches for it when you do "git fetch" from there?
$ git push my-public
is supposed to pretend that immediately after the push you did
"git fetch my-public" _if_and_only_if_ your "git fetch
my-public" would fetch the branches you pushed, and you have
configured to store them in .git/refs/remotes/my-public/
(i.e. your tracking branches). So if you do not fetch from your
remote and do not have configuration to use tracking branches
when you fetch from there, and if you still see that your push
updates your tracking branches, then you found a bug.
But if you do have configuration to use tracking branches when
you fetch from there, that is a different story. I do not think
there currently is a way to disable that "pretend we have
fetched back immediately" behaviour. There could be valid
reasons that you may _want_ to keep your existing tracking
branches stale after a push, in which case we may want to make
it overridable, but at the time that change was accepted, nobody
had such a convincing use scenario.
^ permalink raw reply
* Re: git-apply{,mbox,patch} should default to --unidiff-zero
From: Adrian Bunk @ 2007-07-06 1:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707060217460.9789@racer.site>
On Fri, Jul 06, 2007 at 02:18:46AM +0100, Johannes Schindelin wrote:
> Hi,
Hi Johannes,
> On Fri, 6 Jul 2007, Adrian Bunk wrote:
>
> > git-apply{,mbox,patch} should default to doing --unidiff-zero:
>
> But is that not dangerous? At least now the committer has some safeguard
> against this kind of mistakes. Because you can easily introduce mistakes
> that way.
you are saying "easily".
Did you ever actually run into such a problem?
You must do something like "diff -U0" or manually editing patches for
creating such patches, and that's very unusual.
And although GNU patch (which has a much bigger userbase than git)
applies such patches without any warning I don't remember having ever
seen what you call "easily".
> Ciao,
> Dscho
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: git-apply{,mbox,patch} should default to --unidiff-zero
From: Johannes Schindelin @ 2007-07-06 1:51 UTC (permalink / raw)
To: Adrian Bunk; +Cc: git
In-Reply-To: <20070706014222.GK3492@stusta.de>
Hi,
On Fri, 6 Jul 2007, Adrian Bunk wrote:
> On Fri, Jul 06, 2007 at 02:18:46AM +0100, Johannes Schindelin wrote:
>
> > On Fri, 6 Jul 2007, Adrian Bunk wrote:
> >
> > > git-apply{,mbox,patch} should default to doing --unidiff-zero:
> >
> > But is that not dangerous? At least now the committer has some
> > safeguard against this kind of mistakes. Because you can easily
> > introduce mistakes that way.
>
> you are saying "easily".
>
> Did you ever actually run into such a problem?
Not yet, thankfully.
> You must do something like "diff -U0" or manually editing patches for
> creating such patches, and that's very unusual.
The point is that the _committer_ is not necessarily involved in that
business.
And "git apply" is strict for a reason. It catches possibly unwanted
things much earlier than patch. I _want_ to be warned that somebody is
introducing some code at a certain position, which might, or might not be
correct. apply has no way to tell, since there is no context to at least
minimally verify.
> And although GNU patch (which has a much bigger userbase than git)
> applies such patches without any warning I don't remember having ever
> seen what you call "easily".
GNU patch is very sloppy. And I had to fix up quite a number of patches
which were "successfully" applied, but did not do what they were supposed
to do. The recent "GNU patch applies _indented_ _context_ diffs" fracass
is only one example why I prefer git apply.
Unfortunately, I do not off-hand remember if I had to fix up a
unified-zero patch that GNU patch applied, but I do know this:
if "git am" learns to apply unified-zero by default, the first
thing I will do is patch it in my Git branch to _not_ do that. I
do _not_ want that. I want to be warned.
I can still decide that it is probably okay, but I will make
_damned_ _well_ sure afterwards that it did something sensible. I
will _only_ apply such a scrutiny when git apply refused to apply
a unified-zero patch, and I decided to apply it nevertheless.
Ciao,
Dscho
^ permalink raw reply
* Re: git-apply{,mbox,patch} should default to --unidiff-zero
From: Adrian Bunk @ 2007-07-06 2:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707060243110.4093@racer.site>
On Fri, Jul 06, 2007 at 02:51:07AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 6 Jul 2007, Adrian Bunk wrote:
>
> > On Fri, Jul 06, 2007 at 02:18:46AM +0100, Johannes Schindelin wrote:
> >
> > > On Fri, 6 Jul 2007, Adrian Bunk wrote:
> > >
> > > > git-apply{,mbox,patch} should default to doing --unidiff-zero:
> > >
> > > But is that not dangerous? At least now the committer has some
> > > safeguard against this kind of mistakes. Because you can easily
> > > introduce mistakes that way.
> >
> > you are saying "easily".
> >
> > Did you ever actually run into such a problem?
>
> Not yet, thankfully.
>
> > You must do something like "diff -U0" or manually editing patches for
> > creating such patches, and that's very unusual.
>
> The point is that the _committer_ is not necessarily involved in that
> business.
>
> And "git apply" is strict for a reason. It catches possibly unwanted
> things much earlier than patch. I _want_ to be warned that somebody is
> introducing some code at a certain position, which might, or might not be
> correct. apply has no way to tell, since there is no context to at least
> minimally verify.
>...
That's wrong.
My use cases are replacing or deleting lines.
In these cases there is context in the deleted lines that is already
being verified even with --unidiff-zero.
> Ciao,
> Dscho
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Josh Triplett @ 2007-07-06 3:22 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20070705135824.GB5493@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
Jeff King wrote:
> On Wed, Jul 04, 2007 at 03:36:01PM +0100, Johannes Schindelin wrote:
>
>> It is slightly ugly that the output of msg-filter is written
>> to a temporary file. But I do not know a better method to
>> catch a failing msg-filter. Help?
>
> If you mean, in general, to catch the exit code of the first part of a
> pipe, you have to do something like this:
>
> status=`((cmd1; echo $? >&3) | cmd2) 3>&1`
>
> which is pretty ugly in itself, and if you want the stdout of cmd2, then
> you have to add even more redirection. I'm not sure it's worth it.
bash has "set -o pipefail", but that would require bash. However, you could
try setting pipefail, and ignoring any failure to set it; that would give the
more friendly behavior with bash, while still allowing any /bin/sh in general.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git-apply{,mbox,patch} should default to --unidiff-zero
From: Johannes Schindelin @ 2007-07-06 3:16 UTC (permalink / raw)
To: Adrian Bunk; +Cc: git
In-Reply-To: <20070706022629.GL3492@stusta.de>
Hi,
On Fri, 6 Jul 2007, Adrian Bunk wrote:
> On Fri, Jul 06, 2007 at 02:51:07AM +0100, Johannes Schindelin wrote:
> >
> > On Fri, 6 Jul 2007, Adrian Bunk wrote:
> >
> > > You must do something like "diff -U0" or manually editing patches
> > > for creating such patches, and that's very unusual.
> >
> > The point is that the _committer_ is not necessarily involved in that
> > business.
BTW this still holds true, and you have not addressed that. It really is
a serious issue. "git apply" is a committer's tool. So it should help
the committer.
> > And "git apply" is strict for a reason. It catches possibly unwanted
> > things much earlier than patch. I _want_ to be warned that somebody is
> > introducing some code at a certain position, which might, or might not
> > be correct. apply has no way to tell, since there is no context to at
> > least minimally verify.
> >...
>
> That's wrong.
>
> My use cases are replacing or deleting lines.
That is _your_ use case.
> In these cases there is context in the deleted lines that is already
> being verified even with --unidiff-zero.
With --unidiff-zero, also _adding_ lines will be handled as if there were
no problem.
Yes, in your case it fixes a problem.
Yet, in other cases it introduces a problem.
Okay?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Johannes Schindelin @ 2007-07-06 3:18 UTC (permalink / raw)
To: Josh Triplett; +Cc: Jeff King, git
In-Reply-To: <468DB570.1090900@freedesktop.org>
Hi,
On Thu, 5 Jul 2007, Josh Triplett wrote:
> bash has "set -o pipefail", but that would require bash. However, you
> could try setting pipefail, and ignoring any failure to set it; that
> would give the more friendly behavior with bash, while still allowing
> any /bin/sh in general.
I was aware of pipefail when I wrote that patch. However, I have zero
interest in a "solution" which works on bash, but fails on other shells.
That is like allowing a precious few to overstep some serious line (and
commuting them), but severely punish all others. And that's wrong. And
to allow it to happen is wrong, too.
Ciao,
Dscho
^ permalink raw reply
* Re: Update local tracking refs when pushing- no way to disable
From: Daniel Barkalow @ 2007-07-06 3:37 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <449c10960707051722q6650ec7dq6012695acdfba4af@mail.gmail.com>
On Thu, 5 Jul 2007, Dan McGee wrote:
> In this commit:
> b516968ff62ec153e008d033c153affd7ba9ddc6
>
> I don't know if anyone else has the same way of working as I do, but I
> tend to set the "remote.<name>.skipDefaultUpdate" property to true for
> my publicly visible repository, just so I don't have duplicate branch
> heads lying around in my local repository. Call this peculiar, but I
> like it that way. However, git-push does not respect this property,
> meaning I know have these branches whether I want them or not. In a
> tool such as qgit or even 'git branch -a' output, it starts to get
> awful cluttered.
What git-fetch and git-push care about is whether you have an entry
"remote.<name>.fetch" with a colon and stuff on the right of it. If so,
this is a pattern that is used to generate the duplicate branch heads that
you don't want. git clone sets it up to a default pattern
(refs/remotes/origin/*), and I don't think there's any way to make it not
do that, but you can just reconfigure it afterwards if you don't like it.
I can't see where git-push would get the names to use if you don't have
such an entry, and having the entry isn't useful if you actually don't
want those refs. It's probably just a matter of deleting it, since it was
probably created for you by some tool trying to be helpful.
(AFAICT, the only additional stuff that -a shows with git branch is the
stuff that you're deleting; perhaps qgit should have an option to not show
remotes, or not show them by default or only show them if what they point
to isn't otherwise marked? Anyway, it shouldn't be necessary to avoid
having this information just so that it isn't shown in interfaces you
use.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Email address from username and hostname preferred over $EMAIL
From: Josh Triplett @ 2007-07-06 3:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: mkraai, git
In-Reply-To: <alpine.LFD.0.98.0707051357360.9434@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
Linus Torvalds wrote:
> On Thu, 5 Jul 2007, mkraai@beckman.com wrote:
>> Git prefers to use an email address constructed from the username and
>> hostname to the value of the EMAIL environment variable. I think it
>> should prefer the latter to the former. This problem was introduced by
>> ec563e8153cba89728a271a26c8a94e7a42d8152.
>
> It did that very much on purpose. "git_default_email" must take
> precedence, because that's the one that is filled in by the config file
> syntax.
>
> So just use
>
> [user]
> name = ..
> email = ..
>
> and be happy. Only in the absense of that will git start guessing, and
> yeah, it will not generally use EMAIL, unless it cannot get anything at
> all from username/hostname.
>
> If you want it to prefer $EMAIL, you'd need to change the initialization
> of git_default_email, methinks.
When I originally wrote the patch, I did so intending that $EMAIL would always
override git's guess of user@hostname. I set GIT_{AUTHOR,COMMITTER}_EMAIL in
my environment specifically so that git would stop using guesses like
josh@josh-mobile and start using my actual email address. I submitted the
$EMAIL patch in hopes that eventually I could stop setting the git-specific
email addresses and just set $EMAIL, which I already do for other tools. In
order for that to work, $EMAIL should always override git's guesses.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git-apply{,mbox,patch} should default to --unidiff-zero
From: Linus Torvalds @ 2007-07-06 4:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Adrian Bunk, git
In-Reply-To: <Pine.LNX.4.64.0707060413190.4093@racer.site>
On Fri, 6 Jul 2007, Johannes Schindelin wrote:
>
> With --unidiff-zero, also _adding_ lines will be handled as if there were
> no problem.
>
> Yes, in your case it fixes a problem.
>
> Yet, in other cases it introduces a problem.
Well, we could make the rule be that ew require --unidiff-zero only if
there really is _no_ old data to verify in a hunk. No deleted lines, and
no context around it.
Adrian has a point in that if there are lines to be deleted, that in
itself is context, and then the strict behaviour of "git-apply" is
arguably unnecessaily strict.
That said, I do absolutely _hate_ how GNU patch will basically apply
random line noise without complaints. So git-apply is designed to be much
stricter on _so_ many levels. The thing that I personally always really
detested about GNU patch was how it would apply part of a patch, then fail
half-way, and leave the partial patch applied!
git-apply is about a million times better than standard "patch", exactly
because it tries to make sure that what it does makes sense, and you
actually need to use explicit flags to make it do things that may be hard
to undo or slightly questionable.
Linus
^ permalink raw reply
* Re: [PATCH] git init: activate rerere by default
From: Junio C Hamano @ 2007-07-06 5:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0707052018260.9789@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> .... I guess that many
> distros do not update their templates as often as the core, because they
> are much more likely to be modified distro-specifically.
Can you back that up? Fedora and Debian seem to ship them unmodified.
> Further, there
> are some platforms which are insane enough that you cannot trust the
> executable bit, and therefore the templates are disabled by default.
>
> All this means that the given patch would not hardly make rerere as
> widespread as I intended.
If you truly want to have rerere enabled by default, it might
make sense to:
* Remove "if test -d "$GIT_DIR/rr-cache" tests we have in the
existing users;
* Implement a new test in builtin-rerere.c, as:
- if rerere.enabled configuration does not exist, check
$GIT_DIR/rr-cache as before;
- if rerere.enabled configuration is true, do not bother
checking $GIT_DIR/rr-cache, but just do it;
- if rerere.enabled configuration is explicitly set to false,
never use rerere.
* Maybe later we might change the default value for
rerere.enabled to "true", IOW, everybody except people who
say "[rerere] enabled = false" in their configuration
automatically gets rerere.
Doing it in git-init, either your patch or by installing a new
template, means existing old repository would never get the
updated behaviour unless the user runs "git init" there, which
is not a very intuitive thing to do to begin with.
^ permalink raw reply
* Re: git-apply{,mbox,patch} should default to --unidiff-zero
From: Junio C Hamano @ 2007-07-06 5:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Adrian Bunk, git
In-Reply-To: <alpine.LFD.0.98.0707052108070.9434@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Well, we could make the rule be that we require --unidiff-zero only if
> there really is _no_ old data to verify in a hunk. No deleted lines, and
> no context around it.
There are two things --unidiff-zero affects, because git-apply
needs to disable otherwise reasonable sanity checks it does for
safety:
- When we see a patch that has only one hunk, and its change
consists of only deletion, we can verify and complain if the
header does not say it delete the file. Not so if the patch
was created without "diff -u0". The same applies for "only
addition" vs. "creation of the file".
- When there is no leading context in the hunk, it usually has
to match only at the beginning of the file (same for
"following context" vs "at the end of the file"), and we do
perform this sanity check. However, "diff -u0" patch needs
to bypass it, as not having any context is the norm.
Because "diff -u0" is unusual, these sanity checks are disabled
only when the user explicitly says --unidiff-zero when applying.
> Adrian has a point in that if there are lines to be deleted, that in
> itself is context, and then the strict behaviour of "git-apply" is
> arguably unnecessaily strict.
Not really. That is true, unless you have two identical
instances of the group of lines being deleted, in which case you
cannot safely tell which instance is to be removed.
> That said, I do absolutely _hate_ how GNU patch will basically apply
> random line noise without complaints. So git-apply is designed to be much
> stricter on _so_ many levels. The thing that I personally always really
> detested about GNU patch was how it would apply part of a patch, then fail
> half-way, and leave the partial patch applied!
>
> git-apply is about a million times better than standard "patch", exactly
> because it tries to make sure that what it does makes sense, and you
> actually need to use explicit flags to make it do things that may be hard
> to undo or slightly questionable.
No question about it.
^ permalink raw reply
* Re: [PATCH] git-send-email: allow an email alias for --from
From: Junio C Hamano @ 2007-07-06 5:43 UTC (permalink / raw)
To: git; +Cc: Michael Hendricks
In-Reply-To: <11835978963177-git-send-email-michael@ndrix.org>
This sounds sane. List?
^ permalink raw reply
* Re: [PATCH] fix remote.origin.url in tutorial.txt
From: Junio C Hamano @ 2007-07-06 5:44 UTC (permalink / raw)
To: Alecs King; +Cc: git
In-Reply-To: <20070705162116.GA5337@localhost>
Thanks.
^ permalink raw reply
* [PATCH] Fixed a formulation mistake in Documentation/user-manual.txt
From: Marcus Fritzsch @ 2007-07-06 7:02 UTC (permalink / raw)
To: git, gitster
This one fixes a small formulation weirdness in
Documentation/user-manual.txt
Signed-off-by: Marcus Fritzsch <m@fritschy.de>
---
Documentation/user-manual.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ff7c71d..c23077c 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2957,13 +2957,13 @@ developed. If you blow the directory cache away entirely, you generally
haven't lost any information as long as you have the name of the tree
that it described.
-At the same time, the index is at the same time also the
-staging area for creating new trees, and creating a new tree always
-involves a controlled modification of the index file. In particular,
-the index file can have the representation of an intermediate tree that
-has not yet been instantiated. So the index can be thought of as a
-write-back cache, which can contain dirty information that has not yet
-been written back to the backing store.
+At the same time, the index is also the staging area for creating
+new trees, and creating a new tree always involves a controlled
+modification of the index file. In particular, the index file can
+have the representation of an intermediate tree that has not yet been
+instantiated. So the index can be thought of as a write-back cache,
+which can contain dirty information that has not yet been written back
+to the backing store.
--
1.5.3.rc0.31.g39f17
^ permalink raw reply related
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Johannes Sixt @ 2007-07-06 7:06 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <Pine.LNX.4.64.0707051636240.9789@racer.site>
Johannes Schindelin wrote:
> - sed -e '1,/^$/d' <../commit | \
> - eval "$filter_msg" | \
> - sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
> - $parentstr > ../map/$commit
> + (sed -e '1,/^$/d' <../commit |
> + (eval "$filter_msg" ||
> + die "msg filter failed: $filter_msg" 2>&3) |
> + (sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
> + $parentstr > ../map/$commit ||
> + die "commit filter failed: $filter_commit" 2>&3)) 3>&1 |
> + grep . && die
You introduce a handful of new forks and an exec. Isn't an intermediate
file much cheaper?
-- Hannes
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Marco Costalba @ 2007-07-06 7:54 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, git
In-Reply-To: <20070704182806.GA3268@efreet.light.src>
On 7/4/07, Jan Hudec <bulb@ucw.cz> wrote:
>
> > 3- More robust to API change
> > 4- Less easy to break by changes in git.
>
> Actually, no. The porcelains are more likely to change than the plumbing.
>
Well, changing internal API does not break compatibility, _modifying_
user commands behaviour yes and you need to release a new version for
this.
If for "change" you mean adding stuff then, yes, I agree with you, but
adding stuff is not a problem.
> > Having said that, from '-F' option documentation:
> >
> > -F <file>::
> > Take the commit message from the given file. Use '-' to
> > read the message from the standard input.
> >
> > Jan, what about to use '-' and feed message from stdin?
>
> I actually am, because I am rewriting it to use plumbing, which means
> git-write-tree and git-commit-tree directly. And git-commit-tree always reads
> commit message from stdin.
>
> > Indeed the full signature of run() is:
> >
> > bool Git::run(SCRef runCmd, QString* runOutput, QObject* receiver, SCRef
> > buf)
> >
> > Where the last parameter 'buf' it's a string that, if not empty, is
> > passed to the launched program stdin.
>
> ... except if I read the code correctly, it will create a temporary file
> anyway. The comment in QGit::startProcess says it is because of windows, but
> there is nothing to disable it in Unix, so to me it seems temporary file is
> used anyway.
>
Yes you are right, but the file is redirected to process stdin by the call
proc->setStandardInputFile()
just below the comment you reported. I can assure you it works because
to read file names it is used "git diff-tree -r -C --stdin" without
problems.
Sorry for mt late reply, but I'm abroad this week and can access the
email only seldom.
Marco
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: David Kastrup @ 2007-07-06 8:06 UTC (permalink / raw)
To: git
In-Reply-To: <468DE9F3.B4489CDE@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Johannes Schindelin wrote:
>> - sed -e '1,/^$/d' <../commit | \
>> - eval "$filter_msg" | \
>> - sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
>> - $parentstr > ../map/$commit
>> + (sed -e '1,/^$/d' <../commit |
>> + (eval "$filter_msg" ||
>> + die "msg filter failed: $filter_msg" 2>&3) |
>> + (sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
>> + $parentstr > ../map/$commit ||
>> + die "commit filter failed: $filter_commit" 2>&3)) 3>&1 |
>> + grep . && die
>
> You introduce a handful of new forks and an exec. Isn't an intermediate
> file much cheaper?
The number of forks can be reduced by using { ...; } instead of (
... ) here (though it is possible the shell optimizes them away).
grep . should likely redirect its output with >&2 so that it ends up
on stderr. I'd probably prefer grep ^ or grep '' since that matches
empty lines as well. When done that way, I don't see a "handful of
new forks".
Instead of "grep ." one could also do something like
if read line then
while echo "$line" && read line; do :; done
die
fi
which is fork-less.
--
David Kastrup
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Marco Costalba @ 2007-07-06 8:12 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070705185426.GB3991@efreet.light.src>
On 7/5/07, Jan Hudec <bulb@ucw.cz> wrote:
>
> Therefore I'll either have to always ask git via run("git-rev-parse HEAD",
> head), add HEAD into the map, or store HEAD somewhere in the Git object.
> Which do you think makes most sense?
>
Asking git when you need it and keep HEAD value only for the minimum
time required to execute the commit command.
- HEAD is very 'volatile'
- commit is _not_ performance critical.
- commit, being a write operation, is instead bugs/misbehaviour
critical (a big point to use an high level "git-commit" BTW)
- asking git with getRefSha("HEAD", ANY_REF, true) is very quick and
in any case much quicker then the whole commit dance.
- someone can always change the repo behind you, qgit is not the only
interface to git ;-) does exist also the command line.
Marco
^ permalink raw reply
* Re: Update local tracking refs when pushing- no way to disable
From: Marco Costalba @ 2007-07-06 8:26 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Dan McGee, git
In-Reply-To: <Pine.LNX.4.64.0707052320090.14638@iabervon.org>
On 7/6/07, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> (AFAICT, the only additional stuff that -a shows with git branch is the
> stuff that you're deleting; perhaps qgit should have an option to not show
> remotes, or not show them by default or only show them if what they point
> to isn't otherwise marked? Anyway, it shouldn't be necessary to avoid
> having this information just so that it isn't shown in interfaces you
> use.)
>
Probably an option "show remote branches" from a popup context menu
(right click) is the more natural and predictable solution.
In case someone is interested, please confirm me, I will add that.
Marco
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Junio C Hamano @ 2007-07-06 8:33 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <863b02j6qs.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> Instead of "grep ." one could also do something like
>
> if read line then
> while echo "$line" && read line; do :; done
> die
> fi
>
> which is fork-less.
I'd agree with you that "grep ^" would be preferable _if_ we
were to do this. But in your fork-less example, you are
assuming that (1) "read" does not molest what is read, (2)
"echo" is built-in, and (3) "echo" does not munge the
parameter.
Since I am one of old fashioned shell people (I readily admit
that I used to have _fun_ with autoconf generated shell
scripts), I'd love to continue shell skill show-offs, but for
the purpose of updating this script, I would say a temporary
file is much better than any of the alternatives around 1>&3.
For one thing, it would make debugging the script while
developing and tweaking it, _and_ while using it, much more
pleasant.
^ permalink raw reply
* [PATCH 1/3] Introduce diff_filespec_is_binary()
From: Junio C Hamano @ 2007-07-06 8:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0707051223520.9789@racer.site>
This replaces an explicit initialization of filespec->is_binary
field used for rename/break followed by direct access to that
field with a wrapper function that lazily iniaitlizes and
accesses the field. We would add more attribute accesses for
the use of diff routines, and it would be better to make this
abstraction earlier.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It is quite cute to hide this in the funcname patch...
So this is the proper refactoring _before_ any of your topics.
diff.c | 71 +++++++++++++++++++++++++++--------------------------
diffcore-delta.c | 2 +-
diffcore.h | 2 +
3 files changed, 39 insertions(+), 36 deletions(-)
diff --git a/diff.c b/diff.c
index 1958970..16ea710 100644
--- a/diff.c
+++ b/diff.c
@@ -1102,30 +1102,45 @@ static void setup_diff_attr_check(struct git_attr_check *check)
{
static struct git_attr *attr_diff;
- if (!attr_diff)
+ if (!attr_diff) {
attr_diff = git_attr("diff", 4);
- check->attr = attr_diff;
+ }
+ check[0].attr = attr_diff;
}
-static int file_is_binary(struct diff_filespec *one)
+static void diff_filespec_check_attr(struct diff_filespec *one)
{
- struct git_attr_check attr_diff_check;
+ struct git_attr_check attr_diff_check[1];
- setup_diff_attr_check(&attr_diff_check);
- if (!git_checkattr(one->path, 1, &attr_diff_check)) {
- const char *value = attr_diff_check.value;
+ if (one->checked_attr)
+ return;
+
+ setup_diff_attr_check(attr_diff_check);
+ one->is_binary = 0;
+
+ if (!git_checkattr(one->path, ARRAY_SIZE(attr_diff_check), attr_diff_check)) {
+ const char *value;
+
+ /* binaryness */
+ value = attr_diff_check[0].value;
if (ATTR_TRUE(value))
- return 0;
+ ;
else if (ATTR_FALSE(value))
- return 1;
+ one->is_binary = 1;
}
- if (!one->data) {
- if (!DIFF_FILE_VALID(one))
- return 0;
+ if (!one->data && DIFF_FILE_VALID(one))
diff_populate_filespec(one, 0);
- }
- return buffer_is_binary(one->data, one->size);
+
+ if (one->data)
+ one->is_binary = buffer_is_binary(one->data, one->size);
+
+}
+
+int diff_filespec_is_binary(struct diff_filespec *one)
+{
+ diff_filespec_check_attr(one);
+ return one->is_binary;
}
static void builtin_diff(const char *name_a,
@@ -1182,7 +1197,8 @@ static void builtin_diff(const char *name_a,
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
die("unable to read files to diff");
- if (!o->text && (file_is_binary(one) || file_is_binary(two))) {
+ if (!o->text &&
+ (diff_filespec_is_binary(one) || diff_filespec_is_binary(two))) {
/* Quite common confusing case */
if (mf1.size == mf2.size &&
!memcmp(mf1.ptr, mf2.ptr, mf1.size))
@@ -1260,7 +1276,7 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
die("unable to read files to diff");
- if (file_is_binary(one) || file_is_binary(two)) {
+ if (diff_filespec_is_binary(one) || diff_filespec_is_binary(two)) {
data->is_binary = 1;
data->added = mf2.size;
data->deleted = mf1.size;
@@ -1302,7 +1318,7 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
die("unable to read files to diff");
- if (file_is_binary(two))
+ if (diff_filespec_is_binary(two))
goto free_and_return;
else {
/* Crazy xdl interfaces.. */
@@ -1880,8 +1896,8 @@ static void run_diff(struct diff_filepair *p, struct diff_options *o)
if (o->binary) {
mmfile_t mf;
- if ((!fill_mmfile(&mf, one) && file_is_binary(one)) ||
- (!fill_mmfile(&mf, two) && file_is_binary(two)))
+ if ((!fill_mmfile(&mf, one) && diff_filespec_is_binary(one)) ||
+ (!fill_mmfile(&mf, two) && diff_filespec_is_binary(two)))
abbrev = 40;
}
len += snprintf(msg + len, sizeof(msg) - len,
@@ -2783,7 +2799,7 @@ static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
return error("unable to read files to diff");
/* Maybe hash p->two? into the patch id? */
- if (file_is_binary(p->two))
+ if (diff_filespec_is_binary(p->two))
continue;
len1 = remove_space(p->one->path, strlen(p->one->path));
@@ -3011,21 +3027,6 @@ void diffcore_std(struct diff_options *options)
if (options->quiet)
return;
- /*
- * break/rename count similarity differently depending on
- * the binary-ness.
- */
- if ((options->break_opt != -1) || (options->detect_rename)) {
- struct diff_queue_struct *q = &diff_queued_diff;
- int i;
-
- for (i = 0; i < q->nr; i++) {
- struct diff_filepair *p = q->queue[i];
- p->one->is_binary = file_is_binary(p->one);
- p->two->is_binary = file_is_binary(p->two);
- }
- }
-
if (options->break_opt != -1)
diffcore_break(options->break_opt);
if (options->detect_rename)
diff --git a/diffcore-delta.c b/diffcore-delta.c
index a038b16..d9729e5 100644
--- a/diffcore-delta.c
+++ b/diffcore-delta.c
@@ -129,7 +129,7 @@ static struct spanhash_top *hash_chars(struct diff_filespec *one)
struct spanhash_top *hash;
unsigned char *buf = one->data;
unsigned int sz = one->size;
- int is_text = !one->is_binary;
+ int is_text = !diff_filespec_is_binary(one);
i = INITIAL_HASH_SIZE;
hash = xmalloc(sizeof(*hash) + sizeof(struct spanhash) * (1<<i));
diff --git a/diffcore.h b/diffcore.h
index 0c8abb5..dcab7e2 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -37,6 +37,7 @@ struct diff_filespec {
#define DIFF_FILE_VALID(spec) (((spec)->mode) != 0)
unsigned should_free : 1; /* data should be free()'ed */
unsigned should_munmap : 1; /* data should be munmap()'ed */
+ unsigned checked_attr : 1;
unsigned is_binary : 1; /* data should be considered "binary" */
};
@@ -46,6 +47,7 @@ extern void fill_filespec(struct diff_filespec *, const unsigned char *,
extern int diff_populate_filespec(struct diff_filespec *, int);
extern void diff_free_filespec_data(struct diff_filespec *);
+extern int diff_filespec_is_binary(struct diff_filespec *);
struct diff_filepair {
struct diff_filespec *one;
--
1.5.3.rc0.822.g38609
^ permalink raw reply related
* [PATCH] Per-path attribute based hunk header selection.
From: Junio C Hamano @ 2007-07-06 8:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0707051223520.9789@racer.site>
This makes"diff -p" hunk headers customizable via gitattributes mechanism.
It is based on Johannes's earlier patch that allowed to define a single
regexp to be used for everything.
The mechanism to arrive at the regexp that is used to define hunk header
is the same as other use of gitattributes. You assign an attribute, funcname
(because "diff -p" typically uses the name of the function the patch is about
as the hunk header), a simple string value. This can be one of the names of
built-in pattern (currently, "java" is defined) or a custom pattern name, to
be looked up from the configuration file.
(in .gitattributes)
*.java funcname=java
*.perl funcname=perl
(in .git/config)
[funcname]
java = ... # ugly and complicated regexp to override the built-in one.
perl = ... # another ugly and complicated regexp to define a new one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
This three patch series is lacking 2/3, as it is exactly the
same as the earlier "1/2 Future-proof source for changes in
xdemitconf_t" patch.
diff.c | 96 +++++++++++++++++++++++++++++++++++++++++++++-
diffcore.h | 1 +
t/t4018-diff-funcname.sh | 60 ++++++++++++++++++++++++++++
xdiff-interface.c | 71 ++++++++++++++++++++++++++++++++++
xdiff-interface.h | 2 +
xdiff/xdiff.h | 4 ++
xdiff/xemit.c | 37 +++++++++++-------
7 files changed, 256 insertions(+), 15 deletions(-)
create mode 100644 t/t4018-diff-funcname.sh
diff --git a/diff.c b/diff.c
index d10e848..04e7e91 100644
--- a/diff.c
+++ b/diff.c
@@ -1101,22 +1101,26 @@ static void emit_binary_diff(mmfile_t *one, mmfile_t *two)
static void setup_diff_attr_check(struct git_attr_check *check)
{
static struct git_attr *attr_diff;
+ static struct git_attr *attr_diff_func_name;
if (!attr_diff) {
attr_diff = git_attr("diff", 4);
+ attr_diff_func_name = git_attr("funcname", 8);
}
check[0].attr = attr_diff;
+ check[1].attr = attr_diff_func_name;
}
static void diff_filespec_check_attr(struct diff_filespec *one)
{
- struct git_attr_check attr_diff_check[1];
+ struct git_attr_check attr_diff_check[2];
if (one->checked_attr)
return;
setup_diff_attr_check(attr_diff_check);
one->is_binary = 0;
+ one->hunk_header_ident = NULL;
if (!git_checkattr(one->path, ARRAY_SIZE(attr_diff_check), attr_diff_check)) {
const char *value;
@@ -1127,6 +1131,13 @@ static void diff_filespec_check_attr(struct diff_filespec *one)
;
else if (ATTR_FALSE(value))
one->is_binary = 1;
+
+ /* hunk header ident */
+ value = attr_diff_check[1].value;
+ if (ATTR_TRUE(value) || ATTR_FALSE(value) || ATTR_UNSET(value))
+ ;
+ else
+ one->hunk_header_ident = value;
}
if (!one->data && DIFF_FILE_VALID(one))
@@ -1143,6 +1154,82 @@ int diff_filespec_is_binary(struct diff_filespec *one)
return one->is_binary;
}
+static struct hunk_header_regexp {
+ char *name;
+ char *regexp;
+ struct hunk_header_regexp *next;
+} *hunk_header_regexp_list, **hunk_header_regexp_tail;
+
+static int hunk_header_config(const char *var, const char *value)
+{
+ static const char funcname[] = "funcname.";
+ struct hunk_header_regexp *hh;
+
+ if (prefixcmp(var, funcname))
+ return 0;
+ var += strlen(funcname);
+ for (hh = hunk_header_regexp_list; hh; hh = hh->next)
+ if (!strcmp(var, hh->name)) {
+ free(hh->regexp);
+ hh->regexp = xstrdup(value);
+ return 0;
+ }
+ hh = xcalloc(1, sizeof(*hh));
+ hh->name = xstrdup(var);
+ hh->regexp = xstrdup(value);
+ hh->next = NULL;
+ *hunk_header_regexp_tail = hh;
+ return 0;
+}
+
+static const char *hunk_header_regexp(const char *ident)
+{
+ struct hunk_header_regexp *hh;
+
+ if (!hunk_header_regexp_tail) {
+ hunk_header_regexp_tail = &hunk_header_regexp_list;
+ git_config(hunk_header_config);
+ }
+ for (hh = hunk_header_regexp_list; hh; hh = hh->next)
+ if (!strcmp(ident, hh->name))
+ return hh->regexp;
+ return NULL;
+}
+
+static const char *diff_hunk_header_regexp(struct diff_filespec *one)
+{
+ const char *ident, *regexp;
+
+ diff_filespec_check_attr(one);
+ ident = one->hunk_header_ident;
+
+ if (!ident)
+ /*
+ * If the config file has "funcname.default" defined, that
+ * regexp is used; otherwise NULL is returned and xemit uses
+ * the built-in default.
+ */
+ return hunk_header_regexp("default");
+
+ /* Look up custom "funcname.$ident" regexp from config. */
+ regexp = hunk_header_regexp(ident);
+ if (regexp)
+ return regexp;
+
+ /*
+ * And define built-in fallback patterns here. Note that
+ * these can be overriden by the user's config settings.
+ */
+ if (!strcmp(ident, "java"))
+ return "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
+ "new\\|return\\|switch\\|throw\\|while\\)\n"
+ "^[ ]*\\(\\([ ]*"
+ "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
+ "[ ]*([^;]*$\\)";
+
+ return NULL;
+}
+
static void builtin_diff(const char *name_a,
const char *name_b,
struct diff_filespec *one,
@@ -1217,6 +1304,11 @@ static void builtin_diff(const char *name_a,
xdemitconf_t xecfg;
xdemitcb_t ecb;
struct emit_callback ecbdata;
+ const char *hunk_header_regexp;
+
+ hunk_header_regexp = diff_hunk_header_regexp(one);
+ if (!hunk_header_regexp)
+ hunk_header_regexp = diff_hunk_header_regexp(two);
memset(&xecfg, 0, sizeof(xecfg));
memset(&ecbdata, 0, sizeof(ecbdata));
@@ -1226,6 +1318,8 @@ static void builtin_diff(const char *name_a,
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
xecfg.ctxlen = o->context;
xecfg.flags = XDL_EMIT_FUNCNAMES;
+ if (hunk_header_regexp)
+ xdiff_set_find_func(&xecfg, hunk_header_regexp);
if (!diffopts)
;
else if (!prefixcmp(diffopts, "--unified="))
diff --git a/diffcore.h b/diffcore.h
index dcab7e2..0598514 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -27,6 +27,7 @@ struct diff_filespec {
char *path;
void *data;
void *cnt_data;
+ const void *hunk_header_ident;
unsigned long size;
int xfrm_flags; /* for use by the xfrm */
unsigned short mode; /* file mode */
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
new file mode 100644
index 0000000..dc7a47b
--- /dev/null
+++ b/t/t4018-diff-funcname.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='Test custom diff function name patterns'
+
+. ./test-lib.sh
+
+LF='
+'
+
+cat > Beer.java << EOF
+public class Beer
+{
+ int special;
+ public static void main(String args[])
+ {
+ String s=" ";
+ for(int x = 99; x > 0; x--)
+ {
+ System.out.print(x + " bottles of beer on the wall "
+ + x + " bottles of beer\n"
+ + "Take one down, pass it around, " + (x - 1)
+ + " bottles of beer on the wall.\n");
+ }
+ System.out.print("Go to the store, buy some more,\n"
+ + "99 bottles of beer on the wall.\n");
+ }
+}
+EOF
+
+sed 's/beer\\/beer,\\/' < Beer.java > Beer-correct.java
+
+test_expect_success 'default behaviour' '
+ git diff Beer.java Beer-correct.java |
+ grep "^@@.*@@ public class Beer"
+'
+
+test_expect_success 'preset java pattern' '
+ echo "*.java funcname=java" >.gitattributes &&
+ git diff Beer.java Beer-correct.java |
+ grep "^@@.*@@ public static void main("
+'
+
+git config funcname.java '!static
+!String
+[^ ].*s.*'
+
+test_expect_success 'custom pattern' '
+ git diff Beer.java Beer-correct.java |
+ grep "^@@.*@@ int special;$"
+'
+
+test_expect_success 'last regexp must not be negated' '
+ git config diff.functionnameregexp "!static" &&
+ ! git diff Beer.java Beer-correct.java
+'
+
+test_done
diff --git a/xdiff-interface.c b/xdiff-interface.c
index e407cf1..be866d1 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -129,3 +129,74 @@ int buffer_is_binary(const char *ptr, unsigned long size)
size = FIRST_FEW_BYTES;
return !!memchr(ptr, 0, size);
}
+
+struct ff_regs {
+ int nr;
+ struct ff_reg {
+ regex_t re;
+ int negate;
+ } *array;
+};
+
+static long ff_regexp(const char *line, long len,
+ char *buffer, long buffer_size, void *priv)
+{
+ char *line_buffer = xstrndup(line, len); /* make NUL terminated */
+ struct ff_regs *regs = priv;
+ regmatch_t pmatch[2];
+ int result = 0, i;
+
+ for (i = 0; i < regs->nr; i++) {
+ struct ff_reg *reg = regs->array + i;
+ if (reg->negate ^ !!regexec(®->re,
+ line_buffer, 2, pmatch, 0)) {
+ free(line_buffer);
+ return -1;
+ }
+ }
+ i = pmatch[1].rm_so >= 0 ? 1 : 0;
+ line += pmatch[i].rm_so;
+ result = pmatch[i].rm_eo - pmatch[i].rm_so;
+ if (result > buffer_size)
+ result = buffer_size;
+ else
+ while (result > 0 && (isspace(line[result - 1]) ||
+ line[result - 1] == '\n'))
+ result--;
+ memcpy(buffer, line, result);
+ free(line_buffer);
+ return result;
+}
+
+void xdiff_set_find_func(xdemitconf_t *xecfg, const char *value)
+{
+ int i;
+ struct ff_regs *regs;
+
+ xecfg->find_func = ff_regexp;
+ regs = xecfg->find_func_priv = xmalloc(sizeof(struct ff_regs));
+ for (i = 0, regs->nr = 1; value[i]; i++)
+ if (value[i] == '\n')
+ regs->nr++;
+ regs->array = xmalloc(regs->nr * sizeof(struct ff_reg));
+ for (i = 0; i < regs->nr; i++) {
+ struct ff_reg *reg = regs->array + i;
+ const char *ep = strchr(value, '\n'), *expression;
+ char *buffer = NULL;
+
+ reg->negate = (*value == '!');
+ if (reg->negate && i == regs->nr - 1)
+ die("Last expression must not be negated: %s", value);
+ if (*value == '!')
+ value++;
+ if (ep)
+ expression = buffer = xstrndup(value, ep - value);
+ else
+ expression = value;
+ if (regcomp(®->re, expression, 0))
+ die("Invalid regexp to look for hunk header: %s", expression);
+ if (buffer)
+ free(buffer);
+ value = ep + 1;
+ }
+}
diff --git a/xdiff-interface.h b/xdiff-interface.h
index 536f4e4..fb742db 100644
--- a/xdiff-interface.h
+++ b/xdiff-interface.h
@@ -20,4 +20,6 @@ int parse_hunk_header(char *line, int len,
int read_mmfile(mmfile_t *ptr, const char *filename);
int buffer_is_binary(const char *ptr, unsigned long size);
+extern void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line);
+
#endif
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 9402bb0..c00ddaa 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -73,9 +73,13 @@ typedef struct s_xdemitcb {
int (*outf)(void *, mmbuffer_t *, int);
} xdemitcb_t;
+typedef long (*find_func_t)(const char *line, long line_len, char *buffer, long buffer_size, void *priv);
+
typedef struct s_xdemitconf {
long ctxlen;
unsigned long flags;
+ find_func_t find_func;
+ void *find_func_priv;
} xdemitconf_t;
typedef struct s_bdiffparam {
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 4b6e639..d3d9c84 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -69,7 +69,24 @@ static xdchange_t *xdl_get_hunk(xdchange_t *xscr, xdemitconf_t const *xecfg) {
}
-static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
+static long def_ff(const char *rec, long len, char *buf, long sz, void *priv)
+{
+ if (len > 0 &&
+ (isalpha((unsigned char)*rec) || /* identifier? */
+ *rec == '_' || /* also identifier? */
+ *rec == '$')) { /* identifiers from VMS and other esoterico */
+ if (len > sz)
+ len = sz;
+ while (0 < len && isspace((unsigned char)rec[len - 1]))
+ len--;
+ memcpy(buf, rec, len);
+ return len;
+ }
+ return -1;
+}
+
+static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll,
+ find_func_t ff, void *ff_priv) {
/*
* Be quite stupid about this for now. Find a line in the old file
@@ -80,22 +97,12 @@ static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
const char *rec;
long len;
- *ll = 0;
while (i-- > 0) {
len = xdl_get_rec(xf, i, &rec);
- if (len > 0 &&
- (isalpha((unsigned char)*rec) || /* identifier? */
- *rec == '_' || /* also identifier? */
- *rec == '$')) { /* mysterious GNU diff's invention */
- if (len > sz)
- len = sz;
- while (0 < len && isspace((unsigned char)rec[len - 1]))
- len--;
- memcpy(buf, rec, len);
- *ll = len;
+ if ((*ll = ff(rec, len, buf, sz, ff_priv)) >= 0)
return;
- }
}
+ *ll = 0;
}
@@ -120,6 +127,7 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdchange_t *xch, *xche;
char funcbuf[80];
long funclen = 0;
+ find_func_t ff = xecfg->find_func ? xecfg->find_func : def_ff;
if (xecfg->flags & XDL_EMIT_COMMON)
return xdl_emit_common(xe, xscr, ecb, xecfg);
@@ -143,7 +151,8 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
xdl_find_func(&xe->xdf1, s1, funcbuf,
- sizeof(funcbuf), &funclen);
+ sizeof(funcbuf), &funclen,
+ ff, xecfg->find_func_priv);
}
if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2,
funcbuf, funclen, ecb) < 0)
--
1.5.3.rc0.822.g38609
^ 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