* Re: Git and tagging hook
From: Jakub Narebski @ 2008-10-07 17:28 UTC (permalink / raw)
To: git; +Cc: scmbug-users
In-Reply-To: <1223399613.20250.1.camel@localhost>
Kristis Makris wrote:
> But the post-receive is NOT executed when I apply a tag.
>
> I want the integration when I apply the tag to a local repository, NOT
> only when I push/pull.
If you are talking about taging locally, you can simply make an alias
or do something after tagging. Search archives for description when
it is worth to add a hook, and when it is not.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git and tagging hook
From: Kristis Makris @ 2008-10-07 17:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, scmbug-users
In-Reply-To: <48E9BB72.2080008@op5.se>
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
But the post-receive is NOT executed when I apply a tag.
I want the integration when I apply the tag to a local repository, NOT
only when I push/pull.
On Mon, 2008-10-06 at 09:17 +0200, Andreas Ericsson wrote:
> Kristis Makris wrote:
> > Hello,
> >
> > It seems that Git (at least v1.5.6) does not offer hooks on tag creation
> > (a pre-tag and a post-tag hook). I need such a hook for integrating tag
> > activities with an issue-tracker. Is it possible to add this hook ?
> >
>
> What you want is probably the post-receive or 'update' hooks on whatever
> repository you consider your public watering hole for your project.
> Integrating with an issue-tracker from the developers machine would be
> utterly stupid, as it would prevent tagging from happening while not
> connected.
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [QGIT PATCH] Add safeguards to Git::userInfo()
From: Abdelrazak Younes @ 2008-10-07 17:12 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070950j66bbb980vc26bd50a5615d44@mail.gmail.com>
On 07/10/2008 18:50, Marco Costalba wrote:
> On Tue, Oct 7, 2008 at 3:10 PM, Abdelrazak Younes<younes@lyx.org> wrote:
>
>> OK, with this patch, I see that the local config request is apparently
>> successful even though the 'user' and 'email' strings stay empty.
>>
>
> An empty user and email it does not mean failure.
Yes, I know that but what is troublesome is that the user and email are
not empty when git config is called outside of qgit.
What is even more troublesome is that the two calls to 'git config
--global user.xxx' fail (but don't fail when called manually at the
command line).
Abdel.
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Abdelrazak Younes @ 2008-10-07 17:08 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070948p6a9b2fdcq51f2b1580cef2f4e@mail.gmail.com>
On 07/10/2008 18:48, Marco Costalba wrote:
> On Tue, Oct 7, 2008 at 2:31 PM, Abdelrazak Younes<younes@lyx.org> wrote:
>
>> No, 'git config user.name' works fine in any directory, even on the naked
>> Windows console (I mean without msys bash). So that must be something else.
>> I've traced it down to
>> MyProcess::on_finished().
>>
>> isErrorExit = (exitStatus != QProcess::NormalExit)
>> || (exitCode != 0&& isWinShell)
>> || !errorDesc.isEmpty()
>> || canceling;
>>
>> At this point we have:
>> exitStatus = NormalExit
>> exitCode = 1
>> isWinShell = false
>> errorDesc.isEmpty() returns true
>> canceling = false
>>
>> Which gives 'isErrorExit = false'. I wonder if the isWinShell test is
>> correct?
>>
>>
>
> Hi Abdel,
>
> I would think it is correct to return isErrorExit == false
>
OK.
> The problem is that it seems git config return empty data if run from
> outside git directory...isn't it ?
>
No, as I said, 'git config user.name' is working just fine outside git
directory.
Abdel.
^ permalink raw reply
* Re: [QGIT PATCH] Add safeguards to Git::userInfo()
From: Marco Costalba @ 2008-10-07 16:55 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070950j66bbb980vc26bd50a5615d44@mail.gmail.com>
On Tue, Oct 7, 2008 at 6:50 PM, Marco Costalba <mcostalba@gmail.com> wrote:
>
> An empty user and email it does not mean failure. Again, I would think
> that is git config that returns no data (without failing) if it is run
> from outside git directory.
>
Yes ! it is like this, I have finally had the possibility to test.
git config does not returns user and mail if run outside git dir
because user and mail are local set.
^ permalink raw reply
* Re: [QGIT PATCH] Add safeguards to Git::userInfo()
From: Marco Costalba @ 2008-10-07 16:50 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48EB5FAF.4080303@lyx.org>
On Tue, Oct 7, 2008 at 3:10 PM, Abdelrazak Younes <younes@lyx.org> wrote:
>
> OK, with this patch, I see that the local config request is apparently
> successful even though the 'user' and 'email' strings stay empty.
An empty user and email it does not mean failure. Again, I would think
that is git config that returns no data (without failing) if it is run
from outside git directory.
^ permalink raw reply
* Re: Repairing fatal: ref HEAD is not a symbolic ref (git checkout of svn remote)
From: Jeff Kowalczyk @ 2008-10-07 16:49 UTC (permalink / raw)
To: git
In-Reply-To: <20081006140243.GB8203@spearce.org>
On Mon, 06 Oct 2008 07:02:43 -0700, Shawn O. Pearce wrote:
> Jeff Kowalczyk <jtk@yahoo.com> wrote:
>> To test a particular upstream revision, on a git svn remote checkout (i.e.
>> branches/1.2, 76c7af2...), I checked out the equivalent of HEAD^^ (git
>> checkout 4a3d99c0c9).
>>
>> Now back at the branch tip, I get fatal: ref HEAD is not a symbolic ref
>> on git svn rebase:
>>
>> (4a3d99c...) $ git checkout 76c7af2
>> HEAD is now at 76c7af2... Minor changes to CONTRIBUTORS
>> (76c7af2...) $ git svn rebase
>> fatal: ref HEAD is not a symbolic ref Current branch HEAD is up to date.
>> Segmentation fault
>>
>> How can I manually correct ref HEAD?
>
> git checkout whateverbranchyouwereonbefore
> git svn rebase
Thanks, and the other svn remotes are working fine. I still have the
problem on the svn remote 'branches/1.2'. The following illustrates:
(1.2_mybranch) $ git checkout 1.2
Note: moving to "1.2" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 76c7af2... Minor changes to CONTRIBUTORS
(76c7af2...) $ git svn fetch
M CONTRIBUTORS
M LedgerSMB/AM.pm
r2353 = ddd452af128f9b4698a1c1d6cc7fe2f23a0e6c90 (1.2)
M LedgerSMB/AM.pm
r2354 = fc6857004eeabf6963a9b2856f51db8842c00b70 (1.2)
Segmentation fault
(fc68570...) $ git checkout 1.2_print_pdf_default
Previous HEAD position was fc68570... (commit message snip)
Switched to branch "1.2_print_pdf_default"
(1.2_print_pdf_default) $ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: naive replacement to option selected value="pdf" where PDF is format option,
Segmentation fault
(76c7af2...) $ git svn rebase
fatal: ref HEAD is not a symbolic ref
First, rewinding head to replay your work on top of it...
Fast-forwarded HEAD to refs/remotes/1.2.
Segmentation fault
This last git svn rebase on 'branches/1.2' (whether it's correct procedure
or not for a svn remote) used to work without the error until I issued
that one command (git checkout 4a3d99c0c9).
Thanks for any suggestions.
^ permalink raw reply
* Re: [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Marco Costalba @ 2008-10-07 16:48 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48EB56BA.5020502@lyx.org>
On Tue, Oct 7, 2008 at 2:31 PM, Abdelrazak Younes <younes@lyx.org> wrote:
>
> No, 'git config user.name' works fine in any directory, even on the naked
> Windows console (I mean without msys bash). So that must be something else.
> I've traced it down to
> MyProcess::on_finished().
>
> isErrorExit = (exitStatus != QProcess::NormalExit)
> || (exitCode != 0 && isWinShell)
> || !errorDesc.isEmpty()
> || canceling;
>
> At this point we have:
> exitStatus = NormalExit
> exitCode = 1
> isWinShell = false
> errorDesc.isEmpty() returns true
> canceling = false
>
> Which gives 'isErrorExit = false'. I wonder if the isWinShell test is
> correct?
>
Hi Abdel,
I would think it is correct to return isErrorExit == false
The problem is that it seems git config return empty data if run from
outside git directory...isn't it ?
Marco
^ permalink raw reply
* Re: [PATCH 0/4] diff text conversion filter
From: Johannes Sixt @ 2008-10-07 16:15 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20081007154646.GB26531@coredump.intra.peff.net>
Jeff King schrieb:
> On Tue, Oct 07, 2008 at 08:15:45AM +0200, Matthieu Moy wrote:
>
>> One proposal: have a diff.<driver>.activate with several values:
>>
>> * "always": activate the diff driver in any porcelain
>> * "diff": activate it only for "git diff", as currently
>> * "singlefile": Johannes's heuristic proposal
>>
>> That way, one could say easily "activate exiftags filter all the time,
>> but MS-Word only when I request a diff for a single file", and this
>> leaves room for other values if the need be. Well, there's no room for
>> "use MS-Word native diff tool in git-gui but antiword/catdoc +
>> textconv in 'git log -p'" here, but do we want it?
>>
>> Or is all that just overkill?
>
> Actually, as soon as I read the first part of your mail I thought of the
> "ms-word vs antiword" situation. The example you gave seems plausible.
> And it seems to me that it is really a superset of the problem we are
> discussing. That is, gitattributes is really just saying "this is a
> 'foo' type file". And if we have a mechanism flexible enough to say "in
> this situation, this is how you handle 'foo' type files", then that
> would work as the basis for implementing these heuristics.
>
> For example, maybe you could set up some mapping like:
>
> git diff --diffdriver=foo,bar
>
> where a file with gitattribute diff=x would look for the driver config
> for x.foo, then x.bar, and then finally fall back to just x. Then you
> could easily have (ignoring the fact that I'm not sure about the config
> syntax for having _3_ section parts):
>
> git config diff.doc.graphical.command ms-word-diff-script
> git config diff.doc.textconv antiword
>
> and then git-gui would be configured to diff with:
>
> git diff --diffdriver=graphical
>
> whereas a regular "git diff" would always fall back to
> "diff.doc.textconv". Make sense?
I think you are complicating things. We already have
diff.doc.command ms-word-diff-script
and with your 4-patch-series-under-discussion we would have
diff.doc.texconv antiword
and that should be sufficient. I'm proposing this heuristics:
* If only textconv is given, all porcelains pick it.
* If only command is given, all porcelains pick it.
* If both are given, then
- git log picks textconv.
- git show and git diff:
. if exactly one pathspec was given, pick command;
. otherwise pick textconv
Plumbing never picks any of them, just like today, nor should git
format-patch. The are other porcelains that could be sorted into this
list, like git blame and (the summary line of) git commit.
BTW, please don't take git-gui as an example that would lauch MS-Word on
each diff. (Neither would gitk.) Both rely on plumbing, and that's good.
gitk has a menu entry "External diff", where the diff.doc.command could be
hooked into.
-- Hannes
^ permalink raw reply
* [PATCH] git rm: refresh index before up-to-date check
From: Johannes Schindelin @ 2008-10-07 16:08 UTC (permalink / raw)
To: git, spearce
Since "git rm" is supposed to be porcelain, we should convince it to
be user friendly by refreshing the index itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-rm.c | 1 +
t/t3600-rm.sh | 25 +++++++++++++++++--------
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/builtin-rm.c b/builtin-rm.c
index 50ae6d5..e06640c 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -137,6 +137,7 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
if (read_cache() < 0)
die("index file corrupt");
+ refresh_cache(REFRESH_QUIET);
pathspec = get_pathspec(prefix, argv);
seen = NULL;
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index 558c80e..66aca99 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -219,14 +219,23 @@ test_expect_success 'Remove nonexistent file returns nonzero exit status' '
test_expect_success 'Call "rm" from outside the work tree' '
mkdir repo &&
- cd repo &&
- git init &&
- echo something > somefile &&
- git add somefile &&
- git commit -m "add a file" &&
- (cd .. &&
- git --git-dir=repo/.git --work-tree=repo rm somefile) &&
- test_must_fail git ls-files --error-unmatch somefile
+ (cd repo &&
+ git init &&
+ echo something > somefile &&
+ git add somefile &&
+ git commit -m "add a file" &&
+ (cd .. &&
+ git --git-dir=repo/.git --work-tree=repo rm somefile) &&
+ test_must_fail git ls-files --error-unmatch somefile)
+'
+
+test_expect_success 'refresh index before checking if it is up-to-date' '
+
+ git reset --hard &&
+ test-chmtime -86400 frotz/nitfol &&
+ git rm frotz/nitfol &&
+ test ! -f frotz/nitfol
+
'
test_done
--
1.6.0.2.713.g3dcb0
^ permalink raw reply related
* Re: files missing after converting a cvs repository to git
From: Adam Mercer @ 2008-10-07 15:58 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jakub Narebski, git
In-Reply-To: <48EB3E06.70100@alum.mit.edu>
On Tue, Oct 7, 2008 at 05:46, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Jakub Narebski wrote:
>>> cvs2svn is apparently quite good at getting even the weirdest history
>>> right. Perhaps you can try that and then running "git svn" on the
>>> resulting svn repo?
>>
>> cvs2svn has git output now (I think it is actually fast-import output)
>
> Correct. See http://cvs2svn.tigris.org/cvs2git.html for more info. I
> suggest using the trunk version of cvs2svn for conversions to git.
>
> Please note, however, that cvs2svn can only handle one-time conversions
> (i.e., not tracking a live CVS repository incrementally).
Thanks, I'll look into this for creating the final git repos.
Cheers
Adam
^ permalink raw reply
* Re: files missing after converting a cvs repository to git
From: Adam Mercer @ 2008-10-07 15:55 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: GIT
In-Reply-To: <48EAFCEF.8030907@op5.se>
On Tue, Oct 7, 2008 at 01:08, Andreas Ericsson <ae@op5.se> wrote:
> Has the CVS repo been tampered with in the past? If so, it's entirely
> possible that checking out and working with CVS works just fine, but
> getting history into coherent changesets is impossible.
Unfortunately yes. Thats what I thought, and was afraid, was going on.
I've managed to get things working by restoring some of the missing
files ,v files from a backup and regenerating the tracking
repositories. Then I had to remove the files in question from cvs and
readd them, git cvsimport then saw these files.
> cvs2svn is apparently quite good at getting even the weirdest history
> right. Perhaps you can try that and then running "git svn" on the
> resulting svn repo?
Thanks, I'll give cvs2svn a go.
> Good luck. You'll probably need it :-/
Cheers
Adam
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Johannes Sixt @ 2008-10-07 15:54 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20081007153543.GA26531@coredump.intra.peff.net>
Jeff King schrieb:
> On Tue, Oct 07, 2008 at 05:17:08PM +0200, Johannes Sixt wrote:
>
>>> However, there is at least one conflicting situation: there
>>> is no way to say "use the regular rules to determine whether
>>> this file is binary, but if we do diff it textually, use
>>> this funcname pattern." That is, currently setting diff=foo
>>> indicates that the file is definitely text.
>> I don't get your point. Can you provide an example?
>
> Let's say I have a subdirectory of files, some of which are binary. But
> for those that _aren't_ binary, I want to use a particular funcname
> pattern. So I do this:
>
> echo '* diff=foo' >subdir/.gitattributes
> git config diff.foo.funcname some-regex
>
> Under the old behavior, I have just claimed all of the subdir as text.
> But that's not necessarily what I wanted.
No, you claimed that all of the files are of type "foo". If this is not
what you wanted, be more specific.
> In practice, this doesn't happen much, because funcname tends to follow
> the file extension, as does binary-ness. So you get "*.java diff=java",
> and you really would be insane to have binary files named *.java. But I
> think it makes the concept clearer to explain, and the code simpler, if
> the various facets of a diff driver are orthogonal. In particular, I
> think this makes things cleaner for adding new driver properties in the
> future.
I tend to disagree. "Binaryness" is subordinate to the "type" of the file,
which is what the diff attribute basically specifies.
> As to your complaint (which I think is valid)...
>
>> The reason why I'd like to understand the issue is because I like the
>> diff.foo.textconv that you introduce in patch 4/4, but I dislike that I
>> have to set diff.foo.binary to false in order to use the textconv. So, why
>> is this .binary needed?
>
> I think this .binary is something we can and should get rid of; as it
> stands now, you always end up having to set it along with .textconv. I
> have considered two ways:
>
> - because textconv is for converting binary to text for diffing, the
> result should always be text. So whenever we do the conversion, we
> should note that it is no longer binary, and automatically treat the
> result as a text diff. So in this case, we are explicitly saying
> that binaryness is _not_ orthogonal to this property of the diff
> driver.
>
> - textconv should arguably just be "canonicalize" or similar. That is,
> there is no reason you couldn't take something like text XML and
> canonicalize it for a more readable diff. Or even canonicalize a
> binary file to get a smaller or more sensible binary diff, if you
> wanted to.
>
> In that case, I think the right thing is to set it back to "unknown,
> check the file contents" if .binary is not set. So you really are
> saying "this is just a conversion, treat the canonicalized contents
> exactly as you would have treated the actual contents, including
> binary detection magic".
I see your point. But this second item goes too far, in particular,
canonicalizing binary files to some other binary form is certainly not
something that should happen under 'git diff' porcelain. (We already have
clean/smudge filters for this purpose.)
For the purpose of generating diffs at the porcelain level (*not*
generating patches to be applied, aka format-patch), we can safely stay
with the interpretation in the first item above.
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/4] diff text conversion filter
From: Jeff King @ 2008-10-07 15:46 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Sixt, git
In-Reply-To: <vpqprmdlylq.fsf@bauges.imag.fr>
On Tue, Oct 07, 2008 at 08:15:45AM +0200, Matthieu Moy wrote:
> One proposal: have a diff.<driver>.activate with several values:
>
> * "always": activate the diff driver in any porcelain
> * "diff": activate it only for "git diff", as currently
> * "singlefile": Johannes's heuristic proposal
>
> That way, one could say easily "activate exiftags filter all the time,
> but MS-Word only when I request a diff for a single file", and this
> leaves room for other values if the need be. Well, there's no room for
> "use MS-Word native diff tool in git-gui but antiword/catdoc +
> textconv in 'git log -p'" here, but do we want it?
>
> Or is all that just overkill?
Actually, as soon as I read the first part of your mail I thought of the
"ms-word vs antiword" situation. The example you gave seems plausible.
And it seems to me that it is really a superset of the problem we are
discussing. That is, gitattributes is really just saying "this is a
'foo' type file". And if we have a mechanism flexible enough to say "in
this situation, this is how you handle 'foo' type files", then that
would work as the basis for implementing these heuristics.
For example, maybe you could set up some mapping like:
git diff --diffdriver=foo,bar
where a file with gitattribute diff=x would look for the driver config
for x.foo, then x.bar, and then finally fall back to just x. Then you
could easily have (ignoring the fact that I'm not sure about the config
syntax for having _3_ section parts):
git config diff.doc.graphical.command ms-word-diff-script
git config diff.doc.textconv antiword
and then git-gui would be configured to diff with:
git diff --diffdriver=graphical
whereas a regular "git diff" would always fall back to
"diff.doc.textconv". Make sense?
-Peff
^ permalink raw reply
* proper flags for make check ?
From: David Bryson @ 2008-10-07 15:46 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]
After the recent discussion about make check I decided to give it a try
and see what happens.
I installed sparse, took a look at the source and it appears to want
something along the following lines for a intel processor:
-D__LITTLE_ENDIAN__ -D__i386__=1
I then type 'make check' and get about 30 seconds of errors printing out
for kerberos headers.
The errors look a lot like this:
/usr/include/krb5/krb5.h:1166:18: error: got *
/usr/include/krb5/krb5.h:1167:18: error: Expected ; at end of
declaration
/usr/include/krb5/krb5.h:1167:18: error: got *
/usr/include/krb5/krb5.h:1168:20: error: Expected ; at end of
declaration
/usr/include/krb5/krb5.h:1168:20: error: got *
/usr/include/krb5/krb5.h:1169:1: error: Expected ; end of type
declaration
/usr/include/krb5/krb5.h:1169:1: error: got }
/usr/include/krb5/krb5.h:1173:17: error: expected ; at end of
declaration
/usr/include/krb5/krb5.h:1173:17: error: Expected } at end of
struct-union-enum-specifier
What is the proper way to run sparse on the git sources ?
Dave
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Jeff King @ 2008-10-07 15:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthieu Moy, git
In-Reply-To: <48EB7D74.40302@viscovery.net>
On Tue, Oct 07, 2008 at 05:17:08PM +0200, Johannes Sixt wrote:
> > However, there is at least one conflicting situation: there
> > is no way to say "use the regular rules to determine whether
> > this file is binary, but if we do diff it textually, use
> > this funcname pattern." That is, currently setting diff=foo
> > indicates that the file is definitely text.
>
> I don't get your point. Can you provide an example?
Let's say I have a subdirectory of files, some of which are binary. But
for those that _aren't_ binary, I want to use a particular funcname
pattern. So I do this:
echo '* diff=foo' >subdir/.gitattributes
git config diff.foo.funcname some-regex
Under the old behavior, I have just claimed all of the subdir as text.
But that's not necessarily what I wanted.
In practice, this doesn't happen much, because funcname tends to follow
the file extension, as does binary-ness. So you get "*.java diff=java",
and you really would be insane to have binary files named *.java. But I
think it makes the concept clearer to explain, and the code simpler, if
the various facets of a diff driver are orthogonal. In particular, I
think this makes things cleaner for adding new driver properties in the
future.
As to your complaint (which I think is valid)...
> The reason why I'd like to understand the issue is because I like the
> diff.foo.textconv that you introduce in patch 4/4, but I dislike that I
> have to set diff.foo.binary to false in order to use the textconv. So, why
> is this .binary needed?
I think this .binary is something we can and should get rid of; as it
stands now, you always end up having to set it along with .textconv. I
have considered two ways:
- because textconv is for converting binary to text for diffing, the
result should always be text. So whenever we do the conversion, we
should note that it is no longer binary, and automatically treat the
result as a text diff. So in this case, we are explicitly saying
that binaryness is _not_ orthogonal to this property of the diff
driver.
- textconv should arguably just be "canonicalize" or similar. That is,
there is no reason you couldn't take something like text XML and
canonicalize it for a more readable diff. Or even canonicalize a
binary file to get a smaller or more sensible binary diff, if you
wanted to.
In that case, I think the right thing is to set it back to "unknown,
check the file contents" if .binary is not set. So you really are
saying "this is just a conversion, treat the canonicalized contents
exactly as you would have treated the actual contents, including
binary detection magic".
And both of those obviously involve changes to patch 4/4.
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] diff: introduce diff.<driver>.binary
From: Johannes Sixt @ 2008-10-07 15:17 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20081005214336.GC21925@coredump.intra.peff.net>
Jeff King schrieb:
> The "diff" gitattribute is somewhat overloaded right now. It
> can say one of three things:
>
> 1. this file is definitely binary, or definitely not
> (i.e., diff or !diff)
> 2. this file should use an external diff engine (i.e.,
> diff=foo, diff.foo.command = custom-script)
> 3. this file should use particular funcname patterns
> (i.e., diff=foo, diff.foo.(x?)funcname = some-regex)
>
> Most of the time, there is no conflict between these uses,
> since using one implies that the other is irrelevant (e.g.,
> an external diff engine will decide for itself whether the
> file is binary).
>
> However, there is at least one conflicting situation: there
> is no way to say "use the regular rules to determine whether
> this file is binary, but if we do diff it textually, use
> this funcname pattern." That is, currently setting diff=foo
> indicates that the file is definitely text.
I don't get your point. Can you provide an example?
The reason why I'd like to understand the issue is because I like the
diff.foo.textconv that you introduce in patch 4/4, but I dislike that I
have to set diff.foo.binary to false in order to use the textconv. So, why
is this .binary needed?
> This patch introduces a "binary" config option for a diff
> driver, so that one can explicitly set diff.foo.binary. We
> default this value to "don't know". That is, setting a diff
> attribute to "foo" and using "diff.foo.funcname" will have
> no effect on the binaryness of a file. To get the current
> behavior, one can set diff.foo.binary to true.
-- Hannes
^ permalink raw reply
* Re: Different svn-id URLs in history
From: Michael J Gruber @ 2008-10-07 15:01 UTC (permalink / raw)
To: Knut Eldhuset; +Cc: git
In-Reply-To: <48EB40E1.40506@3d-radar.com>
Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
> Hi,
>
> After cloning my svn repository, I notice that the svn-id URL is
> different when going back in history:
>
> git-svn-id: https://server/trunk@300
>
> vs
>
> git-svn-id: https://server/trunk/some_folder/project/src@250
>
> If i checkout the first version, I get a working copy that has the
> folder "some_folder" in it. If I checkout the latter version, I get a
> working copy with the contents of the folder "src". Why is this? I
> thought I always was supposed to get a wc with the whole tree.
>
> Regards,
> Knut Eldhuset
I take this is as an invitation for guesswork (given the amount of
details)...
You probably have commits which don't follow your usual svn repo layout
(trunk/some_folder/project/src) but commit to trunk/ directly. The output of
svn log -v -r300 https://server/trunk@300
svn log -v -r250 https://server/trunk/some_folder/project/src@250
should give some clues.
Michael
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #01; Mon, 06)
From: Shawn O. Pearce @ 2008-10-07 14:50 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081006210303.GA30812@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Mon, Oct 06, 2008 at 09:59:43AM -0700, Shawn O. Pearce wrote:
>
> > * jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
> > - diff: add filter for converting binary to text
> > - diff: introduce diff.<driver>.binary
> > - diff: unify external diff and funcname parsing code
> > - t4012: use test_cmp instead of cmp
> >
> > A general cleanup on how diff drivers are implemented. Its still
> > missing documentation updates and tests but doesn't break anything
> > current as far as I can tell. It needs more review before it can
> > be slated for 'next'.
>
> I should note, too, that this is in direct competition with Matthieu
> Moy's "Implementation of a textconv filter for easy custom diff" posted
> about a week ago. So if you are reviewing this series, please review
> both and decide which you think is more sensible.
To be clear, Jeff's series is in pu because it seems reasonable on
the surface and applied cleanly to my master branch. Matthieu's
branch didn't apply cleanly, and I didn't really have the time to
figure out why and hand fix it.
So my carrying of Jeff's series and not Matthieu's is not an
endorsement one way or the other. It was simply a matter of trying
to help the topic get exposure with the least amount of effort on
my part.
--
Shawn.
^ permalink raw reply
* Re: GitTogether topics status (4th of October)
From: Shawn O. Pearce @ 2008-10-07 14:46 UTC (permalink / raw)
To: Jeff King
Cc: Christian Couder, git, Junio C Hamano, Scott Chacon, Sam Vilain,
Petr Baudis
In-Reply-To: <20081007031509.GA6031@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> I just added two proposed half-hour meetings, both of which I intend to
> be a few minutes of me talking followed by group discussion. The topics
> are:
>
> 1. Helping new developers join the git community
Oh, this is a good idea. Yesterday I myself had trouble with
a new contributor not being familiar with the patching process.
Partly also my fault of still being a green maintainer. ;-)
> 2. What needs refactoring?
>
> I occasionally run up against parts of the code that just make my
> eyes bleed everytime I touch them. I think we've made significant
> progress in maintanability and bug-avoidance with things like the
> strbuf library, refactoring of remote and transport handling, etc.
> What areas might still benefit from such refactoring?
Also a good idea. I imagine Junio may have some interest in this.
I certainly do. Some of the code is just bloodly aweful to work
with. I guess those are the parts that make your eyes bleed.
--
Shawn.
^ permalink raw reply
* Re: Git pager woes
From: Matthieu Moy @ 2008-10-07 14:30 UTC (permalink / raw)
To: J.R. Mauro; +Cc: git
In-Reply-To: <3aaafc130810070643m352ea2ufa1069dc149f0d9e@mail.gmail.com>
"J.R. Mauro" <jrm8005@gmail.com> writes:
> Git doesn't set special options to it's pager command if the LESS
> environment variable is set.
Yes, this is by design: if you customized less, git obeys the
configuration you've set. Otherwise, it takes a default wich is more
appropriate to git that what "less" does without $LESS set.
That policy isn't perfect, but I think any other would be worse: I
wouldn'l like git to change my configuration if I did set $LESS
myself, and I also prefer git's default to LESS default when it comes
to paging git commands (but I like less's default for other uses, for
example, I like the man page to disapear when I close it).
--
Matthieu
^ permalink raw reply
* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Jakub Narebski @ 2008-10-07 14:39 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810070542v4c8a9820x4d91ea20597ddf01@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Tue, Oct 7, 2008 at 12:57 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Fri, 3 Oct 2008, Giuseppe Bilotta wrote:
>>> + # find which part of PATH_INFO is project
>>> + my $project = $path_info;
>>
>> Hmmm... now $project is local (lexically) here.
>
> Yes, itt's only used temporarily here, to see if a proper $project
> can be defined. It gets redefined outside. It just made sense to name
> it like this 8-)
Well, if $project is local in evaluate_path_info(), so could be
$path_info...
>>> + $project =~ s,/+$,,;
>>> + while ($project && !check_head_link("$projectroot/$project")) {
>>> + $project =~ s,/*[^/]*$,,;
>>> + }
>>> + # validate project
>>> + $project = validate_project($project);
>>
>> I'm not sure if it is worth worrying over, but I think you repeat
>> check_head_link() check here.
>>
>> [After examining code further]. But I think you do double validation;
>> once you do it here, and once you do it copying to global variables
>> such as $action or $project, and double checking check_head_link()
>> won't be easy to avoid; fortunately it is cheap filesystem-level check
>> (might be slow only when stat is extremely slow, and is not cached).
>
> I know. This is actually the reason why I had interleaved path_info
> definition and global validation in my previous version of the patch.
> The big issue here is that path_info evaluation _needs_ (partial)
> validation.
>
> A possible alternative could be to only put validated parameters into
> %input_params. This would completely separate the validation for cgi
> and path_info (modulo shared subs).
>
> Of course, the check_head_link would still be repeated inside
> evaluate_path_info, but the other params could skip a double
> validation.
Wouldn't it be simpler and as good solution to just leave validation
off evaluate_path_info() (well, of course except check_head_link() test),
and allow it to be validated when assigning global 'params' variables?
check_head_link() would be repeated for path_info links, but that
should not affect performance much.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: GitTogether topics status (4th of October)
From: Shawn O. Pearce @ 2008-10-07 14:38 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jeff King, Christian Couder, git, Junio C Hamano, Scott Chacon,
Sam Vilain, Petr Baudis
In-Reply-To: <alpine.LFD.2.00.0810062343000.3045@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 6 Oct 2008, Jeff King wrote:
>
> > 2. What needs refactoring?
> >
> > I occasionally run up against parts of the code that just make my
> > eyes bleed everytime I touch them. I think we've made significant
> > progress in maintanability and bug-avoidance with things like the
> > strbuf library, refactoring of remote and transport handling, etc.
> > What areas might still benefit from such refactoring?
>
> Tree object walking and commit object parsing. This is what's holding
> pack v4 performances back. But I think that Shawn will cover this
> already (I won't be there but I sent my thoughts about this to him).
Yup. A huge part of the pack v4 talk is going to be the parsing
code. Maybe 10 minutes of it will give the high level overview
of how pack v4 is organized, to explain why the parsing code is
a problem. :)
--
Shawn.
^ permalink raw reply
* Re: [PATCH RFC] rebase--interactive: if preserving merges, use first-parent to limit what is shown.
From: Shawn O. Pearce @ 2008-10-07 14:38 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Avi Kivity, git
In-Reply-To: <20081007013654.274e5cf6.stephen@exigencecorp.com>
Stephen Haberman <stephen@exigencecorp.com> wrote:
> However, lest I burn my "PATCH v2" opportunity, I'm holding off on
> posting the updated patch. It works and passes tests but I'm sure I'll
> tinker with it some more over the next few days. It will also likely
> conflict with my pu sh/maint-rebase3 patch, so I don't know whether to
> base it on top of that one or not (guessing not).
When a patch series is in `pu` it can be rebased/replaced/amended
at any time. That's why I parked it there. The pu branch rewinds
and is rebuilt on a daily basis. Any commits not yet merged into
maint, master or next are automatically rebased onto the latest
maint or master branch and get merged into that day's pu.
So don't hold back on posting patches. Folks expect to see
patches on this list; talking is less productive than posting code.
Showing code that purports to solve a problem, or that at least
displays a problem concretely is worthy of discussion.
And don't worry about replacing what is currently in pu. Its easily
done by the maintainer. However don't expect daily updates to a
topic in pu. Junio (and I) just don't have the bandwidth to keep
replacing patches every day.
--
Shawn.
^ permalink raw reply
* [PATCH] git-push.txt: Describe --repo option in more detail
From: Johannes Sixt @ 2008-10-07 14:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Junio C Hamano, Daniel Barkalow
From: Johannes Sixt <johannes.sixt@telecom.at>
The --repo option was described in a way that the reader would have to
assume that it is the same as the <repository> parameter. But it actually
servers a purpose, which is now written down.
Furthermore, the --mirror option was missing from the synopsis.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I do not have the toolchain to format the documentation, so please take
this with a grain of salt.
-- Hannes
Documentation/git-push.txt | 24 +++++++++++++++++++-----
builtin-push.c | 2 +-
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 45c9643..6150b1b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,8 +9,8 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
- [--repo=all] [-f | --force] [-v | --verbose]
+'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+ [--repo=<repository>] [-f | --force] [-v | --verbose]
[<repository> <refspec>...]
DESCRIPTION
@@ -101,9 +101,23 @@ nor in any Push line of the corresponding remotes file---see below).
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
---repo=<repo>::
- When no repository is specified the command defaults to
- "origin"; this overrides it.
+--repo=<repository>::
+ This option is only relevant if no <repository> argument is
+ passed in the invocation. In this case, 'git-push' derives the
+ remote name from the current branch: If it tracks a remote
+ branch, then that remote repository is pushed to. Otherwise,
+ the name "origin" is used. For this latter case, this option
+ can be used to override the name "origin". In other words,
+ the difference between these two commands
++
+--------------------------
+git push public #1
+git push --repo=public #2
+--------------------------
++
+is that #1 always pushes to "public" whereas #2 pushes to "public"
+only if the current branch does not track a remote branch. This is
+useful if you write an alias or script around 'git-push'.
--thin::
--no-thin::
diff --git a/builtin-push.c b/builtin-push.c
index cc6666f..122fdcf 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
--
1.6.0.2.651.gd07df
^ 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