* 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
* Re: Git vs Monotone
From: David Kastrup @ 2008-08-01 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 31 Jul 2008, Craig L. Ching wrote:
>>
>> It's possible he's doing that, but it's also possible he just isn't that
>> familiar with git.
>
> Possible. But it really sounded like he didn't even try. Because quite
> frankly, if he had even bothered to _try_, he wouldn't have gotten the
> numbers he got.
>
> The fact is, even without "-s", a local clone will do hardlinks for the
> database.
That means that git takes up less disk space. It does not mean that it
looks like it.
If you do a df before and afterwards, you'll notice (but that does not
seem reliable as other changed might happen in the file system). If you
do "du" into the individual clones, you won't notice it.
It is quite plausible that he might have tried it, but misinterpreted
the results.
It is a similar situation with size estimates when sparse files are
involved: they may take up less space than what it looks like.
--
David Kastrup
^ permalink raw reply
* Re: StGit: kha/{stable,safe,experimental} updated
From: Karl Hasselström @ 2008-08-01 10:22 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Samuel Tardieu
In-Reply-To: <b0943d9e0807270144n359e5bd3ye3e91c52b8fa7beb@mail.gmail.com>
On 2008-07-27 09:44:31 +0100, Catalin Marinas wrote:
> 2008/7/25 Karl Hasselström <kha@treskal.com>:
>
> > The big update since last time is support (in kha/experimental) for
> > hidden patches in the new-infrastructure commands and stack log.
>
> I'll have a look at the new stack log format (my main worry) this
> week but the other patches look OK.
Heh. It's _always_ your main worry. But rightly so, since mistakes
could be costly. Thanks for spending time on this with me.
I made one change apart from adding the hidden patches: use the same
tree for both the full and simplified logs. It's no more costly to
write, and made the parsing substantially simpler.
> I merged the safe and stable branches.
Thanks.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-08-01 10:19 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Stephan Beyer, git, Johannes Schindelin,
Julian Phillips, Scott Chacon, Petr Baudis
In-Reply-To: <200808011146.29883.trast@student.ethz.ch>
Thomas Rast wrote:
> 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
>
Right, quote is a special case in lyx format because we have to take
care of locale differences. So, as you guessed, quotes are not really
written with the ascii quote character. But the format is not that hard
in general. If needed, I could modify this special case so that it's
easier to read though.
Don't get me wrong, I don't pretend that LyX is easy to read for the
untrained eyes, it is not. But simple modifications like Junio's example
is definitely possible. For non simple text insertion, it is better to
launch LyX and to type the modification within LyX. But maybe this is a
showstopper for you, and so is maybe our treatment of quotes. In which
case I'll stop arguying :-)
Abdel.
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-08-01 10:35 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160808010252j540a28cdw6e48027396da5248@mail.gmail.com>
On Fri, 1 Aug 2008 11:52:08 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> 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);
> > :
> >
> > 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".
After we join/merge these into the super-project, we're going to remove
the sup-repos, so all new commits will be made in the super-repo.
What I'm a bit worried about is that if people are looking for a change
in "include/inih001.h", they will not be able to find the commits on
that path, as the old commits have stored it without the path element.
Will that be a problem, or is git/gitk clever enough to still find
commits to both?
--
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: markdown 2 man, was Re: Git Community Book
From: Dmitry Potapov @ 2008-08-01 10:45 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: Jan Krüger, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <4892C042.20302@lyx.org>
On Fri, Aug 1, 2008 at 11:50 AM, Abdelrazak Younes <younes@lyx.org> wrote:
>
> AsciiDoc is indeed excellent if you want to write in a plain text editor.
> But LyX is easier to use and more porwerful :-)
What is really powerful is TeX. As to LyX, it is leaky abstraction over it.
I have never been able to use without ending up saying, it is so much easier
and much more powerful to use Latex than trying to do the same with LyX. Of
course, LyX looks much better nowadays than used to be, so I decided to give
it another try, and here is my fifteen minutes experience with it.
First, I tried to open FAQ.lyx that you attached to your previous email, and
here is what I see:
===
/tmp/FAW.lix is from a different version of LyX, but the lex2lex script failed
to covert it.
===
This is result was received with two LyX versions that I tried:
LyX Version 1.4.3 (21/09/2006)
LyX 1.5.5 (Sun, May 11, 2008)
Now, I see, that your FAQ was created with LyX 1.6.0svn, which is not released
yet. So, I hope that this issue will be correctly before it will be released.
Otherwise, anyone opening document with 1.6.0 will make it unaccessible to users
of previous versions.
Then I tried to use Formatted reference and everything looks okay until I tried
to generate DVI file, where I was welcome but the following error:
===
Paragraph ended before \@prettyref was complete.
===
What is \@prettyref? What is wrong with my paragraph? Actually, my paragraph is
fine, it is just when you use Formatted reference, you should know that it is
implemented using prettyref TeX package, which requires three letter prefix in
name of each label. Why did not LyX warn me about that? BTW, is really prettyref
is the best package for this job anyway? I remember some TeX experts recommended
some other packages for references.
Finally, I still have not figured out how to the same what AsciiDoc does:
Chapter #, $CHAPTER_NAME
It does not look like that LyX can produce references in this format.
The I tried to insert some verbatim text, and I cannot find the standard way
to do that in LyX. Sure, I can press CTRL-L and type in TeX:
\begin{verbatim}
# git itself (approx. 10MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
# the linux kernel (approx. 150MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
\end{verbatim}
but I don't think that having a lot TeX code is going to help us with
having good formatted HTML version.
BTW, it is really annoying to see TeX code displayed in proportional
fonts and formatted with full adjustment. For instance, the last line
was displayed like this:
$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Another rather surprising experience for those who got used to HTML:
Left-click on a reference produces its properties, while the right
click means to go to the label, and once you jump on it, there is
no way to jump back (at least, I was not able to find how to do that).
Well, I wrote all above only because I hope that LyX will continue to
improve. It looks much better now than before. Yet, I will rather stay
with plain text editors for now. Some of them are much more powerful
than Notepad :)
Dmitry
^ permalink raw reply
* Re: [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Johannes Schindelin @ 2008-08-01 10:57 UTC (permalink / raw)
To: Junio C Hamano, spearce; +Cc: Pieter de Bie, Git Mailinglist
In-Reply-To: <7vtze5td00.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 1 Aug 2008, Junio C Hamano wrote:
> 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.
... who let's Shawn 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?
No.
Ciao,
Dscho
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-08-01 11:06 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Jan Krüger, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <37fcd2780808010345l755b83a5gff8a5aa350016ad5@mail.gmail.com>
Hi Dimitry,
Dmitry Potapov wrote:
> On Fri, Aug 1, 2008 at 11:50 AM, Abdelrazak Younes <younes@lyx.org>
> wrote:
> > AsciiDoc is indeed excellent if you want to write in a plain text
> > editor. But LyX is easier to use and more porwerful :-)
>
> What is really powerful is TeX. As to LyX, it is leaky abstraction
> over it. I have never been able to use without ending up saying, it
> is so much easier and much more powerful to use Latex than trying to
> do the same with LyX. Of course, LyX looks much better nowadays than
> used to be, so I decided to give it another try, and here is my
> fifteen minutes experience with it.
I was afraid this thread will turn into a pro and con of LyX versus
plain LateX :-)
> First, I tried to open FAQ.lyx that you attached to your previous
> email, and here is what I see:
...
> Now, I see, that your FAQ was created with LyX 1.6.0svn, which is not
> released yet. So, I hope that this issue will be correctly before it
> will be released.
Of course. Sorry, as I use the pre-release I didn't think that about
that. FYI, we will release one last version of 1.5.x that is able to
read 1.6 format. 1.6 will is of course able to read all previous format.
> Otherwise, anyone opening document with 1.6.0 will make it
> unaccessible to users of previous versions.
>
> Then I tried to use Formatted reference and everything looks okay
> until I tried to generate DVI file, where I was welcome but the
> following error: === Paragraph ended before \@prettyref was
> complete. ===
>
> What is \@prettyref? What is wrong with my paragraph? Actually, my
> paragraph is fine, it is just when you use Formatted reference, you
> should know that it is implemented using prettyref TeX package, which
> requires three letter prefix in name of each label. Why did not LyX
> warn me about that? BTW, is really prettyref is the best package for
> this job anyway? I remember some TeX experts recommended some other
> packages for references.
Aha, yes you're right. LyX will automatically insert those three letters
(eg. 'cha' for chapter). This is the reason why I never came across this
bug. We'll try to fix that, thanks!
>
> Finally, I still have not figured out how to the same what AsciiDoc
> does: Chapter #, $CHAPTER_NAME It does not look like that LyX can
> produce references in this format.
You can choose among a number of document class. If you want the
"Chapter" prefixing, choose the 'Book' document class. The default,
document class is 'Article', for with you don't have level 1 sections.
> The I tried to insert some verbatim text, and I cannot find the
> standard way to do that in LyX.
There are at least two:
- The LyX-code environment
- The listing inset
The listing inset supports a number of languages so you'll be able to
have syntax highlighting and cloring for your language of choice.
> Sure, I can press CTRL-L and type in
> TeX: \begin{verbatim} # git itself (approx. 10MB download): $ git
> clone git://git.kernel.org/pub/scm/git/git.git # the linux kernel
> (approx. 150MB download): $ git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> \end{verbatim}
>
> but I don't think that having a lot TeX code is going to help us
> with having good formatted HTML version.
No, either LyX-code (To choose from the Layout combo box) or preferable
the Listing inset (Menu Insert -> Program Listing). Of course, all these
action have keyboard shortcuts.
>
> BTW, it is really annoying to see TeX code displayed in proportional
> fonts and formatted with full adjustment. For instance, the last
> line was displayed like this:
>
> $ git
> clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Yes I know, this will be better in 1.6 due out this month in principle.
> Another rather surprising experience for those who got used to HTML:
> Left-click on a reference produces its properties, while the right
> click means to go to the label, and once you jump on it, there is no
> way to jump back (at least, I was not able to find how to do that).
There is one 'Ctrl-0' but this is more or less hidden feature. 1.6 will
have context menu so all the above actions will be a lot more consistant
and easier.
> Well, I wrote all above only because I hope that LyX will continue
> to improve. It looks much better now than before.
Thanks for the comments :-)
> Yet, I will rather
> stay with plain text editors for now. Some of them are much more
> powerful than Notepad :)
It's a matter of choice. I have to confess that I don't use plain text
editor anymore because I am so used to LyX keybindings.
Thanks,
Abdel.
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-08-01 11:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Potapov, git, Eric Wong
In-Reply-To: <7vbq0dtawp.fsf@gitster.siamese.dyndns.org>
> 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.
Sorry I have lost the mind flow here.
1. We 'fetch' files from svn as is. Yes, we know that svn use delta to rebuild
original file.
2. We commit file to git. Right here we use git-hash-object. As I understand
we _have_ to do convertion CRLF->LF here.
3. In some days we will checkout file from git and wil do LF->CRLF convertion.
I thought this is a right workflow.
- We could store original file too at step 2 somwhow to be able to use delta
at step 1.
- We can't skip convertion at step 2. Overwise git will store files with CRLF.
Am I wrong ?
^ permalink raw reply
* [PATCH] builtin-name-rev: refactor stdin handling to its own function
From: Pieter de Bie @ 2008-08-01 11:16 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Git Mailinglist
Cc: Pieter de Bie
In-Reply-To: <alpine.DEB.1.00.0808011256330.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
---
On 1 aug 2008, at 09:23, Junio C Hamano wrote:
>Is it just me to find that this part is getting indented too deeply to be
>readable?
How about something like this then?
builtin-name-rev.c | 93 ++++++++++++++++++++++++++++------------------------
1 files changed, 50 insertions(+), 43 deletions(-)
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index 0536af4..057172d 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -176,6 +176,52 @@ static char const * const name_rev_usage[] = {
NULL
};
+static void handle_stdin_line(char *p_start, int name_only)
+{
+ int forty = 0;
+ char *p;
+ for (p = p_start; *p; p++) {
+#define ishex(x) (isdigit((x)) || ((x) >= 'a' && (x) <= 'f'))
+ if (!ishex(*p))
+ forty = 0;
+ else if (++forty == 40 && !ishex(*(p+1))) {
+ unsigned char sha1[40];
+ const char *name = NULL;
+ char c = *(p+1);
+
+ forty = 0;
+
+ *(p+1) = 0;
+ if (!get_sha1(p - 39, sha1)) {
+ struct object *o =
+ lookup_object(sha1);
+ if (o)
+ name = get_rev_name(o);
+ }
+ *(p+1) = c;
+
+ if (!name)
+ continue;
+
+ if (name_only) {
+ fwrite(p_start, p - p_start + 1 - 40,
+ 1, stdout);sssss
+ printf(name);
+ }
+ else {
+ fwrite(p_start, p - p_start + 1, 1, stdout);
+ printf(" (%s)", name);
+ }
+ p_start = p + 1;
+ }
+ }
+
+ /* flush */
+ if (p != p_start)
+ fwrite(p_start, p - p_start, 1, stdout);
+
+}
+
int cmd_name_rev(int argc, const char **argv, const char *prefix)
{
struct object_array revs = { 0, 0, NULL };
@@ -234,53 +280,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
if (transform_stdin) {
char buffer[2048];
- char *p, *p_start;
+ char *p_start;
while (!feof(stdin)) {
- int forty = 0;
- p = fgets(buffer, sizeof(buffer), stdin);
- if (!p)
+ p_start = fgets(buffer, sizeof(buffer), stdin);
+ if (!p_start)
break;
- for (p_start = p; *p; p++) {
-#define ishex(x) (isdigit((x)) || ((x) >= 'a' && (x) <= 'f'))
- if (!ishex(*p))
- forty = 0;
- else if (++forty == 40 &&
- !ishex(*(p+1))) {
- unsigned char sha1[40];
- const char *name = NULL;
- char c = *(p+1);
-
- forty = 0;
-
- *(p+1) = 0;
- if (!get_sha1(p - 39, sha1)) {
- struct object *o =
- lookup_object(sha1);
- if (o)
- name = get_rev_name(o);
- }
- *(p+1) = c;
-
- if (!name)
- continue;
-
- 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;
- }
- }
-
- /* flush */
- if (p_start != p)
- fwrite(p_start, p - p_start, 1, stdout);
+ handle_stdin_line(p_start, data.name_only);
}
} else if (all) {
int i, max;
--
1.6.0.rc1.214.g5f0bd
^ permalink raw reply related
* Filtering mode changes
From: Stefan Naewe @ 2008-08-01 11:25 UTC (permalink / raw)
To: git
Hi there.
Here's my story:
- I did some minor modifications to a repo that I want to 'give back'.
- I worked on my own branch (of course).
- I was stupid to edit the files (that live on a linux box) through a windows
network share.
- When I created diffs (using 'git format-patch') to send send 'upstream', I
noticed that the edited files got their executable bit set (old mode 100644 ->
new mode 100755)
- I created another commit to undo the mode changes.
My question:
Is there a way to create clean diffs (between master and my branch) that don't
contain the 'double mode change' (from 644 to 755 to 644) ?
TIA
Stefan
^ 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