* Re: [PATCH] format-patch: fix skipping of blank-lines
From: Linus Torvalds @ 2005-07-09 1:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0j44xi4.fsf@assigned-by-dhcp.cox.net>
On Fri, 8 Jul 2005, Junio C Hamano wrote:
>
> If it is fed a commit with more than one leading blank lines,
> the sed scripts git-format-patch-script used looped forever.
> This patch fixes it.
How about using "git-stripspace"? That's what it's there for. It strips
whitespace from the end of lines, from the beginning, and from the end. It
also removes multiple consecutive whitespace lines from within the body of
the message - which might turn some people off, but I use that same thing
when I do my automated email commits, so if you don't strip those lines
from the email, they _will_ get stripped at commit time, so..
"git-stripspace" also doesn't get confused by non-empty lines that have
spaces in them, like your script seems to be (ie /^$/ won't match a line
that has a space on it).
Linus
^ permalink raw reply
* Converting commits to patch files? HEAD vs HEAD^
From: Marc Singer @ 2005-07-09 1:38 UTC (permalink / raw)
To: git
Jeff Garzik's guide doesn't appear to explain how to get patches back
out of the system.
I've successfully commited a set of changes.
# git diff HEAD^ HEAD
This command will produce a diff of the changes I've made. What is
the HEAD^? Does it refer to the commit before the last one made?
If I've made several commits, I'd like to be able to gather several
together and produce a patch file. Better still, I'd like to be able
to pick a set of discontiguous commits an bundle them into a single
patch. Ought I be using tags?
Finally, given that the upstream repository is git, what is the way to
push commits upstream?
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Junio C Hamano @ 2005-07-09 1:31 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050709011628.GA11253@buici.com>
>>>>> "MS" == Marc Singer <elf@buici.com> writes:
MS> I gather that the approved solution is to have complete replicas of
MS> the git master from Linus for each line of development.
Either symlink .git/objects together, or GIT_OBJECT_DIRECTORY
environment variable point at a shared repository, and just do
not run git-prune-script and you will be fine.
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Marc Singer @ 2005-07-09 0:40 UTC (permalink / raw)
To: git
On Fri, Jul 08, 2005 at 05:17:08PM -0700, Junio C Hamano wrote:
> >>>>> "MS" == Marc Singer <elf@buici.com> writes:
>
> MS> In working through a usage example on my way to producing bonafide
> MS> patches, I've found that commit is complaining. Here's what I've done.
>
> MS> o Fetched and built cogito-0.12
> MS> o Fetched (rsync) Linus' tree
> MS> o Created a working directory, linux-2.6
> MS> o linked .git in the working directory to the .git directory fetched
> MS> from the net.
>
> This is slightly different from the BCP. A recommended way is:
>
> $ mkdir linux-2.6
> $ cd linux-2.6
> $ git-init-db
> $ rsync linux-2.6.git/ from kernel.org into .git/
Does this preclude symlinking .git? I'd like to keep one .git which
is mirrored from the net and allow for more than one working
directory.
> Although your commit problem does not have to do with this.
>
> MS> o # git checkout -f v2.6.11
> MS> o # cat ../old-patch-file | patch -p1
>
> GITified Linux kernel repository starts at v2.6.12-rc2, so
> from anything older you cannot create a commit off of it
> (easily).
Trouble is that 2.6.12 breaks some things and I need to continue to
build patches from 2.6.11 for the time being. Once I get familiar,
I'll patch the tree to build properly for my targets with later
revisions.
> MS> Then, according to Jeff's instructions, I have to perform
> MS> get-update-cache with the name of each file I changed. Is that really
> MS> the way?
>
> MS> o # git-update-cache LIST_OF_CHANGED_FILES
>
> That is correct. Also remember to say:
>
> git-update-cache --add LIST_OF_ADDED_FILES
> git-update-cache --remove LIST_OF_REMOVED_FILES
His text is a little overly-brief on this, but I got the gist.
> Notice the use of git-apply --index instead of patch -p1 in the
> above example? If you use git-apply --index, you do not have to
> do the above steps yourself.
Notice it...where? I gather that git-apply is a better way to apply
patches?
> MS> fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object
>
> That is a tag to the v2.6.11 tree, which is not a valid commit,
> so you cannot make a commit off of it.
So what does this mean? Can I only produce commits from the master?
Is this a peculiarity of the v2.6.11 tag?
> Linus, I think git-checkout-script should not store a tag to non
> commit in HEAD. If that did not happen, and if the repo was
> created without ref/heads/master (the usual case), then he
> _could_ have done something like this:
>
> $ git checkout -f v2.6.11 ;# fixed one
> warning: v2.6.11 is not a commit -- not updating your HEAD
> $ git commit ;# to have his own baseline at v2.6.11
> $ git-apply --index --stat --summary --apply <../old-patch-file
> $ : do the usual tests
> $ git commit ;# create a commit based on the baseline v2.6.11
That sounds like what I'm looking for. Can I do this by hand somehow?
As an ARM developer, I need to be able to cleanly track kernel
development revisions and produce patches that are easy to merge. The
cycle is something like this:
o Update kernel tree.
o Fix the build.
o Produce a patch to send upstream.
o Apply work-in-progress patches
o Fix the build.
o Publish new patches against updated kernel tree
The trickiest part has been bringing the works-in-progress forward
without spending lots of time babysitting the SCM tools.
^ permalink raw reply
* [PATCH] format-patch: fix skipping of blank-lines
From: Junio C Hamano @ 2005-07-09 0:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
If it is fed a commit with more than one leading blank lines,
the sed scripts git-format-patch-script used looped forever.
This patch fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-format-patch-script | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
58a3c79b488a28897cd5556dab0dd599b4ed9f0c
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -66,9 +66,13 @@ trap 'rm -f $tmp-*' 0 1 2 3 15
series=$tmp-series
titleScript='
- 1,/^$/d
+ /./d
: loop
- /^$/b loop
+ /^$/{
+ n
+ b loop
+ }
+ s/^\[PATCH[^]]*\] *//
s/[^-a-z.A-Z_0-9]/-/g
s/\.\.\.*/\./g
s/\.*$//
@@ -76,6 +80,7 @@ titleScript='
s/^-//
s/-$//
s/$/./
+ p
q
'
@@ -88,7 +93,7 @@ total=`wc -l <$series`
i=$total
while read commit
do
- title=`git-cat-file commit "$commit" | sed -e "$titleScript"`
+ title=`git-cat-file commit "$commit" | sed -ne "$titleScript"`
case "$numbered" in
'') num= ;;
*)
@@ -102,9 +107,12 @@ do
echo "$file"
{
mailScript='
- 1,/^$/d
+ /./d
: loop
- /^$/b loop
+ /^$/{
+ n
+ b loop
+ }
s|^|[PATCH'"$num"'] |
: body
p
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Marc Singer @ 2005-07-09 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x684wgr.fsf@assigned-by-dhcp.cox.net>
On Fri, Jul 08, 2005 at 06:08:52PM -0700, Junio C Hamano wrote:
> >>>>> "MS" == Marc Singer <elf@buici.com> writes:
>
> MS> Does this preclude symlinking .git? I'd like to keep one .git which
> MS> is mirrored from the net and allow for more than one working
> MS> directory.
>
> I think people typically do this by symlinking .git/objects, not
> .git/ itself.
>
> Presumably the reason you would want to have more than one
> working tree is so that you can keep more than one topic of
> development, one for each working tree, and make commits
> independently, right? Which commit is the latest in each work
> tree is, unsurprisingly, stored in .git/refs/heads/master file
> in each work tree, so usually you would _not_ want to share
> things other than .git/objects/ under .git/ directory across
> work trees.
>
> One major downside of this, which I was burned once myself
> (which is the reason for me to stop doing it), is that
> git-fsck-cache and git-prune-script would not know anything
> about the objects in the shared .git/objects reachable from
> other work trees, and can happily garbage collect objects
> necessary for other work trees.
Hmm. Seems, then, that this precludes any sharing at all. It isn't
so serious with git as it was wth BK. The latter being disk hungry.
I gather that the approved solution is to have complete replicas of
the git master from Linus for each line of development.
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Marc Singer @ 2005-07-09 1:11 UTC (permalink / raw)
To: git
In-Reply-To: <7v4qb46dff.fsf@assigned-by-dhcp.cox.net>
> $ git checkout -f v2.6.11 ;# fixed one
> warning: v2.6.11 is not a commit -- not updating your HEAD
> $ git commit ;# to have his own baseline at v2.6.11
> $ git-apply --index --stat --summary --apply <../old-patch-file
> $ : do the usual tests
> $ git commit ;# create a commit based on the baseline v2.6.11
Interesting note. I tried the git-apply command and found that it
complained and wouldn't succeed.
elf@florence ~...embedded/linux-2.6 > git-apply --index --stat --summary --apply < ../ms16/ide.patch
error: patch failed: drivers/ide/ide-io.c:129
error: drivers/ide/ide-io.c: patch does not apply
Yet, patch does apply.
elf@florence ~...embedded/linux-2.6 > patch -p1 < ../ms16/ide.patch
patching file drivers/ide/arm/ide_arm.c
patching file drivers/ide/arm/ide-lpd7952x.c
patching file drivers/ide/arm/ide-lpd7a40x.c
patching file drivers/ide/arm/Makefile
patching file drivers/ide/ide-disk.c
Hunk #1 succeeded at 282 (offset 41 lines).
Hunk #2 succeeded at 294 (offset 41 lines).
patching file drivers/ide/ide-io.c
Hunk #1 succeeded at 96 with fuzz 2 (offset -33 lines).
Hunk #2 succeeded at 1227 (offset 189 lines).
Hunk #3 succeeded at 1388 (offset 189 lines).
Hunk #4 succeeded at 1689 (offset 187 lines).
patching file drivers/ide/ide-iops.c
patching file drivers/ide/ide-probe.c
Hunk #1 succeeded at 422 (offset 51 lines).
Hunk #2 succeeded at 784 (offset 59 lines).
Hunk #3 succeeded at 847 (offset 59 lines).
Hunk #4 succeeded at 1112 (offset 64 lines).
Hunk #5 succeeded at 1172 (offset 64 lines).
patching file drivers/ide/Kconfig
Hunk #1 succeeded at 272 (offset -1 lines).
Hunk #2 succeeded at 781 (offset 5 lines).
patching file drivers/ide/legacy/ht6560b.c
patching file drivers/ide/legacy/qd65xx.c
patching file drivers/ide/pci/ns87415.c
patching file drivers/ide/pci/sl82c105.c
patching file drivers/ide/pci/trm290.c
patching file drivers/ide/ppc/pmac.c
Hunk #1 succeeded at 572 (offset 61 lines).
Hunk #2 succeeded at 596 (offset 61 lines).
patching file include/linux/ide.h
Hunk #1 succeeded at 961 (offset 1 line).
Hunk #2 succeeded at 1497 (offset -14 lines).
It should be obvious that a patch that doesn't apply cleanly,
i.e. without rejects, is still useful to apply so that I can fix the
places where it fails.
o Why does patch work and git-apply fail?
o Is there a way to force git to apply and safe the rejects?
^ permalink raw reply
* arch 2.0 first source available (git related)
From: Thomas Lord @ 2005-07-09 0:12 UTC (permalink / raw)
To: git
The first source release and some very early documentation for Arch 2.0
("revc") is now ready!
Web page: <http://www.seyza.com/>
Source: <http://www.seyza.com/releases/revc-0.0x0.tar.gz>
Source (tar bundle) SHA1:
9c279f78e57a99d517ccf5b983960620ff6f2cf7
Source (tar bundle) size: 1732018
Some highlights: revc has only 10 core commands; there are about 165
functions; the source code is literally about 14K lines and is closer to
10K lines if you subtract out non-code boilerplate.
User complaints about tla 1.x being addressed in revc:
inventory is too complicated -- but is drastically simplified (almost
eliminated) in 2.0
we hate the funny filenames -- 2.0 requires only a single .revc
directory and you aren't expected to edit any files there. No more
{arch}, {arch}/=tagging-method, or deeply nested project-tree logs
the namespace blows -- 2.0 allows just about any revision name that
doesn't contain a slash character. There is a moderate limit on the
length of a revision name.
all this stuff about registering archives and making mirrors is hard to
learn -- and, in 2.0, it's all gone. You can use rsync to mirror stuff,
for starters. And all archives are anonymous -- there's no longer any
such thing as an archive name.
too much is too slow -- although the 2.0 code isn't especially optimized
yet, it seems to be hella snappy.
2.0 is very much git influenced but it brings some (imo significant)
improvements to the table.
-t
^ permalink raw reply
* Re: patches to support working without the object database
From: Junio C Hamano @ 2005-07-08 19:34 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <7vwto16t6h.fsf@assigned-by-dhcp.cox.net>
Replying to myself...
JCH> While you are at it, you might also want to add an option to
JCH> write-blob to specify the type of the object you are hashing, so
JCH> that would make [*1*]:
JCH> git-write-blob [-n] [-t <type>] <file>...
JCH> [Footnote]
JCH> *1* I considered this instead:
JCH> git-write-blob [-n | -t <type>] <file>...
JCH> which means that if you specify type then -n is implied. But
JCH> making -t independent would let you have inverse of
JCH> git-cat-file; a silly example:
JCH> $ git-cat-file -t $FOO
JCH> tree
JCH> $ git-cat-file tree $FOO >tmp1
JCH> $ FOO1=$(git-write-blob -t tree tmp1)
JCH> If we go this route, we may also want to rename it to
JCH> write-object, but I would want to have it as a separate patch
JCH> after this series settles down.
Come to think of it, there is only one in-tree user of
write-blob remaining. Renaming it to hash-object, changing the
default behaviour to just hash without storing and instead give
it --write (or just -w) flag would make more sense. Without -t,
the type should default to "blob".
Then, the above stupid example would then become:
$ git-cat-file -t $FOO
tree
$ git-cat-file tree $FOO >tmp1
$ FOO1=$(git-hash-object -t tree tmp1)
And the only in-tree user git-cvsimport-script would be changed to:
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -683,7 +683,7 @@ while(<CVS>) {
$fn =~ s#^/+##;
my ($tmpname, $size) = $cvs->file($fn,$rev);
print "".($init ? "New" : "Update")." $fn: $size bytes.\n" if $opt_v;
- open my $F, '-|', "git-write-blob $tmpname"
+ open my $F, '-|', "git-hash-object -w $tmpname"
or die "Cannot create object: $!\n";
my $sha = <$F>;
chomp $sha;
^ permalink raw reply
* cogito Mac OS X compatibility
From: Bryan Larsen @ 2005-07-08 23:34 UTC (permalink / raw)
To: git
On Mac OS X
$ cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git
defaulting to local storage area
19:11:10
URL:http://www.kernel.org/pub/scm/cogito/cogito.git/refs/heads/master
[41/41] -> "refs/heads/origin" [1]
/Users/blarsen/bin/cg-pull: line 82: 0 + : syntax error: operand
expected (error token is " ")
cg-pull: objects pull failed
cg-init: pull failed
This appears to be some sort of weird shell thing. I've got bash 3.0
compiling in the background to see if that fixes the problem.
Cogito also appears to rely on the gnu tools. For instance, I've seen
the "-a" flag used with cp. OS X's default installation of cp doesn't
support -a. darwinports coreutils installs gnu cp as "gcp".
Myself, I can't live without cp -a, so have linked gcp to cp, but I
presume we want to be portable, at least to a certain degree.
Bryan
^ permalink raw reply
* Re: New script: cg-clean
From: Wolfgang Denk @ 2005-07-08 22:59 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Petr Baudis
In-Reply-To: <1120862084.17812.6.camel@dv>
In message <1120862084.17812.6.camel@dv> Pavel Roskin wrote:
>
> Please consider this script for Cogito.
...
> # OPTIONS
> # -------
> # -i::
> # Clean files ignored by cg-status, such as object files.
May I suggest to give "-i" the standard "--interactive" meaning
(= prompt before removal) like with "rm" etc. ?
Thanks.
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
How come everyone's going so slow if it's called rush hour?
^ permalink raw reply
* Bootstrapping into git, commit gripes at me
From: Marc Singer @ 2005-07-08 23:07 UTC (permalink / raw)
To: git
In working through a usage example on my way to producing bonafide
patches, I've found that commit is complaining. Here's what I've done.
o Fetched and built cogito-0.12
o Fetched (rsync) Linus' tree
o Created a working directory, linux-2.6
o linked .git in the working directory to the .git directory fetched
from the net.
o # git checkout -f v2.6.11
o # cat ../old-patch-file | patch -p1
Then, according to Jeff's instructions, I have to perform
get-update-cache with the name of each file I changed. Is that really
the way?
o # git-update-cache LIST_OF_CHANGED_FILES
Now I commit.
o # git commit
I am presented with an editor session with the list of changed files
already present. IfI add a comment and leave the editor, I'm told
fatal: 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is not a valid 'commit' object
If I don't edit the comment, it doesn't give an error but I don't
think the changes are committed because I can invoke git commit again.
Am I off track?
Cheers.
P.S. vger isn't letting me subscribe ATM. Please copy me with
replies.
^ permalink raw reply
* New script: cg-clean
From: Pavel Roskin @ 2005-07-08 22:34 UTC (permalink / raw)
To: git, Petr Baudis
Hello, Petr!
Please consider this script for Cogito.
Signed-off-by: Pavel Roskin <proski@gnu.org>
#!/usr/bin/env bash
#
# Clean unknown files from the working tree.
# Copyright (c) Pavel Roskin, 2005
#
# Cleans file and directories that are not under version control.
# Only regular files that are not ignored by cg-status are cleaned
# by default.
#
# OPTIONS
# -------
# -i::
# Clean files ignored by cg-status, such as object files.
#
# -s::
# Clean symlinks, fifos, sockets and other special files.
#
# -r::
# Clean directories.
#
# -R::
# Clean directories, try harder. Make directories writeable
# recursively before removing.
#
# -a::
# Clean all the above.
#
# If any other arguments are specified, they will be the only files
# considered for removal. It will also imply the `-a' option.
USAGE="cg-clean [-i] [-s] [-r] [-R] [-a] [FILE]..."
. ${COGITO_LIB}cg-Xlib
cleanexclude=
cleanspecial=
cleandir=
cleandirhard=
while optparse; do
if optparse -i; then
cleanexclude=1
elif optparse -s; then
cleanspecial=1
elif optparse -r; then
cleandir=1
elif optparse -R; then
cleandirhard=1
elif optparse -a; then
cleanexclude=1
cleandirhard=1
else
optfail
fi
done
if [ "$ARGS" ]; then
cleanexclude=1
cleandirhard=1
fi
# Good candidate for cg-Xlib
# Put exclude options for git-ls-files to EXCLUDE
set_exclude() {
stdignores=('*.[ao]' '.*' tags '*~' '#*' ',,merge*')
for ign in "${stdignores[@]}"; do
EXCLUDE="$EXCLUDE --exclude=$ign"
done
EXCLUDEFILE=$_git/exclude
if [ -f "$EXCLUDEFILE" ]; then
EXCLUDE="$EXCLUDE --exclude-from=$EXCLUDEFILE"
fi
}
EXCLUDE=
if [ -z "$cleanexclude" ]; then
set_exclude
fi
git-update-cache --refresh > /dev/null
do_clean() {
# FIXME - very suboptimal
if [ "$ARGS" ]; then
local found=
for arg in "${ARGS[@]}"; do
if [ "$arg" = "$file" ]; then
found=1
break
fi
done
[ "$found" ] || return
fi
if [ "$cleandirhard" ]; then
chmod -R 700 "$file"
rm -rf "$file"
return
fi
if [ "$cleandir" ]; then
rm -rf "$file"
return
fi
if [ "$cleanspecial" ]; then
[ -d "$file" ] && return
rm -f "$file"
return
fi
[ -f "$file" ] && rm -f "$file"
}
# Need to use temporary file so that changing IFS doesn't affect $EXCLUDE
# expansion.
filelist=$(mktemp -t gitlsfiles.XXXXXX)
git-ls-files --others $EXCLUDE >"$filelist"
IFS=$'\n'
for file in $(cat "$filelist"); do
do_clean "$file"
done
rm -f "$filelist"
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: patches to support working without the object database
From: Bryan Larsen @ 2005-07-08 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwto16t6h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>>>>>"BL" == Bryan Larsen <bryan.larsen@gmail.com> writes:
>
>
> BL> Sometimes you may wish to keep an audit trail of what changed, where,
> BL> and by whom. You do not need to know the exact details of the change,
> BL> and the files are so large that keeping an extra copy of the data in
> BL> the object database cache is prohibitively expensive.
>
> I am basically OK with this patch series, except I have one
> minor problem about interface detail, and more seriously, that
> the patch is whitespace mangled and would not apply. E.g.
>
* SNIP *
>
> Also please make sure that core GIT part patch applies against
> Linus tip (especially [PATCH 2/7]) as well. I think it does, but
> please double check.
>
>
I had trouble getting tip. That may be because I'm on OS X: I want to
try it on
a Linux box to narrow down the source of my problems. Given that it's
currently
4PM on Friday, I don't think the IT staff is going to fix the firewall
before Monday.
So please excuse me while I scrounge up another Linux box or two.
After that happens, I'll fix up my patches as suggested by you and
Linus, get
myself a real mailer and resubmit.
thanks,
Bryan
^ permalink raw reply
* Re: git and commiting
From: Linus Torvalds @ 2005-07-08 20:10 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: git
In-Reply-To: <42CE88A6.5080502@gmail.com>
On Fri, 8 Jul 2005, Mateusz Berezecki wrote:
>
> How to commit and check-in changes done to the checked-out source code?
> The "git commit" command seems to only commit the changes locally
> without pushing them via rsync.
> Is there any way I can push commits via rsync? Am I missing the point
> and git commit is not enough?
"git commit" is "enough" in the sense that it does indeed commit
everything to the local tree, and often that is enough.
But what you're asking for is to _export_ the changes to others. And
that's a different issue.
There's actually two different parts to exporting your changes:
- making your existing tree (or branch) available as-is on some public
place.
This is done with
git-send-pack <destination> [branches]
where the destination can either be a locally writable tree, or it's a
ssh-format remote tree (ie you need to have some place where you can
log into with ssh).
For example, when I export my kernel changes, I do so with
git-send-pack master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
which I have in a "push-all" script in my kernel directory (so that
regardless of what project I'm working on, I can just do "./push-all"
to push it to the repositories I have as the public destinations).
- other people will _pull_ the changes (ie you don't push them to others:
you publicize, and then it's up to others to decide whether they want
to pull your tree).
Now, there's one special case, namely when you use a shared "CVS-line"
repository that multiple people push to. If you do that, then you are both
pusher and puller, and exactly like with CVS, you'll have to be up-to-date
in order to push. So before you do the git-send-pack, you should first see
if you need to update with work that other people have done in the shared
repository, ie it might look something like this:
git pull repo.work.com:/project/work.git branch
git-send-pack repo.work.com:/project/work.git branch
where the first command makes sure that you're up-to-date (and as with
"cvs update", you may need to fix up any merge issues), and the second
command then pushes back the merge results.
NOTE NOTE NOTE! As it stands, git-send-pack is really geared towards _my_
kind of usage, ie it is geared towards sending to a public repository that
doesn't have other people pushing to it (ie it's "public for reading", but
it's "private for writing"). That's the way _I_ work, but it's not the
way you'd work in a more CVS-like environment with multiple people that
push to a common repository.
What this means is that "git-send-pack" is a bit too eager to try to make
the other end look exactly like _your_ end. It's a bit too easy to re-set
a branch that somebody else may have changed to what _you_ happen to have
in your tree, so be careful. The data doesn't go away, of course, but if
you reset a branch the old contents aren't reachable any more, so it might
as well be considered gone (you can use "git-fsck-cache" to find the
non-reachable commits and re-name them to some new branch, but the point
is that it's real work).
I'll try to make git-send-pack much more careful about setting branches to
new values.
Linus
^ permalink raw reply
* Re: pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
From: Linus Torvalds @ 2005-07-08 19:50 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: git
In-Reply-To: <200507081149.45344.adobriyan@gmail.com>
On Fri, 8 Jul 2005, Alexey Dobriyan wrote:
>
> I'm confused now. This pack file is ~60M in size. Will rsync download
> another 60M next time? What command should I use now to a) get latest and
> greatest and b) be nice with my traffic?
Your existing command should work fine.
You may (or may not) want to use the "--delete" argument to the rsync,
which will remove any old objects as they get packed. That won't change
your network traffic, but will just keep your disk usage down (and may
make rsync a bit more efficient).
And no, the way I'm setting up the kernel repo is that I won't re-pack the
_whole_ archive next time around, I'll only create a new incremental pack.
So next time a "git repack" happens, you'll see a new pack, probably in
the couple-of-megabytes size range (depending on how much work has done
on, of course), and the old pack you already downloaded will continue to
contain the older history.
Depending on how well - or badly - the incremental packing ends up
working, I _may_ end up doing a full, non-incremental pack at some point,
but that would be something that happens just a couple of times a year, so
then you'd get to do one big update every once in a while.
But I'm hoping that the incrementals work well enough that I literally
need to do that maybe once a year or something (replacing 50 incrementals
with one new big complete re-pack). Or maybe the incrementals work so well
that we don't need to do that at all.
So this "ugh, a new 60MB pack" thing should be something that happens
quite infrequently.
Linus
^ permalink raw reply
* Re: [PATCH] add --no-check option to git-write-tree
From: Linus Torvalds @ 2005-07-08 19:42 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42CE577C.1070404@gmail.com>
On Fri, 8 Jul 2005, Bryan Larsen wrote:
>
> Add --no-check option to git-write-tree.
I like almost all of these patches (well, the ones relevant to core git,
I'll not speak for Pasky on cogito), although I'd actually prefer your
"index_fd()" info-only flag to work the other way around: make it a flag
to say whether to update the object directory or not (ie "0" means info
only, and "1" means the current "update object directory" - and name it
accordingly, of course).
However, your mailer - apparently
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
is totally broken and does strange white-space corruption, so none of the
patches would apply.
So can you fix that up and re-send (and cc me on the git part)?
Linus
^ permalink raw reply
* Re: patches to support working without the object database
From: Junio C Hamano @ 2005-07-08 18:36 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42CE5764.9010405@gmail.com>
>>>>> "BL" == Bryan Larsen <bryan.larsen@gmail.com> writes:
BL> Sometimes you may wish to keep an audit trail of what changed, where,
BL> and by whom. You do not need to know the exact details of the change,
BL> and the files are so large that keeping an extra copy of the data in
BL> the object database cache is prohibitively expensive.
I am basically OK with this patch series, except I have one
minor problem about interface detail, and more seriously, that
the patch is whitespace mangled and would not apply. E.g.
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -139,7 +139,7 @@ extern int remove_cache_entry_at(int pos
extern int remove_file_from_cache(char *path);
extern int ce_same_name(struct cache_entry *a, struct cache_entry *b);
extern int ce_match_stat(struct cache_entry *ce, struct stat *st);
-extern int index_fd(unsigned char *sha1, int fd, struct stat *st);
+extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int
info_only);
Notice the "info_only" folded, and other unchanged lines
indented by two spaces instead of one?
Please retry. I especially like what [PATCH 4/7] does and do
not want to see this patch go to dustbin due to technicalities.
Also please make sure that core GIT part patch applies against
Linus tip (especially [PATCH 2/7]) as well. I think it does, but
please double check.
I would also suggest adding the same --info-only logic to
write-blob (perhaps give it a short and sweet name like "-n"),
in order to get the hash information out of it without actually
registering the blob.
This would make things more useful in general. One immediate
benefit of it is that we would have a standalone checksum
program we can reuse, by just saying "write-blob -n". Once you
have it, you _could_ even drop --info-only from git-update-cache
and use normal --cacheinfo instead.
While you are at it, you might also want to add an option to
write-blob to specify the type of the object you are hashing, so
that would make [*1*]:
git-write-blob [-n] [-t <type>] <file>...
One way to do this would be to add "const char *type" argument
to index_fd(), which is usually "blob" in the traditional use.
Then, the change to index_fd() would become:
- ret = write_sha1_file(buf, size, "blob", sha1);
+ if (info_only) {
+ (void) write_sha1_file_prepare(buf, size, type, sha1, hdr, &hdrlen);
+ ret = 0;
+ } else ret = write_sha1_file(buf, size, type, sha1);
But first let's get the whitespace mangling fixed up ;-).
[Footnote]
*1* I considered this instead:
git-write-blob [-n | -t <type>] <file>...
which means that if you specify type then -n is implied. But
making -t independent would let you have inverse of
git-cat-file; a silly example:
$ git-cat-file -t $FOO
tree
$ git-cat-file tree $FOO >tmp1
$ FOO1=$(git-write-blob -t tree tmp1)
If we go this route, we may also want to rename it to
write-object, but I would want to have it as a separate patch
after this series settles down.
^ permalink raw reply
* Re: Please rename t/t6000-lib.sh - it gets run as test
From: Chris Wright @ 2005-07-08 18:14 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1120846193.27711.6.camel@dv>
* Pavel Roskin (proski@gnu.org) wrote:
> I suggest renaming t6000-lib.sh to t6000.lib.sh but I'll be happy with
> any other name that doesn't match t[0-9][0-9][0-9][0-9]-*.sh
It's already been renamed to t6000lib.sh in current git repo.
thanks,
-chris
^ permalink raw reply
* Please rename t/t6000-lib.sh - it gets run as test
From: Pavel Roskin @ 2005-07-08 18:09 UTC (permalink / raw)
To: git
Hello!
t/t6000-lib.sh has a bad name - it matches the wildcard for tests and
gets run by "make test". The only side effect is an empty file named
t/sed.script. This is pretty benign, but let's fix it.
I suggest renaming t6000-lib.sh to t6000.lib.sh but I'll be happy with
any other name that doesn't match t[0-9][0-9][0-9][0-9]-*.sh
Alternatively, we could filter out *-lib.sh in t/Makefile, but I think
it would be more error prone.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Linus kernel tree corrupt?
From: Tony Luck @ 2005-07-08 17:06 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e473391050708085756bd463e@mail.gmail.com>
On 7/8/05, Jon Smirl <jonsmirl@gmail.com> wrote:
> What happened in this session...
Linus has "packed" his GIT tree ... and now http-pull doesn't work.
rsync still does (provided
you have a new enough cogito).
-Tony
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.12
From: Daniel Barkalow @ 2005-07-08 15:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Tony Luck, Junio C Hamano, git
In-Reply-To: <20050708081458.GA17022@pasky.ji.cz>
On Fri, 8 Jul 2005, Petr Baudis wrote:
> It seems like the whole pull family is totally borked now, and I'm
> getting desperate. Looks like this evening will be *pull.c fixing for
> me.
>
> Jul 04 Daniel Barkalow [PATCH 0/2] Support for transferring pack files in git-ssh-*
>
> is what brings some hope to my life, though. Daniel? Any chance we could
> get the similar fixes for local-pull? (I didn't actually look at the
> patch but briefly.)
This patch is not actually for transferring objects which are in pack
files in the source, but for transferring a group of objects as a pack
file. It does, however, read the source side with git-pack-objects to
generate the content to send, so it would, I guess, fix the problem for
the case where it decides to use a pack to transfer.
The real fix is to go through the pull methods (local-pull and
ssh-pull; http-pull presumably won't be encountering pack files yet) and
make them do appropriate things with pack files.
One thing that is in the patch is a change to the comment, specifying
that fetch() could also get other objects in addition to the one
specified, if there's some reason to think this is a good idea; the fix
for local-pull is probably to link/symlink/copy the pack file if the
object is in one.
For ssh-pull, serve_object in ssh-push needs to be taught how to extract
an object from a pack file and send it.
However, there's a bug in pull.c, covering up a terrible performance
issue: it doesn't actually make sure you have all the parent of a commit
that you had when it checked (due to not having a way of caching the
result of checking this, which would require you to put the entire
repository through cache each time you pull). This would mean that, if you
have a pack that references something outside of it, you won't get
everything with my proposal above.
I should be able to spend some time on these issues over the weekend.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Linus kernel tree corrupt?
From: Jon Smirl @ 2005-07-08 15:57 UTC (permalink / raw)
To: git
What happened in this session...
[jonsmirl@jonsmirl linus]$ cg update
11:52:32 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.g
it/refs/heads/master [41/41] -> "refs/heads/origin" [1]
progress: 34 objects, 102329 bytes
error: File 9cd17004869977026b473030ebb5b6fb71bfcebf
(http://www.kernel.org/pub/
scm/linux/kernel/git/torvalds/linux-2.6.git/objects/9c/d17004869977026b473030ebb
5b6fb71bfcebf) corrupt
Cannot obtain needed tree 9cd17004869977026b473030ebb5b6fb71bfcebf
while processing commit 0000000000000000000000000000000000000000.
cg-pull: objects pull failed
[jonsmirl@jonsmirl linus]$ cg update
11:53:26 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.g
it/refs/heads/master [41/41] -> "refs/heads/origin" [1]
Up to date.
Applying changes...
Branch already fully merged.
[jonsmirl@jonsmirl linus]$ cg pull
11:53:33 URL:http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.g
it/refs/heads/master [41/41] -> "refs/heads/origin" [1]
Up to date.
[jonsmirl@jonsmirl linus]$ cg diff
error: cannot read sha1_file for 9cd17004869977026b473030ebb5b6fb71bfcebf
fatal: unable to read tree object 7fd73e9f39bf6003cc3188a10426b62d8c47ab40
[jonsmirl@jonsmirl linus]$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Amin Azez @ 2005-07-08 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <42B9E536.60704@pobox.com>
Thanks for the HOWTO, Jeff, but it gives me problems in step 4.
I checked out your latest git source today and "make install"ed it as
part of your instructions and at step 4 I get:
$ git checkout -f
error: cannot map sha1 file f8640c306db2d583b9a30f2e52f8fb0a4cf624e0
fatal: failed to unpack tree object a92b7b80579fe68fe229892815c750f6652eb6a9
$ cat .git/HEAD
a92b7b80579fe68fe229892815c750f6652eb6a9
Naturally I have no idea what f8640c306db2d583b9a30f2e52f8fb0a4cf624e0
refers to.
Step 3:
$ git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
said I was already up to date.
Variations on step 4:
$ git-read-tree -m HEAD
or
$ git-read-tree a92b7b80579fe68fe229892815c750f6652eb6a9
also fail in the same way.
My linux-2.6 directory only has one entry, .git, containing about 75M of
files.
Sam
Jeff Garzik wrote:
>
> Things in git-land are moving at lightning speed, and usability has
> improved a lot since my post a month ago:
> http://lkml.org/lkml/2005/5/26/11
>
>
>
> 1) installing git
>
> git requires bootstrapping, since you must have git installed in order
> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> have put together a bootstrap tarball of today's git repository.
>
> Download tarball from:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
>
> tarball build-deps: zlib, libcurl, libcrypto (openssl)
>
> install tarball: unpack && make && sudo make prefix=/usr/local install
>
> jgarzik helper scripts, not in official git distribution:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branch
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
>
> After reading the rest of this document, come back and update your copy
> of git to the latest:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
>
>
> 2) download a linux kernel tree for the very first time
>
> $ mkdir -p linux-2.6/.git
> $ cd linux-2.6
> $ rsync -a --delete --verbose --stats --progress \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> \ <- word-wrapped backslash; sigh
> .git/
>
>
> 3) update local kernel tree to latest 2.6.x upstream ("fast-forward merge")
>
> $ cd linux-2.6
> $ git-pull-script \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
>
> 4) check out files from the git repository into the working directory
>
> $ git checkout -f
>
>
> 5) check in your own modifications (e.g. do some hacking, or apply a patch)
>
> # go to repo
> $ cd linux-2.6
>
> # make some modifications
> $ patch -sp1 < /tmp/my.patch
> $ diffstat -p1 < /tmp/my.patch
>
> # NOTE: add '--add' and/or '--remove' if files were added or removed
> $ git-update-cache <list of all files changed>
>
> # check in changes
> $ git commit
>
>
> 6) List all changes in working dir, in diff format.
>
> $ git-diff-cache -p HEAD
>
>
> 7) List all changesets (i.e. show each cset's description text) in local
> branch of local tree, that are not present in remote tree.
>
> $ cd my-kernel-tree-2.6
> $ git-changes-script -L ../linux-2.6 | less
>
>
> 8) List all changesets:
>
> $ git-whatchanged
>
>
> 9) apply all patches in a Berkeley mbox-format file
>
> First, download and add to your PATH Linus's git tools:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
>
> $ cd my-kernel-tree-2.6
> $ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
>
>
> 10) don't forget to download tags from time to time.
>
> git-pull-script only downloads sha1-indexed object data, and the
> requested remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads directories. It is advisable to update your kernel .git
> directories periodically with a full rsync command, to make sure you got
> everything:
>
> $ cd linux-2.6
> $ rsync -a --delete --verbose --stats --progress \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> \ <- word-wrapped backslash; sigh
> .git/
>
>
> 11) list all branches, such as those found in my netdev-2.6 or
> libata-dev trees.
>
> Download
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
> or
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>
>
> $ cd netdev-2.6
> $ ls .git/refs/heads/
>
> { these are the current netdev-2.6 branches }
>
>> 8139cp forcedeth master qeth smc91x we18
>> 8139too-iomap for-linus natsemi r8169 smc91x-eeprom wifi
>> airo hdlc ns83820 register-netdev starfire
>> atmel ieee80211 orinoco remove-drivers tlan
>> chelsio iff-running orinoco-hch sis900 veth
>> dm9000 janitor ppp skge viro
>
>
>
> 12) make desired branch current in working directory
>
> $ git checkout -f $branch
>
>
> 13) create a new branch, and make it current
>
> $ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
> $ git checkout -f my-new-branch-name
>
>
> 14) examine which branch is current
>
> $ ls -l .git/HEAD
>
>
> 15) undo all local modifications (same as checkout):
>
> $ git checkout -f
>
>
> 16) obtain a diff between current branch, and master branch
>
> In most trees WITH BRANCHES, .git/refs/heads/master contains the current
> 'vanilla' upstream tree, for easy diffing and merging. (in trees
> without branches, 'master' simply contains your latest changes)
>
> $ git-diff-tree -p master HEAD
>
>
> -
> 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
>
^ permalink raw reply
* git and commiting
From: Mateusz Berezecki @ 2005-07-08 14:07 UTC (permalink / raw)
To: git
Hi list readers,
How to commit and check-in changes done to the checked-out source code?
The "git commit" command seems to only commit the changes locally
without pushing them via rsync.
Is there any way I can push commits via rsync? Am I missing the point
and git commit is not enough?
please CC me with the answer as I am not subscribed to the list.
regards
/mb
^ 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