* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Alexander Skwar @ 2007-11-01 13:06 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0710311742170.3342@woody.linux-foundation.org>
Linus Torvalds <torvalds <at> linux-foundation.org> writes:
>
>
> On Wed, 31 Oct 2007, Mike Hommey wrote:
> > + if type cpio > /dev/null 2>&1; then
> > + local=yes
> > + fi
>
> Isn't "type" a bashism?
ksh also has type. But SUS states, that "command -v" can be used.
Options
[...]
-v
(On systems supporting the User Portability Utilities option.)
Write a string to standard output that indicates the pathname or
command that will be used by the shell, in the current shell
execution environment (see Shell Execution Environment ), to
invoke command_name, but do not invoke command_name.
* Utilities, regular built-in utilities, command_names
including a slash character, and any implementation-defined
functions that are found using the PATH variable (as
described in Command Search and Execution ), shall be
written as absolute pathnames.
* Shell functions, special built-in utilities, regular
built-in utilities not associated with a PATH search, and
shell reserved words shall be written as just their names.
* An alias shall be written as a command line that represents
its alias definition.
* Otherwise, no output shall be written and the exit status
shall reflect that the name was not found.
Regards,
Alexander
^ permalink raw reply
* Re: Managing /etc with git: Store ownership and time in git?
From: Miklos Vajna @ 2007-11-01 13:09 UTC (permalink / raw)
To: Alexander Skwar; +Cc: git
In-Reply-To: <loom.20071101T123817-247@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
On Thu, Nov 01, 2007 at 12:55:57PM +0000, Alexander Skwar <listen@alexander.skwar.name> wrote:
> I'd like to use git to manage the /etc directories of some servers.
http://git.or.cz/gitwiki/GitFaq#head-7e70881352ec207609dc4d7eedbd0532946a5825
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Managing /etc with git: Store ownership and time in git?
From: Alexander Skwar @ 2007-11-01 12:55 UTC (permalink / raw)
To: git
Hello.
I'd like to use git to manage the /etc directories of some servers.
What's quite nice with git (in comparison to svn) is, that it
out-of-the-box stores the permissions of a file. But it doesn't seem
like it stores the ownership (ie. user/group) of tracked content.
Does anyone know how to cope with that "problem"?
Oh, and it also seems that Git doesn't store the time information of
files, does it? For tracking /etc, this would be very useful. Would
anyone have a solution for this as well?
What I'm thinking about right now is, to write a "hook" script which
"dumps" the stats of the to-be added files in some "index" file. But
that seems like a rather clumsy soltion...
It would be great of someone could maybe share his solution!
Thanks a lot,
Alexander
^ permalink raw reply
* Re: Question on git-filter-branch
From: Mike Hommey @ 2007-11-01 12:58 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18217.52425.655322.52338@lisa.zopyra.com>
On Thu, Nov 01, 2007 at 06:55:37AM -0600, Bill Lear wrote:
> In my repo, I have sensitive files A, C, and a directory full of
> sensitive stuff I want to remove forever from the git repository.
>
> % ls
> A B C D sensitive_stuff
>
> % git --version
> git version 1.5.3.5
>
> % git filter-branch --index-filter 'git update-index --remove A' HEAD
> Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
> Ref 'refs/heads/master' was rewritten
>
> These refs were rewritten:
> % ls
> B C D sensitive_stuff
>
> % git status
> # On branch master
> nothing to commit (working directory clean)
>
> Ok, so I guess it has done what I wanted. So, I try to remove the
> next file that has sensitive information in it:
>
> % git filter-branch --index-filter 'git update-index --remove C' HEAD
> Namespace refs/original/ not empty
Just remove .git/refs/original/
Mike
^ permalink raw reply
* Question on git-filter-branch
From: Bill Lear @ 2007-11-01 12:55 UTC (permalink / raw)
To: git
In my repo, I have sensitive files A, C, and a directory full of
sensitive stuff I want to remove forever from the git repository.
% ls
A B C D sensitive_stuff
% git --version
git version 1.5.3.5
% git filter-branch --index-filter 'git update-index --remove A' HEAD
Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
% ls
B C D sensitive_stuff
% git status
# On branch master
nothing to commit (working directory clean)
Ok, so I guess it has done what I wanted. So, I try to remove the
next file that has sensitive information in it:
% git filter-branch --index-filter 'git update-index --remove C' HEAD
Namespace refs/original/ not empty
And there I am stuck: what do I do now?
I did also try this (on a fresh clone of the original repo):
% git filter-branch --index-filter 'git update-index --remove A C sensitive_stuff/*' HEAD
Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
% ls
B D sensitive_stuff/
% ls sensitive_stuff
E F G
So, that appears to have removed A and C, but it did nothing to the
files in the subdirectory. Is there a way to remove the files in the
subdirectory --- or, better, to simply remove the entire subdirectory?
I did try reading the man page for this, and the first example is
essentially what I want. It says "you will get the rewritten history
saved in HEAD", but I'm not sure what I'm supposed to do next.
Bill
^ permalink raw reply
* [PATCH] gitweb: Update config file example for snapshot feature in gitweb/INSTALL
From: Jakub Narebski @ 2007-11-01 12:45 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Commit a3c8ab30a54c30a6a434760bedf04548425416ef by Matt McCutchen
"gitweb: snapshot cleanups & support for offering multiple formats"
introduced new format of $feature{'snapshot'}{'default'} value. Update
"Config file example" in gitweb/INSTALL accordingly.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/INSTALL | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 6328e26..9cd5b0a 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -116,7 +116,7 @@ GITWEB_CONFIG file:
$feature{'pickaxe'}{'default'} = [1];
$feature{'pickaxe'}{'override'} = 1;
- $feature{'snapshot'}{'default'} = ['x-gzip', 'gz', 'gzip'];
+ $feature{'snapshot'}{'default'} = ['zip', 'tgz'];
$feature{'snapshot'}{'override'} = 1;
--
1.5.3.5
^ permalink raw reply related
* Re: Newbie: report of first experience with git-rebase.
From: Sergei Organov @ 2007-11-01 12:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhck7gdzs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Wed, 31 Oct 2007, Sergei Organov wrote:
>>
>>> Yes, and that's the problem. Why 'git --continue' didn't just skip this
>>> patch that *already became no-op* after conflict resolution and forced
>>> me to explicitly use 'git --skip' instead?
>>
>> Isn't that obvious? To prevent you from accidentally losing a commit.
>
> In case it is not obvious...
>
> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen.
Funny how 2 of my first 3 commits suffer from this "rather rare event",
and it was not Friday, 13 ;)
--
Sergei.
^ permalink raw reply
* Re: Bug in git-show-branch, or in core-tutorial?
From: Sergei Organov @ 2007-11-01 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x5ictrx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think that is a simple typo of "these", not "three".
No, the explanation text explicitly mentions merge~1 revision that is
not there in the git-show-branch output, so those "three" is consistent
with explanation text itself, but not with git-show-branch output.
--
Sergei.
^ permalink raw reply
* Re: [PATCH 1/5] prune-packed: don't call display_progress() for every file
From: Nicolas Pitre @ 2007-11-01 12:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071101025830.GX14735@spearce.org>
On Wed, 31 Oct 2007, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > The progress count is per fanout directory, so it is useless to call
> > it for every file as the count doesn't change that often.
>
> If you go back into the history and look at the commit message for
> when I introduced this per-object display_progress() call we find
> the following:
>
> commit b5d72f0a4cd3cce945ca0d37e4fa0ebbfcdcdb52
> Author: Shawn O. Pearce <spearce@spearce.org>
> Date: Fri Oct 19 00:08:37 2007 -0400
>
> [...snip...]
> We perform the display_progress() call from within the very innermost
> loop in case we spend more than 1 second within any single object
> directory. This ensures that a progress_update event from the
> timer will still trigger in a timely fashion and allow the user to
> see the progress meter.
Hmmmm OK. I overlooked that.
> During my testing with a 40,000 loose object case (yea, I fully
> unpacked a git.git clone I had laying around) my system stalled
> hard in the first object directory. A *lot* longer than 1 second.
> So I got no progress meter for a long time, and then a progress
> meter appeared on the second directory.
But then don't you get a "0% (1/256)" on the screen for a while, like if
it was stalled? Might be better than nothing at all I suppose...
> So I'm a little against this patch. But I think I understand why
> you think its worth doing. I just consider the progress feedback
> more important than the few machine cycles avoiding it saves.
OK, I don't mind reverting the patch, or actually providing another one
to move the call back inside the loop since other changes will prevent a
clean revert.
Nicolas
^ permalink raw reply
* [PATCH 3/3] gitweb: Use href(-replay=>1, action=>...) to generate alternate views
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
Use href(action=>..., -replay=>1) to generate links to alternate views
of current page in the $formats_nav (bottom) part of page_nav
navigation bar. This form is used only when all parameters are
repeated, and when the replay form is shorter.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 29 +++++++++++------------------
1 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 20d4009..827f977 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3911,11 +3911,11 @@ sub git_blame2 {
or die_error(undef, "Open git-blame failed");
git_header_html();
my $formats_nav =
- $cgi->a({-href => href(action=>"blob", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blob", -replay=>1)},
"blob") .
" | " .
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base, file_name=>$file_name)},
- "history") .
+ $cgi->a({-href => href(action=>"history", -replay=>1)},
+ "history") .
" | " .
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
"HEAD");
@@ -4191,18 +4191,15 @@ sub git_blob {
if (defined $file_name) {
if ($have_blame) {
$formats_nav .=
- $cgi->a({-href => href(action=>"blame", hash_base=>$hash_base,
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blame", -replay=>1)},
"blame") .
" | ";
}
$formats_nav .=
- $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"history", -replay=>1)},
"history") .
" | " .
- $cgi->a({-href => href(action=>"blob_plain",
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"blob_plain", -replay=>1)},
"raw") .
" | " .
$cgi->a({-href => href(action=>"blob",
@@ -4210,7 +4207,8 @@ sub git_blob {
"HEAD");
} else {
$formats_nav .=
- $cgi->a({-href => href(action=>"blob_plain", hash=>$hash)}, "raw");
+ $cgi->a({-href => href(action=>"blob_plain", -replay=>1)},
+ "raw");
}
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
@@ -4273,8 +4271,7 @@ sub git_tree {
my @views_nav = ();
if (defined $file_name) {
push @views_nav,
- $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
- hash=>$hash, file_name=>$file_name)},
+ $cgi->a({-href => href(action=>"history", -replay=>1)},
"history"),
$cgi->a({-href => href(action=>"tree",
hash_base=>"HEAD", file_name=>$file_name)},
@@ -4742,10 +4739,7 @@ sub git_blobdiff {
# header
if ($format eq 'html') {
my $formats_nav =
- $cgi->a({-href => href(action=>"blobdiff_plain",
- hash=>$hash, hash_parent=>$hash_parent,
- hash_base=>$hash_base, hash_parent_base=>$hash_parent_base,
- file_name=>$file_name, file_parent=>$file_parent)},
+ $cgi->a({-href => href(action=>"blobdiff_plain", -replay=>1)},
"raw");
git_header_html(undef, $expires);
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
@@ -4819,8 +4813,7 @@ sub git_commitdiff {
my $formats_nav;
if ($format eq 'html') {
$formats_nav =
- $cgi->a({-href => href(action=>"commitdiff_plain",
- hash=>$hash, hash_parent=>$hash_parent)},
+ $cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
"raw");
if (defined $hash_parent &&
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/3] gitweb: Use href(-replay=>1, page=>...) to generate pagination links
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
Use href(-replay=>1, page=>$page-1) and href(-replay=>1, page=>$page+1)
to generate previous page and next page links.
Generate next page link only once.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 44 +++++++++++++++-----------------------------
1 files changed, 15 insertions(+), 29 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index eaab895..20d4009 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2518,7 +2518,7 @@ sub format_paging_nav {
if ($page > 0) {
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>$action, hash=>$hash, page=>$page-1),
+ $cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
$paging_nav .= " ⋅ prev";
@@ -2526,7 +2526,7 @@ sub format_paging_nav {
if ($nrevs >= (100 * ($page+1)-1)) {
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>$action, hash=>$hash, page=>$page+1),
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
} else {
$paging_nav .= " ⋅ next";
@@ -4448,7 +4448,7 @@ sub git_log {
}
if ($#commitlist >= 100) {
print "<div class=\"page_nav\">\n";
- print $cgi->a({-href => href(action=>"log", hash=>$hash, page=>$page+1),
+ print $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
print "</div>\n";
}
@@ -5015,27 +5015,20 @@ sub git_history {
file_name=>$file_name)},
"first");
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name, page=>$page-1),
+ $cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
$paging_nav .= "first";
$paging_nav .= " ⋅ prev";
}
- if ($#commitlist >= 100) {
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name, page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
- } else {
- $paging_nav .= " ⋅ next";
- }
my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
- $cgi->a({-href => href(action=>"history", hash=>$hash, hash_base=>$hash_base,
- file_name=>$file_name, page=>$page+1),
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
+ $paging_nav .= " ⋅ $next_link";
+ } else {
+ $paging_nav .= " ⋅ next";
}
git_header_html();
@@ -5105,30 +5098,23 @@ sub git_search {
searchtext=>$searchtext, searchtype=>$searchtype)},
"first");
$paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"search", hash=>$hash,
- searchtext=>$searchtext, searchtype=>$searchtype,
- page=>$page-1),
+ $cgi->a({-href => href(-replay=>1, page=>$page-1),
-accesskey => "p", -title => "Alt-p"}, "prev");
} else {
$paging_nav .= "first";
$paging_nav .= " ⋅ prev";
}
+ my $next_link = '';
if ($#commitlist >= 100) {
- $paging_nav .= " ⋅ " .
- $cgi->a({-href => href(action=>"search", hash=>$hash,
- searchtext=>$searchtext, searchtype=>$searchtype,
- page=>$page+1),
+ $next_link =
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
+ $paging_nav .= " ⋅ $next_link";
} else {
$paging_nav .= " ⋅ next";
}
- my $next_link = '';
+
if ($#commitlist >= 100) {
- $next_link =
- $cgi->a({-href => href(action=>"search", hash=>$hash,
- searchtext=>$searchtext, searchtype=>$searchtype,
- page=>$page+1),
- -accesskey => "n", -title => "Alt-n"}, "next");
}
git_print_page_nav('','', $hash,$co{'tree'},$hash, $paging_nav);
@@ -5327,7 +5313,7 @@ sub git_shortlog {
my $next_link = '';
if ($#commitlist >= 100) {
$next_link =
- $cgi->a({-href => href(action=>"shortlog", hash=>$hash, page=>$page+1),
+ $cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
--
1.5.3.4
^ permalink raw reply related
* [PATCH 1/3] gitweb: Easier adding/changing parameters to current URL
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
Add boolean option '-replay' to href() subroutine, which is used to
generate links in gitweb. This option "replays" current URL,
overriding it with provided parameters. It means that current value
of each CGI parameter is used unless otherwise provided.
This change is meant to make it easier to generate links which differ
from current page URL only by one parameter, for example the same view
but sorted by different column:
href(-replay=>1, order=>"age")
or view which differs by some option, e.g. in log views
href(-replay=>1, extra_options=>"--no-merges")
or alternate view of the same object, e.g. in the 'blob' view
href(-replay=>1, action=>"blob_plain")
Actual use of this functionality is left for later.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e36dec1..eaab895 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -611,6 +611,15 @@ sub href(%) {
);
my %mapping = @mapping;
+ if ($params{-replay}) {
+ while (my ($name, $symbol) = each %mapping) {
+ if (!exists $params{$name}) {
+ # to allow for multivalued params we use arrayref form
+ $params{$name} = [ $cgi->param($symbol) ];
+ }
+ }
+ }
+
$params{'project'} = $project unless exists $params{'project'};
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
--
1.5.3.4
^ permalink raw reply related
* [PATCH 0/3] gitweb: Simplify some gitweb URLs generation
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git
This series of patches simplifies some gitweb URLs generation by
providing -replay option to href() subroutine, and then using this
feature in gitweb code.
Shortlog:
gitweb: Easier adding/changing parameters to current URL
gitweb: Use href(-replay=>1, page=>...) to generate pagination links
gitweb: Use href(-replay=>1, action=>...) to generate alternate views
Diffstat:
gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
1 files changed, 35 insertions(+), 47 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 0/3] gitweb: Simplify some gitweb URLs generation
From: Jakub Narebski @ 2007-11-01 12:06 UTC (permalink / raw)
To: git
In-Reply-To: <1193918789-16421-1-git-send-email-jnareb@gmail.com>
gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
1 files changed, 35 insertions(+), 47 deletions(-)
gitweb/gitweb.perl | 82 ++++++++++++++++++++++-----------------------------
1 files changed, 35 insertions(+), 47 deletions(-)
[PATCH 1/3] gitweb: Easier adding/changing parameters to current URL
[PATCH 2/3] gitweb: Use href(-replay=>1, page=>...) to generate pagination links
[PATCH 3/3] gitweb: Use href(-replay=>1, action=>...) to generate alternate views
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-11-01 11:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710280943090.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> The cost is not generally in outputting the commits. The real cost is in
> traversing them in the first place.
Actually, the biggest cost is still gitk reading in the commits from
git log and doing the processing that gitk needs to do on each commit
(which I have tried to minimize, and is way smaller than it used to
be, but is still significant).
In fact that would go significantly faster if git log could output the
data for each commit in a slightly different format. What would be
good is to get one header line for each commit in the form:
id flag {parent parent parent...} length
where:
id is the 40-char SHA1 for the commit
flag is normally 1, but is 0 for "boundary" commits, 2 for "left-side"
commits (with --merge), or 3 for "right-side" commits
length is the number of characters of commit data that follow
(which may differ from the number of bytes, so there would need
to be agreement on the encoding)
followed by the body of the commit (with no null or other separator
character between commits).
That would be easier to parse in Tcl, and looks like it would knock
another 1.5 seconds off the gitk startup time (for the kernel
repository on my G5).
Paul.
^ permalink raw reply
* [PATCH 1/2] gitweb: Always set 'from_file' and 'to_file' in parse_difftree_raw_line
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193917089-15920-1-git-send-email-jnareb@gmail.com>
Always set 'from_file' and 'to_file' keys when parsing raw diff output
format line, even if filename didn't change (file was not renamed).
This allows for simpler code (and no problems with file named '0').
Use
$diffinfo->{'from_file'}
instead of
$diffinfo->{'from_file'} || $diffinfo->{'file'}
from now on.
While at it, replace (for merge commits)
$diffinfo->{'from_file'}[$i] || $diffinfo->{'to_file'}
by
defined $diffinfo->{'from_file'}[$i] ?
$diffinfo->{'from_file'}[$i] :
$diffinfo->{'to_file'};
to have no problems woth file named '0'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2e00756..79ea7ec 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1995,7 +1995,7 @@ sub parse_difftree_raw_line {
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
} else {
- $res{'file'} = unquote($7);
+ $res{'from_file'} = $res{'to_file'} = $res{'file'} = unquote($7);
}
}
# '::100755 100755 100755 60e79ca1b01bc8b057abe17ddab484699a7f5fdb 94067cc5f73388f33722d52ae02f44692bc07490 94067cc5f73388f33722d52ae02f44692bc07490 MR git-gui/git-gui.sh'
@@ -2062,7 +2062,10 @@ sub parse_from_to_diffinfo {
fill_from_file_info($diffinfo, @parents)
unless exists $diffinfo->{'from_file'};
for (my $i = 0; $i < $diffinfo->{'nparents'}; $i++) {
- $from->{'file'}[$i] = $diffinfo->{'from_file'}[$i] || $diffinfo->{'to_file'};
+ $from->{'file'}[$i] =
+ defined $diffinfo->{'from_file'}[$i] ?
+ $diffinfo->{'from_file'}[$i] :
+ $diffinfo->{'to_file'};
if ($diffinfo->{'status'}[$i] ne "A") { # not new (added) file
$from->{'href'}[$i] = href(action=>"blob",
hash_base=>$parents[$i],
@@ -2074,7 +2077,7 @@ sub parse_from_to_diffinfo {
}
} else {
# ordinary (not combined) diff
- $from->{'file'} = $diffinfo->{'from_file'} || $diffinfo->{'file'};
+ $from->{'file'} = $diffinfo->{'from_file'};
if ($diffinfo->{'status'} ne "A") { # not new (added) file
$from->{'href'} = href(action=>"blob", hash_base=>$hash_parent,
hash=>$diffinfo->{'from_id'},
@@ -2084,7 +2087,7 @@ sub parse_from_to_diffinfo {
}
}
- $to->{'file'} = $diffinfo->{'to_file'} || $diffinfo->{'file'};
+ $to->{'file'} = $diffinfo->{'to_file'};
if (!is_deleted($diffinfo)) { # file exists in result
$to->{'href'} = href(action=>"blob", hash_base=>$hash,
hash=>$diffinfo->{'to_id'},
@@ -2829,7 +2832,7 @@ sub is_patch_split {
my ($diffinfo, $patchinfo) = @_;
return defined $diffinfo && defined $patchinfo
- && ($diffinfo->{'to_file'} || $diffinfo->{'file'}) eq $patchinfo->{'to_file'};
+ && $diffinfo->{'to_file'} eq $patchinfo->{'to_file'};
}
@@ -4667,8 +4670,8 @@ sub git_blobdiff {
}
%diffinfo = parse_difftree_raw_line($difftree[0]);
- $file_parent ||= $diffinfo{'from_file'} || $file_name || $diffinfo{'file'};
- $file_name ||= $diffinfo{'to_file'} || $diffinfo{'file'};
+ $file_parent ||= $diffinfo{'from_file'} || $file_name;
+ $file_name ||= $diffinfo{'to_file'};
$hash_parent ||= $diffinfo{'from_id'};
$hash ||= $diffinfo{'to_id'};
--
1.5.3.4
^ permalink raw reply related
* [PATCH 0/2] gitweb: Simplify dealing with raw diff output
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git
This series of patches simplifies (and improves) gitweb code dealing
with (parsed) raw diff output format.
See individual patches for more detail.
Table of contents:
[PATCH 1/2] gitweb: Always set 'from_file' and 'to_file'
in parse_difftree_raw_line
[PATCH 2/2] gitweb: Add 'status_str' to parse_difftree_raw_line output
Diffstat:
gitweb/gitweb.perl | 22 +++++++++++++---------
1 files changed, 13 insertions(+), 9 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 2/2] gitweb: Add 'status_str' to parse_difftree_raw_line output
From: Jakub Narebski @ 2007-11-01 11:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <1193917089-15920-1-git-send-email-jnareb@gmail.com>
Add 'status_str' to diffinfo output, which stores status (also for
merge commit) as a string. This allows for easy checking if there is
given status among all for merge commit, e.g.
$diffinfo->{'status_str'} =~ /D/;
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 79ea7ec..e36dec1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1990,7 +1990,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = $2;
$res{'from_id'} = $3;
$res{'to_id'} = $4;
- $res{'status'} = $5;
+ $res{'status'} = $res{'status_str'} = $5;
$res{'similarity'} = $6;
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
@@ -2006,6 +2006,7 @@ sub parse_difftree_raw_line {
$res{'to_mode'} = pop @{$res{'from_mode'}};
$res{'from_id'} = [ split(' ', $3) ];
$res{'to_id'} = pop @{$res{'from_id'}};
+ $res{'status_str'} = $4;
$res{'status'} = [ split('', $4) ];
$res{'to_file'} = unquote($5);
}
@@ -2821,7 +2822,7 @@ sub fill_from_file_info {
sub is_deleted {
my $diffinfo = shift;
- return $diffinfo->{'to_id'} eq ('0' x 40);
+ return $diffinfo->{'status_str'} =~ /D/;
}
# does patch correspond to [previous] difftree raw line
--
1.5.3.4
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-01 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vmytycykt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
> + rebase: allow starting from a dirty tree.
> + stash: implement "stash create"
>
> Will revert at least the latter one, but perhaps both, from
> 'next'. The traditional behaviour of refusing to work in a
> dirty tree is much safer, as the tool cannot decide where to
> unstash for you.
One of frequently requested features is ability to rebase and merge
in a dirty tree (CVS-like). Perhaps we should advocate git-stash better,
e.g. in error message for git-rebase / git-merge / git-pull when in dirty
state.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Mike Hommey @ 2007-11-01 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vejfag40g.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 31, 2007 at 06:15:27PM -0700, Junio C Hamano wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > BTW, you have workaround for git-merge also? It uses cpio to save/restore state.
>
> Why do people want "workaround"? Is installing cpio such a
> hassle?
Note that to do what git-merge does with cpio, i wonder if it wouldn't
be sensible to use git stash, now.
Mike
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-11-01 10:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710280943090.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> (And as mentioned many times earlier - if you can avoid topo-order and
> date-order entirely, you are going to perform a million times better at
> startup for the cold-cache case. Since you seem to be doing the graph
> layout lazily now, maybe you could aim for that some day? It does mean
> that you might - occasionally - end up having to add a commit to
> *before* one you already laid out).
The other thing --topo-order does is reorder the commits so that
related commits come together. So far, doing that in Tcl has turned
out to be much slower than having it done in C (within git log) for
the hot-cache case (which I expect is the common case).
I'm now thinking that the best approach would be to have gitk cache
the topology, and on startup only read in the part of the graph that
isn't in the cache. Mostly that will be small and so git log should
be fast even in the cold-cache case with --topo-order.
Paul.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 9:29 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <0A8A6A99-4C8B-4056-9068-DA54B69B08B5@zib.de>
Steffen Prohaska wrote:
>
> On Nov 1, 2007, at 9:18 AM, Andreas Ericsson wrote:
>
>> Junio C Hamano wrote:
>>
>>> (actually, shared repository people seem to
>>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>>
>> That's definitely true. The number of useless merge-commits we
>> have in our repos is annoying, and has twice made bisect a bit
>> troublesome for no good reason.
>
> Can you describe a bit more what's "annoying" about them?
> Is it the visualization? Or are there more problems; like
> the trouble with bisect?
>
Visualization is a small nuissance. git-bisect troubles are more
worrisome. I've been in the seat where useless merges means git
bisect needs constant babysitting and constant manual handling.
It's no fun at all, so we're sticking with the fetch+rebase flow.
> I'm trying to estimate if it's worth teaching _all_
> developers rebase or if we should just live with the "useless"
> merge-commits.
>
I'd say that depends on how valuable you find gitk, qgit and
git-bisect are. To me, I'd happily use any scm in the world,
so long as it has git-bisect. Otoh, I'm a lazy bastard and
love bisect so much that all our automated tests are focused
around "git bisect run". This means bugs in software released
to customers are few and far apart. When we get one reported,
we just create a new test that exposes it, fire up git-bisect
and then go to lunch. Quality costs, however. We pay that bill
by using a workflow that's perhaps more convoluted than
necessary.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-01 9:11 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <6B0CD829-A964-410B-8C23-74D26BD2C0FA@zib.de>
Steffen Prohaska wrote:
>
> On Oct 31, 2007, at 10:31 PM, Junio C Hamano wrote:
>
>> Steffen Prohaska <prohaska@zib.de> writes:
>>
>>>> You forgot a lot more important part. Pushing into publishing
>>>> repositories. And the discussion is about git-push command.
>>>
>>> Exactly, here are two examples:
>>>
>>> If you push only to publishing repositories that are read
>>> only by others, you'll never encounter the problem that
>>> 10/10 tried to solve. The publishing repository is never
>>> changed by others. You are the only one who pushes to this
>>> repository. Therefore the remote never advances unexpectedly.
>>
>> Wrong.
>>
>> People can and do work from more than one private repositories
>> (I do). In a sense, that is sharing the repository with
>> oneself.
>
> I do, too. But as long as I do not forget what I've done, the
> branches do not advance _unexpectedly_. I am in full control.
>
>
>> I may do an emergency patch to fix breakage on 'maint' (and
>> 'maint' only) from a location that is not my primary development
>> box and push the fix out. I fully expect that the push will
>> push out 'maint' and expect the other branches such as 'master'
>> on the remote side to stay the same, as I haven't touched
>> 'master' on that box for quite a while and it is now stale. In
>> that situation, I _want_ the "git push" itself to report failure
>> to notify me that it did not push what _I_ asked it to push out,
>> so that I can be reminded that I'd better do "git push $remote
>> maint" the next time. In the meantime, even though it reports
>> a failure, 'master' on the remote side is _not_ updated, so the
>> behaviour is still _safe_.
>
> You're right it is safe, but it may be confusing.
>
>
>>> Another difference is the way changes are integrated. In
>>> a workflow without shared repositories, only pull is used
>>> for integration, while push in only used for publishing the
>>> changes.
>>
>> Wrong. push is a mirror of fetch and does not do _any_
>> integration. It is just a safe (because it insists on
>> fast-forward) propagation mechanism. Your integration still
>> happens with pull (actually, shared repository people seem to
>> prefer "fetch + rebase" over "pull" which is "fetch + merge").
>
> Right; but you can't push without doing the integration. If you
> have new changes on the remote side you _must_ pull before
> you can push.
Yes, because otherwise you'd rewrite published history. That's not
a good thing.
> You're forced to do the integration immediately.
Yes, but you get to choose how. Perhaps git-push should list more
options than just git-pull, such as the three commands required to
rebase the currently checked out branch onto its remote counterpart.
That would support more workflows.
> Your main objective was to push, but the shared workflow forces
> you to do the integration _now_ (by using pull). In a pull-only
> workflow, you can just push and defere the integration for later.
>
No, you can also fetch + rebase.
> Some people claim fetch + rebase is superior to fetch + merge.
> The only point I can see is that fetch + rebase gives a linear
> history without loops, which is nicer to visualize. I recently
> asked on the list if there are any benefits of fetch + rebase
> over fetch + merge, besides a nicer visualization.
It's easier to bisect. If git bisect lands you on a merge-commit,
you need to start a new bisect for each of the parents included
in the merge. Hopefully the nature of the merge gives a clue so
the user can make an educated guess as to which parent introduced
the bogus commit, but for an "evil octopus" (unusual) or if the
merge had conflicts which were resolved in a buggy way (not
exactly uncommon), it can be quite a hassle to get things right.
With a mostly linear history, this problem goes away.
> I didn't
> receive many interesting comments. One comment explained
> that rebase can shift the merge conflict resolution from
> the maintainer (merge) to the original author (rebase). But
> this is not very interesting in a shared workflow, because
> the author must resolve conflicts in any case before he can
> push. It doesn't matter much if he uses merge or rebase to
> do so.
>
It depends. When commit ordering doesn't matter the original
author can use "git rebase --skip" and then continue with the
rebase to get as much as possible out as quickly as possible.
I'm in the unfortunate position of having a boss that likes
to fiddle with help-texts in code when it's in alpha-testing.
Sometimes that causes conflicts but it's often not important
enough to spend 30 minutes figuring out how to resolve it
properly. I tend to just skip those patches and send them as
emails to our tech-writer instead, asking him to rephrase the
text to incorporate both changes, and then manually applying
the text to the end result.
>
> I am searching for a solution that just works for them. They
> currently use CVS. I'll give them a detailed getting started
> document for git. The workflow described should be as simple as
> possible, but safe and reliable.
If they're used to CVS and want to use more than one branch without
having to learn additional syntax, nothing can help, methinks.
>
> Another question is what to do with a local branch after
> you finished work. We recently had the
> "Re: best git practices, was Re: Git User's Survey 2007
> unfinished summary continued" aka the 200-local-branches
> discussion.
>
We're at 224 branches now, having added 7 new repos.
> There were different suggestions what to do. A reasonable
> suggestion was to delete the local branch after you're done.
Except that it doesn't work unless you either detach the HEAD
(which prints a big fat ugly message) or give it -D to force
it, which I really, really don't recommend. We use git because
I'm pretty confident in its capabilities of never ever losing
anything. Using the seemingly harmless -D switch to git-branch
puts us at risk of wiping history quite without noticing.
> This clearly distinguishes between remote branches (which are
> mirrored as a remote tracking branch) and local branches. Local
> branches are _your_ branches while the remote branches contain
> the shared work. If you're done with your local work, delete
> your local branch. So maybe you should do
>
> git checkout origin/devel
Except that this gives a warning-esque message:
Note: moving to "origin/devel" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at deadbeef... Ma! Pa butchered all the cows!
To me, this indicates I've done something git thinks I shouldn't have.
>
> Independently of what the best practice is, leaving the local
> work branch there shouldn't do any harm because I'm sure that
> some devs will forget to clean up, independently of what I tell
> them.
>
I wholeheartedly agree with this one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] git-clone.txt: Improve --depth description.
From: Ralf Wildenhues @ 2007-11-01 8:46 UTC (permalink / raw)
To: git, Junio C Hamano
Avoid abbreviation 'revs', improve the language a bit.
---
Documentation/git-clone.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 253f4f0..cca14d6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -111,11 +111,11 @@ OPTIONS
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
- specified number of revs. A shallow repository has
+ specified number of revisions. A shallow repository has a
number of limitations (you cannot clone or fetch from
it, nor push from nor into it), but is adequate if you
- want to only look at near the tip of a large project
- with a long history, and would want to send in a fixes
+ are only interested in the recent history of a large project
+ with a long history, and would want to send in fixes
as patches.
<repository>::
--
1.5.3.1.522.g85b0
^ permalink raw reply related
* [PATCH] git-rev-list.txt: rev stands for revision, not reverse.
From: Ralf Wildenhues @ 2007-11-01 8:45 UTC (permalink / raw)
To: git, Junio C Hamano
Mention revs, revisions as aliases for commit objects,
to clarify that rev-list is not an abbreviation for
listing in reverse order, but for listing revisions.
---
Yes, believe it or not, but I stumbled over the synopsis
| git-rev-list - Lists commit objects in reverse chronological order
asking myself whether rev could possibly mean "reverse".
I hope this helps avoid this pitfall for others.
Cheers,
Ralf
Documentation/git-rev-list.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 4852804..8afe34b 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -44,9 +44,9 @@ SYNOPSIS
DESCRIPTION
-----------
-Lists commit objects in reverse chronological order starting at the
-given commit(s), taking ancestry relationship into account. This is
-useful to produce human-readable log output.
+Lists commit objects (revs, revisions) in reverse chronological order
+starting at the given commit(s), taking ancestry relationship into
+account. This is useful to produce human-readable log output.
Commits which are stated with a preceding '{caret}' cause listing to
stop at that point. Their parents are implied. Thus the following
--
1.5.3.3.g34c6d
^ permalink raw reply related
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