* Pulling one commit at a time.
From: Sanjiv Gupta @ 2009-08-23 16:48 UTC (permalink / raw)
To: git
In-Reply-To: <F536B7C316F9474E9F7091239725AC9A02FA7F44@CHN-CL-MAIL01.mchp-main.com>
Hi,
This is my first post here.
I just wanted to know how can I pull one commit at a time from public
repository.
e.g.
when I first cloned from the public repo, it was at X. now it
has reached Y. I just want to pull x+1.
how to do that?
In SVN, we can just do $ svn update -r next_rev_num
thanks
- Sanjiv
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Thell Fowler @ 2009-08-23 17:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7vvdkfx8rl.fsf@alter.siamese.dyndns.org>
Junio C Hamano (gitster@pobox.com) wrote on Aug 23, 2009:
> Thell Fowler <git@tbfowler.name> writes:
>
> > @@ -191,12 +191,14 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
> > int i1, i2;
> >
> > if (flags & XDF_IGNORE_WHITESPACE) {
> > - for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
> > + for (i1 = i2 = 0; i1 < s1 || i2 < s2; ) {
> > if (isspace(l1[i1]))
> > - while (isspace(l1[i1]) && i1 < s1)
> > + while ((isspace(l1[i1]) && i1 < s1)
> > + || (i1 + 1 == s1 && l1[s1] != '\n'))
>
> This is wrong. If you ran out l1/s1/i1 but you still have remaining
> characters in l2/s2/i2, you do not want to even look at l1[i1].
>
> You can fudge this by sprinkling more "(i1 < s1) &&" in many places (and
> reordering how your inner while() loop checks (i1 < s1) and l1[i1]), but I
> do not think that is the right direction.
>
> The thing is, the loop control in this function is extremely hard to read
> to begin with, and now it is "if we haven't run out both", the complexity
> seeps into the inner logic.
>
I see what you're saying here and your absolutely right. Good thing you
didn't write a critique of the XDF_IGNORE_WHITESPACE_CHANGE case. ;)
> How about doing it like this patch instead? This counterproposal replaces
> your 3 patches starting from [3/6].
[...snip...]
> The basic idea of the re-written logic is this.
>
> - An initial loop runs while the characters from both strings we are
> looking at match. We declare unmatch immediately when we find
> something that does not match and return false from the loop. And we
> break out of the loop if we ran out of either side of the string.
>
> The way we skip spaces inside this loop varies depending on the style
> of ignoring whitespaces.
>
> - After the loop, the lines can match only if the remainder consists of
> nothing but whitespaces. This part of the logic is shared across all
> three styles.
>
> The new code is more obvious and should be much easier to follow.
Because the flow is much more direct it also makes the test additions to
t4015 obsolete as they essentially tested for line end conditions instead
of whitespace (like they should have).
[...clip...]
> + /*
> + * If we do not want -b to imply --ignore-space-at-eol
> + * then you would need to add this:
> + *
> + * if (!(flags & XDF_IGNORE_WHITESPACE_AT_EOL))
> + * return (s1 <= i1 && s2 <= i2);
> + *
> + */
> +
While it would be nice to have -b and --ignore-space-at-eol be two
different options that could be merged together the documentation states
that -b ignores spaces at eol, and there are scripts that depend on this
behavior.
IMHO it is wrong to accept that new spaces where none existed before is
akin to having one or more existing spaces coalesced. I seem to recall
reading something about 1.7 having some changes in it that wouldn't be
backward compatible; perhaps -b and --ignore-space-at-eol could be
distinct options for that release.
On another item:
Right now the xdl_recmatch() checks three distinct flags before having the
opportunity to do the default behavior of a straight diff. In
xdl_hash_record there is an initial check for whitespace flags.
...
if (flags & XDF_WHITESPACE_FLAGS)
return xdl_hash_record_with_whitespace(data, top, flags);
...
Perhaps a similar setup for xdl_rematch() and a
xdl_recmatch_with_whitespace() ?
Lastly:
Since your to counter-proposals give the same results, provide safer and
faster processing, eliminate the additional test, as well as being easier
to read and comprehend I propose a v3 with just those two patches. I'll
be glad to post it, with or without a xdl_recmatch_with_whitespace, if
need be. And should I, or do I need to, add something to the commit (ie:
ack, tested, ...) ?
Thank you again for taking the time to look at this change!
--
Thell
^ permalink raw reply
* Re: [PATCH-v2/RFC 2/6] xutils: fix hash with whitespace on incomplete line
From: Thell Fowler @ 2009-08-23 17:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7veir3ynma.fsf@alter.siamese.dyndns.org>
Junio C Hamano (gitster@pobox.com) wrote on Aug 23, 2009:
> Thell Fowler <git@tbfowler.name> writes:
>
> > - Make xdl_hash_record_with_whitespace stop hashing before the
> > eof when ignoring space change or space at eol on an incomplete
> > line.
> >
> > Resolves issue with a final trailing space being included in the
> > hash on an incomplete line by treating the eof in the same fashion
> > as a newline.
>
> Please study the style of existing commit messages and imitate them.
>
I'll keep trying.
> > Signed-off-by: Thell Fowler <git@tbfowler.name>
> > ---
> > xdiff/xutils.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/xdiff/xutils.c b/xdiff/xutils.c
> > index 04ad468..c6512a5 100644
> > --- a/xdiff/xutils.c
> > +++ b/xdiff/xutils.c
> > @@ -248,12 +248,12 @@ static unsigned long xdl_hash_record_with_whitespace(char const **data,
> > if (flags & XDF_IGNORE_WHITESPACE)
> > ; /* already handled */
> > else if (flags & XDF_IGNORE_WHITESPACE_CHANGE
> > - && ptr[1] != '\n') {
> > + && ptr[1] != '\n' && ptr + 1 < top) {
> > ha += (ha << 5);
> > ha ^= (unsigned long) ' ';
> > }
> > else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
> > - && ptr[1] != '\n') {
> > + && ptr[1] != '\n' && ptr + 1 < top) {
> > while (ptr2 != ptr + 1) {
> > ha += (ha << 5);
> > ha ^= (unsigned long) *ptr2;
>
> Thanks.
>
> The issue you identified and tried to fix is a worthy one. But before the
> pre-context of this hunk, I notice these lines:
>
> if (isspace(*ptr)) {
> const char *ptr2 = ptr;
> while (ptr + 1 < top && isspace(ptr[1])
> && ptr[1] != '\n')
> ptr++;
>
> If you have trailing whitespaces on an incomplete line, ptr initially
> points at the first such whitespace, ptr2 points at the same location, and
> then the while() loop advances ptr to point at the last byte on the line,
> which in turn will be the last byte of the file. And the codepath with
> your updates still try to access ptr[1] that is beyond that last byte.
>
> I would write it like this patch instead.
>
> The intent is the same as your patch, but it avoids accessing ptr[1] when
> that is beyond the end of the buffer, and the logic is easier to follow as
> well.
>
I appreciate your taking the time to look at the issue and explaining the
reasons for your change.
> -- >8 --
> Subject: xutils: fix hashing an incomplete line with whitespaces at the end
>
> Upon seeing a whitespace, xdl_hash_record_with_whitespace() first skipped
> the run of whitespaces (excluding LF) that begins there, ensuring that the
> pointer points the last whitespace character in the run, and assumed that
> the next character must be LF at the end of the line. This does not work
> when hashing an incomplete line, that lacks the LF at the end.
>
> Introduce "at_eol" variable that is true when either we are at the end of
> line (looking at LF) or at the end of an incomplete line, and use that
> instead throughout the code.
>
> Noticed by Thell Fowler.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Yeah... comparing this commit message to the original shows a pretty stark
difference. I'll get it 'the git way' eventually.
--
Thell
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Reece Dunn @ 2009-08-23 18:22 UTC (permalink / raw)
To: Thiago Farina
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <a4c8a6d00908230926of0ea10bhd8f66e7d37c3b39b@mail.gmail.com>
2009/8/23 Thiago Farina <tfransosi@gmail.com>:
> Hi,
>
> On Fri, Aug 21, 2009 at 10:30 AM, Marius Storm-Olsen<mstormo@gmail.com> wrote:
>> From: Frank Li <lznuaa@gmail.com>
>>
>> +3. Open gitbuild\gitbuild.sln with VS2008. Then press F7.
> F7 does nothing in VS2008, to build the solution you have to press
> Ctrl+Shift+B. To build and start debugging you have to press F5, and
> for start without debbuging support is Ctrl+F5.
IIRC, Visual Studio can be configured to use different keyboard shortcuts.
However, saying "press F7" says nothing of the intent. It would
probably be better to have this say something like "Then build the
solution." or "Open gitbuild\gitbuild.sln with Visual Studio 2008,
then build it." But then you don't need to open Visual Studio 2008 to
build it (you can build it from command line).
So, how about:
3. You can now build git with Visual Studio 2008 using the
gitbuild\gitbuild.sln file.
- Reece
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Marius Storm-Olsen @ 2009-08-23 18:59 UTC (permalink / raw)
To: Reece Dunn; +Cc: Thiago Farina, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <3f4fd2640908231122m34604196pc98c5871cf5925b5@mail.gmail.com>
Reece Dunn said the following on 23.08.2009 20:22:
> 2009/8/23 Thiago Farina <tfransosi@gmail.com>:
>> Hi,
>>
>> On Fri, Aug 21, 2009 at 10:30 AM, Marius Storm-Olsen<mstormo@gmail.com> wrote:
>>> From: Frank Li <lznuaa@gmail.com>
>>>
>>> +3. Open gitbuild\gitbuild.sln with VS2008. Then press F7.
>> F7 does nothing in VS2008, to build the solution you have to press
>> Ctrl+Shift+B. To build and start debugging you have to press F5, and
>> for start without debbuging support is Ctrl+F5.
>
> IIRC, Visual Studio can be configured to use different keyboard shortcuts.
>
> However, saying "press F7" says nothing of the intent. It would
> probably be better to have this say something like "Then build the
> solution." or "Open gitbuild\gitbuild.sln with Visual Studio 2008,
> then build it." But then you don't need to open Visual Studio 2008 to
> build it (you can build it from command line).
>
> So, how about:
> 3. You can now build git with Visual Studio 2008 using the
> gitbuild\gitbuild.sln file.
>
> - Reece
Agreed.
Thanks guys.
--
.marius
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Thiago Farina @ 2009-08-23 19:29 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Reece Dunn, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <4A91917F.9000709@gmail.com>
Marius, how common-cmds.h will be generated? In the header file says
that it's generated by generate-cmdlist.sh, so the VS user will need
to generate this file first (before compiling)?
When I tried to compile after pulling from the repository, I couldn't,
so I copied it from the the msysgit.
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Junio C Hamano @ 2009-08-23 19:40 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Johannes.Schindelin
In-Reply-To: <alpine.DEB.2.00.0908231110500.29625@GWPortableVCS>
Thell Fowler <git@tbfowler.name> writes:
> Because the flow is much more direct it also makes the test additions to
> t4015 obsolete as they essentially tested for line end conditions instead
> of whitespace (like they should have).
Your patch 6/6 that added the tests were useful to find a bug I originally
had, which is the one below that is commented out.
>> + /*
>> + * If we do not want -b to imply --ignore-space-at-eol
>> + * then you would need to add this:
>> + *
>> + * if (!(flags & XDF_IGNORE_WHITESPACE_AT_EOL))
>> + * return (s1 <= i1 && s2 <= i2);
>> + *
>> + */
>> +
>
> While it would be nice to have -b and --ignore-space-at-eol be two
> different options that could be merged together the documentation states
> that -b ignores spaces at eol, and there are scripts that depend on this
> behavior.
Also that is how "diff -b" behaves, and that is why I said your tests
found a _bug_ in my original. I'll drop the above large comment and
replace it with just a "/* -b implies --ignore-space-at-eol */".
> Right now the xdl_recmatch() checks three distinct flags before having the
> opportunity to do the default behavior of a straight diff. In
> xdl_hash_record there is an initial check for whitespace flags.
>
> ...
> if (flags & XDF_WHITESPACE_FLAGS)
> return xdl_hash_record_with_whitespace(data, top, flags);
> ...
>
> Perhaps a similar setup for xdl_rematch() and a
> xdl_recmatch_with_whitespace() ?
Or we can just move the final else clause up and start the function like
this:
int i1, i2;
if (!(flags & XDF_WHITESPACE_FLAGS))
return s1 == s2 && !memcmp(l1, l2, s1);
i1 = i2 = 0;
if (flags & XDF_IGNORE_WHITESPACE) {
...
that would get rid of two unnecessary clearing of variables (i1 and i2,
even though I suspect that the compiler _could_ optimize them out without
such an change), and three flags-bit check in the most common case of not
ignoring any whitespaces.
> Since your to counter-proposals give the same results, provide safer and
> faster processing, eliminate the additional test, as well as being easier
> to read and comprehend I propose a v3 with just those two patches. I'll
> be glad to post it, with or without a xdl_recmatch_with_whitespace, if
> need be. And should I, or do I need to, add something to the commit (ie:
> ack, tested, ...) ?
I can amend the counterproposal patches with tests from your 6/6 and add
your "Tested-by:" and commit them myself.
> Thank you again for taking the time to look at this change!
Thank _you_ for bringing this issue up in the first place.
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Alex Riesen @ 2009-08-23 20:11 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: git
In-Reply-To: <4A9172D0.6030507@microchip.com>
On Sun, Aug 23, 2009 at 18:48, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:
> when I first cloned from the public repo, it was at X. now it has reached Y.
> I just want to pull x+1.
>
> how to do that?
Depending on what you mean, it maybe either the what Git already
does (a git fetch/git pull always transmits only the differences) or a
security risk and impossible (an ability to fetch an arbitrary commit
bypasses checks imposed by the reference names published).
^ permalink raw reply
* Re: [PATCH] gitweb: pull ref markes pull out of subject <a> tag
From: Jakub Narebski @ 2009-08-23 20:13 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1251016089-10548-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 23 Aug 2009, Giuseppe Bilotta wrote:
> Since 4afbaefffa9095fe1391b4b61289a7dc954e9f7b ref markers that
> accompain the subject in views such as shortlog and history point to
> something different from the subject itself. Therefore, they should not
> be included in the same <a> tag.
>
> Benefits of the change are:
> * better compliance to the XHTML standards, that forbid links within
> links even though the restriction cannot be imposed via DTD; this also
> benefits visualization in some older browsers;
Yes, some older browsers (like Mozilla 1.7.12, Gecko/20050923) did
_enforce_ that requirement when served document with XHTML DOCTYPE,
and application/xml+xhtml Content-Type, by moving inner link (A element)
just outside (just after) outer, containing <a> element.
For format_subject_html which you are fixing, and which is used by
'shortlog', 'history' and 'tags' views this didn't cause much changes
in layout. But the way gitweb uses git_print_header_div in views such
as 'tree', 'blob' etc., where the outer (containing) link is made into
*block* element[1] by the way of CSS (display: block) makes layout
(visualisation) very screwed up in older browser. But I don't expect
you to fix that.
[1] Originally so the area to click is larger.
> * when hovering the subject, only the subject itself is underlined; when
> hovering the ref markers, only the text in the hovered ref marker is
> underlined; previously, hovering any written part of the subject
> column led to complete underlying of everything at the same time,
> with unpleasing effects.
Signoff?
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> The next step would be to find a way to layout decently the case when
> some shortlog entries have a _humongous_ amount of ref markers. See
> for example http://git.oblomov.eu/acecad/shortlog
>
> I honestly doubt these cases happen in normal git repositories, but it
> might still be worth taking them into consideration. Possibilities
> include hard-limiting the title column maximum width (in browsers for
> which the corresponding attributes and rules work), manual insertion of
> hard line breaks <br/> every n-th ref marker, or something more dynamic
> such as hiding most of the ref markers when they are more than, say, 5,
> and showing them on hover.
>
> Suggestions? Comments?
Perhaps limiting to heads and tags if there are too many refs?
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index ce6e8f6..bb9648b 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1524,10 +1524,10 @@ sub format_subject_html {
> $long =~ s/[[:cntrl:]]/?/g;
> return $cgi->a({-href => $href, -class => "list subject",
> -title => to_utf8($long)},
> - esc_html($short) . $extra);
> + esc_html($short)) . $extra;
> } else {
> return $cgi->a({-href => $href, -class => "list subject"},
> - esc_html($long) . $extra);
> + esc_html($long)) . $extra;
> }
> }
>
> --
> 1.6.3.rc1.192.gdbfcb
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Add script for importing bits-and-pieces to Git.
From: Peter Krefting @ 2009-08-23 20:11 UTC (permalink / raw)
To: git
Allows the user to import version history that is stored in bits and
pieces in the file system, for instance snapshots of old development
trees, or day-by-day backups. A configuration file is used to
describe the relationship between the different files and allow
describing branches and merges, as well as authorship and commit
messages.
Output is created in a format compatible with git-fast-import.
Full documentation is provided inline in perldoc format.
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
---
I used this to import a couple of projects which had history that
was too complex for import-tars or import-zips. The configuration
file language for this script allow creation of both branches and
merges.
contrib/fast-import/import-directories.perl | 333 +++++++++++++++++++++++++++
1 files changed, 333 insertions(+), 0 deletions(-)
create mode 100755 contrib/fast-import/import-directories.perl
diff --git a/contrib/fast-import/import-directories.perl b/contrib/fast-import/import-directories.perl
new file mode 100755
index 0000000..1f5ea07
--- /dev/null
+++ b/contrib/fast-import/import-directories.perl
@@ -0,0 +1,333 @@
+#!/usr/bin/perl -w
+#
+# Copyright 2008-2009 Peter Krefting <peter@softwolves.pp.se>
+#
+# ------------------------------------------------------------------------
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+#
+# ------------------------------------------------------------------------
+
+=pod
+
+=head1 NAME
+
+import-directories - Import bits and pieces to Git.
+
+=head1 SYNOPSIS
+
+B<import-directories.perl> F<configfile>
+
+=head1 DESCRIPTION
+
+Script to import arbitrary projects version controlled by the "copy the
+source directory to a new location and edit it there"-version controlled
+projects into version control. Handles projects with arbitrary branching
+and version trees, taking a file describing the inputs and generating a
+file compatible with the L<git-fast-import(1)> format.
+
+=head1 CONFIGURATION FILE
+
+=head2 Format
+
+The configuration file is using a standard I<.ini> format.
+
+ ; Comments start with semi-colons
+ [section]
+ key=value
+
+=head2 Global configuration
+
+Global configuration is done in the B<[config]> section, which should be
+the first section in the file. Configuration can be changed by
+repeating configuration sections later on.
+
+ [config]
+ ; configure conversion of CRLFs. "convert" means that all CRLFs
+ ; should be converted into LFs (suitable for the core.autocrlf
+ ; setting set to true in Git). "none" means that all data is
+ ; treated as binary.
+ crlf=convert
+
+=head2 Revision configuration
+
+Each revision that is to be imported is described in three
+sections. Sections should be defined chronologically, so that a
+revision's parent has always been defined when a new revision
+is introduced. All sections for one revision should be defined
+before defining the next revision.
+
+Revisions are specified numerically, but they numbers need not be
+consecutive, only unique.
+
+=pod
+
+=head3 Revision description section
+
+A section whose section name is just an integer gives meta-data
+about the revision.
+
+ [3]
+ ; author sets the author of the revisions
+ author=Peter Krefting <peter@softwolves.pp.se>
+ ; branch sets the branch that the revision should be committed to
+ branch=master
+ ; parent describes the revision that is the parent of this commit
+ ; (optional)
+ parent=1
+ ; merges describes a revision that is merged into this commit
+ ; (optional; can be repeated)
+ merges=2
+ ; selects one file to take the timestamp from
+ ; (optional; if unspecified, the most recent file from the .files
+ ; section is used)
+ timestamp=3/source.c
+
+=head3 Revision contents section
+
+A section whose section name is an integer followed by B<.files>
+describes the files included in this revision.
+
+ [3.files]
+ ; the key is the path inside the repository, the value is the path
+ ; as seen from the importer script.
+ source.c=3/source.c
+ source.h=3/source.h
+
+=head3 Revision commit message section
+
+A section whose section name is an integer followed by B<.message>
+gives the commit message. This section is read verbatim.
+
+ [3.message]
+ Implement foobar.
+ ; trailing blank lines are ignored.
+
+=cut
+
+# Globals
+use strict;
+use integer;
+my $crlfmode = 0;
+my @revs;
+my (%revmap, %message, %files, %author, %branch, %parent, %merges, %time, %timesource);
+my $sectiontype = 0;
+my $rev = 0;
+my $mark = 1;
+
+# Check command line
+if ($#ARGV == -1 || $ARGV[0] =~ /^--?h/)
+{
+ exec('perldoc', $0);
+ exit 1;
+}
+
+# Open configuration
+my $config = $ARGV[0];
+open CFG, '<', $config or die "Cannot open configuration file \"$config\": ";
+
+# Open output
+my $output = $ARGV[1];
+open OUT, '>', $output or die "Cannot create output file \"$output\": ";
+binmode OUT;
+
+LINE: while (my $line = <CFG>)
+{
+ $line =~ s/\r?\n$//;
+ next LINE if $sectiontype != 4 && $line eq '';
+ next LINE if $line =~ /^;/;
+ my $oldsectiontype = $sectiontype;
+ my $oldrev = $rev;
+
+ # Sections
+ if ($line =~ m"^\[(config|(\d+)(|\.files|\.message))\]$")
+ {
+ if ($1 eq 'config')
+ {
+ $sectiontype = 1;
+ }
+ elsif ($3 eq '')
+ {
+ $sectiontype = 2;
+ $rev = $2;
+ # Create a new revision
+ die "Duplicate rev: $line\n " if defined $revmap{$rev};
+ print "Reading revision $rev\n";
+ push @revs, $rev;
+ $revmap{$rev} = $mark ++;
+ $time{$revmap{$rev}} = 0;
+ }
+ elsif ($3 eq '.files')
+ {
+ $sectiontype = 3;
+ $rev = $2;
+ die "Revision mismatch: $line\n " unless $rev == $oldrev;
+ }
+ elsif ($3 eq '.message')
+ {
+ $sectiontype = 4;
+ $rev = $2;
+ die "Revision mismatch: $line\n " unless $rev == $oldrev;
+ }
+ else
+ {
+ die "Internal parse error: $line\n ";
+ }
+ next LINE;
+ }
+
+ # Parse data
+ if ($sectiontype != 4)
+ {
+ # Key and value
+ if ($line =~ m"^(.*)=(.*)$")
+ {
+ my ($key, $value) = ($1, $2);
+ # Global configuration
+ if (1 == $sectiontype)
+ {
+ if ($key eq 'crlf')
+ {
+ $crlfmode = 1, next LINE if $value eq 'convert';
+ $crlfmode = 0, next LINE if $value eq 'none';
+ }
+ die "Unknown configuration option: $line\n ";
+ }
+ # Revision specification
+ if (2 == $sectiontype)
+ {
+ my $current = $revmap{$rev};
+ $author{$current} = $value, next LINE if $key eq 'author';
+ $branch{$current} = $value, next LINE if $key eq 'branch';
+ $parent{$current} = $value, next LINE if $key eq 'parent';
+ $timesource{$current} = $value, next LINE if $key eq 'timestamp';
+ push(@{$merges{$current}}, $value), next LINE if $key eq 'merges';
+ die "Unknown revision option: $line\n ";
+ }
+ # Filespecs
+ if (3 == $sectiontype)
+ {
+ # Add the file and create a marker
+ die "File not found: $line\n " unless -f $value;
+ my $current = $revmap{$rev};
+ ${$files{$current}}{$key} = $mark;
+ my $time = &fileblob($value, $crlfmode, $mark ++);
+
+ # Update revision timestamp if more recent than other
+ # files seen, or if this is the file we have selected
+ # to take the time stamp from using the "timestamp"
+ # directive.
+ if ((defined $timesource{$current} && $timesource{$current} eq $value)
+ || $time > $time{$current})
+ {
+ $time{$current} = $time;
+ }
+ }
+ }
+ else
+ {
+ die "Parse error: $line\n ";
+ }
+ }
+ else
+ {
+ # Commit message
+ my $current = $revmap{$rev};
+ if (defined $message{$current})
+ {
+ $message{$current} .= "\n";
+ }
+ $message{$current} .= $line;
+ }
+}
+close CFG;
+
+# Start spewing out data for git-fast-import
+foreach my $commit (@revs)
+{
+ # Progress
+ print OUT "progress Creating revision $commit\n";
+
+ # Create commit header
+ my $mark = $revmap{$commit};
+
+ # Branch and commit id
+ print OUT "commit refs/heads/", $branch{$mark}, "\nmark :", $mark, "\n";
+
+ # Author and timestamp
+ die "No timestamp defined for $commit (no files?)\n" unless defined $time{$mark};
+ print OUT "committer ", $author{$mark}, " ", $time{$mark}, " +0100\n";
+
+ # Commit message
+ die "No message defined for $commit\n" unless defined $message{$mark};
+ my $message = $message{$mark};
+ $message =~ s/\n$//; # Kill trailing empty line
+ print OUT "data ", length($message), "\n", $message, "\n";
+
+ # Parent and any merges
+ print OUT "from :", $revmap{$parent{$mark}}, "\n" if defined $parent{$mark};
+ if (defined $merges{$mark})
+ {
+ foreach my $merge (@{$merges{$mark}})
+ {
+ print OUT "merge :", $revmap{$merge}, "\n";
+ }
+ }
+
+ # Output file marks
+ print OUT "deleteall\n"; # start from scratch
+ foreach my $file (sort keys %{$files{$mark}})
+ {
+ print OUT "M 644 :", ${$files{$mark}}{$file}, " $file\n";
+ }
+ print OUT "\n";
+}
+
+# Create one file blob
+sub fileblob
+{
+ my ($filename, $crlfmode, $mark) = @_;
+
+ # Import the file
+ print OUT "progress Importing $filename\nblob\nmark :$mark\n";
+ open FILE, '<', $filename or die "Cannot read $filename\n ";
+ binmode FILE;
+ my (undef, undef, undef, undef, undef, undef,
+ undef, $size, undef, $time, undef, undef, undef) = stat FILE;
+ my $file;
+ read FILE, $file, $size;
+ close FILE;
+ $file =~ s/\r\n/\n/g if $crlfmode;
+ print OUT "data ", length($file), "\n", $file, "\n";
+
+ return $time;
+}
+
+__END__
+
+=pod
+
+=head1 EXAMPLES
+
+B<import-directories.perl> F<project.import>
+
+=head1 AUTHOR
+
+Copyright 2008-2009 Peter Krefting E<lt>peter@softwolves.pp.se>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation.
+
+=cut
--
1.6.3.3
^ permalink raw reply related
* Re: Pulling one commit at a time.
From: Sam Vilain @ 2009-08-23 20:19 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: git
In-Reply-To: <4A9172D0.6030507@microchip.com>
On Sun, 2009-08-23 at 22:18 +0530, Sanjiv Gupta wrote:
> Hi,
> This is my first post here.
> I just wanted to know how can I pull one commit at a time from public
> repository.
> e.g.
> when I first cloned from the public repo, it was at X. now it
> has reached Y. I just want to pull x+1.
>
> how to do that?
>
> In SVN, we can just do $ svn update -r next_rev_num
git pull or git pull --rebase
Why not find a tutorial or go through the user manual.
Sam
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Adam Brewster @ 2009-08-23 20:17 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: git
In-Reply-To: <4A9172D0.6030507@microchip.com>
On Sun, Aug 23, 2009 at 12:48 PM, Sanjiv
Gupta<sanjiv.gupta@microchip.com> wrote:
> Hi,
> This is my first post here.
> I just wanted to know how can I pull one commit at a time from public
> repository.
> e.g.
> when I first cloned from the public repo, it was at X. now it has reached Y.
> I just want to pull x+1.
>
> how to do that?
>
> In SVN, we can just do $ svn update -r next_rev_num
>
Git is a distributed system and handles branching much differently
than svn, so pull x+1 sounds like a funny request to git.
You could use `git fetch` to get the history from the remote
repository, then use `git log` or `gitk` to find the name of the
commit you're interested in, and use `git checkout` to switch to that
branch or `git merge` to merge the changes from the next commit into
your current branch.
Perhaps it would help if we knew why you only wanted to fetch one
commit at a time.
Adam
^ permalink raw reply
* Re: [PATCH] Add script for importing bits-and-pieces to Git.
From: Thomas Adam @ 2009-08-23 20:28 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <20090823201624.206F52FC20@perkele>
2009/8/23 Peter Krefting <peter@softwolves.pp.se>:
> + my (undef, undef, undef, undef, undef, undef,
> + undef, $size, undef, $time, undef, undef, undef) = stat FILE;
Minor nit. Better written as:
my ($size, $mtime) = (stat(FILE))[7,9];
-- Thomas Adam
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Thell Fowler @ 2009-08-23 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7vljlauxmk.fsf@alter.siamese.dyndns.org>
Junio C Hamano (gitster@pobox.com) wrote on Aug 23, 2009:
> Thell Fowler <git@tbfowler.name> writes:
>
> > Because the flow is much more direct it also makes the test additions to
> > t4015 obsolete as they essentially tested for line end conditions instead
> > of whitespace (like they should have).
>
> Your patch 6/6 that added the tests were useful to find a bug I originally
> had, which is the one below that is commented out.
>
That's good to hear!
> >> + /*
> >> + * If we do not want -b to imply --ignore-space-at-eol
> >> + * then you would need to add this:
> >> + *
> >> + * if (!(flags & XDF_IGNORE_WHITESPACE_AT_EOL))
> >> + * return (s1 <= i1 && s2 <= i2);
> >> + *
> >> + */
> >> +
> >
> > While it would be nice to have -b and --ignore-space-at-eol be two
> > different options that could be merged together the documentation states
> > that -b ignores spaces at eol, and there are scripts that depend on this
> > behavior.
>
> Also that is how "diff -b" behaves, and that is why I said your tests
> found a _bug_ in my original. I'll drop the above large comment and
> replace it with just a "/* -b implies --ignore-space-at-eol */".
>
In that case the only other outstanding issue to being able to use
patch-id to validate a whitespace fixed patch is diff's -B option to catch
the situations where the original has multiple blank newlines at the end
of file.
> > Right now the xdl_recmatch() checks three distinct flags before having the
> > opportunity to do the default behavior of a straight diff. In
> > xdl_hash_record there is an initial check for whitespace flags.
> >
> > ...
> > if (flags & XDF_WHITESPACE_FLAGS)
> > return xdl_hash_record_with_whitespace(data, top, flags);
> > ...
> >
> > Perhaps a similar setup for xdl_rematch() and a
> > xdl_recmatch_with_whitespace() ?
>
> Or we can just move the final else clause up and start the function like
> this:
>
> int i1, i2;
>
> if (!(flags & XDF_WHITESPACE_FLAGS))
> return s1 == s2 && !memcmp(l1, l2, s1);
>
> i1 = i2 = 0;
> if (flags & XDF_IGNORE_WHITESPACE) {
> ...
>
> that would get rid of two unnecessary clearing of variables (i1 and i2,
> even though I suspect that the compiler _could_ optimize them out without
> such an change), and three flags-bit check in the most common case of not
> ignoring any whitespaces.
>
HA! That's a nifty way to do that with the variables.
> > Since your to counter-proposals give the same results, provide safer and
> > faster processing, eliminate the additional test, as well as being easier
> > to read and comprehend I propose a v3 with just those two patches. I'll
> > be glad to post it, with or without a xdl_recmatch_with_whitespace, if
> > need be. And should I, or do I need to, add something to the commit (ie:
> > ack, tested, ...) ?
>
> I can amend the counterproposal patches with tests from your 6/6 and add
> your "Tested-by:" and commit them myself.
>
Excellent.
> > Thank you again for taking the time to look at this change!
>
> Thank _you_ for bringing this issue up in the first place.
My pleasure! It has been quite the learning experience!
--
Thell
^ permalink raw reply
* bundles with multiple branches
From: Jeffrey Ratcliffe @ 2009-08-23 20:36 UTC (permalink / raw)
To: git
I tend to work on multiple machines that don't have direct access to
each and therefore keep my git repositories in sync using bundles.
This works fine for single branches - but how can I set things up so
that I can just
$ git pull <bundle>
or
$ git fetch <bundle>
and have git update all branches?
Regards
Jeff
^ permalink raw reply
* [PATCH] import-tars: Allow per-tar author and commit message.
From: Peter Krefting @ 2009-08-23 20:34 UTC (permalink / raw)
To: git
Instead of having each imported tar ball's commit message be "Imported
from filename.tar", optionally take a commit message from a file
called "filename.tar.msg".
Instead of having each commit have the same author and committer
information, optionally read the committer information from a file
called "filename.tar.committer" and author from a file called
"filename.tar.author".
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
---
I used this (albeit based on a slightly earlier verison of the script)
to generate a better-looking history when importing
http://git.debian.org/?p=crashmail/jamnntpd.git and
http://git.debian.org/?p=crashmail/crashmail.git into Git, using
excerpts from the embedded change history as commit messages.
contrib/fast-import/import-tars.perl | 42 +++++++++++++++++++++++++++++++--
1 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
index 78e40d2..7aad16f 100755
--- a/contrib/fast-import/import-tars.perl
+++ b/contrib/fast-import/import-tars.perl
@@ -109,12 +109,48 @@ foreach my $tar_file (@ARGV)
$have_top_dir = 0 if $top_dir ne $1;
}
+ # Optionally read a commit message from <filename.tar>.msg
+ my $commit_msg = "Imported from $tar_file.";
+ if (open MSG, '<', "${tar_file}.msg")
+ {
+ $commit_msg = '';
+ while (<MSG>)
+ {
+ $commit_msg .= $_;
+ }
+ close MSG;
+ }
+
+ # Optionally read a committer from <filename.tar>.committer
+ # (first line is name, second line is e-mail address).
+ my $this_committer_name = $committer_name;
+ my $this_committer_email = $committer_email;
+ if (open COMMITTER, '<', "${tar_file}.committer")
+ {
+ ($this_committer_name, $this_committer_email) = <COMMITTER>;
+ chomp $this_committer_name;
+ chomp $this_committer_email;
+ close COMMITTER;
+ }
+
+ # Optionally read an author from <filename.tar>.author
+ # (first line is name, second line is e-mail address).
+ my $this_author_name = $author_name;
+ my $this_author_email = $author_email;
+ if (open AUTHOR, '<', "${tar_file}.author")
+ {
+ ($this_author_name, $this_author_email) = <AUTHOR>;
+ chomp $this_author_name;
+ chomp $this_author_email;
+ close AUTHOR;
+ }
+
print FI <<EOF;
commit $branch_ref
-author $author_name <$author_email> $author_time +0000
-committer $committer_name <$committer_email> $commit_time +0000
+author $this_author_name <$this_author_email> $author_time +0000
+committer $this_committer_name <$this_committer_email> $commit_time +0000
data <<END_OF_COMMIT_MESSAGE
-Imported from $tar_file.
+$commit_msg
END_OF_COMMIT_MESSAGE
deleteall
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] gitweb: pull ref markes pull out of subject <a> tag
From: Giuseppe Bilotta @ 2009-08-23 20:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <200908232213.48786.jnareb@gmail.com>
2009/8/23 Jakub Narebski <jnareb@gmail.com>:
> For format_subject_html which you are fixing, and which is used by
> 'shortlog', 'history' and 'tags' views this didn't cause much changes
> in layout. But the way gitweb uses git_print_header_div in views such
> as 'tree', 'blob' etc., where the outer (containing) link is made into
> *block* element[1] by the way of CSS (display: block) makes layout
> (visualisation) very screwed up in older browser. But I don't expect
> you to fix that.
>
> [1] Originally so the area to click is larger.
Fixing that really needs some kind of ridiculously complex
workarounds, or a totally different layout. That is actually one of
the situations where nested links make perfect sense, and it's a real
pity the standard wouldn't allow them, and that some client actually
altered the DOM to 'fix' it. But anyway.
> Signoff?
Aaaargh. Is it enough if I put it here:
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
or should I resend?
(One would expect I actually learned to add it, finally, but noooo ...
gah, stupid me.)
>> The next step would be to find a way to layout decently the case when
>> some shortlog entries have a _humongous_ amount of ref markers. See
>> for example http://git.oblomov.eu/acecad/shortlog
>>
>> I honestly doubt these cases happen in normal git repositories, but it
>> might still be worth taking them into consideration. Possibilities
>> include hard-limiting the title column maximum width (in browsers for
>> which the corresponding attributes and rules work), manual insertion of
>> hard line breaks <br/> every n-th ref marker, or something more dynamic
>> such as hiding most of the ref markers when they are more than, say, 5,
>> and showing them on hover.
>>
>> Suggestions? Comments?
>
> Perhaps limiting to heads and tags if there are too many refs?
That wouldn't help at all in the case I linked:
http://git.oblomov.eu/acecad/shortlog due to the number of tags that
were imported from CVS.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: bundles with multiple branches
From: Adam Brewster @ 2009-08-23 20:52 UTC (permalink / raw)
To: Jeffrey Ratcliffe; +Cc: git
In-Reply-To: <30e395780908231336p403c2171ie383a81c3d1bb020@mail.gmail.com>
On Sun, Aug 23, 2009 at 4:36 PM, Jeffrey
Ratcliffe<jeffrey.ratcliffe@gmail.com> wrote:
> I tend to work on multiple machines that don't have direct access to
> each and therefore keep my git repositories in sync using bundles.
>
> This works fine for single branches - but how can I set things up so
> that I can just
>
> $ git pull <bundle>
>
> or
>
> $ git fetch <bundle>
>
> and have git update all branches?
>
1. Make sure you've got all of the refs you want in the bundle. I
usually use `git bundle create ... --all`
2. Set up a remote on the destination side with a url of wherever you
keep bundles (like /media/cdrom) and a fetch line like
refs/heads/*:refs/remotes/source/*
git remote add bundle /media/cdrom
git config --replace-all remotes.bundle.fetch refs/heads/*:refs/remotes/bundle/*
Since your destination machine is likely not connected to the
internet, you may also want copy all of the remotes too. I do that
with
git config --add remotes.bundle.fetch refs/remotes/*:refs/remotes/*
Beware of the use of the name "origin" with setups like this. If you
have branches under refs/remotes/origin/ on the machine you use to
create the bundle, you will should make sure you don't try to copy
refs from refs/heads and refs/remotes/origin to the same place
(because refs/remotes/origin is the natural place to store both).
Adam
^ permalink raw reply
* Re: bundles with multiple branches
From: Jeffrey Ratcliffe @ 2009-08-23 21:04 UTC (permalink / raw)
To: Adam Brewster; +Cc: git
In-Reply-To: <c376da900908231352o5c5746c0h9e39b80adede66e8@mail.gmail.com>
Thanks for the help
2009/8/23 Adam Brewster <adambrewster@gmail.com>:
> git remote add bundle /media/cdrom
> git config --replace-all remotes.bundle.fetch refs/heads/*:refs/remotes/bundle/*
> git config --add remotes.bundle.fetch refs/remotes/*:refs/remotes/*
On
$ git pull bundle
or
$ git fetch bundle
I get
fatal: '/media/cdrom': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Any ideas?
(I used the mount point of the USB stick where the bundles were but
the principle is the same)
Regards
Jeff
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Nanako Shiraishi @ 2009-08-23 21:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7v1vn2yklo.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Having said that, I could use something like this.
>
> -- >8 -- cut here -- >8 --
> Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
>
> This teaches mailinfo the scissors -- >8 -- mark; the command ignores
> everything before it in the message body.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are left handed people whose scissors run in the wrong direction.
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b0906ef..38c01e4 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -725,7 +725,8 @@ static int scissors(const struct strbuf *line)
scissors_dashes_seen |= 02;
continue;
}
- if (i + 1 < len && !memcmp(buf + i, ">8", 2)) {
+ if (i + 1 < len &&
+ !memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2)) {
scissors_dashes_seen |= 01;
i++;
continue;
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: Pulling one commit at a time.
From: Nanako Shiraishi @ 2009-08-23 21:07 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: git
In-Reply-To: <4A9172D0.6030507@microchip.com>
Quoting Sanjiv Gupta <sanjiv.gupta@microchip.com>
> I just wanted to know how can I pull one commit at a time from public
> repository.
> e.g.
> when I first cloned from the public repo, it was at X. now it has
> reached Y. I just want to pull x+1.
When your histories look like this:
A your 'master'
/
---X---U---V---W---Y public 'master' (your 'origin')
instead of creating a single merge like this with "git pull":
A---------------M your 'master' (fully merges 'origin')
/ /
---X---U---V---W---Y public 'master'
you want to create a history like this?
A---J your 'master' (lacks V, W and Y)
/ /
---X---U---V---W---Y public 'master'
For that, you can fetch first.
git fetch origin
Then look at the history in gitk
gitk master origin
And find the commit you are interested in merging (U in the above picture). And merge it.
git merge origin~3
Replace "origin~3" in the example above with whatever commit you want to merge the entire history leading to it.
You can repeat this final step as many times you want. For example, if you want create a history like this:
A---J---K---L---M your 'master'
/ / / / /
---X---U---V---W---Y public 'master'
you can do so by repeating the last step for V, W and Y in turn.
In general the public history isn't necessarily a single straight line like this picture and it doesn't make sense to merge one at a time for all the commits on the public branch, but if that is what you really want to do, you can do so.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Junio C Hamano @ 2009-08-23 21:11 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Johannes.Schindelin
In-Reply-To: <alpine.DEB.2.00.0908231515020.29625@GWPortableVCS>
Thell Fowler <git@tbfowler.name> writes:
>> Or we can just move the final else clause up and start the function like
>> this:
>>
>> int i1, i2;
>>
>> if (!(flags & XDF_WHITESPACE_FLAGS))
>> return s1 == s2 && !memcmp(l1, l2, s1);
>>
>> i1 = i2 = 0;
>> if (flags & XDF_IGNORE_WHITESPACE) {
>> ...
>>
>> that would get rid of two unnecessary clearing of variables (i1 and i2,
>> even though I suspect that the compiler _could_ optimize them out without
>> such an change), and three flags-bit check in the most common case of not
>> ignoring any whitespaces.
>>
>
> HA! That's a nifty way to do that with the variables.
My tentative draft to replace the "how about this" patch further reworks
the loop structure and currently looks like this.
It adds net 15 lines but among that 12 lines are comments, which is not so
bad.
-- >8 --
Subject: [PATCH] xutils: Fix xdl_recmatch() on incomplete lines
Thell Fowler noticed that various "ignore whitespace" options to git diff
do not work well on an incomplete line.
The loop control of the function responsible for these bugs was extremely
difficult to follow. This patch restructures the loops for three variants
of "ignore whitespace" logic.
The basic idea of the re-written logic is:
- A loop runs while the characters from both strings we are looking at
match. We declare unmatch immediately when we find something that does
not match and return false from the function. We break out of the loop
if we ran out of either side of the string.
The way we skip spaces inside this loop varies depending on the style
of ignoring whitespaces.
- After the above loop breaks, we know that the parts of the strings we
inspected so far match, ignoring the whitespaces. The lines can match
only if the remainder consists of nothing but whitespaces. This part
of the logic is shared across all three styles.
The new code is more obvious and should be much easier to follow.
Tested-by: Thell Fowler <git@tbfowler.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
xdiff/xutils.c | 77 +++++++++++++++++++++++++++++++++----------------------
1 files changed, 46 insertions(+), 31 deletions(-)
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 9411fa9..eb7b597 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -190,48 +190,63 @@ int xdl_recmatch(const char *l1, long s1, const char *l2, long s2, long flags)
{
int i1, i2;
+ if (!(flags & XDF_WHITESPACE_FLAGS))
+ return s1 == s2 && !memcmp(l1, l2, s1);
+
+ i1 = 0;
+ i2 = 0;
+
+ /*
+ * -w matches everything that matches with -b, and -b in turn
+ * matches everything that matches with --ignore-space-at-eol.
+ *
+ * Each flavor of ignoring needs different logic to skip whitespaces
+ * while we have both sides to compare.
+ */
if (flags & XDF_IGNORE_WHITESPACE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (isspace(l1[i1]))
- while (isspace(l1[i1]) && i1 < s1)
- i1++;
- if (isspace(l2[i2]))
- while (isspace(l2[i2]) && i2 < s2)
- i2++;
- if (i1 < s1 && i2 < s2 && l1[i1++] != l2[i2++])
+ goto skip_ws;
+ while (i1 < s1 && i2 < s2) {
+ if (l1[i1++] != l2[i2++])
return 0;
+ skip_ws:
+ while (i1 < s1 && isspace(l1[i1]))
+ i1++;
+ while (i2 < s2 && isspace(l2[i2]))
+ i2++;
}
- return (i1 >= s1 && i2 >= s2);
} else if (flags & XDF_IGNORE_WHITESPACE_CHANGE) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (isspace(l1[i1])) {
- if (!isspace(l2[i2]))
- return 0;
- while (isspace(l1[i1]) && i1 < s1)
- i1++;
- while (isspace(l2[i2]) && i2 < s2)
- i2++;
- } else if (l1[i1++] != l2[i2++])
- return 0;
- }
- return (i1 >= s1 && i2 >= s2);
- } else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL) {
- for (i1 = i2 = 0; i1 < s1 && i2 < s2; ) {
- if (l1[i1] != l2[i2]) {
+ while (i1 < s1 && i2 < s2) {
+ if (isspace(l1[i1]) && isspace(l2[i2])) {
+ /* Skip matching spaces and try again */
while (i1 < s1 && isspace(l1[i1]))
i1++;
while (i2 < s2 && isspace(l2[i2]))
i2++;
- if (i1 < s1 || i2 < s2)
- return 0;
- return 1;
+ continue;
}
+ if (l1[i1++] != l2[i2++])
+ return 0;
+ }
+ } else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL) {
+ while (i1 < s1 && i2 < s2 && l1[i1++] == l2[i2++])
+ ; /* keep going */
+ }
+
+ /*
+ * After running out of one side, the remaining side must have
+ * nothing but whitespace for the lines to match.
+ */
+ if (i1 < s1) {
+ while (i1 < s1 && isspace(l1[i1]))
i1++;
+ return (s1 == i1);
+ }
+ if (i2 < s2) {
+ while (i2 < s2 && isspace(l2[i2]))
i2++;
- }
- return i1 >= s1 && i2 >= s2;
- } else
- return s1 == s2 && !memcmp(l1, l2, s1);
+ return (s2 == i2);
+ }
+ return 1;
}
static unsigned long xdl_hash_record_with_whitespace(char const **data,
--
1.6.4.1.255.g5556a
^ permalink raw reply related
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Junio C Hamano @ 2009-08-23 21:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090824060708.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> There are left handed people whose scissors run in the wrong direction.
Heh.
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index b0906ef..38c01e4 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -725,7 +725,8 @@ static int scissors(const struct strbuf *line)
> scissors_dashes_seen |= 02;
> continue;
> }
> - if (i + 1 < len && !memcmp(buf + i, ">8", 2)) {
> + if (i + 1 < len &&
> + !memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2)) {
> scissors_dashes_seen |= 01;
You need a pair of parentheses around the memcmp || memcmp.
I'll squash that in.
^ permalink raw reply
* Re: [PATCH] import-tars: Allow per-tar author and commit message.
From: Nanako Shiraishi @ 2009-08-23 21:24 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <20090823203640.B195D189B12@perkele>
Quoting Peter Krefting <peter@softwolves.pp.se>
> Instead of having each imported tar ball's commit message be "Imported
> from filename.tar", optionally take a commit message from a file
> called "filename.tar.msg".
>
> Instead of having each commit have the same author and committer
> information, optionally read the committer information from a file
> called "filename.tar.committer" and author from a file called
> "filename.tar.author".
Instead of requiring the user to have millions of separate files, how about reading a single metainfo file that may look like this?
[file "git-1.0.0.tar"]
message = "Commit log message for the first revision"
author = "A U Thor <au.thor@example.xz>"
[file "git-1.0.1.tar"]
message = "Commit log message for the first maintenance revision"
author = "F I Xer <fi.xer@example.xz>"
and give the name of that metainfo file from the command line? The message may be awkward to put in the metainfo file itself, and it might be easier to refer to the name of a file that is outside the metainfo file itself, but the point is that doing so will both reduce the clutter in your folders, and will give people an option to avoid accidentally reading from random files in the same folder as the tar files that unfortunately have names that ends with the suffixes you randomly chose in this patch.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] import-tars: Allow per-tar author and commit message.
From: Sam Vilain @ 2009-08-23 21:46 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <20090823203640.B195D189B12@perkele>
Peter Krefting wrote:
> Instead of having each imported tar ball's commit message be "Imported
> from filename.tar", optionally take a commit message from a file
> called "filename.tar.msg".
>
> Instead of having each commit have the same author and committer
> information, optionally read the committer information from a file
> called "filename.tar.committer" and author from a file called
> "filename.tar.author".
>
> Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
> ---
> I used this (albeit based on a slightly earlier verison of the script)
> to generate a better-looking history when importing
> http://git.debian.org/?p=crashmail/jamnntpd.git and
> http://git.debian.org/?p=crashmail/crashmail.git into Git, using
> excerpts from the embedded change history as commit messages.
>
> contrib/fast-import/import-tars.perl | 42 +++++++++++++++++++++++++++++++--
> 1 files changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/contrib/fast-import/import-tars.perl b/contrib/fast-import/import-tars.perl
> index 78e40d2..7aad16f 100755
> --- a/contrib/fast-import/import-tars.perl
> +++ b/contrib/fast-import/import-tars.perl
> @@ -109,12 +109,48 @@ foreach my $tar_file (@ARGV)
> $have_top_dir = 0 if $top_dir ne $1;
> }
>
> + # Optionally read a commit message from <filename.tar>.msg
> + my $commit_msg = "Imported from $tar_file.";
> + if (open MSG, '<', "${tar_file}.msg")
> + {
> + $commit_msg = '';
> + while (<MSG>)
> + {
> + $commit_msg .= $_;
> + }
> + close MSG;
> + }
> +
> + # Optionally read a committer from <filename.tar>.committer
> + # (first line is name, second line is e-mail address).
> + my $this_committer_name = $committer_name;
> + my $this_committer_email = $committer_email;
> + if (open COMMITTER, '<', "${tar_file}.committer")
> + {
> + ($this_committer_name, $this_committer_email) = <COMMITTER>;
> + chomp $this_committer_name;
> + chomp $this_committer_email;
> + close COMMITTER;
> + }
> +
> + # Optionally read an author from <filename.tar>.author
> + # (first line is name, second line is e-mail address).
> + my $this_author_name = $author_name;
> + my $this_author_email = $author_email;
> + if (open AUTHOR, '<', "${tar_file}.author")
> + {
> + ($this_author_name, $this_author_email) = <AUTHOR>;
> + chomp $this_author_name;
> + chomp $this_author_email;
> + close AUTHOR;
> + }
> +
>
It's not necessary to duplicate code like that.
Also I wonder if there isn't a nicer interface for users. Why not allow
the file to specify From:, Committer: etc as header lines
# Optionally read a commit message from <filename.tar>.msg
my $commit_msg = "Imported from $tar_file.";
my ($committer, $commit_date, $author, $author_date);
if (open MSG, '<', "${tar_file}.desc")
{
my $state = "header";
$commit_msg = '';
my $last_val;
while (<MSG>)
{
if ($state eq "header") {
if (m{^([A-Z][\w\-]+): (.*)}) {
my ($header, $value) = $1;
$last_val = ($header eq "Date" ? \$author_date :
$header eq "From" ? \$author :
$header eq "Subject" ? \$commit_msg :
$header eq "Commit-Date" ? \$commit_date :
$header eq "Committer" ? \$committer :
undef );
if ($last_val) {
$$last_val = $value;
}
else {
warn "ignoring header '$header' in ${tar_file}.desc line $.\n";
}
}
elsif (m{^\s+(.+)}) {
if ($last_val) {
$$last_val .= " $1";
}
}
elsif (m{^\s*$}) {
$commit_msg .= ($commit_msg ? "\n" : "") . "\n";
$state = "body";
next;
}
}
if ($state eq "body") {
$commit_msg .= $_;
}
}
close MSG;
}
($this_committer_name, $this_committer_email) =
choose_email($committer, $committer_name, $committer_email);
($this_author_name, $this_author_email) =
choose_email($author, $author_name, $author_email);
sub choose_email {
my ($spec_combined, $def_name, $def_email) = @_;
return ($def_name, $def_email) unless $spec_combined;
if ($spec_combined =~ m{^([^<]+) <([^@]+@[^@]+)>$})) {
($1, $2);
}
elsif ($spec_combined =~ m{^([^@]+@[^@]+) \((.*)\)$}) {
($2, $1);
}
else {
warn "Couldn't parse e-mail address '$spec_combined'";
($def_name, $def_email);
}
}
Something like that, anyway...
Sam
> print FI <<EOF;
> commit $branch_ref
> -author $author_name <$author_email> $author_time +0000
> -committer $committer_name <$committer_email> $commit_time +0000
> +author $this_author_name <$this_author_email> $author_time +0000
> +committer $this_committer_name <$this_committer_email> $commit_time +0000
> data <<END_OF_COMMIT_MESSAGE
> -Imported from $tar_file.
> +$commit_msg
> END_OF_COMMIT_MESSAGE
>
> deleteall
>
^ 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