* Re: git-svn does not seems to work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-08-06 16:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Alexander Litvinov, git
In-Reply-To: <20080806111545.GD32184@machine.or.cz>
On Wed, Aug 6, 2008 at 3:15 PM, Petr Baudis <pasky@suse.cz> wrote:
>
> If not, why do you want to drop git-svn from Windows Git? It seems
> that the CRLF issue has trivial workaround to set autocrlf=false;
> this will make git-svn-tracked repositories useful only on Windows,
> but I'd bet this is fine for large majority of Windows git-svn users?
Actually, it is not so simple. If you have svn properties setup correctly
for your text files (i.e. svn:eol-style=native) than autocrlf=false is
not what you want, because then SVN uses LF as EOL when stores this files.
In many case, just setting svn:eol-style correctly in SVN may solve the
problem.
However, to make git-svn work reliable in present files with different
ending, it should import files from SVN without applying any filter.
Therefore, the --no-filters option was recently added to git-hash-object.
Adding its use to git-svn should be easy (I have not had time to test it):
===
diff --git a/perl/Git.pm b/perl/Git.pm
index 087d3d0..438b7fd 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -829,7 +829,7 @@ sub _open_hash_and_insert_object_if_needed {
($self->{hash_object_pid}, $self->{hash_object_in},
$self->{hash_object_out}, $self->{hash_object_ctx}) =
- command_bidi_pipe(qw(hash-object -w --stdin-paths));
+ command_bidi_pipe(qw(hash-object -w --stdin-paths
--no-filters));
}
sub _close_hash_and_insert_object {
===
This should solve all problem with git-svn fetch. However, if you want to
respect svn:eol-style and when you commit your changes, that will require
synchronization svn:eol-style with values for crlf in your .gitattributes,
which is a much more ambitious task.
Dmitry
^ permalink raw reply related
* Re: [PATCH] bash: remove redundant check for 'git stash apply' options
From: Shawn O. Pearce @ 2008-08-06 15:47 UTC (permalink / raw)
To: SZEDER GGGbor; +Cc: Lee Marlow, git, Junio C Hamano
In-Reply-To: <1218037523-32266-1-git-send-email-szeder@ira.uka.de>
SZEDER GGGbor <szeder@ira.uka.de> wrote:
> It will never trigger anyway because of the first check, and even if it
> would, it would not offer the command line option.
>
> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Oops. I should have caught that. ACK.
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 447cb06..5d60f82 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1427,7 +1427,7 @@ _git_stash ()
> apply,--*)
> __gitcomp "--index"
> ;;
> - show,--*|apply,--*|drop,--*|pop,--*|branch,--*)
> + show,--*|drop,--*|pop,--*|branch,--*)
> COMPREPLY=()
> ;;
> show,*|apply,*|drop,*|pop,*|branch,*)
--
Shawn.
^ permalink raw reply
* [PATCH] bash: remove redundant check for 'git stash apply' options
From: SZEDER Gábor @ 2008-08-06 15:45 UTC (permalink / raw)
To: Lee Marlow, Shawn O. Pearce; +Cc: git, Junio C Hamano, SZEDER Gábor
In-Reply-To: <1217915438-6838-6-git-send-email-lee.marlow@gmail.com>
It will never trigger anyway because of the first check, and even if it
would, it would not offer the command line option.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 447cb06..5d60f82 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1427,7 +1427,7 @@ _git_stash ()
apply,--*)
__gitcomp "--index"
;;
- show,--*|apply,--*|drop,--*|pop,--*|branch,--*)
+ show,--*|drop,--*|pop,--*|branch,--*)
COMPREPLY=()
;;
show,*|apply,*|drop,*|pop,*|branch,*)
--
1.6.0.rc1.104.gf5b36
^ permalink raw reply related
* Re: [BUG] git diff-tree --stdin doesn't accept two trees
From: Junio C Hamano @ 2008-08-06 15:31 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080806115358.GD18336@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
>> The feature of --stdin to take a commit and its parents on one line was
>> broken before that to support the common
>>
>> rev-list --parents $commits... -- $paths... |
>> diff-tree --stdin -v -p
>>
>> usage pattern by Porcelains. For diff-tree to talk sensibly about
>> commits, it needs to see commits, not just trees.
>
> But is there any fundamental reason why it couldn't accept tree-ishes
> as well?
The -v option given to diff-tree is the key. Without it, it could take
trees.
^ permalink raw reply
* Re: something fishy with Git commit and log from file
From: Junio C Hamano @ 2008-08-06 15:38 UTC (permalink / raw)
To: pascal; +Cc: Luciano Rocha, git list
In-Reply-To: <4899848C.6030800@obry.net>
Pascal Obry <pascal@obry.net> writes:
> So definitely a Git bug! Can be reproduced with:
>
> $ mkdir repo && cd repo
> $ git init
> $ mkdir dir
> $ cd dir
> $ echo file > file
> $ echo log > log
> $ git add file
> $ git commit --file=log
> fatal: could not read log file 'log': No such file or directory
Try it without cding down to "dir".
^ permalink raw reply
* Re: [PATCH] perl/Makefile: handle paths with spaces in the NO_PERL_MAKEMAKER section
From: Junio C Hamano @ 2008-08-06 15:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <klGWkbWGpsUHZpuNwl9WvZs5UGGfYVAngWbiM3eippaejrXLNyLpRA@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Junio C Hamano wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> writes:
>>
>>> Use double quotes to protect against paths which may contain spaces.
>>> ...
>>> + echo ' mkdir -p "$(instdir_SQ)"' >> $@
>>
>> Is this sufficient? We seem to apply double-sq when writing shell
>> scriptlet in GIT-BUILD-OPTIONS from the main Makefile, and I suspect you
>> would need to do something similar.
>
> It seems to be sufficient. The double quotes survived into my perl.mak file
> and the two perl modules were installed correctly when I supplied a prefix
> with spaces. Is there something else to be concerned about?
I think the generic way GIT-BUILD-OPTIONS writing is done covers cases
where the installation directory has funnies other than whitespace, e.g.
double quotes. Is your 'echo "$(instdir_SQ)"' sufficient?
^ permalink raw reply
* Re: git show doesn't respect config: diff.renames=copies
From: Jeff King @ 2008-08-06 15:25 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Stephen R. van den Berg, git
In-Reply-To: <20080806141559.GA25791@atjola.homenet>
On Wed, Aug 06, 2008 at 04:15:59PM +0200, Björn Steinbrink wrote:
> > $ git grep -A3 diff.renames
> > config.txt:diff.renames::
> > config.txt- Tells git to detect renames. If set to any boolean value, it
> > config.txt- will enable basic rename detection. If set to "copies" or
> > config.txt- "copy", it will detect copies, as well.
>
> See subject line ;-)
Heh. Yes, oops. His question makes a lot more sense now. ;)
> Works for me though. Stephen, probably the source file didn't change in
> the same commit. In such a case you need --find-copies-harder, and that
> seems not to be configurable as the default.
I don't think it is configurable. Probably a "copiesharder" option for
diff.renames would be a sane addition.
-Peff
^ permalink raw reply
* Re: git-svn on MSysGit and why is it (going to be?) unsupported
From: Avery Pennarun @ 2008-08-06 15:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Alexander Litvinov, git
In-Reply-To: <20080806135100.GB10151@machine.or.cz>
On 8/6/08, Petr Baudis <pasky@suse.cz> wrote:
> On Wed, Aug 06, 2008 at 02:43:51PM +0200, Johannes Schindelin wrote:
> > And _noone_ of those competent Windows git-svn users seemed fit or willing
> > to do anything about git-svn, not even the simplest of issues.
>
> I can of course understand that argument, even though it's a bit sad to
> see when the issues are apparently either trivial or there is simple
> workaround available. My trouble was that the _concrete_ reasons for
> this are buried deep inside long mail threads (or threads on other
> mailing lists).
>
> > If you want to do something about it, go ahead. But I have no inclination
> > of hearing from any Windows user about git-svn again, ever.
>
> Not currently, I'm just afraid I *might* have to sometime in the future.
> ;-)
FWIW (and related to the subject line in this thread), I think there
are a lot of git users on Windows who just use the cygwin one. That's
what I do, and git-svn works fine (I don't use autocrlf though, which
is probably why it worked). git's support for both platforms, and the
fact that cygwin was first and works already, probably greatly reduces
the number of developers who want to fix msysgit.
Have fun,
Avery
^ permalink raw reply
* Re: git problem: pack has bad object at offset 77100841: inflate returned -3
From: srinivas naga vutukuri @ 2008-08-06 15:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080806143310.GB28231@spearce.org>
Hi,
On Wed, Aug 6, 2008 at 8:03 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> srinivas naga vutukuri <srinivas.vutukuri@gmail.com> wrote:
>> remote: Counting objects: 879862, done.
>> remote: Compressing objects: 100% (156686/156686), done.
>> fatal: pack has bad object at offset 77100841: inflate returned -3
>> fatal: index-pack failed
>>
>> while doing "git clone" of linux kernel of latest 2.6.27-rc2.
>> But am able to do the latest stable successfully.
> ...
>> I am using cygwin, git 1.5.6.4
>
> Where are you cloning from?
>
> This is an indication that the data sent to your system from the
> remote side is corrupt. Possibly a bad network link?
>
> Remote side corruption should have been detected by the remote
> server as it was writing the data out. The message above however
> came from your client, so the server seems to be OK.
>
> --
> Shawn.
>
I am gone to the site: http://www.kernel.org
from this place
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=summary
trying out, for 2.6.27-rc2
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
which is causing the problem,
But, from the place,
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.26.y.git;a=summary
trying for stable.
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.26.y.git
is working fine...
Could any possible clue from this...
best regards,
srinivas.
^ permalink raw reply
* Re: git problem: pack has bad object at offset 77100841: inflate returned -3
From: Shawn O. Pearce @ 2008-08-06 14:33 UTC (permalink / raw)
To: srinivas naga vutukuri; +Cc: git
In-Reply-To: <ace3f33d0808060015t25d9c21epc31e48e3c1d041b1@mail.gmail.com>
srinivas naga vutukuri <srinivas.vutukuri@gmail.com> wrote:
> remote: Counting objects: 879862, done.
> remote: Compressing objects: 100% (156686/156686), done.
> fatal: pack has bad object at offset 77100841: inflate returned -3
> fatal: index-pack failed
>
> while doing "git clone" of linux kernel of latest 2.6.27-rc2.
> But am able to do the latest stable successfully.
...
> I am using cygwin, git 1.5.6.4
Where are you cloning from?
This is an indication that the data sent to your system from the
remote side is corrupt. Possibly a bad network link?
Remote side corruption should have been detected by the remote
server as it was writing the data out. The message above however
came from your client, so the server seems to be OK.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] perl/Makefile: handle paths with spaces in the NO_PERL_MAKEMAKER section
From: Brandon Casey @ 2008-08-06 14:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v8wvbuit7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> Use double quotes to protect against paths which may contain spaces.
>> ...
>> + echo ' mkdir -p "$(instdir_SQ)"' >> $@
>
> Is this sufficient? We seem to apply double-sq when writing shell
> scriptlet in GIT-BUILD-OPTIONS from the main Makefile, and I suspect you
> would need to do something similar.
It seems to be sufficient. The double quotes survived into my perl.mak file
and the two perl modules were installed correctly when I supplied a prefix
with spaces. Is there something else to be concerned about?
perl.mak:
all: private-Error.pm Git.pm
mkdir -p blib/lib
rm -f blib/lib/Git.pm; cp Git.pm blib/lib/
rm -f blib/lib/Error.pm
cp private-Error.pm blib/lib/Error.pm
install:
mkdir -p "/home/casey/opt/SunOS spaces/sun4u/lib"
rm -f "/home/casey/opt/SunOS spaces/sun4u/lib/Git.pm"; cp Git.pm "/home/casey/opt/SunOS spaces/sun4u/lib"
rm -f "/home/casey/opt/SunOS spaces/sun4u/lib/Error.pm"
cp private-Error.pm "/home/casey/opt/SunOS spaces/sun4u/lib/Error.pm"
instlibdir:
echo /home/casey/opt/SunOS spaces/sun4u/lib
-brandon
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2008, #01; Tue, 05)
From: Shawn O. Pearce @ 2008-08-06 14:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyjqsm04.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> [New Topics]
> * sp/smart-http (Sun Aug 3 00:25:17 2008 -0700) 2 commits
> - [do not merge -- original version] Add Git-aware CGI for Git-aware
> smart HTTP transport
> - Add backdoor options to receive-pack for use in Git-aware CGI
>
> The "magic" detection protocol was revised to use POST to info/refs; the
> top one queued is from before that discussion.
I'm surprised you queued these. They really are not ready for
application to a tree. For example the CGI is really messed up for
trying to do Transfer-Encoding: chunked on its own, JH was right and
Apache does it for us. That removed a good chunk of code from it.
Writing the client for this is slightly non-trivial. I more-or-less
want to shove it into send-pack, not http-push, as the bulk of the
protocol we need to speak is there in send-pack.
Anyway, I'm going to try to get back to this topic more later
this week. I have been focusing on JGit this week (or at least
trying to) as I really need to get some stuff done there for EGit.
--
Shawn.
^ permalink raw reply
* Re: git show doesn't respect config: diff.renames=copies
From: Björn Steinbrink @ 2008-08-06 14:15 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen R. van den Berg, git
In-Reply-To: <20080806140602.GA20423@sigill.intra.peff.net>
On 2008.08.06 10:06:03 -0400, Jeff King wrote:
> On Wed, Aug 06, 2008 at 01:43:40PM +0200, Stephen R. van den Berg wrote:
>
> > What do I need to enter in /etc/gitconfig to get all commands that
> > deal with diffs of some kind to honour renames=copies ?
>
> $ git grep -A3 diff.renames
> config.txt:diff.renames::
> config.txt- Tells git to detect renames. If set to any boolean value, it
> config.txt- will enable basic rename detection. If set to "copies" or
> config.txt- "copy", it will detect copies, as well.
See subject line ;-)
Works for me though. Stephen, probably the source file didn't change in
the same commit. In such a case you need --find-copies-harder, and that
seems not to be configurable as the default.
Björn
^ permalink raw reply
* Re: git show doesn't respect config: diff.renames=copies
From: Jeff King @ 2008-08-06 14:06 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: git
In-Reply-To: <20080806114340.GA24552@cuci.nl>
On Wed, Aug 06, 2008 at 01:43:40PM +0200, Stephen R. van den Berg wrote:
> What do I need to enter in /etc/gitconfig to get all commands that
> deal with diffs of some kind to honour renames=copies ?
$ git grep -A3 diff.renames
config.txt:diff.renames::
config.txt- Tells git to detect renames. If set to any boolean value, it
config.txt- will enable basic rename detection. If set to "copies" or
config.txt- "copy", it will detect copies, as well.
-Peff
^ permalink raw reply
* git-svn on MSysGit and why is it (going to be?) unsupported
From: Petr Baudis @ 2008-08-06 13:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alexander Litvinov, git
In-Reply-To: <alpine.DEB.1.00.0808061436310.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Hi!
On Wed, Aug 06, 2008 at 02:43:51PM +0200, Johannes Schindelin wrote:
> On Wed, 6 Aug 2008, Petr Baudis wrote:
>
> > On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:
> > > Note that you will have to do your digging using msysGit (i.e. the
> > > developer's pack, not the installer for plain Git), since git-svn will
> > > be removed from the next official "Windows Git" release, due to lack
> > > of fixers.
> >
> > is there any other problem with git-svn on Windows than the CRLF
> > issue? I couldn't find anything significant in the issue tracker.
>
> http://code.google.com/p/msysgit/issues/detail?id=120&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
Yes, that's why added the word "significant". ;-) This seems to be
simple module-out-of-sync issue.
> It is also frustrating that
>
> http://code.google.com/p/msysgit/issues/detail?id=83&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
> http://code.google.com/p/msysgit/issues/detail?id=103&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
> http://code.google.com/p/msysgit/issues/detail?id=129&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
>
> are probably the same issue. I cannot only blame the users for not really
> looking if their issue has been reported yet; there are 32 open issues in
> msysGit right now, number increasing, so it gets quite confusing.
>
> I once switched off the issue tracker, because I was the only one who took
> at least a little bit of care of it. Due to list consensus, it was turned
> back on -- against my will.
>
> Guess who takes care of it right now?
>
> Exactly. So I will soon be switching it off again, I think, because there
> are few more useless things than an unmonitored issue tracker.
Well, when looking through the tracker earlier today, I actually wanted
to mark few dupes, but I did not find out how on the earth I'm supposed
to do that. Either the operation is well-hidden in the web interface or
I have to have some special rights to do that - in which case, it's no
wonder the tracker is deteriorating.
> > If not, why do you want to drop git-svn from Windows Git? It seems
> > that the CRLF issue has trivial workaround to set autocrlf=false; this
> > will make git-svn-tracked repositories useful only on Windows, but I'd
> > bet this is fine for large majority of Windows git-svn users?
>
> If it was so trivial, why does nobody use it?
Because it is not documented? Or is it? *Searches crlf in git-svn.html
bundled with his msysgit* *Looks at Git FAQ* *Looks for release notes in
the start menu ... unsuccessfully* *Tries to Google out MSysGit release
notes ... unsuccessfully* *Founds MSysGit release notes sitting in
Program Files* "git svn is slow or seems to be broken (see discussions
on the mailing list)" What is "the" mailing list in MSysGit context?
*Googles out MSysGit Google Group* *Searches git-svn and pages... and
pages.*
http://groups.google.com/group/msysgit/browse_thread/thread/8240da55a76f8c92/30656b448e9f5e74?lnk=gst&q=git-svn#30656b448e9f5e74
Okay. That was really easy to find, wasn't it... Somewhere deep inside,
even few mentions of autocrlf can be found.
> Oh, and git-svn is slow, too.
>
> And _noone_ of those competent Windows git-svn users seemed fit or willing
> to do anything about git-svn, not even the simplest of issues.
I can of course understand that argument, even though it's a bit sad to
see when the issues are apparently either trivial or there is simple
workaround available. My trouble was that the _concrete_ reasons for
this are buried deep inside long mail threads (or threads on other
mailing lists).
> If you want to do something about it, go ahead. But I have no inclination
> of hearing from any Windows user about git-svn again, ever.
Not currently, I'm just afraid I *might* have to sometime in the future.
;-)
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* git filter-branch --subdirectory-filter, still a mistery
From: Jan Wielemaker @ 2008-08-06 13:39 UTC (permalink / raw)
To: git
Hi,
I've been puzzling most of today to do something that must be simple.
I've got a big repo which contains a project with several nicely related
subprojects in directories. Only now, we want to share some of these
subprojects with another project. I.e. they must start to live there own
life. Of course, I would like to keep the history. So, I did (git --version:
1.5.6.GIT):
% git clone /home/git/pl.git
% cd pl
% git filter-branch --subdirectory-filter packages/chr HEAD
This indeed creates a nice directory holding only the contents of
packages/chr. But, starting qgit I see that all commits, also those
that had absolutely nothing to do with this dir are still there. Also,
all tags are still there with exactly the same SHA1 as the original.
I'd expect the tags to be rewritten such that their SHA1 refers to the
state of this single directory and its contents!? Of course, these
tags give me access to everything, so the repository doesn't shrink
much too.
I must be missing something important ... I found similar complaints,
but few decent answers and the few answer I did find appeared outdated.
The one at http://use.perl.org/~rjbs/journal/34411 comes closest, although
the reset --hard is no longer needed and the copying and gc-ing doesn't
help much anymore.
Should I write a tree-filter that removes all but the directory I want
to keep? I.e. something like this? Feels like and overkill and I fear
I'll have a lot of empty commits left.
'mv packages/chr .. && rm -r * && mv ../chr/* . && rmdir ../chr'
I'll be grateful for a clue!
Cheers --- Jan
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Johannes Schindelin @ 2008-08-06 12:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alexander Litvinov, git
In-Reply-To: <20080806111545.GD32184@machine.or.cz>
Hi,
On Wed, 6 Aug 2008, Petr Baudis wrote:
> On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:
> > Note that you will have to do your digging using msysGit (i.e. the
> > developer's pack, not the installer for plain Git), since git-svn will
> > be removed from the next official "Windows Git" release, due to lack
> > of fixers.
>
> is there any other problem with git-svn on Windows than the CRLF
> issue? I couldn't find anything significant in the issue tracker.
http://code.google.com/p/msysgit/issues/detail?id=120&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
It is also frustrating that
http://code.google.com/p/msysgit/issues/detail?id=83&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
http://code.google.com/p/msysgit/issues/detail?id=103&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
http://code.google.com/p/msysgit/issues/detail?id=129&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary
are probably the same issue. I cannot only blame the users for not really
looking if their issue has been reported yet; there are 32 open issues in
msysGit right now, number increasing, so it gets quite confusing.
I once switched off the issue tracker, because I was the only one who took
at least a little bit of care of it. Due to list consensus, it was turned
back on -- against my will.
Guess who takes care of it right now?
Exactly. So I will soon be switching it off again, I think, because there
are few more useless things than an unmonitored issue tracker.
> If not, why do you want to drop git-svn from Windows Git? It seems
> that the CRLF issue has trivial workaround to set autocrlf=false; this
> will make git-svn-tracked repositories useful only on Windows, but I'd
> bet this is fine for large majority of Windows git-svn users?
If it was so trivial, why does nobody use it?
Oh, and git-svn is slow, too.
And _noone_ of those competent Windows git-svn users seemed fit or willing
to do anything about git-svn, not even the simplest of issues.
If you want to do something about it, go ahead. But I have no inclination
of hearing from any Windows user about git-svn again, ever.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Peter Harris @ 2008-08-06 12:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Alexander Litvinov, git
In-Reply-To: <20080806111545.GD32184@machine.or.cz>
On Wed, Aug 6, 2008 at 7:15 AM, Petr Baudis wrote:
> On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:
>> Note that you will have to do your digging using msysGit (i.e. the
>> developer's pack, not the installer for plain Git), since git-svn will be
>> removed from the next official "Windows Git" release, due to lack of
>> fixers.
>
> is there any other problem with git-svn on Windows than the CRLF
> issue? I couldn't find anything significant in the issue tracker.
The main problem currently is that git is Win32, and perl is Msys.
When perl asks git to read files from /tmp (a path that doesn't exist
outside Msys), it grinds to a screeching halt.
The quick and dirty fix is to convince git-svn to write temporary
files somewhere else (maybe by passing DIR => $ENV{GIT_DIR} to
File::Temp::tempname, but I've been too embarrassed to suggest that
publicly).
The correct fix is to switch the msysGit perl from Msys to Vanilla,
but I've been too lazy to finish that up (as the SVN modules quickly
descend into dependancy hell).
Peter Harris
^ permalink raw reply
* git show doesn't respect config: diff.renames=copies
From: Stephen R. van den Berg @ 2008-08-06 11:43 UTC (permalink / raw)
To: git
What do I need to enter in /etc/gitconfig to get all commands that
deal with diffs of some kind to honour renames=copies ?
--
Sincerely,
Stephen R. van den Berg.
If there's a hard way to do something, I'm there before anyone else.
^ permalink raw reply
* Re: [BUG] git diff-tree --stdin doesn't accept two trees
From: Karl Hasselström @ 2008-08-06 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsivusy2.fsf@gitster.siamese.dyndns.org>
On 2008-08-05 13:07:17 -0700, Junio C Hamano wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > I'm trying to use diff-tree --stdin to diff several trees in one
> > go. But I just get error messages when I feed it two
> > space-separated trees (one commit works fine):
>
> No, the documentation was made wrong during 1.2.0 timeperiod.
>
> The feature of --stdin to take a commit and its parents on one line was
> broken before that to support the common
>
> rev-list --parents $commits... -- $paths... |
> diff-tree --stdin -v -p
>
> usage pattern by Porcelains. For diff-tree to talk sensibly about
> commits, it needs to see commits, not just trees.
But is there any fundamental reason why it couldn't accept tree-ishes
as well? It only talks about commits if asked to do so with
command-line options.
Or would that break existing users somehow?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: do without .netrc
From: Jürgen Mangler @ 2008-08-06 11:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080806085025.GU32057@genesis.frugalware.org>
Miklos Vajna wrote:
> On Wed, Aug 06, 2008 at 01:00:54AM +0200, Jürgen Mangler <juergen.mangler@univie.ac.at> wrote:
>> it is working without a:b@ part, but ~/.netrc instead
>>
>> :-(, is it possible without .netrc
>
> I thought questions have question marks. ;-)
Explanation 1: I wrote it to IRC and then thought maybe crossposting to
the list would be no bad idea. On IRC i was not using question marks,
mail was just copying the lines, forgot to add question marks.
Explanation 2: its not questions but accusations! *fg*
> Anyway, what is the advantage of not using a ~/.netrc?
It's mentioned on several occations that it is not necessary (e.g.
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt)
The advantages for me would be:
a) I have multiple different passwords on the same server for different
directories, it's not possible to put this to a netrc (AS FAR AS I
KNOW). So i have to edit the netrc for every push, clone, ... -> very
inconvenient
b) secondly (maybe not a super valid argument for you): netrc is not
considered to be the most secure thing, isn't it? Our network is invaded
every year "tested" by thousands of computer science students, so i
always try to have as few plain-text passwords as possible lying around
(one never knows - yes netrc has 0600).
i'd also prefer not to use the user:pass@server schema, but to be asked,
to not show pass in the history and config file in .git although even
user:pass@server would be an advantage because it solves a).
Jürgen
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Petr Baudis @ 2008-08-06 11:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alexander Litvinov, git
In-Reply-To: <alpine.DEB.1.00.0807231356540.8986@racer>
Hi,
On Wed, Jul 23, 2008 at 01:57:54PM +0100, Johannes Schindelin wrote:
> Note that you will have to do your digging using msysGit (i.e. the
> developer's pack, not the installer for plain Git), since git-svn will be
> removed from the next official "Windows Git" release, due to lack of
> fixers.
is there any other problem with git-svn on Windows than the CRLF
issue? I couldn't find anything significant in the issue tracker.
If not, why do you want to drop git-svn from Windows Git? It seems
that the CRLF issue has trivial workaround to set autocrlf=false;
this will make git-svn-tracked repositories useful only on Windows,
but I'd bet this is fine for large majority of Windows git-svn users?
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [tig] Feeding specific revisions to tig
From: Jonas Fonseca @ 2008-08-06 11:06 UTC (permalink / raw)
To: Jeff King; +Cc: Jean-Baptiste Quenot, git
In-Reply-To: <20080604230858.GA27136@sigill.intra.peff.net>
Sorry for restarting this old thread ...
On Thu, Jun 5, 2008 at 01:08, Jeff King <peff@peff.net> wrote:
> On Wed, Jun 04, 2008 at 10:04:45PM +0200, Jean-Baptiste Quenot wrote:
>
>> Thanks for the suggestion. However, my list of commits is too long,
>> the shell errors out with "tig: command too long". I'd like to feed
>> tig with a list of commits from stdin, or from a file.
>>
>> Something like: ... | tig --no-walk -F -
>>
>> Which means: take the list of revisions from specified file, or here -
>> for stdin, a la grep.
>
> Ah. Adding "-F" probably wouldn't be that much work, but tig spawns "git
> log" internally, so you would probably end up with the same problem
> there. Converting tig to use "git rev-list --stdin" would fix that, but
> is probably a bit of major surgery.
git-rev-list expects a commit as an argument while git-log does not. I
have been gradually changing the option parsing code to move towards
using git-rev-parse for splitting up arguments so it will be possible
to support refreshing better and pass user arguments to the diff
engine etc. When the code will get there it probably won't be that
hard to switch to use git-rev-list.
I actually added something that let's you alter the command executed
for each view. So here is another possibility that can be used:
function tignowalk ()
{
tmp=$(mktemp) # or .git/tigfiles or similar
# Safe stuff from "stdin" and run tig with custom rev-list command
cat > "$tmp
TIG_MAIN_CMD="git rev-list --pretty=raw --no-walk --stdin < $tmp"
tig < /dev/tty
rm "$tmp"
}
And then:
printf "tig-0.2\ntig-0.1" | tignowalk
On Wed, Jun 4, 2008 at 22:04, Jean-Baptiste Quenot <jbq@caraldi.com> wrote:
> 2008/6/4 Jeff King <peff@peff.net>:
>> Though it seems there are a few display artifacts. If I do
>>
>> tig --no-walk tig-0.1 tig-0.2
>>
>> I get the 2 commits I expect, but also two "extra" blank
>> commits at the bottom.
>
> I confirm there are extra blank lines at the bottom. As many as real
> commit lines.
The problem is that --no-walk doesn't seem to play nice with the
--boundary flag that tig add by default. When the user requests
--no-walk boundary commits are probably not interesting. My fix below
has more information. I don't know if having only the "commit" line
show up is a bug in git. At least there are no tests to confirm this
or not.
commit ad9f9954419b5d3f595580d5184db59a00711f92
Author: Jonas Fonseca <fonseca@diku.dk>
Date: Tue Aug 5 23:40:21 2008 +0200
Clean up incomplete commits from main view listed for --no-walk
When --no-walk is given on the command line by the user it causes
boundary commits to be output with just the commit line, i.e:
> git rev-list --pretty=raw --boundary --no-walk HEAD
commit 60e8ea56880fc2e42008075d516c356ef605bc60
tree 5b76086e4deaf62d3f7baffc6f49840f61d4e79c
parent 145194bdfc8bf0b58185bbe28bc0097ce429de4d
author Jonas Fonseca <fonseca@diku.dk> 1217797175 +0200
committer Jonas Fonseca <fonseca@diku.dk> 1217797402 +0200
Remove the global opt_request variable
commit -145194bdfc8bf0b58185bbe28bc0097ce429de4d
diff --git a/NEWS b/NEWS
index b7a8df1..d93fb04 100644
--- a/NEWS
+++ b/NEWS
@@ -22,6 +22,7 @@ Bug fixes:
keybinding to launch the merge tool in the status view.
- Fix problem with $(cmd) usage in shell code. Some shells (jsh)
installed as /bin/sh does not support it.
+ - Do not show incomplete boundary commits when --no-walk is used.
- Documentation: Rename gitlink macro to support AsciiDoc 8.2.3.
tig-0.11
diff --git a/tig.c b/tig.c
index 6846519..6b111e4 100644
--- a/tig.c
+++ b/tig.c
@@ -4983,6 +4983,14 @@ main_read(struct view *view, char *line)
if (!line) {
if (!view->lines && !view->parent)
die("No revisions match the given arguments.");
+ if (view->lines > 0) {
+ commit = view->line[view->lines - 1].data;
+ if (!*commit->author) {
+ view->lines--;
+ free(commit);
+ graph->commit = NULL;
+ }
+ }
update_rev_graph(graph);
return TRUE;
}
--
Jonas Fonseca
^ permalink raw reply related
* Re: something fishy with Git commit and log from file
From: Pascal Obry @ 2008-08-06 11:01 UTC (permalink / raw)
To: Luciano Rocha; +Cc: git list
In-Reply-To: <20080806104432.GG7121@bit.office.eurotux.com>
Luciano,
> If the function doesn't exist, try:
> (gdb) p getwd(malloc(2048))
I got:
(gdb) p (char *)getwd(malloc(2048))
$3 = 0x903680 "/home/obry/dev/repositories/git/AWS"
And this is not the directory I was in. It is the Git root. I was under
/home/obry/dev/repositories/git/AWS/regtests when running the command.
So definitely a Git bug! Can be reproduced with:
$ mkdir repo && cd repo
$ git init
$ mkdir dir
$ cd dir
$ echo file > file
$ echo log > log
$ git add file
$ git commit --file=log
fatal: could not read log file 'log': No such file or directory
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: do without .netrc
From: Miklos Vajna @ 2008-08-06 10:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g7bq85$otb$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On Wed, Aug 06, 2008 at 11:17:48AM +0200, Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
> Not having the password on disk[?!]
I think you can't avoid so (we are talking about http).
There is no such thing as ssh-agent for http, and typing the password
for each pull or push is boring. (OK, this is subjective, but I think
nobody types his/her pass on every push/pull.)
You could have the password in the URL, but the it's in .git/config,
even worse.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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