* [PATCH] repack: allow simultaneous packing and pruning
From: Sam Vilain @ 2006-10-10 10:14 UTC (permalink / raw)
To: git
If using git-repack -a, unreferenced objects are kept behind in the
pack. This might be the best default, but there are no good ways
to clean up the packfiles if a lot of rebasing is happening, or
branches have been deleted.
---
see also http://colabti.de/irclogger/irclogger_log/git?date=2006-10-10,Tue&sel=27#l75
Documentation/git-repack.txt | 7 ++++++-
git-repack.sh | 14 +++++++++++++-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 9516227..63ee7cb 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -9,7 +9,7 @@ objects into pack files.
SYNOPSIS
--------
-'git-repack' [-a] [-d] [-f] [-l] [-n] [-q]
+'git-repack' [-a] [-d] [-f] [-l] [-n] [-q] [-p]
DESCRIPTION
-----------
@@ -40,6 +40,11 @@ OPTIONS
existing packs redundant, remove the redundant packs.
Also runs gitlink:git-prune-packed[1].
+-p::
+ Before packing, remove any unreferenced objects with
+ gitlink:git-prune[1]. When used with '-a', unreferenced
+ objects in the old packs are not taken across.
+
-l::
Pass the `--local` option to `git pack-objects`, see
gitlink:git-pack-objects[1].
diff --git a/git-repack.sh b/git-repack.sh
index 640ad8d..a2ad955 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -7,13 +7,14 @@ USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
. git-sh-setup
no_update_info= all_into_one= remove_redundant=
-local= quiet= no_reuse_delta= extra=
+local= quiet= no_reuse_delta= extra= prune=
while case "$#" in 0) break ;; esac
do
case "$1" in
-n) no_update_info=t ;;
-a) all_into_one=t ;;
-d) remove_redundant=t ;;
+ -p) prune=t ;;
-q) quiet=-q ;;
-f) no_reuse_delta=--no-reuse-delta ;;
-l) local=--local ;;
@@ -32,6 +33,11 @@ case ",$all_into_one," in
,,)
rev_list='--unpacked'
pack_objects='--incremental'
+ if [ -n "$prune" ]
+ then
+ # prune junk first
+ git-prune
+ fi
;;
,t,)
rev_list=
@@ -40,8 +46,14 @@ case ",$all_into_one," in
# Redundancy check in all-into-one case is trivial.
existing=`cd "$PACKDIR" && \
find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
+
+ if [ -n "$prune" ]
+ then
+ rev_list=`cd "$GIT_DIR" && find refs -type f -print`
+ fi
;;
esac
+
pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
name=$(git-rev-list --objects --all $rev_list 2>&1 |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
--
1.4.2.g0ea2
^ permalink raw reply related
* Re: [PATCH] gitweb: Show project README if available
From: Petr Baudis @ 2006-10-10 10:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <egfndo$lg6$1@sea.gmane.org>
Dear diary, on Tue, Oct 10, 2006 at 11:00:41AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Petr Baudis wrote:
>
> > + print $_ while (<$fd>);
>
> Wouldn't it be better to do it in slurp mode, i.e.
>
> {
> local $/
> print <$fd>;
> }
>
> instead?
I personally prefer my version as it prevents allocation of big chunks
of memory, but I don't really care in this particular case.
> Do you assume that README is HTML fragment? If not, you should esc_html it.
> Besides, we have similar (if assumed to have one line only) file, namely
> description.
I _do_ assume that README is HTML fragment (so that you can use links,
non-proportional fonts, etc.), this is a difference to the description
file.
> Besides, README for a project can be huge. Git README has 589 lines!
This is not /README from the tree but README in the .git directory, so
it may not be the same. In the repo.or.cz admin interface, I limit
README to 8kb.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Petr Baudis @ 2006-10-10 10:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7iz894ct.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Oct 10, 2006 at 06:33:54AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Junio C Hamano <junkio@cox.net> writes:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> >> If the project includes a README file, show it in the summary page.
> >...
> > I wonder how this should relate to .git/description file,
> > though. In other words, it _might_ make sense to change where
> > we show the contents of description right now to show the first
> > line and take README from the same location.
In principle I like this idea. One problem is that description is not
supposed to contain HTML and my README is (perhaps it should read
README.html instead), and I really want README to. And if it's not
plaintext, division of the first line and the rest does not work so
well:
If you show first line of description as the "short" one and whole
description as the "full" one in summary page, it will look awkward. If
you look at http://repo.or.cz/gitweb.cgi/hed.git, the first line in the
full description starts with boldened Hed, and is of course a separate
paragraph etc.
> Also we might want to consider using this file (or description)
> for git-daemon "motd" action if we were to enhance it. I
> remember that early days of git-daemon some people wanted to
> have motd.
I'd rather keep those separate...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Sam Vilain @ 2006-10-10 11:04 UTC (permalink / raw)
To: git
In-Reply-To: <20061010102210.568341380D6@magnus.utsl.gen.nz>
er, I guess I assumed that the critique about the behaviour was true
rather than checking it myself... this patch is mostly a null-op. *and*
it's not whitespace clean!
Sam.
Sam Vilain wrote:
> If using git-repack -a, unreferenced objects are kept behind in the
> pack. This might be the best default, but there are no good ways
> to clean up the packfiles if a lot of rebasing is happening, or
> branches have been deleted.
> ---
> see also http://colabti.de/irclogger/irclogger_log/git?date=2006-10-10,Tue&sel=27#l75
>
> Documentation/git-repack.txt | 7 ++++++-
> git-repack.sh | 14 +++++++++++++-
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
> index 9516227..63ee7cb 100644
> --- a/Documentation/git-repack.txt
> +++ b/Documentation/git-repack.txt
> @@ -9,7 +9,7 @@ objects into pack files.
>
> SYNOPSIS
> --------
> -'git-repack' [-a] [-d] [-f] [-l] [-n] [-q]
> +'git-repack' [-a] [-d] [-f] [-l] [-n] [-q] [-p]
>
> DESCRIPTION
> -----------
> @@ -40,6 +40,11 @@ OPTIONS
> existing packs redundant, remove the redundant packs.
> Also runs gitlink:git-prune-packed[1].
>
> +-p::
> + Before packing, remove any unreferenced objects with
> + gitlink:git-prune[1]. When used with '-a', unreferenced
> + objects in the old packs are not taken across.
> +
> -l::
> Pass the `--local` option to `git pack-objects`, see
> gitlink:git-pack-objects[1].
> diff --git a/git-repack.sh b/git-repack.sh
> index 640ad8d..a2ad955 100755
> --- a/git-repack.sh
> +++ b/git-repack.sh
> @@ -7,13 +7,14 @@ USAGE='[-a] [-d] [-f] [-l] [-n] [-q]'
> . git-sh-setup
>
> no_update_info= all_into_one= remove_redundant=
> -local= quiet= no_reuse_delta= extra=
> +local= quiet= no_reuse_delta= extra= prune=
> while case "$#" in 0) break ;; esac
> do
> case "$1" in
> -n) no_update_info=t ;;
> -a) all_into_one=t ;;
> -d) remove_redundant=t ;;
> + -p) prune=t ;;
> -q) quiet=-q ;;
> -f) no_reuse_delta=--no-reuse-delta ;;
> -l) local=--local ;;
> @@ -32,6 +33,11 @@ case ",$all_into_one," in
> ,,)
> rev_list='--unpacked'
> pack_objects='--incremental'
> + if [ -n "$prune" ]
> + then
> + # prune junk first
> + git-prune
> + fi
> ;;
> ,t,)
> rev_list=
> @@ -40,8 +46,14 @@ case ",$all_into_one," in
> # Redundancy check in all-into-one case is trivial.
> existing=`cd "$PACKDIR" && \
> find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
> +
> + if [ -n "$prune" ]
> + then
> + rev_list=`cd "$GIT_DIR" && find refs -type f -print`
> + fi
> ;;
> esac
> +
> pack_objects="$pack_objects $local $quiet $no_reuse_delta$extra"
> name=$(git-rev-list --objects --all $rev_list 2>&1 |
> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Dongsheng Song @ 2006-10-10 10:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7ro64pq.fsf@assigned-by-dhcp.cox.net>
Thanks, now that's OK.
>
> I am not sure what version of gitweb your distribution packages,
> but it used to be that commitdiff page wanted to create
> temporary file somewhere on the filesystem (the variable was
> $git_temp and by default it was set to "/tmp/gitweb", I think).
> Your other pages such as commit and log page seem to be working,
> so perhaps your gitweb has trouble writing there only on that
> machine?
>
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Jakub Narebski @ 2006-10-10 11:21 UTC (permalink / raw)
To: git
In-Reply-To: <20061010105521.GQ20017@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Tue, Oct 10, 2006 at 06:33:54AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Junio C Hamano <junkio@cox.net> writes:
>>
>> > Petr Baudis <pasky@suse.cz> writes:
>> >
>> >> If the project includes a README file, show it in the summary page.
>> >...
>> > I wonder how this should relate to .git/description file,
>> > though. In other words, it _might_ make sense to change where
>> > we show the contents of description right now to show the first
>> > line and take README from the same location.
>
> In principle I like this idea. One problem is that description is not
> supposed to contain HTML and my README is (perhaps it should read
> README.html instead), and I really want README to. And if it's not
> plaintext, division of the first line and the rest does not work so
> well:
Perhaps we should assume $GIT_DIR/README to be text/plain (and useable
as motd), and $GIT_DIR/README.html as text/html, preffering the README.html.
The "problem" is if README.html is HTML _fragment_, or is it self contained
HTML (and we should use iframe, object, or strip it).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: Show trailing slash when listing tree entry in tree listing
From: Josef Weidendorfer @ 2006-10-10 13:14 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jeff King, Luben Tuikov, Petr Baudis, Jakub Narebski, git,
Junio C Hamano
In-Reply-To: <452B54A5.4080901@op5.se>
On Tuesday 10 October 2006 10:07, Andreas Ericsson wrote:
> I like my links blue and underlined. Can't be arsed to mouse over things
> to figure out if they're clickable. If they're not blue and underlined,
> they're not, insofar as I'm concerned.
Same opinion here.
Better be functional than beautiful but confusing.
If Gitweb would be a desktop application, we would have context menues
for different actions on list items, but that is not really possible
with web pages (?), and would be unexpected.
Gitweb is a web interface. So lets use the conventions for web pages.
One solution is to repeat the actions everytime in every row of a list,
as we do now (and I think is fine; we could use icons instead). The other
standard solution is to have checkboxes at the front of every row, and
the actions as buttons, which means two mouse clicks (which IMHO is a
really bad UI).
And as we go with the first solution, we explicitly should state all
possible actions, and not provide an hidden action which is triggered
when clicking on the entry name. Currently, it is not very clear that
* we have a "blob" action at all,
* clicking on the entry name provides the blob action. Seems to me
like an arbitrary choice. Why not "raw" or "blame" instead?
Therefore, I am in favor of reintroducing the "blob" link,
which allows the entry names to stay as they are
now (and could get the hidden redundant action).
One thing I found confusing in this regard the first time:
Why do list rows show a recoloring with mouse over?
This somehow suggest that the whole row makes up some kind of
a button and is clickable (BTW, blame pages do not do this).
Can we get rid of this?
Josef
^ permalink raw reply
* is git-unpack-objects now redundant for 'git-push' and friends?
From: Sam Vilain @ 2006-10-10 13:23 UTC (permalink / raw)
To: git
When pushing or pulling to/from a repository, why unpack the objects?
Why not just fsck and then throw the pack into $GIT_DIR/objects/pack?
If you're pushing the entire repository, for instance, currently you
might create 10,000's of files, which will just be thrown away later
when you `git-repack -d'.
I suspect that this was never changed, because there never used to be
more than one packfile allowed, correct?
If the server *does* send us duplicates of objects we already have for
some reason, well that's what `git-repack -a -d' is for.
I'm just wondering if there are any good reasons to do this any more.
Sam.
^ permalink raw reply
* Re: [PATCH] gitweb: Show project README if available
From: Horst H. von Brand @ 2006-10-10 14:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7v7iz894ct.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> Also we might want to consider using this file (or description)
> for git-daemon "motd" action if we were to enhance it. I
> remember that early days of git-daemon some people wanted to
> have motd.
I consider motd to be a system-wide property, not of a particular
project/repository...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* [PATCH] Add --dry-run option to git-send-email
From: Matthew Wilcox @ 2006-10-10 14:58 UTC (permalink / raw)
To: git
Add a --dry-run option to git-send-email due to having made too many
mistakes with it in the past week. I like having a safety catch on my
machine gun.
Signed-off-by: Matthew @ilcox <matthew@wil.cx>
--- /usr/bin/git-send-email 2006-07-29 09:52:13.000000000 -0600
+++ ./git-send-email.perl 2006-10-10 08:46:13.000000000 -0600
@@ -40,7 +40,8 @@
$initial_reply_to,$initial_subject,@files,$from,$compose,$time);
# Behavior modification variables
-my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc) = (1, 0, 0, 0);
+my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,
+ $dry_run) = (1, 0, 0, 0, 0);
my $smtp_server;
# Example reply to:
@@ -63,6 +64,7 @@
"quiet" => \$quiet,
"suppress-from" => \$suppress_from,
"no-signed-off-cc|no-signed-off-by-cc" => \$no_signed_off_cc,
+ "dry-run" => \$dry_run,
);
# Verify the user input
@@ -395,7 +397,9 @@
$header .= "References: $references\n";
}
- if ($smtp_server =~ m#^/#) {
+ if ($dry_run) {
+ # We don't want to send the email.
+ } elsif ($smtp_server =~ m#^/#) {
my $pid = open my $sm, '|-';
defined $pid or die $!;
if (!$pid) {
^ permalink raw reply
* [PATCH] Understand the meaning of commas in git-send-email
From: Matthew Wilcox @ 2006-10-10 14:59 UTC (permalink / raw)
To: git
I made the mistake of adding one Cc: line with two email addresses on
it, instead of two Cc: lines with one email address each. Extending
git-send-email to parse that case turns out to not be too much work.
Signed-off-by: Matthew Wilcox <matthew@wil.cx>
--- /usr/bin/git-send-email 2006-07-29 09:52:13.000000000 -0600
+++ ./git-send-email.perl 2006-10-10 08:46:13.000000000 -0600
@@ -537,13 +542,15 @@
my @emails;
foreach my $entry (@_) {
- if (my $clean = extract_valid_address($entry)) {
- $seen{$clean} ||= 0;
- next if $seen{$clean}++;
- push @emails, $entry;
- } else {
- print STDERR "W: unable to extract a valid address",
- " from: $entry\n";
+ foreach my $addr (split(/, */, $entry)) {
+ if (my $clean = extract_valid_address($addr)) {
+ $seen{$clean} ||= 0;
+ next if $seen{$clean}++;
+ push @emails, $addr;
+ } else {
+ print STDERR "W: unable to extract a valid",
+ " address from: $entry\n";
+ }
}
}
return @emails;
^ permalink raw reply
* Re: [PATCH] repack: allow simultaneous packing and pruning
From: Linus Torvalds @ 2006-10-10 15:03 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <20061010102210.568341380D6@magnus.utsl.gen.nz>
On Tue, 10 Oct 2006, Sam Vilain wrote:
>
> If using git-repack -a, unreferenced objects are kept behind in the
> pack. This might be the best default, but there are no good ways
> to clean up the packfiles if a lot of rebasing is happening, or
> branches have been deleted.
Don't do this.
I understand why you want to do it, but the fact is, it's dangerous.
Right now, "git repack" is actually safe to run even on a repository which
is being modified! And that's actually important, if you have something
like a shared repo that gets re-packed every once in a while from a
cron-job!
So the refs might be up-dated as it runs, and if that happens, your
pruning doesn't really do the right thing - it might consider a new loose
object to be unreachable, because it didn't check whether the refs have
changed since it read them so that it might actually _be_ reachable after
all.
So please don't do this.
It's important for operations to always think about "what happens if
somebody does a 'commit' or pushes into the tree at the same time?".
For example, the "git prune-packed" that gets run afterwards is _not_
racy, because it will only prune objects that already exist in the pack.
Linus
^ permalink raw reply
* Re: is git-unpack-objects now redundant for 'git-push' and friends?
From: Shawn Pearce @ 2006-10-10 16:14 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <452B9EE8.5020702@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> When pushing or pulling to/from a repository, why unpack the objects?
> Why not just fsck and then throw the pack into $GIT_DIR/objects/pack?
>
> If you're pushing the entire repository, for instance, currently you
> might create 10,000's of files, which will just be thrown away later
> when you `git-repack -d'.
>
> I suspect that this was never changed, because there never used to be
> more than one packfile allowed, correct?
>
> If the server *does* send us duplicates of objects we already have for
> some reason, well that's what `git-repack -a -d' is for.
>
> I'm just wondering if there are any good reasons to do this any more.
There's still a few good reasons to unpack things, even though I
hate sitting through 5000 objects unpacking on a Windows system,
or a very slow NFS system (one NFS based system I work with unpacks
small <1KiB objects at a rate of about 1 every 15 seconds).
- We don't completely trust the remote peer. If the remote sends
us an object we already have we want to use the bytes we have
and not the bytes they are sending. That way even if the remote
were able to generate a hash collision and produce a replacement
byte sequence with the same hash, our known good byte sequence
is not affected.
- Packs sent over the network can be thin packs. A think pack
may not contain the object used as the delta base for a delta
within that pack. This is done to save network bandwidth when
both sides already have the delta base for an object that is
being transferred.
- Local packs cannot access delta base objects not in the same
pack. This limitation simplifies the pack access code in a
lot of the system. It also means that you can in a worst case
scenario obtain everything in that pack back when all you have
is the pack file itself.
I'm sure there's more reasons than that, but those are the major
ones.
--
Shawn.
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Shawn Pearce @ 2006-10-10 16:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90610091408y29f60a12gea7040b5412331c6@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> However, I don't think that scenario is hard to support and Git can
> have a much better story to tell than keyword substituting SCMs.
>
> If we have a tool that I can pass a file or a directory tree and will
> find the (perfectly|closely) matching trees and related commits.
>
> For the single file case, searching for an exact SHA1 match is easy,
> as is by path. If we get a file without a path it gets a bit harder --
> is there a way to scan the object store for blobs of around a given
> size (as the packing code does) from Perl? Actually, if we find a
> relatively close match, it'd be useful to ask git if it's deltified
> and ask for other members of the delta chain.
git-verify-pack -v will print every SHA1, its type and its
decompressed size. It also prints who its delta base is. Its also
not very fast. However if you run that on a pack file once and
cache the result then you have much of the data you are looking for.
You can find objects within a margin of error of the blob size,
then find all objects in those delta chains. Then start fetching
those objects and comparing contents. But this is brutal and will
take a long time due to the sheer number of objects that probably
would fall into that size bucket.
The single file case without a path is not an easy problem. Even if
you have an exact SHA1 match (an unmodified file) its difficult
to find what commits used that SHA1 somewhere within their trees.
You need to unpack every tree in every commit and test every
entry for a match. That's going to take a while on any decent
sized repository.
Most maintainers would just toss the modified file pack at the sender
and say "Uh, where did this file come from?!" And rightly so.
A maintainer familiar with that section of the repository might
recognize some of the file contents and be able to guess the
filename. So in short I don't think the single file case without
filename is doable, and I don't think its very useful either.
> For the directory tree case, the ideal thing would be to build a
> temporary index without getting the blobs in the object store, and
> then do a first pass trying to match tree SHA1s. If the user has
> modified a few files in a large project, it'll be trivial to find a
> good candidate commit for delta. OTOH, if the user has indulged in
> wide ranging search and replace... it will be well deserved pain ;-)
You have a chance in the tree case. If you have the entire tree
as a working directory and the modifications made are limited to
a handful of paths then you can load that working directory into a
set of tree objects and perform a match process by walking backwards
through the commit chains looking for trees which have a high number
of paths in common with the working directory.
Unfortunately this also has limited use (but I have one myself!).
If you got the entire working directory from a submitter than that
implies they took your entire distribution, unpacked it, hacked away,
repacked it and sent you the tar/zip file. That's significantly
larger than a simple patch file produced by diff -R. As a maintainer
you probably should be kicking that back at the user and saying
"Uh, please submit a patch instead, thanks."
I actually have a scenario where I'm using Git to track another
(much, much crappier) file revision storage tool that would probably
benefit from this, but the benefit is relatively low.
I'm completely unable to read that tool's version data. The only
thing I can get from that tool is a snapshot of files as they exist
at the point in time that I am running the snapshot. The snapshots
aren't always consistent with themselves. Worse they take upwards
of 30 minutes to run, can only run on a Windows desktop, and consume
100% of the CPU while running. So we cannot get them very often.
I have several users working on those files in Git through a common
shared repository. We send changes to that file revision storage
tool on a frequent basis, say up to 3-5 times per day. Each such
change is basically a squashed merge commit in Git terminology,
so the fine grained commits in Git aren't being preserved by that
storage tool, despite being in our shared Git repository.
Many days later most of the changes the users put into the storage
tool suddenly appear on the next snapshot we obtain from it. I say
most because sometimes the powers that be either don't permit a
change to show up in the snapshot and delay it for a while, or
because they actually wanted to include a change but someone fat
fingered the storage controls and the change got omitted. Yet the
powers that be *believe* the change is included, right up through
testing accusing development of not fixing the bug despite the fix
being there in the file revision storage tool.
Now I'd like to take these snapshots every so often, load them
into Git on a special branch just for the snapshots, then generate
a merge commit on that branch which merges the real commit that
corresponds as closely as possible to to this snapshot into the
snapshot branch. Part of the reason for doing this is to look
for unexpected differences between what Git has and what the file
revision storage tool has.
But doing that is nearly impossible, so I don't.
--
Shawn.
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Linus Torvalds @ 2006-10-10 17:14 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Martin Langhoff, git
In-Reply-To: <20061010164927.GC16412@spearce.org>
On Tue, 10 Oct 2006, Shawn Pearce wrote:
>
> Now I'd like to take these snapshots every so often, load them
> into Git on a special branch just for the snapshots, then generate
> a merge commit on that branch which merges the real commit that
> corresponds as closely as possible to to this snapshot into the
> snapshot branch. Part of the reason for doing this is to look
> for unexpected differences between what Git has and what the file
> revision storage tool has.
>
> But doing that is nearly impossible, so I don't.
Well, it probably wouldn't be too nasty to try to have a "find nearest
commit" kind of thing. It's not quite as simple as bisection, but you
could probably use a bisection-like algorithm to do something like a
binary search to try to guess which tree is the closest.
In other words, if you just give git a "range" of commits to look at, and
let a bisection-line thing pick a mid-way point, you can then compare the
mid-way point and the end-points (more than two) against the target tree,
and then pick the range that looks "closer".
I wouldn't guarantee that it finds the best candidate (since the "closer"
choice will inevitably not guarantee a monotonic sequence), but I think
you could probably most of the time find something that is reasonably
close.
If you do a lot of branching, you'd have to be a lot smarter about it
(since you'd not have _one_ commit for beginning/end), but in a
straight-line tree it should be really trivial, and in a branchy one I
think it should still be quite doable.
I dunno. It might be useful even if it's just a heuristic, in a "try to
find a commit in the range X..Y that generates the smallest diff when
compared against this tree". If it finds something sucky, you can try to
look at the history of one of the files that generates a big diff, and try
to give a better range - the automation should hopefully have given you
_some_ clues.
Linus
^ permalink raw reply
* Approxidate licensing
From: Daniel Barkalow @ 2006-10-10 17:39 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano, dwmw2; +Cc: git
I'm working on an LGPL project (for my company; it's obscure enough and
we're lazy enough that we're not really distributing it in general in
either source or binary form), and I'm running into the usual date parsing
issue (i.e., all the standard functions are broken in various ways). My
plan has been to write my own, but it's hard to get the motivation when
approxidate exists, works well, and is open source.
Would the three of you agree to license date.c under the LGPL or BSD? It
looks like you're the only authors of non-trivial changes [1]. And it seems
reasonable to want the date parsing thing under non-GPL terms outside of
git.
-Daniel
*This .sig left intentionally blank*
[1] git log and git blame are pretty impressive, but they don't quite
catch that most of date.c was written by David as part of commit-tree.c,
then Tony replaced it with a version that uses curl, then Edgar separated
it out into a date.c and simultaneously reverted Tony's changes. On the
other hand, the commit messages do say this, and you can use git log and
git blame to verify that they're true. The only thing they don't let
you verify is what the differences are between the date.c added in
ecee9d9e and the similar part of commit-tree.c in 812666c8. If someone
wants to make git blame *really* magic, date.c would be a good test case.
^ permalink raw reply
* Re: Does GIT has vc keywords like CVS/Subversion?
From: Junio C Hamano @ 2006-10-10 17:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Shawn Pearce, Martin Langhoff
In-Reply-To: <Pine.LNX.4.64.0610101005420.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Well, it probably wouldn't be too nasty to try to have a "find nearest
> commit" kind of thing. It's not quite as simple as bisection, but you
> could probably use a bisection-like algorithm to do something like a
> binary search to try to guess which tree is the closest.
I had to do something like that in my day job once. A customer
installation was made from a tarball of unknown vintage, and
then field patched with later fixes.
I ended up slurping the thing back and populated my index with
it. Luckily I could guess a good initial point to find the
commit that gives minimum "git diff" output. Then from the
remaining patches it was reasonably easy to find out which
changes were cherry-picked by hand with "git log master --
$paths".
^ permalink raw reply
* Re: GIT 1.4.3-rc2
From: Junio C Hamano @ 2006-10-10 17:42 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061010093914.GC8612@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> have you looked into the git-fetch --update-head-ok thing I sent last
> week?
I remember seeing it and wondering what workflow would need it.
Also at the same time I wondered if it was indeed needed for a
workflow why that workflow can get away with adding only that
option to git-fetch without either adding more things to it or
have a custom porcelain that drives the underlying
git-fetch-pack directly.
In the end I dropped it on the floor because what I wondered
about was not clear from the proposed commit log message.
^ permalink raw reply
* Re: Why gitweb commitdiff NO diff output ?
From: Junio C Hamano @ 2006-10-10 17:42 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <4b3406f0610100346v16f1f2f6i305963bc1b398dac@mail.gmail.com>
"Dongsheng Song" <dongsheng.song@gmail.com> writes:
> Thanks, now that's OK.
>
>> I am not sure what version of gitweb your distribution packages,
>> but it used to be that commitdiff page wanted to create
>> temporary file somewhere on the filesystem (the variable was
>> $git_temp and by default it was set to "/tmp/gitweb", I think).
>> Your other pages such as commit and log page seem to be working,
>> so perhaps your gitweb has trouble writing there only on that
>> machine?
Care to share your experience to help others?
If it was /tmp/gitweb permission problem then the newer gitweb
shouldn't have that issue so it would be a moot point, but if
the pitfall still applies to the current software we might want
to add a "common pitfals" section to gitweb/README.
^ permalink raw reply
* Re: is git-unpack-objects now redundant for 'git-push' and friends?
From: Junio C Hamano @ 2006-10-10 17:44 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <452B9EE8.5020702@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> When pushing or pulling to/from a repository, why unpack the objects?
> Why not just fsck and then throw the pack into $GIT_DIR/objects/pack?
>...
> I suspect that this was never changed, because there never used to be
> more than one packfile allowed, correct?
We've supported more than one packs at the same time from the
day we supported packs.
Primary reason that push never keeps the pack is that explosion
into loose objects hurts you only at the first round and later
pushes are supposed to be much smaller, so changing it to keep
the pack for the initial one has a very small value making it a
very low priority change. Not keeping the pack on push makes it
possible to always use --thin for pushing if we wanted to.
On the fetch side you could use --keep option when you know the
fetch will be huge.
^ permalink raw reply
* Re: [PATCH] Understand the meaning of commas in git-send-email
From: Junio C Hamano @ 2006-10-10 17:44 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: git
In-Reply-To: <20061010145936.GC8993@parisc-linux.org>
Matthew Wilcox <matthew@wil.cx> writes:
> I made the mistake of adding one Cc: line with two email addresses on
> it, instead of two Cc: lines with one email address each. Extending
> git-send-email to parse that case turns out to not be too much work.
>
> Signed-off-by: Matthew Wilcox <matthew@wil.cx>
I am not sure. The input addresses this part of the code deals
with are of human readable form
Matthew Wilcox <matthew@wil.cx>
matthew@wil.cx (Matthew Wilcox)
and the loop is extracting the part inside <> pair.
I have a mild suspicion that your patch may need to understand
quoting to handle somebody else's name safely and correctly.
junkio@cox.net (Junio C Hamano, aka gitster)
^ permalink raw reply
* Re: [PATCH] Add --dry-run option to git-send-email
From: Junio C Hamano @ 2006-10-10 17:44 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: git
In-Reply-To: <20061010145823.GB8993@parisc-linux.org>
Matthew Wilcox <matthew@wil.cx> writes:
> Add a --dry-run option to git-send-email due to having made too many
> mistakes with it in the past week. I like having a safety catch on my
> machine gun.
>
> Signed-off-by: Matthew @ilcox <matthew@wil.cx>
Good.
When I have to look into other people's issues with send-email,
I used to say "--smtp-server=/var/tmp/send" which is this
script:
#!/bin/sh
for i
do
echo "arg $i"
done
sed -e 's/^/Msg: /'
I hope your patch makes the above hack unneeded (I want to see
what is fed to sendmail, what goes on the header and body).
^ permalink raw reply
* Re: GIT 1.4.3-rc2
From: Martin Waitz @ 2006-10-10 17:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsd02hkm.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
hoi :)
On Tue, Oct 10, 2006 at 10:42:33AM -0700, Junio C Hamano wrote:
> > have you looked into the git-fetch --update-head-ok thing I sent last
> > week?
>
> I remember seeing it and wondering what workflow would need it.
> Also at the same time I wondered if it was indeed needed for a
> workflow why that workflow can get away with adding only that
> option to git-fetch without either adding more things to it or
> have a custom porcelain that drives the underlying
> git-fetch-pack directly.
I was wondering about it, too.
That's why I haven't added a [PATCH] tag to the message
and just added the diff to show the broken part ;-).
It is clear that the code as it is now does not work but perhaps
the right fix is to simply kill that option.
As nobody replied to the message I guess that nobody cares and
we can remove it after the release.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn fetch fails when a file is renamed changing only case
From: Pazu @ 2006-10-10 17:57 UTC (permalink / raw)
To: git
In-Reply-To: <egevhe$d15$1@sea.gmane.org>
Pazu wrote:
> Well, I'll keep browsing the git-svn source code, and try to make some
> sense out of it...
While doing that I noticed the error happens in a code path that only
gets executed when SVN::Core isn't available. So I decided to go through
the trouble of manually building and installing the subversion perl
bindings, and to my delight, git-svn is working flawlessly now.
Since svn binaries *use* the svn libraries, I still don't think this was
subversion's fault, but probably some bug in git-svn parsing svn output.
Oh well, using SVN::Core fixed, and git-svn is a lot faster to boot.
-- Marcus
^ permalink raw reply
* paginate git-diff by default?
From: Martin Waitz @ 2006-10-10 18:13 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 233 bytes --]
hoi :)
I always find myself typing "git -p diff".
Should we paginate git-diff output by default?
I was sure this was discussed before but I could not immediately
find it, so I'm simply asking again ;-).
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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