* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-08-01 3:23 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Eric Wong
In-Reply-To: <20080731104529.GE7008@dpotapov.dyndns.org>
> It does not look to be true. I did the following test:
...
> which means that the autocrlf conversion is done for temporary
> files created by perl. (I tested it on Linux and Windows/Cygwin).
>
> In any case, I believe the right solution should be adding a
> new option to git-hash-object to disable any conversion.
My bad, I did not append full thoughts. git-hash-object DOES autocrlf
convertion but it cant do it correctly. All it can do - is to autodetect
text files. My setup has .git/info/attributes file where all files but .cpp
and .h are binary. While .cpp and .h are text files. In this case
git-hash-object do not know the real file name as far as git-svn use
temporary files.
I dont think that disabling convertion is a good way. I really want to convert
my files. Possible solution is to pass two file names to git-hash-object: the
real file with content and the proposed file name in the working directory.
In this case git-hash-object will be able to make correct convertion.
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Linus Torvalds @ 2008-08-01 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vabfxv3px.fsf@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
>
> It was even worse than that.
>
> The output from v3 is incorrect
Ok. I'm really not surprised. Incrementally is really hard. I'm reminded
of all the problems we had with just the "trivial" issue of just knowing
when to consider something uninteresting or not, that ended up depending
on commit timestamps etc, and had problems with people having their clocks
set incorrectly.
Doing the ops once you have the full DAG is usually _trivial_ by
comparison.
Linus
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-08-01 3:59 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311956040.3277@nehalem.linux-foundation.org>
On Thu, 31 Jul 2008, Linus Torvalds wrote:
>
> Well, the difference really is the beefy box.
Btw, the fact that I have a beefy box really wasn't the point. The fact
that I can build the kernel three times quicker than I can build the git
documentation _was_ kind of the point. A lot of projects have horrible
build rules - makefiles that don't parallelize well or just tools that
suck dead baby donkeys through a straw.
I often get the feeling that I can compile the kernel faster than I can
run "./configure" on most of the other projects I ever compile.
So I'd heartily encourage projects to try to make their build lean and
mean. It actually then allows you to be more efficient, and gives the
option of using more efficient development models, where "use multiple
branches in the same tree" is just one example of that.
Of course, I have to admit that git itself isn't exactly a stellar
example. I can compile git itself in basically zero time, but those docs
really take a loooong time.
Just one more reason for me to stay away from documentation.
Linus
^ permalink raw reply
* Re: git help broken
From: Christian Couder @ 2008-08-01 4:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, Kevin Ballard, Git Mailing List
In-Reply-To: <20080731000454.GJ32057@genesis.frugalware.org>
Le jeudi 31 juillet 2008, Miklos Vajna a écrit :
> On Thu, Jul 31, 2008 at 01:44:36AM +0200, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> > > And from the patch, it is pretty obvious that it does not come close
> > > to the "man" code path.
> >
> > Oh, so it was involved?
>
> Yes. The command list is no longer loaded automatically and the default
> for non-git commands on git help foo was 'gitfoo', I guess for
> gittutorial and such manpages.
Yeah, and it seems that "git help help" doesn't work any more since my patch
that does that:
2dce956e397be8a769624e8693565b8a30056060 help: check early if we have a
command, if not try a documentation topic
I didn't realize that the function "is_git_command" would not work
for "help".
Perhaps there should be another function like is_git_command that could work
using the "struct cmd_struct commands" defined in "handle_internal_command"
in "git.c". That may be faster and more accurate.
Unfortunately I won't have time to work on this as I will leave for vacation
in a few hours. Sorry to leave this behind.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Junio C Hamano @ 2008-08-01 5:09 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Dmitry Potapov, git, Eric Wong
In-Reply-To: <200808011023.32139.litvinov2004@gmail.com>
Alexander Litvinov <litvinov2004@gmail.com> writes:
> I dont think that disabling convertion is a good way. I really want to convert
> my files. Possible solution is to pass two file names to git-hash-object: the
> real file with content and the proposed file name in the working directory.
> In this case git-hash-object will be able to make correct convertion.
I think the optional parameter to say "pretend the content is from this
path" makes sense even for (and especially for) hashing --stdin.
^ permalink raw reply
* [ANN] git cola: a highly caffeinated git gui
From: David Aguilar @ 2008-08-01 6:08 UTC (permalink / raw)
To: Git Mailing List, msysgit
Greetings!
The latest version of git cola is available for download from the
usual interwebs:
http://cola.tuxfamily.org/
http://gitorious.org/projects/git-cola/
git cola is a highly functional git gui licensed under the gpl.
It's written in Python/Qt4. In addition to its native platform
(Linux/Unix), cola also runs on OSX and Windows.
Although tarballs, .rpms and .deb packages are available, building it
from source is very easy.
On debian it's as simple as:
sudo apt-get install simplejson python-qt4 pyqt4-dev-tools python-pyinotify
git clone git://gitorious.org/git-cola/mainline.git cola
cd cola && ./configure && make && make install
Like git gui, it allows you to do very fine-grained commits. It has a
bunch of other random useful stuff, so I figured it was about time to
announce it here. It has inotify support on Linux, which is why
there's no rescan button in cola.
Hopefully the code isn't too rotten ;-)
CAVEATS:
i18n/l10n is incomplete. I used the latest .po files from git-gui,
but obviously there are a number of strings in git cola that don't
have translations. If there is an interest in cola from the user
community then I will need some advice on how to handle this
situation. I don't like having stolen the .po's from git-gui (sorry
Shawn!) but it did prove that the infrastucture for "LANG=ja git cola"
is working correctly.
cola works by parsing git commands. It's pretty fast despite the
process overhead, though it'll probably be a bit slower on windows. I
have no idea what cr/lf issues exist (if any), though I've tried to be
careful about it.
enjoy,
p.s. if you happen to prefer dark color themes you can run: git cola
--style=dark
--
David
^ permalink raw reply
* Re: [ANN] git cola: a highly caffeinated git gui
From: H.Merijn Brand @ 2008-08-01 6:34 UTC (permalink / raw)
To: David Aguilar; +Cc: Git Mailing List, msysgit
In-Reply-To: <402731c90807312308l4870382dsb707fafd37f9b1d4@mail.gmail.com>
On Thu, 31 Jul 2008 23:08:01 -0700, "David Aguilar" <davvid@gmail.com>
wrote:
> Greetings!
>
> The latest version of git cola is available for download from the
> usual interwebs:
>
> http://cola.tuxfamily.org/
> http://gitorious.org/projects/git-cola/
Your dependencies don't match.
# cola-1.1.1-2.noarch.rpm
$ cola
Traceback (most recent call last):
File "/usr/bin/cola", line 112, in <module>
main()
File "/usr/bin/cola", line 53, in main
from cola.models import Model
File "../../cola/models.py", line 9, in <module>
File "../../cola/utils.py", line 9, in <module>
File "../../cola/defaults.py", line 4, in <module>
ImportError: No module named PyQt4.QtCore
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [ANN] git cola: a highly caffeinated git gui
From: David Aguilar @ 2008-08-01 6:52 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Git Mailing List, msysgit
In-Reply-To: <20080801083413.2ac1782b@pc09.procura.nl>
On Thu, Jul 31, 2008 at 11:34 PM, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Thu, 31 Jul 2008 23:08:01 -0700, "David Aguilar" <davvid@gmail.com>
> wrote:
>
>> Greetings!
>>
>> The latest version of git cola is available for download from the
>> usual interwebs:
>>
>> http://cola.tuxfamily.org/
>> http://gitorious.org/projects/git-cola/
>
> Your dependencies don't match.
>
> # cola-1.1.1-2.noarch.rpm
sorry, I used alien to convert my .debs into an rpm. scripts/mkdeb.sh.
yum installing pyqt4 should fix it.
> ImportError: No module named PyQt4.QtCore
>
> --
> H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
> using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
> 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
> http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
> http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
>
--
David
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-08-01 7:04 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160807311203o3fb4deb8u4a5ae57818c76fab@mail.gmail.com>
On Thu, 31 Jul 2008 21:03:26 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Thu, Jul 31, 2008 at 20:15, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> > On Thu, 31 Jul 2008 17:24:40 +0200, "Santi Béjar" <sbejar@gmail.com> wrote:
> >
> >> I see all OK. Can you provide a self consistent simple testcase that
> >> shows what is wrong?
> >
> > Yes. was rather easy.
> > http://www.xs4all.nl/~hmbrand/testcase.tgz
>
> It is because you cannot merge a branch with an empty branch. So, or
> you create an initial commit in the "superproject" or you create a
> commit just moving the files of the first module as in:
>
> http://article.gmane.org/gmane.comp.version-control.git/79887
Almost perfect now.
4gl/new 121 > git-ls-files | grep fnc_declare
include/fnc_declare.h
4gl/new 122 > git-show d971ec91a3dbc9f1f27a96e4f9b95366babd036c
commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
Author: H.M. Brand <merijn@a5.(none)>
Date: Tue Jul 29 16:45:43 2008 +0200
Backward comp functie voor PV indicatie
diff --git a/fnc_declare.h b/fnc_declare.h
index acd686c..25d9a73 100644
--- a/fnc_declare.h
+++ b/fnc_declare.h
@@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
eaf_N pv_datum ($x1, $x2, $x3);
#endif
+#ifndef PV_INDICATIE
+#define PV_INDICATIE
+eaf_S pv_indicatie ($x1);
+#endif
+
#undef eaf_B
#undef eaf_N
#undef eaf_S
4gl/new 123 >
all the diffs are still showing as if they were against the folder they
were originally committed in. Is that correct? I would now have expected
something like
commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
Author: H.M. Brand <merijn@a5.(none)>
Date: Tue Jul 29 16:45:43 2008 +0200
Backward comp functie voor PV indicatie
diff --git a/include/fnc_declare.h b/include/fnc_declare.h
index acd686c..25d9a73 100644
--- a/include/fnc_declare.h
+++ b/include/fnc_declare.h
@@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
eaf_N pv_datum ($x1, $x2, $x3);
#endif
+#ifndef PV_INDICATIE
+#define PV_INDICATIE
+eaf_S pv_indicatie ($x1);
+#endif
+
#undef eaf_B
#undef eaf_N
#undef eaf_S
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply related
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-08-01 7:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stephan Beyer, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <7vvdylv9zq.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Junio C Hamano wrote:
> Abdelrazak Younes<younes@lyx.org> writes:
>
>
>> I just had a look at the user manual and, well unless you have a
>> special emacs mode or whatever that can automate the markup tag
>> insertion, I wonder how can anybody think that writing with this
>> markup language is easier than within LyX, really (genuine question,
>> not sarcasm).
>>
>
> How greppable and "log -p"-able is the documentation written in LyX?
>
LyX format is plain text, loosely based on LateX. Here's attached a
sample .lyx file FYI. We have one tag per line and a maximum of 80 char
per line so that the format is easily parsable. Advanced users often use
unix tools (grep, sed, etc) to modify the .lyx file manually.
> * Where in the documentation do I have to change the description of
> "--parents" option?
>
You mean in a text editor, not within LyX? Just look for the string :-)
> * When did the description of "--cc" for diff families last changed, by
> whom and why?
>
Ditto.
> Eas of doing these is mostly why we chose AsciiDoc to begin with. Any
> alternative you are going to suggest should not make these two things
> impossible or very harder to do.
>
If you ignore the LyX tags, you can just do what you are used to do
without problem using a plain text editor. If you want to do something
more complicated stuff like choosing a different environment or creating
a nested enumerate list, it is easier to do that within LyX.
Abdel.
[-- Attachment #2: FAQ.lyx --]
[-- Type: application/lyx, Size: 35350 bytes --]
^ permalink raw reply
* Re: [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Junio C Hamano @ 2008-08-01 7:23 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <1217510434-94979-1-git-send-email-pdebie@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
> ---
>
> Or was there a specific reason not to allow this?
I'll let Dscho answer that one.
> diff --git a/builtin-name-rev.c b/builtin-name-rev.c
> index 85612c4..0536af4 100644
> --- a/builtin-name-rev.c
> +++ b/builtin-name-rev.c
> @@ -266,8 +266,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
> if (!name)
> continue;
>
> - fwrite(p_start, p - p_start + 1, 1, stdout);
> - printf(" (%s)", name);
> + if (data.name_only) {
> + fwrite(p_start, p - p_start + 1 - 40, 1, stdout);
> + printf(name);
> + }
> + else {
> + fwrite(p_start, p - p_start + 1, 1, stdout);
> + printf(" (%s)", name);
> + }
> p_start = p + 1;
> }
> }
Is it just me to find that this part is getting indented too deeply to be
readable?
^ permalink raw reply
* Re: Git vs Monotone
From: Sverre Rabbelier @ 2008-08-01 7:23 UTC (permalink / raw)
To: Git Mailinglist
In-Reply-To: <bd6139dc0807311113n50dda9f0t1aab46b724510de2@mail.gmail.com>
On Thu, Jul 31, 2008 at 20:13, Sverre Rabbelier <alturin@gmail.com> wrote:
> I just read this blog post [0] in which one of the Pidgin devs sheds
> his light on their 'tool choice'. In the post he mentions the
> following figures:
> [0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html
I have poked him on #pidgin, and he has added the following:
"Note: It's come to my attention that I had missed the ability to
share a git database across multiple working copies. In that scenario,
the total size of the database and 11 working copies is slightly under
750 MB, and thus a space savings in the neighborhood of 150 MB over
monotone. It had been my understanding that I needed a copy of the
database per working copy. I stand corrected. I don't use git on a
daily basis, as the projects I work with currently use CVS, SVN, or
monotone, so I am bound to miss finer details of git here and there.
There are other reasons I prefer to stick with monotone, but I won't
get into them here, as they're not important to the point of this
post."
So I'm happy ;).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] diff: add ruby funcname pattern
From: Junio C Hamano @ 2008-08-01 7:30 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1217488908-19692-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> Provide a regexp that catches class, module and method definitions in
> Ruby scripts, since the built-in default only finds classes.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> diff.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index cbf2547..c253015 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1381,6 +1381,7 @@ static struct builtin_funcname_pattern {
> "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
> "[ ]*([^;]*\\)$" },
> { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
> + { "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
> };
>
> static const char *diff_funcname_pattern(struct diff_filespec *one)
Thanks.
I do not talk Ruby, so I'll wait for a few days to hear any one of the
following happen before deciding what to do with this patch:
(1) Yeah, this is a sufficient and necessary set of keywords, and it
would make my Ruby life so much better;
(2) This might be a good start but you need to cover this and that
keywords as well;
(3) This will misidentify a line that is not the beginning of a
definition, and should not be applied;
Needless to say, "Here is a better patch" is appreciated if somebody says
(2) or (3).
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-08-01 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <7v63qluxsb.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 1, 2008 at 9:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Alexander Litvinov <litvinov2004@gmail.com> writes:
>
>> I dont think that disabling convertion is a good way. I really want to convert
>> my files. Possible solution is to pass two file names to git-hash-object: the
>> real file with content and the proposed file name in the working directory.
>> In this case git-hash-object will be able to make correct convertion.
>
> I think the optional parameter to say "pretend the content is from this
> path" makes sense even for (and especially for) hashing --stdin.
git-svn uses git hash-object --stdin-paths, which means that it reads
filenames from the standard input, so one optional parameter cannot
help here. Also, I am not sure how it can be useful for --stdin, which
does not convert anything (it uses index_pipe, which does not call
convert_to_git).
Dmitry
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-08-01 7:47 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git, Eric Wong
In-Reply-To: <200808011023.32139.litvinov2004@gmail.com>
On Fri, Aug 1, 2008 at 7:23 AM, Alexander Litvinov
<litvinov2004@gmail.com> wrote:
>
> I dont think that disabling convertion is a good way. I really want to convert
> my files.
To being able to synchronize efficiently in both ways, you need to store
files exactly as they were received from SVN then there will be no
problem with applying binary delta patch. All CRLF conversion should be
done on checkout and checkin from/to Git repository.
Dmitry
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-08-01 7:50 UTC (permalink / raw)
To: git; +Cc: git, Johannes Schindelin, Julian Phillips, Scott Chacon,
Petr Baudis
In-Reply-To: <20080731225703.7be6f76e@neuron>
Hi Jan,
Jan Krüger wrote:
>> Now, about my shameless plug: LyX is ideally suited for structured
>> documentation writing :-)
>
> That may well be, but it gets really complicated once you want to
> get your document into other markup-based formats while preserving all
> the important aspects of formatting. I know this because I started
> using LaTeX for a project that was supposed to be available in HTML
> form along with, say, PDF. I've found that the only converter that
> comes close to being useful for somewhat more ambitious sources
> (including, perhaps, custom environments and stuff like that) without
> spending a ridiculous amount of time trying to understand it is hevea.
I had good success with htlatex (the default converter within LyX). I
just modified the css and was done with it. All cross-references etc
were correctly handled.
> Of course, hevea only translates to HTML, so, for example, generating
> manpages or plain text is an entirely different matter of considerable
> difficulty.
LyX has an excellent plain text export. You can use the export method of
LyX at the command line without launching it graphically by the way. You
don't even need an X server, just use 'lyx -e text mydocument.lyx'
For man page, LyX does not support it natively I'm afraid, but I guess
there are LateX to man converter, aren't there?
> In addition to that, I suspect that LyX files might be difficult to
> deal with in forky Git situations. For example, what if two
> separately contributed patches need merging into a LyX source file?
> This will only work automatically if the LyX source, treated as plain
> text, has a really low chance of randomly changing in other places than
> what the patch is supposed to touch. Also, if a merge does cause a
> conflict, I imagine it would be difficult to resolve that.
Not really. As I said to Junio, .lyx files are using a plain text utf8
format. They are easily mergeable as LyX preserves the structure of the
file: if the two collaborators modify two different parts of the
document there is basically zero chance to have a conflict. On the rare
occasion where I had a conflict with svn, it was very easy to solve
manually by removing the conflict tags inserted by svn. With git, I
never had a single conflict ;-)
> Finally, it's pretty much a given that Git's manpages continue to use
> AsciiDoc because there are few other things that can generate actual
> manpages. I'm not sure it would be a good idea to keep half of Git's
> documentation in one format and the rest in another.
That's a good argument. My personal opinion is that users prefer to use
'-help' for short help and to read the tutorial or the user guide for
more in-depth information. I never use man personally... OK, that's
probably because I use Windows :-)
> And AsciiDoc is --
> by far! -- not the worst choice. I'm tempted to say it's the best that
> I know.
AsciiDoc is indeed excellent if you want to write in a plain text
editor. But LyX is easier to use and more porwerful :-)
Thanks,
Abdel
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-08-01 7:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807312044240.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 31 Jul 2008, Junio C Hamano wrote:
>>
>> It was even worse than that.
>>
>> The output from v3 is incorrect
>
> Ok. I'm really not surprised. Incrementally is really hard. I'm reminded
> of all the problems we had with just the "trivial" issue of just knowing
> when to consider something uninteresting or not, that ended up depending
> on commit timestamps etc, and had problems with people having their clocks
> set incorrectly.
>
> Doing the ops once you have the full DAG is usually _trivial_ by
> comparison.
Surely. I wasn't productive tonight anyway, and I'll give up for now and
keep the post-processing version in 'pu', perhaps queued in 'next' during
the 1.6.0-rc period. Perhaps somebody cleverer than me will feel itchy
enough to make an incremental version someday ;-)
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Junio C Hamano @ 2008-08-01 8:08 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <37fcd2780808010047t4ae20168y65103e90897dd3f8@mail.gmail.com>
"Dmitry Potapov" <dpotapov@gmail.com> writes:
> On Fri, Aug 1, 2008 at 7:23 AM, Alexander Litvinov
> <litvinov2004@gmail.com> wrote:
>>
>> I dont think that disabling convertion is a good way. I really want to convert
>> my files.
>
> To being able to synchronize efficiently in both ways, you need to store
> files exactly as they were received from SVN then there will be no
> problem with applying binary delta patch. All CRLF conversion should be
> done on checkout and checkin from/to Git repository.
Ahh,... if that is the philosophy, perhaps we can teach --stdin-paths to
optionally open the file itself and use index_pipe() like --stdin codepath
does?
^ permalink raw reply
* Re: [PATCH] diff: add ruby funcname pattern
From: Giuseppe Bilotta @ 2008-08-01 8:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyjxtco3.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 1, 2008 at 9:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Thanks.
>
> I do not talk Ruby,
You're really missing into something ;)
> so I'll wait for a few days to hear any one of the
> following happen before deciding what to do with this patch:
>
> (1) Yeah, this is a sufficient and necessary set of keywords, and it
> would make my Ruby life so much better;
>
> (2) This might be a good start but you need to cover this and that
> keywords as well;
>
> (3) This will misidentify a line that is not the beginning of a
> definition, and should not be applied;
>
> Needless to say, "Here is a better patch" is appreciated if somebody says
> (2) or (3).
I wasn't sure about the completeness of the regexp myself, which is
why I asked in #ruby on freenode for additional suggestions. The only
reply I got was an idea to add a number of block-based coding sections
such as Procs an Threads by matching .*\.new ({|do) as well.
This is something I had been thinking about myself, but I decided to
discard the idea because the current chunk text detection in git does
not have a way to say 'this is the end of a function, so get back to
the previous chunk (con)text' instead of using the last chunk text: so
if I have methodx followed by methody and make a change near the top
of methody I get methodx in the chunk text.
This limitation, that affects all funcname parsers, has kept me from
adding Proc, Thread and other anonymous code blocks to the Ruby
funcname, because having the proper context for changed code after an
anonymous block is IMO better than having specific context in the
anonymous block itself.
OTOH, if the funcname capability was expand to a full stack
manipulation (push chunk text, pop chunk text) ... (and yes, if I ever
find a sane way to do it myself I *will* provide a patch)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] diff: add ruby funcname pattern
From: Junio C Hamano @ 2008-08-01 8:20 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0808010111j29e2085etd58150037b55063c@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
> On Fri, Aug 1, 2008 at 9:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> so I'll wait for a few days to hear any one of the
>> following happen before deciding what to do with this patch:
>>
>> (1) Yeah, this is a sufficient and necessary set of keywords, and it
>> would make my Ruby life so much better;
>>
>> (2) This might be a good start but you need to cover this and that
>> keywords as well;
>>
>> (3) This will misidentify a line that is not the beginning of a
>> definition, and should not be applied;
>>
>> Needless to say, "Here is a better patch" is appreciated if somebody says
>> (2) or (3).
>
> I wasn't sure about the completeness of the regexp myself, which is
Well, I forgot to say but the above was soliciting third party review;
original submitter does not count ;-)
... nah, I am just joking.
All of the things you said in the message I am responding to are good
background information. It would have been nicer if it were part of the
initial message, perhaps below the three dash lines, which would have
avoided this extra exchange.
Thanks again for the patch. Somewhere I heard that there are 10 Rubyista
git users for every non Rubyista git user, so I am sure somebody would
comment on your patch in a day or two. Perhaps we might even get Python
and Perl hunk patterns (although I suspect Perl people are happy with the
default one we stole from GNU diff) to go with it ;-).
^ permalink raw reply
* Re: [PATCH] diff: add ruby funcname pattern
From: Giuseppe Bilotta @ 2008-08-01 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4p65tadh.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 1, 2008 at 10:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Well, I forgot to say but the above was soliciting third party review;
> original submitter does not count ;-)
>
> ... nah, I am just joking.
>
> All of the things you said in the message I am responding to are good
> background information. It would have been nicer if it were part of the
> initial message, perhaps below the three dash lines, which would have
> avoided this extra exchange.
Yeah, I know, I'm sorry, I realized I should have written it there as
I was replying to your email. I'll try to keep it in mind the next
time I submit a patch :)
> Thanks again for the patch. Somewhere I heard that there are 10 Rubyista
> git users for every non Rubyista git user, so I am sure somebody would
> comment on your patch in a day or two. Perhaps we might even get Python
> and Perl hunk patterns (although I suspect Perl people are happy with the
> default one we stole from GNU diff) to go with it ;-).
You know, I think the Ruby funcname would work pretty well with Python
as well. Or something very similar. I'll try cooking up a patch for
that too. (But I thought Python users used mercurial? 8-D)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-08-01 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <7vbq0dtawp.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 1, 2008 at 12:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Dmitry Potapov" <dpotapov@gmail.com> writes:
>>
>> To being able to synchronize efficiently in both ways, you need to store
>> files exactly as they were received from SVN then there will be no
>> problem with applying binary delta patch. All CRLF conversion should be
>> done on checkout and checkin from/to Git repository.
>
> Ahh,... if that is the philosophy, perhaps we can teach --stdin-paths to
> optionally open the file itself and use index_pipe() like --stdin codepath
> does?
It is possible to do in this way, but it less efficient, because it uses
index_pipe, which does not know the actual size, so it reallocates the buffer
as it reads data from the descriptor, while index_fd uses xmap() instead.
So I sent another solution yesterday:
http://article.gmane.org/gmane.comp.version-control.git/90968
It is a bit hackish because I unset S_IFREG bit in st_mode to disable
conversion. In fact, my question what would be a better way to tell index_fd
to not do any conversion. If you think that it is better to use index_pipe,
which does not any conversion than I will redo my patch to use it instead.
Dmitry
^ permalink raw reply
* git rev-parse --verify HEAD: fatal: Needed a single revision
From: Arkadiusz Miskiewicz @ 2008-08-01 9:29 UTC (permalink / raw)
To: git
Hello,
I'm trying to git cvsimport a cvs repository. Process ends with:
DONE.
fatal: Needed a single revision
Can merge only exactly one commit into empty head
Could not merge origin into the current branch.
The fatal comes from:
$ git rev-parse --verify HEAD
fatal: Needed a single revision
What is the problem here and how to fix it?
How to reproduce:
get http://carme.pld-linux.org/~arekm/rpm5.tar.bz2
unpack
cd rpm5
git cvsimport -v -d :pserver:anonymous@rpm5.org:/cvs rpm
I'm using:
$ git --version
git version 1.5.6.4
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Thomas Rast @ 2008-08-01 9:46 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: Junio C Hamano, Stephan Beyer, git, Johannes Schindelin,
Julian Phillips, Scott Chacon, Petr Baudis
In-Reply-To: <4892B714.8010401@lyx.org>
[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]
You wrote:
> Junio C Hamano wrote:
> >
> > How greppable and "log -p"-able is the documentation written in LyX?
>
> LyX format is plain text, loosely based on LateX. Here's attached a
> sample .lyx file FYI. We have one tag per line and a maximum of 80 char
> per line so that the format is easily parsable. Advanced users often use
> unix tools (grep, sed, etc) to modify the .lyx file manually.
Is it just me or is the format very hard to read? For example, line
492ff spells a list of quoted items as
\begin_layout Standard
Generally, you would send email to lyx-foo-subscribe@lists.lyx.org to subscribe
to these lists or to lyx-foo-unsubscribe@lists.lyx.org to unsubscribe, where
\begin_inset Quotes eld
\end_inset
foo
\begin_inset Quotes erd
\end_inset
is one of
\begin_inset Quotes eld
\end_inset
announce
\begin_inset Quotes erd
\end_inset
etc. Of course I can "parse" the language, but my untrained eye is
unable to fluently read the text hiding behind it.
Also, if I made a commit changing the "announce", you would have to
turn up diff context to at least 13 lines to get any _semantic_
context of the change.
- Thomas
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Merging submodules
From: Santi Béjar @ 2008-08-01 9:52 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080801090422.55c6a45f@pc09.procura.nl>
On Fri, Aug 1, 2008 at 09:04, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>
> Almost perfect now.
>
> 4gl/new 121 > git-ls-files | grep fnc_declare
> include/fnc_declare.h
> 4gl/new 122 > git-show d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> Author: H.M. Brand <merijn@a5.(none)>
> Date: Tue Jul 29 16:45:43 2008 +0200
>
> Backward comp functie voor PV indicatie
>
> diff --git a/fnc_declare.h b/fnc_declare.h
> index acd686c..25d9a73 100644
> --- a/fnc_declare.h
> +++ b/fnc_declare.h
> @@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
> eaf_N pv_datum ($x1, $x2, $x3);
> #endif
>
> +#ifndef PV_INDICATIE
> +#define PV_INDICATIE
> +eaf_S pv_indicatie ($x1);
> +#endif
> +
> #undef eaf_B
> #undef eaf_N
> #undef eaf_S
> 4gl/new 123 >
>
> all the diffs are still showing as if they were against the folder they
> were originally committed in. Is that correct? I would now have expected
> something like
It is correct for old commits, when you look at an old commit it
doesn't know that later it is merge in a subfolder. For new commits it
depends on how you made them, in the modules and doing a subtree merge
or directly in the "superproject".
Santi
>
> commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> Author: H.M. Brand <merijn@a5.(none)>
> Date: Tue Jul 29 16:45:43 2008 +0200
>
> Backward comp functie voor PV indicatie
>
> diff --git a/include/fnc_declare.h b/include/fnc_declare.h
> index acd686c..25d9a73 100644
> --- a/include/fnc_declare.h
> +++ b/include/fnc_declare.h
> @@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
> eaf_N pv_datum ($x1, $x2, $x3);
> #endif
>
> +#ifndef PV_INDICATIE
> +#define PV_INDICATIE
> +eaf_S pv_indicatie ($x1);
> +#endif
> +
> #undef eaf_B
> #undef eaf_N
> #undef eaf_S
>
> --
> H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
> using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
> 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
> http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
> http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
>
^ 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