* git-applymbox: verify that index is clean
From: Linus Torvalds @ 2005-08-18 22:31 UTC (permalink / raw)
To: Junio C Hamano, Luck, Tony; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508181503200.3412@g5.osdl.org>
This makes git-applymbox verify that the index matches the current HEAD
before it starts applying patches.
Otherwise, you might have updated the index with unrelated changes, and
the first patch will commit not just the patch from the mbox, but also any
changes you had in your index.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
This was brough on by: Tony Luck's problem, which _might_ be due to index
file change contents that got committed together with a real patch. This
will make it much harder to make that particular mistake.
On Thu, 18 Aug 2005, Linus Torvalds wrote:
>
> (git-applymbox _does_ verify that the files that it patches are up-to-date
> in the index, but it does _not_ verify that the index matches the current
> HEAD. I guess I could add a sanity check for that...)
diff --git a/tools/git-applymbox b/tools/git-applymbox
--- a/tools/git-applymbox
+++ b/tools/git-applymbox
@@ -18,6 +18,8 @@
## use a Signoff_file, because applypatch wants to append the sign-off
## message to msg-clean every time it is run.
+. git-sh-setup-script || die "Not a git archive"
+
keep_subject= query_apply= continue= resume=t
while case "$#" in 0) break ;; esac
do
@@ -39,6 +41,12 @@ case "$continue" in
shift
esac
+files=$(git-diff-cache --cached --name-only HEAD) || exit
+if [ "$files" ]; then
+ echo "Dirty index: cannot apply patches (dirty: $files)" >&2
+ exit 1
+fi
+
case "$query_apply" in
t) touch .dotest/.query_apply
esac
^ permalink raw reply
* Re: git-whatchanged -p anomoly?
From: Junio C Hamano @ 2005-08-18 22:13 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <200508182049.j7IKn7TA010456@agluck-lia64.sc.intel.com>
"Luck, Tony" <tony.luck@intel.com> writes:
> $ git-whatchanged -p test ^linus | diffstat -p1
> $ git-diff-tree -p linus test | diffstat -p1
git-whatchanged internally uses git-rev-list which skips merge
commits. You need '-m' to cause it not to.
$ git-whatchanged -m -p linus..test | diffstat -p1
would still not _match_ "git-diff-tree -p linus test | diffstat
-p1" output because conflict-resolving merges inevitably causes
the same file to be touched twice (hence diffstat shows patches
for the same fime twice, adding up the count of the changes), so
in practice, my "use -m if you want to see merges" advice would
not be much useful if you want to _count_ lines using diffstat.
For example, one of the files you had trouble with are touched
by the following commits; only the last one is a non-merge and
that is what you get when you do not give -m to whatchanged:
$ git-whatchanged -m --pretty=oneline test ^linus \
-p Documentation/acpi-hotkey.txt
diff-tree 75304b938dcc2cb89c2bb1174a92ffc76520a899 (from 470ceb05d9a2b4d61c19fac615a79e56e8401565)
Pull ngam-maule-steiner into test branch
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,3 +33,6 @@ The result of the execution of this aml
attached to /proc/acpi/hotkey/poll_method, which is dnyamically
created. Please use command "cat /proc/acpi/hotkey/polling_method"
to retrieve it.
+
+Note: Use cmdline "acpi_generic_hotkey" to over-ride
+loading any platform specific drivers.
diff-tree 2dbff4d454d3ee733f120ad531560a734a6e39d6 (from 715caa83e762c86241ae4450693bb969d03027c4)
Auto-update from upstream
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,3 +33,6 @@ The result of the execution of this aml
attached to /proc/acpi/hotkey/poll_method, which is dnyamically
created. Please use command "cat /proc/acpi/hotkey/polling_method"
to retrieve it.
+
+Note: Use cmdline "acpi_generic_hotkey" to over-ride
+loading any platform specific drivers.
diff-tree f812175c8007fdb614833830ca107062df2845dd (from c1ffb910f7a4e1e79d462bb359067d97ad1a8a25)
Pull prarit-bus-sysdata into test branch
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,6 +33,3 @@ The result of the execution of this aml
attached to /proc/acpi/hotkey/poll_method, which is dnyamically
created. Please use command "cat /proc/acpi/hotkey/polling_method"
to retrieve it.
-
-Note: Use cmdline "acpi_generic_hotkey" to over-ride
-loading any platform specific drivers.
diff-tree b63d6e09b432e6873d072a767c87218f8e73e66c (from 12aaa0855b39b5464db953fedf399fa91ee365ed)
[IA64, X86_64] fix swiotlb sizing
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
--- a/Documentation/acpi-hotkey.txt
+++ b/Documentation/acpi-hotkey.txt
@@ -33,6 +33,3 @@ The result of the execution of this aml
attached to /proc/acpi/hotkey/poll_method, which is dnyamically
created. Please use command "cat /proc/acpi/hotkey/polling_method"
to retrieve it.
-
-Note: Use cmdline "acpi_generic_hotkey" to over-ride
-loading any platform specific drivers.
^ permalink raw reply
* Re: git-whatchanged -p anomoly?
From: Linus Torvalds @ 2005-08-18 22:10 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <200508182049.j7IKn7TA010456@agluck-lia64.sc.intel.com>
On Thu, 18 Aug 2005, Luck, Tony wrote:
>
> The spurious changes reported by "git-whatchanged -p" are:
>
> > Documentation/acpi-hotkey.txt | 3
> > Documentation/kernel-parameters.txt | 5
> > drivers/acpi/osl.c | 6
> > fs/jfs/inode.c | 4
Ehh. These are all from:
Author: Alex Williamson <alex.williamson@hp.com>
[IA64, X86_64] fix swiotlb sizing
in commit b63d6e09b432e6873d072a767c87218f8e73e66c.
And you've signed off on it.
Do a
git-diff-tree -p --pretty b63d6e09b432e6873d072a767c87218f8e73e66c | less -S
to see it in all its glory.
Now, I suspect you didn't mean to commit that thing: it really looks like
you've mixed up your patches somehow, because the commit message seems to
match only a very small portion of the patch.
Did you perhaps have a failed merge or something that was in your index
when you applied that patch? If you have a dirty index when you do
"git-applymbox", it the commit done as part of the applymbox might commit
other state too.
(git-applymbox _does_ verify that the files that it patches are up-to-date
in the index, but it does _not_ verify that the index matches the current
HEAD. I guess I could add a sanity check for that...)
> Is this a bug, or am I just confused about how "git-whatchanged" works?
It's definitely not a bug in git-whatchanged, and I don't think you're
confused about how git-whatchanged is supposed to work. But I think you've
committed a bad patch.
Linus
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Matt Draisey @ 2005-08-18 21:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git-list
In-Reply-To: <7vslx8thx9.fsf@assigned-by-dhcp.cox.net>
Thanks for committing my one-character patch. In the commit message you
said
> Come to think of
> it, maybe we should disallow symlink inside .git/refs hierarchy;
> we update the files there by creat/rename pair, so having
> symlinks would not work anyway when you do anything that would
> update them.]
I agree, linking at the file level makes no sense --- create/rename
pairs will clobber symlinked files (as they would for hardlinked files).
If you accept their use at all, symlinked directories are the only way
to go.
The alternatives to symlinked directories are:
(1) adding a command line option to fsck that supplies a path to an
external refs directory
(1a) adding a subtool to create a commandline list of sha from a
supplied path to an external refs directory
(2) adding an environment variable to do the same
(3) adding a .git configuration file which contains a path --- this is
just a userspace symlink
(4) create a monster (refcounting objects?) (true cross-references?)
(conservative garbage collectors that scan your entire hard disk for
potential references)
(I believe the same arguments hold for the pulling code as for fsck)
Case (1) is easy to implement. (I whipped up a working patch yesterday)
The hardest part is thinking up a good name for the command line
argument. Case (1a) is too ugly. Both of these cases place a
considerable burden on the user, and require some Porcelain work. Case
(2) makes sense but is too intrusive for me to contemplate. I defer to
a core developer. Case (3) offers no advantages over a symlinked
directory under refs. Case (4) is probably patented by Microsoft.
I like symlinks for their simplicity, and that they work now. Otherwise
I am a really only submitting a feature request.
Matt
^ permalink raw reply
* Re: Subject: [PATCH] Updates to glossary
From: Johannes Schindelin @ 2005-08-18 21:36 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0508181702051.23242@iabervon.org>
Hi,
On Thu, 18 Aug 2005, Daniel Barkalow wrote:
> On Thu, 18 Aug 2005, Johannes Schindelin wrote:
>
> > tree object::
> > - An object containing a list of blob and/or tree objects.
> > - (A tree usually corresponds to a directory without
> > - subdirectories).
> > + An object containing a list of file names and modes along with refs
> > + to the associated blob and/or tree objects. A tree object is
> > + equivalent to a directory.
>
> Actually, it contains object names, not refs, to be completely precise.
> (refs would imply an additional indirection.)
Agree.
Dscho
^ permalink raw reply
* Re: Subject: [PATCH] Updates to glossary
From: Johannes Schindelin @ 2005-08-18 21:35 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.08.18.21.15.02.716698@smurf.noris.de>
Hi,
On Thu, 18 Aug 2005, Matthias Urlichs wrote:
> Hi, Johannes Schindelin wrote:
>
> > Subject: Subject: [PATCH] Updates to glossary
>
> Something is stuttering here -- one "Subject:" is quite sufficient.
Subject! Subject! Subject! ;-)
My bad.
Dscho
^ permalink raw reply
* Re: Subject: [PATCH] Updates to glossary
From: Matthias Urlichs @ 2005-08-18 21:15 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0508182117160.6210@wgmdd8.biozentrum.uni-wuerzburg.de>
Hi, Johannes Schindelin wrote:
> Subject: Subject: [PATCH] Updates to glossary
Something is stuttering here -- one "Subject:" is quite sufficient.
--
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
- -
Harris's Lament:
All the good ones are taken.
^ permalink raw reply
* Re: Subject: [PATCH] Updates to glossary
From: Daniel Barkalow @ 2005-08-18 21:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0508182117160.6210@wgmdd8.biozentrum.uni-wuerzburg.de>
On Thu, 18 Aug 2005, Johannes Schindelin wrote:
> tree object::
> - An object containing a list of blob and/or tree objects.
> - (A tree usually corresponds to a directory without
> - subdirectories).
> + An object containing a list of file names and modes along with refs
> + to the associated blob and/or tree objects. A tree object is
> + equivalent to a directory.
Actually, it contains object names, not refs, to be completely precise.
(refs would imply an additional indirection.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* git-whatchanged -p anomoly?
From: Luck, Tony @ 2005-08-18 20:49 UTC (permalink / raw)
To: git
Yesterday I was all happy ... Linus pulled a couple of changes from
my tree, and after I did a pull back from his tree into my "linus"
tracking branch, my status scripts correctly identified the branches
that I'd been using to track those changes as being no longer needed.
But this morning I ran another one of my status scripts that does
$ git-whatchanged -p test ^linus | diffstat -p1
and was surprised when it reported changes in 10 files that I knew
I hadn't touched (the other 18 files it reported looked correct).
So I ran:
$ git-whatchanged test ^linus | git-shortlog
and this just reported the changesets that I expected.
$ git-diff-tree -p linus test | diffstat -p1
shows what I expect to see.
The current heads of the two branches are:
linus=30d5b64b63fa69af31b2cba32e6d71d68526eec9
test=0e595ad82db1b42d631e581630eb3fbeebb3c285
my tree is at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
The spurious changes reported by "git-whatchanged -p" are:
> Documentation/acpi-hotkey.txt | 3
> Documentation/kernel-parameters.txt | 5
> drivers/acpi/osl.c | 6
> fs/jfs/inode.c | 4
> fs/jfs/jfs_logmgr.c | 36 -
> fs/jfs/jfs_logmgr.h | 2
> fs/jfs/jfs_txnmgr.c | 12
> fs/jfs/super.c | 4
> include/asm-i386/processor.h | 2
> include/asm-x86_64/processor.h | 2
Is this a bug, or am I just confused about how "git-whatchanged" works?
-Tony
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Linus Torvalds @ 2005-08-18 20:07 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, git
In-Reply-To: <20050818172646.GA18459@mars.ravnborg.org>
On Thu, 18 Aug 2005, Sam Ravnborg wrote:
>
> I almost always handedit my mails and I find myself forgetting to add
> "Signed-off-by" from time to time.
> Is there a simple way to implment a trigger that can check that _I_
> signed off the patch before applying it?
Well, Junio has been talking about adding commit hooks. I don't think
that's been done. The idea being that you could verify that the thing
you're committing follows certain rules (no bad whitespace added in the
diff, sign-offs in the messages, whatever).
That said, git-applypatch (which is what git-applymbox ends up calling)
does not use the general "git commit" script. So it would have to have its
own hook. The script is pretty easy to read, though: just look at
git-applypatch, and notice that the last stages are:
...
git-apply --index $PATCHFILE || exit 1
tree=$(git-write-tree) || exit 1
echo Wrote tree $tree
commit=$(git-commit-tree $tree -p $(cat .git/HEAD) < $final) || exit 1
echo Committed: $commit
echo $commit > .git/HEAD
and that just before this thing you could easily add some sanity checking
by hand. The commit message at that point is in the "$final" file, and the
patch is obviously in $PATCHFILE, so you can verify either of those to
your hearts content.
The only question is what the hook/trigger should look like. just put
something like
[ -x .git/hooks/applypatch-hook ] &&
.git/hooks/applypatch-hook "$tree" "$PATCHFILE" || exit
at the line before that "git-apply" perhaps? Then, you could install your
own applypatch hook which looks at the message or the patch?
Linus
^ permalink raw reply
* [RFC] Stgit - patch history / add extra parents
From: Jan Veldeman @ 2005-08-18 19:57 UTC (permalink / raw)
To: git
Hi,
I like stgit very much, but I feel there is still something missing:
stgit is very handy when you use it for patches which should be pushed to
mainline rather quickly. But for pacthes which won't be pushed immediately
to mainline, it would be usefull to have a history of the patches itself.
The patch below, together with the following script could be used to
make snapshots of the patch stack (I call it freeze, as I thought snapshot
was already going to be used for something else):
#!/bin/bash
# stg-freeze
set -ex
top=$(stg top)
# Freeze the current stack
branchname=$(basename $(readlink .git/HEAD))
while read patch
do
cp .git/patches/$branchname/$patch/top .git/patches/$branchname/$patch/parent
done < .git/patches/$branchname/applied
# Refresh the patches
stg pop -a
stg push -t $top
# end stg-freeze
Note: this is a proof of concept, when/if it would be incorporated, it
should be implemented in stgit itself, and a bit more efficient, especially
the refreshing of the patches ;-)
This is how it works: when not doing anything, stgit works as normal.
Once stg-freeze is called, it creates .git/patches/$branchname/$patch/parent
which contains the SHA1 id of the "frozen" patch. By refreshing the stack,
all patches now include the corresponding frozen patch as a parent.
The following script is a test I use. Add stg-freeze to the path and
source/run it in an empty directory, view with gitk afterwards:
###
echo "Initial commit" | cg-init
stg init
stg new a -mpatch-1
echo a > a
stg add a
stg refresh -mpatch-1
stg new b -mpatch-2
echo b > b
stg add b
stg refresh -mpatch-2
stg-freeze
stg pop
echo a2 >> a
stg refresh -mpatch-1-update
stg push
stg-freeze
echo b2 >> b
stg refresh -mpatch-2-update
stg pop -a
echo c > c
cg-add c
cg-commit -m"Mainline advance"
stg push -a
stg-freeze
stg pop -a
echo d > d
cg-add d
cg-commit -m"Mainline advance 2"
stg push -a
stg pop -a
echo e > e
cg-add e
cg-commit -m"Mainline advance 3"
stg push -a
###
Comments/remarks are very welcome.
---
stgit/stack.py | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -140,6 +140,13 @@ class Patch:
elif os.path.isfile(fname):
os.remove(fname)
+ def get_parents(self):
+ parents=[]
+ if (self.__get_field('parent') != None):
+ parents = parents + [self.__get_field('parent')]
+ parents = parents + [ self.get_bottom() ]
+ return parents
+
def get_bottom(self):
return self.__get_field('bottom')
@@ -362,7 +369,7 @@ class Series:
if not committer_email:
committer_email = patch.get_commemail()
- commit_id = git.commit(message = descr, parents = [patch.get_bottom()],
+ commit_id = git.commit(message = descr, parents = patch.get_parents(),
allowempty = True,
author_name = author_name,
author_email = author_email,
^ permalink raw reply
* Subject: [PATCH] Updates to glossary
From: Johannes Schindelin @ 2005-08-18 19:17 UTC (permalink / raw)
To: Junio C Hamano, git
Changes to the descriptions of tree and tag objects, a link for ent, and
descriptions for rewind, rebase and core git were added.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/glossary.txt | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
83d69aaac371160ea0da0a6de6c9898c8f6915b2
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -26,9 +26,9 @@ blob object::
Untyped object, e.g. the contents of a file.
tree object::
- An object containing a list of blob and/or tree objects.
- (A tree usually corresponds to a directory without
- subdirectories).
+ An object containing a list of file names and modes along with refs
+ to the associated blob and/or tree objects. A tree object is
+ equivalent to a directory.
tree::
Either a working tree, or a tree object together with the
@@ -118,11 +118,14 @@ tree-ish::
tag object pointing to a tag or commit or tree object.
ent::
- Favorite synonym to "tree-ish" by some total geeks.
+ Favorite synonym to "tree-ish" by some total geeks. See
+ http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth
+ explanation.
tag object::
- An object containing a ref pointing to another object. It can
- contain a (PGP) signature, in which case it is called "signed
+ An object containing a ref pointing to another object, which can
+ contain a message just like a commit object. It can also
+ contain a (PGP) signature, in which case it is called a "signed
tag object".
tag::
@@ -143,6 +146,15 @@ resolve::
The action of fixing up manually what a failed automatic merge
left behind.
+rewind::
+ To throw away part of the development, i.e. to assign the head to
+ an earlier revision.
+
+rebase::
+ To clean a branch by starting from the head of the main line of
+ development ("master"), and reapply the (possibly cherry-picked)
+ changes from that branch.
+
repository::
A collection of refs together with an object database containing
all objects, which are reachable from the refs, possibly accompanied
@@ -196,6 +208,10 @@ pack index::
The list of identifiers, and other information, of the objects in a
pack, to assist in efficiently accessing the contents of a pack.
+core git::
+ Fundamental data structures and utilities of git. Exposes only
+ limited source code management tools.
+
plumbing::
Cute name for core git.
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Sam Ravnborg @ 2005-08-18 17:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508170830050.3553@g5.osdl.org>
> (Also, with proper "Signed-off-by:" lines it's also always clear that
> there were other people involved, and that the author of the patch is
> different from the person who applied it).
I almost always handedit my mails and I find myself forgetting to add
"Signed-off-by" from time to time.
Is there a simple way to implment a trigger that can check that _I_
signed off the patch before applying it?
I prefer to add it myself rather than to have it added automatically -
but mayve thats you me being a bit mistrusting.
Btw. I'm a Cogito user if that makes a difference.
The only git- command I use today is git-applymbox.
Sam
^ permalink raw reply
* Re: [PATCH] gitweb - Use <description> instead of <content:encoded>.
From: Yasushi SHOJI @ 2005-08-18 16:52 UTC (permalink / raw)
To: git
In-Reply-To: <20050818153607.GX11882MdfPADPa@garage.linux.student.kuleuven.ac.be>
At Thu, 18 Aug 2005 17:36:07 +0200,
Sven Verdoolaege wrote:
>
> On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote:
> > Use <description> instead of <content:encoded>.
> >
>
> Hmm.... in snownews this gets displayed as "Use instead of .".
> (http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=rss)
>
> Is that a problem with snownews or with gitweb ?
we are not sure. As Kay said, we need to find out _authoritative_
information for this.
regards,
--
yashi
^ permalink raw reply
* [PATCH] updates for Documentation/howto/using-topic-branches.txt
From: Luck, Tony @ 2005-08-18 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Small fix (use "git branch" to make branches, rather than "git checkout -b").
Optimization for trivial patches (apply to release and merge to test).
Three sample scripts appended.
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -70,8 +70,8 @@ them too:
Now create the branches in which you are going to work, these start
out at the current tip of the linus branch.
- $ git checkout -b test linus
- $ git checkout -b release linus
+ $ git branch test linus
+ $ git branch release linus
These can be easily kept up to date by merging from the "linus" branch:
@@ -144,6 +144,11 @@ is empty. At this point the branch can
$ rm .git/refs/heads/branchname
+Some changes are so trivial that it is not necessary to create a separate
+branch and then merge into each of the test and release branches. For
+these changes, just apply directly to the "release" branch, and then
+merge that into the "test" branch.
+
To create diffstat and shortlog summaries of changes to include in a "please
pull" request to Linus you can use:
@@ -151,3 +156,109 @@ pull" request to Linus you can use:
and
$ git-whatchanged release ^linus | git-shortlog
+
+Here are some of the scripts that I use to simplify all this even further.
+
+==== update script ====
+# Update a branch in my GIT tree. If the branch to be updated
+# is "linus", then pull from kernel.org. Otherwise merge local
+# linus branch into test|release branch
+
+case "$1" in
+test|release)
+ git checkout $1 && git resolve $1 linus "Auto-update from upstream"
+ ;;
+linus)
+ before=$(cat .git/HEAD)
+ git checkout linus && git pull linus
+ after=$(cat .git/HEAD)
+ if [ $before != $after ]
+ then
+ git-whatchanged $after ^$before | git-shortlog
+ fi
+ ;;
+*)
+ echo "Usage: $0 linus|test|release" 1>&2
+ exit 1
+ ;;
+esac
+
+==== merge script ====
+# Merge a branch into either the test or release branch
+
+pname=$0
+
+usage()
+{
+ echo "Usage: $pname branch test|release" 1>&2
+ exit 1
+}
+
+if [ ! -f .git/refs/heads/"$1" ]
+then
+ echo "Can't see branch <$1>" 1>&2
+ usage
+fi
+
+case "$2" in
+test|release)
+ if [ $(git-rev-list $1 ^$2 | wc -c) -eq 0 ]
+ then
+ echo $1 already merged into $2 1>&2
+ exit 1
+ fi
+ git checkout $2 && git resolve $2 $1 "Pull $1 into $2 branch"
+ ;;
+*)
+ usage
+ ;;
+esac
+
+==== status script ====
+# report on status of my ia64 GIT tree
+
+gb=$(tput setab 2)
+rb=$(tput setab 1)
+restore=$(tput setab 9)
+
+if [ `git-rev-tree release ^test | wc -c` -gt 0 ]
+then
+ echo $rb Warning: commits in release that are not in test $restore
+ git-whatchanged release ^test
+fi
+
+for branch in `ls .git/refs/heads`
+do
+ if [ $branch = linus -o $branch = test -o $branch = release ]
+ then
+ continue
+ fi
+
+ echo -n $gb ======= $branch ====== $restore " "
+ status=
+ for ref in test release linus
+ do
+ if [ `git-rev-tree $branch ^$ref | wc -c` -gt 0 ]
+ then
+ status=$status${ref:0:1}
+ fi
+ done
+ case $status in
+ trl)
+ echo $rb Need to pull into test $restore
+ ;;
+ rl)
+ echo "In test"
+ ;;
+ l)
+ echo "Waiting for linus"
+ ;;
+ "")
+ echo $rb All done $restore
+ ;;
+ *)
+ echo $rb "<$status>" $restore
+ ;;
+ esac
+ git-whatchanged $branch ^linus | git-shortlog
+done
^ permalink raw reply
* Re: [PATCH] gitweb - Use <description> instead of <content:encoded>.
From: Yasushi SHOJI @ 2005-08-18 16:26 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <20050818160109.GA7237@vrfy.org>
At Thu, 18 Aug 2005 18:01:09 +0200,
Kay Sievers wrote:
>
> On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote:
> > Use <description> instead of <content:encoded>.
> >
> > RSS 2.0 Specification doesn't have <content:encoded>.
> > see http://blogs.law.harvard.edu/tech/rss
>
> See here:
> http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
>
> The <description> element is designed to contain plain text ONLY. When
> the content of your items contains anything other than plain text i.e.
> HTML or XHTML the <content:encoded> element should be used.
>
> Hmm, there was a request to change it to "encoded" and the mentioned page
> sounded reasonable to me. I will happily change it to the "correct"
> format, if you provide _authoritative_ information that we can trust.
hmm... I'm not an rss guy. so not sure for anything.
at least, the link you gave me points to the rss 2.0 spec site I put
in the log as "RSS v2.0". that can be seen as "more trust'able"
also, in the rss 2.0 spec site, you can find 2.0 sample under "Sapmple
files", which contain _escaped tag_ in <description>.
that's all I can say :< can any one help?
> "It works in XY-reader" does not count. :)
agreed.
--
yashi
^ permalink raw reply
* Re: [PATCH] gitweb - Add <author> and <guid>.
From: Kay Sievers @ 2005-08-18 16:26 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87k6ijwbk8.wl@mail2.atmark-techno.com>
On Thu, Aug 18, 2005 at 11:43:03PM +0900, Yasushi SHOJI wrote:
> Hi all,
>
> with this patch and the privious one I just sent, you can run a pretty
> neat blog site with rss feed for geeks ;)
>
> one missing feature is the picture tag Junio asked a while ago ;P
>
> yashi
> ----
> Add <author> and <guid>.
>
> From http://blogs.law.harvard.edu/tech/rss
> author - Email address of the author of the item.
> guid - A string that uniquely identifies the item.
Next version will have it. Thanks for the patch.
Kay
^ permalink raw reply
* Re: [PATCH] gitweb - Use <description> instead of <content:encoded>.
From: Kay Sievers @ 2005-08-18 16:01 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87ll2zwc4u.wl@mail2.atmark-techno.com>
On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote:
> Use <description> instead of <content:encoded>.
>
> RSS 2.0 Specification doesn't have <content:encoded>.
> see http://blogs.law.harvard.edu/tech/rss
See here:
http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ
The <description> element is designed to contain plain text ONLY. When
the content of your items contains anything other than plain text i.e.
HTML or XHTML the <content:encoded> element should be used.
Hmm, there was a request to change it to "encoded" and the mentioned page
sounded reasonable to me. I will happily change it to the "correct"
format, if you provide _authoritative_ information that we can trust.
"It works in XY-reader" does not count. :)
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH] gitweb - Use <description> instead of <content:encoded>.
From: Sven Verdoolaege @ 2005-08-18 15:36 UTC (permalink / raw)
To: Yasushi SHOJI; +Cc: git
In-Reply-To: <87ll2zwc4u.wl@mail2.atmark-techno.com>
On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote:
> Use <description> instead of <content:encoded>.
>
Hmm.... in snownews this gets displayed as "Use instead of .".
(http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=rss)
Is that a problem with snownews or with gitweb ?
skimo
^ permalink raw reply
* [PATCH] Add Makefile target glossary.html
From: Johannes Schindelin @ 2005-08-18 15:28 UTC (permalink / raw)
To: Junio C Hamano, git
This also includes a script which does the sorting, and introduces
hyperlinks for every described term.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/Makefile | 7 +++-
Documentation/sort_glossary.pl | 70 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+), 1 deletions(-)
create mode 100644 Documentation/sort_glossary.pl
a080898e91dce96c5bac6f0527236e37aeedd156
diff --git a/Documentation/Makefile b/Documentation/Makefile
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,7 +1,7 @@
MAN1_TXT=$(wildcard git-*.txt)
MAN7_TXT=git.txt
-DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
+DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT)) glossary.html
DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT))
@@ -54,3 +54,8 @@ clean:
%.xml : %.txt
asciidoc -b docbook -d manpage $<
+glossary.html : glossary.txt sort_glossary.pl
+ cat $< | \
+ perl sort_glossary.pl | \
+ asciidoc -b xhtml11 - > glossary.html
+
diff --git a/Documentation/sort_glossary.pl b/Documentation/sort_glossary.pl
new file mode 100644
--- /dev/null
+++ b/Documentation/sort_glossary.pl
@@ -0,0 +1,70 @@
+#!/usr/bin/perl
+
+%terms=();
+
+while(<>) {
+ if(/^(\S.*)::$/) {
+ my $term=$1;
+ if(defined($terms{$term})) {
+ die "$1 defined twice\n";
+ }
+ $terms{$term}="";
+ LOOP: while(<>) {
+ if(/^$/) {
+ last LOOP;
+ }
+ if(/^ \S/) {
+ $terms{$term}.=$_;
+ } else {
+ die "Error 1: $_";
+ }
+ }
+ }
+}
+
+sub format_tab_80 ($) {
+ my $text=$_[0];
+ my $result="";
+ $text=~s/\s+/ /g;
+ $text=~s/^\s+//;
+ while($text=~/^(.{1,72})(|\s+(\S.*)?)$/) {
+ $result.=" ".$1."\n";
+ $text=$3;
+ }
+ return $result;
+}
+
+sub no_spaces ($) {
+ my $result=$_[0];
+ $result=~tr/ /_/;
+ return $result;
+}
+
+print 'GIT Glossary
+============
+Aug 2005
+
+This list is sorted alphabetically:
+
+';
+
+@keys=sort {uc($a) cmp uc($b)} keys %terms;
+$pattern='(\b'.join('\b|\b',reverse @keys).'\b)';
+foreach $key (@keys) {
+ $terms{$key}=~s/$pattern/sprintf "<<ref_".no_spaces($1).",$1>>";/eg;
+ print '[[ref_'.no_spaces($key).']]'.$key."::\n"
+ .format_tab_80($terms{$key})."\n";
+}
+
+print '
+
+Author
+------
+Written by Johannes Schindelin <Johannes.Schindelin@gmx.de> and
+the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the link:git.html[git] suite
+';
+
^ permalink raw reply
* cg-help question
From: Kumar Gala @ 2005-08-18 14:48 UTC (permalink / raw)
To: git
cg-help has the following in it
print_command_listing()
{
for command in "$@"; do
[ -f "$command" -a ! -L "$command" ] || continue
cmdname=$(basename $command)
...
}
I was wondering what the [ -f "$command" -o ! -L "$command" ] is
trying to test for. In my install the cg-commands are actually
symlinks. And this test breaks cg-help from reporting the command
list properly.
thanks
- kumar
^ permalink raw reply
* [PATCH] gitweb - Add <author> and <guid>.
From: Yasushi SHOJI @ 2005-08-18 14:43 UTC (permalink / raw)
To: git
Hi all,
with this patch and the privious one I just sent, you can run a pretty
neat blog site with rss feed for geeks ;)
one missing feature is the picture tag Junio asked a while ago ;P
yashi
----
Add <author> and <guid>.
>From http://blogs.law.harvard.edu/tech/rss
author - Email address of the author of the item.
guid - A string that uniquely identifies the item.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
gitweb.cgi | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
0a477312bf2975cf3240d3cf107ff7ac2e32049a
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -1424,7 +1424,9 @@ sub git_rss {
"<title>" .
sprintf("%d %s %02d:%02d", $cd{'mday'}, $cd{'month'}, $cd{'hour'}, $cd{'minute'}) . " - " . escapeHTML($co{'title'}) .
"</title>\n" .
+ "<author>" . escapeHTML($co{'author'}) . "</author>\n" .
"<pubDate>$cd{'rfc2822'}</pubDate>\n" .
+ "<guid isPermaLink=\"true\">" . escapeHTML("$my_url?p=$project;a=commit;h=$commit") . "</guid>\n" .
"<link>" . escapeHTML("$my_url?p=$project;a=commit;h=$commit") . "</link>\n" .
"<description>" .
"<![CDATA[\n";
^ permalink raw reply
* [PATCH] gitweb - Use <description> instead of <content:encoded>.
From: Yasushi SHOJI @ 2005-08-18 14:30 UTC (permalink / raw)
To: git
Use <description> instead of <content:encoded>.
RSS 2.0 Specification doesn't have <content:encoded>.
see http://blogs.law.harvard.edu/tech/rss
I've tested this with Mozilla Thunderbird version 1.0.6 (20050802),
and seems to be working well.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
gitweb.cgi | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
8a489f354a5412e44ddaf7443aaecb47a81167f8
diff --git a/gitweb.cgi b/gitweb.cgi
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -1426,8 +1426,7 @@ sub git_rss {
"</title>\n" .
"<pubDate>$cd{'rfc2822'}</pubDate>\n" .
"<link>" . escapeHTML("$my_url?p=$project;a=commit;h=$commit") . "</link>\n" .
- "<description>" . escapeHTML($co{'title'}) . "</description>\n" .
- "<content:encoded>" .
+ "<description>" .
"<![CDATA[\n";
my $comment = $co{'comment'};
foreach my $line (@$comment) {
@@ -1442,7 +1441,7 @@ sub git_rss {
print "$file<br/>\n";
}
print "]]>\n" .
- "</content:encoded>\n" .
+ "</description>\n" .
"</item>\n";
}
print "</channel></rss>";
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Catalin Marinas @ 2005-08-18 13:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050818133411.15529.qmail@web26306.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> wrote:
> I was thinking at two different kind of workflow, one were you are
> tracking a remote repository ( Linux kernel project like ) and one
> as single developer with both stable and develop lines ( qgit or
> StGIT ;-) projects like ).
There is another option for the 2nd case, where you maintain both both
stable and development. You could use 'git push' to the stable
repository (actually, more like a mirror) and make the
StGIT-maintained repository track the changes from the stable one and
just update it with 'stg pull'
--
Catalin
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-18 13:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Catalin Marinas wrote:
>>
>>If I uderstand correctly you never commit patches from StGIT stack directly
>>in your base git repository, in this example git HEAD, but you always round
>>trip to MAIN.
>
When I say 'you always round trip to MAIN', I mean you send patches
upstream and someone commits to MAIN, then you pull from MAIN.
Sorry if it was not clear.
>
>One usually doesn't maintain MAIN. That's an example for the Linux
>kernel development where you can't control what get merged into MAIN.
>
>There is a bit of confusion here since you said in a previous e-mail
>that more people can commit to the stable branch. In this case, you
>would need a separate repository for stable with a maintainer pulling
>changes from others.
>
When I said 'more people can commit to the stable branch' I meant more
people sends patches to a mantainer that commits the patches in a stable branch.
Sorry, peraphs also this was not clearly expressed.
>>Then you don't have two git repository: HEAD and MAIN
>>
>>Infact there is only one git repository, MAIN, cloned on your box
>>and called HEAD and with a StGIT stack added on top.
>
>
>The StGIT usage idea is that you only know what patches you have on
>top of a main repository. Since you expect your patches to be merged
>upstream or just updated every time the main repository changes, it
>might not make sense to commit the patches onto the base.
>
Yes, you better explained what I was badly trying to say before.
>
>I need a bit more clarification about your work flow.
>
I was thinking at two different kind of workflow, one were you are tracking a
remote repository ( Linux kernel project like ) and one as single developer with
both stable and develop lines ( qgit or StGIT ;-) projects like ).
You clarified me for both cases.
Thanks
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ 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