* 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
* Re: Bootstrapping into git, commit gripes at me
From: Linus Torvalds @ 2005-07-09 1:43 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050708230750.GA23847@buici.com>
On Fri, 8 Jul 2005, Marc Singer wrote:
>
> 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
This won't work.
v2.6.11 isn't a commit, it's a tree, and things will go downhill from
there.
Can you base it on 2.6.12-rc2 or later? That's the earliest with some real
git history.
Linus
^ permalink raw reply
* Re: Converting commits to patch files? HEAD vs HEAD^
From: Linus Torvalds @ 2005-07-09 1:52 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050709013859.GA11947@buici.com>
On Fri, 8 Jul 2005, Marc Singer wrote:
>
> # 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?
Yes. The core tools don't understand this syntax, but most of the helper
scripts use "git-rev-parse" to parse arguments, and then you have the
"extended syntax" which allows short SHA1 names and "parenting".
HEAD^ is the "first parent of HEAD". You could also have written it
"HEAD^1", although the number is really only relevant if you have a merge,
and you want to specify the _other_ side, ie "HEAD^2" is the "second
parent of HEAD".
If you want to have the parent of the parent, write HEAD^^.
Now, to confuse things, a "^" at the _beginning_ of the name means
something else: it means "not", and it used to do ranges.
> 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?
You can use tags, but you can just do
git log
and pick out the commit ID's from there and use those too.
"git-whatchanged -p" is also useful to see what's been going on. And
"gitk", of course.
> Finally, given that the upstream repository is git, what is the way to
> push commits upstream?
You can do
git push destination
(which I just added today), which is just the same thing as
"git-send-pack".
BUT NOTE! It only works for destinations that _you_ control, though. You
can't push to others - you can only push to your own repositories, and
then wait for others to pull from them. Ie, the normal reason to use
"git-send-pack" or "git push" is because you do the work on a private
machine, and then you want to push it out to a public one (still yours),
and send an email to people saying "please pull from so-and-so".
Linus
^ permalink raw reply
* [PATCH] format-patch: fix skipping of blank-lines (take 2)
From: Junio C Hamano @ 2005-07-09 2:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507081838560.17536@g5.osdl.org>
If it is fed a commit with more than one leading blank lines,
the sed scripts git-format-patch-script used looped forever.
Using git-stripspace upfront makes the sed script somewhat
simpler to work around this problem.
Also use git-rev-parse so that we can say
$ git-format-patch-script HEAD^^^^
to prepare the latest four patches for e-mail submission.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> How about using "git-stripspace"?
I first thought it would be an overkill, but it lets me cheat in
the sed script. Thanks for the suggestion.
git-format-patch-script | 22 ++++++++++++++--------
1 files changed, 14 insertions(+), 8 deletions(-)
3006f6c35d08a0f060e021573771b3cfc70c0682
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -53,6 +53,8 @@ case "$#" in
1) linus="$1" junio=HEAD ;;
*) usage ;;
esac
+junio=`git-rev-parse --verify "$junio"`
+linus=`git-rev-parse --verify "$linus"`
case "$outdir" in
*/) ;;
@@ -66,9 +68,9 @@ trap 'rm -f $tmp-*' 0 1 2 3 15
series=$tmp-series
titleScript='
- 1,/^$/d
- : loop
- /^$/b loop
+ /./d
+ /^$/n
+ s/^\[PATCH[^]]*\] *//
s/[^-a-z.A-Z_0-9]/-/g
s/\.\.\.*/\./g
s/\.*$//
@@ -76,6 +78,7 @@ titleScript='
s/^-//
s/-$//
s/$/./
+ p
q
'
@@ -88,7 +91,9 @@ 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" |
+ git-stripspace |
+ sed -ne "$titleScript"`
case "$numbered" in
'') num= ;;
*)
@@ -102,16 +107,17 @@ do
echo "$file"
{
mailScript='
- 1,/^$/d
- : loop
- /^$/b loop
+ /./d
+ /^$/n
s|^|[PATCH'"$num"'] |
: body
p
n
b body'
- git-cat-file commit "$commit" | sed -ne "$mailScript"
+ git-cat-file commit "$commit" |
+ git-stripspace |
+ sed -ne "$mailScript"
echo '---'
echo
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
^ permalink raw reply
* Re: Converting commits to patch files? HEAD vs HEAD^
From: Junio C Hamano @ 2005-07-09 2:41 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050709013859.GA11947@buici.com>
>>>>> "MS" == Marc Singer <elf@buici.com> writes:
MS> If I've made several commits, I'd like to be able to gather several
MS> together and produce a patch file. Better still, I'd like to be able
MS> to pick a set of discontiguous commits an bundle them into a single
MS> patch. Ought I be using tags?
You ought to be using ...
Oh, I want to say it because the above is what I do all the time
using my Porcelain on GIT, but on the other hand, officially I
am _not_ working on any Porcelain, so... I am in a dilemma. I
won't talk about that tool I use myself.
Although I have not looked at it myself, you may want to take a
look at StGIT.
"Keeping patches, tracking upstream by primarily updating,
forward porting and e-mail submitting patches" is often the
development model taken by "individual developers", while
"making commits primarily by accepting patches, merging with
repos of other people who have similar aggregator role" is often
the model used by "project leads".
The core GIT (and "git" barebone Porcelain) is geared towards
"project lead" use, and I suspect Cogito would be so to a
certain extent. By judging only from its description, StGIT,
with its attitude ancestry of quilt, may be more comfortable to
use with "individual developers" mode of operation.
Well, I'd say what I use anyway, and quickly duck ;-)
You ought to be using ... JIT.
^ permalink raw reply
* qgit-0.7
From: Marco Costalba @ 2005-07-09 8:15 UTC (permalink / raw)
To: git
Here is qgit-0.7, a GUI git viewer.
you can download from:
http://prdownloads.sourceforge.net/qgit/qgit-0.7.tar.gz?download
This time a small changelog, but a lot of work ;-)
- rewrite of graph drawing
- start-up loading: switch to use git-rev-list --topo-order
- final fixes to annotation
- cache of file lists to speed-up loading of file names
- added color background on heads
Graph now uses connected lines and should be better to follow,
also the switch from home grown to legacy git-rev-list --topo-order helps in
clarify revs history.
Annotation now works for me in all cases with the limitation that does not
follow renames.
When you run qgit for the first time it takes some time to git-rev-list and
git-diff-tree the repo. Following runs are faster because a persistent
cache of file names is used, so the speed is the same of just running git-rev-list.
Note: because of the use of --topo-order option in git-rev-list you need a very
recent copy of git.
For people who missed previous releases, a brief feature list:
- revisions log with diff and file viewer windows
- graph of development lines
- automatic update of all open views when navigating through lists
- filter by a substring (with wildcards support) in SHA, short log, author or paths
- colored file list window: green new file, red removed one
- patch viewer of diffs against parent, head or a mouse selected (CTRL + PRESS) rev
- file viewer with automatic annotation of content and file history
- file viewer with substring find function and jump to diff with double-click in
annotate line
- command line arguments support using git-rev-parse
- highlight on tags and heads
As usual, to try qgit:
-unpack files
-make
-cd bin
-copy qgit in the path
-run qgit from a git working directory
Please refer to README for more information.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Stacked GIT 0.4
From: Catalin Marinas @ 2005-07-09 9:05 UTC (permalink / raw)
To: GIT
Stacked GIT 0.4 release is available from http://procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
Note that StGIT is not an SCM interface on top of GIT and it expects a
previously initialised GIT repository. For standard SCM operations,
either use plain GIT commands or the Cogito tool.
For more information, see the README file in the archive.
What's new in this release:
* Support for configuration files (/etc/stgitrc,
~/.stgitrc, .git/stgitrc)
* Configurable merge tool ('diff3' by default)
* Empty patches are marked with a '0' when listed with
'series' (useful for tracking upstream merges)
* Support for patch description templates (with variables like
author details and diffstats)
* 'files' command to show the files modified by a patch (either a
simple list or with diffstats)
* 'push --undo' option to cancel a push operation
* 'push/pop --to' option to perform the operation on a range of
patches between the given names
* 'push --reverse' option to push patches in reverse order
* 'diff --stat' option to show the diffstats instead of the diff
* Faster 'pop' - it now switches directly to the bottom of the
last patch to be popped
* The three files involved in a three-way merge are left in the
working tree in case of a conflict for further analysis (can be
overwritten with the 'keeporig' option)
* Many bug fixes
--
Catalin
^ permalink raw reply
* tag referring to a commit but not directly?
From: Junio C Hamano @ 2005-07-09 10:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I was playing with a tag that refers to another tag which refers
to a commit, and found out that some things did not work as I
expected.
Is it a PEBCAK on my part to expect tag-to-tag-to-commit to
behave the same way as a bare commit (or a tag to commit), or is
this just a bug? I think the following two would fix what I
found, but I am not sure if I am using the "struct object" and
friends the way they are expected to be used. I am uncertain
about what the expected behaviour should be either for that
matter; I admit that tags are new to me.
---
*** To find whom to ask about the thing I am butchering, I
*** used the following pickaxe:
git-rev-list linus |
git-diff-tree --stdin -v -s \
-S' if (obj->type == tag_type)
obj = ((struct tag *)obj)->tagged;'
git-rev-list linus |
git-diff-tree --stdin -v -s \
-S' /*
* Tag object? Look what it points to..
*/
if (object->type == tag_type) {'
------------
cd /opt/packrat/playpen/public/in-place/git/git.junio/
jit-diff 0:5
# - master: format-patch: fix skipping of blank-lines (take 2)
# + 5: tag deref until we get non tag
diff --git a/commit.c b/commit.c
--- a/commit.c
+++ b/commit.c
@@ -52,8 +52,9 @@ struct commit *lookup_commit_reference(c
if (!obj)
return NULL;
- if (obj->type == tag_type)
- obj = ((struct tag *)obj)->tagged;
+ while (obj->type == tag_type)
+ obj = parse_object(((struct tag *)obj)->tagged->sha1);
+
return check_commit(obj, sha1);
}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -354,12 +354,12 @@ static struct commit *get_commit_referen
/*
* Tag object? Look what it points to..
*/
- if (object->type == tag_type) {
+ while (object->type == tag_type) {
struct tag *tag = (struct tag *) object;
object->flags |= flags;
if (tag_objects && !(object->flags & UNINTERESTING))
add_pending_object(object, tag->tag);
- object = tag->tagged;
+ object = parse_object(tag->tagged->sha1);
}
/*
Compilation finished at Sat Jul 9 02:37:16
^ permalink raw reply
* [PATCH 1/3] add -N option to cg-add (resent)
From: Bryan Larsen @ 2005-07-09 10:40 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, git
(resending cogito patches)
Add the -N option to cg-add.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-add | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -13,20 +13,35 @@
# is that 'Cogito' manages content and empty directories have no content.
# Instead, directories are added automatically when adding files inside
# them.
+#
+# OPTIONS
+# -------
+# -N::
+# Only update the cache: do not copy the data into the object database.
+#
-USAGE="cg-add FILE..."
+USAGE="cg-add [-N] FILE..."
. ${COGITO_LIB}cg-Xlib
[ "$1" ] || usage
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=--info-only
+ else
+ optfail
+ fi
+done
+
TMPFILE=$(mktemp -t gitadd.XXXXXX) || exit 1
-find "$@" -type f -print0 > $TMPFILE || {
+find "${ARGS[@]}" -type f -print0 > $TMPFILE || {
die "not all files exist, nothing added"
rm $TMPFILE
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add --
+cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
rm $TMPFILE
\f
^ permalink raw reply
* [PATCH 2/3] add -N option to cg-commit (resent)
From: Bryan Larsen @ 2005-07-09 10:40 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, git
In-Reply-To: <20050709104011.26763.37732.sendpatchset@bryan-larsens-ibook-g4.local>
(resending cogito patches)
Add the -N option to cg-add.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-add | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -13,20 +13,35 @@
# is that 'Cogito' manages content and empty directories have no content.
# Instead, directories are added automatically when adding files inside
# them.
+#
+# OPTIONS
+# -------
+# -N::
+# Only update the cache: do not copy the data into the object database.
+#
-USAGE="cg-add FILE..."
+USAGE="cg-add [-N] FILE..."
. ${COGITO_LIB}cg-Xlib
[ "$1" ] || usage
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=--info-only
+ else
+ optfail
+ fi
+done
+
TMPFILE=$(mktemp -t gitadd.XXXXXX) || exit 1
-find "$@" -type f -print0 > $TMPFILE || {
+find "${ARGS[@]}" -type f -print0 > $TMPFILE || {
die "not all files exist, nothing added"
rm $TMPFILE
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add --
+cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
rm $TMPFILE
\f
^ permalink raw reply
* [PATCH 3/3] add -N option to cg-init (resent)
From: Bryan Larsen @ 2005-07-09 10:40 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, git
In-Reply-To: <20050709104011.26763.37732.sendpatchset@bryan-larsens-ibook-g4.local>
(resending cogito patches)
Add the -N option to cg-add.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-add | 21 ++++++++++++++++++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -13,20 +13,35 @@
# is that 'Cogito' manages content and empty directories have no content.
# Instead, directories are added automatically when adding files inside
# them.
+#
+# OPTIONS
+# -------
+# -N::
+# Only update the cache: do not copy the data into the object database.
+#
-USAGE="cg-add FILE..."
+USAGE="cg-add [-N] FILE..."
. ${COGITO_LIB}cg-Xlib
[ "$1" ] || usage
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=--info-only
+ else
+ optfail
+ fi
+done
+
TMPFILE=$(mktemp -t gitadd.XXXXXX) || exit 1
-find "$@" -type f -print0 > $TMPFILE || {
+find "${ARGS[@]}" -type f -print0 > $TMPFILE || {
die "not all files exist, nothing added"
rm $TMPFILE
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add --
+cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
rm $TMPFILE
\f
^ permalink raw reply
* Re: Linus kernel tree corrupt?
From: Russell King @ 2005-07-09 10:43 UTC (permalink / raw)
To: Tony Luck; +Cc: Jon Smirl, git
In-Reply-To: <12c511ca05070810065db87043@mail.gmail.com>
On Fri, Jul 08, 2005 at 10:06:09AM -0700, Tony Luck wrote:
> 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).
So does that mean we should ignore cogito's whinging about rsync being
deprecated?
--
Russell King
^ permalink raw reply
* [PATCH 2/3] add -N option to cg-commit (resent again)
From: Bryan Larsen @ 2005-07-09 10:43 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, git
(resending cogito patches)
Add the -N option to cg-commit.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-commit | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -39,6 +39,10 @@
# the tree is the same as the last time you committed, no changes
# happenned.
#
+# -N::
+# Don't add the files to the object database, just update the caches
+# and the commit information.
+#
# FILES
# -----
# $GIT_DIR/author::
@@ -103,11 +107,16 @@ fi
force=
forceeditor=
ignorecache=
+infoonly=
commitalways=
+nocheck=
msgs=()
while optparse; do
if optparse -C; then
ignorecache=1
+ elif optparse -N; then
+ nocheck=--no-check
+ infoonly=--info-only
elif optparse -e; then
forceeditor=1
elif optparse -E; then
@@ -278,9 +287,9 @@ precommit_update () {
eval "queue$op[\${#queue$op[@]}]=\"\$fname\""
done
# XXX: Do we even need to do the --add and --remove update-caches?
- [ "$queueN" ] && { git-update-cache --add -- "${queueN[@]}" || return 1; }
+ [ "$queueN" ] && { git-update-cache --add ${infoonly} -- "${queueN[@]}" || return 1; }
[ "$queueD" ] && { git-update-cache --force-remove -- "${queueD[@]}" || return 1; }
- [ "$queueM" ] && { git-update-cache -- "${queueM[@]}" || return 1; }
+ [ "$queueM" ] && { git-update-cache ${infoonly} -- "${queueM[@]}" || return 1; }
return 0
}
@@ -300,7 +309,7 @@ if [ -s "$_git/HEAD" ]; then
oldheadstr="-p $oldhead"
fi
-treeid=$(git-write-tree)
+treeid=$(git-write-tree ${nocheck})
[ "$treeid" ] || die "git-write-tree failed"
if [ ! "$force" ] && [ ! "$merging" ] && [ "$oldhead" ] &&
[ "$treeid" = "$(tree-id)" ]; then
\f
^ permalink raw reply
* [PATCH 3/3] add -N option to cg-init (resent again)
From: Bryan Larsen @ 2005-07-09 10:43 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, git
In-Reply-To: <20050709104316.26765.86980.sendpatchset@bryan-larsens-ibook-g4.local>
(resending cogito patches)
add the -N option to cg-init
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-init | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -10,13 +10,29 @@
#
# If `cg-init` is run in a non-empty directory files in the top and
# sub directory will automatically be added.
+#
+# OPTIONS
+# -------
+# -N::
+# Only update the cache: do not copy the data into the object database.
+#
-USAGE="cg-init"
+USAGE="cg-init [-N]"
_git_repo_unneeded=1
. ${COGITO_LIB}cg-Xlib
-uri=$1
+
+infoonly=
+while optparse; do
+ if optparse -N; then
+ infoonly=-N
+ else
+ optfail
+ fi
+done
+
+uri=$ARGV
[ -e $_git ] && die "$_git already exists"
@@ -38,7 +54,7 @@ if [ "$uri" ]; then
echo "Cloned (origin $uri available as branch \"origin\")"
else
git-read-tree # Seed the dircache
- find * \( -type f -o -type l \) -print0 | xargs -0r cg-add
+ find * \( -type f -o -type l \) -print0 | xargs -0r cg-add ${infoonly}
cg-commit -C -m"Initial commit" -E
fi
^ permalink raw reply
* What broke snapshots now?
From: David Woodhouse @ 2005-07-09 11:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 293 bytes --]
Does git on master.kernel.org need to be updated to handle packed
objects? See attached.
Linus, please could you add the snapshot script to your regression
testing? http://david.woodhou.se/git-snapshot.sh
It'd be good to keep that working without too much manual intervention.
--
dwmw2
[-- Attachment #2: Forwarded message - Cron <dwmw2@hera> /home/dwmw2/bin/git-snapshot.sh --]
[-- Type: message/rfc822, Size: 7524 bytes --]
From: root@hera.kernel.org (Cron Daemon)
To: dwmw2@hera.kernel.org
Subject: Cron <dwmw2@hera> /home/dwmw2/bin/git-snapshot.sh
Date: Fri, 8 Jul 2005 02:01:01 -0700
Message-ID: <200507080901.j68911XE005138@hera.kernel.org>
+ case `hostname` in
++ hostname
+ export PATH=/home/dwmw2/cogito:/usr/bin:/bin
+ PATH=/home/dwmw2/cogito:/usr/bin:/bin
+ export BASE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ BASE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ STAGINGLOCK=/staging/upload.lock
+ FINAL=/pub/linux/kernel/v2.6/snapshots
+ '[' '!' -d /pub/scm/linux/kernel/git/torvalds/linux-2.6.git ']'
+ export WORK_DIRECTORY=/home/dwmw2/snapshots/2.6
+ WORK_DIRECTORY=/home/dwmw2/snapshots/2.6
+ export SNAP_TAG_DIRECTORY=/home/dwmw2/snapshots/2.6/tags
+ SNAP_TAG_DIRECTORY=/home/dwmw2/snapshots/2.6/tags
+ export STAGE=/home/dwmw2/snapshots/2.6/stage
+ STAGE=/home/dwmw2/snapshots/2.6/stage
+ export SHA1_FILE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
+ SHA1_FILE_DIRECTORY=/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
++ ls -rt /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.11 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.11-tree /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc2 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc3 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc4 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc5 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.12-rc6 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.13-rc1 /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.13-rc2
++ tail -n1
++ sed s:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v::
+ RELNAME=2.6.13-rc2
++ cat /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/tags/v2.6.13-rc2
+ RELOBJ=c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19
++ tail -n1
++ sed s:/home/dwmw2/snapshots/2.6/tags/v::
++ ls -rt /home/dwmw2/snapshots/2.6/tags/v2.6.13-rc2-git1
+ SNAPNAME=2.6.13-rc2-git1
+ '[' 2.6.13-rc2-git1 == '' ']'
++ cat /home/dwmw2/snapshots/2.6/tags/v2.6.13-rc2-git1
+ LASTOBJ=c101f3136cc98a003d0d16be6fab7d0d950581a6
++ echo 2.6.13-rc2-git1
++ sed 's/^.*-git//'
+ OLDGITNUM=1
++ expr 1 + 1
+ NEWGITNUM=2
+ CURNAME=2.6.13-rc2-git2
++ tree-id c101f3136cc98a003d0d16be6fab7d0d950581a6
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/c1/01f3136cc98a003d0d16be6fab7d0d950581a6: No such file or directory
fatal: git-cat-file c101f3136cc98a003d0d16be6fab7d0d950581a6: bad file
Invalid id: c101f3136cc98a003d0d16be6fab7d0d950581a6
usage: git-cat-file [-t | tagname] <sha1>
usage: git-cat-file [-t | tagname] <sha1>
Invalid id:
+ LASTTREE=
++ cat /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/HEAD
+ CURCOMM=a92b7b80579fe68fe229892815c750f6652eb6a9
++ tree-id a92b7b80579fe68fe229892815c750f6652eb6a9
+ CURTREE=7fd73e9f39bf6003cc3188a10426b62d8c47ab40
++ tree-id c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/c5/21cb0f10ef2bf28a18e1cc8adf378ccbbe5a19: No such file or directory
fatal: git-cat-file c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19: bad file
Invalid id: c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19
usage: git-cat-file [-t | tagname] <sha1>
usage: git-cat-file [-t | tagname] <sha1>
Invalid id:
+ RELTREE=
+ echo release 2.6.13-rc2 commit tree
release 2.6.13-rc2 commit tree
++ git-cat-file -t c101f3136cc98a003d0d16be6fab7d0d950581a6
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/c1/01f3136cc98a003d0d16be6fab7d0d950581a6: No such file or directory
fatal: git-cat-file c101f3136cc98a003d0d16be6fab7d0d950581a6: bad file
+ echo last c101f3136cc98a003d0d16be6fab7d0d950581a6 tree
last c101f3136cc98a003d0d16be6fab7d0d950581a6 tree
+ echo head a92b7b80579fe68fe229892815c750f6652eb6a9 tree 7fd73e9f39bf6003cc3188a10426b62d8c47ab40
head a92b7b80579fe68fe229892815c750f6652eb6a9 tree 7fd73e9f39bf6003cc3188a10426b62d8c47ab40
+ '[' '' == 7fd73e9f39bf6003cc3188a10426b62d8c47ab40 ']'
++ echo 2.6.13-rc2-git2
++ cut -f2- -d-
+ EXTRAVERSION=-rc2-git2
+ cd /home/dwmw2/snapshots/2.6/stage
+ rm -rf tmp-empty-tree
+ mkdir -p tmp-empty-tree/.git
+ cd tmp-empty-tree
+ git-read-tree a92b7b80579fe68fe229892815c750f6652eb6a9
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/f8/640c306db2d583b9a30f2e52f8fb0a4cf624e0: No such file or directory
fatal: failed to unpack tree object a92b7b80579fe68fe229892815c750f6652eb6a9
+ git-checkout-cache Makefile
checkout-cache: Makefile is not in the cache.
+ perl -pi -e 's/EXTRAVERSION =.*/EXTRAVERSION = -rc2-git2/' Makefile
Can't open Makefile: No such file or directory.
+ git-diff-cache -m -p
+ gzip -9
usage: diff-cache [-r] [-z] [-p] [-i] [--cached] <tree sha1>
+ echo a92b7b80579fe68fe229892815c750f6652eb6a9
+ cg-log c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19:a92b7b80579fe68fe229892815c750f6652eb6a9
mv: cannot stat `.git/heads': No such file or directory
mv: cannot stat `.git/tags': No such file or directory
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/c5/21cb0f10ef2bf28a18e1cc8adf378ccbbe5a19: No such file or directory
fatal: git-cat-file c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19: bad file
Invalid id: c521cb0f10ef2bf28a18e1cc8adf378ccbbe5a19
+ echo a92b7b80579fe68fe229892815c750f6652eb6a9
+ echo New Snapshot 2.6.13-rc2-git2
New Snapshot 2.6.13-rc2-git2
+ '[' -z /pub/linux/kernel/v2.6/snapshots ']'
+ '[' -r /staging/upload.lock ']'
+ exec
+ flock -s 200
+ mv -v /home/dwmw2/snapshots/2.6/stage/patch-2.6.13-rc2-git2.gz /home/dwmw2/snapshots/2.6/stage/patch-2.6.13-rc2-git2.id /home/dwmw2/snapshots/2.6/stage/patch-2.6.13-rc2-git2.log /pub/linux/kernel/v2.6/snapshots
`/home/dwmw2/snapshots/2.6/stage/patch-2.6.13-rc2-git2.gz' -> `/pub/linux/kernel/v2.6/snapshots/patch-2.6.13-rc2-git2.gz'
`/home/dwmw2/snapshots/2.6/stage/patch-2.6.13-rc2-git2.id' -> `/pub/linux/kernel/v2.6/snapshots/patch-2.6.13-rc2-git2.id'
`/home/dwmw2/snapshots/2.6/stage/patch-2.6.13-rc2-git2.log' -> `/pub/linux/kernel/v2.6/snapshots/patch-2.6.13-rc2-git2.log'
^ permalink raw reply
* Re: Converting commits to patch files? HEAD vs HEAD^
From: Catalin Marinas @ 2005-07-09 11:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Singer, git
In-Reply-To: <7vvf3k1z28.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>>>>>> "MS" == Marc Singer <elf@buici.com> writes:
> MS> If I've made several commits, I'd like to be able to gather several
> MS> together and produce a patch file. Better still, I'd like to be able
> MS> to pick a set of discontiguous commits an bundle them into a single
> MS> patch. Ought I be using tags?
>
> Although I have not looked at it myself, you may want to take a
> look at StGIT.
I still haven't found time to write a tutorial for StGIT (it has a
README but I haven't updated it for some time) but I will try to give
a short description. People familiar with Quilt should not have any
problem with using this tool (it is safer than quilt).
StGIT is well suited for working on trees you do not control (you send
patches and wait for them to be merged and eventually get them from
the remote repository when pulling the latest changes). The advantage
over quilt is that it uses three-way merging and also informs you when
your local patch is empty (i.e., after the patch was fully merged
upstream, quilt just failing to push the patch in this case because of
conflicts).
In general, you clone a repository (Linus' for example) and run
'stg init' to initialise the StGIT specific files.
There is no 'commit' command in StGIT. To make changes, create a patch
with 'stg new <name>' and add some description (can be modified at any
time with the 'refresh --edit' command). You make changes to the files
(or add/rm files) and save them (can be done for an indefinite number
of times) into the current patch with 'stg refresh'. This last command
creates a GIT commit object for the changes between the working tree
and the bottom of the patch (which can be the upstream HEAD if this is
the first patch).
You can create several patches with 'stg new'. A 'git log' command
would show the patches as individual commits. The advantage over a
normal SCM is that you can modify the patch and replace the commit
object with a new one.
To work on a given patch, make it current via the 'stg push/pop'
commands. Note that 'stg push' also allows patch re-ordering.
To pull the latest changes from the upstream respository, do a 'stg
pop -a' (at this point the tree is the same as the one when you last
pulled the remote changes), 'git pull', 'stg push -a'. You can get
conflicts for the latter command if there are overlapping changes or
the patch was modified by the gatekeeper before being merged. Fix the
conflicts, run 'stg resolved/stg refresh' and re-run 'stg push -a' for
the rest of the patches. The 'push' and the 'series' commands notify
you if the patch is empty so that it can safely be removed ('stg
delete <name>').
To send patches upstream (the 'mail' command is not available yet),
you can export the patches with 'stg export' and e-mail manually. You
can create your own template for the exported patch (to include
description, diffstats etc.). An temlate example is given in the
archive, just copy it to the .git/ directory.
Another way to send patches is to ask the gatekeeper to pull from your
tree. Run 'stg push' for all the patches you want to be merged and the
HEAD of your tree would contain the commit objects.
--
Catalin
^ permalink raw reply
* Re: arch 2.0 first source available (git related)
From: Petr Baudis @ 2005-07-09 11:39 UTC (permalink / raw)
To: Thomas Lord; +Cc: git
In-Reply-To: <1120867947.5882.2.camel@dev1.seyza.com>
Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter
where Thomas Lord <lord@emf.net> told me that...
> 2.0 is very much git influenced but it brings some (imo significant)
> improvements to the table.
Could you list some of the things interesting for us? What is the
benefit of a prereq graph compared to just having a single shared object
database? From the documentation, that's the only interesting thing I
noticed which is different from git (and things like artificially
limiting filename length to 256 characters).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Linus kernel tree corrupt?
From: Petr Baudis @ 2005-07-09 11:55 UTC (permalink / raw)
To: Russell King; +Cc: Tony Luck, Jon Smirl, git
In-Reply-To: <20050709114303.B2175@flint.arm.linux.org.uk>
Dear diary, on Sat, Jul 09, 2005 at 12:43:03PM CEST, I got a letter
where Russell King <rmk@arm.linux.org.uk> told me that...
> On Fri, Jul 08, 2005 at 10:06:09AM -0700, Tony Luck wrote:
> > 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).
>
> So does that mean we should ignore cogito's whinging about rsync being
> deprecated?
Yes, please do. I deprecated rsync a day before Linus "broke" http-pull.
It's un-deprecated again for now in the latest Cogito.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: What broke snapshots now?
From: Jeff Garzik @ 2005-07-09 13:37 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, git
In-Reply-To: <1120907336.8058.293.camel@baythorne.infradead.org>
David Woodhouse wrote:
> Does git on master.kernel.org need to be updated to handle packed
> objects?
Yes.
It's always fun when the on-disk format of the upstream 2.6.x kernel
repo changes without notice :/
Jeff
^ permalink raw reply
* Re: cogito Mac OS X compatibility
From: Martin Langhoff @ 2005-07-09 13:40 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42CF0D9F.8040909@gmail.com>
On 7/9/05, Bryan Larsen <bryan.larsen@gmail.com> wrote:
> On Mac OS X
It also uses on GNU xargs, and the xargs options aren't compatible
between GNU and BSD xargs.
Sad thing is, some of the dependencies, like xargs, aren't available
in fink, so you can build your toolchaing or boot into GNU/LinuxPPC.
Debian actually has git (cogito?) experimental packages.
cheers,
martin
^ permalink raw reply
* Re: arch 2.0 first source available (git related)
From: Thomas Lord @ 2005-07-09 14:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050709113942.GB26343@pasky.ji.cz>
On Sat, 2005-07-09 at 13:39 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 02:12:27AM CEST, I got a letter
> where Thomas Lord <lord@emf.net> told me that...
> > 2.0 is very much git influenced but it brings some (imo significant)
> > improvements to the table.
>
> Could you list some of the things interesting for us? What is the
> benefit of a prereq graph compared to just having a single shared object
> database? From the documentation, that's the only interesting thing I
> noticed which is different from git (and things like artificially
> limiting filename length to 256 characters).
Well, partly the statement about improvements was a hint to look
beyond the docs to the code but...
The prereq graph is, indeed, an improvement.
It:
* speeds up and simplifies blob-db GC
* vastly improves the possibilities for archive integrity
checking
* can be used for smart, streamy network mirroring of revisions
* allows people to commit the same tree multiple ways: e.g.,
once optimizing access for users who frequently read incremental
updates and a second time for users who only update at named
releases
* helps make the system securable (current code isn't yet) against
the possibility of multiple files with identical fingerprints but
different contents in the same or related trees
* helps in a variety of ways when it comes time to make `revc'
operable over a network -- committing to a remote archive.
Other advantageous (imo) changes from `git' not mentioned in the
original message:
* blobs do not have header lines
Git blobs all begin with a line of text declaring the "type"
and size of the blob. That doesn't increase database
verifiability significantly and I found no use for the headers.
Having the headers makes it needlessly complicated to translate
a file to or from a blob.
`revc' does not have blob headers.
* `revc' uses portable file formats
In working dirs, `git' stores binary files which are
endian, word-size, and compiler-environment specific.
`revc' stores some binary files too (for performance
and simplicity reasons) but uses only portable formats.
* `revc' is shaping up into much cleaner and more portable code
(at least compared to the last version of `git' I saw --
which was extremely *lucid* code but not terribly
clean and not even attempting to be portable.)
The list goes on and I don't promise to be picking the
most interesting items from it according to anybody's
particular metric of "interesting".
revc -- probably "strange yet familiar" to git hackers,
-t
^ permalink raw reply
* Re: qgit-0.7
From: Marco Costalba @ 2005-07-09 15:06 UTC (permalink / raw)
To: wd; +Cc: git
Wolfgang Denk ha scritto:
>Dear Marco,
>
>in message <20050709081512.33503.qmail@web26306.mail.ukl.yahoo.com> you wrote:
>
>>Here is qgit-0.7, a GUI git viewer.
>
>
>Sorry, but I cannot compile it on a Fedora Core 4 system:
>
>-> ./configure
>+scons was found, that's excellent+
>scons: Reading SConscript files ...
>-> make
>scons -Q
>g++ -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/lib64/qt-3.3/include -c -o src/annotate.o
src/annotate.cpp
>src/annotate.cpp: In member function `QStringList Annotate::processDiff(const
> QString&, QStringList&, const QString&)':
>src/annotate.cpp:378: error: jump to case label
>src/annotate.cpp:373: error: crosses initialization of `int num'
>src/annotate.cpp:387: error: jump to case label
>src/annotate.cpp:373: error: crosses initialization of `int num'
>src/annotate.cpp:401: error: jump to case label
>src/annotate.cpp:373: error: crosses initialization of `int num'
>scons: *** [src/annotate.o] Error 1
>make: *** [all] Error 2
>
>The following patch solves this problem:
>
>--- src/annotate.cpp.ORIG 2005-07-09 07:10:23.000000000 +0200
>+++ src/annotate.cpp 2005-07-09 16:05:09.556653902 +0200
>@@ -370,10 +370,12 @@
> char firstChar = line[0].latin1();
> switch (firstChar) {
> case '@':
>+ {
> int num = line.section(',', 1, 1). section('+', 1, 1).toInt();
> // diff lines start from 1, 0 is empty file,
> // instead QValueList::at() starts from 0
> cur = (num > 0) ? newAnn.at(num - 1) : newAnn.end();
>+ }
> break;
> case '+':
> if (cur != newAnn.end()) {
>
>
Thanks for your patch, applied.
What version og gcc you have?
Mine is gcc version 4.0.1 and I don't have this compile error (of course ;-) ).
I have cc'ed to git@vger.kernel.org in case someone else have the same problem.
>With this patch, I get a lot of build errors:
>
>QSettings: error creating /.qt
>QSettings: error creating /.qt
>QSettings: error creating /.qt
>QSettings: error creating /.qt
>QSettings: error creating /.qt
>QSettings::sync: filename is null/empty
>QSettings: error creating /.qt
>QSettings::sync: filename is null/empty
>QSettings: error creating /.qt
>QSettings::sync: filename is null/empty
>QSettings: error creating /.qt
>QSettings::sync: filename is null/empty
>QSettings: error creating /.qt
>QSettings::sync: filename is null/empty
>QSettings: error creating /.qt
>QSettings::sync: filename is null/empty
>...
>
>It links and seems to run, though.
>
It's a known issue, probably due to scons setup, but I am not so familiar with scons
to find a fix, in any case should be absolutely painless.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: What broke snapshots now?
From: Linus Torvalds @ 2005-07-09 16:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1120907336.8058.293.camel@baythorne.infradead.org>
On Sat, 9 Jul 2005, David Woodhouse wrote:
>
> Does git on master.kernel.org need to be updated to handle packed
> objects? See attached.
Yes, looks that way. Except it's not "git on master.kernel.org", it's "git
in your home directory", I suspect. I expressly held off packing the
kernel repo until git had been updated on kernel.org.
So while the regular git on kernel.org should already be up-to-date, you
have
PATH=/home/dwmw2/cogito:/usr/bin:/bin
in your script ;)
> Linus, please could you add the snapshot script to your regression
> testing? http://david.woodhou.se/git-snapshot.sh
None of the git-specific parts should have broken - you don't even do
anything strange there, I think we already have regression tests in git
for everything you use. But the fact that you had an old version is not
something I can do much about ;)
Linus
^ permalink raw reply
* Re: cogito Mac OS X compatibility
From: Sven Verdoolaege @ 2005-07-09 16:50 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42CF0D9F.8040909@gmail.com>
On Fri, Jul 08, 2005 at 07:34:55PM -0400, Bryan Larsen wrote:
> 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.
>
Sounds like you're missing "stat" from coreutils.
skimo
^ permalink raw reply
* Re: Linus kernel tree corrupt?
From: H. Peter Anvin @ 2005-07-09 18:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Russell King, Tony Luck, Jon Smirl, git
In-Reply-To: <20050709115530.GC26343@pasky.ji.cz>
Petr Baudis wrote:
>
> Yes, please do. I deprecated rsync a day before Linus "broke" http-pull.
> It's un-deprecated again for now in the latest Cogito.
>
Presumably for packed repos you want to drop the --ignore-existing
--whole-file options I assume?
Also, pulling with cogito-0.12:
cg-clone -s
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
I still get:
receiving file list ... done
master
sent 147 bytes received 863 bytes 2020.00 bytes/sec
total size is 41 speedup is 0.04
receiving file list ... done
progress: 1929 objects, 5796451 bytes, 100% done
pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.idx
pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack
sent 42599 bytes received 73373124 bytes 451789.06 bytes/sec
total size is 73178114 speedup is 1.00
receiving file list ... done
v2.6.11
v2.6.11-tree
v2.6.12
v2.6.12-rc2
v2.6.12-rc3
v2.6.12-rc4
v2.6.12-rc5
v2.6.12-rc6
v2.6.13-rc1
v2.6.13-rc2
sent 339 bytes received 1802 bytes 4282.00 bytes/sec
total size is 410 speedup is 0.19
Missing object of tag v2.6.11... different source (obsolete tag?)
Missing object of tag v2.6.11-tree... different source (obsolete tag?)
Missing object of tag v2.6.12... different source (obsolete tag?)
Missing object of tag v2.6.12-rc2... different source (obsolete tag?)
Missing object of tag v2.6.12-rc3... different source (obsolete tag?)
Missing object of tag v2.6.12-rc4... different source (obsolete tag?)
Missing object of tag v2.6.12-rc5... different source (obsolete tag?)
Missing object of tag v2.6.12-rc6... different source (obsolete tag?)
Missing object of tag v2.6.13-rc1... different source (obsolete tag?)
Missing object of tag v2.6.13-rc2... different source (obsolete tag?)
New branch: 0109fd37046de64e8459f8c4f4706df9ac7cc82c
Cloned (origin
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
available as branch "origin")
Cloned to ./ (origin
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
available as branch "origin")
Is the "missing objects" thing spurious?
-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