* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Petr Baudis @ 2005-07-22 23:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221640050.6074@g5.osdl.org>
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Sat, 23 Jul 2005, Petr Baudis wrote:
> >
> > Yes, but this stuff is not for personal preferences. It is for
> > project-wide preferences and policies, which can be still normally
> > overridden or altered locally in each repository.
>
> What you are describing is a nightmare.
>
> Let's assume that a user alters the settings locally.
>
> EVERY SINGLE TIME he does a "cg-commit", those local alterations would get
> committed, since that config file is part of the same project, and cogito
> by default commits all changes.
No, no, no. A user does not alter the settings locally in .gitinfo/ -
.gitinfo/ is for per-_project_ stuff, not per-user. If user wants an
override, he does it per-repository in his .git/conf directory, which is
not version-tracked (actually, core GIT does not even let me to).
> That's just insane. It means that in practive it's simply not reasonable
> to have your own local copies of that file. So what would you do? You'd
> add more and more hacks to cover this up, and have a "commit-ignore" file
> that ignores the .gitinfo files etc etc. UGLY. All because of a design
> mistake.
Actually, commit-ignore might be useful in other cases, e.g. when
someone (me, a thousand times in the past) needs to keep temporary hacks
in the Makefile so that he can actually build the thing on his weird
system etc. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH 0/2] apply.c: a fix and an enhancement
From: Junio C Hamano @ 2005-07-23 0:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: A Large Angry SCM, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.58.0507221619450.6074@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> In other words, if it's per-project, then that implies that every single
> developer has to agree on the same thing. Which just not possible - it
> makes no sense.
I agree 75%. See the bottom for the rest 25%.
> In contrast, if you have a separate local _branch_ that maintains a
> ".gitinfo" totally separately (no common commits at all), then you can
> choose to propagate/participate in that branch or not, as you wish, on a
> per-developer basis.
Ah, finally the lightbulb moment. And I think what you outlined
using "git switch" in another message is a clean way to do it if
somebody wanted to.
> For example, what if I tried to dig out even _more_ information than what
> is in the BK CVS archives? Or if I wanted to have just the 2.6.0->
> history?
Good examples; I stand corrected. That is also per "group of
people who share the same view", i.e. per-developer thing that
may be propagated among consenting branch participants.
> What you're saying is that people can be happy if they just
> don't use a stupid decision. That's a sure sign that the
> decision shouldn't have been made in the first place.
I am not saying it that strongly. Rather, people can be happy
if they do not have to use a decision that they feel stupid.
In circles you are part of, especially in a project like the
kernel where hundreds of people participate worldwode, I can see
that having project-wide preference (or policy) and maintaining
it may not make _any_ sense.
But on the other hand, it is my understanding that it is a
common practice to enforce some centralized policy (I am
thinking about pre-commit hooks in particular) in a corporate
settings, and for people wanting to have that kind of thing, it
is not even a stupid decision.
^ permalink raw reply
* [PATCH 6/9] Cleanup: git-verify-tag-script
From: Junio C Hamano @ 2005-07-23 0:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
From: Eric W. Biederman <ebiederm@xmission.com>
Date: 1121545120 -0600
- Use git-rev-parse to allow sha1 tags references
- When the tag does not verify set an appropriate exit status
- Use git-sh-setup-script to verify the .git directory
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-verify-tag-script | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
c83d38d1dc23f205bb8758fe695b0b4b47601b2e
diff --git a/git-verify-tag-script b/git-verify-tag-script
--- a/git-verify-tag-script
+++ b/git-verify-tag-script
@@ -1,9 +1,8 @@
#!/bin/sh
-GIT_DIR=${GIT_DIR:-.git}
+. git-sh-setup-script || die "Not a git archive"
-tag=$1
-[ -f "$GIT_DIR/refs/tags/$tag" ] && tag=$(cat "$GIT_DIR/refs/tags/$tag")
+tag=$(git-rev-parse $1) || exit 1
git-cat-file tag $tag > .tmp-vtag || exit 1
-cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag -
+cat .tmp-vtag | sed '/-----BEGIN PGP/Q' | gpg --verify .tmp-vtag - || exit 1
rm -f .tmp-vtag
^ permalink raw reply
* [PATCH 9/9] Document "curl" requirements.
From: Junio C Hamano @ 2005-07-23 0:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Not just libcurl, but now we require curl executable as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
INSTALL | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
b300e6d28fc160ddc6685bde96b6bc9a710e01c3
diff --git a/INSTALL b/INSTALL
--- a/INSTALL
+++ b/INSTALL
@@ -41,8 +41,10 @@ Issues of note:
can avoid the bignum support by excising git-rev-list support
for "--merge-order" (by hand).
- - "libcurl". git-http-pull uses this. You can disable building of
- that program if you just want to get started.
+ - "libcurl" and "curl" executable. git-http-pull and
+ git-fetch-script use them. If you do not use http
+ transfer, you are probabaly OK if you do not have
+ them.
- "GNU diff" to generate patches. Of course, you don't _have_ to
generate patches if you don't want to, but let's face it, you'll
^ permalink raw reply
* [PATCH 4/9] debian/ fixes
From: Junio C Hamano @ 2005-07-23 0:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
From: Ryan Anderson <ryan@michonline.com>
Date: 1121822267 -0400
Make debian/rules executable, and correct the spelling of rsync in
debian/control.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
debian/control | 2 +-
debian/rules | 0
2 files changed, 1 insertions(+), 1 deletions(-)
mode change 100644 => 100755 debian/rules
576a7b14f41e0dc97b45b47b44ba24d4cbe1c789
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${shlibs:Depends}, shellutils, diff, rysnc, rcs
+Depends: ${shlibs:Depends}, shellutils, diff, rsync, rcs
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
and flexible filesystem-based database designed to store directory trees
diff --git a/debian/rules b/debian/rules
old mode 100644
new mode 100755
^ permalink raw reply
* [PATCH 5/9] Fix a typo in git-unpack-objects documentation.
From: Junio C Hamano @ 2005-07-23 0:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
From: Jan Veldeman <jan@mind.be>
Date: 1121810349 -0700
Fix a typo in git-unpack-objects documentation.
Signed-off-by: Jan Veldeman <jan@mind.be>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-unpack-objects.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
cbb150edd69cb7f726a9895ecae9cae276402c3e
diff --git a/Documentation/git-unpack-objects.txt b/Documentation/git-unpack-objects.txt
--- a/Documentation/git-unpack-objects.txt
+++ b/Documentation/git-unpack-objects.txt
@@ -4,7 +4,7 @@ v0.1, July 2005
NAME
----
-git-unpack-objects - Create a packed archive of objects.
+git-unpack-objects - Unpack objects from a packed archive.
SYNOPSIS
^ permalink raw reply
* [PATCH 7/9] Install git-verify-tag-script
From: Junio C Hamano @ 2005-07-23 0:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
From: Eric W. Biederman <ebiederm@xmission.com>
Date: 1121545164 -0600
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
858d9f99d6ff1946c82e0dd191c4bb6a0d737d39
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,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-branch-script git-parse-remote git-verify-tag-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 \
^ permalink raw reply
* [PATCH 8/9] Support more http features: https no cert, .netrc -> auth
From: Junio C Hamano @ 2005-07-23 0:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
From: Darrin Thompson <darrint@progeny.com>
Date: 1121220760 -0500
Cause setting environment variable GIT_SSL_NO_VERIFY to turn off
curl's ssl peer verification.
Only use curl for http transfers, instead of curl and wget.
Make curl check ~/.netrc for credentials.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-fetch-script | 7 +++++--
http-pull.c | 6 ++++++
2 files changed, 11 insertions(+), 2 deletions(-)
1041908edea29758af81ac9452484cfc652f455c
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -9,8 +9,11 @@ merge_store="$_remote_store"
TMP_HEAD="$GIT_DIR/TMP_HEAD"
case "$merge_repo" in
-http://*)
- head=$(wget -q -O - "$merge_repo/$merge_head") || exit 1
+http://* | https://*)
+ if [ -n "$GIT_SSL_NO_VERIFY" ]; then
+ curl_extra_args="-k"
+ fi
+ head=$(curl -ns $curl_extra_args "$merge_repo/$merge_head") || exit 1
echo Fetching "$merge_head" using http
git-http-pull -v -a "$head" "$merge_repo/"
;;
diff --git a/http-pull.c b/http-pull.c
--- a/http-pull.c
+++ b/http-pull.c
@@ -16,6 +16,8 @@ static z_stream stream;
static int local;
static int zret;
+static int curl_ssl_verify;
+
struct buffer
{
size_t posn;
@@ -173,6 +175,10 @@ int main(int argc, char **argv)
curl = curl_easy_init();
+ curl_ssl_verify = gitenv("GIT_SSL_NO_VERIFY") ? 0 : 1;
+ curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, curl_ssl_verify);
+ curl_easy_setopt(curl, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
+
base = url;
if (pull(commit_id))
^ permalink raw reply
* Various fixes and cleanups.
From: Junio C Hamano @ 2005-07-23 2:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I'll be sending these next:
[PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF
[PATCH] git-branch: avoid getting confused by empty or nonexisting branches.
[PATCH] Audit rev-parse users.
[PATCH] Install tools with "make install-tools".
[PATCH] Test framework: prettyprint the failed command.
[PATCH] git-clone-script: store where we cloned from in .git/branches/origin
They are various minor fixes and clean-ups.
^ permalink raw reply
* [PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF
From: Junio C Hamano @ 2005-07-23 2:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The git-rev-parse command uses LF to separate each argument it
parses, so its users at least need to set IFS to LF to be able
to handle filenames with embedded SPs and TABs. Some commands,
however, can take and do expect arguments with embedded LF,
notably, "-S" (pickaxe) of diff family, so even this workaround
does not work for them.
When --sq flag to git-rev-parse is given, instead of showing one
argument per line, it outputs arguments quoted for consumption
with "eval" by the caller, to remedy this situation.
As an example, this patch converts git-whatchanged to use this
new feature.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-whatchanged | 9 ++++++---
rev-parse.c | 34 +++++++++++++++++++++++++++++++---
2 files changed, 37 insertions(+), 6 deletions(-)
707db3532150cc9b1a6a61c66e7533dd7383093d
diff --git a/git-whatchanged b/git-whatchanged
--- a/git-whatchanged
+++ b/git-whatchanged
@@ -1,4 +1,7 @@
#!/bin/sh
-git-rev-list $(git-rev-parse --default HEAD --revs-only "$@") |
- git-diff-tree --stdin --pretty -r $(git-rev-parse --no-revs "$@") |
- LESS="$LESS -S" ${PAGER:-less}
+rev_list_args=$(git-rev-parse --sq --default HEAD --revs-only "$@") &&
+diff_tree_args=$(git-rev-parse --sq --no-revs "$@") &&
+
+eval "git-rev-list $rev_list_args" |
+eval "git-diff-tree --stdin --pretty -r $diff_tree_args" |
+LESS="$LESS -S" ${PAGER:-less}
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -15,6 +15,7 @@ static int do_rev_argument = 1;
static int output_revs = 0;
static int flags_only = 0;
static int no_flags = 0;
+static int output_sq = 0;
#define NORMAL 0
#define REVERSED 1
@@ -49,19 +50,42 @@ static int is_rev_argument(const char *a
}
}
+static void show(const char *arg)
+{
+ if (output_sq) {
+ int sq = '\'', ch;
+
+ putchar(sq);
+ while ((ch = *arg++)) {
+ if (ch == sq)
+ fputs("'\\'", stdout);
+ putchar(ch);
+ }
+ putchar(sq);
+ putchar(' ');
+ }
+ else
+ puts(arg);
+}
+
static void show_rev(int type, const unsigned char *sha1)
{
if (no_revs)
return;
output_revs++;
- printf("%s%s\n", type == show_type ? "" : "^", sha1_to_hex(sha1));
+
+ /* Hexadecimal string plus possibly a carret;
+ * this does not have to be quoted even under output_sq.
+ */
+ printf("%s%s%c", type == show_type ? "" : "^", sha1_to_hex(sha1),
+ output_sq ? ' ' : '\n');
}
static void show_rev_arg(char *rev)
{
if (no_revs)
return;
- puts(rev);
+ show(rev);
}
static void show_norev(char *norev)
@@ -70,7 +94,7 @@ static void show_norev(char *norev)
return;
if (revs_only)
return;
- puts(norev);
+ show(norev);
}
static void show_arg(char *arg)
@@ -328,6 +352,10 @@ int main(int argc, char **argv)
single_rev = 1;
continue;
}
+ if (!strcmp(arg, "--sq")) {
+ output_sq = 1;
+ continue;
+ }
if (!strcmp(arg, "--not")) {
show_type ^= REVERSED;
continue;
^ permalink raw reply
* [PATCH] git-branch: avoid getting confused by empty or nonexisting branches.
From: Junio C Hamano @ 2005-07-23 2:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
When not specifying the start point explicitly, we ended up
emitting ^0 in addition to the default HEAD. Be careful to see
if we have "$2" before finding out which commit to base the new
branch on.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-branch-script | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
baf3c4ffceae925d836f19382611968699414cd6
diff --git a/git-branch-script b/git-branch-script
--- a/git-branch-script
+++ b/git-branch-script
@@ -3,7 +3,13 @@
. git-sh-setup-script || die "Not a git archive"
branchname="$1"
-rev=$(git-rev-parse --verify --default HEAD "$2"^0) || exit
+case "$2" in
+'')
+ head=HEAD ;;
+*)
+ head="$2^0" ;;
+esac
+rev=$(git-rev-parse --revs-only --verify "$head") || exit
[ -z "$branchname" ] && die "git branch: I want a branch name"
[ -e "$GIT_DIR/refs/heads/$branchname" ] && die "$branchname already exists"
^ permalink raw reply
* [PATCH] Test framework: prettyprint the failed command.
From: Junio C Hamano @ 2005-07-23 2:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
The output from a failure case had the test description message
and the first line of the actual test script concatenated on the
same line, which was ugly. Correct the output routine a bit to
make it more readable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
t/test-lib.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
ba7b8ae0b3af6040c8af2f4e381bd4c30ab9cd24
diff --git a/t/test-lib.sh b/t/test-lib.sh
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -84,7 +84,9 @@ test_ok_ () {
test_failure_ () {
test_count=$(expr "$test_count" + 1)
test_failure=$(expr "$test_failure" + 1);
- say "FAIL $test_count: $@"
+ say "FAIL $test_count: $1"
+ shift
+ echo "$@" | sed -e 's/^/ /'
test "$immediate" == "" || exit 1
}
^ permalink raw reply
* [PATCH] Audit rev-parse users.
From: Junio C Hamano @ 2005-07-23 2:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
This patch changes rev-parse users that pass a single argument
that is supposed to be a rev parameter to use "--verify".
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-checkout-script | 2 +-
git-cherry | 8 ++++----
git-commit-script | 2 +-
git-rebase-script | 8 ++++----
git-resolve-script | 4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
f3818c97f985fe20d24fe3d12cca5ce1cfbf8d74
diff --git a/git-checkout-script b/git-checkout-script
--- a/git-checkout-script
+++ b/git-checkout-script
@@ -22,7 +22,7 @@ while [ "$#" != "0" ]; do
force=1
;;
*)
- rev=$(git-rev-parse --verify --revs-only "$arg^0") || exit
+ rev=$(git-rev-parse --verify "$arg^0") || exit
if [ -z "$rev" ]; then
echo "unknown flag $arg"
exit 1
diff --git a/git-cherry b/git-cherry
--- a/git-cherry
+++ b/git-cherry
@@ -28,11 +28,11 @@ The output is intended to be used as:
'
case "$#" in
-1) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse HEAD` || exit
+1) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse "$2"` || exit
+2) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -16,7 +16,7 @@ do
-m) shift
case "$#" in
0) usage ;;
- *) use_commit=`git-rev-parse "$1"` ||
+ *) use_commit=`git-rev-parse --verify "$1"` ||
exit ;;
esac
;;
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -11,11 +11,11 @@ upstream tree.'
: ${GIT_DIR=.git}
case "$#" in
-1) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse HEAD` || exit
+1) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse "$1"` &&
- junio=`git-rev-parse "$2"` || exit
+2) linus=`git-rev-parse --verify "$1"` &&
+ junio=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
diff --git a/git-resolve-script b/git-resolve-script
--- a/git-resolve-script
+++ b/git-resolve-script
@@ -6,8 +6,8 @@
#
. git-sh-setup-script || die "Not a git archive"
-head=$(git-rev-parse --revs-only "$1")
-merge=$(git-rev-parse --revs-only "$2")
+head=$(git-rev-parse --verify "$1")
+merge=$(git-rev-parse --verify "$2")
merge_msg="$3"
dropheads() {
^ permalink raw reply
* [PATCH] Install tools with "make install-tools".
From: Junio C Hamano @ 2005-07-23 2:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Match the main Makefile by separating COPTS from CFLAGS,
defining INSTALL, prefix, and bin. Add a new target 'install-tools'
to the main Makefile to install them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 4 ++++
tools/Makefile | 13 +++++++++++--
2 files changed, 15 insertions(+), 2 deletions(-)
b0189708a35914c504e7bfa8914d1f5ff029a3a4
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -195,12 +195,16 @@ test: all
doc:
$(MAKE) -C Documentation all
+install-tools:
+ $(MAKE) -C tools install
+
install-doc:
$(MAKE) -C Documentation install
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
rm -f git-core-*.tar.gz git-core.spec
+ $(MAKE) -C tools/ clean
$(MAKE) -C Documentation/ clean
backup: clean
diff --git a/tools/Makefile b/tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -1,6 +1,14 @@
+#
+# Make Linus git-tools
+#
CC=gcc
-CFLAGS=-Wall -O2
+COPTS=-O2
+CFLAGS=-g $(COPTS) -Wall
+INSTALL=install
HOME=$(shell echo $$HOME)
+prefix=$(HOME)
+bin=$(prefix)/bin
+# dest=
PROGRAMS=mailsplit mailinfo
SCRIPTS=applymbox applypatch
@@ -8,7 +16,8 @@ SCRIPTS=applymbox applypatch
all: $(PROGRAMS)
install: $(PROGRAMS) $(SCRIPTS)
- cp -f $(PROGRAMS) $(SCRIPTS) $(HOME)/bin/
+ $(INSTALL) -m755 -d $(dest)$(bin)
+ $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(dest)$(bin)
clean:
rm -f $(PROGRAMS) *.o
^ permalink raw reply
* [PATCH] git-clone-script: store where we cloned from in .git/branches/origin
From: Junio C Hamano @ 2005-07-23 2:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
A bit more usability enhancement, while retaining Cogito
compatibility.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Just after sending I noticed that the first hunk is a pure
*** bugfix. Hope you do not mind...
git-clone-script | 41 +++++++++++++++++++++++------------------
1 files changed, 23 insertions(+), 18 deletions(-)
170214e3ccecc995e4f5c2567f9542a8de8cfc65
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -20,12 +20,12 @@ upload_pack=
while
case "$#,$1" in
0,*) break ;;
- *,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
+ *,-l|*,--l|*,--lo|*,--loc|*,--loca|*,--local) use_local=yes ;;
*,-q|*,--quiet) quiet=-q ;;
- 1,-u|*,--upload-pack) usage ;;
+ 1,-u|1,--upload-pack) usage ;;
*,-u|*,--upload-pack)
shift
- upload_pack="--exec=$2" ;;
+ upload_pack="--exec=$1" ;;
*,-*) usage ;;
*) break ;;
esac
@@ -81,23 +81,28 @@ yes,yes)
HEAD=HEAD
fi
tar Ccf "$repo" - refs $HEAD | tar Cxf "$D/.git" - || exit 1
- exit 0
- ;;
-esac
-
-case "$repo" in
-rsync://*)
- rsync $quiet -avz --ignore-existing "$repo/objects/" "$D/.git/objects/" &&
- rsync $quiet -avz --ignore-existing "$repo/refs/" "$D/.git/refs/"
- ;;
-http://*)
- echo "Somebody should add http fetch" >&2
- exit 1
;;
*)
- cd "$D" && case "$upload_pack" in
- '') git-clone-pack $quiet "$repo" ;;
- *) git-clone-pack $quiet "$upload_pack" "$repo" ;;
+ case "$repo" in
+ rsync://*)
+ rsync $quiet -avz --ignore-existing "$repo/objects/" "$D/.git/objects/" &&
+ rsync $quiet -avz --ignore-existing "$repo/refs/" "$D/.git/refs/"
+ ;;
+ http://*)
+ echo "Somebody should add http fetch" >&2
+ exit 1
+ ;;
+ *)
+ cd "$D" && case "$upload_pack" in
+ '') git-clone-pack $quiet "$repo" ;;
+ *) git-clone-pack $quiet "$upload_pack" "$repo" ;;
+ esac
+ ;;
esac
;;
esac
+
+# Update origin.
+mkdir -p "$D/.git/branches/" &&
+rm -f "$D/.git/branches/origin" &&
+echo "$repo" >"$D/.git/branches/origin"
^ permalink raw reply
* [PATCH] tutorial: mention "git clone" records .git/branches/origin
From: Junio C Hamano @ 2005-07-23 2:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Update the recommended workflow for individual developers.
While they are tracking the origin, refs/heads/origin is updated
by "git fetch", so there is no need to manually copy FETCH_HEAD
to refs/heads/ anywhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/tutorial.txt | 48 ++++++++++++++++++++------------------------
1 files changed, 22 insertions(+), 26 deletions(-)
6a1a7bd322037c65a4325798ddd76024d99dff3d
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -1042,7 +1042,8 @@ A recommended work cycle for a "subsyste
on that project and has own "public repository" goes like this:
(1) Prepare your work repository, by "git clone" the public
- repository of the "project lead".
+ repository of the "project lead". The URL used for the
+ initial cloning is stored in .git/branches/origin.
(2) Prepare a public repository accessible to others.
@@ -1051,7 +1052,7 @@ on that project and has own "public repo
currently not automated.
(4) Push into the public repository from your primary
- repository. Run "git repack" (and possibly "git
+ repository. Run "git repack", and possibly "git
prune-packed" if the transport used for pulling from your
repository supports packed repositories.
@@ -1076,30 +1077,25 @@ A recommended work cycle for an "individ
not have a "public" repository is somewhat different. It goes
like this:
- (1) Prepare your work repositories, by "git clone" the public
- repository of the "project lead" (or "subsystem
- maintainer", if you work on a subsystem).
-
- (2) Copy .git/refs/master to .git/refs/upstream.
-
- (3) Do your work there. Make commits.
-
- (4) Run "git fetch" from the public repository of your upstream
- every once in a while. This does only the first half of
- "git pull" but does not merge. The head of the public
- repository is stored in .git/FETCH_HEAD. Copy it in
- .git/refs/heads/upstream.
-
- (5) Use "git cherry" to see which ones of your patches were
- accepted, and/or use "git rebase" to port your unmerged
- changes forward to the updated upstream.
-
- (6) Use "git format-patch upstream" to prepare patches for
- e-mail submission to your upstream and send it out.
- Go back to step (3) and continue.
-
-[Side Note: I think Cogito calls this upstream "origin".
- Somebody care to confirm or deny? ]
+ (1) Prepare your work repository, by "git clone" the public
+ repository of the "project lead" (or a "subsystem
+ maintainer", if you work on a subsystem). The URL used for
+ the initial cloning is stored in .git/branches/origin.
+
+ (2) Do your work there. Make commits.
+
+ (3) Run "git fetch origin" from the public repository of your
+ upstream every once in a while. This does only the first
+ half of "git pull" but does not merge. The head of the
+ public repository is stored in .git/refs/heads/origin.
+
+ (4) Use "git cherry origin" to see which ones of your patches
+ were accepted, and/or use "git rebase origin" to port your
+ unmerged changes forward to the updated upstream.
+
+ (5) Use "git format-patch origin" to prepare patches for e-mail
+ submission to your upstream and send it out. Go back to
+ step (2) and continue.
[ to be continued.. cvsimports ]
^ permalink raw reply
* [PATCH] Deb packages should include the binaries (Try 2 - this time it actually applies)
From: Junio C Hamano @ 2005-07-23 5:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
From: Ryan Anderson <ryan@michonline.com>
Date: 1122011756 -0400
The Deb packages were missing a dependency on "build install" from the
binary target - this fixes that, and cleans up some inconsistencies
elsewhere in the rulesets.
Traditionally, Debian packaging uses a file called "build-stamp" (or
"install-stamp", etc) in the main source tree. The initial deb package
support for Git tried to move this "build-stamp" file into the debian/
directory, but some instances were missed. That problem, however, was
incidental - the real fix is the missing dependency mentioned above.
(version 2 of this patch. I missed an early commit in v1 that made the old
patch impossible to apply.)
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
debian/changelog | 8 +++++++-
debian/control | 2 +-
debian/rules | 10 +++++-----
3 files changed, 13 insertions(+), 7 deletions(-)
469775a2f3b479cd4bbd930754e59601a7132f68
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,11 @@
+git-core (0.99-1) unstable; urgency=low
+
+ * Update deb package support to build correctly.
+
+ -- Ryan Anderson <ryan@michonline.com> Thu, 21 Jul 2005 02:03:32 -0400
+
git-core (0.99-0) unstable; urgency=low
-
+
* Initial deb package support
-- Eric Biederman <ebiederm@xmission.com> Tue, 12 Jul 2005 10:57:51 -0600
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${shlibs:Depends}, shellutils, diff, rsync, rcs
+Depends: ${misc:Depends}, shellutils, diff, rsync, rcs
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
and flexible filesystem-based database designed to store directory trees
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -21,8 +21,8 @@ DESTDIR := $(CURDIR)/debian/tmp
DOC_DESTDIR := $(DESTDIR)/usr/share/doc/git-core/
MAN_DESTDIR := $(DESTDIR)/$(MANDIR)
-build: build-stamp
-build-stamp:
+build: debian/build-stamp
+debian/build-stamp:
dh_testdir
$(MAKE) all doc
touch debian/build-stamp
@@ -36,7 +36,7 @@ debian-clean:
clean: debian-clean
$(MAKE) clean
-install: debian/build-stamp
+install: build
dh_testdir
dh_testroot
dh_clean -k
@@ -47,9 +47,9 @@ install: debian/build-stamp
mkdir -p $(DOC_DESTDIR)
find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'
- dh_install --sourcedir=$(DESTDIR)
+ dh_install --list-missing --sourcedir=$(DESTDIR)
-binary:
+binary: build install
dh_testdir
dh_testroot
dh_installchangelogs
^ permalink raw reply
* [PATCH] Deb packaging needs two more configuration files
From: Junio C Hamano @ 2005-07-23 5:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
From: Ryan Anderson <ryan@michonline.com>
Date: 1122014167 -0400
The deb package building needs these two new files to work correctly.
debian/compat sets the rules under which the debhelper scripts (dh_*) operate.
debian/git-core.install tells dh_install what files to install in each package
that is generated. There is only one package being generated, so all files go
into it.
(I missed these in the last patch, mostly because I needed to do this to
find stuff I had missed:
find . -name .git -type d -prune -o -type f -print \
| grep -v -e .tree1 -e .tree2 \
| sed -e "s/^\.\///" \
| sort >.tree1
git-ls-files | grep -v -e .tree1 -e .tree2 \
| sort >.tree2
diff -u .tree1 .tree2
)
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
debian/compat | 1 +
debian/git-core.install | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 debian/compat
create mode 100644 debian/git-core.install
1d3ca8896651928adb5ec138b32c8bc3700fc0a6
diff --git a/debian/compat b/debian/compat
new file mode 100644
--- /dev/null
+++ b/debian/compat
@@ -0,0 +1 @@
+4
diff --git a/debian/git-core.install b/debian/git-core.install
new file mode 100644
--- /dev/null
+++ b/debian/git-core.install
@@ -0,0 +1 @@
+*
^ permalink raw reply
* [PATCH] GIT: Try all addresses for given remote name
From: Junio C Hamano @ 2005-07-23 5:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, yoshfuji
From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: 1121951436 -0400
Try all addresses for given remote name until it succeeds.
Also supports IPv6.
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** Linus, I am not ACKing Hideaki's other change on the
*** daemon.c side at this moment; Pasky raised two good points
*** and I expect Hideaki will resubmit (either modified or as
*** is).
connect.c | 71 +++++++++++++++++++++++++++++++++++++------------------------
1 files changed, 43 insertions(+), 28 deletions(-)
42210dd815647c3d4b71142a8a43de5a009485b2
diff --git a/connect.c b/connect.c
--- a/connect.c
+++ b/connect.c
@@ -96,42 +96,57 @@ static enum protocol get_protocol(const
die("I don't handle protocol '%s'", name);
}
-static void lookup_host(const char *host, struct sockaddr *in)
-{
- struct addrinfo *res;
- int ret;
-
- ret = getaddrinfo(host, NULL, NULL, &res);
- if (ret)
- die("Unable to look up %s (%s)", host, gai_strerror(ret));
- *in = *res->ai_addr;
- freeaddrinfo(res);
-}
+#define STR_(s) # s
+#define STR(s) STR_(s)
static int git_tcp_connect(int fd[2], const char *prog, char *host, char *path)
{
- struct sockaddr addr;
- int port = DEFAULT_GIT_PORT, sockfd;
- char *colon;
-
- colon = strchr(host, ':');
- if (colon) {
- char *end;
- unsigned long n = strtoul(colon+1, &end, 0);
- if (colon[1] && !*end) {
- *colon = 0;
- port = n;
+ int sockfd = -1;
+ char *colon, *end;
+ char *port = STR(DEFAULT_GIT_PORT);
+ struct addrinfo hints, *ai0, *ai;
+ int gai;
+
+ if (host[0] == '[') {
+ end = strchr(host + 1, ']');
+ if (end) {
+ *end = 0;
+ end++;
+ host++;
+ } else
+ end = host;
+ } else
+ end = host;
+ colon = strchr(end, ':');
+
+ if (colon)
+ port = colon + 1;
+
+ memset(&hints, 0, sizeof(hints));
+ hints.ai_socktype = SOCK_STREAM;
+ hints.ai_protocol = IPPROTO_TCP;
+
+ gai = getaddrinfo(host, port, &hints, &ai);
+ if (gai)
+ die("Unable to look up %s (%s)", host, gai_strerror(gai));
+
+ for (ai0 = ai; ai; ai = ai->ai_next) {
+ sockfd = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
+ if (sockfd < 0)
+ continue;
+ if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
+ close(sockfd);
+ sockfd = -1;
+ continue;
}
+ break;
}
- lookup_host(host, &addr);
- ((struct sockaddr_in *)&addr)->sin_port = htons(port);
+ freeaddrinfo(ai0);
- sockfd = socket(PF_INET, SOCK_STREAM, IPPROTO_IP);
if (sockfd < 0)
- die("unable to create socket (%s)", strerror(errno));
- if (connect(sockfd, (void *)&addr, sizeof(addr)) < 0)
- die("unable to connect (%s)", strerror(errno));
+ die("unable to connect a socket (%s)", strerror(errno));
+
fd[0] = sockfd;
fd[1] = sockfd;
packet_write(sockfd, "%s %s\n", prog, path);
^ permalink raw reply
* [PATCH] Deb Packaging fixes: Build against Mozilla libs for Debian, conflict with "git"
From: Ryan Anderson @ 2005-07-23 7:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano, Sebastian Kuzminsky
This patch includes two fixes to the git-core Debian package:
* Conflict with the GNU Interactive Tools package, which _also_
wants to install /usr/bin/git.
* Compile against the unencumbered Mozilla SHA1 code, instead of
the iffy OpenSSL code. This makes it easier to get the package
included for distribution with Debian.
Note: Assumes that Ryan Anderson's patch "Deb packages should include
the binaries" has been applied.
(Note - I fixed up the conflicts against my earlier packaging fixes -- Ryan)
Signed-off-by: Sebastian Kuzminsky <seb@highlab.com>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
debian/changelog | 11 +++++++++++
debian/control | 3 ++-
debian/rules | 14 ++++++++++++++
3 files changed, 27 insertions(+), 1 deletions(-)
c651cdc175712c26d4b9c8b75b44a89eb1b74752
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+git-core (0.99.1-1) unstable; urgency=low
+
+ * Conflict with the GNU Interactive Tools package, which also installs
+ /usr/bin/git.
+ * Dont compile against the OpenSSL SHA1 code, it's problematically
+ licensed. Instead use the PPC assembly on PPC, and the code ripped
+ from Mozilla everywhere else.
+ * Minor tweaks to the Build-Depends.
+
+ -- Sebastian Kuzminsky <seb@highlab.com> Thu, 21 Jul 2005 01:28:35 -0600
+
git-core (0.99-1) unstable; urgency=low
* Update deb package support to build correctly.
diff --git a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,8 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
-Depends: ${misc:Depends}, shellutils, diff, rsync, rcs
+Depends: ${misc:Depends}, patch, diff, rsync, rcs, wget, rsh-client
+Conflicts: git
Description: The git content addressable filesystem
GIT comes in two layers. The bottom layer is merely an extremely fast
and flexible filesystem-based database designed to store directory trees
diff --git a/debian/rules b/debian/rules
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +12,20 @@ else
endif
export CFLAGS
+#
+# On PowerPC we compile against the hand-crafted assembly, on all
+# other architectures we compile against GPL'ed sha1 code lifted
+# from Mozilla. OpenSSL is strangely licensed and best avoided
+# in Debian.
+#
+HOST_ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
+ifeq (${HOST_ARCH},powerpc)
+ export PPC_SHA1=YesPlease
+else
+ export MOZILLA_SHA1=YesPlease
+endif
+
+
PREFIX := /usr
MANDIR := /usr/share/man/
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [PATCH] Add git-find-new-files to spot files added to the tree, but not the repository
From: Ryan Anderson @ 2005-07-23 7:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Add git-find-new-files to find files that are in the tree, but not checked into the repository.
Most users will probably want to "make clean" before using this for real
significant changes, as it does such a good job that it finds binaries that
just got built.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
Makefile | 2 +-
git-find-new-files | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 1 deletions(-)
create mode 100755 git-find-new-files
028b21ae78dba3edab5e9b1a24cdf68011e42ab7
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -36,7 +36,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-branch-script git-parse-remote git-find-new-files
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-find-new-files b/git-find-new-files
new file mode 100755
--- /dev/null
+++ b/git-find-new-files
@@ -0,0 +1,48 @@
+#!/usr/bin/perl
+#
+# A simple script to take a look at all the files git knows about and compare
+# that to the files that we actually see in teh source tree, and output a
+# listing of the difference between them.
+#
+# The original command that did this is below, but a pure-Perl version can skip
+# the temp files.
+#
+# find . -name .git -type d -prune -o -type f -print \
+# | grep -v -e .tree1 -e .tree2 \
+# | sed -e "s/^\.\///" \
+# | sort >.tree1
+# git-ls-files | grep -v -e .tree1 -e .tree2 \
+# | sort >.tree2
+# diff -u .tree1 .tree2
+
+use warnings;
+use strict;
+
+# Since we're using NUL (ASCII value of 0) to terminate strings,
+# set the field separator to that:
+$/ = "\0";
+
+my (%actual,%git);
+
+open(F,"-|","find . -name .git -type d -prune -o -type f -print0")
+ or die "Failed to open pipe from find: " . $!;
+
+while(<F>) {
+ chomp;
+ s#^\./##;
+ $actual{$_}++;
+}
+close(F);
+
+open(F,"-|","git-ls-files -z")
+ or die "Failed to open pipe from git-ls-files: " . $!;
+
+while(<F>) {
+ chomp;
+ delete $actual{$_};
+}
+close(F);
+
+foreach my $f (sort keys %actual) {
+ printf("A\t%s\n",$f);
+}
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Last mile to 1.0?
From: Ryan Anderson @ 2005-07-23 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net>
On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:
> I do not know what release plan Linus has in mind, and also
> expect things to be quieter next week during OLS and kernel
> summit, but I think we are getting really really close.
Looking at the set of patches we just all dumped on Linus, I think they
pretty much show us that we don't have any major issues.
As I see it, the status is currently like this:
Revision control - Stable
Pulling locally or over rsync - Stable
Pushing over ssh - Stable
Remote, anonymous pulls not using rsync - Beta
Usability features[1] - Beta
Documentation - Alpha
My feeling is that we're pretty well set to do a 1.0 release.
1 - Usability features are all the things around git-apply,
git-format-patch, etc, that we're clearly working on to make life more
pleasant, but aren't really critical.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-23 8:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Petr Baudis, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <7vu0imh23q.fsf@assigned-by-dhcp.cox.net>
On Fri, 2005-07-22 at 16:07 -0700, Junio C Hamano wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> If signed-off-by is the only thing you are worried about, how
> about making it not part of the commit template and the message
> user touches with the editor? You first look at the user
> configuration somewhere to see if the user wants the
> signed-off-by line to his commits and with what value, and if
> the last lines of the edit result does not contain that value
> (to avoid duplicates), add it before feeding the message to
> git-commit-tree.
That's an idea.
Another problem with the template is when one wants a header as well as
footer (for things like '-*- mode: text; -*-'). Maybe something like
below would work:
GIT: your header
@DESCRIPTION@
GIT: your footer
GIT: @FILELIST@
where @DESCRIPTION@ is either a blank line for cogito or the existing
patch description for StGIT. One could also add a 'Signed-...' line when
the patch is first created (instead of a blank line).
For StGIT, one could add something like @PATCHNAME@ as well.
> > StGIT currently uses .git/exclude, since I saw it used by cogito. What
> > is dontdiff supposed to do? The 'git diff' command only shows the diff
> > for the files added to the repository.
>
> I see that what I wrote was vague and badly stated. Please
> forget about my mentioning "dontdiff". What I meant was your
> .git/exclude, Pasky's .gitignore file and friends.
.gitignore are note currently supported by StGIT but I'll add this.
> When you merge two projects like Linus did between git.git and
> gitk, obviously the person who is merging the two is responsible
> for merging the per-project default configuration and resolving
> conflicts. This probably should be overridable by individual
> developers who pull/fetch into their repository by having per-
> repository configuration.
The problem appears when one upstream maintainer changes the
configuration, should this be merged again? In this case you can get
conflicts.
> > For StGIT it makes sense to get some default settings via /etc/stgitrc.
> > There are things like a SMTP server and the diff3 command. These are set
> > when installing the application and can be overridden in your home
> > or .git directories.
>
> Exactly, but that is not specific to StGIT, I presume, and I did
> not want to hear "``For StGIT'' it makes sense". If StGIT needs
> to use "diff3" on a system, probably that is because "merge" is
> not available on that system. In that case, cogito needs to
> use it too, doesn't it?
This is not always the case. With StGIT you can define your own options
and tools for a three-way merge. This was implemented because Bryan
Larsen, I think, asked whether a different (smarter) tool could be used.
One might also want that when diff3 fails, a xxdiff or emacs should be
automatically started for the conflict files.
This could be simplified if we enforce the presence of a gitmerge.sh
file which only calls merge or diff3 by default. Users can create a new
file and put it in the $PATH.
> If we can make users and sysadmins not having to maintain two
> sets of configuration files for two Porcelains, if we
> can,... that is what I have been trying to address.
That's probably a good reason. Also people might use 2 Porcelains and
the plain git, they could have a common configuration, especially where
settings overlap.
> I think Petr already started the discussion rolling for commit
> templates, and I like his proposal.
I like it too.
> > That's the thing I didn't like in GNU Arch. You modify the file ignoring
> > rules for example and the change will be included in the next commit.
> > You could only get some defaults when cloning a repository, otherwise
> > once you have different preferences from the repository's maintainer,
> > you start getting conflicts in the config files.
>
> That's why I suggested to have "_git" (project wide default)
> separate from $GIT_DIR/info (repository owner's discretion), the
> latter overriding the former.
That's OK with one issue - git should be able to exclude _git when
generating a diff between 2 trees, unless one can enforce the _git/*
files to be read-only.
Another option would be to have .git/info/<branch> and, with cogito for
example, .git/info/origin should always be pulled, even if the local
files were modified. You would override these settings
in .git/info/master. The problem is to define the branches order in
which the settings are read.
> > Again, having Porcelain specific options mixed in the same file might
> > lead to some confusion among users.
>
> True. We need to be careful.
This could be avoided by using ini-like files (well, easy to read in
Python) and have [git] (for the common things like author name),
[cogito], [stgit] etc. sections.
> Or course, there is an option of not worry about Porcelain
> compatibilities at all --- which is certainly simpler. All we
> need is to make sure they do not use the same filename for
> conflicting purposes. If everybody feels that way then this
> discussion is moot and I apologize for wasting people's time.
I don't think this is a waste of time. It's useful to have at least some
basic conventions. StGIT places files all over the place but without any
convention, not even a .stgit extension.
The problem is how much similar we want the Porcelains to be regarding
the settings and the templates. For StGIT, it is much simpler to have
something like '%(FILELIST)s' rather than '@FILELIST@' in a template but
I have not problem with switching to a common syntax. But we should see
what can easily be changed.
I will write a list with what files StGIT uses and where they are placed
and we can agree on a structure. I think the .git/ directory usage is
more important to be clarified than having a common {git,cogito,stgit}rc
file.
--
Catalin
^ permalink raw reply
* Re: Last mile to 1.0?
From: Ryan Anderson @ 2005-07-23 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net>
On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:
> - Publicity. I would be very happy to see somebody with good
> writing and summarizing skills to prepare an article to be
> published on LWN.NET to coincide with the 1.0 release. An
> update to GIT traffic would also be nice.
How is this for a start?
Source Code Management with Git
Git, sometimes called "global information tracker", is a "directory
content manager". Git has been designed to handle absolutely massive
projects with speed and efficiency, and the release of the 2.6.12 and
(soon) the 2.6.13 version of the Linux kernel would indicate that it
does this task well.
Git falls into the category of distributed source code management tools,
similar to Arch or Darcs (or, in the commercial world, BitKeeper). This
means that every working directory is a full-fledged repository with
full revision tracking capabilities.
Git uses the SHA1 hash algorithm to provide a content-addressable pseudo
filesystem, complete with its own version of fsck.
o Speed of use, both for the project maintainer, and the end-users, is
a key development principle.
o The history is stored as a directed acyclic graph, making long-lived
branches and repeated merging simple.
o A collection of related projects are building on the core Git
project, either to provide an easier to use interface on top (Darcs,
Mercurial, StGit, Cogito), or to take some of the underlying concepts
and reimplement them directly into another system (Arch 2.0).
o Two, interchangeable, on-disk formats are used:
o An efficient, packed format that saves spaced and network
bandwidth.
o An unpacked format, optimized for fast writes and incremental
work.
Git results from the inspiration and frustration of Linus Torvalds, and
the enthusiastic help of over 300 participants on the development
mailing list.[1]
1 - Generated with the following, in a maildir folder:
find . -type f | xargs grep -h "^From:" | perl -ne \
'tr#A-Z#a-z#; m#<(.*)># && print $1,"\n";' | sort -u | wc -l
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-23 9:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Catalin Marinas, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <7vu0imh23q.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Jul 23, 2005 at 01:07:05AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>
> > Would such a template only have 'GIT:' prefixed lines? I usually put
> > another line like 'Signed-off-by:', for convenience. The problem with
> > StGIT appears when one wants to re-edit the patch description (stg
> > refresh -e), in which case the existing description should be merged
> > with a part of the template (if you want to get the editor setting for
> > example). It doesn't do this since there is no point in getting another
> > 'Signed...' line in the existing description.
>
> If signed-off-by is the only thing you are worried about, how
> about making it not part of the commit template and the message
> user touches with the editor? You first look at the user
> configuration somewhere to see if the user wants the
> signed-off-by line to his commits and with what value, and if
> the last lines of the edit result does not contain that value
> (to avoid duplicates), add it before feeding the message to
> git-commit-tree.
I would rather have something universal. Just avoid inserting duplicate
lines at the bottom.
> >> - standard "dontdiff/ignore" file.
> >
> > StGIT currently uses .git/exclude, since I saw it used by cogito. What
> > is dontdiff supposed to do? The 'git diff' command only shows the diff
> > for the files added to the repository.
>
> I see that what I wrote was vague and badly stated. Please
> forget about my mentioning "dontdiff". What I meant was your
> .git/exclude, Pasky's .gitignore file and friends.
Cogito supports .git/exclude too, but I'd rather rename it to
.git/ignore (or .git/conf/ignore) as well (gradually).
> >> - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
> >> such).
> >
> > StGIT works the other way around. By default uses the environment, which
> > can be overridden by the stgitrc file. I could change this easily.
>
> Again I was vague, and what you say StGIT does is exactly what I
> meant. I have one value in my environment coming from the login
> shell, and a per- repository preference item overrides it to
> something else.
I have it the other way around, with the rationale that your default
settings should be in your ~/.gitrc, not environment, which is always
the highest priority. The simple reason is that how would I apply the
patches of other people otherwise? Now I do
GIT_AUTHOR_NAME="Junio C Hamano" \
GIT_AUTHOR_EMAIL="junkio@cox.net" \
GIT_AUTHOR_DATE="2008-04-01 05:12:33" \
cg-commit
and it makes complete sense to me.
> > For StGIT it makes sense to get some default settings via /etc/stgitrc.
> > There are things like a SMTP server and the diff3 command. These are set
> > when installing the application and can be overridden in your home
> > or .git directories.
>
> Exactly, but that is not specific to StGIT, I presume, and I did
> not want to hear "``For StGIT'' it makes sense". If StGIT needs
> to use "diff3" on a system, probably that is because "merge" is
> not available on that system. In that case, cogito needs to
> use it too, doesn't it?
diff3 throws its output on stdout, AFAIK.
> If we can make users and sysadmins not having to maintain two
> sets of configuration files for two Porcelains, if we
> can,... that is what I have been trying to address.
Yes, but it is a bit secondary to me. The most important for me is that
meta-files inside the project itself (e.g. .gitignore) should be as
portable as possible, as that'd be the biggest hurdle. The second
priority for me is to make ~/.git/ as universal as possible. Having
common per-user/per-system configuration file as well is nice too, but
not so crucial.
> > Before we get to "where", we should define the common
> > settings. I think that git should define the common settings
> > for its operations and the other tools should follow them.
>
> Personally, unless it is something very obvious and basic, I do
> not think the core barebone Porcelain should be inventing
> arbitrary conventions and imposing them on other Porcelains.
> For very basic things I would agree.
>
> I think Petr already started the discussion rolling for commit
> templates, and I like his proposal. For ignore pattern files, I
> think what Cogito does sounds almost sensible [*1*] and I am
> sure StGIT have something similar. I do not see Linus and co
> jumping up and down saying git-status should detect and show new
> files not registered in the cache, so for now I'd propose to
> skip adding this one to the barebone Porcelain (meaning, this is
> an example of not "git defining the common and others following
> suite").
(Quite some things came to git from Cogito anyway. ;-) And well, that's
completely natural.)
> *1* I said "almost sensible" but it is not meant to blame Pasky.
> I think the --exclude mechanism in git-ls-files should be
> extended to allow not just the filename-sans-leading-directory
> match but a full relative-to-the-project-root path match. That
> way, cg-status would not have to run around in the tree to find
> individual .gitignore files.
>
> Personally, I think having to have ignore pattern like .cvsignore
> per-directory is simply _ugly_.
No, I think it's great. That increases the locality of things, which is
good. Think about it as of variables - it's nicer to have them local.
Also, with a central .gitignore file, how do you specify "Ignore all
*.html files under Documentation/" or so? (Without having ** - or you
need to support that one too to make the central .gitignore feasible.
But I think that in that case, it would depend on the user whether he
defines things in the central .gitignore or in subdirectories.)
> >> - Use $HOME/.gitrc (could be a directory or a file in .ini
> >> style like StGIT uses -- again, I do not care about the
> >> details at this moment) to store per-user configuration.
> >
> > Again, having Porcelain specific options mixed in the same file might
> > lead to some confusion among users.
>
> True. We need to be careful.
>
> Or course, there is an option of not worry about Porcelain
> compatibilities at all --- which is certainly simpler. All we
> need is to make sure they do not use the same filename for
> conflicting purposes. If everybody feels that way then this
> discussion is moot and I apologize for wasting people's time.
I don't think it is moot at all. (But see above - if we can't agree on
everything, I would much rather have common stuff in the project tree
than in ~ - there's not so much trouble of having multiple sets in ~,
but it's annoying to have e.g. .stgitignore, .cgignore and .jitignore in
each directory of the project, and if one project developer moves to
another Porcelain, having to add another set of files, and then keeping
them all up to date...)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ 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