* Re: [PATCH v3] Add script for importing bits-and-pieces to Git.
From: Peter Krefting @ 2009-08-26 9:08 UTC (permalink / raw)
To: git
In-Reply-To: <20090826090426.D6C73189B12@perkele>
Peter Krefting:
> This version contains updated documentation, trying to address the
> points raised by Junio. It also fixes a compile error that snuck in
> the v2 patch.
No it doesn't. I seem to have sent out v2 again under a new name. Sorry for
the noise :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] git-bisect: call the found commit "*the* first bad commit"
From: Junio C Hamano @ 2009-08-26 9:05 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090826173850.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> .. as we learned in the school ;-)
Thanks.
Is it "learned in school", or do you also need "*the*" there?
;-)
^ permalink raw reply
* [PATCH v3] Add script for importing bits-and-pieces to Git.
From: Peter Krefting @ 2009-08-24 17:09 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>
---
This version contains updated documentation, trying to address the
points raised by Junio. It also fixes a compile error that snuck in
the v2 patch.
contrib/fast-import/import-directories.perl | 332 +++++++++++++++++++++++++++
1 files changed, 332 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..98079ad
--- /dev/null
+++ b/contrib/fast-import/import-directories.perl
@@ -0,0 +1,332 @@
+#!/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 ($size, $mtime) = (stat(FILE))[7,9];
+ 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: [PATCH] fix simple deepening of a repo
From: Junio C Hamano @ 2009-08-26 9:03 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Sixt, Junio C Hamano, Nicolas Pitre, Julian Phillips,
Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <20090826082256.GO1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> How will this mesh with 'git clone --mirror'?
>
> Not well.
>
>> Is the client expected to
>> ask with 'expand refs/*'?
>
> If the client is new enough to understand the "expand" extension,
> yes, it would ask for "expand refs/*" and get everthing, allowing
> it to complete a full mirror.
>
> If the client is older and doesn't know this extension, then it
> is hopeless. The server isn't advertising refs/*, doesn't know
> that the client can't ask for refs/*, and the client doesn't know
> it is missing refs when it makes the mirror.
>
> This backwards incompatible breakage is something I have no real
> solution for. :-|
But we at least can assume that the server operator is reasonable and
wouldn't go overboard, (ab)using this "abbreviated advertisement" feature
to hide heads and tags from the clients. I would suspect that a server
operated by such a sick person who hides these normal refs will be shunned
by users so it won't either happen in practice, or even if it happens, it
won't be a problem---simply because nobody would want to interact with
such a server.
Think about in what situation you would want to do a mirror clone. The
most obvious is to have a back-up or secondary distribution point, and I
do not think of any other sane reason (other than "because I can", which
does not count). If the original repository has so many refs to benefit
from the "abbreviated advertisement" feature (otherwise there is no point
using it in the first place), then its mirror repository would also want
to use the feature when talking to its clients, acting as a back-up
distribution point. That means the version of git used to prime, update
and serve the mirror will know the expand extention.
I am hoping that we can finish 1.6.5 by mid September (let's tentatively
say we will shoot for 16th). I expect the expand extention to be in
'next' by that time, cooking for 1.7.0. How does that timetable sound?
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Junio C Hamano @ 2009-08-26 9:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Tom Werner, Tom Preston-Werner, git
In-Reply-To: <alpine.DEB.1.00.0908261043140.4713@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 25 Aug 2009, Junio C Hamano wrote:
>
>> If we are allowed to talk about asking for the moon,
>
> How about
>
> run_hook(NULL, "post-upload-pack",
> create_full_pack ? "clone" : "fetch,
> "the moon",
> NULL);
>
> then?
>
>> and if one of the primary reason for this new hook is statistics, it
>> would be useful to see the number of bytes given, where the fetch-pack
>> came from, and if we are using git-daemon virtual hosting which of our
>> domain served the request.
>
> Certainly those are possible add-on patches, but would you require them to
> be in the same commit?
I was merely responding to the "what else would be useful" question posed
by Peff.
Did you get an impression that I was saying "you must add these otherwise
I'll reject the patch"?
I didn't mean to. I think it is entirely reasonable to queue the patch in
'pu' (after fixing the NULL termination bug), and start cooking without
any of the additional information.
Having said that, this is an external interface, and until we feel
reasonably sure that we are giving enough information to the hook and
we wouldn't need to change the interface, the series must not come near
'master'.
It might make sense to define the external interface to be "information is
given through the standard input of the hook, formatted in YAML, and here
are the initial set of items that may be fed", so that we do not have to
worry about the details too much.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-26 9:03 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nicolas Sebrecht, Nanako Shiraishi, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <h72td7$cu6$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Nicolas Sebrecht wrote:
>
>> For people who _really_ want to obey to scissors by default I'll add an
>> option to git-config. Whithout more comments, I'll add
>>
>> scissors.obey
>
> mailsplit.scissors
That may be a better name.
It must take lower precedence than the command line --no-scissors option,
and that option must be given to am when rebase internally runs am, so that
we won't pay attention to scissors when rebasing existing commits.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Johannes Schindelin @ 2009-08-26 9:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <h72td7$cu6$1@ger.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 479 bytes --]
Hi,
On Wed, 26 Aug 2009, Jakub Narebski wrote:
> Nicolas Sebrecht wrote:
>
> > For people who _really_ want to obey to scissors by default I'll add
> > an option to git-config. Whithout more comments, I'll add
> >
> > scissors.obey
>
> mailsplit.scissors
Sorry, did not have time to read this thread properly, but has anybody put
thought into the interaction between this patch and "git rebase" (which
uses "git am", and therefore mailsplit, internally)?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Jakub Narebski @ 2009-08-26 8:57 UTC (permalink / raw)
To: git
In-Reply-To: <20090826050224.GK3526@vidovic>
Nicolas Sebrecht wrote:
> For people who _really_ want to obey to scissors by default I'll add an
> option to git-config. Whithout more comments, I'll add
>
> scissors.obey
mailsplit.scissors
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Johannes Schindelin @ 2009-08-26 8:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Tom Werner, Tom Preston-Werner, git
In-Reply-To: <7vprajmp16.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, 25 Aug 2009, Junio C Hamano wrote:
> If we are allowed to talk about asking for the moon,
How about
run_hook(NULL, "post-upload-pack",
create_full_pack ? "clone" : "fetch,
"the moon",
NULL);
then?
> and if one of the primary reason for this new hook is statistics, it
> would be useful to see the number of bytes given, where the fetch-pack
> came from, and if we are using git-daemon virtual hosting which of our
> domain served the request.
Certainly those are possible add-on patches, but would you require them to
be in the same commit?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-bisect: call the found commit "*the* first bad commit"
From: Nanako Shiraishi @ 2009-08-26 8:38 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
.. as we learned in the school ;-)
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
bisect.c | 2 +-
git-bisect.sh | 2 +-
t/t6030-bisect-porcelain.sh | 18 +++++++++---------
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/bisect.c b/bisect.c
index 7f20acb..dc18db8 100644
--- a/bisect.c
+++ b/bisect.c
@@ -991,7 +991,7 @@ int bisect_next_all(const char *prefix)
if (!hashcmp(bisect_rev, current_bad_sha1)) {
exit_if_skipped_commits(tried, current_bad_sha1);
- printf("%s is first bad commit\n", bisect_rev_hex);
+ printf("%s is the first bad commit\n", bisect_rev_hex);
show_diff_tree(prefix, revs.commits->item);
/* This means the bisection process succeeded. */
exit(10);
diff --git a/git-bisect.sh b/git-bisect.sh
index 8969553..6f6f039 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -405,7 +405,7 @@ bisect_run () {
exit $res
fi
- if grep "is first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then
+ if grep "is the first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then
echo "bisect run success"
exit 0;
fi
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 1315bab..def397c 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -175,7 +175,7 @@ test_expect_success 'bisect skip: successfull result' '
git bisect start $HASH4 $HASH1 &&
git bisect skip &&
git bisect bad > my_bisect_log.txt &&
- grep "$HASH2 is first bad commit" my_bisect_log.txt &&
+ grep "$HASH2 is the first bad commit" my_bisect_log.txt &&
git bisect reset
'
@@ -261,7 +261,7 @@ test_expect_success \
git bisect good $HASH1 &&
git bisect bad $HASH4 &&
git bisect run ./test_script.sh > my_bisect_log.txt &&
- grep "$HASH3 is first bad commit" my_bisect_log.txt &&
+ grep "$HASH3 is the first bad commit" my_bisect_log.txt &&
git bisect reset'
# We want to automatically find the commit that
@@ -274,7 +274,7 @@ test_expect_success \
chmod +x test_script.sh &&
git bisect start $HASH4 $HASH1 &&
git bisect run ./test_script.sh > my_bisect_log.txt &&
- grep "$HASH4 is first bad commit" my_bisect_log.txt &&
+ grep "$HASH4 is the first bad commit" my_bisect_log.txt &&
git bisect reset'
# $HASH1 is good, $HASH5 is bad, we skip $HASH3
@@ -287,14 +287,14 @@ test_expect_success 'bisect skip: add line and then a new test' '
git bisect start $HASH5 $HASH1 &&
git bisect skip &&
git bisect good > my_bisect_log.txt &&
- grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
git bisect log > log_to_replay.txt &&
git bisect reset
'
test_expect_success 'bisect skip and bisect replay' '
git bisect replay log_to_replay.txt > my_bisect_log.txt &&
- grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ grep "$HASH5 is the first bad commit" my_bisect_log.txt &&
git bisect reset
'
@@ -335,7 +335,7 @@ test_expect_success 'bisect run & skip: find first bad' '
chmod +x test_script.sh &&
git bisect start $HASH7 $HASH1 &&
git bisect run ./test_script.sh > my_bisect_log.txt &&
- grep "$HASH6 is first bad commit" my_bisect_log.txt
+ grep "$HASH6 is the first bad commit" my_bisect_log.txt
'
test_expect_success 'bisect skip only one range' '
@@ -385,7 +385,7 @@ test_expect_success 'bisect does not create a "bisect" branch' '
rev_hash6=$(git rev-parse --verify HEAD) &&
test "$rev_hash6" = "$HASH6" &&
git bisect good > my_bisect_log.txt &&
- grep "$HASH7 is first bad commit" my_bisect_log.txt &&
+ grep "$HASH7 is the first bad commit" my_bisect_log.txt &&
git bisect reset &&
rev_hash6=$(git rev-parse --verify bisect) &&
test "$rev_hash6" = "$HASH6" &&
@@ -534,7 +534,7 @@ test_expect_success 'restricting bisection on one dir' '
para1=$(git rev-parse --verify HEAD) &&
test "$para1" = "$PARA_HASH1" &&
git bisect bad > my_bisect_log.txt &&
- grep "$PARA_HASH1 is first bad commit" my_bisect_log.txt
+ grep "$PARA_HASH1 is the first bad commit" my_bisect_log.txt
'
test_expect_success 'restricting bisection on one dir and a file' '
@@ -552,7 +552,7 @@ test_expect_success 'restricting bisection on one dir and a file' '
para1=$(git rev-parse --verify HEAD) &&
test "$para1" = "$PARA_HASH1" &&
git bisect good > my_bisect_log.txt &&
- grep "$PARA_HASH4 is first bad commit" my_bisect_log.txt
+ grep "$PARA_HASH4 is the first bad commit" my_bisect_log.txt
'
test_expect_success 'skipping away from skipped commit' '
--
1.6.4.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-26 8:22 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <4A94DF84.4050906@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> > static void upload_pack(void)
> > {
> > reset_timeout();
> > - head_ref(send_ref, NULL);
> > - for_each_ref(send_ref, NULL);
> > - packet_flush(1);
> > + head_ref(scan_ref, NULL);
> > + for_each_ref(scan_ref, NULL);
> > +
> > + push_advertise("HEAD");
> > + push_advertise("refs/heads/*");
> > + push_advertise("refs/tags/*");
> > + send_refs();
> > +
>
> How will this mesh with 'git clone --mirror'?
Not well.
> Is the client expected to
> ask with 'expand refs/*'?
If the client is new enough to understand the "expand" extension,
yes, it would ask for "expand refs/*" and get everthing, allowing
it to complete a full mirror.
If the client is older and doesn't know this extension, then it
is hopeless. The server isn't advertising refs/*, doesn't know
that the client can't ask for refs/*, and the client doesn't know
it is missing refs when it makes the mirror.
This backwards incompatible breakage is something I have no real
solution for. :-|
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Johannes Sixt @ 2009-08-26 7:08 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <20090826021057.GL1033@spearce.org>
Shawn O. Pearce schrieb:
> static void upload_pack(void)
> {
> reset_timeout();
> - head_ref(send_ref, NULL);
> - for_each_ref(send_ref, NULL);
> - packet_flush(1);
> + head_ref(scan_ref, NULL);
> + for_each_ref(scan_ref, NULL);
> +
> + push_advertise("HEAD");
> + push_advertise("refs/heads/*");
> + push_advertise("refs/tags/*");
> + send_refs();
> +
How will this mesh with 'git clone --mirror'? Is the client expected to
ask with 'expand refs/*'?
-- Hannes
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-26 5:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Nanako Shiraishi, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <7veiqzjmy7.fsf@alter.siamese.dyndns.org>
The 25/08/09, Junio C Hamano wrote:
> I therefore conclude that using the "remove above scissors" should be a
> conscious decision, and should not be enabled by default. --obey-scissors
> would be a good option for this reason.
I'm not sure what between --obey or --ignore will help most to write
good commit message. I (as a maintainer myself or as a contributor)
usually prefer to --amend a commit rather than play with copy/paste or
starting from scratch. So, I tend to agree even if the reasons are not
exactly the same. :-)
That said, I don't bother what is the default that much. The main
purpose is to have the choice.
For people who _really_ want to obey to scissors by default I'll add an
option to git-config. Whithout more comments, I'll add
scissors.obey
.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: gitosis-lite
From: Sitaram Chamarty @ 2009-08-26 5:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <200908251405.17644.jnareb@gmail.com>
On Tue, Aug 25, 2009 at 5:35 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> Sitaram Chamarty wrote:
>> On Tue, Aug 25, 2009 at 12:14 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>> > Wouldn't it be better to use "use warnings" instead of 'perl -w'?
>> I'm not sure what is the minimum perl required for git
> I think that git requires Perl at least version 5.6
thanks; I'll change "-w" to "use warnings"
>> > It would be, I think, better if you have used POD for such
>> > documentation. One would be able to generate manpage using pod2man,
>> > and it is no less readable in source code. See e.g. perl/Git.pm or
>> > contrib/hooks/update-paranoid.
>>
>> Hmm... I've been spoiled by Markdown's sane bullet list
>> handling. Visually, POD forces everything other than code
>> to be flush left -- any sort of list is definitely less
>> readable in source code as a result. IMHO of course.
>
> How it is relevant to the issue at hand? I was talking about replacing
> documentation comments in the header with POD markup.
>
> Also you usually document top-level structures with POD.
Forget I mentioned markdown :) All I'm saying is that even in the
documentation you speak of, I have a couple of small "lists". And I
like lists to be properly indented, that's all -- I am mentally unable
to edit them if they are all flush left :-( just like it's irritating
to edit code that's mis-indented or not indented. Sorry...!
And yes, one of my python friends has then asked "why do you not like
python". I have no answer. As Whitman said
(http://www.quotationspage.com/quote/26914.html):
Do I contradict myself?
Very well then I contradict myself,
(I am large, I contain multitudes.)
:-)
Regards,
--
Sitaram "not normally given to quoting poets" Chamarty
^ permalink raw reply
* Re: git only one file
From: Giuseppe Bilotta @ 2009-08-26 4:30 UTC (permalink / raw)
To: syn hedionn; +Cc: git
In-Reply-To: <a7c6f4d60908251605l5fb771a5t79b27cf688fab205@mail.gmail.com>
On Wed, Aug 26, 2009 at 1:05 AM, syn hedionn<synhedionn@gmail.com> wrote:
> ok , but if I put,
> git add index.htm
> I have:
> fatal: Not a git repository
You need to initialize the repository before you can add files to it, so:
git init
git add index.htm
git commit -m "Initial commit"
The zit way would be:
zit track index.htm
zit commit -m "Initial commit" index.htm
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Jeremy O'Brien @ 2009-08-26 4:24 UTC (permalink / raw)
To: Frank Münnich; +Cc: <git@vger.kernel.org>
In-Reply-To: <000001ca257d$b60326c0$22097440$@com>
Vim (or gvim if I want better colors), and cscope. Cscope + vim is a
killer combination that enables you to fly around projects of any size
very efficiently. I swear by it. I use it at my job to navigate a
project consisting of over 14000 lines of code. It makes tracing
execution and navigating a project child's play.
Hope that helps,
Jeremy
On Aug 25, 2009, at 8:15, Frank Münnich <git@frank-muennich.com> wrote:
> Hi there,
>
> I am interested in helping out and improving git, though I haven't
> programmed in C for quite a while now and thus have to relearn quite
> some
> things.
> I understand the different branches (master, next, pu) and so on,
> and were
> successful in compiling git with my Ubuntu 9.04. [yeea] ;)
>
> One thing I would like to ask you: what, if any, IDEs are you
> working with?
> I tried Anjuta but were unsuccessful in importing the git folder
> from any
> branch into Anjuta. Eclipse worked a bit better, though I am still
> batteling
> with the debugger a bit.
>
> Any recommendations, manuals or how-to tips are greatly welcome.
> And one thing: thank you for your effort! Git really caught my
> attention and
> I was so much amused by the Google-Techtalk that Linus gave about
> Git, that
> it sparked my interest in relearning how to program again ;)
>
> Best regards from lovely Dresden in Germany
> Frank Münnich
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-26 3:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Nanako Shiraishi, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <7vvdkbl4ul.fsf@alter.siamese.dyndns.org>
The 25/08/09, Junio C Hamano wrote:
> What I meant was that I would not want to spend any more of _my_ time on
> the definition of the scissors for now. That means spending or wasting
> time on improving the 'pu' patch myself, or looking at others patch to
> find flaws in them.
>
> Of course, as the maintainer, I would need to look at proposals to improve
> or fix bugs in the code before the series hits the master, but I would
> give zero priority to the patches that change the definition at least for
> now to give myself time to work on more useful things.
Ok, thank you.
> I think --ignore-scissors is a good thing to add, regardless of what the
> definition of scissors should be. So your patch should definitely be
> separated into two parts.
Could find it at the end of the mails.
> > #include "builtin.h"
> > #include "utf8.h"
> > #include "strbuf.h"
> > +#include "git-compat-util.h"
>
> Inclusion of builtin.h is designed to be enough. What do you need this
> for?
It is for the warning() call
warning("scissors line found, will skip text above");
I've added. That said, moving this declaration to builtin.h could be a
good idea. Hint?
> > @@ -715,51 +717,63 @@ static inline int patchbreak(const struct strbuf *line)
> > if (isspace(buf[i])) {
> > + if (scissors_dashes_seen)
> > + mark_end = i;
>
> I think you do not want this part, and then you won't have to trim
> trailing whitespaces from mark_end later.
Good eyes.
> > + /*
> > + * The mark is 8 charaters long and contains at least one dash and
> > + * either a ">8" or "<8". Check if the last mark in the line
> > + * matches the first mark found without worrying about what could
> > + * be between them. Only one mark in the whole line is permitted.
> > + */
>
> This definition makes "- 8<" a scissors.
Yes. Instead of looking for dashes alone, I will give a try to something
like
if (!scissors_dashes_seen)
mark_start = i;
if (i + 1 < len) {
if (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2))) {
scissors_dashes_seen |= 02;
i++;
mark_end = i;
continue;
else if (!memcmp(buf + i "--", 2) {
scissors_dashes_seen |= 04;
i++;
mark_end = i;
continue;
}
}
if (i + 2 < len)
if (!memcmp(buf + i + 1, "- -", 3) {
scissors_dashes_seen |= 04;
i += 2;
mark_end = i;
continue;
}
if (buf[i] == '-') {
mark_end = i;
scissors_dashes_seen |= 01;
continue;
}
break;
}
if (scissors_dashes_seen == 07) {
...
> it does not allow
>
> "-- 8< -- please cut here -- 8< -- --"
Actually, I believe this one should really not be a scissors line. If we
accept some random dashes around markers it will break the definition of
the mark itself.
As I said, I'd rather rules easy to define over others because if the
end-user scissors line doesn't work, he can refer to the documentation...
> nor
>
> "-- 8< -- -- please cut here -- -- 8< --"
>
> nor
>
> "-- 8< -- -- please cut here -- -- >8 --"
...and symmetrical markers make sense to the user. Will add this.
> > + if (!ignore_scissors) {
> > + if (is_scissors_line(line)) {
> > + warning("scissors line found, will skip text above");
> > ...
> > + return 0;
>
> Don't re-indent like this. Just do:
>
> if (!ignore_scissors && is_scissors_line(line)) {
> ...
> }
Does the compilers (or a standard) assure that the members are evaluated
in the left-right order?
Otherwise, we may call is_scissors_line() where not needed.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-26 3:03 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7vvdkbl4ul.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think --ignore-scissors is a good thing to add, regardless of what the
> definition of scissors should be. So your patch should definitely be
> separated into two parts.
Having thought about this a bit more, I do not think --ignore-scissors
makes much sense, for several reasons.
Traditionally, a few lines of "background material" that accompanies a
patch, without being a part of discussion thread that quotes large chunks
of original message with ">" (like you see above), are given below the
three-dash line, not above "scissors". This is a good practice not only
because we did not have "scissors" support in mailinfo, but because it
forced the author to be concise and to the point, and also immediately
below the three-dash lines is where the diffstat comes, and it is a place
designed to be used for memory refreshers (e.g. "I changed this and that
from the previous round based on comments by ...").
The scissors feature shouldn't be used as the replacement for this, not
from technical but from human efficiency reasons, as you have to first
read above scissors and then jump your eyes down to diffstat, before
deciding if it is worth your time to read the commit log message and the
patch.
When there is a long discussion, a message in the thread, after following
the usual discussion style, may give a (counter)proposal as a "how about
this" patch. Such a patch is still _primarily_ for discussion, but it
sometimes turn out to be a good solution to the problem discussed in the
thread. The maintainer (or participant) then deliberately picks that
message and feeds it to "am", and it would be nice if things above
scissors are removed automatically. This is the _only_ intended use case
of the "scissors" line.
I therefore conclude that using the "remove above scissors" should be a
conscious decision, and should not be enabled by default. --obey-scissors
would be a good option for this reason.
Besides, if you _lost_ information because the scissors that is on by
default gave a false positive, you have to reset HEAD^ and re-apply. If
on the other hand we mistakenly kept cruft above a scissors, we can edit
it away using "rebase -i". So the failure recovery is much nicer if the
feature is not on by default.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-26 2:20 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Nicolas Sebrecht, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090826110332.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> What I meant was that I would not want to spend any more of _my_ time on
>> the definition of the scissors for now. That means spending or wasting
>> time on improving the 'pu' patch myself, or looking at others patch to
>> find flaws in them.
>>
>> Of course, as the maintainer, I would need to look at proposals to improve
>> or fix bugs in the code before the series hits the master, but I would
>> give zero priority to the patches that change the definition at least for
>> now to give myself time to work on more useful things.
>
> I am hoping that you didn't mean to say that other people on the list
> mustn't look at such patches and help improve them either?
>
> Perhaps you can rephrase your message in a more positive way, just like
> you request other people to do in their proposed commit log messages?
Ok, I agree that the way I worded the message was suboptimal, so let's try
again.
I would appreciate if the members of the list come up with an alternative
definition with a good implementation that they can agree on, and present
the result as a list consensus, with a solid justification to replace the
crap I have queued in 'pu', in the form of an applicable patch. Because I
consider that the exact definition of what a scissors line looks like is
an insignificant detail, I would prefer to see that process happen without
involving me.
By the way, I already queued your documentation patch, as adding the part
that describes what a "scissors" line is good for is a very good idea.
The "community" patch to replace the definition of scissors line may have
to update the part that describes what a "scissors" line looks like in
your patch.
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-26 2:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <20090825151424.GJ1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > So I think that expand-refs is a much nicer general solution than just
> > "server side is configured to hide but still allow certain refs", and
> > client updates cannot be avoided.
>
> Yes, I agree.
...
> I'm thinking about writing an RFC patch for this today for git.git.
RFC patch below. This is only the upload-pack side, and lacks
test, etc, so its posted *ONLY* for discussion. I'll try to flesh
it out further tomorrow into something that could be considered
more seriously.
--8<--
[RFC] upload-pack: expand capability advertises additional refs
The expand capability and associated command permits the client
to ask for information about refs which were not in the initial
advertisement sent when the connection was first opened.
In the below exchange the server initially only advertises its
current HEAD, refs/heads and refs/tags namespaces. However,
the client has been instructed to fetch anything which matches
refs/remotes/jc/*.
Since no matching refs appeared in the initial advertisement,
the client requests the server to expand the desired pattern,
and terminates its expand request list with a flush.
Upon receiving a flush from the client, the server displays any
local refs which match any of the expand patterns requested,
and then closes this secondary advertisement list with a flush.
If no refs matched, the server immediately returns a flush.
If multiple expand patterns match the same ref, the ref is returned
only once in the secondary advertisement, avoid confusing the client
with duplicate results.
S: 008f... HEAD\0...include-tag expand
S: 0043... refs/heads/build-next
S: 0040... refs/tags/v1.6.4.1
S: 0043... refs/tags/v1.6.4.1^{}
S: 0000
C: 001dexpand refs/remotes/jc/*
C: 0000
S: 0043... refs/remotes/jc/maint
S: 0044... refs/remotes/jc/master
S: 0000
C: 0031want ...
C: 0000
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
upload-pack.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 4d8be83..e1ec608 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -10,6 +10,8 @@
#include "revision.h"
#include "list-objects.h"
#include "run-command.h"
+#include "remote.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=nn] <dir>";
@@ -30,6 +32,18 @@ static int multi_ack, nr_our_refs;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
static int shallow_nr;
+
+struct adv_ref {
+ struct adv_ref *next;
+ char *name;
+ unsigned pattern:1;
+};
+static struct adv_ref *to_advertise;
+static struct adv_ref **advertise_tail = &to_advertise;
+
+static struct ref *local_refs;
+static struct ref **refs_tail = &local_refs;
+
static struct object_array have_obj;
static struct object_array want_obj;
static unsigned int timeout;
@@ -470,6 +484,17 @@ static int get_common_commits(void)
}
}
+static void push_advertise(const char *name)
+{
+ struct adv_ref *adv = xcalloc(1, sizeof(*adv));
+ adv->name = xstrdup(name);
+ adv->pattern = !!strchr(adv->name, '*');
+ *advertise_tail = adv;
+ advertise_tail = &adv->next;
+}
+
+static void send_refs(void);
+
static void receive_needs(void)
{
struct object_array shallows = {0, 0, NULL};
@@ -484,11 +509,22 @@ static void receive_needs(void)
unsigned char sha1_buf[20];
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
- if (!len)
+ if (!len) {
+ if (to_advertise) {
+ send_refs();
+ continue;
+ }
break;
+ }
if (debug_fd)
write_in_full(debug_fd, line, len);
+ if (!prefixcmp(line, "expand ")) {
+ if (line[len - 1] == '\n')
+ line[len - 1] = 0;
+ push_advertise(line + 7);
+ continue;
+ }
if (!prefixcmp(line, "shallow ")) {
unsigned char sha1[20];
struct object *object;
@@ -603,11 +639,14 @@ static void receive_needs(void)
free(shallows.objects);
}
-static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+static int send_ref(struct string_list_item *item, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
- " include-tag";
+ " include-tag expand";
+ const struct ref *ref = item->util;
+ const char *refname = ref->name;
+ const unsigned char *sha1 = ref->new_sha1;
struct object *o = parse_object(sha1);
if (!o)
@@ -631,12 +670,58 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static void send_refs(void)
+{
+ struct ref *to_send = NULL, **tail = &to_send;
+ struct ref *ref;
+ struct adv_ref *adv, *next_adv;
+ struct string_list sorted_names;
+
+ for (adv = to_advertise; adv; adv = next_adv) {
+ struct refspec spec;
+
+ memset(&spec, 0, sizeof(spec));
+ spec.pattern = adv->pattern;
+ spec.src = adv->name;
+ spec.dst = adv->name;
+ next_adv = adv->next;
+ get_fetch_map(local_refs, &spec, &tail, 1);
+
+ free(adv->name);
+ free(adv);
+ }
+ to_advertise = NULL;
+ advertise_tail = &to_advertise;
+
+ memset(&sorted_names, 0, sizeof(sorted_names));
+ for (ref = to_send; ref; ref = ref->next)
+ string_list_insert(ref->name, &sorted_names)->util = ref;
+ for_each_string_list(send_ref, &sorted_names, NULL);
+ string_list_clear(&sorted_names, 0);
+ free_refs(to_send);
+ packet_flush(1);
+}
+
+static int scan_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct ref *r = alloc_ref(refname);
+ hashcpy(r->new_sha1, sha1);
+ *refs_tail = r;
+ refs_tail = &r->next;
+ return 0;
+}
+
static void upload_pack(void)
{
reset_timeout();
- head_ref(send_ref, NULL);
- for_each_ref(send_ref, NULL);
- packet_flush(1);
+ head_ref(scan_ref, NULL);
+ for_each_ref(scan_ref, NULL);
+
+ push_advertise("HEAD");
+ push_advertise("refs/heads/*");
+ push_advertise("refs/tags/*");
+ send_refs();
+
receive_needs();
if (want_obj.nr) {
get_common_commits();
--
1.6.4.1.331.gda1d56
--
Shawn.
^ permalink raw reply related
* Re: gitosis-lite -- now renamed to "gitolite"
From: Sitaram Chamarty @ 2009-08-26 1:54 UTC (permalink / raw)
To: Git Mailing List; +Cc: Tommi Virtanen, Jakub Narebski
On Mon, Aug 24, 2009 at 5:58 PM, Sitaram Chamarty<sitaramc@gmail.com> wrote:
> I created a new project called gitosis-lite, which combines
I have now renamed it to gitolite. Seemed a good choice, keeping only
one letter from the main inspiration project; and the hyphen was
bothering me anyway.
For those who already downloaded it, please change the name of the
repo from "gitosis-lite" to "gitolite" in your .git/config.
There is one bug that was fixed; you'll know what it is when you fetch
and see the commit log :-(
> http://github.com/sitaramc/gitosis-lite
...and for completeness, this is now http://github.com/sitaramc/gitolite
--
sitaram
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-26 1:51 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <fc2ecb5cf28cabb7d183e2835ce46aa9afb2a322.1251215299.git.nicolas.s.dev@gmx.fr>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>> I think we have bikeshedded long enough, so I won't be touching this code
>> any further only to change the definition of what a scissors mark looks
>> like,
>
> I'm not sure I understand. Are you still open to a patch touching this code
> /too/?
What I meant was that I would not want to spend any more of _my_ time on
the definition of the scissors for now. That means spending or wasting
time on improving the 'pu' patch myself, or looking at others patch to
find flaws in them.
Of course, as the maintainer, I would need to look at proposals to improve
or fix bugs in the code before the series hits the master, but I would
give zero priority to the patches that change the definition at least for
now to give myself time to work on more useful things.
I think --ignore-scissors is a good thing to add, regardless of what the
definition of scissors should be. So your patch should definitely be
separated into two parts.
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index 7e09b51..92319f6 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -6,6 +6,7 @@
> #include "builtin.h"
> #include "utf8.h"
> #include "strbuf.h"
> +#include "git-compat-util.h"
Inclusion of builtin.h is designed to be enough. What do you need this
for?
> static FILE *cmitmsg, *patchfile, *fin, *fout;
>
> @@ -25,6 +26,7 @@ static enum {
> static struct strbuf charset = STRBUF_INIT;
> static int patch_lines;
> static struct strbuf **p_hdr_data, **s_hdr_data;
> +static int ignore_scissors = 0;
Don't initialize a static to 0.
> @@ -715,51 +717,63 @@ static inline int patchbreak(const struct strbuf *line)
> if (isspace(buf[i])) {
> + if (scissors_dashes_seen)
> + mark_end = i;
I think you do not want this part, and then you won't have to trim
trailing whitespaces from mark_end later.
> + /*
> + * The mark is 8 charaters long and contains at least one dash and
> + * either a ">8" or "<8". Check if the last mark in the line
> + * matches the first mark found without worrying about what could
> + * be between them. Only one mark in the whole line is permitted.
> + */
This definition makes "- 8<" a scissors.
Even though
"-- 8< -- please cut here -- -- 8< --"
is allowed, so is
"-- 8< -- -- please cut here -- 8< -- --"
it does not allow
"-- 8< -- please cut here -- 8< -- --"
nor
"-- 8< -- -- please cut here -- -- 8< --"
nor
"-- 8< -- -- please cut here -- -- >8 --"
Oh, did I say I won't waste my time on the definition? I should have just
discarded this hunk ;-)
> @@ -782,22 +796,25 @@ static int handle_commit_msg(struct strbuf *line)
> if (metainfo_charset)
> convert_to_utf8(line, charset.buf);
>
> - if (is_scissors_line(line)) {
> - int i;
> - rewind(cmitmsg);
> - ftruncate(fileno(cmitmsg), 0);
> - still_looking = 1;
> + if (!ignore_scissors) {
> + if (is_scissors_line(line)) {
> + warning("scissors line found, will skip text above");
> ...
> + return 0;
Don't re-indent like this. Just do:
if (!ignore_scissors && is_scissors_line(line)) {
...
}
> - # -s, -u, -k, --whitespace, -3, -C, -q and -p flags are kept
> + # Following flags are kept
We seem to have lost the description of what the "Following" are.
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Junio C Hamano @ 2009-08-25 23:50 UTC (permalink / raw)
To: Jeff King; +Cc: Tom Werner, Tom Preston-Werner, git
In-Reply-To: <20090825184525.GC23731@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> +static void run_post_upload_pack_hook(int create_full_pack)
>> +{
>> + const char *fetch_type;
>> + fetch_type = (create_full_pack) ? "clone" : "fetch";
>> + run_hook(get_index_file(), "post-upload-pack", fetch_type);
>> +}
>
> Does it really need an index file? This operation in question seems to
> be totally disconnected from the index (and indeed, most bare
> repositories won't even have one). Probably it should pass NULL as the
> initial argument to run_hook.
Very good point; a bare repository does not have to have (and typically
shouldn't have) the index, and a bare repository is what upload-pack
typically serves.
A short-and-sweet:
run_hook(NULL, "post-upload-pack",
create_full_pack ? "clone" : "fetch,
NULL);
would be sufficient. Notice that run_hook() is variadic and its argument
list needs to be terminated with NULL (iow, the original patch is buggy
and risks reading random places on the stack---I would recommend against
using it on your production site yet).
> Is there any other information that might be useful to other non-GitHub
> users of the hook? The only thing I can think of is the list of refs
> that were fetched.
I do not think that information is available. "want" will tell you what
object they want, but that does not necessarily uniquey translate to a
ref.
If we are allowed to talk about asking for the moon, and if one of the
primary reason for this new hook is statistics, it would be useful to see
the number of bytes given, where the fetch-pack came from, and if we are
using git-daemon virtual hosting which of our domain served the request.
^ permalink raw reply
* Re: git svn messages
From: Peter Harris @ 2009-08-25 22:49 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
In-Reply-To: <43d8ce650908251531n397ba6e1xe71e80d7b8a08344@mail.gmail.com>
On Tue, Aug 25, 2009 at 6:31 PM, John Tapsell wrote:
> Hi all,
>
> When doing git svn dcommit, the messages that it gives are, well,
> frightening :-)
Some moreso than others, depending on your level of familiarity with git. :-)
> It's full of things like:
>
>> No changes between current HEAD and refs/remotes/git-svn
>
> No changes? What's gone wrong? Why can't it find any changes?..
Because you aren't working from a branch-point older than your current
refs/remotes/git-svn. I suppose one could misinterpret that as a
bidirectional "no changes". Still, the message doesn't contain a scary
prefix like "Error:" or even "Warning:". It's just informational.
>> Resetting to the latest refs/remotes/git-svn
>
> That doesn't sound good. Why did it have reset?
Because the newly created svn commits are a different DAG from your
former DAG (which contained git commits that weren't in svn yet), even
though the tree contents are the same. The way git-svn tells the rest
of git about this change is by running the "git reset" command.
You can run "gitk" before you run "git svn dcommit", then hit refresh
(F5, I believe) after "git svn dcommit" is done to get a more visual
idea of what is going on.
Peter Harris
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Junio C Hamano @ 2009-08-25 22:42 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill A. Korinskiy, git
In-Reply-To: <20090825215726.GA30981@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Aug 25, 2009 at 11:27:47PM +0400, Kirill A. Korinskiy wrote:
>
>> +test_expect_success 'clone' '
>> +
>> + git clone parent clone &&
>> + (cd clone && git rev-parse --verify refs/remotes/origin/master)
>> +
>> +'
>> +
>> +test_expect_success 'clone -b' '
>> +
>> + git clone -b two parent clone-b &&
>> + (cd clone-b && test $(git rev-parse --verify HEAD) = $(git rev-parse --verify refs/remotes/origin/two))
>> +
>> +'
>
> OK, I think that second test makes sense (though please wrap the very
> long line), but now what is the first one doing? Shouldn't it be:
>
> (cd clone &&
> test $(git rev-parse --verify HEAD) = \
> $(git rev-parse --verify refs/remotes/origin/master)
> )
>
> also?
Are you checking that the HEAD (whichever branch it points at) points at
the same commit, or are you also interested in the _current branch_ to be
a particular name as well? The suggested check only compares commits and
HEAD can be pointing at a local branch whose name is xyzzy.
What is the semantics of this new -b option? When the remote repository
has 'next' as its default branch (i.e. HEAD points at it), and if you run
clone with "-b maint" against it, I expect that the checked out commit
will be the 'maint' of remote repository, but what is the name of the
current branch in the resulting clone on our end?
- Would we use 'master' as the name of our current branch, because that
is the default?
- Would we use 'next' as the name of our current branch, because that is
what the remote side uses?
- Would we use 'maint', because that is what -b gave us?
I am _hoping_ it is the last one, as otherwise you would also need to make
sure that the branch that is different from 'maint' we set as the current
branch must track 'maint' from the remote.
Oh, with -b, would we set up our 'maint' to track their 'maint'? Is it
something you may want to verify as well?
^ 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