Re: Questions on 'cvs migration guide''
On 8/19/05, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > And yet another question: the teammember who is pulling must 'switch' > > the merging repo to the right branch, pull from the corresponding > > remote repos of each teammember, and push to the public view of the > > repo. Is that right? > > .. yes. Or alternatively, just keep the repo at that branch (and if such a > person works on multiple branches, he/she can thus just keep multiple > repos). I'm keen on keeping my 'merge & publish' step in a single repo that has all the 'team' branches. The person running this repo will probably actually code in separate repos, and merge in there too. Right now I'm switching 'heads' (I'm getting used to cogito's use of 'branch' for 'remote head') using this quick'n'dirty bit of shell: #!/bin/bash HEADNAME=$1 if [ -e .git/refs/heads/$HEADNAME ]; then cd .git/ ln -s -f .git/refs/heads/$HEADNAME HEAD cd .. cg-reset cg-restore -f fi; but I want to prevent the action if the checkout is 'dirty'. Is there any way to check whether cg-diff thinks anything has changed? cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Questions on 'cvs migration guide''
On Fri, 19 Aug 2005, Martin Langhoff wrote: > > In the section 'Emulating CVS behaviour', where the team setup is > described with a team 'merger'. What is not clear is how to deal with > project-wide branches. Should they be created in the master repo, and > everyone clone a new repo from it? Just make them another branch in the master repo. Whether people will clone a whole new repo for it, or have just one repo and switch between local branches in their own local (single) repo is their personal choice. Some people may well prefer to have all different branches checked out in different places (ie have one repository per branch) others may prefer to work with one repository and just switch. > And yet another question: the teammember who is pulling must 'switch' > the merging repo to the right branch, pull from the corresponding > remote repos of each teammember, and push to the public view of the > repo. Is that right? .. yes. Or alternatively, just keep the repo at that branch (and if such a person works on multiple branches, he/she can thus just keep multiple repos). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Merge conflicts as .rej .orig files
On Fri, 19 Aug 2005, Martin Langhoff wrote: > > Is there a way to convince cogito/git to leave reject files around? Nope. Git just doesn't deal in patches. There's never any patch rejects: there are just two source files that get merged. The ".orig" and ".rej" things are signs of patch-based systems. I'm sure you could fake it, but I'm also sure that there's an emacs mode for the "merge" style diffs. It is, after all, what CVS and RCS have used, so I'd expect that there be tons of support for making it look nice and help merges. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Spell __attribute__ correctly in cache.h.
Sun's cc doesn't know __attribute__. Signed-off-by: Jason Riedy <[EMAIL PROTECTED]> --- cache.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 4181b19f615b3d56f9fae5f3accd435480aa7d2f diff --git a/cache.h b/cache.h --- a/cache.h +++ b/cache.h @@ -41,7 +41,7 @@ #endif #ifndef __attribute__ -#define __attribute(x) +#define __attribute__(x) #endif /* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cannot use cg-clone over http after packing a public repo
Resolved. I was missing a call to git-update-server-info. It fails to make the objects/info directory, so that had to be done manually. GIT_DIR=~/public_html/repos/moodle.git git-update-server-info error: cannot open /home/martin/public_html/repos/moodle.git/objects/info/packs+ mkdir ~/public_html/repos/moodle.git/objects/info GIT_DIR=~/public_html/repos/moodle.git git-update-server-info And all is well. I'll update the documentation to note that dumb protocols will need this. Looking at server-info.c, there _is_ a call to safe_create_leading_directories(), not sure why it'd fail. I'm not much of a C jockey, really. This is with git as of a couple of ours ago: 66e06b6a17f1074401ad23f4b2a8a146b2900333 cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Cannot use cg-clone over http after packing a public repo
With todays git and cogito: moodle-git-merge$ git-push-script --all ~/public_html/repos/moodle.git This unpacked the repo completely, in spite if it being local. Anyway, from a remote machine I could do cg-clone and it succeeded, though it took ages: cg-clone http://mltest/~martin/repos/moodle.git moodle-foo So I packed the repo GIT_DIR=~/public_html/repos/moodle.git/ git-repack-script GIT_DIR=~/public_html/repos/moodle.git/ git-prune-packed And now cg-clone dies -- the objects/info/packs file is missing. It's there for the repos in kernel.org, but it isn't there in mine. H. I don't see any option mentioned in the git-repack documentation to create them. strange. cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Questions on 'cvs migration guide''
In the section 'Emulating CVS behaviour', where the team setup is described with a team 'merger'. What is not clear is how to deal with project-wide branches. Should they be created in the master repo, and everyone clone a new repo from it? With a team of 10 people, and perhaps 4 or 5 branches, the setup to pull stuff back seems messy. And yet another question: the teammember who is pulling must 'switch' the merging repo to the right branch, pull from the corresponding remote repos of each teammember, and push to the public view of the repo. Is that right? cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Not A Patch] Octopus demo
Create an empty directory and running this script in there would
let you see the original Octopus in action.
---
#!/bin/sh
test -d .saved-git || {
U=http://www.kernel.org/pub/scm/git/git.git
GIT_DIR=.saved-git
export GIT_DIR
git-init-db
: >$GIT_DIR/FETCH_HEAD
h=0
while read SHA1
do
git-http-pull -a -v $SHA1 $U
h=$(expr $h + 1)
echo $SHA1 >$GIT_DIR/refs/heads/H$h
echo "$SHA1 heads/H$h" >>$GIT_DIR/FETCH_HEAD
done <<\EOF
fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc
9e30dd7c0ecc9f10372f31539d0122db97418353
c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a
660265909fc178581ef327076716dfd3550e6e7b
b28858bf65d4fd6d8bb070865518ec43817fe7f3
EOF
echo ed4eeaf203d0f293bd5ffc2a0ad8711f052db1f3 >$GIT_DIR/HEAD
}
rm -fr testing
git clone -l ./.saved-git testing
cp .saved-git/FETCH_HEAD testing/.git/.
cd testing || exit
git show-branches
git checkout
git octopus || exit
git show-branches
git-rev-list --max-count=1 --pretty HEAD
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add commit hook and make the verification customizable.
There are three hooks:
- 'pre-commit' is given an opportunity to inspect what is
being committed, before we invoke the EDITOR for the
commit message;
- 'commit-msg' is invoked on the commit log message after
the user prepares it;
- 'post-commit' is run after a successful commit is made.
The first two can interfere to stop the commit. The last one is
for after-the-fact notification.
The earlier built-in commit checker is now moved to pre-commit.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-commit-script| 75 +-
templates/hooks--commit-msg | 14
templates/hooks--post-commit |8
templates/hooks--pre-commit | 60 ++
4 files changed, 105 insertions(+), 52 deletions(-)
create mode 100644 templates/hooks--commit-msg
create mode 100644 templates/hooks--post-commit
create mode 100644 templates/hooks--pre-commit
971fd26a05c6a5f71c727b7350c091d5bdb4ebb7
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -6,10 +6,10 @@
. git-sh-setup-script || die "Not a git archive"
usage () {
- die 'git commit [-a] [-m ] [-F ] [(-C|-c) ]
[...]'
+ die 'git commit [-a] [-v | --no-verify] [-m ] [-F ]
[(-C|-c) ] [...]'
}
-all= logfile= use_commit= no_edit= log_given= log_message= verify= signoff=
+all= logfile= use_commit= no_edit= log_given= log_message= verify=t signoff=
while case "$#" in 0) break;; esac
do
case "$1" in
@@ -67,6 +67,9 @@ do
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
signoff=t
shift ;;
+ -n|--n|--no|--no-|--no-v|--no-ve|--no-ver|--no-veri|--no-verif|--no-verify)
+verify=
+shift ;;
-v|--v|--ve|--ver|--veri|--verif|--verify)
verify=t
shift ;;
@@ -101,56 +104,10 @@ git-update-cache -q --refresh || exit 1
case "$verify" in
t)
- # This is slightly modified from Andrew Morton's Perfect Patch.
- # Lines you introduce should not have trailing whitespace.
- # Also check for an indentation that has SP before a TAB.
- perl -e '
- my $fh;
- my $found_bad = 0;
- my $filename;
- my $reported_filename = "";
- my $lineno;
- sub bad_line {
- my ($why, $line) = @_;
- if (!$found_bad) {
- print "*\n";
- print "* You have some suspicious patch lines:\n";
- print "*\n";
- $found_bad = 1;
- }
- if ($reported_filename ne $filename) {
- print "* In $filename\n";
- $reported_filename = $filename;
- }
- print "* $why (line $lineno)\n$line\n";
- }
- open $fh, "-|", qw(git-diff-cache -p -M --cached HEAD);
- while (<$fh>) {
- if (m|^diff --git a/(.*) b/\1$|) {
- $filename = $1;
- next;
- }
- if (/^@@ -\S+ \+(\d+)/) {
- $lineno = $1 - 1;
- next;
- }
- if (/^ /) {
- $lineno++;
- next;
- }
- if (s/^\+//) {
- $lineno++;
- chomp;
- if (/\s$/) {
- bad_line("trailing whitespace", $_);
- }
- if (/^\s* /) {
- bad_line("indent SP followed by a TAB", $_);
- }
- }
- }
- exit($found_bad);
- ' || exit ;;
+ if test -x "$GIT_DIR"/hooks/pre-commit
+ then
+ "$GIT_DIR"/hooks/pre-commit || exit
+ fi
esac
PARENTS="-p HEAD"
@@ -255,6 +212,15 @@ case "$no_edit" in
${VISUAL:-${EDITOR:-vi}} .editmsg
;;
esac
+
+case "$verify" in
+t)
+ if test -x "$GIT_DIR"/hooks/commit-msg
+ then
+ "$GIT_DIR"/hooks/commit-msg .editmsg || exit
+ fi
+esac
+
grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
grep -v -i '^Signed-off-by' .cmitmsg >.cmitchk
if test -s .cmitchk
@@ -269,4 +235,9 @@ else
fi
ret="$?"
rm -f .cmitmsg .editmsg .cmitchk
+
+if test -x "$GIT_DIR"/hooks/post-commit && test "$ret" = 0
+then
+ "$GIT_DIR"/hooks/post-commit
+fi
exit "$ret"
diff --git a/templates/hooks--commit-msg b/templates/hooks--commit-msg
new file mode 100644
--- /dev/null
+++ b/templates/hooks--commit-msg
@@ -0,0 +1,14 @@
+#!/bin/sh
+#
+# An example hook script to check the commit log message.
+# Called by git-commit-script with one argument, the name of the file
+# that has the commit message. The hook should exit with non-zero
+# status after issuing an appropriate message if it wants to stop the
+# commit. The hook is allowed to edit the commit message file.
+#
+# To enable this hook, make this file executable.
+
+# This
[PATCH] Infamous 'octopus merge'
This script uses the list of heads and their origin multi-head "git
fetch" left in the $GIT_DIR/FETCH_HEAD file, and makes an octopus
merge on top of the current HEAD using them.
The implementation tries to be strict for the sake of safety. It
insists that your working tree is clean (no local changes) and matches
the HEAD, and when any of the merged heads does not automerge, the
whole process is aborted and tries to rewind your working tree is to
the original state.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Makefile |1 +
git-octopus-script | 64
2 files changed, 65 insertions(+), 0 deletions(-)
create mode 100755 git-octopus-script
bad69944391b17bf5d4060b19e24013807409b28
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -72,6 +72,7 @@ SCRIPTS += git-count-objects-script
# SCRIPTS += git-send-email-script
SCRIPTS += git-revert-script
SCRIPTS += git-show-branches-script
+SCRIPTS += git-octopus-script
PROG= git-update-cache git-diff-files git-init-db git-write-tree \
git-read-tree git-commit-tree git-cat-file git-fsck-cache \
diff --git a/git-octopus-script b/git-octopus-script
new file mode 100755
--- /dev/null
+++ b/git-octopus-script
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+# Resolve two or more trees recorded in $GIT_DIR/FETCH_HEAD.
+#
+. git-sh-setup-script || die "Not a git archive"
+
+usage () {
+die "usage: git octopus"
+}
+
+# Sanity check the heads early.
+while read SHA1 REPO
+do
+ test $(git-cat-file -t $SHA1) = "commit" ||
+ die "$REPO given to octopus is not a commit"
+done <"$GIT_DIR/FETCH_HEAD"
+
+head=$(git-rev-parse --verify HEAD) || exit
+
+git-update-cache --refresh ||
+ die "Your working tree is dirty."
+test "$(git-diff-cache --cached "$head")" = "" ||
+ die "Your working tree does not match HEAD."
+
+# MRC is the current "merge reference commit"
+# MRT is the current "merge result tree"
+
+MRC=$head MRT=$head MSG='Octopus merge of the following: ' PARENT="-p $head"
+while read SHA1 REPO
+do
+ common=$(git-merge-base $MRC $SHA1) ||
+ die "Unable to find common commit between $SHA1 and $MRC"
+
+ git-read-tree -u -m $common $MRT $SHA1 || exit
+ next=$(git-write-tree 2>/dev/null)
+ if test $? -ne 0
+ then
+ git-merge-cache -o git-merge-one-file-script -a || {
+ git-read-tree --reset "$head"
+ git-checkout-tree -f -q -u -a
+ die "Automatic merge failed; should not be doing Octopus"
+ }
+ next=$(git-write-tree 2>/dev/null)
+ fi
+ PARENT="$PARENT -p $SHA1"
+ MRC=$common
+ MRT=$next
+ MSG="$MSG
+ $REPO"
+done <"$GIT_DIR/FETCH_HEAD"
+
+# Just to be careful in case the user feeds nonsense to us.
+if test "$MRT" = "$head"
+then
+ echo "No changes."
+ exit 0
+fi
+
+result_commit=$(echo "$MSG" | git-commit-tree $MRT $PARENT)
+echo "Committed octopus merge $result_commit"
+echo $result_commit >"$GIT_DIR"/HEAD
+git-diff-tree -p $head $result_commit | git-apply --stat
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach applymbox to keep the Subject: line.
Linus Torvalds <[EMAIL PROTECTED]> writes: > Well, Junio has been talking about adding commit hooks. I don't think > that's been done. No, notyet. But tonight. > 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? Sounds sensible. The hook would probably want a handy access to the commit object as well to catch: - the author name may be spelled wrong or has funky B-encodings still left. - some people might want to even run spellchecker on the commit message. - lack of S-O-B line. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach applymbox to keep the Subject: line.
Sam Ravnborg <[EMAIL PROTECTED]> writes: > I prefer to add it myself rather than to have it added automatically - > but mayve thats you me being a bit mistrusting. > > The only git- command I use today is git-applymbox. If you did not have that "add it myself" preference, I would have recommended the (not counting the flags) second parameter to git-applymbox. While we are on the topic of applymbox, currently it takes this form: $ applymbox [ -k ] [ -q ] (-c .dotest/msg_num | mail_archive) [Signoff_file]" It may make more sense to change it to: applymbox [-k] [-q] [-s ] ( -c .dotest/ | ... ) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Allow file removal when "git commit --all" is used.
Johannes Schindelin <[EMAIL PROTECTED]> writes: >> The patch is for people who thinks the user who uses the "--all" >> flag deserves the danger that comes with the convenience. >> >> Comments? > > This is a sane default behaviour. Maybe introduce yet another flag > "--no-remove", which says that removes should not be performed? But then, > "--all" is mostly used by lazy people, who probably expect the removes to > take place. Well, let's refrain from using that word; I am one of the "lazy" people, but I do that on purpose and from principle, not from lazyness. http://members.cox.net/junkio/per-file-commit.txt. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Small team cogito/git setup
On 8/18/05, Martin Langhoff <[EMAIL PROTECTED]> wrote: > We have a small team of 3, and our main activity is to run local To self: RTFM, specifically, Documentation/tutorial.txt I had read it early on and either didn't get to the end of it, or had forgotten already. Apologies, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach parse_commit_buffer about grafting.
On Fri, 19 Aug 2005, Paul Mackerras wrote: > > > Umm. git-rev-list really does everything. Rule of thumb: if you _ever_ > > need to look at any other internal git information, you're probably doing > > something wrong, or you've missed yet another flag ;) > > I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what > flag have I missed? :) Junio wants me to look at everything under > [gitdir]/refs, in fact. Or are the refs not considered internal git > information? Ahh, ok, fair enough. git-rev-list won't give you that. And yes, the general rule is that anything under .git/refs/ is potentially a reference. If it's under "heads/" or "tags/" it's a branch/tag, and then the prefix "heads/" or "tags/" shouldn't be part of the name - you already show the difference with colors. Anything else is unusual, but bisection puts refs in the ".git/refs/bisect" directory for example, and if gitk were to show those, it should probably show them in yet another color, and _with_ the "bisect/" prefix.. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach parse_commit_buffer about grafting.
Hi, On Fri, 19 Aug 2005, Paul Mackerras wrote: > Linus Torvalds writes: > > > Paul, I hate to tell you about yet another flag [...] But why? You're doing such a fine job telling people about flags :-) > > Umm. git-rev-list really does everything. Rule of thumb: if you _ever_ > > need to look at any other internal git information, you're probably doing > > something wrong, or you've missed yet another flag ;) > > I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what > flag have I missed? :) Junio wants me to look at everything under > [gitdir]/refs, in fact. Or are the refs not considered internal git > information? Time for git-ref-list? Joking. But there may be a use for a "--refs" flag to git-rev-list, which just lists all the refs' names together with their object name (SHA1). Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach parse_commit_buffer about grafting.
Linus Torvalds writes: > Paul, I hate to tell you about yet another flag to git-rev-list, but did > you realize that in addition to all the other magic flags, there's a flag > called "--parents"? Cool. I didn't realize that. The current version uses it now. > Umm. git-rev-list really does everything. Rule of thumb: if you _ever_ > need to look at any other internal git information, you're probably doing > something wrong, or you've missed yet another flag ;) I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what flag have I missed? :) Junio wants me to look at everything under [gitdir]/refs, in fact. Or are the refs not considered internal git information? Paul. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
>Yup. Think of it as a good exercise in git ;) Fixed now (I hope). -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
Hi, On Thu, 18 Aug 2005, Linus Torvalds wrote: > Btw, it's a shame that git has all these "git rebase" etc helper scripts, > which rebase whole series of patches, but the simple "git re-do" which > basically ends up being a > > git-diff-tree -p $old | git-apply --index && > git commit --reedit=$old How about "git-cherry-pick-script"? Junio? Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
On Thu, 18 Aug 2005, Luck, Tony wrote: > > Yes I had a failed merge ... I thought that I had cleaned up from it, but > clearly I hadn't. Bother. The simplest way of cleaning up after a failed merge is just a simple "git reset", which will also tell you if you need to perhaps clean up afterwards (equally easily done with "git checkout -f" if you just want to blow all the changes away. > I guess I have a bit of tree maintenance to do ... But I think that it > should be easy ... I can just step "test" back to before I merged in > the Alex patch. Redo the Alex patch properly. Then re-merge all the > branches that happened after this. Followed by crossing my fingers and > running "git prune". > > Maybe I'll try all that in a *copy" of my GIT tree first! Yup. Think of it as a good exercise in git ;) Btw, it's a shame that git has all these "git rebase" etc helper scripts, which rebase whole series of patches, but the simple "git re-do" which basically ends up being a git-diff-tree -p $old | git-apply --index && git commit --reedit=$old doesn't have a nice helper script. Anyway, the easiest approach may be to just do git branch new-test-branch git format-patch -o patchdir --mbox git checkout new-test-branch .. edit the individual patches in patchdir/* to taste .. cat git-applymbox patchdir/* | git-applymbox or similar. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git-whatchanged -p anomoly?
>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. Yes I had a failed merge ... I thought that I had cleaned up from it, but clearly I hadn't. Bother. I guess I have a bit of tree maintenance to do ... But I think that it should be easy ... I can just step "test" back to before I merged in the Alex patch. Redo the Alex patch properly. Then re-merge all the branches that happened after this. Followed by crossing my fingers and running "git prune". Maybe I'll try all that in a *copy" of my GIT tree first! -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-applymbox: verify that index is clean
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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-whatchanged -p anomoly?
"Luck, Tony" <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-whatchanged -p anomoly?
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 <[EMAIL PROTECTED]> [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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: symlinked directories in refs are now unreachable
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH] Updates to glossary
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH] Updates to glossary
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH] Updates to glossary
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 | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Harris's Lament:
All the good ones are taken.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH] Updates to glossary
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* - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git-whatchanged -p anomoly?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach applymbox to keep the Subject: line.
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Stgit - patch history / add extra parents
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,
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Subject: [PATCH] Updates to glossary
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 <[EMAIL PROTECTED]>
---
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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach applymbox to keep the Subject: line.
> (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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb - Use instead of .
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 instead of . > > > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] updates for Documentation/howto/using-topic-branches.txt
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 <[EMAIL PROTECTED]>
---
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb - Use instead of .
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 instead of . > > > > RSS 2.0 Specification doesn't have . > > see http://blogs.law.harvard.edu/tech/rss > > See here: > http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ > > The 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 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 . that's all I can say :< can any one help? > "It works in XY-reader" does not count. :) agreed. -- yashi - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb - Add and .
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 and . > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb - Use instead of .
On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote: > Use instead of . > > RSS 2.0 Specification doesn't have . > see http://blogs.law.harvard.edu/tech/rss See here: http://www.notestips.com/80256B3A007F2692/1/NAMO5P9UPQ The 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 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb - Use instead of .
On Thu, Aug 18, 2005 at 11:30:41PM +0900, Yasushi SHOJI wrote: > Use instead of . > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add Makefile target glossary.html
This also includes a script which does the sorting, and introduces
hyperlinks for every described term.
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
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:
+
+';
+
[EMAIL PROTECTED] {uc($a) cmp uc($b)} keys %terms;
+$pattern='(\b'.join('\b|\b',reverse @keys).'\b)';
+foreach $key (@keys) {
+ $terms{$key}=~s/$pattern/sprintf "<>";/eg;
+ print '[[ref_'.no_spaces($key).']]'.$key."::\n"
+ .format_tab_80($terms{$key})."\n";
+}
+
+print '
+
+Author
+--
+Written by Johannes Schindelin <[EMAIL PROTECTED]> and
+the git-list .
+
+GIT
+---
+Part of the link:git.html[git] suite
+';
+
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
cg-help question
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitweb - Add and .
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 and .
>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 <[EMAIL PROTECTED]>
---
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 {
"" .
sprintf("%d %s %02d:%02d", $cd{'mday'}, $cd{'month'},
$cd{'hour'}, $cd{'minute'}) . " - " . escapeHTML($co{'title'}) .
"\n" .
+ "" . escapeHTML($co{'author'}) . "\n" .
"$cd{'rfc2822'}\n" .
+ "" .
escapeHTML("$my_url?p=$project;a=commit;h=$commit") . "\n" .
"" .
escapeHTML("$my_url?p=$project;a=commit;h=$commit") . "\n" .
"" .
"
[PATCH] gitweb - Use instead of .
Use instead of .
RSS 2.0 Specification doesn't have .
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 <[EMAIL PROTECTED]>
---
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 {
"\n" .
"$cd{'rfc2822'}\n" .
"" .
escapeHTML("$my_url?p=$project;a=commit;h=$commit") . "\n" .
- "" . escapeHTML($co{'title'}) .
"\n" .
- "" .
+ "" .
"\n" .
- "\n" .
+ "\n" .
"\n";
}
print "";
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patches exchange is bad?
Marco Costalba <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patches exchange is bad?
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patches exchange is bad?
Marco Costalba <[EMAIL PROTECTED]> wrote: > Catalin Marinas wrote: >>That's how you would normally do development on Linux using StGIT - >>clone the mainline kernel, create patches in your StGIT tree and submit >>them either via e-mail or ask the gatekeeper to pull directly from your >>tree (assuming that you only push those patches that need to be merged). >>Doing a 'stg pull' would retrieve the latest changes from the mainline >>kernel (including the changes made by your patches which were merged >>upstream). > > 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. 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. > 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. If you want to keep a stable branch (and only you comitting to it), I would recommend having separate branches for stable and development in the same tree (and avoid having separate trees) rather than directly modifying the base. StGIT doesn't support this directly (didn't think anyone would ask) but you can do the following steps: 1. Use 'stg clone ' to create the initial clone. The 'master' branch will be used for development. You can use 'git-init-db' and 'stg init' if you don't follow a remote repository 2. 'git checkout -b stable' will create the stable branch. This will initially be the same as the master one since there are not patches applied to the master stack 3. switch back to the devel branch with 'git checkout master' and do the normal StGIT development (create patches, commit them etc.). If you are tracking a remote respository, you could pull the latest changes with 'stg pull' 4. Once you have a set of patches applied and your stack is stable (some patches can be unapplied, they don't affect the head of the development branch), you can switch to the stable branch with 'stg checkout stable' and merge the changes in master with 'git-resolve-script'. I think it might make more sense to simply do a 'cp .git/refs/heads/master .git/refs/heads/stable' instead of the previous paragraph since the stable branch doesn't have additional data from what's in master. The remote repository tracking is done via master. 5. You can advance the base of the stack to what's in stable with an 'stg pull stable' but it's not clear for me whether this makes any sense since you lose the StGIT patches already added to stable and you will might later get conflicts when pulling the changes from the remote repository you are tracking. For the 2, 3 and 4 steps above I will add a 'snapshot' command to StGIT but I'm not sure why one would want step 5 since this would mean that the devel branch needs to track both the remote repository and the stable branch. Some questions: do you track a remote repository? Do you need a stable repository or branch where more people can update? If you track the remote repository, do you want the latest remote changes merged into the stable branch directly (i.e. is the stable branch tracking the remote repository)? I need a bit more clarification about your work flow. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] Allow file removal when "git commit --all" is used.
Hi, On Thu, 18 Aug 2005, Junio C Hamano wrote: > After you deleted files from your working tree, automatic > git-update-cache used when the "--all" flag is given to "git > commit" barfs because it lacks the --remove flag. > > It can be argued that this is a feature; people should be > careful and something with a grave consequence like removing > files should be done manually, in which case the current > behaviour may be OK. > > The patch is for people who thinks the user who uses the "--all" > flag deserves the danger that comes with the convenience. > > Comments? This is a sane default behaviour. Maybe introduce yet another flag "--no-remove", which says that removes should not be performed? But then, "--all" is mostly used by lazy people, who probably expect the removes to take place. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multi-head pulling series
On Thursday 18 August 2005 09:24, Junio C Hamano wrote: > $ cat $GIT_DIR/remotes/www > URL: http://www.kernel.org/pub/scm/git/git.git/ > Pull: master:ko-master pu:ko-pu > Push: master:master pu:pu foo:bar Isn't this mixing two kinds of information: 1) Some default/persistent mapping of local to remote heads 2) The default heads which are pulled/pushed when only giving the remote, like in: > $ git push mko ;# push our master and pu to the same > # name, foo to .git/refs/heads/bar. I think it makes sense to be able to store mappings without adding the head to the default group of heads pulled. Can we put the default pull/push actions in separate lines, like $ cat $GIT_DIR/remotes/mko URL: master.kernel.org:/pub/scm/git/git.git/ Pull: master:ko-master pu:ko-pu mylocal:myremote Push: master:master pu:pu foo:bar Default-Pull: master pu Default-Push: master pu foo > $ git push mko pu:refs/heads/testing > # instead of pushing to the usual ref, > # push our pu to refs/heads/testing, > # this time only. With a command (push/fetch/pull) giving an explicit local/remote mapping, it would be cool to automatically add the given mapping to the remotes/ file if there is no push-mapping for pu yet, so that you can have the same later with only git push mko pu And finally, it would be nice to specify a default mapping for arbitrary heads $ cat $GIT_DIR/remotes/www URL: http://www.kernel.org/pub/scm/git/git.git/ Pull: www#*:* Such that git fetch www#pu will fetch head pu into local head .refs/heads/www#pu Josef PS: I know I should provide patches for my proposals. But let discuss them first. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Teach applymbox to keep the Subject: line.
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Wed, 17 Aug 2005, Jeff Garzik wrote: >> >> 1) Fix applymbox such that it understands RFC822-valid Subject lines >> which wrap across multiple text lines. > > It already should do this. > >> 2) Teach it to understand MIME, and not treat the MIME headers like part >> of the message. > > But this one I really realyl disagree with. > > The fact is, anybody who doesn't edit the emails that come in is BROKEN. > There are two kinds of emails: > > - the nicely formatted ones where the author follows all the rules > >This kind of email doesn't need MIME decoding anyway. Unless they want to write something that doesn't fit in ASCII, as discussed in another thread here. But maybe you are only talking about MIME attachments, and not about MIME content encodings? We probably need to separate the two. Note that I'm not really talking about your patch handling for Linux; you are free to disallow my name in Linux patches if you want to. But I'd like to see a way to get rid of that limitation for other uses of git. -- David Kågedal - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patches exchange is bad?
Johannes Schindelin <[EMAIL PROTECTED]> wrote: > maybe it is time for a quick run through the typical jobs you do with > StGIT, much like what Jeff sent the other day? I hope I will find some time this weekend and write some tutorials on an StGIT wiki. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Patches exchange is bad?
Catalin Marinas wrote: > >The base of the StGIT stack in the HEAD repository (branch) should >always be the head of the MAIN repository. That's the point I missed, now it's more clear. > >That's how you would normally do development on Linux using StGIT - >clone the mainline kernel, create patches in your StGIT tree and submit >them either via e-mail or ask the gatekeeper to pull directly from your >tree (assuming that you only push those patches that need to be merged). >Doing a 'stg pull' would retrieve the latest changes from the mainline >kernel (including the changes made by your patches which were merged >upstream). > 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. 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. > >Please let me know if this needs further clarification. > I think so. Please, reading my notes above tell me if I thinking right ;-) Marco __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Small team cogito/git setup
Hi, Martin Langhoff wrote:
> Or are we forced to run an 'integration' repo so that we work with a
> 'star' arrangement? I am actually trying to avoid needing a central
> repo if possible.
Personally, I like the idea of an integration repository. The main reason
is that it avoids duplicate work and shifting blame for broken software,
particularly if you have a test suite.
My workflow is "develop, test, check-in, pull-and-merge, test-if-merged,
push". That tends to yield a saner change history, and requires less work,
than doing it for every co-worker.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"Fundamentalists are like the fir trees in German forests: they cannot
stand alone, and are only stable when crowded together, branches locked
with those of their brothers. That is why we must always fear them,
because they will always hate us for our individualism."
[Brent Yaciw, with inspirational regards to Jack M. Bickham]
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git 1.0 Synopis (Draft v4)
Hi, Horst von Brand wrote:
> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.
Ummm... why?
make's SCCS support depends on the presence of a SCCS/s. file
for each . We don't have that. Teaching make about git would be
equivalent to teaching it about parsing the index file.
Technically, that would require a stable libgit.so or so.
In reality, however, I don't know when I last had a tree which wasn't
fully populated, but it's been a while, and it's something that can be
readily fixed by "git-checkout-cache -a".
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
One possible reason that things aren't going according to plan
is that there never was a plan in the first place.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] Allow file removal when "git commit --all" is used.
After you deleted files from your working tree, automatic git-update-cache used when the "--all" flag is given to "git commit" barfs because it lacks the --remove flag. It can be argued that this is a feature; people should be careful and something with a grave consequence like removing files should be done manually, in which case the current behaviour may be OK. The patch is for people who thinks the user who uses the "--all" flag deserves the danger that comes with the convenience. Comments? Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- diff --git a/git-commit-script b/git-commit-script --- a/git-commit-script +++ b/git-commit-script @@ -88,13 +88,13 @@ esac case "$all,$#" in t,*) git-diff-files --name-only -z | - xargs -0 git-update-cache -q -- + xargs -0 git-update-cache -q --remove -- ;; ,0) ;; *) git-diff-files --name-only -z "$@" | - xargs -0 git-update-cache -q -- + xargs -0 git-update-cache -q --remove -- ;; esac || exit 1 git-update-cache -q --refresh || exit 1 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Update git-pull to match updated git-fetch.
This retires the git-parse-remote script, and allows pull to fetch from multiple remote references. There is no support for resolving more than two heads, so that would be next. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- Makefile |2 + git-parse-remote | 79 -- git-pull-script | 14 ++ 3 files changed, 10 insertions(+), 85 deletions(-) delete mode 100755 git-parse-remote 3a071a02828c71bbfdc2749d25814906cd9c8b18 diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -64,7 +64,7 @@ SCRIPTS=git git-apply-patch-script git-m git-reset-script git-add-script git-checkout-script git-clone-script \ gitk git-cherry git-rebase-script git-relink-script git-repack-script \ git-format-patch-script git-sh-setup-script git-push-script \ - git-branch-script git-parse-remote git-parse-remote-script git-verify-tag-script \ + git-branch-script git-parse-remote-script git-verify-tag-script \ git-ls-remote-script git-clone-dumb-http git-rename-script \ git-request-pull-script git-bisect-script diff --git a/git-parse-remote b/git-parse-remote deleted file mode 100755 --- a/git-parse-remote +++ /dev/null @@ -1,79 +0,0 @@ -: To be included in git-pull and git-fetch scripts. - -# A remote repository can be specified on the command line -# in one of the following formats: -# -# -# -# tag -# -# where could be one of: -# -# a URL (including absolute or local pathname) -# a short-hand -# a short-hand followed by a trailing path -# -# A short-hand has a corresponding file $GIT_DIR/branches/, -# whose contents is a URL, possibly followed by a URL fragment # -# to name the default branch on the remote side to fetch from. - -_remote_repo= _remote_store= _remote_head= _remote_name= - -case "$1" in -*:* | /* | ../* | ./* ) - _remote_repo="$1" - ;; -* ) - # otherwise, it is a short hand. - case "$1" in - */*) - # a short-hand followed by a trailing path - _token=$(expr "$1" : '\([^/]*\)/') - _rest=$(expr "$1" : '[^/]*\(/.*\)$') - ;; - *) - _token="$1" - _rest= - _remote_store="refs/heads/$_token" - ;; - esac - test -f "$GIT_DIR/branches/$_token" || - die "No such remote branch: $_token" - - _remote_repo=$(cat "$GIT_DIR/branches/$_token")"$_rest" - ;; -esac - -case "$_remote_repo" in -*"#"*) - _remote_head=`expr "$_remote_repo" : '.*#\(.*\)$'` - _remote_repo=`expr "$_remote_repo" : '\(.*\)#'` - ;; -esac - -_remote_name=$(echo "$_remote_repo" | sed 's|\.git/*$||') - -case "$2" in -tag) - _remote_name="tag '$3' of $_remote_name" - _remote_head="refs/tags/$3" - _remote_store="$_remote_head" - ;; -?*) - # command line specified a head explicitly; do not - # store the fetched head as a branch head. - _remote_name="head '$2' of $_remote_name" - _remote_head="refs/heads/$2" - _remote_store='' - ;; -'') - case "$_remote_head" in - '') - _remote_head=HEAD ;; - *) - _remote_name="head '$_remote_head' of $_remote_name" - _remote_head="refs/heads/$_remote_head" - ;; - esac - ;; -esac diff --git a/git-pull-script b/git-pull-script --- a/git-pull-script +++ b/git-pull-script @@ -1,12 +1,16 @@ #!/bin/sh # . git-sh-setup-script || die "Not a git archive" -. git-parse-remote "$@" -merge_name="$_remote_name" - git-fetch-script "$@" || exit 1 +merge_head=$(sed -e 's/.*//' "$GIT_DIR"/FETCH_HEAD | tr '\012' ' ') +merge_name=$(sed -e 's/^[0-9a-f]* //' "$GIT_DIR"/FETCH_HEAD | +tr '\012' ' ') + +case "$merge_head" in +'' | *' '?*) die "Cannot resolve multiple heads at the same time (yet)." ;; +esac + git-resolve-script \ "$(cat "$GIT_DIR"/HEAD)" \ - "$(cat "$GIT_DIR"/FETCH_HEAD)" \ - "Merge $merge_name" + $merge_head "Merge $merge_name" - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Start adding the $GIT_DIR/remotes/ support.
All the necessary parsing code is in git-parse-remote-script;
update git-push-script to use it.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Makefile|2 -
git-parse-remote-script | 122 +++
git-push-script | 28 ++-
3 files changed, 129 insertions(+), 23 deletions(-)
create mode 100755 git-parse-remote-script
f8892bf17675056cd18a252d3bc4e4ba381fb3bc
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -64,7 +64,7 @@ SCRIPTS=git git-apply-patch-script git-m
git-reset-script git-add-script git-checkout-script git-clone-script \
gitk git-cherry git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
- git-branch-script git-parse-remote git-verify-tag-script \
+ git-branch-script git-parse-remote git-parse-remote-script
git-verify-tag-script \
git-ls-remote-script git-clone-dumb-http git-rename-script \
git-request-pull-script git-bisect-script
diff --git a/git-parse-remote-script b/git-parse-remote-script
new file mode 100755
--- /dev/null
+++ b/git-parse-remote-script
@@ -0,0 +1,122 @@
+#!/bin/sh
+
+. git-sh-setup-script || die "Not a git archive"
+
+get_data_source () {
+ case "$1" in
+ */*)
+ # Not so fast. This could be the partial URL shorthand...
+ token=$(expr "$1" : '\([^/]*\)/')
+ remainder=$(expr "$1" : '[^/]*/\(.*\)')
+ if test -f "$GIT_DIR/branches/$token"
+ then
+ echo branches-partial
+ else
+ echo ''
+ fi
+ ;;
+ *)
+ if test -f "$GIT_DIR/remotes/$1"
+ then
+ echo remotes
+ elif test -f "$GIT_DIR/branches/$1"
+ then
+ echo branches
+ else
+ echo ''
+ fi ;;
+ esac
+}
+
+get_remote_url () {
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '')
+ echo "$1" ;;
+ remotes)
+ sed -ne '/^URL: */{
+ s///p
+ q
+ }' "$GIT_DIR/remotes/$1" ;;
+ branches)
+ sed -e 's/#.*//' "$GIT_DIR/branches/$1" ;;
+ branches-partial)
+ token=$(expr "$1" : '\([^/]*\)/')
+ remainder=$(expr "$1" : '[^/]*/\(.*\)')
+ url=$(sed -e 's/#.*//' "$GIT_DIR/branches/$token")
+ echo "$url/$remainder"
+ ;;
+ *)
+ die "internal error: get-remote-url $1" ;;
+ esac
+}
+
+get_remote_default_refs_for_push () {
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '' | branches | branches-partial)
+ ;; # no default push mapping, just send matching refs.
+ remotes)
+ sed -ne '/^Push: */{
+ s///p
+ }' "$GIT_DIR/remotes/$1" ;;
+ *)
+ die "internal error: get-remote-default-ref-for-push $1" ;;
+ esac
+}
+
+# Subroutine to caninicalize remote:local notation
+canon_refs_list_for_fetch () {
+ for ref
+ do
+ expr "$ref" : '.*:' >/dev/null || ref="${ref}:"
+ remote=$(expr "$ref" : '\([^:]*\):')
+ local=$(expr "$ref" : '[^:]*:\(.*\)')
+ case "$remote" in
+ '') remote=HEAD ;;
+ *) remote="refs/heads/$remote" ;;
+ esac
+ case "$local" in
+ '') local= ;;
+ *) local="refs/heads/$local" ;;
+ esac
+ echo "${remote}:${local}"
+ done
+}
+
+# Returns list of src: (no store), or src:dst (store)
+get_remote_default_refs_for_fetch () {
+ data_source=$(get_data_source "$1")
+ case "$data_source" in
+ '' | branches-partial)
+ echo "HEAD:" ;;
+ branches)
+ remote_branch=$(sed -ne '/#/s/.*#//p' "$GIT_DIR/branches/$1")
+ case "$remote_branch" in '') remote_branch=master ;; esac
+ echo "refs/heads/${remote_branch}:refs/heads/$1"
+ ;;
+ remotes)
+ canon_refs_list_for_fetch $(sed -ne '/^Pull: */{
+ s///p
+ }' "$GIT_DIR/remotes/$1")
+ ;;
+ *)
+ die "internal error: get-remote-default-ref-for-push $1" ;;
+ esac
+}
+
+get_remote_refs_for_push () {
+ case "$#" in
+ 0) die "internal error: get-remote-refs-for-push." ;;
+ 1) get_remote_default_refs_for_push "$@" ;;
+ *) shift; echo "$@" ;;
+ esac
+}
+
+get_remote_refs_for_fetch () {
+ case "$#" in
+ 0) die "internal error: get-remote-refs-for-fetch." ;;
+
[PATCH 2/3] Multi-head fetch.
Traditionally, fetch takes these forms:
$ git fetch
$ git fetch
$ git fetch tag
This patch updates it to take
$ git fetch ...
where:
- A of form ":" is to fetch the objects
needed for the remote ref that matches , and if
is not empty, store it as a local .
- "tag" followed by is just an old way of saying
"refs/tags/:refs/tags/"; this mimics the
current behaviour of the third form above and means "fetch
that tag and store it under the same name".
- A single token without colon is a shorthand for
":" That is, "fetch that ref but do not store
anywhere".
- when there is no specified
- if is the name of a file under $GIT_DIR/remotes/
(i.e. a new-style shorthand), then it is the same as giving
the s listed on Pull: line in that file.
- if is the name of a file under $GIT_DIR/branches/
(i.e. an old-style shorthand, without trailing path), then it
is the same as giving a single
":refs/heads/" on the command line, where
is the remote branch name (defaults to HEAD, but
can be overridden by .git/branches/ file having the
URL fragment notation). That is, "fetch that branch head and
store it in refs/heads/".
- otherwise, it is the same as giving a single
that is "HEAD:".
The SHA1 object names of fetched refs are stored in FETCH_HEAD,
one name per line.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-fetch-script | 154 ++
1 files changed, 108 insertions(+), 46 deletions(-)
7dbfeb149dfc049015f27f15dd9135fd15d5f99f
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -1,54 +1,116 @@
#!/bin/sh
#
. git-sh-setup-script || die "Not a git archive"
-. git-parse-remote "$@"
-merge_repo="$_remote_repo"
-merge_head="$_remote_head"
-merge_store="$_remote_store"
-
-TMP_HEAD="$GIT_DIR/TMP_HEAD"
-
-case "$merge_repo" in
-http://* | https://*)
-if [ -n "$GIT_SSL_NO_VERIFY" ]; then
-curl_extra_args="-k"
-fi
- _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]' &&
- _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40" &&
- head=$(curl -nsf $curl_extra_args "$merge_repo/$merge_head") &&
- expr "$head" : "$_x40\$" >/dev/null || {
- echo >&2 "Failed to fetch $merge_head from $merge_repo"
- exit 1
- }
- echo Fetching "$merge_head" using http
- git-http-pull -v -a "$head" "$merge_repo/" || exit
- ;;
-rsync://*)
- rsync -L "$merge_repo/$merge_head" "$TMP_HEAD" || exit 1
- head=$(git-rev-parse TMP_HEAD)
- rm -f "$TMP_HEAD"
- rsync -avz --ignore-existing "$merge_repo/objects/"
"$GIT_OBJECT_DIRECTORY/"
- ;;
-*)
- head=$(git-fetch-pack "$merge_repo" "$merge_head")
- if h=`expr "$head" : '\([^ ][^ ]*\) '`
+. git-parse-remote-script
+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
+_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
+
+remote_nick="$1"
+remote=$(get_remote_url "$@")
+refs=
+rref=
+prev_was_literal_tag=
+rsync_slurped_objects=
+: >$GIT_DIR/FETCH_HEAD
+
+fast_forward_local () {
+
+ # NEEDSWORK: probably use the same cmpxchg protocol here...
+ echo "$2" >"$GIT_DIR/$1.lock"
+ if test -f "$GIT_DIR/$1"
then
- head=$h
+ local=$(git-rev-parse --verify "$1^0") &&
+ mb=$(git-merge-base "$local" "$2") &&
+ test "$mb" = "$local" || {
+ rm -f "$GIT_DIR/$1.lock"
+ die "$1 does not fast forward to $4 from $3.";
+ }
fi
- ;;
-esac || exit 1
-
-git-rev-parse --verify "$head" > /dev/null || exit 1
+ mv "$GIT_DIR/$1.lock" "$GIT_DIR/$1"
+}
-case "$merge_store" in
-'')
- ;;
-*)
- echo "$head" > "$GIT_DIR/$merge_store"
-esac &&
+for ref in $(get_remote_refs_for_fetch "$@")
+do
+ if test "$prev_was_literal_tag"
+ then
+ ref="refs/tags/${ref}:refs/tags/${ref}"
+ prev_was_literal_tag=
+ else
+ case "$ref" in
+ tag)
+ prev_was_literal_tag=yes
+ continue
+ ;;
+ esac
+ fi
-# FETCH_HEAD is fed to git-resolve-script which will eventually be
-# passed to git-commit-tree as one of the parents. Make sure we do
-# not give a tag object ID.
+ refs="$refs $ref"
-git-rev-parse "$head^0" >"$GIT_DIR/FETCH_HEAD"
+ # These are relative path from $GIT_DIR, typically starting at refs/
+ # but may be HEAD
+ remote_name=$(expr "$ref" : '\([^:]*\):')
+ local_name=$(expr "$ref" : '[^:]*:\(.*\)')
+
+ rref="$rref $remote_name"
+
+ # There are transports that can fetch only one head at a time...
+ case "$remote" in
+ http://* | https://*)
+ if
Multi-head pulling series
Here is the current status of the multi-head download support. [PATCH 1/3] Start adding the $GIT_DIR/remotes/ support. [PATCH 2/3] Multi-head fetch. [PATCH 3/3] Update git-pull to match updated git-fetch. The first one in the series adds support for the long promised $GIT_DIR/remotes/ files; they use the following format: $ cat $GIT_DIR/remotes/www URL: http://www.kernel.org/pub/scm/git/git.git/ Pull: master:ko-master pu:ko-pu $ cat $GIT_DIR/remotes/mko URL: master.kernel.org:/pub/scm/git/git.git/ Pull: master:ko-master pu:ko-pu Push: master:master pu:pu foo:bar The idea is that you should be able to say: $ git push mko ;# push our master and pu to the same # name, foo to .git/refs/heads/bar. $ git push mko pu:refs/heads/testing # instead of pushing to the usual ref, # push our pu to refs/heads/testing, # this time only. $ git fetch www ;# get their master and pu to our ko-master # and ko-pu. $ git pull www bar # instead of fetching from usual ref, # fetch from there bar, and merge with it. Having a Push: entry that uses anything but hostname:/path or just local directory as its URL does not make any sense at this moment, because git native send-pack transport is the only one that is supported for push, as before. Note that using a $GIT_DIR/branches/ file as a short-cut is still supported, for both upload and download. The second one extends "git fetch" to allow pulling from more than one head. Earlier, "git fetch " with shorthand form (i.e. a file $GIT_DIR/branches/ exists and describes the URL) always overwrote $GIT_DIR/refs/heads/, but it does the "reverse push", meaning it does not overwrite when the update does not result in a fast-forward merge with the existing value of the reference. The above "git fetch www" example would fetch both their master and pu, and tries to fast forward our ko-master and ko-pu with them. When fast forwarding fails, currently it just stops and does not try to download all the heads. This may need to change. The fetch results, whether they update the local refs/heads/ hierarchy by fast forwarding or not, will be also stored in $GIT_DIR/FETCH_HEAD. Note that the format of this file has changed to accomodate multiple heads. I've checked that neither Cogito nor StGIT looks at this file, so this change should hopefully be a safe one. The third one is to update the "git pull" to prevent people from abusing the extended "git fetch" and attempt to create a king ghidorah. "git resolve" has not been updated to do anything but two-head merge yet, so when you say "git pull www master pu rc", it would run "git fetch www master pu rc" but stops without running the resolving step. While it would not make much sense xsto do an octopus merge against master, pu and rc from git.git repository, doing an octopus would probably make a lot more sense when pulling from a repository like what Jeff Garzik has, so that would be an interesting future project. I have tested the very basic form of the above works reasonably well, but there probably are bugs, maybe attempting to pull heads to a wrong local heads, or something silly like that. Please handle it with care. It will stay in "pu" branch for now. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
