* [PATCH 3/6] cogito: try harder to find gnu stat
From: Bryan Larsen @ 2005-07-18 2:51 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Look harder for gnu stat.
Cogito has code to use awk if gnu stat is missing. Look harder
for gnu stat under alternate names such as gstat and gnustat, avoiding
the use of awk if possible.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-Xlib | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -229,11 +229,16 @@ fi
# Compatibility hacks:
-# Fortunately none as of now.
-
export BROKEN_MKTEMP=1
del=$($(which mktemp) -t 2>/dev/null) && { rm $del; export BROKEN_MKTEMP=; }
-has_stat=$(which stat 2>/dev/null)
-[ "$has_stat" ] && $has_stat -c %s / 2>/dev/null >&2 || has_stat=
+
+has_stat=
+for stat in "$(which gnustat)" "$(which gstat)" "$(which stat)" ; do
+ if ( [ $stat ] && $stat -c %s / 2> /dev/null >&2 ) ; then
+ has_stat=$stat
+ break
+ fi
+done
+
has_gnudate=$(date -Rud "1970-01-01 UTC" 2>/dev/null)
^ permalink raw reply
* [PATCH 4/6] cogito: try harder to find gnu date
From: Bryan Larsen @ 2005-07-18 2:51 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Look harder for gnu date, use if available.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-Xlib | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -70,7 +70,7 @@ showdate () {
secs=$(($secs + $tzhours * 3600 + $tzmins * 60))
[ "$format" ] || format="+%a, %d %b %Y %H:%M:%S $2"
if [ "$has_gnudate" ]; then
- LANG=C date -ud "1970-01-01 UTC + $secs sec" "$format"
+ LANG=C ${has_gnudate} -ud "1970-01-01 UTC + $secs sec" "$format"
else
LANG=C date -u -r $secs "$format"
fi
@@ -241,4 +241,12 @@ for stat in "$(which gnustat)" "$(which
fi
done
-has_gnudate=$(date -Rud "1970-01-01 UTC" 2>/dev/null)
+has_gnudate=
+for date in "$(which gnudate)" "$(which gdate)" "$(which date)" ; do
+ if ( [ $date ] && $date -Rud "1970-01-01 UTC" 2> /dev/null >&2 ) ; then
+ has_gnudate=$date
+ break
+ fi
+done
+
+
^ permalink raw reply
* [PATCH 5/6] cogito: remove findutils dependency from Portfile
From: Bryan Larsen @ 2005-07-18 2:51 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Gnu findutils (xargs) is no longer required; remove the dependency.
Gnu coreutils is still required, but only if awk is not installed.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
Portfile.in | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Portfile.in b/Portfile.in
--- a/Portfile.in
+++ b/Portfile.in
@@ -14,8 +14,8 @@ long_description The git core, develope
homepage http://kernel.org/pub/software/scm/cogito/
master_sites http://kernel.org/pub/software/scm/cogito/
configure {}
-depends_lib bin:gcp:coreutils
-depends_lib bin:gnuxargs:findutils
+depends_lib bin:gstat:coreutils
+depends_lib lib:libz.dylib:zlib
build.type gnu
destroot.type gnu
destroot.destdir prefix=${prefix} DESTDIR=${destroot}
^ permalink raw reply
* [PATCH 6/6] cogito: update documentation
From: Bryan Larsen @ 2005-07-18 2:51 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
In-Reply-To: <20050718025024.11198.10556.sendpatchset@bryan-larsens-ibook-g4.local>
Update the documentation to add a README.osx and update requirements.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
README | 2 ++
README.osx | 31 +++++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/README b/README
--- a/README
+++ b/README
@@ -45,6 +45,8 @@ The following tools are optional but str
libcrypto (OpenSSL)
rsync
+ gnu coreutils (the gnu versions of stat, date and cp are
+ preferred over the BSD variants)
Starting a Fresh GIT Repository
diff --git a/README.osx b/README.osx
new file mode 100644
--- /dev/null
+++ b/README.osx
@@ -0,0 +1,31 @@
+This version of Cogito should work on OS X and other BSD variants.
+
+To install on OS X:
+
+1) Install darwinports (http://darwinports.opendarwin.org/) 2) type
+"make Portfile" 3) type "sudo port install"
+
+You may have to deal with md5 mismatches. Either adjust the md5sum in
+your new Portfile or place the new tarball in
+/opt/local/var/db/dports/distfiles/cogito.
+
+Caveats:
+
+cg-pull on a local repository requires cp -u, a non-portable gnu
+extension. This means that cg-pull, cg-clone and cg-update from a
+local repository are broken.
+
+Workaround #1: Use rsync for local clones. I.e. "cg-clone
+rsync://localhost/dir" instead of "cg-clone dir". This loses the disk
+space savings of normally gained by cg-clone.
+
+Workaround #2: Use gnu cp. "cd /opt/local/bin; sudo ln -s gcp cp".
+
+Recommendations:
+
+The gnu versions of "stat" and "date" are preferred over their BSD
+variants.
+
+"patch", "diff", "merge", "curl" and "rysnc" are required. OS X.4
+includes recent versions of these tools. If you are not running X.4,
+you may wish to check this.
^ permalink raw reply
* [PATCH 1/6 RESEND] cogito: remove use of xargs -r, a non-portable GNU extension
From: Bryan Larsen @ 2005-07-18 3:15 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
Remove usage of xargs -r, a non-portable gnu extension.
Resent with nasty bug fixed.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-add | 6 +++---
cg-init | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cg-add b/cg-add
--- a/cg-add
+++ b/cg-add
@@ -25,8 +25,6 @@ USAGE="cg-add [-N] FILE..."
. ${COGITO_LIB}cg-Xlib
-[ "$1" ] || usage
-
infoonly=
while optparse; do
if optparse -N; then
@@ -36,6 +34,8 @@ while optparse; do
fi
done
+[ "$ARGS" ] || usage
+
TMPFILE=$(mktemp -t gitadd.XXXXXX) || exit 1
find "${ARGS[@]}" -type f -print0 > $TMPFILE || {
die "not all files exist, nothing added"
@@ -43,6 +43,6 @@ find "${ARGS[@]}" -type f -print0 > $TMP
}
cat $TMPFILE | tr '\0' '\n' | sed 's/^/Adding file /'
-cat $TMPFILE | xargs -0r git-update-cache --add ${infoonly} --
+cat $TMPFILE | xargs -0 git-update-cache --add ${infoonly} --
rm $TMPFILE
diff --git a/cg-init b/cg-init
--- a/cg-init
+++ b/cg-init
@@ -55,7 +55,7 @@ if [ "$uri" ]; then
echo "Cloned (origin $uri available as branch \"origin\")"
else
git-read-tree # Seed the dircache
- find * \( -type f -o -type l \) -print0 | xargs -0r cg-add ${infoonly}
+ [ "`ls`" ] && find * \( -type f -o -type l \) -print0 | xargs -0 cg-add ${infoonly}
cg-commit -C -m"Initial commit" -E ${infoonly}
fi
^ permalink raw reply
* [PATCH] cg-commit chokes when given a very large list of files
From: Bryan Larsen @ 2005-07-18 3:18 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
cg-commit currently chokes when passed a very large list of files.
Fix it.
This patch depends on your filenames not containing line feeds. No
big deal, other parts of cogito break on filenames containing line
feeds.
Resent because previous send appears to have been dropped. This patch
is cleaner.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-commit | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -289,9 +289,9 @@ precommit_update () {
eval "queue$op[\${#queue$op[@]}]=\"\$fname\""
done
# XXX: Do we even need to do the --add and --remove update-caches?
- [ "$queueN" ] && { git-update-cache --add ${infoonly} -- "${queueN[@]}" || return 1; }
- [ "$queueD" ] && { git-update-cache --force-remove -- "${queueD[@]}" || return 1; }
- [ "$queueM" ] && { git-update-cache ${infoonly} -- "${queueM[@]}" || return 1; }
+ [ "$queueN" ] && { ( echo "${queueN[*]}" | tr \\n \\0 | IFS=$'\n' xargs -0 git-update-cache --add ${infoonly} -- ) || return 1; }
+ [ "$queueD" ] && { ( echo "${queueD[*]}" | tr \\n \\0 | IFS=$'\n' xargs -0 git-update-cache --force-remove -- ) || return 1; }
+ [ "$queueM" ] && { ( echo "${queueM[*]}" | tr \\n \\0 | IFS=$'\n' xargs -0 git-update-cache ${infoonly} -- ) || return 1; }
return 0
}
^ permalink raw reply
* Re: [PATCH] cg-commit chokes when given a very large list of files
From: Bryan Larsen @ 2005-07-18 3:29 UTC (permalink / raw)
To: Bryan Larsen; +Cc: pasky, git
In-Reply-To: <20050718031808.20247.43698.sendpatchset@bryan-larsens-ibook-g4.local>
This patch is broken. The original patch still works.
Bryan
Bryan Larsen wrote:
> cg-commit currently chokes when passed a very large list of files.
> Fix it.
>
> This patch depends on your filenames not containing line feeds. No
> big deal, other parts of cogito break on filenames containing line
> feeds.
>
> Resent because previous send appears to have been dropped. This patch
> is cleaner.
>
> Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
> ---
>
> cg-commit | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cg-commit b/cg-commit
> --- a/cg-commit
> +++ b/cg-commit
> @@ -289,9 +289,9 @@ precommit_update () {
> eval "queue$op[\${#queue$op[@]}]=\"\$fname\""
> done
> # XXX: Do we even need to do the --add and --remove update-caches?
> - [ "$queueN" ] && { git-update-cache --add ${infoonly} -- "${queueN[@]}" || return 1; }
> - [ "$queueD" ] && { git-update-cache --force-remove -- "${queueD[@]}" || return 1; }
> - [ "$queueM" ] && { git-update-cache ${infoonly} -- "${queueM[@]}" || return 1; }
> + [ "$queueN" ] && { ( echo "${queueN[*]}" | tr \\n \\0 | IFS=$'\n' xargs -0 git-update-cache --add ${infoonly} -- ) || return 1; }
> + [ "$queueD" ] && { ( echo "${queueD[*]}" | tr \\n \\0 | IFS=$'\n' xargs -0 git-update-cache --force-remove -- ) || return 1; }
> + [ "$queueM" ] && { ( echo "${queueM[*]}" | tr \\n \\0 | IFS=$'\n' xargs -0 git-update-cache ${infoonly} -- ) || return 1; }
> return 0
> }
>
>
^ permalink raw reply
* [PATCH UPDATED] cg-commit chokes when given a very large list of files
From: Bryan Larsen @ 2005-07-18 4:37 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
cg-commit currently chokes when passed a very large list of files. Fix it.
Resent again. This time we completely avoid messing with IFS, resulting
in support for filenames with line feeds.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-Xlib | 18 ++++++++++++++++++
cg-commit | 6 +++---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -49,6 +49,24 @@ mktemp () {
$(which mktemp) $dirarg $prefix"$1"
}
+
+# this function is useful when you want to execute a command that's bigger
+# than the system's limit.
+#
+# this is similar to piping output to xargs -0r
+#
+# example usage: eval_via_xargs "git-update-cache --add --" "$@"
+eval_via_xargs () {
+ local cmd=$1
+ shift
+ if [ "$1" ] ; then
+ ( for f in "$@" ; do
+ echo -ne ${f}\\000
+ done ) | xargs -0 $cmd
+ fi
+}
+
+
stat () {
if [ "$1" != "-c" ] || [ "$2" != "%s" ]; then
echo "INTERNAL ERROR: Unsupported stat call $@" >&2
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -289,9 +289,9 @@ precommit_update () {
eval "queue$op[\${#queue$op[@]}]=\"\$fname\""
done
# XXX: Do we even need to do the --add and --remove update-caches?
- [ "$queueN" ] && { git-update-cache --add ${infoonly} -- "${queueN[@]}" || return 1; }
- [ "$queueD" ] && { git-update-cache --force-remove -- "${queueD[@]}" || return 1; }
- [ "$queueM" ] && { git-update-cache ${infoonly} -- "${queueM[@]}" || return 1; }
+ eval_via_xargs "git-update-cache --add ${infoonly} --" "${queueN[@]}" || return 1
+ eval_via_xargs "git-update-cache --force-remove --" "${queueD[@]}" || return 1
+ eval_via_xargs "git-update-cache ${infoonly} --" "${queueM[@]}" || return 1
return 0
}
^ permalink raw reply
* Re: Barebone Porcelain. Where to stop?
From: Bryan Larsen @ 2005-07-18 4:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek9yirdi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I have been somewhat disturbed and confused by the fact that the
> line between what Porcelain like Cogito does and what we ship as
> part of "core GIT" is getting more and more blurred. This was
> especially so while I was working on the $GIT_DIR/branches/
> patch.
I have also been disturbed. But I am gratified that such a core git
personage shares my concern. This is enough from a technical point of
view, at least for me.
Any lack of porcelain momentum is probably due to git having better
documentation than the current porcelains, such as cogito and stacked
git. The documentation, like tutorial.txt and Jeff Garzik's git kernel
howto give the impression that most kernel folks use git instead of cogito.
I personally think that the cogito interface and stacked git interfaces
are much nicer than git's, and would like to see these two tools achieve
some momentum.
Another way of encouraging porcelain is by helping Pasky and Catalin
out. Myself, I have been sending corresponding patches for Cogito and
Stacked when making changes to git. This is purely selfish: I use both
of these porcelains, but if it became general practice, we'd probably
see less breakage.
Bryan
^ permalink raw reply
* git, porcelain, darcs, and version 1.0
From: Bryan Larsen @ 2005-07-18 4:46 UTC (permalink / raw)
To: Juliusz Chroboczek; +Cc: darcs-devel, git
In-Reply-To: <7islyev5s4.fsf@lanthane.pps.jussieu.fr>
Juliusz Chroboczek wrote:
> There are three ways to do that:
>
> (1) require that the users put a suitable libgit.a in /usr/local/lib
> before building Darcs, and distribute a tarball of Git from
> darcs.net;
I was under the impression that the stablest interface to git was the
command line; we use spawnvp in stacked git. I've been using it with
repositories that make the Linux kernel look small.
I certainly don't think the lib interface is anywhere near stable:
Linus accepted my change to index_fd far too easily.
>
> (2) include just the sources needed for libgit.a in Darcs, and have
> the Darcs build build a local libgit
>
> (3) as (2), but include all of Git, including their
> ``user-friendly'' scripts.
Ugh. That's what they do in the commercial world. We have it so much
better here in Linux & BSD land: you just add a "depends libgit1" line
to your package, and the right thing happens: minor updates happen
automatically and changes that break the interface don't. Of course,
keeping it that easy for the user requires active effort from us, the
developers, and sometimes the pain spills over, but the benefits are nice.
I see too major long-term alternatives:
1) talk the darcs guys into using spawnvp
2) talk the git people into exporting a stable lib interface
It's my opinion that #1 is a non-starter. We want others to interact
with us. I'm going to use spawnvp for my porcelain, but we should be
inclusive.
The current 'libgit' probably contains more than Linus and Junio are
comfortable locking down as a stable interface, but I'm sure that
there's a subset that they'd be comfortable with once a relative amount
of stability is achieved, or it may be achievable via some other method.
I propose that Darcs includes all of git for now. (I prefer this over
partial inclusion; anybody should be able to take the darcs sources and
easily drop in a later git). However, the long term goal is for a
library. Darcs and git work together to determine the minimal amount
that needs to go into libgit1.so. It gets blessed by being documented,
and doesn't change until libgit2.so.
I'd like to see this added to Junio's list of "1.0" goals.
A similar 1.0 goal would be to document porcelain's use of the .git
directory. For instance, stacked git uses .git/patches,
.git/patchdescr.tmpl and .git/patchexport.tmpl. If Linus does not
accept a patch documenting this usage, stacked git should use .stgit
instead.
Bryan
^ permalink raw reply
* Re: Last mile to 1.0?
From: Alexey Nezhdanov @ 2005-07-18 4:53 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net>
Satturday, 16 July 2005 21:46 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.
>
> Here are the things I think we would want to see before we hit
> 1.0:
>
> - Remaining feature enhancements and fixes.
>
> - Anonymous pull from packed archives on remote sites via
> non-rsync, non-ssh transport. Many people are behind
> corporate firewalls that do not pass anything but outgoing
> http(s) and some do not even pass outgoing ssh. The recent
> addition of git-daemon by Linus would greatly alleviate the
> situation, but we may also end up wanting something HTTP
> reachable.
I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't
support that. Probably this should be done at as low as possible level.
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-18 5:35 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: git
In-Reply-To: <200507180853.41633.snake@penza-gsm.ru>
Alexey Nezhdanov <snake@penza-gsm.ru> writes:
> I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't
> support that. Probably this should be done at as low as possible level.
I do not understand your proposal. Care to clarify? You can
write your commit messages in UTF-8 today and "git-cat-file
commit $commit_ID", which is as low level as you can go, gives
you that commit message in UTF-8.
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Eric W. Biederman @ 2005-07-18 5:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64v8j4qn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Actually looking a little deeper unless I have misread
>> the code git-fetch-pack at least will only ask for commit
>> objects so git fetch will never return a tag object.
>
> I thought so but then I tried it and actually it does seem to
> work as expected (well, it is Linus code so it has to be perfect
> ;-).
Yep. I confused the want and have cases when I was reading
the code.
A generalization of git-fetch-pack that can handle multiple
heads looks like it would handle the transfer part of the
problem with tags. git-clone-pack already does. Then
all that is needed is a sane way to list the heads that
are read back and some post processing to install everything.
The big question is in what format should we return the heads?
Just a space separated list of sha1's or a directory hierarchy
like git-clone-pack uses.
Eric
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-18 5:44 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0507161815100.15383@qynat.qvtvafvgr.pbz>
David Lang <david.lang@digitalinsight.com> writes:
> a very common one will be prople who want to setup a cron job to
> update their local tree nightly, in this case having a pre-generated
> pack file with each day's updates will save a significant amount of
> processing power.
>
> would it make sense to have it do something along the lines of sending
> the day;s pack file plus a small number of individual object (even if
> the pack file will partially duplicate object the puller already has)
I think that would be a reasonable thing to do. The server for
anonymous puller, git-daemon, may need some extending. As
people criticised, git-upload-pack/git-fetch-pack protocol being
not easily extensible, we would end up doing another protocol,
though, that's OK.
Fortunately [*1*], git-daemon itself is written to be extensible
if you are willing to introduce a totally new protocol driver,
so if this on-demand pack generation turns out to be too much
a resource hog, we have a reasonably easy way out.
[Footnote]
*1* We are fortunate but that is not by dumb luck. When he did
daemon.c::execute(), Linus must have thought things through.
^ permalink raw reply
* Re: [PATCH] git-revover-tags-script
From: Junio C Hamano @ 2005-07-18 6:36 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m164v8oenn.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> The big question is in what format should we return the heads?
> Just a space separated list of sha1's or a directory hierarchy
> like git-clone-pack uses.
My knee-jerk reaction is something like this:
$ git-list-remote jg-libata
9956d54ace3c64512d0c5498e0137180741e5d04 heads/adma
433e7832818faf93c0f366fea3e14773cdcf3811 heads/adma-mwi
...
80ebd62e0cca50869da2d5159fa4d6b723f0c014 heads/sil24
9e734775f7c22d2f89943ad6c745571f1930105f tags/v2.6.12-rc2
26791a8bcf0e6d33f43aef7682bdb555236d56de tags/v2.6.12
...
a339981ec18d304f9efeb9ccf01b1f04302edf32 tags/v2.6.13-rc3
That is, SHA1 and path relative to .git/refs separated with a
TAB, and terminated with LF.
I do not care too much about the protocol level, but since we
are not talking about hundreds of heads and tags, probably
the simplest would be to match the same, or use SP instead of
TAB there to match upload-pack protocol.
I think the bigger question is how to help the user manage and
store this information in his .git/refs/tags hierarchy.
The mechanism to store the URL and head in branches/<name>, and
copy the head value in the corresponding refs/heads/<name> was
borrowed from Cogito, and I think it covers the refs/heads side
quite well. The user gives a name to the branch of a foreign
repository he is interested in, the fetched head from there is
stored in the same <name>, so the namespace under refs/heads and
branches are totally under the user's control.
If somebody cares about automated fetching of all the tags from
a remote repository, probably the easiest way would be to create
a subdirectory that corresponds to the short-hand name and use
that directory to store all tags slurped from there. But I am
not convinced myself this is that much useful.
^ permalink raw reply
* Re: Last mile to 1.0?
From: Alexey Nezhdanov @ 2005-07-18 6:48 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyucfzgt.fsf@assigned-by-dhcp.cox.net>
Monday, 18 July 2005 09:35 Junio C Hamano wrote:
> Alexey Nezhdanov <snake@penza-gsm.ru> writes:
> > I'd add the UTF-8 native support. Currently neither commit nor gitk
> > doesn't support that. Probably this should be done at as low as possible
> > level.
>
> I do not understand your proposal. Care to clarify? You can
> write your commit messages in UTF-8 today and "git-cat-file
> commit $commit_ID", which is as low level as you can go, gives
> you that commit message in UTF-8.
Yes. But it have not integration with user environment. Personally I use
koi8-r environment and doing "cg commit" (and probably "git commit" too)
results in koi8-r text written as commit text. I remember that this issue
were discussed on this list and all come to conclusion that utf-8 is the only
sane encoding that can be used in this case.
But this should not be user's problem - it's just the UI that doesn't
understands when transcoding should be done.
Similarly - when I start gitk then I see only weird symbols instead of commit
text, not matter what encoding I use for commits - koi8-r or utf-8. BTW
russian koi8-r encoded text _in_diff_contents_ show correctly. Wonder why...
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: Last mile to 1.0?
From: Junio C Hamano @ 2005-07-18 7:38 UTC (permalink / raw)
To: Alexey Nezhdanov; +Cc: git
In-Reply-To: <200507181048.50303.snake@penza-gsm.ru>
Alexey Nezhdanov <snake@penza-gsm.ru> writes:
> But this should not be user's problem - it's just the UI that doesn't
> understands when transcoding should be done.
I disagree.
Yes, while you _could_ do something like this to feed text in
local encoding to the VISUAL/EDITOR, and convert it back to
UTF-8:
--- a/git-commit-script
+++ b/git-commit-script
@@ -84,7 +84,7 @@
fi
if [ "$?" != "0" ]
then
- cat .editmsg
+ git-char-conv --utf8-to-user < .editmsg
rm .editmsg
exit 1
fi
@@ -93,7 +93,9 @@
${VISUAL:-${EDITOR:-vi}} .editmsg
;;
esac
-grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
+grep -v '^#' < .editmsg |
+git-stripspace |
+git-char-conv --user-to-utf8 > .cmitmsg
[ -s .cmitmsg ] &&
tree=$(git-write-tree) &&
commit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&
I think it is a horrible way to do things.
I presume that your bringing up UTF-8 suggests that you believe
doing things in UTF-8 for interoperability's sake is the right
thing. If that is indeed the case, then tools other than GIT
and Cogito you would use would need to deal with this exact same
problem, that your VISUAL/EDITOR does not understand UTF-8.
How about writing a little wrapper, koi-vi, which would roughly
be:
#!/bin/sh
tcs -f utf -t koi8 "$1" >.tmp-koi
vi .tmp-koi
tcs -t utf -f koi8 .tmp-koi >"$1"
and point VISUAL/EDITOR environment variable at it? That way
your other tools would be able to let you keep using your
favorite editor, now utf8 enabled, and deal with UTF-8. None of
the scripts, including the script I quoted above, has to be
changed that way.
Having said that, I personally feel that the choice of the
character encoding of commit messages is per-project convention
issue and does not even warrant a per-project "configuration
file". As long as your developers all agree to use KOI, and you
are reasonably sure that you will not ever cross-merge with
another project that uses different encoding for commit
messages, I think it is perfectly fine to use KOI in your commit
messages. The core's job is only to ensure that we are 8-bit
clean and faithfully record whatever you throw at us.
^ permalink raw reply
* Re: Barebone Porcelain. Where to stop?
From: Catalin Marinas @ 2005-07-18 10:22 UTC (permalink / raw)
To: Bryan Larsen; +Cc: Junio C Hamano, git
In-Reply-To: <42DB32F1.5020900@gmail.com>
Bryan Larsen <bryan.larsen@gmail.com> wrote:
> Any lack of porcelain momentum is probably due to git having better
> documentation than the current porcelains, such as cogito and stacked
> git. The documentation, like tutorial.txt and Jeff Garzik's git
> kernel howto give the impression that most kernel folks use git
> instead of cogito.
>
> I personally think that the cogito interface and stacked git
> interfaces are much nicer than git's, and would like to see these two
> tools achieve some momentum.
I don't see git going towards stgit at all. Indeed, it gets closer to
cogito but I still like cogito over plain git since it's easier to use
(my goal, though, is to add pull/clone commands to stgit so that one
doesn't need to rely on directly using other tools).
I am aware that, probably, the biggest problem with stgit is the
documentation (and also a lack of regression tests). I hope I will
find some time soon to write a tutorial and improve the command line
help. I will setup a wiki in the next few days so that others can
easily fix/update the documentation.
--
Catalin
^ permalink raw reply
* Re: 2.6.12 hangs on boot
From: Alexander Y. Fomichev @ 2005-07-18 11:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List, admin, Git Mailing List, ak
In-Reply-To: <Pine.LNX.4.58.0506241446440.11175@ppc970.osdl.org>
On Saturday 25 June 2005 02:20, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote:
> > I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8
> > GHz [ MoBo: Intel E7520, intel 82801 ]
> > but kernel hangs on boot right after records:
> >
> > Booting processor 2/1 rip 6000 rsp ffff8100023dbf58
> > Initializing CPU#2
>
> Hmm.. Since you seem to be a git user, maybe you could try the git
> "bisect" thing to help narrow down exactly where this happened (and help
> test that thing too ;).
[skiped]
Ok, as i can see [and as Andi guessed
http://bugme.osdl.org/show_bug.cgi?id=4792]
issue have been introduced by new TSC sync algorithm
git id: dda50e716dc9451f40eebfb2902c260e4f62cf34.
And, yes, seems like it depends of timings...
In my case kludge with insertion of low delay (e.g. printk) between
cpu_set/mb and tsc_sync_wait() makes kernel bootable.
diff -urN b/arch/x86_64/kernel/smpboot.c a/arch/x86_64/kernel/smpboot.c
--- b/arch/x86_64/kernel/smpboot.c 2005-07-17 21:55:55.000000000 +0400
+++ a/arch/x86_64/kernel/smpboot.c 2005-07-17 21:57:56.000000000 +0400
@@ -451,6 +451,7 @@
cpu_set(smp_processor_id(), cpu_online_map);
mb();
+ printk(KERN_INFO "We're still here!\n");
/* Wait for TSC sync to not schedule things before.
We still process interrupts, which could see an inconsistent
time in that window unfortunately. */
--
Best regards.
Alexander Y. Fomichev <gluk@php4.ru>
Public PGP key: http://sysadminday.org.ru/gluk.asc
^ permalink raw reply
* Re: 2.6.12 hangs on boot
From: Andi Kleen @ 2005-07-18 12:58 UTC (permalink / raw)
To: Alexander Y. Fomichev
Cc: Linus Torvalds, Kernel Mailing List, admin, Git Mailing List, ak
In-Reply-To: <200507181527.16652.gluk@php4.ru>
Can you please test if this patch fixes it?
-Andi
Don't compare linux processor index with APICID
Fixes boot up lockups on some machines where CPU apic ids
don't start with 0
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/arch/x86_64/kernel/smpboot.c
===================================================================
--- linux.orig/arch/x86_64/kernel/smpboot.c
+++ linux/arch/x86_64/kernel/smpboot.c
@@ -211,7 +211,7 @@ static __cpuinit void sync_master(void *
{
unsigned long flags, i;
- if (smp_processor_id() != boot_cpu_id)
+ if (smp_processor_id() != 0)
return;
go[MASTER] = 0;
^ permalink raw reply
* [PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF
From: Junio C Hamano @ 2005-07-18 17:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vslyd3lhk.fsf@assigned-by-dhcp.cox.net>
The git-rev-parse command uses LF to separate each arguments 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, -Spickaxe 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
feature.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
*** This is a replacement for two patches I sent earlier:
*** [RFC/PATCH] git-rev-parse vs IFS
*** [PATCH] rev-parse --sq bugfixes.
git-whatchanged | 9 ++++++---
rev-parse.c | 34 +++++++++++++++++++++++++++++++---
2 files changed, 37 insertions(+), 6 deletions(-)
a99f0d64fae9a121a1ecbfd07d7667cf4aa0f19d
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-clone-script: store where we cloned from in .git/branches/origin
From: Junio C Hamano @ 2005-07-18 17:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507161032410.19183@g5.osdl.org>
A bit more usability enhancement related to the recent URL
short-hand support in .git/branches, while retaining Cogito
compatibility.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-clone-script | 41 +++++++++++++++++++++++------------------
1 files changed, 23 insertions(+), 18 deletions(-)
cb70e0d83c336e0fc3485b6c823b948c07d15a12
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-18 17:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0507161032410.19183@g5.osdl.org>
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(-)
6af33a52163dd15beaaf610f6b7506b900189770
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
* Re: Barebone Porcelain. Where to stop?
From: Junio C Hamano @ 2005-07-18 18:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Bryan Larsen, git
In-Reply-To: <tnx3bqcxvkm.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> I don't see git going towards stgit at all. Indeed, it gets closer to
> cogito but I still like cogito over plain git since it's easier to use
> (my goal, though, is to add pull/clone commands to stgit so that one
> doesn't need to rely on directly using other tools).
All good to hear. I do not speak for Linus, but I think core
should not be competing with Porcelain. To me, there are four
purposes for the barebone Porcelain layer:
(1) provide the end user a minimum UI to do essential things.
(2) codify the BCP/convention to use the core by higher level
SCMs to help them stay compatible with each other where
possible (e.g. "what .git/HEAD means, when it gets updated,
and to what" was discussed recently).
(3) serve as an example for people interested in learning the
core GIT (i.e. they may be starting their own Porcelain).
(4) implement operations that are heavy on logic/convention but
does not have much UI need so that higher level SCMs can
implement their own UI by just being a thin wrapper around
them (e.g. clone/fetch and push).
> I am aware that, probably, the biggest problem with stgit is the
> documentation (and also a lack of regression tests). I hope I will
> find some time soon to write a tutorial and improve the command line
> help. I will setup a wiki in the next few days so that others can
> easily fix/update the documentation.
Wonderful.
^ permalink raw reply
* Re: git, porcelain, darcs, and version 1.0
From: Junio C Hamano @ 2005-07-18 19:11 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <42DB341D.6050506@gmail.com>
Bryan Larsen <bryan.larsen@gmail.com> writes:
> ... Darcs and git work together to determine the minimal amount
> that needs to go into libgit1.so. It gets blessed by being
> documented, and doesn't change until libgit2.so.
>
> I'd like to see this added to Junio's list of "1.0" goals.
I should mention that I liked the libification work Brad Roberts
did around late April. Unfortunately the things have been
always in great flux for the last couple of months, and it was
too hard to include that and maintain it back then.
I fully agree that supporting C-level linkage is worthy, and
should be one of our longer term goals.
> A similar 1.0 goal would be to document porcelain's use of the .git
> directory. For instance, stacked git uses .git/patches,
> .git/patchdescr.tmpl and .git/patchexport.tmpl. If Linus does not
> accept a patch documenting this usage, stacked git should use .stgit
> instead.
I agree that coordinating the namespace under $GIT_DIR among
Porcelains is something we need (it was what prompted me to
steal the branches/ convention from Cogito). The job of the
core should be to help Porcelains avoid stepping on each other's
toes.
The documentation of the internals for $GIT_DIR/patches is
probably better left to StGIT documentation, though, at the
moment. When other Porcelains start wishing to access the
"series of patches expressed as a set of commit chain" expressed
by StGIT there (e.g. show patch series in addition to regular
commit chain in gitk), the core should help the Porcelains to
work well with each other, to do things in a compatible way.
This may involve moving some common things to core side and
mention the convention for Porcelains to work well together in
the core documentation.
However, I am slightly negative about suggesting these two to be
part of the 1.0 goals. Linus wanted to make 1.0 how many weeks
ago? I personally think that a usable baseline, stable enough
to allow stripping out the core part currently shipped as part
of Cogito, would be a good place to stop and declare 1.0. My
list was meant to enumuerate what might be missing from the
"usable baseline".
^ 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