* 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: Luck, Tony @ 2005-08-18 22:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
>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
^ permalink raw reply
* RE: git-whatchanged -p anomoly?
From: Linus Torvalds @ 2005-08-18 23:04 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F042C819D@scsmsx401.amr.corp.intel.com>
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 <good-point>
git format-patch -o patchdir --mbox <good-point>
git checkout new-test-branch
.. edit the individual patches in patchdir/* to taste ..
cat git-applymbox patchdir/* | git-applymbox
or similar.
Linus
^ permalink raw reply
* RE: git-whatchanged -p anomoly?
From: Johannes Schindelin @ 2005-08-18 23:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luck, Tony, git
In-Reply-To: <Pine.LNX.4.58.0508181555370.3412@g5.osdl.org>
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
^ permalink raw reply
* RE: git-whatchanged -p anomoly?
From: Luck, Tony @ 2005-08-18 23:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
>Yup. Think of it as a good exercise in git ;)
Fixed now (I hope).
-Tony
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Paul Mackerras @ 2005-08-19 0:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Wolfgang Denk, git
In-Reply-To: <Pine.LNX.4.58.0508172209220.3412@g5.osdl.org>
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.
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Johannes Schindelin @ 2005-08-19 0:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Junio C Hamano, Wolfgang Denk, git
In-Reply-To: <17157.10227.296309.809074@cargo.ozlabs.ibm.com>
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
^ permalink raw reply
* Re: [PATCH] Teach parse_commit_buffer about grafting.
From: Linus Torvalds @ 2005-08-19 0:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Wolfgang Denk, git
In-Reply-To: <17157.10227.296309.809074@cargo.ozlabs.ibm.com>
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
^ permalink raw reply
* Re: Small team cogito/git setup
From: Martin Langhoff @ 2005-08-19 1:03 UTC (permalink / raw)
To: GIT
In-Reply-To: <46a038f9050817211446684aac@mail.gmail.com>
On 8/18/05, Martin Langhoff <martin.langhoff@gmail.com> 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
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Junio C Hamano @ 2005-08-19 1:04 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linus Torvalds, git
In-Reply-To: <20050818172646.GA18459@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> 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 <signoff>] ( -c .dotest/<msg_num> | <mbox>... )
^ permalink raw reply
* Re: [PATCH/RFC] Allow file removal when "git commit --all" is used.
From: Junio C Hamano @ 2005-08-19 1:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508181248110.30218@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Junio C Hamano @ 2005-08-19 1:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sam Ravnborg, git
In-Reply-To: <Pine.LNX.4.58.0508181257320.3412@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> 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.
^ permalink raw reply
* [PATCH] Infamous 'octopus merge'
From: Junio C Hamano @ 2005-08-19 1:05 UTC (permalink / raw)
To: git
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 <junkio@cox.net>
---
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
^ permalink raw reply
* [PATCH] Add commit hook and make the verification customizable.
From: Junio C Hamano @ 2005-08-19 1:05 UTC (permalink / raw)
To: git
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 <junkio@cox.net>
---
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 <message>] [-F <logfile>] [(-C|-c) <commit>] [<path>...]'
+ die 'git commit [-a] [-v | --no-verify] [-m <message>] [-F <logfile>] [(-C|-c) <commit>] [<path>...]'
}
-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 example catches duplicate Signed-off-by lines.
+
+test "" = "$(grep '^Signed-off-by: ' "$1" |
+ sort | uniq -c | sed -e '/^[ ]*1 /d')"
diff --git a/templates/hooks--post-commit b/templates/hooks--post-commit
new file mode 100644
--- /dev/null
+++ b/templates/hooks--post-commit
@@ -0,0 +1,8 @@
+#!/bin/sh
+#
+# An example hook script that is called after a successful
+# commit is made.
+#
+# To enable this hook, make this file executable.
+
+: Nothing
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
new file mode 100644
--- /dev/null
+++ b/templates/hooks--pre-commit
@@ -0,0 +1,60 @@
+#!/bin/sh
+#
+# An example hook script to verify what is about to be committed.
+# Called by git-commit-script with no arguments. The hook should
+# exit with non-zero status after issuing an appropriate message if
+# it wants to stop the commit.
+#
+# To enable this hook, make this file executable.
+
+# 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);
+'
+
^ permalink raw reply
* [Not A Patch] Octopus demo
From: Junio C Hamano @ 2005-08-19 1:05 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* git-push to a local directory forces unpack/repack?
From: Martin Langhoff @ 2005-08-19 2:57 UTC (permalink / raw)
To: GIT
If I do git-push ~/somelocaldir it forces a full unpack of the
project, is this expected? I was expecting a harmless copy of the
packs...
At the moment, it means 900MB when I am initializing the public repo.
I haven't found the way to convince it to use rsync. Still running
repack.
cheers,
martin
^ permalink raw reply
* Merge conflicts as .rej .orig files
From: Martin Langhoff @ 2005-08-19 3:06 UTC (permalink / raw)
To: GIT
After using arch for a while, I've gotten used to getting .rej and
.orig files instead of big ugly conflict markers inside the file.
Emacs has a nice 'diff' mode that is a boon when dealing with
conflicts this way.
Is there a way to convince cogito/git to leave reject files around?
What utility is git using to do the merges? Or at least: where should
I look?
cheers,
martin
^ permalink raw reply
* Questions on 'cvs migration guide''
From: Martin Langhoff @ 2005-08-19 3:17 UTC (permalink / raw)
To: GIT
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
^ permalink raw reply
* Cannot use cg-clone over http after packing a public repo
From: Martin Langhoff @ 2005-08-19 3:35 UTC (permalink / raw)
To: GIT
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. Hmmmm.
I don't see any option mentioned in the git-repack documentation to
create them. strange.
cheers,
martin
^ permalink raw reply
* Re: Cannot use cg-clone over http after packing a public repo
From: Martin Langhoff @ 2005-08-19 3:55 UTC (permalink / raw)
To: GIT
In-Reply-To: <46a038f905081820353988dfdd@mail.gmail.com>
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
^ permalink raw reply
* [PATCH] Spell __attribute__ correctly in cache.h.
From: Jason Riedy @ 2005-08-19 4:10 UTC (permalink / raw)
To: git
Sun's cc doesn't know __attribute__.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
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
/*
^ permalink raw reply
* Re: Merge conflicts as .rej .orig files
From: Linus Torvalds @ 2005-08-19 4:29 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f9050818200625d64a12@mail.gmail.com>
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
^ permalink raw reply
* Re: Questions on 'cvs migration guide''
From: Linus Torvalds @ 2005-08-19 4:33 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f9050818201717f9ed93@mail.gmail.com>
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
^ permalink raw reply
* Re: Questions on 'cvs migration guide''
From: Martin Langhoff @ 2005-08-19 5:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: GIT
In-Reply-To: <Pine.LNX.4.58.0508182130050.3412@g5.osdl.org>
On 8/19/05, Linus Torvalds <torvalds@osdl.org> 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
^ permalink raw reply
* [RFC] Importing from a patch-oriented SCM
From: Martin Langhoff @ 2005-08-19 7:04 UTC (permalink / raw)
To: GIT
I am drafting an import script to turn a GNU Arch into a GIT archive.
Importing the branches and commits increamentally is reasonably
straightforward -- or so it seems so far. Note: the repository
manipulation is based on cvsimport -- so my knowledge of the git repo
internals is still pertty close to zero.
Each patchset has a unique identifier, and can carry metadata with the
identifiers of the patches it "includes". If you are using gnu arch,
when you merge across branches, it'll know to skip a particular
patchset if it has been applied already. AFAICT there is no such
concept in GIT, and I wonder what to do with all this metadata about
merges.
My proto-plan is to keep track of merged stuff (in a cache file
somewhere), and if a particular merge means that the branches are
fully merged up to the last patch of the series (if no commits from
the source branch have been skipped) mark it as a merge in GIT.
If the merges have been done out-of-order, that may show up in the
latest merge. For example, branch A and B of the same project each
have 10 commits from the branching point. If a merge A -> B does
commits 1,2,3,7,8 it gets imported to git as a merge up to commit "3",
although there is more there. The next merge, which does 4,5,6,10 will
show up as a merge of commit 8.
Yuk.
If I remember correctly, Junio added some stuff in the merge & rebase
code that will identify if a particular patch has been seen and
applied, and skip it even if it's a bit out of order. But I don't know
what that is based on, and whether I can somehow maximize the chances
of the patch being identified as already merged across branches. If
it's based on the initial commit identifier being carried through
(does that travel with commits when you merge?) I stand a small
chance. Otherwise, I'm lost.
Suggestions?
cheers,
martin
^ 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