* Re: [PATCH] fetch-pack: start multi-head pulling.
From: Matthias Urlichs @ 2005-08-13 3:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vk6irumv3.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> I have been trying, admittably perhaps not very successfully, to
> stay away from bashism in the core GIT scripts.
We should probably use #!/bin/bash for scripts with bashisms...
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
He has more goodness in his little finger Than you have in your whole
body.
-- Jonathan Swift
^ permalink raw reply
* Re: Cloning speed comparison
From: Linus Torvalds @ 2005-08-13 3:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, ftpadmin
In-Reply-To: <20050813031025.GE20812@pasky.ji.cz>
On Sat, 13 Aug 2005, Petr Baudis wrote:
>
> Oh. Sounds nice, are there plans to run this on kernel.org too? (So far,
> 90% of my GIT network activity happens with kernel.org; the rest is with
> my notebook, and I want to keep that ssh.)
Maybe. I don't know what the status of that is, but the plan was to at
least give it a try.
> BTW, is the pack protocol flexible enough to be extended to support
> pushing?
The _protocol_ could handle it, but you obviously need some kind of secure
authentication, and quite frankly, one of the selling points on git-daemon
right now is that it's all read-only and very simple and there should be
no security issues because it will never write anything at all.
So right now git-daemon only accepts requests from fetch-pack.
> > [ Hey. There's a deer outside my window eating our roses again. Cute ]
>
> Oh, it must be nice in Oregon. I can't imagine anything like that to
> happen in Czechia unless you live at a solitude or in some lonely tiny
> village.
Deer are really just oversized rats with horns (*). They're cute, though,
and it's kind of funny looking up from the screen and noticing one
munching on the roses just ten feet away.
Linus
(*) Did I mention that biology wasn't one of the things I did at Uni?
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Carl Baldwin @ 2005-08-13 4:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050729081051.GH24895@pasky.ji.cz>
On Fri, Jul 29, 2005 at 08:10:51AM +0000, Petr Baudis wrote:
> Exactly. I want much more freedom in pushing, the only requirement being
> that "the to-be-replaced remote head is ancestor of the to-be-pushed
> local head". I think (am I wrong?) git-send-pack localhead:remotehead
> would work just fine for me, the only thing I need is the support for
> different local and remote head names.
Greetings,
Sorry to join the game so late. I've only read this thread now.
It seems to me that this is the way to go. Several have mentioned that
head names should be the same on the remote and the local side.
However, I wanted to point out that it may be impossible to keep these
names in sync due to the 'loosely knit' nature of the types of projects
that are likely to use git.
It seems that the requirement that the remote head be a strict ancestor
of the local head is actually quite strong and should avoid mistakes
like pushing to the wrong head.
Anyway, those are my two cents. I couldn't tell wether a resolution had
been achieved so I thought I would pipe up.
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: gitweb - feature request
From: Matthias Urlichs @ 2005-08-13 4:13 UTC (permalink / raw)
To: git
In-Reply-To: <20050812211600.GA61428@gaz.sfgoth.com>
Hi, Mitchell Blank Jr wrote:
> Is it really hard to just make it purely time-based (git-rev-list
> --max-age)? Think of if Linus is merging with a lot of people and then
> pushes the results to the master repository -- suddenly there's, say,
> 400 new commits since the last time my aggregator checked 2 hours ago.
Think of Linus merging a bunch of trees with 1-month old commits, all of
which you'd miss that way.
IMHO, you definitely need a static file for RSS -- do a git-rev-list
between HEAD and HEAD-as-of-the-last-time-you-generated-the-RSS,
concatenate with the old RSS, then trim appropriately.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
You judge the acts of others only by their intentions.
^ permalink raw reply
* Fwd: Re: git checkout -f branch doesn't remove extra files
From: Dave Jones @ 2005-08-13 4:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 65 bytes --]
Gar, got caught by the 'reply-to' going to Tony only...
Dave
[-- Attachment #2: Type: message/rfc822, Size: 1308 bytes --]
From: Dave Jones <davej@redhat.com>
To: "Luck, Tony" <tony.luck@intel.com>
Subject: Re: git checkout -f branch doesn't remove extra files
Date: Sat, 13 Aug 2005 00:16:13 -0400
Message-ID: <20050813041613.GA25236@redhat.com>
On Fri, Aug 12, 2005 at 10:31:17AM -0700, Luck, Tony wrote:
> I've just got around to noticing some of the new (to
> me) features in git, and started experimenting with
> branches.
Seems a good day to learn new features, I was completely
unaware of git-ls-files somehow.
My git snapshot creator that builds the hourly tarballs at
http://www.codemonkey.org.uk/projects/git-snapshots/
currently does an rsync, and then a checkout, and finally
it cleans up by removing all the checked out files.
It currently does this by hand, but on learning about
this 'new' command, I thought, cool, now I can do..
git-ls-files | xargs rm -rf
however, this then leaves a bunch of empty subdirs, as
git-ls-files doesn't list the subdirs by themselves in
the output. Am I missing some other option ?
Dave
^ permalink raw reply
* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Linus Torvalds @ 2005-08-13 5:05 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20050813041737.GB25236@redhat.com>
On Sat, 13 Aug 2005, Dave Jones wrote:
>
> My git snapshot creator that builds the hourly tarballs at
> http://www.codemonkey.org.uk/projects/git-snapshots/
> currently does an rsync, and then a checkout, and finally
> it cleans up by removing all the checked out files.
> It currently does this by hand, but on learning about
> this 'new' command, I thought, cool, now I can do..
>
> git-ls-files | xargs rm -rf
>
> however, this then leaves a bunch of empty subdirs, as
> git-ls-files doesn't list the subdirs by themselves in
> the output. Am I missing some other option ?
Nope, you're not missing anything, except that you shouldn't do that.
"git-ls-files" is very nice for things like
git-ls-files | xargs grep ....
but your example is not one of them. Not without options, and not _with_
strange options.
Your example is an example of just not doing it the right way.
If you really want a temporary tree, what you do is something like
git-checkout-cache --prefix=tmp-dir/ -f -a
and when you're done, you just do
rm -rf tmp-dir
and you're done.
NOTE NOTE NOTE! In the above, the order of the parameters is really really
important! "-a" takes effect when it is seen, so it needs to be last.
Also, the "--prefix" thing really _really_ needs the slash at the end,
because it's literally used to prefix the pathname.
HOWEVER, if all you want to do is just a tar-file, then there's a better
solution. It's called
snap=git-snapshot-$(date +"%Y%m%d")
git-tar-tree HEAD $snap | gzip -9 > $snap.tar.gz
which is even easier, and a hell of a lot more efficient.
Git actually has a _lot_ of nifty tools. I didn't realize that people
didn't know about such basic stuff as "git-tar-tree" and "git-ls-files".
Linus
^ permalink raw reply
* Re: Cloning speed comparison
From: H. Peter Anvin @ 2005-08-13 5:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git, ftpadmin
In-Reply-To: <20050813031025.GE20812@pasky.ji.cz>
Petr Baudis wrote:
>>>
>>In my tests, the git daemon was noticeably faster than ssh, if only
>>because the authentication actually tends to be a big part of the overhead
>>in small pulls.
>
> Oh. Sounds nice, are there plans to run this on kernel.org too? (So far,
> 90% of my GIT network activity happens with kernel.org; the rest is with
> my notebook, and I want to keep that ssh.)
>
Yes, when I get some time...
-hpa
^ permalink raw reply
* Re: Cloning speed comparison
From: H. Peter Anvin @ 2005-08-13 5:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git, ftpadmin
In-Reply-To: <Pine.LNX.4.58.0508122021490.19049@g5.osdl.org>
Linus Torvalds wrote:
>
>>BTW, is the pack protocol flexible enough to be extended to support
>>pushing?
>
> The _protocol_ could handle it, but you obviously need some kind of secure
> authentication, and quite frankly, one of the selling points on git-daemon
> right now is that it's all read-only and very simple and there should be
> no security issues because it will never write anything at all.
>
Running it over ssh would be a good way to do authentication...
-hpa
^ permalink raw reply
* Re: Cloning speed comparison
From: Linus Torvalds @ 2005-08-13 5:25 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Petr Baudis, git, ftpadmin
In-Reply-To: <42FD8224.9020700@zytor.com>
On Fri, 12 Aug 2005, H. Peter Anvin wrote:
>
> Running it over ssh would be a good way to do authentication...
Well, if you have ssh as an option, you don't need git-daemon any more,
since the protocol that git-daemon does runs quite well over ssh on its
own...
The only point of git-daemon really is when you don't have ssh access (ie
you may want to give people a limited interface, but not full ssh). Ie
as-is, it's only for anonymous reads of a git archive, but it obviously
_could_ do more.
Linus
^ permalink raw reply
* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Dave Jones @ 2005-08-13 5:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508122151120.19049@g5.osdl.org>
On Fri, Aug 12, 2005 at 10:05:11PM -0700, Linus Torvalds wrote:
> HOWEVER, if all you want to do is just a tar-file, then there's a better
> solution. It's called
>
> snap=git-snapshot-$(date +"%Y%m%d")
> git-tar-tree HEAD $snap | gzip -9 > $snap.tar.gz
>
> which is even easier, and a hell of a lot more efficient.
Nice. That takes noticably less time to create the sparse/git snapshots
compared to my crappy old script. And its now less than half the size.
I'm sold.
> Git actually has a _lot_ of nifty tools. I didn't realize that people
> didn't know about such basic stuff as "git-tar-tree" and "git-ls-files".
Maybe its because things are moving so fast :) Or maybe I just wasn't
paying attention on that day. (I even read the git changes via RSS,
so I should have no excuse).
Dave
^ permalink raw reply
* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Linus Torvalds @ 2005-08-13 5:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508122151120.19049@g5.osdl.org>
On Fri, 12 Aug 2005, Linus Torvalds wrote:
>
> Git actually has a _lot_ of nifty tools. I didn't realize that people
> didn't know about such basic stuff as "git-tar-tree" and "git-ls-files".
Btw, I just checked that git-tar-tree is documented and has a man-page. It
does. However, that man-page attributes authorship to me, which is wrong.
git-tar-tree was written by Rene Scharfe <rene.scharfe@lsrfire.ath.cx>.
Don't know how many other man-pages say I wrote something just because
people copied another man-page around. Worth fixing, though.
Linus
^ permalink raw reply
* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Linus Torvalds @ 2005-08-13 5:39 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20050813052731.GC11456@redhat.com>
On Sat, 13 Aug 2005, Dave Jones wrote:
>
> > Git actually has a _lot_ of nifty tools. I didn't realize that people
> > didn't know about such basic stuff as "git-tar-tree" and "git-ls-files".
>
> Maybe its because things are moving so fast :) Or maybe I just wasn't
> paying attention on that day. (I even read the git changes via RSS,
> so I should have no excuse).
Well, git-tar-tree has been there since late April - it's actually one of
those really early commands. I'm pretty sure the RSS feed came later ;)
I use it all the time in doing releases, it's a lot faster than creating a
tar tree by reading the filesystem (even if you don't have to check things
out). A hidden pearl.
This is my crappy "release-script":
[torvalds@g5 ~]$ cat bin/release-script
#!/bin/sh
stable="$1"
last="$2"
new="$3"
echo "# git-tag-script v$new"
echo "git-tar-tree v$new linux-$new | gzip -9 > ../linux-$new.tar.gz"
echo "git-diff-tree -p v$stable v$new | gzip -9 > ../patch-$new.gz"
echo "git-rev-list --pretty v$new ^v$last > ../ChangeLog-$new"
echo "git-rev-list --pretty=short v$new ^v$last | git-shortlog > ../ShortLog"
echo "git-diff-tree -p v$last v$new | git-apply --stat > ../diffstat-$new"
and when I want to do a new kernel release I literally first tag it, and
then do
release-script 2.6.12 2.6.13-rc6 2.6.13-rc7
and check that things look sane, and then just cut-and-paste the commands.
Yeah, it's stupid.
Linus
^ permalink raw reply
* git/cogito workshop/bof at linuxconf au?
From: Martin Langhoff @ 2005-08-13 7:34 UTC (permalink / raw)
To: GIT
Anyone coming to Linuxconf.au 2006? It'll will be in Dunedin NZ and
I'd be really keen on joining a git/cogito workshop or bof.
I would gladly try and organize a workshop, but I am far from fluent
with git, so I won't go at it alone. Any takers? Call for papers ends
5th September, not too far ahead. We have to register our interest
_now_.
cheers,
martin
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-08-13 7:48 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050813041114.GA29412@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> On Fri, Jul 29, 2005 at 08:10:51AM +0000, Petr Baudis wrote:
>> Exactly. I want much more freedom in pushing, the only requirement being
>> that "the to-be-replaced remote head is ancestor of the to-be-pushed
>> local head". I think (am I wrong?) git-send-pack localhead:remotehead
>> would work just fine for me, the only thing I need is the support for
>> different local and remote head names.
>
> Sorry to join the game so late. I've only read this thread now.
Just in case you have not noticed, the push in 0.99.4 and
onwards does exactly that. Please see git-push-script.txt in
the Documentation/ directory --- oops, there is no such thing.
Please see git-send-pack.txt instead, and if you feel like it, I
would appreciate a patch to add the missing documentation for
git-push-script ;-).
What's not supported well yet is the opposite --- downloading
multiple refs and dealing with them.
Johannes Schindelin calls this "reverse push", and I think that
is really a good name to describe what it does. It takes a
remote repository and possibly multiple refs, downloads the
objects to complete the named remote references, and updates the
local refs only if the remote refs are fast forward children of
the local refs being replaced, just like "push" fast forwards
the remote refs using the local refs. In other words, given
<src> and <dst> repository, the following should do the same
thing:
On <src> repository machine, with GIT_DIR being the <src> repository:
$ git push <dst> <ref-local-name>:<ref-remote-name>...
On <dst> repository machine, with GIT_DIR being the <dst> repository:
$ git pull <src> <ref-remote-name>:<ref-local-name>...
Johannes posted a script on the list a couple of days ago, which
should work well, except that it was written before the
git-fetch-pack command was updated to natively download from
multiple refs, so it does not know how to fetch multiple refs at
a one go.
-jc
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Junio C Hamano @ 2005-08-13 8:57 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Linus Torvalds, Johannes Schindelin, git
In-Reply-To: <20050812222716.GD22778@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> See, for example, the history on git-rename-script for why this is good.
Why do you think it is a good example? What happens when next
time somebody rewrites it in C?
^ permalink raw reply
* [PATCH] Add --signoff and --verify option to git commit.
From: Junio C Hamano @ 2005-08-13 9:08 UTC (permalink / raw)
To: git
As brought up in the discussion which followed a patch to add a
signed-off-by line with the --sign flag to format-patch from
Johannes Schindelin, add --signoff to the git commit command.
Also add --verify to make sure the lines you introduced are
clean, which is more useful in commit but not very much in
format-patch as it was originally implemented, because finding
botches at format-patch time is too late.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-commit-script | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 72 insertions(+), 4 deletions(-)
2f1c5b4fa572886646d9993129f7cd0a61fe4190
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -9,7 +9,7 @@ usage () {
die 'git commit [-a] [-m <message>] [-F <logfile>] [(-C|-c) <commit>] [<path>...]'
}
-all= logfile= use_commit= no_edit= log_given= log_message=
+all= logfile= use_commit= no_edit= log_given= log_message= verify= signoff=
while case "$#" in 0) break;; esac
do
case "$1" in
@@ -64,6 +64,12 @@ do
use_commit="$1"
no_edit=t
shift ;;
+ -s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
+ signoff=t
+ shift ;;
+ -v|--v|--ve|--ver|--veri|--verif|--verify)
+ verify=t
+ shift ;;
--)
shift
break ;;
@@ -86,6 +92,60 @@ t)
esac
git-update-cache -q --refresh -- "$@" || exit 1
+case "$verify" in
+t)
+ # This is slightly modified from Andrew Morton's Perfect Patch.
+ # Lines you introduce should not have trailing whitespace.
+ # Also check for an indentation that has SP before a TAB.
+ perl -e '
+ my $fh;
+ my $found_bad = 0;
+ my $filename;
+ my $reported_filename = "";
+ my $lineno;
+ sub bad_line {
+ my ($why, $line) = @_;
+ if (!$found_bad) {
+ print "*\n";
+ print "* You have some suspicious patch lines:\n";
+ print "*\n";
+ $found_bad = 1;
+ }
+ if ($reported_filename ne $filename) {
+ print "* In $filename\n";
+ $reported_filename = $filename;
+ }
+ print "* $why (line $lineno)\n$line\n";
+ }
+ open $fh, "-|", qw(git-diff-cache -p -M --cached HEAD);
+ while (<$fh>) {
+ if (m|^diff --git a/(.*) b/\1$|) {
+ $filename = $1;
+ next;
+ }
+ if (/^@@ -\S+ \+(\d+)/) {
+ $lineno = $1 - 1;
+ next;
+ }
+ if (/^ /) {
+ $lineno++;
+ next;
+ }
+ if (s/^\+//) {
+ $lineno++;
+ chomp;
+ if (/\s$/) {
+ bad_line("trailing whitespace", $_);
+ }
+ if (/^\s* /) {
+ bad_line("indent SP followed by a TAB", $_);
+ }
+ }
+ }
+ exit($found_bad);
+ ' || exit ;;
+esac
+
PARENTS="-p HEAD"
if [ ! -r "$GIT_DIR/HEAD" ]; then
if [ -z "$(git-ls-files)" ]; then
@@ -161,7 +221,14 @@ else
export GIT_AUTHOR_DATE
git-cat-file commit "$use_commit" |
sed -e '1,/^$/d'
- fi >.editmsg
+ fi |
+ git-stripspace >.editmsg
+ case "$signoff" in
+ t)
+ git-var GIT_COMMITTER_IDENT | sed -e '
+ s/>.*/>/
+ s/^/Signed-off-by: /' >>.editmsg ;;
+ esac
git-status-script >>.editmsg
fi
if [ "$?" != "0" -a ! -f $GIT_DIR/MERGE_HEAD ]
@@ -176,7 +243,8 @@ case "$no_edit" in
;;
esac
grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
-if test -s .cmitmsg
+grep -v -i '^Signed-off-by' .cmitmsg >.cmitchk
+if test -s .cmitchk
then
tree=$(git-write-tree) &&
commit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&
@@ -187,5 +255,5 @@ else
false
fi
ret="$?"
-rm -f .cmitmsg .editmsg
+rm -f .cmitmsg .editmsg .cmitchk
exit "$ret"
^ permalink raw reply
* [PATCH] Add SubmittingPatches
From: Junio C Hamano @ 2005-08-13 9:08 UTC (permalink / raw)
To: git
Not that I have stricter patch submission standards than ordinary
projects, I wanted to have it to make sure people understand
what they are doing when they add their own Signed-off-by line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/SubmittingPatches | 130 +++++++++++++++++++++++++++++++++++++++
1 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 Documentation/SubmittingPatches
3de1a21da62e2ad89bfb25f742384b9af496e4e0
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
new file mode 100644
--- /dev/null
+++ b/Documentation/SubmittingPatches
@@ -0,0 +1,130 @@
+I started reading over the SubmittingPatches document for Linux
+kernel, primarily because I wanted to have a document similar to
+it for the core GIT to make sure people understand what they are
+doing when they write "Signed-off-by" line.
+
+But the patch submission requirements are a lot more relaxed
+here, because the core GIT is thousand times smaller ;-). So
+here is only the relevant bits.
+
+
+(1) Make separate commits for logically separate changes.
+
+Unless your patch is really trivial, you should not be sending
+out a patch that was generated between your working tree and
+your commit head. Instead, always make a commit with complete
+commit message and generate a series of patches from your
+repository. It is a good discipline.
+
+Describe the technical detail of the change(s).
+
+If your description starts to get long, that's a sign that you
+probably need to split up your commit to finer grained pieces.
+
+
+(2) Generate your patch using git/cogito out of your commits.
+
+git diff tools generate unidiff which is the preferred format.
+You do not have to be afraid to use -M option to "git diff" or
+"git format-patch", if your patch involves file renames. The
+receiving end can handle them just fine.
+
+Please make sure your patch does not include any extra files
+which do not belong in a patch submission. Make sure to review
+your patch after generating it, to ensure accuracy. Before
+sending out, please make sure it cleanly applies to the "master"
+branch head.
+
+
+(3) Sending your patches.
+
+People on the git mailing list needs to be able to read and
+comment on the changes you are submitting. It is important for
+a developer to be able to "quote" your changes, using standard
+e-mail tools, so that they may comment on specific portions of
+your code. For this reason, all patches should be submitting
+e-mail "inline". WARNING: Be wary of your MUAs word-wrap
+corrupting your patch. Do not cut-n-paste your patch.
+
+It is common convention to prefix your subject line with
+[PATCH]. This lets people easily distinguish patches from other
+e-mail discussions.
+
+"git format-patch" command follows the best current practice to
+format the body of an e-mail message. At the beginning of the
+patch should come your commit message, ending with the
+Signed-off-by: lines, and a line that consists of three dashes,
+followed by the diffstat information and the patch itself. If
+you are forwarding a patch from somebody else, optionally, at
+the beginning of the e-mail message just before the commit
+message starts, you can put a "From: " line to name that person.
+
+You often want to add additional explanation about the patch,
+other than the commit message itself. Place such "cover letter"
+material between the three dash lines and the diffstat.
+
+Do not attach the patch as a MIME attachment, compressed or not.
+Do not let your e-mail client send quoted-printable. Many
+popular e-mail applications will not always transmit a MIME
+attachment as plain text, making it impossible to comment on
+your code. A MIME attachment also takes a bit more time to
+process. This does not decrease the likelihood of your
+MIME-attached change being accepted, but it makes it more likely
+that it will be postponed.
+
+Exception: If your mailer is mangling patches then someone may ask
+you to re-send them using MIME.
+
+Note that your maintainer does not subscribe to the git mailing
+list (he reads it via mail-to-news gateway). If your patch is
+for discussion first, send it "To:" the mailing list, and
+optoinally "cc:" him. If it is trivially correct or after list
+discussion reached consensus, send it "To:" the maintainer and
+optionally "cc:" the list.
+
+
+(6) Sign your work
+
+To improve tracking of who did what, we've borrowed the
+"sign-off" procedure from the Linux kernel project on patches
+that are being emailed around. Although core GIT is a lot
+smaller project it is a good discipline to follow it.
+
+The sign-off is a simple line at the end of the explanation for
+the patch, which certifies that you wrote it or otherwise have
+the right to pass it on as a open-source patch. The rules are
+pretty simple: if you can certify the below:
+
+ Developer's Certificate of Origin 1.1
+
+ By making a contribution to this project, I certify that:
+
+ (a) The contribution was created in whole or in part by me and I
+ have the right to submit it under the open source license
+ indicated in the file; or
+
+ (b) The contribution is based upon previous work that, to the best
+ of my knowledge, is covered under an appropriate open source
+ license and I have the right under that license to submit that
+ work with modifications, whether created in whole or in part
+ by me, under the same open source license (unless I am
+ permitted to submit under a different license), as indicated
+ in the file; or
+
+ (c) The contribution was provided directly to me by some other
+ person who certified (a), (b) or (c) and I have not modified
+ it.
+
+ (d) I understand and agree that this project and the contribution
+ are public and that a record of the contribution (including all
+ personal information I submit with it, including my sign-off) is
+ maintained indefinitely and may be redistributed consistent with
+ this project or the open source license(s) involved.
+
+then you just add a line saying
+
+ Signed-off-by: Random J Developer <random@developer.example.org>
+
+Some people also put extra tags at the end. They'll just be ignored for
+now, but you can do this to mark internal company procedures or just
+point out some special detail about the sign-off.
^ permalink raw reply
* [PATCH] Alternate object pool mechanism updates.
From: Junio C Hamano @ 2005-08-13 9:09 UTC (permalink / raw)
To: git
It was a mistake to use GIT_ALTERNATE_OBJECT_DIRECTORIES
environment variable to specify what alternate object pools to
look for missing objects when working with an object database.
It is not a property of the process running the git commands,
but a property of the object database that is partial and needs
other object pools to complete the set of objects it lacks.
This patch allows you to have $GIT_OBJECT_DIRECTORY/info/alt
file whose contents is in exactly the same format as the
environment variable, to let an object database name alternate
object pools it depends on.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cache.h | 5 +-
fsck-cache.c | 8 ++-
sha1_file.c | 146 ++++++++++++++++++++++++++++++++--------------------------
3 files changed, 88 insertions(+), 71 deletions(-)
8150a422f79cc461316052b52263289b851d4820
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -278,9 +278,10 @@ struct checkout {
extern int checkout_entry(struct cache_entry *ce, struct checkout *state);
extern struct alternate_object_database {
- char *base;
+ struct alternate_object_database *next;
char *name;
-} *alt_odb;
+ char base[0]; /* more */
+} *alt_odb_list;
extern void prepare_alt_odb(void);
extern struct packed_git {
diff --git a/fsck-cache.c b/fsck-cache.c
--- a/fsck-cache.c
+++ b/fsck-cache.c
@@ -456,13 +456,13 @@ int main(int argc, char **argv)
fsck_head_link();
fsck_object_dir(get_object_directory());
if (check_full) {
- int j;
+ struct alternate_object_database *alt;
struct packed_git *p;
prepare_alt_odb();
- for (j = 0; alt_odb[j].base; j++) {
+ for (alt = alt_odb_list; alt; alt = alt->next) {
char namebuf[PATH_MAX];
- int namelen = alt_odb[j].name - alt_odb[j].base;
- memcpy(namebuf, alt_odb[j].base, namelen);
+ int namelen = alt->name - alt->base;
+ memcpy(namebuf, alt->base, namelen);
namebuf[namelen - 1] = 0;
fsck_object_dir(namebuf);
}
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -222,84 +222,100 @@ char *sha1_pack_index_name(const unsigne
return base;
}
-struct alternate_object_database *alt_odb;
+struct alternate_object_database *alt_odb_list;
+static struct alternate_object_database **alt_odb_tail;
/*
* Prepare alternate object database registry.
- * alt_odb points at an array of struct alternate_object_database.
- * This array is terminated with an element that has both its base
- * and name set to NULL. alt_odb[n] comes from n'th non-empty
- * element from colon separated ALTERNATE_DB_ENVIRONMENT environment
- * variable, and its base points at a statically allocated buffer
- * that contains "/the/directory/corresponding/to/.git/objects/...",
- * while its name points just after the slash at the end of
- * ".git/objects/" in the example above, and has enough space to hold
- * 40-byte hex SHA1, an extra slash for the first level indirection,
- * and the terminating NUL.
- * This function allocates the alt_odb array and all the strings
- * pointed by base fields of the array elements with one xmalloc();
- * the string pool immediately follows the array.
+ *
+ * The variable alt_odb_list points at the list of struct
+ * alternate_object_database. The elements on this list come from
+ * non-empty elements from colon separated ALTERNATE_DB_ENVIRONMENT
+ * environment variable, and $GIT_OBJECT_DIRECTORY/info/alt file,
+ * whose contents is exactly in the same format as that environment
+ * variable. Its base points at a statically allocated buffer that
+ * contains "/the/directory/corresponding/to/.git/objects/...", while
+ * its name points just after the slash at the end of ".git/objects/"
+ * in the example above, and has enough space to hold 40-byte hex
+ * SHA1, an extra slash for the first level indirection, and the
+ * terminating NUL.
*/
-void prepare_alt_odb(void)
+static void link_alt_odb_entries(const char *alt, const char *ep)
{
- int pass, totlen, i;
const char *cp, *last;
- char *op = NULL;
- const char *alt = gitenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
+ struct alternate_object_database *ent;
+
+ last = alt;
+ do {
+ for (cp = last; cp < ep && *cp != ':'; cp++)
+ ;
+ if (last != cp) {
+ /* 43 = 40-byte + 2 '/' + terminating NUL */
+ int pfxlen = cp - last;
+ int entlen = pfxlen + 43;
+
+ ent = xmalloc(sizeof(*ent) + entlen);
+ *alt_odb_tail = ent;
+ alt_odb_tail = &(ent->next);
+ ent->next = NULL;
+
+ memcpy(ent->base, last, pfxlen);
+ ent->name = ent->base + pfxlen + 1;
+ ent->base[pfxlen] = ent->base[pfxlen + 3] = '/';
+ ent->base[entlen-1] = 0;
+ }
+ while (cp < ep && *cp == ':')
+ cp++;
+ last = cp;
+ } while (cp < ep);
+}
+
+void prepare_alt_odb(void)
+{
+ char path[PATH_MAX];
+ char *map, *ep;
+ int fd;
+ struct stat st;
+ char *alt = gitenv(ALTERNATE_DB_ENVIRONMENT) ? : "";
- if (alt_odb)
+ sprintf(path, "%s/info/alt", get_object_directory());
+ if (alt_odb_tail)
+ return;
+ alt_odb_tail = &alt_odb_list;
+ link_alt_odb_entries(alt, alt + strlen(alt));
+
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ return;
+ if (fstat(fd, &st) || (st.st_size == 0)) {
+ close(fd);
return;
- /* The first pass counts how large an area to allocate to
- * hold the entire alt_odb structure, including array of
- * structs and path buffers for them. The second pass fills
- * the structure and prepares the path buffers for use by
- * fill_sha1_path().
- */
- for (totlen = pass = 0; pass < 2; pass++) {
- last = alt;
- i = 0;
- do {
- cp = strchr(last, ':') ? : last + strlen(last);
- if (last != cp) {
- /* 43 = 40-byte + 2 '/' + terminating NUL */
- int pfxlen = cp - last;
- int entlen = pfxlen + 43;
- if (pass == 0)
- totlen += entlen;
- else {
- alt_odb[i].base = op;
- alt_odb[i].name = op + pfxlen + 1;
- memcpy(op, last, pfxlen);
- op[pfxlen] = op[pfxlen + 3] = '/';
- op[entlen-1] = 0;
- op += entlen;
- }
- i++;
- }
- while (*cp && *cp == ':')
- cp++;
- last = cp;
- } while (*cp);
- if (pass)
- break;
- alt_odb = xmalloc(sizeof(*alt_odb) * (i + 1) + totlen);
- alt_odb[i].base = alt_odb[i].name = NULL;
- op = (char*)(&alt_odb[i+1]);
}
+ map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ close(fd);
+ if (map == MAP_FAILED)
+ return;
+
+ /* Remove the trailing newline */
+ for (ep = map + st.st_size - 1; map < ep && ep[-1] == '\n'; ep--)
+ ;
+ link_alt_odb_entries(map, ep);
+ munmap(map, st.st_size);
}
static char *find_sha1_file(const unsigned char *sha1, struct stat *st)
{
- int i;
char *name = sha1_file_name(sha1);
+ struct alternate_object_database *alt;
if (!stat(name, st))
return name;
prepare_alt_odb();
- for (i = 0; (name = alt_odb[i].name) != NULL; i++) {
+ for (alt = alt_odb_list; alt; alt = alt->next) {
+ name = alt->name;
fill_sha1_path(name, sha1);
- if (!stat(alt_odb[i].base, st))
- return alt_odb[i].base;
+ if (!stat(alt->base, st))
+ return alt->base;
}
return NULL;
}
@@ -522,18 +538,18 @@ static void prepare_packed_git_one(char
void prepare_packed_git(void)
{
- int i;
static int run_once = 0;
+ struct alternate_object_database *alt;
- if (run_once++)
+ if (run_once)
return;
-
prepare_packed_git_one(get_object_directory());
prepare_alt_odb();
- for (i = 0; alt_odb[i].base != NULL; i++) {
- alt_odb[i].name[0] = 0;
- prepare_packed_git_one(alt_odb[i].base);
+ for (alt = alt_odb_list; alt; alt = alt->next) {
+ alt->name[0] = 0;
+ prepare_packed_git_one(alt->base);
}
+ run_once = 1;
}
int check_sha1_signature(const unsigned char *sha1, void *map, unsigned long size, const char *type)
^ permalink raw reply
* Re: [PATCH] fetch-pack: start multi-head pulling.
From: Junio C Hamano @ 2005-08-13 9:09 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.08.13.03.25.28.489523@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
>> I have been trying, admittably perhaps not very successfully, to
>> stay away from bashism in the core GIT scripts.
>
> We should probably use #!/bin/bash for scripts with bashisms...
As a fall-back position, yes, but I'd rather see trivial
bashisms eradicated when the rewrite does not make things too
complicated.
^ permalink raw reply
* [PATCH] fix null TZ problems on os/x
From: Brad Roberts @ 2005-08-13 10:22 UTC (permalink / raw)
To: git
[PATCH] Fix TZ handling in tests, "" isn't a valid timezone at least on os/x
It seems that the localtime() libc routine doesn't care for finding a TZ
that's empty. It's ok with TZ not being set. Setting the TZ to GMT allowed
these tests to pass.
$ uname -v
Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC
Signed-off-by: Brad Roberts <braddr@puremagic.com>
---
diff --git a/t/t1100-commit-tree-options.sh b/t/t1100-commit-tree-options.sh
--- a/t/t1100-commit-tree-options.sh
+++ b/t/t1100-commit-tree-options.sh
@@ -32,7 +32,7 @@ test_expect_success \
GIT_COMMITTER_NAME="Committer Name" \
GIT_COMMITTER_EMAIL="committer@email" \
GIT_COMMITTER_DATE="2005-05-26 23:30" \
- TZ= git-commit-tree `cat treeid` >commitid 2>/dev/null'
+ TZ=GMT git-commit-tree `cat treeid` >commitid 2>/dev/null'
test_expect_success \
'read commit' \
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -41,7 +41,7 @@ test_expect_success \
find a -type l | xargs git-update-cache --add &&
treeid=`git-write-tree` &&
echo $treeid >treeid &&
- TZ= GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
+ TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
git-commit-tree $treeid </dev/null >.git/HEAD'
test_expect_success \
@@ -50,7 +50,7 @@ test_expect_success \
test_expect_success \
'validate file modification time' \
- 'TZ= tar tvf b.tar a/a |
+ 'TZ=GMT tar tvf b.tar a/a |
awk \{print\ \$4,\ \(length\(\$5\)\<7\)\ ?\ \$5\":00\"\ :\ \$5\} \
>b.mtime &&
echo "2005-05-27 22:00:00" >expected.mtime &&
^ permalink raw reply
* Re: git reveals a bug in (some versions) BSD diff
From: Brad Roberts @ 2005-08-13 10:42 UTC (permalink / raw)
To: git
I'm seeing this on a standard os/x 10.3.9 install which seems to have an
old, but still GNU based, diff.
$ which diff
/usr/bin/diff
$ diff --version
diff - GNU diffutils version 2.7
$ sh ./t4101-apply-nonl.sh
* ok 1: apply diff between 0 and 1
* ok 2: apply diff between 0 and 2
* ok 3: apply diff between 0 and 3
* ok 4: apply diff between 1 and 0
* ok 5: apply diff between 1 and 2
* ok 6: apply diff between 1 and 3
* ok 7: apply diff between 2 and 0
* ok 8: apply diff between 2 and 1
* FAIL 9: apply diff between 2 and 3
git-apply <diff.2-3 && diff frotz.3 frotz
* ok 10: apply diff between 3 and 0
* ok 11: apply diff between 3 and 1
* FAIL 12: apply diff between 3 and 2
git-apply <diff.3-2 && diff frotz.2 frotz
* failed 2 among 12 test(s)
For what it's worth, this is the only test failing on this box (after the
application of the TZ patch I just sent).
Later,
Brad
^ permalink raw reply
* [patch] possible memory leak in diff.c::diff_free_filepair()
From: Yasushi SHOJI @ 2005-08-13 10:58 UTC (permalink / raw)
To: git
Hi all,
When I run git-diff-tree on big change, it seems the command eats so
much memory. so I just put git under valgrind to see what's going on.
here is the output:
==26475== 63816 bytes in 766 blocks are definitely lost in loss record 7 of 7
==26475== at 0x1B8FF896: malloc (vg_replace_malloc.c:149)
==26475== by 0x805203B: alloc_filespec (diff.c:214)
==26475== by 0x80528C5: diff_addremove (diff.c:1141)
==26475== by 0x8049C7A: show_file (diff-tree.c:97)
==26475== by 0x8049D63: show_file (diff-tree.c:206)
==26475== by 0x8049D63: show_file (diff-tree.c:206)
==26475== by 0x8049D63: show_file (diff-tree.c:206)
==26475== by 0x8049EB3: diff_tree (diff-tree.c:118)
==26475== by 0x804A12E: diff_tree_sha1 (diff-tree.c:260)
==26475== by 0x804A06E: diff_tree (diff-tree.c:139)
==26475== by 0x804A12E: diff_tree_sha1 (diff-tree.c:260)
==26475== by 0x804A06E: diff_tree (diff-tree.c:139)
==26475==
==26475== LEAK SUMMARY:
==26475== definitely lost: 63816 bytes in 766 blocks.
==26475== possibly lost: 0 bytes in 0 blocks.
==26475== still reachable: 351 bytes in 6 blocks.
==26475== suppressed: 0 bytes in 0 blocks.
diff_free_filespec_data() doesn't free diff_filespec itself. is this
because in merge_broken() filespec itself is used but fliespec data
need to be freed?
so I've put one more function, diff_free_filespec(), between
diff_free_filepare() and diff_free_filespec_data() call-chain.
result is:
==27983== LEAK SUMMARY:
==27983== definitely lost: 0 bytes in 0 blocks.
==27983== possibly lost: 0 bytes in 0 blocks.
==27983== still reachable: 276 bytes in 6 blocks.
==27983== suppressed: 0 bytes in 0 blocks.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
diff --git a/diff.c b/diff.c
--- a/diff.c
+++ b/diff.c
@@ -767,10 +767,16 @@ struct diff_filepair *diff_queue(struct
return dp;
}
+void diff_free_filespec(struct diff_filespec *s)
+{
+ diff_free_filespec_data(s);
+ free(s);
+}
+
void diff_free_filepair(struct diff_filepair *p)
{
- diff_free_filespec_data(p->one);
- diff_free_filespec_data(p->two);
+ diff_free_filespec(p->one);
+ diff_free_filespec(p->two);
free(p);
}
^ permalink raw reply
* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Petr Baudis @ 2005-08-13 11:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, git
In-Reply-To: <Pine.LNX.4.58.0508122151120.19049@g5.osdl.org>
Dear diary, on Sat, Aug 13, 2005 at 07:05:11AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> If you really want a temporary tree, what you do is something like
>
> git-checkout-cache --prefix=tmp-dir/ -f -a
>
> and when you're done, you just do
>
> rm -rf tmp-dir
>
> and you're done.
>
> NOTE NOTE NOTE! In the above, the order of the parameters is really really
> important! "-a" takes effect when it is seen, so it needs to be last.
> Also, the "--prefix" thing really _really_ needs the slash at the end,
> because it's literally used to prefix the pathname.
>
> HOWEVER, if all you want to do is just a tar-file, then there's a better
> solution. It's called
>
> snap=git-snapshot-$(date +"%Y%m%d")
> git-tar-tree HEAD $snap | gzip -9 > $snap.tar.gz
>
> which is even easier, and a hell of a lot more efficient.
To put my two cents too, Cogito has cg-export for this:
cg-export tmp-dir
to export to a temporary directory and
cg-export git-snapshot.tar.gz
to export to a gzipped tarball (it can also do .tar, .tgz and .tar.bz2).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Petr Baudis @ 2005-08-13 12:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmznmp5ja.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Aug 13, 2005 at 11:09:13AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> It was a mistake to use GIT_ALTERNATE_OBJECT_DIRECTORIES
> environment variable to specify what alternate object pools to
> look for missing objects when working with an object database.
> It is not a property of the process running the git commands,
> but a property of the object database that is partial and needs
> other object pools to complete the set of objects it lacks.
>
> This patch allows you to have $GIT_OBJECT_DIRECTORY/info/alt
> file whose contents is in exactly the same format as the
> environment variable, to let an object database name alternate
> object pools it depends on.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
What about calling it rather info/alternates (or info/alternate)? It
looks better, sounds better, is more namespace-ecological tab-completes
fine and you don't type it that often anyway. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: Fwd: Re: git checkout -f branch doesn't remove extra files
From: Sergey Vlasov @ 2005-08-13 12:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Dave Jones, git
In-Reply-To: <20050813110050.GA5608@pasky.ji.cz>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
On Sat, 13 Aug 2005 13:00:51 +0200 Petr Baudis wrote:
> Dear diary, on Sat, Aug 13, 2005 at 07:05:11AM CEST, I got a letter
> where Linus Torvalds <torvalds@osdl.org> told me that...
[...]
> > snap=git-snapshot-$(date +"%Y%m%d")
> > git-tar-tree HEAD $snap | gzip -9 > $snap.tar.gz
> >
> > which is even easier, and a hell of a lot more efficient.
>
> To put my two cents too, Cogito has cg-export for this:
>
> cg-export tmp-dir
>
> to export to a temporary directory and
>
> cg-export git-snapshot.tar.gz
>
> to export to a gzipped tarball (it can also do .tar, .tgz and .tar.bz2).
However, cg-export is buggy - if you use the second argument
(cg-export DESTFILE TREE_ID), the resulting tar file is different
from what git-tar-tree produces for the same TREE_ID (unless that
TREE_ID actually points to a tree - but in practice a commit or even
tag ID is typically used).
The problem is in this line:
id=$(tree-id "$2")
This converts the passed commit or tag to the underlying tree, which
is then passed to git-tar-tree. However, git-tar-tree can follow
such links itself, and, what's more important, it actually uses some
information from the passed commit (it writes the commit ID to the
tar file as an extended header, and sets timestamp of all archive
members to the time of the commit). Therefore reducing the ID
passed to git-tar-tree to a plain tree ID is wrong - if a commit ID
is available, it should be used.
--
Sergey Vlasov
[-- Attachment #2: 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