* [PATCH] git-clone: use cpio's --quiet flag
From: Jeff King @ 2007-08-04 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Without this flag, cpio prints the number of blocks copied,
leading to the somewhat confusing git-clone output:
$ git-clone foo bar
Initialized empty Git repository in ...
0 blocks
Signed-off-by: Jeff King <peff@peff.net>
---
This is obviously on top of the jc/clone topic in next.
git-clone.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 4c9b1c9..ccfc316 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -281,7 +281,8 @@ yes)
fi
fi &&
cd "$repo" &&
- find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
+ find objects -depth -print | cpio --quiet -pumd$l "$GIT_DIR/" \
+ || exit 1
fi
git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
;;
--
1.5.3.rc3.942.g536b2
^ permalink raw reply related
* Re: Shell script cleanups/style changes?
From: Florian Weimer @ 2007-08-04 7:10 UTC (permalink / raw)
To: git
In-Reply-To: <20070802214103.GT29424@schiele.dyndns.org>
* Robert Schiele:
>> Sure. What about the git-rebase line using $(($end - $msgnum)) ?
>
> Bad on Solaris:
>
> $ uname -a
> SunOS solaris10-x64 5.10 Generic i86pc i386 i86pc
> $ end=1
> $ msgnum=5
> $ echo $(($end - $msgnum))
> syntax error: `(' unexpected
> $
Is this with /usr/xpg4/bin/sh or /bin/sh? The latter is not POSIX and
should not be used by GIT, IMHO, otherwise there will be endless
issues in less-well-tested code paths. Is rewriting the shebang lines
to use the POSIX shell an option for GIT?
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Jeff King @ 2007-08-04 7:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Väinö Järvelä, git
In-Reply-To: <20070804065516.GS20052@spearce.org>
On Sat, Aug 04, 2007 at 02:55:16AM -0400, Shawn O. Pearce wrote:
> V??in?? J??rvel?? <v@pp.inet.fi> wrote:
Your mailer claims this message is in us-ascii, but I think it isn't...
> I had a devil of a time applying your patch though. git-am
> choked because the patch was whitespace damaged, and then after
> hand-correction and resuming it horribly munged your name's encoding
> in the commit. I think there's a bug in there in git-am; I'll
> have to try to track it down. I managed to get the patch applied
> correctly by editing the mbox file directly, so that git-am did
> not need to stop and ask me to resolve the patch.
I tried reproducing the encoding breakage and it ended up fine. I just
edited the patch in the .dotest directory (looks like the leading spaces
were all stripped) and it applied fine when I re-ran "git-am".
Are you sure it didn't get munged by your editor when you hand-edited
the mbox file?
-Peff
^ permalink raw reply
* add "test-absolute-path" to .gitignore
From: Randal L. Schwartz @ 2007-08-04 7:13 UTC (permalink / raw)
To: git
New file requires new ignore.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Doug Maxey @ 2007-08-04 6:17 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <46B418AA.4070701@midwinter.com>
On Sat, 04 Aug 2007 14:11:54 +0800, Steven Grimm wrote:
>
> I will look around and see what I can find. You're quite right, better
> to use already-existing code than reinvent the wheel.
/me dons his asbestos skivvies.
What about perldoc? Thats about as minimal as it gets, yet can output
text or nroff quite nicely. Don't pay much attention to html myself.
++doug
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-04 7:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Ismail Dönmez, git
In-Reply-To: <7vfy2zj4nj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Steven Grimm <koreth@midwinter.com> writes:
>
>> Am I correct in observing that "*roff -man" and HTML are the only
>> two output formats we care about, or do people use other formats in
>> their private branches?
>
> I obviously do not speak for others, but the only format I care
> about personally is the *.txt one. We picked asciidoc primarily
> because the source language was readable.
[...]
> It might be more worthwhile to research what other "Text-ish
> lightweight mark-up" systems are availble, and if there is one
> that is more efficient and can go to at least html and man,
> one-time convert our documentation source to that format using
> your Perl magic. The minimum requirements are:
>
> * The source is readable without too much mark-up distraction;
>
> * Can go to roff -man;
>
> * Can go to html.
Naturally I am biased, but Texinfo might be an option. The source is
editable without too much distraction, one can generate HTML, printed
output, cross-referenced info files (those are really convenient for
Emacs users), cross-referenced PDF output. For man pages, one could
follow the path outlined in
<URL:http://gcc.gnu.org/onlinedocs/gccint/Man-Page-Generation.html>.
That is probably the weakest point.
Plain, user-readable ASCII text without any Texinfo markup can also be
generated. One can even include images in info, PDF and HTML and have
those replaced by ASCII art in the plain text output.
There are some disadvantages: AFAIR, utf-8 characters will in general
not fly. One needs to code accented characters more or less
explicitly.
Texinfo conversions are fast.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Shawn O. Pearce @ 2007-08-04 7:33 UTC (permalink / raw)
To: Jeff King; +Cc: Väinö Järvelä, git
In-Reply-To: <20070804071131.GA6557@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Sat, Aug 04, 2007 at 02:55:16AM -0400, Shawn O. Pearce wrote:
>
> > V??in?? J??rvel?? <v@pp.inet.fi> wrote:
>
> Your mailer claims this message is in us-ascii, but I think it isn't...
My mutt-foo isn't very good. I tried to tell it utf-8, but I think
its ignoring me:
set allow_8bit=yes
set charset=utf8
:-/
> I tried reproducing the encoding breakage and it ended up fine. I just
> edited the patch in the .dotest directory (looks like the leading spaces
> were all stripped) and it applied fine when I re-ran "git-am".
>
> Are you sure it didn't get munged by your editor when you hand-edited
> the mbox file?
I just tried to reproduce it myself and I can't do whatever I did
before again now; it Just Works(tm). *sigh* No idea how I messed
the patch application up earlier, but I did.
It wasn't my patch editing. My vi clone only works on bytes, so
it doesn't care about character encodings and won't mangle them
unless I edit a utf-8 multibyte sequence by hand. Which I'm sure
I didn't do. And the first time I messed up the apply I was fixing
up only .dotest/patch, which was most certainly just us-ascii.
I'm actually pretty good about making sure I don't munge people's
non-ASCII names, but my mutt seems to think us-ascii is the only
character encoding in the world.
--
Shawn.
^ permalink raw reply
* Re: [RFC (take 3)] Git User's Survey 2007
From: David Kastrup @ 2007-08-04 7:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200708040250.55180.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Getting help, staying in touch
>
> 1. Have you tried to get GIT help from other people?
> - yes/no
> 2. If yes, did you get these problems resolved quickly
> and to your liking?
> - yes/no
> 3. Do you subscribe to the mailing list?
> - yes/no
> 4. Do you read the mailing list? What method do you use?
> - subscribed/news interface/RSS interface/archives/
> /post + reply-to request/digests/I don't read it
> 5. If yes, do you find it useful?
> - yes/no (optional)
> 6. Do you find traffic levels on GIT mailing list OK.
> - yes/no? (optional)
> 7. Do you use the IRC channel (#git on irc.freenode.net)?
> - yes/no
> 8. If yes, do you find IRC channel useful?
> - yes/no (optional)
I miss a question about developer and mailing list attitude. That is
often inversely proportional to the quality of help and support: one
has forums where lots of friendly people without much of a clue hang
out, and then there are some where one can always get competent and
fast help in one package with an ulcer.
The German TeX Usenet group has sort of a renown for that. It has an
expert quota quite unusual for a Usenet group, but it is obvious that
some visitors use it mostly as a last resort when everything else
fails. It is not that the tone there is actually acrimonious, but it
can be somewhat dry.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Jeff King @ 2007-08-04 7:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Väinö Järvelä, git
In-Reply-To: <20070804073321.GU20052@spearce.org>
On Sat, Aug 04, 2007 at 03:33:21AM -0400, Shawn O. Pearce wrote:
> My mutt-foo isn't very good. I tried to tell it utf-8, but I think
> its ignoring me:
>
> set allow_8bit=yes
> set charset=utf8
Try looking at the send_charset config option; by default mutt will try
to send us-ascii if possible. Also, should it be "utf-8"?
> I just tried to reproduce it myself and I can't do whatever I did
> before again now; it Just Works(tm). *sigh* No idea how I messed
> the patch application up earlier, but I did.
OK, given that I couldn't reproduce it either, we should perhaps chalk
it up to cosmic rays.
-Peff
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: David Kastrup @ 2007-08-04 7:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: J. Bruce Fields, Steffen Prohaska, git
In-Reply-To: <20070804062010.GQ20052@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I haven't explored any in-Tk rendering options yet, been too busy
> with other projects. Ideally I'd like to just render the asciidoc
> markup directly, but I don't think anyone has done an asciidoc
> viewer for Tk. I can't imagine it would be that difficult to get
> some sort of parser working though...
With regard to my Texinfo proposal in a different thread, it must be
mentioned that "tkinfo" can be used as an embedded info viewer in
existing applications.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Some ideas for StGIT
From: Yann Dirson @ 2007-08-04 8:08 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Andy Parkins, git, Catalin Marinas
In-Reply-To: <1186206085.28481.33.camel@dv>
On Sat, Aug 04, 2007 at 01:41:25AM -0400, Pavel Roskin wrote:
> [quote]
> Sometimes, I just make patches in quilt, then I do "quilt
> refresh", "quilt pop -a", "cd patches" and modify the patches
> and series file manually, e.g. by moving one patch from one file
> into the other.
> [end of quote]
FWIW, I have written a couple of scripts to help moving stuff around
between patches. Those are not yet integrated in stgit proper, and it
happens that the 0.13 tarball does not contain them, they are only
available from the git tree (better use my tree[1], since I updated them
recently).
Most notably relevant to this use are stg-fold-files-from and
stg-dispatch, to move diff hunks between patches. They only cases
(off the top of my hand) where they do not fit my needs are:
- when I need to move a part of a diff hunk that is not possible to
isolate using -U<n> (but I have read interesting things about git-gui
for such functionnality, so that will surely come one day)
- when I need to move git-specific diff hunks (moves, permissions,
etc.), since it uses filterdiff, which is not git-aware (yet ?)
(in short, there are lots of dev to do in/around stgit, but there are
not as many contributors as there is for git - hint, hint ;)
If there are other typical situations where they need to edit patches,
I'd be interested to hear about them. Not to avoid implementing patch
edition in stgit, since it is occasionally useful to fix a typo when
reviewing at refresh time, but to see what higher-level tools we could
provide.
Best regards,
--
Yann
[1] gitweb at http://repo.or.cz/w/stgit/ydirson.git
^ permalink raw reply
* Re: Some ideas for StGIT
From: Yann Dirson @ 2007-08-04 8:16 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pavel Roskin, Catalin Marinas, git
In-Reply-To: <20070804063858.GA13758@thunk.org>
On Sat, Aug 04, 2007 at 02:38:58AM -0400, Theodore Tso wrote:
> My main reason for avoiding StGIT is the fact that at least in the
> past, I've found it very fragile when I forget and use "git checkout"
> instead of "stg branch" to switch between branches.
FWIW, I exclusively use git-checkout to switch between git branches
and stgit stacks, and it works like a charm. I don't remember ever
seeing a problem with this, so I guess it has been fixed for a long
time.
But yes, there are still robustness issues with stgit. It looks like
the user base is small, since there are not so many bugreports. We
tend to take care about the workfows we use, and people with other
workflows obviously should tell us what gets wrong :)
Best regards,
--
Yann
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Steffen Prohaska @ 2007-08-04 8:28 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: Michael Haggerty, Git Mailing List
In-Reply-To: <46B25FC3.6000205@fs.ei.tum.de>
On Aug 3, 2007, at 12:50 AM, Simon 'corecode' Schubert wrote:
> Steffen Prohaska wrote:
>>> yah, that pretty much tells me it is shawn's bug :) but without
>>> more details, it is very hard to diagnose.
>> I tried again. Interestingly now togit works but tohg still fails.
>> togit starts with reporting
>> fatal: Not a valid object name
>
> that's fine.
Looks a bit scary. Could you hide the message from the user
if it's fine.
>> as the first line. But besides that it seems to work fine. What
>> concerns me a bit is that the last line togit reports is
>> committing set 18100/18173
>> I'd expect it should report 18173/18173.
>
> that's fine as well. You only saw multiples of 100, but you didn't
> consider it would skip the itermediate ones, right? :)
I don't care about the intermediates, but only about the
last one. I'd expect that a successful import would report
as the last line 18173/18173. If the first number is smaller
than the second, this indicates to me that there's something
left to do.
>> BTW, togit creates much more complex branching patterns than cvs2svn
>> does. The attached file branching.png displays a small view of a
>> branching pattern that extends downwards over a couple of screens.
>> I checked the cvs2svn history again. It doesn't contain anything
>> of similar complexity.
>
> haha yea, there is still some issue with duplicate branch names and
> the branchpoint. if it doesn't get the branch right, it will
> always "pull" files from the parent branch.
>
> did you do some manual RCS file copying or manual branch name
> changing of individual files? this could be the reason. I still
> have to find a simple repo to reproduce this.
Maybe, the repo is 8 years old. It started before I joined the
development.
Steffen
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Sam Ravnborg @ 2007-08-04 9:12 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <46B418AA.4070701@midwinter.com>
On Sat, Aug 04, 2007 at 02:11:54PM +0800, Steven Grimm wrote:
> Junio C Hamano wrote:
> >If I read you correctly, what you are proposing to offer is a
> >clone of asciidoc, perhaps AsciiDoc 7, with only xhtml11 and man
> >backends. It is a subset in the sense that you will do only two
> >backends, but otherwise is a clone in the sense that you are
> >going to implement the input language we use (one thing I
> >personally care about while probably other people do not is the
> >conditional compilation "ifdef::stalenotes[]" in git.txt).
> >
>
> Yes and no. I am not offering to clone *all* of AsciiDoc, just whatever
> subset is necessary to format the git documentation. (Of course, having
> looked at this very little so far, perhaps that really is all of
> AsciiDoc -- but it's certainly not all of xmlto.)
Never looked at Ascii-doc... but how about finding the loopholes
in Ascii-doc to make it 10x faster?
That would benefit a larger user-base than just doing-it-ourself.
Sam
^ permalink raw reply
* [RFC/PATCH] update-index: Add a --refresh-only option to refresh specified files.
From: Alexandre Julliard @ 2007-08-04 9:59 UTC (permalink / raw)
To: git
This allows to quickly refresh a file that has been touched without
having to stat all the files of the project.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
Does this look reasonable? The refresh_index_path() function is a
copy/paste of refresh_index(), I'm not sure all of it is really
needed, but I don't claim to understand all the subtleties of the
index management...
builtin-update-index.c | 17 +++++++++++++--
cache.h | 1 +
read-cache.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 509369e..ac24ef3 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -22,6 +22,7 @@ static int allow_add;
static int allow_remove;
static int allow_replace;
static int info_only;
+static int refresh_only;
static int force_remove;
static int verbose;
static int mark_valid_only;
@@ -266,8 +267,9 @@ static void chmod_path(int flip, const char *path)
die("git-update-index: cannot chmod %cx '%s'", flip, path);
}
-static void update_one(const char *path, const char *prefix, int prefix_length)
+static int update_one(const char *path, const char *prefix, int prefix_length)
{
+ int has_errors = 0;
const char *p = prefix_path(prefix, prefix_length, path);
if (!verify_path(p)) {
fprintf(stderr, "Ignoring path %s\n", path);
@@ -278,6 +280,10 @@ static void update_one(const char *path, const char *prefix, int prefix_length)
die("Unable to mark file %s", path);
goto free_return;
}
+ if (refresh_only) {
+ has_errors |= refresh_index_path(&the_index, 0, path);
+ goto free_return;
+ }
cache_tree_invalidate_path(active_cache_tree, path);
if (force_remove) {
@@ -292,6 +298,7 @@ static void update_one(const char *path, const char *prefix, int prefix_length)
free_return:
if (p < path || p > path + strlen(path))
free((char*)p);
+ return has_errors;
}
static void read_index_info(int line_termination)
@@ -620,6 +627,10 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
has_errors |= refresh_cache(REFRESH_REALLY | refresh_flags);
continue;
}
+ if (!strcmp(path, "--refresh-only")) {
+ refresh_only = 1;
+ continue;
+ }
if (!strcmp(path, "--cacheinfo")) {
unsigned char sha1[20];
unsigned int mode;
@@ -702,7 +713,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
die("unknown option %s", path);
}
p = prefix_path(prefix, prefix_length, path);
- update_one(p, NULL, 0);
+ has_errors |= update_one(p, NULL, 0);
if (set_executable_bit)
chmod_path(set_executable_bit, p);
if (p < path || p > path + strlen(path))
@@ -722,7 +733,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
else
path_name = buf.buf;
p = prefix_path(prefix, prefix_length, path_name);
- update_one(p, NULL, 0);
+ has_errors |= update_one(p, NULL, 0);
if (set_executable_bit)
chmod_path(set_executable_bit, p);
if (p < path_name || p > path_name + strlen(path_name))
diff --git a/cache.h b/cache.h
index e97af18..6982ab4 100644
--- a/cache.h
+++ b/cache.h
@@ -278,6 +278,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_QUIET 0x0004 /* be quiet about it */
#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
extern int refresh_index(struct index_state *, unsigned int flags);
+extern int refresh_index_path(struct index_state *istate, unsigned int flags, const char *path);
struct lock_file {
struct lock_file *next;
diff --git a/read-cache.c b/read-cache.c
index e060392..1c0bfe8 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -836,6 +836,55 @@ int refresh_index(struct index_state *istate, unsigned int flags)
return has_errors;
}
+int refresh_index_path(struct index_state *istate, unsigned int flags, const char *path)
+{
+ int really = (flags & REFRESH_REALLY) != 0;
+ int allow_unmerged = (flags & REFRESH_UNMERGED) != 0;
+ int quiet = (flags & REFRESH_QUIET) != 0;
+ int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
+ struct cache_entry *ce, *new;
+ int cache_errno = 0;
+ int i = index_name_pos(istate, path, strlen(path));
+
+ if (i < 0) {
+ printf("%s: not in index\n", path);
+ return 1;
+ }
+
+ ce = istate->cache[i];
+ if (ce_stage(ce)) {
+ if (allow_unmerged)
+ return 0;
+ printf("%s: needs merge\n", ce->name);
+ return 1;
+ }
+
+ new = refresh_cache_ent(istate, ce, really, &cache_errno);
+ if (new == ce)
+ return 0;
+ if (!new) {
+ if (not_new && cache_errno == ENOENT)
+ return 0;
+ if (really && cache_errno == EINVAL) {
+ /* If we are doing --really-refresh that
+ * means the index is not valid anymore.
+ */
+ ce->ce_flags &= ~htons(CE_VALID);
+ istate->cache_changed = 1;
+ }
+ if (quiet)
+ return 0;
+ printf("%s: needs update\n", ce->name);
+ return 1;
+ }
+ istate->cache_changed = 1;
+ /* You can NOT just free istate->cache[i] here, since it
+ * might not be necessarily malloc()ed but can also come
+ * from mmap(). */
+ istate->cache[i] = new;
+ return 0;
+}
+
struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really)
{
return refresh_cache_ent(&the_index, ce, really, NULL);
--
1.5.3.rc4
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* git-gui console app ?
From: Erik Colson @ 2007-08-04 10:10 UTC (permalink / raw)
To: git
Hello !
git-gui is a nice application and I like to use it while developping.
However as probably a lot of developpers do, I regularly code in Emacs
from a distant ssh client.
Therefor I'd want to find some app like git-gui running in console...
Does this exist or is there a project in development ?
Thanks for info
--
Erik
^ permalink raw reply
* Re: Help a sed noob
From: martin f krafft @ 2007-08-04 10:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0708031622w25ab6e9ev61372169cfc0bd98@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
also sprach Nguyen Thai Ngoc Duy <pclouds@gmail.com> [2007.08.04.0122 +0200]:
> sed -ne '/^URL: */{
> s///p
> q
> }' "$GIT_DIR/remotes/$1"
Looks like it prints the first matching line:
grep '^URL: *' | head -1
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
quantum mechanics: the dreams stuff is made of.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Timo Hirvonen @ 2007-08-04 10:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, Ismail Dönmez, git
In-Reply-To: <7vfy2zj4nj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> wrote:
> It might be more worthwhile to research what other "Text-ish
> lightweight mark-up" systems are availble, and if there is one
> that is more efficient and can go to at least html and man,
> one-time convert our documentation source to that format using
> your Perl magic. The minimum requirements are:
>
> * The source is readable without too much mark-up distraction;
>
> * Can go to roff -man;
>
> * Can go to html.
I used asciidoc too but it was really PITA to install and use so I wrote
a small tool (ttman) in C which converts .txt files directly to man
pages. It doesn't have html support but you could use man2html for that.
Unfortunately it does not format as pretty html as asciidoc.
http://onion.dynserv.net/git/?p=cmus.git;a=tree;f=Doc;h=8ab4e92a6356d9cca0d738130fe54026da8c690b;hb=54b6ddacd9d1387c256ce5e7d7d8bb3324799c04
It might be quite easy to extend ttman to output html too...
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Steven Grimm @ 2007-08-04 10:55 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <20070804091249.GA17821@uranus.ravnborg.org>
Sam Ravnborg wrote:
> Never looked at Ascii-doc... but how about finding the loopholes
> in Ascii-doc to make it 10x faster?
> That would benefit a larger user-base than just doing-it-ourself.
>
Because AsciiDoc is only half of the toolchain we use. (Though in your
defense, I made the mistake of only mentioning AsciiDoc by name, rather
than "the AsciiDoc toolchain.") We run asciidoc's output through xmlto,
which is just as slow and is a highly general piece of software for
doing arbitrary transformations of XML documents. I won't say it's
impossible to speed up xmlto as well, of course, but it's probably an
order of magnitude more work than implementing a new parser/renderer for
our .txt files.
-Steve
^ permalink raw reply
* Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 10:55 UTC (permalink / raw)
To: git
I am trying to dig through man-pages and user manual and trying to
match them with reality. I seem to have a hard time. My current
understanding (which definitely differs from the documented state) is
that there are two types of branches, local and remote branches, and
both types of branches can be remote-tracking (it may not be possible
to have a non-remote-tracking remote branch, though).
A local branch is one with a local branch head. In contrast, checking
out a remote branch, while possible, leaves one with a detached head.
"remote-tracking" basically means that git-pull will update the branch
according to changes in the remote repository.
Creating a branch using git-branch or git-checkout will always create
a local branch which may or may not be remote-tracking according to
the --no-track or --track options.
So there are basically three types of branches in a repository that I
can see:
local branch, not remote-tracking
local branch, remote-tracking
remote branch, remote-tracking
The way to add a remote branch basically is not via git-branch or
git-checkout -b (those always create local branches), but by editing
.git/config.
Is this understanding correct or did I get things completely wrong?
Because there is little sense in myself working on changing the
documentation if I have not understood the situation.
Also, the documentation currently uses "remote-tracking"
interchangeably for "local branch, remote-tracking" and "remote
branch, remote-tracking", at some times claiming that one can locally
switch to a "remote-tracking" branch, at other times not.
So the terminology seems fuzzy at the moment, and my attempt to clear
it up might not be the preferred way of doing it.
Thanks,
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-gui console app ?
From: Johannes Schindelin @ 2007-08-04 11:29 UTC (permalink / raw)
To: Erik Colson; +Cc: git
In-Reply-To: <20070804101058.GA520@Mac2.local>
Hi,
On Sat, 4 Aug 2007, Erik Colson wrote:
> git-gui is a nice application and I like to use it while developping.
> However as probably a lot of developpers do, I regularly code in Emacs
> from a distant ssh client.
> Therefor I'd want to find some app like git-gui running in console...
> Does this exist or is there a project in development ?
There is tig. http://repo.or.cz/w/tig.git
It is something similar to gitk but based on curses, so it is a viewer for
now. But I do not see any fundamental reason why it should not be
possible to teach it many of the tricks git-gui does.
Just fork it (you can even do that on repo.or.cz; tig.git is mirrored
there), and give it a go!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Väinö Järvelä @ 2007-08-04 11:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070804065516.GS20052@spearce.org>
On Aug 4, 2007, at 09:55, Shawn O. Pearce wrote:
> I had a devil of a time applying your patch though. git-am
> choked because the patch was whitespace damaged, and then after
> hand-correction and resuming it horribly munged your name's encoding
> in the commit. I think there's a bug in there in git-am; I'll
> have to try to track it down. I managed to get the patch applied
> correctly by editing the mbox file directly, so that git-am did
> not need to stop and ask me to resolve the patch.
You are right in that Mail.app seems to eat up the whitespaces in the
patch. I emailed the patch first to myself, and everything seemed
fine, should have tested it with git-am rather than eyeballing it,
sorry.
About the name-munging, that didn't happen for me, after i fixed the
spacing with Vim, the name shows up correctly in Git log. It seems
that the email is ISO-8859-1 encoded, I'll enforce UTF-8 encoding
next time if it helps, and I'll see if I can send an inlined patch
which works.
--
Väinö
^ permalink raw reply
* [MinGW PATCH] 'git clone git://...' was failing inside git-read-tree with 'fatal: Not a valid object name HEAD'
From: Dmitry Kakurin @ 2007-08-04 11:38 UTC (permalink / raw)
To: git; +Cc: johannes.sixt, Johannes Schindelin
NOTE: This fix uses is_absolute_path from msysGit-0.3.exe that is not in mingw.git yet.
Correctly test for absolute path
This fix (while correct) actually avoids another nasty bug that must be fixed later:
environment.c caches results of many getenv calls.
Under MinGW setenv(X) invalidates all previous values returned by getenv(X)
so cached values become dangling pointers.
Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
---
setup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/setup.c b/setup.c
index e921013..47cd790 100644
--- a/setup.c
+++ b/setup.c
@@ -332,7 +332,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
* In case there is a work tree we may change the directory,
* therefore make GIT_DIR an absolute path.
*/
- if (gitdirenv[0] != '/') {
+ if ( !is_absolute_path( gitdirenv ) ) {
setenv(GIT_DIR_ENVIRONMENT, gitdir, 1);
gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
if (!gitdirenv)
--
mingw.v1.5.2.4.884.gad85-dirty
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Johannes Schindelin @ 2007-08-04 11:38 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <46B418AA.4070701@midwinter.com>
Hi,
On Sat, 4 Aug 2007, Steven Grimm wrote:
> Junio C Hamano wrote:
>
> > * How much can we really rely on your fork to be kept
> > maintained? When we need newer mark-up that is not offered
> > by AsciiDoc 7 clone, is it our plan to model that after
> > AsciiDoc X (X > 7), or we just come up with an extension of
> > our own?
> >
>
> My thought would be to come up with our own syntax; that's a logical
> result of me not considering this anything but "a formatter whose input
> looks suspiciously like AsciiDoc".
There have been a few suggestions to step away from asciidoc in this
thread now. IMNSVHO the only switch which would actually make sense,
would be towards the Wiki format.
Why?
Because right now, we have a _ton_ of documentation on the Gitwiki, and
no easy way to import it back. We also have at least one document which
is (semi-regularly) converted from ascii to Wiki markup.
Wiki markup is relatively easy to read (a bit more disruptive that
asciidoc), but granted, it is lacking features such as the conditional
thing Junio mentioned.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Lars Hjemli @ 2007-08-04 11:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, Sven Verdoolaege, git, Eran Tromer
In-Reply-To: <7v643vj316.fsf@assigned-by-dhcp.cox.net>
On 8/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> As we explicitly allow
> submodule checkout to drift from the supermodule index entry,
> the check should say "Ok, for submodules, not matching is the
> norm" for now. Later when we have the ability to mark "I care
> about this submodule to be always in sync with the superproject"
> (thereby implementing automatic recursive checkout and perhaps
> diff, among other things), we should check if the submodule in
> question is marked as such and perform the current test.
Yes, this sounds like a sane plan (and a good explanation of the
current semantics: maybe something to include in the release notes for
1.5.3?)
Btw: I've applied your patch to rc-4 and tested the result in my cgit
repo: very nice, and very ack'd ;-)
--
larsh
^ 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