* [PATCH] Fix a few typos in relnotes
From: Mikael Magnusson @ 2008-10-07 18:15 UTC (permalink / raw)
To: git, Shawn O. Pearce
---
Documentation/RelNotes-1.6.0.3.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/RelNotes-1.6.0.3.txt b/Documentation/RelNotes-1.6.0.3.txt
index edd5e45..6cf8ae4 100644
--- a/Documentation/RelNotes-1.6.0.3.txt
+++ b/Documentation/RelNotes-1.6.0.3.txt
@@ -53,7 +53,7 @@ Fixes since v1.6.0.2
* Stale temporary files under $GIT_DIR/objects/pack are now cleaned up
automatically by "git prune".
-* "git merge" once agrain removes directories after the last file has
+* "git merge" once again removes directories after the last file has
been removed from it during the merge.
* "git blame -C -C" no longer segfaults while trying to pass blame if
@@ -68,10 +68,10 @@ Fixes since v1.6.0.2
* The "git commit" error message when there are still unmerged
files present was clarified to match "git write-tree".
-* Some segfaults due to uncaught NULL pointers were fixed multiple
+* Some segfaults due to uncaught NULL pointers were fixed in multiple
tools such as apply, reset, update-index.
-* Solaris bulds now default to OLD_ICONV=1 to avoid compile warnings.
+* Solaris builds now default to OLD_ICONV=1 to avoid compile warnings.
* "Git.pm" tests relied on unnecessarily more recent version of Perl.
@@ -80,7 +80,7 @@ Fixes since v1.6.0.2
* "gitweb" triggered undef warnings on missing trees.
* "gitweb" now removes PATH_INFO from its URLs so users don't have
- to manually set the url in the gitweb configuration.
+ to manually set the URL in the gitweb configuration.
* Bash completion removed support for legacy "git-fetch", "git-push"
and "git-pull" as these are no longer installed. Dashless form
--
1.6.0.2.GIT
--
Mikael Magnusson
^ permalink raw reply related
* Re: [QGIT PATCH] Add safeguards to Git::userInfo()
From: Marco Costalba @ 2008-10-07 18:03 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48EB9EB1.7080302@lyx.org>
On Tue, Oct 7, 2008 at 6:38 PM, Abdelrazak Younes <younes@lyx.org> wrote:
>
> So how do you explain this:
>
Form git-config(1) docs:
This command will fail if:
-The config file is invalid,
......
-you use --global option without $HOME being properly set.
So please try to comment out following line
--- a/src/git.cpp
+++ b/src/git.cpp
@@ -345,7 +345,7 @@ void Git::userInfo(SList info) {
info.clear();
info << "Environment" << user << email;
- errorReportingEnabled = false; // 'git config' could fail, see docs
+ //errorReportingEnabled = false; // 'git config' could fail, see docs
run("git config user.name", &user);
run("git config user.email", &email);
run from double click and you probably will see an error message box
where git says $HOME is not set (I can reproduce this now).
So what I think is that when you run from command line there is the
$HOME variable set and command does not fails.
Marco
^ permalink raw reply
* Re: [xfs-masters] git://oss.sgi.com broke
From: Andrew Morton @ 2008-10-07 17:39 UTC (permalink / raw)
To: Russell Cattelan; +Cc: xfs-masters, git
In-Reply-To: <48EA4B22.2050900@thebarn.com>
On Mon, 06 Oct 2008 12:30:10 -0500 Russell Cattelan <cattelan@thebarn.com> wrote:
> Andrew Morton wrote:
> > y:/usr/src/git26> git --version
> > git version 1.5.6.rc0
> >
> > y:/usr/src/git26> cat .git/branches/git-xfs
> > git://oss.sgi.com:8090/xfs/xfs-2.6.git#master
> >
> > y:/usr/src/git26> git-fetch git-xfs
> > remote: usage: git-pack-objects [{ -q | --progress | --all-progress }]
> > remote: [--max-pack-size=N] [--local] [--incremental]
> > remote: [--window=N] [-remote: -window-memory=N] [--depth=N]
> > remote: [--no-reuse-delta] [--no-reuse-object] [--delta-base-offset]
> > remote: [--threads=N] [--non-empty] [--reremote: vs [--unpacked | --all]*] [--reflog]
> > remote: [--stdout | base-name] [--keep-unreachable] [<ref-list | <object-list]
> > remote: aborting due to possible repository corruption on the remote side.
> > fatal: protocol error: bad pack header
> >
> > It was OK yesterday.
> >
> > (cc'ing the git list in case this is an faq?)
> >
> > The last two error messages there look wrong/misleading?
> >
> >
> Ok not sure exactly what was wrong but it looks like there was some
> confusion
> with older git bits still install on oss.
>
> I manually cleaned everything from the system and reinstalled git from a
> fresh "make rpm" rpm.
>
> Please try your pull again and see if the problem is resolved.
>
It seems OK now, thanks.
^ permalink raw reply
* Re: [QGIT PATCH] Add safeguards to Git::userInfo()
From: Abdelrazak Younes @ 2008-10-07 17:38 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550810070955o5ea20e90jf52faf31a0ada013@mail.gmail.com>
On 07/10/2008 18:55, Marco Costalba wrote:
> 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.
So how do you explain this:
C:\>git config --global user.name
Abdelrazak Younes
C:\>git config user.name
Abdelrazak Younes
I get the same result in any directory, git repo or not.
FYI, I never set the name locally, just once and globally.
Abdel.
^ permalink raw reply
* Re: git://oss.sgi.com broke
From: Andrew Morton @ 2008-10-07 17:32 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, xfs-masters, git
In-Reply-To: <alpine.LNX.1.00.0810061353140.19665@iabervon.org>
On Mon, 6 Oct 2008 13:58:02 -0400 (EDT) Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Mon, 6 Oct 2008, Linus Torvalds wrote:
>
> > On Fri, 3 Oct 2008, Andrew Morton wrote:
> > >
> > > y:/usr/src/git26> git --version
> > > git version 1.5.6.rc0
> > >
> > > y:/usr/src/git26> cat .git/branches/git-xfs
> > > git://oss.sgi.com:8090/xfs/xfs-2.6.git#master
> >
> > Hmm. That's the really old and deprecated branch format.
> >
> > I'm getting a "Connection refused" from oss.sgi.com, and I think there's
> > possibly something broken there, but quite independently of that, maybe we
> > can try to teach you another way to set up remote branches?
> >
> > In your .git/config file, use
> >
> > [remote "git-xfs"]
> > url = git://oss.sgi.com:8090/xfs/xfs-2.6.git
> > fetch = master
> >
> > because the whole .git/branches/<branch-name> thing is fairly deprecated,
> > and cannot handle some things that the .git/config file format can (like
> > saying where to fetch into, or how to push back etc).
>
> I think Andrew convinced us to undeprecate that format, because he wants
> to be able to configure each branch with one line in a separate file. In
> any case, remote.c takes care of these things seemlessly.
>
Well I was kinda attached to the old format but my world wouldn't end
if it went away.
Judging from the Next/Trees contents, I suspect that Stephen uses the old
convenient/compact/one-per-file form too.
^ permalink raw reply
* Re: Git and tagging hook
From: Kristis Makris @ 2008-10-07 17:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48E9BC54.5070609@op5.se>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
On Mon, 2008-10-06 at 09:20 +0200, Andreas Ericsson wrote:
> Next time, don't include a members-only list in the CC, please. The
> usual action when replying to an email on git@vger is to "Reply All",
> which doesn't play nicely with such lists and will render one list
> archive incomplete (since people will inevitably cull that other
> list from their CC's after having sent to it once).
Why would they cull that other list, if the usual action is to "Reply
All" ?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* 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
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