* Re: UI tweak suggestion for kernel.org git web gui.
From: Kay Sievers @ 2005-11-21 16:55 UTC (permalink / raw)
To: Rob Landley; +Cc: git
In-Reply-To: <200511211019.51110.rob@landley.net>
On Mon, Nov 21, 2005 at 10:19:50AM -0600, Rob Landley wrote:
> When I view the changelog at:
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog
>
> It mixes in tags, which is cool, but they're the same color as regular
> commits.
They are all commits. There is nothing "mixed". Tags usually just point
to a commit.
> Is there any way that tags could stand out visually? (Bold them,
> give them a different color background, etc.)
You mean, you want to see in the list of commits, the ones marked, which
a tag is pointing to? Similar to what gitk is doing?
> I'd try to ask this in the right place, but the above page doesn't even say
> which git web display package kernel.org is using. (A small discreet link at
> the bottom would be nice...)
There is no package for gitweb. Just the single gitweb.cgi file, which is
copied there. You can get the gitweb version in the html source. Just do
"view source" in your browser.
Kay
^ permalink raw reply
* [PATCH] git-daemon not listening when compiled with -DNO_IPV6
From: Paul Serice @ 2005-11-21 17:07 UTC (permalink / raw)
To: git
git-daemon was not listening when compiled with -DNO_IPV6.
socksetup() was not returning socket count when compiled with -DNO_IPV6.
Signed-off-by: Paul Serice <paul@serice.net>
---
daemon.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
applies-to: 339319e60db7b3f96f8c711407b135a54da7aa2e
bb8968537a35a635c6f8a6393cff8735b4edcef9
diff --git a/daemon.c b/daemon.c
index 2b81152..e889596 100644
--- a/daemon.c
+++ b/daemon.c
@@ -510,8 +510,14 @@ static int socksetup(int port, int **soc
return 0;
}
+ if (listen(sockfd, 5) < 0) {
+ close(sockfd);
+ return 0;
+ }
+
*socklist_p = xmalloc(sizeof(int));
**socklist_p = sockfd;
+ return 1;
}
#endif
---
0.99.9i
^ permalink raw reply related
* Re: [RFC] git-format-patch options
From: Luben Tuikov @ 2005-11-21 17:36 UTC (permalink / raw)
To: Andreas Ericsson, git
In-Reply-To: <4381F97A.9010105@op5.se>
--- Andreas Ericsson <ae@op5.se> wrote:
>
> Please don't. git-format-patch is generally used to send
Ok, so then when I want to extract a single commit into a patch in a patch format, I loosely do
(scripted):
git-rev-list --pretty=raw --max-count=1 <commit-ish>
Then I record the parent <parent> of the commit-ish and do:
git-format-patch [output options] <parent>..<commit-ish>
Which gives me the commit with id <commit-ish> as a
formatted patch.
Is there an alernative to this, as opposed to the two
step procedure above?
Luben
^ permalink raw reply
* Re: UI tweak suggestion for kernel.org git web gui.
From: Rob Landley @ 2005-11-21 17:41 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <20051121165522.GA3217@vrfy.org>
On Monday 21 November 2005 10:55, Kay Sievers wrote:
> On Mon, Nov 21, 2005 at 10:19:50AM -0600, Rob Landley wrote:
> > When I view the changelog at:
> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=sh
> >ortlog
> >
> > It mixes in tags, which is cool, but they're the same color as regular
> > commits.
>
> They are all commits. There is nothing "mixed". Tags usually just point
> to a commit.
>
> > Is there any way that tags could stand out visually? (Bold them,
> > give them a different color background, etc.)
>
> You mean, you want to see in the list of commits, the ones marked, which
> a tag is pointing to? Similar to what gitk is doing?
I don't know what gitk is.
This shows tags on the bottom half of this page, with the last few commits in
the top half:
http://www.kernel.org/git/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=summary
If I click on the "..." under shortlog, I get to see a full page of commits,
which does (currently) include the -rc2 tag.
My use case is I want to see what commits have gone in since the last tarball
I downloaded. (Waiting for various patches to be merged, etc.) The tag
indicates the last intentionally released (and thus minimally tested)
tarball, so it would be nice if the tag's entry was visually distinct in the
big list.
> > I'd try to ask this in the right place, but the above page doesn't even
> > say which git web display package kernel.org is using. (A small discreet
> > link at the bottom would be nice...)
>
> There is no package for gitweb. Just the single gitweb.cgi file, which is
> copied there. You can get the gitweb version in the html source. Just do
> "view source" in your browser.
Ah:
<!-- git web interface v252, (C) 2005, Kay Sievers <kay.sievers@vrfy.org>,
Christian Gierke <ch@gierke.de> -->
Good to know.
> Kay
Rob
^ permalink raw reply
* Re: [RFC] git-format-patch options
From: Andreas Ericsson @ 2005-11-21 17:59 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051121173603.73700.qmail@web31806.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Andreas Ericsson <ae@op5.se> wrote:
>
>
>>Please don't. git-format-patch is generally used to send
>
>
> Ok, so then when I want to extract a single commit into a patch in a patch format, I loosely do
> (scripted):
>
> git-rev-list --pretty=raw --max-count=1 <commit-ish>
>
> Then I record the parent <parent> of the commit-ish and do:
>
> git-format-patch [output options] <parent>..<commit-ish>
>
> Which gives me the commit with id <commit-ish> as a
> formatted patch.
>
> Is there an alernative to this, as opposed to the two
> step procedure above?
>
Here's how to automate it.
git format-patch $(git rev-list --max-count=2 <commit-ish> | tail -n
1)..<commit-ish>
Either way, you need to know <commit-ish>, but this format should be
fairly easy to add to git-format-patch. If you do, please let the user
specify the --max-count (but default to 1) so it can be used to extract
a series of patches rather than just one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] Using sticky directories to control access to branches.
From: Carl Baldwin @ 2005-11-21 18:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfypumlu3.fsf@assigned-by-dhcp.cox.net>
OK,
To follow-up on this. Here is a final version of this script that was
started by Junio. I polished it and made it work the way I want it.
Hopefully, someone on the list will find it useful.
Here is a basic description. There are two files:
.git/info/allowed-users
.git/info/allowed-groups
The users file is checked, line by line, followed by the groups file.
The first line matching the ref to be updated is used. Each line has
one regular expression to match the ref followed by one or more regular
expressions to match user (or group). Space is the delimeter so the RE
cannot contain a space.
If no line matches the ref then access is denied. For this reason I
tend to include the following line as the last line of allowed-groups as
the default since it will match any ref and any group.
.* .*
Here is the hook script... Thanks to Junio for getting me started. I
rewrote the whole thing using my own style but much of the code is based
on his.
#!/bin/bash
umask 002
verbose=no
# Default shell globbing messes things up later
GLOBIGNORE=*
function grant {
[ "yes" == "$verbose" ] && echo >&2 "-Grant- $1"
exit 0
}
function deny {
[ "yes" == "$verbose" ] && echo >&2 "-Deny- $1"
exit 1
}
function info {
[ "yes" == "$verbose" ] && echo >&2 "-Info- $1"
}
# Implement generic branch and tag policies.
# - Tags should not be updated once created.
# - Branches should only be fast-forwarded.
case "$1" in
refs/tags/*)
[ -f "$GIT_DIR/$1" ] && deny "You can't overwrite an existing tag"
;;
refs/heads/*)
# No rebasing or rewinding
if expr "$2" : '0*$' >/dev/null; then
info "The branch '$1' is new..."
else
# updating -- make sure it is a fast forward
mb=$(git-merge-base "$2" "$3")
case "$mb,$2" in
"$2,$mb") info "Update is fast-forward" ;;
*) deny "This is not a fast-forward update." ;;
esac
fi
;;
*)
deny "Branch is not under refs/heads or refs/tags. What are you trying to do?"
;;
esac
# Implement per-branch controls based on username
allowed_users_file=$GIT_DIR/info/allowed-users
username=$(id -u -n)
info "The user is: '$username'"
if [ -f "$allowed_users_file" ]; then
3<$allowed_users_file
while read -u 3 head_pattern user_patterns; do
matchlen=$(expr "$1" : "$head_pattern")
if [ "$matchlen" == "${#1}" ]; then
info "Found matching head pattern: '$head_pattern'"
for user_pattern in $user_patterns; do
info "Checking user: '$username' against pattern: '$user_pattern'"
matchlen=$(expr "$username" : "$user_pattern")
if [ "$matchlen" == "${#username}" ]; then
grant "Allowing user: '$username' with pattern: '$user_pattern'"
fi
done
deny "The user is not in the access list for this branch"
fi
done
fi
allowed_groups_file=$GIT_DIR/info/allowed-groups
groups=$(id -G -n)
info "The user belongs to the following groups:"
info "'$groups'"
if [ -f "$allowed_groups_file" ]; then
4<$allowed_groups_file
while read -u 4 head_pattern group_patterns; do
matchlen=$(expr "$1" : "$head_pattern")
if [ "$matchlen" == "${#1}" ]; then
info "Found matching head pattern: '$head_pattern'"
for group_pattern in $group_patterns; do
for groupname in $groups; do
info "Checking group: '$groupname' against pattern: '$group_pattern'"
matchlen=$(expr "$groupname" : "$group_pattern")
if [ "$matchlen" == "${#groupname}" ]; then
grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
fi
done
done
deny "None of the user's groups are in the access list for this branch"
fi
done
fi
deny "There are no more rules to check. Denying access"
# End script here
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: default update hook broken
From: Andreas Ericsson @ 2005-11-21 18:08 UTC (permalink / raw)
To: git
In-Reply-To: <20051121140914.GB1598@parisc-linux.org>
Matthew Wilcox wrote:
> There's two syntax errors and one good-netizen error in the hooks/update
> file created when cloning Linus' linux-2.6.git repo. I don't know
> if that file is created fresh or if it gets pulled from Linus' tree.
> Here's a patch to fix it
>
Good thing I read new list entries before I send things. I did this
exact same patch too. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] git-format-patch options
From: Luben Tuikov @ 2005-11-21 18:27 UTC (permalink / raw)
To: Andreas Ericsson, git
In-Reply-To: <43820AF8.5060208@op5.se>
--- Andreas Ericsson <ae@op5.se> wrote:
> Here's how to automate it.
>
> git format-patch $(git rev-list --max-count=2 <commit-ish> | tail -n
> 1)..<commit-ish>
I've a similar script, called
"git-format-commit-patch <commit-ish>" which is slightly
more involved.
> Either way, you need to know <commit-ish>, but this format should be
> fairly easy to add to git-format-patch. If you do, please
How about git-format-patch --commit <commit-ish>
to generate the formatted patch of only what _that_ commit
introduced? (i.e. <parent>..<commit-ish>)
Do people find this valuable to have?
Luben
P.S. Since it is really trivial to write such a script
on top of git-rev-list and git-format-patch, it may be
easier to just leave things as they are. It was just
something I needed, which I thought other people might
need too.
^ permalink raw reply
* Re: Pure renames/copies
From: Linus Torvalds @ 2005-11-21 18:37 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <87hda61a80.fsf@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3291 bytes --]
On Mon, 21 Nov 2005, Santi Béjar wrote:
>
> Is there any way to ask git to find pure renames or copies?
Not directly, but git sure makes it easy for you.
Do this:
git-diff-tree -r old..new |
grep '^:[^<tab>]*0000000000000000000000000000000000000000'
and you'll get all the information (that "<tab>" is obviously the tab
character) you need to efficiently do it (or, if you want to just do one
commit, just do "git-diff-tree -r cmit").
In the git tree, commit 0086e2c854e3af3209915e4ec2f933bcef400050 can act
as a good example of this: the output of
git-diff-tree -r 0086e2c854e3af3209915e4ec2f933bcef400050
is
0086e2c854e3af3209915e4ec2f933bcef400050
:100644 100644 328b399f9fe6e2b668691ab359319f50561cd773 16a8af63f0523cec82faa23f29cee579ac224e82 M .gitignore
:100644 000000 a8cc5739d7851da3aeca2388d74eb92c464f1732 0000000000000000000000000000000000000000 D Documentation/git-lost+found.txt
:000000 100644 0000000000000000000000000000000000000000 03156f218bb41b955779207ec2e94120f958fc45 A Documentation/git-lost-found.txt
:100644 100644 a9d47c115c071694321d076af8a73a06ddd46875 1c32dd5be7156ae0e1142523fe50d84745964793 M Documentation/git.txt
:100644 100644 b75cb137875b3cdb8746d2e0135e6f2743e2046a 5b2eca897386e17021d2a8a052b0c2759df96447 M Makefile
:100755 000000 3892f52005d1e36676681806a87ef35dc0689f22 0000000000000000000000000000000000000000 D git-lost+found.sh
:000000 100755 0000000000000000000000000000000000000000 3892f52005d1e36676681806a87ef35dc0689f22 A git-lost-found.sh
and then after the "grep", you have just
:100644 000000 a8cc5739d7851da3aeca2388d74eb92c464f1732 0000000000000000000000000000000000000000 D Documentation/git-lost+found.txt
:000000 100644 0000000000000000000000000000000000000000 03156f218bb41b955779207ec2e94120f958fc45 A Documentation/git-lost-found.txt
:100755 000000 3892f52005d1e36676681806a87ef35dc0689f22 0000000000000000000000000000000000000000 D git-lost+found.sh
:000000 100755 0000000000000000000000000000000000000000 3892f52005d1e36676681806a87ef35dc0689f22 A git-lost-found.sh
left, which shows you the new and the deleted files.
Then, look for renames: just match up a new file that has the same SHA1 as
a deleted file, and you can see that the change from "git-lost+found.sh"
to "git-lost-found.sh" was exactly such an exact rename, because they
share the 3892f52005d1e36676681806a87ef35dc0689f22 SHA1.
After rename detection, look at any remaining new files (in the above
example, only
:000000 100644 0000000000000000000000000000000000000000 03156f218bb41b955779207ec2e94120f958fc45 A Documentation/git-lost-found.txt
would be left), and try to match up the SHA1 of that file with the result
of "git-ls-tree -r $old", ie something like
git-ls-tree -r 0086e2c854e3af3209915e4ec2f933bcef400050^ |
grep 03156f218bb41b955779207ec2e94120f958fc45
which in this case is empty (that new file wasn't an exact copy of any old
file, it was a rename+edit, of course).
Very efficient, very simple, you can do it either with a small
shell-script (using cut + sort + join + grep), or write a specialized tool
around the git-diff-tree logic.
Of course, arguably "-M100" should really do this optimization for you.
Junio?
Linus
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Carl Baldwin @ 2005-11-21 19:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0510131113490.15297@g5.osdl.org>
I have a question about automatic repacking.
I am thinking of turning something like Linus' repacking heuristic loose
on my repositories. I just want to make sure it is as safe as possible.
At the core of the incremental and full repack strategies are these
statements.
Incremental...
> git repack &&
> git prune-packed
Full...
> git repack -a -d &&
> git prune-packed
Are there some built in safety checks in 'git repack' and/or 'git
prune-packed' to guard against corruption? In the long run, I would
feel more comfortable with somelike like this:
git repack
git verify-pack <new pack>
git prune-packed
Would something like this even work with 'git repack -a -d'? Is there a
way to do something like the following for a full repack to achieve the
ultimate in paranoia?
git repack -a
git verify-pack <new pack file>
git trash-redundant-packs <new pack file>
git prune-packed
Carl
On Thu, Oct 13, 2005 at 11:44:30AM -0700, Linus Torvalds wrote:
>
> I know we tried this once earlier, and it caused problems, but that was
> when pack-files were new, and not everybody could handle them. These days,
> if you can't handle pack-files, kernel.org is already pretty useless,
> because all the major packages use them anyway, because people have
> packed their repositories by hand.
>
> So I'm suggesting we try to do an automatic repack every once in a while.
>
> In my suggestion, there would be two levels of repacking: "incremental"
> and "full", and both of them would count the number of files before they
> run, so that you'd only do it when it seems worthwhile.
>
> This is a _really_ simple heuristic:
>
> - incremental repacking run every day:
>
> #
> # Check if we have more than a couple of hundred
> # unpacked objects - approximated by whether we
> # have any "00" directory with more than one
> #
> # This means that we don't repack projects that
> # that don't have a lot of work going on.
> #
> # Note: with really new versions of git, the "00"
> # directory may not exist if it has been pruned
> # away, so handle that gracefully.
> #
> export GIT_DIR=${1:-.}
> objs=$(find "$GIT_DIR/objects/00" -type f 2> /dev/null | wc -l)
> if [ "$obj" -gt 0 ]; then
> git repack &&
> git prune-packed
> fi
>
> - "full repack" every week if the number of packs has grown to be bigger
> than say 10 (ie even a very active projects will never have a full
> repack more than every other week)
>
> #
> # Check if we have lots of packs, where "lots" is defined as 10.
> #
> # Note: with something that was generated with an old version
> # of git, the "pack" directory may not exist, so handle that
> # gracefully.
> #
> export GIT_DIR=${1:-.}
> packs=$(find "$GIT_DIR/objects/pack" -name '*.idx' 2> /dev/null | wc -l)
> if [ "$packs" -gt 10 ]; then
> git repack -a -d &&
> git prune-packed
> fi
>
> - do a full repack of everything once to start with.
>
> export GIT_DIR=${1:-.}
> git repack -a -d &&
> git prune-packed
>
> the above three trivial scripts just take a single argument, which becomes
> the GIT_DIR (and if no argument exists, it would default to ".")
>
> Is there any reason not to do this? Right now mirroring is slow, and
> webgit is also getting to be very slow sometimes. I bet we'd be _much_
> better off with this kind of setup.
>
> NOTE! The above is the "stupid" approach, which totally ignores alternate
> directories, and isn't able to take advantage of the fact that many
> projects could share objects. But it's simple, and it's efficient (eg it
> won't spend time on things like the large historic archives which don't
> change, but that would be expensive to repack if you didn't check for the
> need).
>
> So we could try to come up with a better approach eventually, which would
> automatically notice alternate directories and not repack stuff that
> exists there, but I'm pretty sure that the above would already help a
> _lot_, and while pack-files have been been around forever, the
> "alternates" support is still pretty new, so the above is also the "safer"
> thing to do.
>
> We'd only do the automatic thing on stuff under /pub/scm, of course: not
> stuff in peoples home directories etc..
>
> Peter?
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [RFC] git-format-patch options
From: Ryan Anderson @ 2005-11-21 19:11 UTC (permalink / raw)
To: ltuikov; +Cc: Andreas Ericsson, git
In-Reply-To: <20051121182737.43012.qmail@web31811.mail.mud.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
Luben Tuikov wrote:
> --- Andreas Ericsson <ae@op5.se> wrote:
>
>
>>Here's how to automate it.
>>
>>git format-patch $(git rev-list --max-count=2 <commit-ish> | tail -n
>>1)..<commit-ish>
>
>
> I've a similar script, called
> "git-format-commit-patch <commit-ish>" which is slightly
> more involved.
>
>
>>Either way, you need to know <commit-ish>, but this format should be
>>fairly easy to add to git-format-patch. If you do, please
>
>
> How about git-format-patch --commit <commit-ish>
> to generate the formatted patch of only what _that_ commit
> introduced? (i.e. <parent>..<commit-ish>)
Doesn't git-format-patch $commit^1..$commit do what you want?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [RFC] git-format-patch options
From: Junio C Hamano @ 2005-11-21 19:27 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git, Andreas Ericsson
In-Reply-To: <20051121162540.4722.qmail@web31812.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> I was wondering about the value of
>
> git-format-patch <commit-ish>
>
> to output/prepare a diff patch between the indicated commit
> and its parent. As opposed to the current behaviour giving
> all changes between the indicated commit and HEAD.
Yes, that would be "git-format-patch $commit^1 $commit", but it
might deserve better shortcuts.
Later Andreas quoted the backward compatibility constraints:
> # Backward compatible argument parsing hack.
> #
> # Historically, we supported:
> # 1. "rev1" is equivalent to "rev1..HEAD"
> # 2. "rev1..rev2"
> # 3. "rev1" "rev2 is equivalent to "rev1..rev2"
> #
> # We want to take a sequence of "rev1..rev2" in general.
> # Also, "rev1.." should mean "rev1..HEAD"; git-diff users are
> # familiar with that syntax.
The case statement that follows that comment is not quite right,
BTW. "format-patch foo bar..baz" should mean sequence of "foo"
and then "bar..baz", but it incorrectly translates to a
malformed "foo..bar..baz".
Modulo that bug, what the current code does is to special case
one or two arguments case and rewrite them in that case
statement, and then iterate over the resulting "$@". We barf if
each 'revpair' is not in rev1..rev2 format.
But it might make sense to (still keeping the above three
backward compatibility syntax exceptions) interpret "rev" to
mean "rev^1..rev", like this:
---
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 7ee5d32..351790c 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -99,7 +99,7 @@ filelist=$tmp-files
# Also, "rev1.." should mean "rev1..HEAD"; git-diff users are
# familiar with that syntax.
-case "$#,$1" in
+case "$#,$1$2" in
1,?*..?*)
# single "rev1..rev2"
;;
@@ -131,7 +131,8 @@ do
rev2=`expr "$revpair" : '.*\.\.\(.*\)'`
;;
*)
- usage
+ rev1="$revpair^"
+ rev2="$revpair"
;;
esac
git-rev-parse --verify "$rev1^0" >/dev/null 2>&1 ||
^ permalink raw reply related
* Re: [RFC] Using sticky directories to control access to branches.
From: Junio C Hamano @ 2005-11-21 19:29 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20051121180133.GA28171@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> To follow-up on this. Here is a final version of this script that was
> started by Junio. I polished it and made it work the way I want it.
> Hopefully, someone on the list will find it useful.
Looking good. We might want to have collections of user
contributed hooks, maybe a new directory examples/ perhaps?
^ permalink raw reply
* Re: [RFC 1/2] Use remote information in .git/config
From: Junio C Hamano @ 2005-11-21 19:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511211452470.13775@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This patch allows to store shortcuts for fetch/pull into the config:
>
> [remote.junio]
> url = http://www.kernel.org/pub/scm/git/git.git
> pull = master:junio
> pull = todo:todo
> pull = +pu:pu
>
> Note that there is only one pair per "pull" line, to allow for spaces
> (urgh!) in the branch names.
I think "allow for spaces" nonsense can be removed by now. I
did it initially that way before making the ref name validation
tighter with check-ref-format. And if I understand what you
wrote about multivalues correctly, your intent is that "orders
do not matter"; with pull refspecs, orders do matter, so it
probably is a good idea to allow only a single line.
Personally I do not mind moving remotes/branches information
there, except that I suspect the git-config-set interface makes
it cumbersome to (1) find out what remotes I defined (i.e. an
equivalent of "ls .git/remotes") and (2) remove a single remote
when I do not want it anymore (--unset-all would remove the keys
but would leave the empty section).
I am unsure if putting everything in .git/config file is the
right approach, though. What will we put there next? ls-files
ignore patterns? grafts? alternates? We should be able to
even get rid of .git/refs directory hierarchy and replace that
with something like this:
[refs]
head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for master
head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for pu
tag = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for v1.0rc1
...
Where will we stop, and why?
I am worried about people later asking "why do we have X in
config but not Y"?
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Linus Torvalds @ 2005-11-21 19:24 UTC (permalink / raw)
To: Carl Baldwin; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <20051121190151.GA2568@hpsvcnb.fc.hp.com>
On Mon, 21 Nov 2005, Carl Baldwin wrote:
>
> I have a question about automatic repacking.
>
> I am thinking of turning something like Linus' repacking heuristic loose
> on my repositories. I just want to make sure it is as safe as possible.
>
> At the core of the incremental and full repack strategies are these
> statements.
>
> Incremental...
> > git repack &&
> > git prune-packed
>
> Full...
> > git repack -a -d &&
> > git prune-packed
NOTE! Since that email, "git repack" has gotten a "local" option (-l),
which is very useful if the repositories have pointers to alternates.
So do
git repack -l
instead, to get much better packs (and "-a -d" for the full case, of
course).
Other that than, the old email suggestion should still be fine.
> Are there some built in safety checks in 'git repack' and/or 'git
> prune-packed' to guard against corruption? In the long run, I would
> feel more comfortable with somelike like this:
>
> git repack
> git verify-pack <new pack>
> git prune-packed
You can certainly do that if you are nervous. It might even be a good
idea: just for fun, I just did
git clone -l git git-clone
cd git-clone
# pick an object at random
rm .git/objects/f7/c3d39fe3db6da3a307da385a7a1cb563ed15f7
git repack -a -d
and it said:
error: Could not read f7c3d39fe3db6da3a307da385a7a1cb563ed15f7
fatal: bad tree object f7c3d39fe3db6da3a307da385a7a1cb563ed15f7
but then it created the pack _anyway_, and said:
Packing 27 objects
Pack pack-13bfca704078175c1c1c59964553b14f7b952651 created.
and happily removed all the old ones.
So right now, repacking a broken archive can actually break it even more.
NOTE! Your "git verify-pack" wouldn't even catch this: the _pack_ is fine,
it's just incomplete.
Of course, this only happens if the repository was broken to begin with,
so arguably it's not that bad. But it does show that git-repack should be
more careful and return an error more aggressively.
Can anybody tell me how to do that sanely? Right now we do
..
name=$(git-rev-list --objects $rev_list $(git-rev-parse $rev_parse) |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
exit 1
..
and the thing is, the "git-pack-objects" thing is happy, it's the
"git-rev-list" that fails. So because the last command in the pipeline
returns ok, we think it all is ok..
(This is one of the reasons I much prefer working in C over working in
shell: it may be twenty times more lines, but when you have a problem, the
fix is always obvious..)
Anyway, with that fixed, a "git repack" in many ways would be a mini-fsck,
so it should be very safe in general. Modulo any other bugs like the
above.
Linus
^ permalink raw reply
* Re: Pure renames/copies
From: Junio C Hamano @ 2005-11-21 19:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511211020130.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Of course, arguably "-M100" should really do this optimization for you.
> Junio?
I'd agree. That is what -M100 should mean.
^ permalink raw reply
* Re: Pure renames/copies
From: Junio C Hamano @ 2005-11-21 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511211020130.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Of course, arguably "-M100" should really do this optimization for you.
> Junio?
Probably something like this would suffice.
-- >8 --
Subject: rename detection with -M100 means "exact renames only".
When the user is interested in pure renames, there is no point
doing the similarity scores. This changes the score argument
parsing to special case -M100 (otherwise, it is a precision
scaled value 0 <= v < 1 and would mean 0.1, not 1.0 --- if you
do mean 0.1, you can say -M1), and optimizes the diffcore_rename
transformation to only look at pure renames in that case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/diff.c b/diff.c
index 0391e8c..0f839c1 100644
--- a/diff.c
+++ b/diff.c
@@ -853,6 +853,10 @@ static int parse_num(const char **cp_p)
}
*cp_p = cp;
+ /* special case: -M100 would mean 1.0 not 0.1 */
+ if (num == 100 && scale == 1000)
+ return MAX_SCORE;
+
/* user says num divided by scale and we say internally that
* is MAX_SCORE * num / scale.
*/
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 6a9d95d..dba965c 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -307,6 +307,9 @@ void diffcore_rename(struct diff_options
if (rename_count == rename_dst_nr)
goto cleanup;
+ if (minimum_score == MAX_SCORE)
+ goto cleanup;
+
num_create = (rename_dst_nr - rename_count);
num_src = rename_src_nr;
mx = xmalloc(sizeof(*mx) * num_create * num_src);
^ permalink raw reply related
* Re: auto-packing on kernel.org? please?
From: Junio C Hamano @ 2005-11-21 19:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511211110480.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Can anybody tell me how to do that sanely? Right now we do
>
> ..
> name=$(git-rev-list --objects $rev_list $(git-rev-parse $rev_parse) |
> git-pack-objects --non-empty $pack_objects .tmp-pack) ||
> exit 1
> ..
>
> and the thing is, the "git-pack-objects" thing is happy, it's the
> "git-rev-list" that fails. So because the last command in the pipeline
> returns ok, we think it all is ok..
One cop-out: do fsck-objects upfront before making a pack. This
would populate your buffer cache so it might not be a bad thing.
Alternatively:
name=$( {
git-rev-list --objects $rev_list $(git-rev-parse $rev_parse) ||
echo Gaaahhh
} | git-pack-objects --non-empty $pack_objects .tmp-pack)
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Franck @ 2005-11-21 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vzmo04dpl.fsf@assigned-by-dhcp.cox.net>
2005/11/19, Junio C Hamano <junkio@cox.net>:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > So "git repack" should _never_ call git-redundant-pack. It's always either
> > wrong or pointless.
>
> Right-o.
>
Ok, it works now. My new git repository is only 60Mo. But :), I would
like to make up my public repository based on this "light" repository.
And if someone has the big repository, I would like him to be able to
pull my public repo into his one. But since I used grafting to "cut"
my light repo and .git/info/grafts file is not copied during
push/pull/clone operations it's not going to work. Is it a scheme that
could work ?
Moreover, I'm wondering if my public repository really needs to store
big repo's pack files as it is described in git tutorial ?
Thanks
--
Franck
^ permalink raw reply
* Re: [RFC 1/2] Use remote information in .git/config
From: Johannes Schindelin @ 2005-11-21 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q65sst3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 21 Nov 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Note that there is only one pair per "pull" line, to allow for spaces
> > (urgh!) in the branch names.
>
> I think "allow for spaces" nonsense can be removed by now. I
> did it initially that way before making the ref name validation
> tighter with check-ref-format. And if I understand what you
> wrote about multivalues correctly, your intent is that "orders
> do not matter"; with pull refspecs, orders do matter, so it
> probably is a good idea to allow only a single line.
Okay. (I also wondered how git-config-set could be used to replace the
first pair, which is what gets merged when pulling).
> Personally I do not mind moving remotes/branches information
> there, except that I suspect the git-config-set interface makes
> it cumbersome to (1) find out what remotes I defined (i.e. an
> equivalent of "ls .git/remotes") and (2) remove a single remote
> when I do not want it anymore (--unset-all would remove the keys
> but would leave the empty section).
(1) git-var -l | grep '^remote\.'
(2) I would add --remove-section for that. (Though I'll wait to implement
that until I know if people want it.)
> I am unsure if putting everything in .git/config file is the
> right approach, though. What will we put there next? ls-files
> ignore patterns? grafts? alternates? We should be able to
> even get rid of .git/refs directory hierarchy and replace that
> with something like this:
>
> [refs]
> head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for master
> head = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for pu
> tag = ABCD1234ABCD1234ABCD1234ABCD1234ABCD1234 for v1.0rc1
> ...
>
> Where will we stop, and why?
Ahh! I have a clear picture of what *I* would put into it: all interesting
static data about that particular repository which I would not like to
version.
For that matter, .gitignore would stay where it is, though I'd also like
to version grafts, i.e. move the location from .git/info/grafts to
.gitgrafts (which would effectively end another thread on this list).
I would not like to version refs, evidently, or alternates. But the refs
would not be static (they *want* to change often), while the alterates
would be.
But I will not be a bugger about it. If things stay where they are
(including .git/remotes), I will not be sad. There was just this crazy
idea in my head (not the tip of the development branch, but the object my
eyes are in), and I wanted to discuss it with you guys, just in case...
Ciao,
Dscho
^ permalink raw reply
* Re: auto-packing on kernel.org? please?
From: Linus Torvalds @ 2005-11-21 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3blprcwk.fsf@assigned-by-dhcp.cox.net>
On Mon, 21 Nov 2005, Junio C Hamano wrote:
>
> One cop-out: do fsck-objects upfront before making a pack. This
> would populate your buffer cache so it might not be a bad thing.
Well, it's extremely expensive most of the time. It's often as expensive
as the packing itself. So I don't like that option very much.
> Alternatively:
>
> name=$( {
> git-rev-list --objects $rev_list $(git-rev-parse $rev_parse) ||
> echo Gaaahhh
> } | git-pack-objects --non-empty $pack_objects .tmp-pack)
Actually, some dim memories prodded me to some man-page digging, and the
"pipefail" option in particular.
It seems to be a common option to both ksh and bash, so
set -o pipefail
seems like it should fix this. Sadly, I think it's pretty recent in bash
(ksh apparently got it in -93, bash seems to have gotten it only as of
version 3.0, which is definitely recent enough that we can't just assume
it).
[ Also, bash seems to have a variable called $PIPESTATUS, but that's
bash-specific (I don't know when it was enabled). ]
Anyway, doing a
set -o pipefail
should never be the wrong thing to do, but the problem is figuring out
whether the option is available or not, since if it isn't available, it's
considered an error ;/
So with all that, how about we take your "Gaah" idea, and simplify it:
just pipe stderr too. That, together with making git-pack-objects tell
what garbage it got, actually does the rigth thing:
[torvalds@g5 git-clone]$ git repack -a -d
fatal: expected sha1, got garbage:
error: Could not read 7f59dbbb8f8d479c1d31453eac06ec765436a780
with this pretty simple patch.
Whaddaya think?
Linus
---
diff --git a/git-repack.sh b/git-repack.sh
index 4e16d34..c0f271d 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -41,7 +41,7 @@ esac
if [ "$local" ]; then
pack_objects="$pack_objects --local"
fi
-name=$(git-rev-list --objects $rev_list $(git-rev-parse $rev_parse) |
+name=$(git-rev-list --objects $rev_list $(git-rev-parse $rev_parse) 2>&1 |
git-pack-objects --non-empty $pack_objects .tmp-pack) ||
exit 1
if [ -z "$name" ]; then
diff --git a/pack-objects.c b/pack-objects.c
index 4e941e7..8864a31 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -524,7 +524,7 @@ int main(int argc, char **argv)
unsigned char sha1[20];
if (get_sha1_hex(line, sha1))
- die("expected sha1, got garbage");
+ die("expected sha1, got garbage:\n %s", line);
hash = 0;
p = line+40;
while (*p) {
^ permalink raw reply related
* Re: [QUESTION] Access to a huge GIT repository.
From: Junio C Hamano @ 2005-11-21 20:45 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <cda58cb80511211211l2ff6ff12j@mail.gmail.com>
Franck <vagabon.xyz@gmail.com> writes:
> ... But since I used grafting to "cut"
> my light repo and .git/info/grafts file is not copied during
> push/pull/clone operations it's not going to work. Is it a scheme that
> could work ?
If you tell your downloaders that your repository is incomplete
and they need to have at least up to such and such commits from
another repository, they should be able to slurp from you.
It might be possible to teach upload-pack (that is run when your
downloaders run git-fetch or git-clone against your repository)
to somehow send a customized error message to the client when it
finds the other end needs certain objects that you yourself do
not even have. In that message you could say something like "due
to space constraints this repository is an incomplete one, and
you can only use it on top of a clone of such and such
repository, found at this URL: ...".
> Moreover, I'm wondering if my public repository really needs to store
> big repo's pack files as it is described in git tutorial ?
Copying is one way, but if the repository you are borrowing from
lives on the same machine, you could use objects/info/alternates
to point at it from your public repository. In either case, the
point in that section is to reduce the need to transfer and
expand much stuff in your public repository while keeping the
repository complete. The recommended procedure in the tutorial
always assumes that the public repository is kept fsck-objects
clean and complete.
What you are trying to do is to keep your public repository
fsck-objects *un*clean and still let downloaders work with it;
so I suspect following that section of the tutorial procedure
defeats the purpose your experiments.
^ permalink raw reply
* [RFC] Make grafts versionable
From: Johannes Schindelin @ 2005-11-21 20:54 UTC (permalink / raw)
To: git
... by moving the location from .git/info/grafts to .gitgrafts. This
allows checking it in like .gitignore, and sure enough also pulling it (as
well as knowing who the heck added that particular graft anyway).
Totally untested.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This would make half the discussion about rewriting history
obsolete, methinks.
Of course, to take advantage of it, you have to move the file
.git/info/grafts (if it exists) into the correct place yourself:
mv -i .git/info/grafts .gitgrafts
environment.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 20259f7c4418392e0e0c2f3a867811f657498afe
a1756142e3be780ed7992cd6a3f5e64b53c42253
diff --git a/environment.c b/environment.c
index b5026f1..b0c2f79 100644
--- a/environment.c
+++ b/environment.c
@@ -35,7 +35,7 @@ static void setup_git_env(void)
}
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
- git_graft_file = strdup(git_path("info/grafts"));
+ git_graft_file = strdup(git_path("../.gitgrafts"));
}
char *get_git_dir(void)
---
0.99.9.GIT
^ permalink raw reply related
* Re: Pure renames/copies
From: H. Peter Anvin @ 2005-11-21 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vacfxrdao.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>
>>Of course, arguably "-M100" should really do this optimization for you.
>>Junio?
>
>
> Probably something like this would suffice.
>
> -- >8 --
> Subject: rename detection with -M100 means "exact renames only".
>
> When the user is interested in pure renames, there is no point
> doing the similarity scores. This changes the score argument
> parsing to special case -M100 (otherwise, it is a precision
> scaled value 0 <= v < 1 and would mean 0.1, not 1.0 --- if you
> do mean 0.1, you can say -M1), and optimizes the diffcore_rename
> transformation to only look at pure renames in that case.
>
Any reason we can't make it take an actual decimal number, like -M1.0 or
-M0.345? It seems odd and annoying to invent our own notation for
floating-point numbers, especially in userspace.
-hpa
^ permalink raw reply
* Re: [RFC] Make grafts versionable
From: H. Peter Anvin @ 2005-11-21 21:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511212152110.4611@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> ... by moving the location from .git/info/grafts to .gitgrafts. This
> allows checking it in like .gitignore, and sure enough also pulling it (as
> well as knowing who the heck added that particular graft anyway).
This is problematic, because it means something that isn't in GIT_DIR
affects its interpretation. I would say that that is a showstopper.
One could even argue that it's incorrect, since it would mean different
points on the history have different grafts.
Now, CVS has a reserved namespace (CVSROOT/) for things under version
control which are still significant to CVS. The logical equivalent to
git would be to have .git/ be such a namespace, if it makes sense.
-hpa
^ 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