* Re: jgit performance update
From: Shawn Pearce @ 2006-12-04 0:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekvoan$lst$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> I got:
> $ git clone http://www.spearce.org/projects/scm/egit.git
> [...]
> got 73ed47b2bb1fa5978f7368775979e5c85d354c5a
> error: File 2332eacf114debb7a27d138811197f06eb262551
> (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41ebbd87d8f8968529e9c30) corrupt
> Getting pack list for http://www.spearce.org/projects/scm/egit.git/
> got afefbe09bacc08adb75fb46200a973001c6b02de
> [...]
> walk c1f287cb19b9910af19756cf29c08b1fda75da8c
> Some loose object were found to be corrupt, but they might be just
> a false '404 Not Found' error message sent with incorrect HTTP
> status code. Suggest running git fsck-objects.
> got eab86de8ac23e2e77878835007724146fdd83796
> $ git fsck-objects --unreachable --full --strict ;# returns no errors
Right. My web server doesn't send back 404 messages when an object
isn't found (but is packed). Thus the error...
I've setup a project on repo.or.cz:
http://repo.or.cz/w/egit.git
--
^ permalink raw reply
* Re: [DRAFT 2] Branching and merging with git
From: J. Bruce Fields @ 2006-12-04 1:19 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061120235136.4841.qmail@science.horizon.com>
On Mon, Nov 20, 2006 at 06:51:36PM -0500, linux@horizon.com wrote:
> I tried to incorporate all the suggestions. There are still a few things
> I have to research, and now I'm worried it's getting too long. Sigh.
If you made another pass for it asking whether each sentence was really
absolutely necessary you'd be able to cut quite a bit without
compromising on content. One example:
> In CVS, branches are difficult and awkward to use, and generally
> considered an advanced technique. Many people use CVS for a long time
> without departing from the trunk.
Lots of people have CVS experience, but not everyone does, and this
paragraph isn't really necessary. Cut it out, and the following
paragraph (minus first sentence) stands just fine on its own:
> Git is very different. Branching and merging are central to effective use
> of git, and if you aren't comfortable with them, you won't be comfortable
> with git. In particular, they are required to share work with other
> people.
Note also "if you aren't comfortable with them..." just repeats
something you've already said. So now we're down to just:
"Branching and merging are central to effective use of git. In
particular, they are required to share work with other people."
which is short and to the point. Neat!
I'm not sure of the ordering. For example:
> The only things that are a bit confusing are some of the names.
> In particular, at least when beginning:
> - You create new branches with "git checkout -b".
> "git branch" should only be used to list and delete branches.
> - You share work with "git fetch" and "git push". These are opposites.
> - You merge with "git pull", not "git merge". "git pull" can also do a
> "git fetch", but that's optional. What's not optional is the merge.
>
> Also, a good habit it to never commit directly to your main "master"
> branch. Do all work in temporary "topic" branches, and then merge them
> into the master. Most experienced users don't bother to be quite this
> purist, but you should err on the side of using separate topic branches,
> so it's excellent practice.
We're diving in here without explaining what checkout, fetch, push,
pull, or merge are yet, or what the master branch is.
The document seems to be targetted at someone who has read some
scattered git documentation, gotten confused, and needs help putting it
all together. This is understandable--there are a lot of people like
that right now! But if we're going to get the documentation in some
sort of sensible order then we need to think about how to start with
someone who is a blank slate and lead them step by step to what they
most need to know.
That doesn't mean *you* need to do everything from scratch, but it would
be helpful to figure out where this would fit in with the other
documentation in a logical progression. As a start, the first paragraph
could say "before reading this, we assume you've read X, Y, and Z", and
then the rest of the document could be audited to make sure that it
didn't assume anything that isn't in X, Y, and Z.
^ permalink raw reply
* Re: [PATCH] [checkout-index] Give names to stages
From: Junio C Hamano @ 2006-12-04 2:00 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <651451.91694.qm@web31813.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> One can now say "git-checkout-index --stage=ours ..." or
> "git-checkout-index --stage=theirs ...", instead of having
> to remember the corresponding number assigned to each stage.
I really do not like to have this in checkout-index; I would
rather keep checkout-index a purely plumbing thing. If there
are valid and frequently appearing use cases that currently
requires "checkout-index --stage=$n", I think that need should
be addressed as a missing feature in the UI layer.
During a conflicted merge, you may run "diff --cc" in order to
decide that you would want to take yours (or theirs), and that
would be a good reason to wanting to checkout "your" version (or
"their" version; but I do not think of a valid reason to want to
say "checkout-index --stage=1"). From the UI point of view, it
would make more sense to be able to say:
$ git checkout --ours hello.c
$ git checkout --theirs Makefile
If the user is interested in looking at raw copies of our and
their version for comparison (not just "diff --theirs" kind of
usage), it _might_ even make sense to be able to do:
$ git checkout --stdout --ours hello.c >hello.c-ours
$ git checkout --stdout --theirs hello.c >hello.c-theirs
$ diff -u hello.c-ours hello.c-theirs
I do not particularly like the above overloaded meaning of
"checkout" myself, but that would be something people who are
used to "cvs up -p" might expect to be able to do.
If we were to do both of the above, then it might even make
sense to make the first form (sans --stdout) to also mark the
index entry after checking out the specified higher stage.
And the UI layer (Porcelain-ish) should be where we should add
the "usability" and "human readability" bits.
^ permalink raw reply
* Re: [PATCH] Document git-diff whitespace flags -b and -w
From: Junio C Hamano @ 2006-12-04 2:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612032006580.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> make tests pass for recent "diff -b" change
Both patches look sane. Thanks. Mind if I forge your
signature?
> Am I the only one finding it funny to read diffs of diffs,
> especially when being used to combined diffs?
I agree that it is very hard to get used to.
^ permalink raw reply
* Re: [RFC] gitweb: Add committags support (take 2)
From: Junio C Hamano @ 2006-12-04 2:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612040001.13640.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> The subroutine should return either reference to scalar which means
> "do not process", scalar which means changed available for further
> processing, or void (undef) which means no change. In [PATCH 2/3] we
> will enable returning also list of elements, each of which could be
> reference to scalar or scalar (for example signoff would return three
> element list: opening span element as ref, signoff text as scalar,
> closing span element as ref).
Personally I think that "list of elements" should be in the
first patch to build the foundation.
> our %committags = (
> 'sha1' => {
> 'pattern' => qr/[0-9a-fA-F]{40}/,
> 'sub' => sub {
> my $hash_text = shift;
> my $type = git_get_type($hash_text);
> if ($type) {
> return \$cgi->a({-href => href(action=>$type, hash=>$hash_text),
> -class => "text"}, $hash_text);
> }
> return undef;
> },
> },
It might make sense to do a /[0-9a-f]{8,40}/ pattern, and make
sure that the named object exists in the sub (which you already
do). People often write abbreviated commit object name that has
a high chance of staying unique during the life of the project.
> 'mantis' => {
> 'pattern' => qr/(BUG|FEATURE)\(\d+\)/,
> 'bugzilla' => {
> 'pattern' => qr/bug\s+\d+/,
This is not wrong per-se but somehow feels funny. It feels as
if there is a convention that bugzilla bugs are usually spelled
in lowercase while mantis bugs are in uppercase, but I do not
think you are suggesting that.
I do not know how this %committags{} is used per project. With
a setting like repo.or.cz, it is likely that one instance of
gitweb is serving unrelated projects that have their issue
tracker at different locations using different "committags"
convention. Is the idea to eventually allow enabling/disabling
elements from the global %committags per repository somehow
(perhaps not just enable/disable but even overriding patterns or
parameters)?
> 3. To not split message into many fragments we concatenate strings
> if possible.
I do not know why "avoiding splits" is needed, if it raises
issues that you need to ask the list about in a message like
this...
^ permalink raw reply
* Re: Set permissions of each new file before "cvs add"ing it.
From: Junio C Hamano @ 2006-12-04 2:41 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87ac24zrk0.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Without the following patch, git-cvsexportcommit would fail to propagate
> permissions of files added in git to the CVS repository. I.e., when I
> added an executable script in coreutils' git repo, then tried to propagate
> that addition to the mirroring CVS repository, the script ended up added
> not executable there.
Thanks. But...
> +# For any file we want to add to cvs, we must first set its permissions
> +# properly, *before* the "cvs add ..." command. Otherwise, it is impossible
> +# to change the permission of the file in the CVS repository using only cvs
> +# commands. This should be fixed in cvs-1.12.14.
> +sub set_new_file_permissions {
> + my ($file) = @_;
> + # Given input like this:
> + # ba45154d8e9f5f49f46c8c2c2d8a554db7c3465f ...
> + # :000000 100755 0000000... b595dc6... A tests/du/one-file-system
> + # extract the three octal permission digits:
> + my $cmd = 'git-whatchanged --max-count=1 --pretty=oneline -- $f'
> + . q! | sed -n '2s/^:00* [0-7][0-7][0-7]\([0-7][0-7][0-7]\) .*/\1/p'!;
> + my $perm = `$cmd`;
> +
> + chmod oct($perm), $file
> + or die "failed to set permissions of \"$file\": $!\n";
> +}
Why sed in a Perl script ;-)?
^ permalink raw reply
* Re: Set permissions of each new file before "cvs add"ing it.
From: Junio C Hamano @ 2006-12-04 2:47 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <7vbqmktmb7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jim Meyering <jim@meyering.net> writes:
>
>> Without the following patch, git-cvsexportcommit would fail to propagate
>> permissions of files added in git to the CVS repository...
> ...
> Why sed in a Perl script ;-)?
That is,...
-- >8 --
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 7bac16e..7f70501 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -116,6 +116,7 @@ if ($opt_a) {
close MSG;
my (@afiles, @dfiles, @mfiles, @dirs);
+my (%amodes);
my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
#print @files;
$? && die "Error in git-diff-tree";
@@ -124,6 +125,7 @@ foreach my $f (@files) {
my @fields = split(m!\s+!, $f);
if ($fields[4] eq 'A') {
my $path = $fields[5];
+ $amodes[$path] = $fields[1];
push @afiles, $path;
# add any needed parent directories
$path = dirname $path;
@@ -268,6 +270,7 @@ if (($? >> 8) == 2) {
}
foreach my $f (@afiles) {
+ set_new_file_permissions($f, $amodes[$f]);
if (grep { $_ eq $f } @bfiles) {
system('cvs', 'add','-kb',$f);
} else {
@@ -342,3 +345,13 @@ sub safe_pipe_capture {
}
return wantarray ? @output : join('',@output);
}
+
+# For any file we want to add to cvs, we must first set its permissions
+# properly, *before* the "cvs add ..." command. Otherwise, it is impossible
+# to change the permission of the file in the CVS repository using only cvs
+# commands. This should be fixed in cvs-1.12.14.
+sub set_new_file_permissions {
+ my ($file, $perm) = @_;
+ chmod oct($perm), $file
+ or die "failed to set permissions of \"$file\": $!\n";
+}
^ permalink raw reply related
* latest update to git-svn blows up for me
From: Randal L. Schwartz @ 2006-12-04 4:00 UTC (permalink / raw)
To: git
Does this ring a bell?
Fetching git-svn
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/MisplacedShebang.pm
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitShebangWarningsArg.pm
M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/RequirePortableShebang.pm
M trunk/compilers/past-pm/POST/Compiler.pir
M trunk/compilers/past-pm/PAST/Compiler.pir
M trunk/compilers/past-pm/PAST-pm.pir
M trunk/languages/perl6/src/quote.pir
M trunk/languages/perl6/src/classes/Str.pir
M trunk/languages/perl6/src/classes/Code.pir
M trunk/languages/perl6/src/classes/Num.pir
M trunk/languages/plumhead/t/selection.txt
M trunk/languages/plumhead/t/superglobals.t
M trunk/languages/plumhead/t/strings.t
M trunk/languages/tcl/runtime/builtin/clock.pir
no blob information
512 at /opt/git/bin/git-svn line 457
main::fetch_lib() called at /opt/git/bin/git-svn line 328
main::fetch() called at /opt/git/bin/git-svn line 973
main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
main::multi_fetch() called at /opt/git/bin/git-svn line 187
512 at /opt/git/bin/git-svn line 980
main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
main::multi_fetch() called at /opt/git/bin/git-svn line 187
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: [PATCH] [checkout-index] Give names to stages
From: Luben Tuikov @ 2006-12-04 5:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wngv2rc.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > One can now say "git-checkout-index --stage=ours ..." or
> > "git-checkout-index --stage=theirs ...", instead of having
> > to remember the corresponding number assigned to each stage.
>
> I really do not like to have this in checkout-index; I would
> rather keep checkout-index a purely plumbing thing. If there
> are valid and frequently appearing use cases that currently
> requires "checkout-index --stage=$n", I think that need should
> be addressed as a missing feature in the UI layer.
Sometimes when I pull things from a bunch of places and do
a resolve, I'm presented with the standard resolve format of
a source file, "<<<< ==== >>>>" thingie, and all I'd really
like to do is "accept ours". I.e. something similar to what I've
seen in other (commercial) SCMs, a la "scm resolve accept ours".
This patch merely allows the user to say
git-checkout-index --stage=ours their_broken_file.c
instead of
git-checkout-index --stage=2 their_broken_file.c
and similarly for "theirs", etc.
If you think this breaks the ideology, ok.
Luben
> During a conflicted merge, you may run "diff --cc" in order to
> decide that you would want to take yours (or theirs), and that
> would be a good reason to wanting to checkout "your" version (or
> "their" version; but I do not think of a valid reason to want to
> say "checkout-index --stage=1"). From the UI point of view, it
> would make more sense to be able to say:
>
> $ git checkout --ours hello.c
> $ git checkout --theirs Makefile
>
> If the user is interested in looking at raw copies of our and
> their version for comparison (not just "diff --theirs" kind of
> usage), it _might_ even make sense to be able to do:
>
> $ git checkout --stdout --ours hello.c >hello.c-ours
> $ git checkout --stdout --theirs hello.c >hello.c-theirs
> $ diff -u hello.c-ours hello.c-theirs
>
> I do not particularly like the above overloaded meaning of
> "checkout" myself, but that would be something people who are
> used to "cvs up -p" might expect to be able to do.
>
> If we were to do both of the above, then it might even make
> sense to make the first form (sans --stdout) to also mark the
> index entry after checking out the specified higher stage.
>
> And the UI layer (Porcelain-ish) should be where we should add
> the "usability" and "human readability" bits.
^ permalink raw reply
* Re: [PATCH] [checkout-index] Give names to stages
From: Junio C Hamano @ 2006-12-04 6:32 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <505428.75434.qm@web31808.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Sometimes when I pull things from a bunch of places and do
> a resolve, I'm presented with the standard resolve format of
> a source file, "<<<< ==== >>>>" thingie, and all I'd really
> like to do is "accept ours". I.e. something similar to what I've
> seen in other (commercial) SCMs, a la "scm resolve accept ours".
>
> This patch merely allows the user to say
> git-checkout-index --stage=ours their_broken_file.c
> instead of
> git-checkout-index --stage=2 their_broken_file.c
> and similarly for "theirs", etc.
That's _exactly_ my point. It "merely allows to".
> If you think this breaks the ideology, ok.
It's not about the ideology. It's in the part you quoted but
did not respond to (by the way, please don't quote the the bulk
of the message if you are not responding to it).
You stopped at only adding "ours" as synonym for "2" and did not
do anything else in the patch; it is a very sensible thing to
do, because "checkout-index" is a plumbing command that is about
checking out files from the index to the working tree.
But that means you HAVE TO stop at that because you are working
at the plumbing layer. You said yourself that what you really
wanted to do was "scm resolve accept ours". And from an end
user's point of view, "checkout --stage=ours" is NOT it.
A user who wants to see "accept ours" wants the scm to perform:
git checkout-index --stage=2 paths...
git update-index paths... ;# or Nico's "git add"
for him. That is why I suggested to hoist the place you
implement this usability improvement up one level and make the
Porcelain level command:
git checkout --ours paths...
to do the above two plumbing command sequence internally for the
end user.
^ permalink raw reply
* Re: [PATCH] [checkout-index] Give names to stages
From: Luben Tuikov @ 2006-12-04 6:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ix8rx19.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Sometimes when I pull things from a bunch of places and do
> > a resolve, I'm presented with the standard resolve format of
> > a source file, "<<<< ==== >>>>" thingie, and all I'd really
> > like to do is "accept ours". I.e. something similar to what I've
> > seen in other (commercial) SCMs, a la "scm resolve accept ours".
> >
> > This patch merely allows the user to say
> > git-checkout-index --stage=ours their_broken_file.c
> > instead of
> > git-checkout-index --stage=2 their_broken_file.c
> > and similarly for "theirs", etc.
>
> That's _exactly_ my point. It "merely allows to".
>
> > If you think this breaks the ideology, ok.
>
> It's not about the ideology. It's in the part you quoted but
> did not respond to (by the way, please don't quote the the bulk
> of the message if you are not responding to it).
>
> You stopped at only adding "ours" as synonym for "2" and did not
> do anything else in the patch; it is a very sensible thing to
> do, because "checkout-index" is a plumbing command that is about
> checking out files from the index to the working tree.
>
> But that means you HAVE TO stop at that because you are working
> at the plumbing layer. You said yourself that what you really
> wanted to do was "scm resolve accept ours". And from an end
> user's point of view, "checkout --stage=ours" is NOT it.
>
> A user who wants to see "accept ours" wants the scm to perform:
>
> git checkout-index --stage=2 paths...
> git update-index paths... ;# or Nico's "git add"
Yes, that's what I normally do.
> for him. That is why I suggested to hoist the place you
> implement this usability improvement up one level and make the
> Porcelain level command:
>
> git checkout --ours paths...
>
> to do the above two plumbing command sequence internally for the
> end user.
Ok.
Luben
^ permalink raw reply
* Re: latest update to git-svn blows up for me
From: Eric Wong @ 2006-12-04 7:00 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863b7wnwcw.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
>
> Does this ring a bell?
Nope.
> Fetching git-svn
> M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/MisplacedShebang.pm
> M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/ProhibitShebangWarningsArg.pm
> M trunk/lib/Perl/Critic/Policy/TestingAndDebugging/RequirePortableShebang.pm
> M trunk/compilers/past-pm/POST/Compiler.pir
> M trunk/compilers/past-pm/PAST/Compiler.pir
> M trunk/compilers/past-pm/PAST-pm.pir
> M trunk/languages/perl6/src/quote.pir
> M trunk/languages/perl6/src/classes/Str.pir
> M trunk/languages/perl6/src/classes/Code.pir
> M trunk/languages/perl6/src/classes/Num.pir
> M trunk/languages/plumhead/t/selection.txt
> M trunk/languages/plumhead/t/superglobals.t
> M trunk/languages/plumhead/t/strings.t
> M trunk/languages/tcl/runtime/builtin/clock.pir
> no blob information
> 512 at /opt/git/bin/git-svn line 457
> main::fetch_lib() called at /opt/git/bin/git-svn line 328
> main::fetch() called at /opt/git/bin/git-svn line 973
> main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
> main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
> main::multi_fetch() called at /opt/git/bin/git-svn line 187
> 512 at /opt/git/bin/git-svn line 980
> main::fetch_child_id('git-svn') called at /opt/git/bin/git-svn line 991
> main::rec_fetch('', '/Volumes/UFS/MIRROR/parrot-GITSVN/.git/svn') called at /opt/git/bin/git-svn line 747
> main::multi_fetch() called at /opt/git/bin/git-svn line 187
This is on r15941 of https://svn.perl.org/parrot/trunk ? I can't seem
to reproduce this with git svn fetch -r15940:15941
--
^ permalink raw reply
* [PATCH]: Pass -M to diff in request-pull
From: David Miller @ 2006-12-04 7:17 UTC (permalink / raw)
To: junkio; +Cc: git
Linus recommended this, otherwise any renames cause the
diffstate output to be rediculious in some circumstances :)
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 4319e35..4eacc3a 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -30,4 +30,4 @@ echo " $url"
echo
git log $baserev..$headrev | git-shortlog ;
-git diff --stat --summary $baserev..$headrev
^ permalink raw reply related
* Re: [DRAFT 2] Branching and merging with git
From: J. Bruce Fields @ 2006-12-04 7:23 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061204011958.GB28043@fieldses.org>
On Sun, Dec 03, 2006 at 08:19:58PM -0500, J. Bruce Fields wrote:
> That doesn't mean *you* need to do everything from scratch, but it would
> be helpful to figure out where this would fit in with the other
> documentation in a logical progression. As a start, the first paragraph
> could say "before reading this, we assume you've read X, Y, and Z", and
> then the rest of the document could be audited to make sure that it
> didn't assume anything that isn't in X, Y, and Z.
By the way, I have some draft rough work on getting that introductory
documentation organized at
git://linux-nfs.org/~bfields/git.git
See Documentation/user-manual.txt and Documentation/quick-start.txt. I
think I've stolen a small amount of text from you--hope that's OK!
I have two ideas in mind:
- The tutorial is supposed to a very quick "look what git can
do" document, but people also want it to really explain git,
prepare people to read the man pages, etc., which will make it
much longer over time. So I'm trying to split out an
extremely concise "quick-start" guide (modelled partly on
Mercurial's) that doesn't even pretend to explain anything, and
a "user manual" that's much more verbose and tries to cover
the basics comprehensively.
- A lot of people don't actually need to do commits or merges at
all--they just need to know how to clone a repository, check
out a few versions, etc. (Witness the number of web pages
with "how to check out our latest code from CVS" out
there....) I'm also assuming most people are joining an
ongoing project instead of creating a new one. So instead of
starting right away with init-db/add/commit, I'm putting off
actual "development" stuff till pretty late:
1. clone
2. checking out old versions, basic branch management
3. keeping up-to-date with fetch
4. bisect
5. archaeology (commits DAG, git-log, ...)
6. creating commits, index file
7. resolving merges, pull
8. publishing a public repository, push
etc. I'm hoping you'd be interested in working together on
the last parts (7 and 8 especially).
Comments welcomed...
^ permalink raw reply
* Re: Set permissions of each new file before "cvs add"ing it.
From: Jim Meyering @ 2006-12-04 7:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64cstm0x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Jim Meyering <jim@meyering.net> writes:
>>
>>> Without the following patch, git-cvsexportcommit would fail to propagate
>>> permissions of files added in git to the CVS repository...
>> ...
>> Why sed in a Perl script ;-)?
Yeah, yeah, I was rushed.
There are existing uses of `git-ls-tree ... | cut ...` :-)
Ahh. Your approach is better.
Your patch works fine (once I changed $amodes[] to $amodes{}).
> +my (%amodes);
...
> + $amodes[$path] = $fields[1];
...
> + set_new_file_permissions($f, $amodes[$f]);
I tested it with the following script.
New patch below.
Thank you!
--------------------------------------------
#!/bin/sh
rm -rf g c m
mkdir g c
top=`pwd`
cvs_repo=$top/c
(
cd g
git-init-db
touch a
git-add a
git-commit -m.
echo foo > f
chmod a+x f
git-add f
git-commit -m.
)
cvs -Q -d $cvs_repo init
mkdir $cvs_repo/m
cvs -Q -f -q -d $cvs_repo co m
cd m
fail=0
export GIT_DIR=$top/g/.git
git-cvsexportcommit -c -p -v HEAD
test -x f || fail=1
rm -f f a
cvs -Q up
test -x f || fail=1
test -x a && fail=1
exit $fail
--------------------------------
Here's the patch I tested:
From: Jim Meyering <jim@meyering.net>
Date: Mon, 4 Dec 2006 08:44:08 +0100
Subject: Set permissions of each new file before "cvs add"ing it.
Otherwise, an executable script in git would end up being
checked into the CVS repository without the execute bit.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
git-cvsexportcommit.perl | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 7bac16e..c9d1d88 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -116,6 +116,7 @@ if ($opt_a) {
close MSG;
my (@afiles, @dfiles, @mfiles, @dirs);
+my %amodes;
my @files = safe_pipe_capture('git-diff-tree', '-r', $parent, $commit);
#print @files;
$? && die "Error in git-diff-tree";
@@ -124,6 +125,7 @@ foreach my $f (@files) {
my @fields = split(m!\s+!, $f);
if ($fields[4] eq 'A') {
my $path = $fields[5];
+ $amodes{$path} = $fields[1];
push @afiles, $path;
# add any needed parent directories
$path = dirname $path;
@@ -268,6 +270,7 @@ if (($? >> 8) == 2) {
}
foreach my $f (@afiles) {
+ set_new_file_permissions($f, $amodes{$f});
if (grep { $_ eq $f } @bfiles) {
system('cvs', 'add','-kb',$f);
} else {
@@ -342,3 +345,13 @@ sub safe_pipe_capture {
}
return wantarray ? @output : join('',@output);
}
+
+# For any file we want to add to cvs, we must first set its permissions
+# properly, *before* the "cvs add ..." command. Otherwise, it is impossible
+# to change the permission of the file in the CVS repository using only cvs
+# commands. This should be fixed in cvs-1.12.14.
+sub set_new_file_permissions {
+ my ($file, $perm) = @_;
+ chmod oct($perm), $file
+ or die "failed to set permissions of \"$file\": $!\n";
+}
--
^ permalink raw reply related
* Re: [PATCH]: Pass -M to diff in request-pull
From: Junio C Hamano @ 2006-12-04 8:35 UTC (permalink / raw)
To: David Miller; +Cc: junkio, git
In-Reply-To: <20061203.231700.55509531.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> Linus recommended this, otherwise any renames cause the
> diffstate output to be rediculious in some circumstances :)
Thanks, but "rediculious"?
I think this makes sense, especially as it matches what we
show after a git-pull that ought to match the request.
^ permalink raw reply
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Eric Wong @ 2006-12-04 8:52 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <871wnget3b.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> wrote:
> * Eric Wong:
>
> > finish_report does seem to return a useful value indicating success
> > or failure, so we'll just set a flag when close_edit is called
> > (it is not called on failures, nor is abort_edit) and check
> > the flag before proceeding.
>
> It seems that this needs some kind of fine-tuning. Now that git-svn
> uses HTTP keepalive connections, you get a HTTP request error once you
> run into the server-side request limit. It seems a bit excessive to
> stop completely in this case.
Does the following patch help?
From: Eric Wong <normalperson@yhbt.net>
Date: Mon, 4 Dec 2006 00:51:16 -0800
Subject: [PATCH] git-svn: avoid network timeouts for long-running fetches
Long-running fetches run inside children to avoid memory leaks.
When we refork, the connection in the parent can be idle for a
long time; attempting to reuse it in the next child can result
in timeouts.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d0bd0bd..747daf0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -459,6 +459,7 @@ sub fetch_lib {
$min = $max + 1;
$max += $inc;
$max = $head if ($max > $head);
+ $SVN = libsvn_connect($SVN_URL);
}
restore_index($index);
return { revision => $last_rev, commit => $last_commit };
--
^ permalink raw reply related
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Florian Weimer @ 2006-12-04 8:56 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061204085253.GA31047@soma>
* Eric Wong:
> Does the following patch help?
Don't think so. The issue is not timing-related. I've seen a failure
every 1000 requests, which suggests to me that it's hitting the
^ permalink raw reply
* Re: [PATCH] Document git-diff whitespace flags -b and -w
From: Johannes Schindelin @ 2006-12-04 9:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvekstn9t.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 3 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > make tests pass for recent "diff -b" change
>
> Both patches look sane. Thanks. Mind if I forge your
> signature?
Not at all. I forget it, you forge it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-svn: error out when the SVN connection fails during a fetch
From: Eric Wong @ 2006-12-04 9:05 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87zma4yr71.fsf@mid.deneb.enyo.de>
Florian Weimer <fw@deneb.enyo.de> wrote:
> * Eric Wong:
>
> > Does the following patch help?
>
> Don't think so. The issue is not timing-related. I've seen a failure
> every 1000 requests, which suggests to me that it's hitting the
> MaxKeepAliveRequests limit configured on the server.
Actually, that's exactly what this patch should fix. git-svn restarts a
child every 1000 revisions to avoid memory usage from going through the
roof.
--
^ permalink raw reply
* Re: [PATCH] Print progress message to stderr, not stdout
From: Catalin Marinas @ 2006-12-04 9:17 UTC (permalink / raw)
To: Marco Costalba; +Cc: Karl Hasselström, git
In-Reply-To: <e5bfff550612020520w3ad48a09xfdde63b9050a75cf@mail.gmail.com>
On 02/12/06, Marco Costalba <mcostalba@gmail.com> wrote:
> On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> > Printing progress messages to stdout causes them to get mixed up with
> > the actual output of the program. Using stderr is much better, since
> > the user can then redirect the two components separately.
>
> This patch breaks qgit.
>
> GUI interface to stgit pop and push commands is broken because a
> command that prints to stderr is considered a failing one by qgit.
>
> I would kindly ask you to:
>
> 1 - Revert the patch. That would be the best. You can use a prefix to
> printed message instead, see git pull, something like 'stg: bla bla
> bla' . In any case, IMHO, using stderr for normal activity logging
> does not sound like a great idea in general.
>
> 2 - At least add a '-v' '--verbose' option that defaults to quiet so
> to not break back compatibility.
Since there are other tools relying on a clean stderr, I think I would
revert it and add a verbose flag and/or config option. Karl, any
thoughts on this (since you sent the patch)?
--
^ permalink raw reply
* Re: problem in unpack-trees.c
From: Junio C Hamano @ 2006-12-04 9:53 UTC (permalink / raw)
To: Roman Zippel; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612022125530.1867@scrub.home>
Roman Zippel <zippel@linux-m68k.org> writes:
> I looked into it and the problem is during the "git-read-tree --reset"
> step and it seems that the local df_conflict_entry variable of
> unpack_trees() survives past that function. If you check in
> add_cache_entry() it's called with this variable and only because
> verify_path() fails it's not added to the tree on the other archs, but on
> m68k the data on the stack is a bit different and thus verify_path()
> succeeds and the stack variable is added to the tree and later saved.
I am very puzzled about this.
You are correct that the address of the df_conflict_entry is
assigned to "struct unpack_trees_options *o" in unpack_trees(),
and add_cache_entry() are called from many places in the call
chain that starts from that function. And these call sites do
rely on the conflict_entry to have a NUL name to prevent
add_cache_entry from adding the entry to the index. Which feels
like a hack, but it should get the job done while it is running.
But I do not see the o->df_conflict_entry used after unpack_trees()
returns in git-read-tree.
> Using the patch below, you can simulate what's happing on m68k...
The patch does not compile for me (the static definition part),
but it appears that the memset() in question is not clearing the
name field.
Ah....
Oops....
Isn't "struct cache_entry" a structure with a flexible array
member at the end? I wonder why we have it on the stack to
begin with.
On my x86-64 box with gcc 4 (i.e. "#define FLEX_ARRAY /* empty */"
is used,
#include "cache.h"
int
main(int ac, char **av)
{
printf("sz %zu\n", sizeof(struct cache_entry));
printf("of %zu\n", offsetof(struct cache_entry, name));
memset(&dfc, 0, sizeof(dfc));
}
size of "struct cache_entry" is 64 while the offset of name
member is 62, so I am luckily getting two bytes of room for
memset to fill and cause name[] to be properly NUL terminated.
If the alignment requirement of the platform is smaller, we may
be overstepping the struct when we access its name[] member.
^ permalink raw reply
* Re: [PATCH 1/2] move Git.pm build instructions into perl/Makefile
From: Alex Riesen @ 2006-12-04 9:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvektyi7n.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On 12/3/06, Junio C Hamano <junkio@cox.net> wrote:
> > This is the first patch, just rebased upon current master.
> > The ActiveState-related parts follow
>
> diff --git a/perl/.gitignore b/perl/.gitignore
> index e990cae..98b2477 100644
> --- a/perl/.gitignore
> +++ b/perl/.gitignore
> @@ -1,4 +1,5 @@
> -Makefile
> +perl.mak
> +perl.mak.old
> blib
> blibdirs
> pm_to_blib
>
> This, and perl/Makefile not cleaning perl.mak.old, are wrong.
How is this wrong, and the previous (for when there weren't
Makefile at all) Makefile-in-.gitignore is not?
These are generated files, what do you want to preserve them for?
> "make && make clean" after a fresh checkout should leave the
> working tree the same state is it were.
oh, right. Missed it (never seen it generated, BTW. Just took
from Pasky's code that it happens).
Updated patch attached.
[-- Attachment #2: perl-makefile.patch --]
[-- Type: text/x-diff, Size: 3395 bytes --]
Author: Alex Riesen <raa.lkml@gmail.com>
Date: Mon Dec 4 10:50:04 2006 +0100
Subject: Move Git.pm build instructions into perl/Makefile
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
diff --git a/Makefile b/Makefile
index de3e9f3..3e6825b 100644
--- a/Makefile
+++ b/Makefile
@@ -539,6 +539,9 @@ endif
ifdef NO_ACCURATE_DIFF
BASIC_CFLAGS += -DNO_ACCURATE_DIFF
endif
+ifdef NO_PERL_MAKEMAKER
+ export NO_PERL_MAKEMAKER
+endif
# Shell quote (do not use $(call) to accommodate ancient setups);
@@ -568,8 +571,8 @@ export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
-all: perl/Makefile
- $(MAKE) -C perl
+all:
+ $(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
$(MAKE) -C templates
strip: $(PROGRAMS) git$X
@@ -602,7 +605,11 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
chmod +x $@+
mv $@+ $@
-$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/Makefile
+$(patsubst %.perl,%,$(SCRIPT_PERL)): perl/perl.mak
+
+perl/perl.mak: GIT-CFLAGS
+ $(MAKE) -C perl PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' $(@F)
+
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
rm -f $@ $@+
INSTLIBDIR=`$(MAKE) -C perl -s --no-print-directory instlibdir` && \
@@ -796,7 +803,7 @@ install: all
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X gitk '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
- $(MAKE) -C perl install
+ $(MAKE) -C perl prefix='$(prefix_SQ)' install
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
then \
ln -f '$(DESTDIR_SQ)$(bindir_SQ)/git$X' \
@@ -866,8 +873,7 @@ clean:
rm -f $(htmldocs).tar.gz $(manpages).tar.gz
rm -f gitweb/gitweb.cgi
$(MAKE) -C Documentation/ clean
- [ ! -f perl/Makefile ] || $(MAKE) -C perl/ clean || $(MAKE) -C perl/ clean
- rm -f perl/ppport.h perl/Makefile.old
+ $(MAKE) -C perl clean
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
rm -f GIT-VERSION-FILE GIT-CFLAGS
diff --git a/perl/.gitignore b/perl/.gitignore
index e990cae..98b2477 100644
--- a/perl/.gitignore
+++ b/perl/.gitignore
@@ -1,4 +1,5 @@
-Makefile
+perl.mak
+perl.mak.old
blib
blibdirs
pm_to_blib
diff --git a/perl/Makefile b/perl/Makefile
new file mode 100644
index 0000000..bd483b0
--- /dev/null
+++ b/perl/Makefile
@@ -0,0 +1,39 @@
+#
+# Makefile for perl support modules and routine
+#
+makfile:=perl.mak
+
+PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
+prefix_SQ = $(subst ','\'',$(prefix))
+
+all install instlibdir: $(makfile)
+ $(MAKE) -f $(makfile) $@
+
+clean:
+ test -f $(makfile) && $(MAKE) -f $(makfile) $@ || exit 0
+ $(RM) ppport.h
+ $(RM) $(makfile)
+ $(RM) $(makfile).old
+
+ifdef NO_PERL_MAKEMAKER
+instdir_SQ = $(subst ','\'',$(prefix)/lib)
+$(makfile): ../GIT-CFLAGS Makefile
+ echo all: > $@
+ echo ' :' >> $@
+ echo install: >> $@
+ echo ' mkdir -p $(instdir_SQ)' >> $@
+ echo ' $(RM) $(instdir_SQ)/Git.pm; cp Git.pm $(instdir_SQ)' >> $@
+ echo ' $(RM) $(instdir_SQ)/Error.pm; \
+ cp private-Error.pm $(instdir_SQ)/Error.pm' >> $@
+ echo instlibdir: >> $@
+ echo ' echo $(instdir_SQ)' >> $@
+else
+$(makfile): Makefile.PL ../GIT-CFLAGS
+ '$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
+endif
+
+# this is just added comfort for calling make directly in perl dir
+# (even though GIT-CFLAGS aren't used yet. If ever)
+../GIT-CFLAGS:
+ $(MAKE) -C .. GIT-CFLAGS
+
^ permalink raw reply related
* Re: problem in unpack-trees.c
From: Junio C Hamano @ 2006-12-04 10:00 UTC (permalink / raw)
To: Roman Zippel; +Cc: git
In-Reply-To: <7vodqkq956.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> If the alignment requirement of the platform is smaller, we may
> be overstepping the struct when we access its name[] member.
Would this help?
I do not think we need a separate identity for df_conflict_entry
per invocation of unpack_trees(), so this allocates one such
entry with NUL name at the first call to the function and reuses
it from the variable.
diff --git a/unpack-trees.c b/unpack-trees.c
index 7cfd628..47aa804 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -370,7 +370,7 @@ int unpack_trees(struct object_list *trees, struct unpack_trees_options *o)
int i;
struct object_list *posn = trees;
struct tree_entry_list df_conflict_list;
- struct cache_entry df_conflict_entry;
+ static struct cache_entry *dfc;
memset(&df_conflict_list, 0, sizeof(df_conflict_list));
df_conflict_list.next = &df_conflict_list;
@@ -381,8 +381,10 @@ int unpack_trees(struct object_list *trees, struct unpack_trees_options *o)
state.refresh_cache = 1;
o->merge_size = len;
- memset(&df_conflict_entry, 0, sizeof(df_conflict_entry));
- o->df_conflict_entry = &df_conflict_entry;
+
+ if (!dfc)
+ dfc = xcalloc(1, sizeof(struct cache_entry) + 1);
+ o->df_conflict_entry = dfc;
if (len) {
posns = xmalloc(len * sizeof(struct tree_entry_list *));
^ permalink raw reply related
* Re: On removing files and "git-rm is pointless"
From: Junio C Hamano @ 2006-12-04 10:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, Linus Torvalds, Carl Worth, Sam Vilain
In-Reply-To: <Pine.LNX.4.64.0612022246310.2630@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> I think what Linus is proposing makes tons of sense.
>
> If you do git rm by mistake then you can always do git checkout on that
> file to get it back.
>
> If you modified it so it doesn't match the index then git rm won't do
> anything by default so you have a chance to think a bit more.
>
> If you updated the index, didn't commit anything but then do git rm then
> you certainly wanted to really rm the file.
FWIW, I too am in favor of the proposed fix to "git rm" as Linus
outlined.
^ 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