* Re: [PATCH 2/4] Use parse_date_format() in revisions.c to parse the --date parameter
From: Junio C Hamano @ 2007-09-28 18:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Schindelin
In-Reply-To: <200709281900.25536.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Friday 2007, September 28, Johannes Schindelin wrote:
>
>> Since this is really more like a code move, 1/4 and 2/4 should be
>> squashed.
>
> I have no problem with that.
>
> Junio: would you like a resend?
Sounds like a good plan.
^ permalink raw reply
* Re: [PATCH] Add a --dateformat= option to git-for-each-ref
From: Jeff King @ 2007-09-28 18:47 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200709281516.05438.andyparkins@gmail.com>
On Fri, Sep 28, 2007 at 03:15:58PM +0100, Andy Parkins wrote:
> > like a sane way to implement these sorts of things (e.g.,
> > "%(objectsize:human)", "%(parent:1)", etc).
>
> I'd thought about doing it like that, but imagined that there would
> objections that it was overcomplicating git-for-each-ref. As you
> think that's acceptable, I'll do it.
Well, I'm not sure my opinion counts for much, but at least there are
now two of us. :)
> A patch series that implements both your requested changes to follow.
Patches 1/2 look fine to me (but I agree with the squash suggestion).
3/4 are not exactly what I had in mind, but I think are reasonable in
this case. Rather than treating it was ":format", I had imagined more of
a ":attribute1:attribute2" style, where some attributes may be
understood by all substitutions (e.g., the moral equivalent of shell's
":-" and ":+"), and some only by some substitutions (such as date
formats). And on top of that, these sorts of substitutions should be
unified with the --pretty=format machinery.
Of course, that is a much larger task and you probably just want to do
your date formatting and get your other work done. So I think your
implementation is reasonable, in that it accomplishes what you want in a
reasonable amount of code, and its syntax doesn't prevent moving towards
what I described above (since %(foo:bar:baz) is currently nonsensical,
we would be free to adapt its meaning later).
So in a very verbose way,
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: [EGIT PATCH] Won't append '/' to an empty repo relative path.
From: Robin Rosenberg @ 2007-09-28 19:15 UTC (permalink / raw)
To: Jing Xue; +Cc: git
In-Reply-To: <20070928043957.GA18592@falcon.digizenstudio.com>
fredag 28 september 2007 skrev Jing Xue:
>
> When the repo relative path is empty, the extra "/" causes all subsequent
> "startsWith" tests to fail.
>
Thank you.
Please cc me in the future.
--- robin
^ permalink raw reply
* git-svn eliminating master
From: Russ Brown @ 2007-09-28 20:01 UTC (permalink / raw)
To: git
So I've been using git-svn for a while, and just decided to try
publishing my repo via gitweb so I can experiment with showing others my
local branches before I dcommit them to the subversion repository (i.e.
allowing code review prior to commit).
It's working pretty nicely: the only problem I have is the master
branch. I don't use master at all, and I'm willing to be that a lot of
other git-svn users don't either. I take all of my branches from either
trunk or one of the other upstream svn server branches.
The problem is gitweb appears to show the master branch by default,
while I'd rather show trunk by default. Is it legal to just delete the
master branch, or failing that have it automatically follow trunk so I
don't have to rebase it every time I want to push? Personally I'd rather
delete it because it's not used at all in my case and will only lead to
confuse the other developers who decide to look at my repo.
I've tried deleting master in a test repo, and it seems to be fine. But
I don't know if there are any hidden surprised that might come back to
bite me later.
Thanks.
--
Russ
^ permalink raw reply
* [PATCH] gitk: add check for required tcl version >= 8.4
From: Steffen Prohaska @ 2007-09-28 20:57 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
In-Reply-To: <915048.40970.qm@web38908.mail.mud.yahoo.com>
gitk requires tcl version >= 8.4 to work flawlessly. So let's
check the tcl version and quit if it's too low.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
gitk | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..6ea6489 100755
--- a/gitk
+++ b/gitk
@@ -7,6 +7,11 @@ exec wish "$0" -- "$@"
# and distributed under the terms of the GNU General Public Licence,
# either version 2, or (at your option) any later version.
+if {[info tclversion] < 8.4} {
+ puts stderr "Sorry, gitk requires tcl version >= 8.4."
+ exit 1
+}
+
proc gitdir {} {
global env
if {[info exists env(GIT_DIR)]} {
--
1.5.3.2.111.g5166
^ permalink raw reply related
* Re: [PATCH 2/2] fetch/push: readd rsync support
From: Junio C Hamano @ 2007-09-28 21:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0709281629270.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/transport.c b/transport.c
> index 4f9cddc..c8eed95 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -6,6 +6,330 @@
> ...
> +static int direntry_cmp(const void *a, const void *b)
> +{
> + const struct dirent *d1 = a;
> + const struct dirent *d2 = b;
> +
> + return strcmp(d1->d_name, d2->d_name);
> +}
> ...
> +/*
> + * path is assumed to point to a buffer of PATH_MAX bytes, and
> + * path + name_offset is expected to point to "refs/".
> + */
> +
> +static int read_loose_refs(struct strbuf *path, int name_offset,
> + struct ref **tail)
> +{
> + DIR *dir = opendir(path->buf);
> + struct dirent *de;
> + struct {
> + char **entries;
> + int nr, alloc;
> + } list;
> ...
> + while ((de = readdir(dir))) {
> + if (de->d_name[0] == '.' && (de->d_name[1] == '\0' ||
> + (de->d_name[1] == '.' &&
> + de->d_name[2] == '\0')))
> + continue;
> + ALLOC_GROW(list.entries, list.nr + 1, list.alloc);
> + list.entries[list.nr++] = xstrdup(de->d_name);
> + }
> + closedir(dir);
> +
> + /* sort the list */
> +
> + qsort(list.entries, list.nr, sizeof(*de), direntry_cmp);
Hmmmph...?
^ permalink raw reply
* Re: [PATCH] Merge non-first refs that match first refspec
From: Junio C Hamano @ 2007-09-28 21:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vve9vp1zw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
>> Beats me; Junio, what's your test case?
>
> I can paste tomorrow (it is a clone of git.git at work). I do
> not use .git/config but .git/remotes/origin and explicit four
> separate Pull: lines and going over http.
Here are the files. Note that I use traditional layout and
always have 'master' checked out when I initiate 'git pull'.
: xyzzy git.git/master; cat .git/config
[core]
logallrefupdates = true
[diff]
color = auto
[showbranch]
default = --topo-order
default = master
default = next
default = pu
[alias]
co = checkout
: xyzzy git.git/master; cat .git/remotes origin
URL: http://repo.or.cz/r/alt-git.git/
Pull: master:origin
Pull: next:next
Pull: +pu:pu
Pull: maint:maint
Pull: todo:todo
: xyzzy git.git/master; git pull
Warning: No merge candidate found because value of config option
"branch.master.merge" does not match any remote branch
fetched.
No changes.
: xyzzy git.git/master; git version
git version 1.5.3.2.1060.gaf79f
: xyzzy git.git/master; exit
^ permalink raw reply
* Re: [PATCH] Merge non-first refs that match first refspec
From: Daniel Barkalow @ 2007-09-28 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vps02o55q.fsf@gitster.siamese.dyndns.org>
On Fri, 28 Sep 2007, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> >
> >> Beats me; Junio, what's your test case?
> >
> > I can paste tomorrow (it is a clone of git.git at work). I do
> > not use .git/config but .git/remotes/origin and explicit four
> > separate Pull: lines and going over http.
>
> Here are the files. Note that I use traditional layout and
> always have 'master' checked out when I initiate 'git pull'.
>
> : xyzzy git.git/master; cat .git/config
> [core]
> logallrefupdates = true
>
> [diff]
> color = auto
>
> [showbranch]
> default = --topo-order
> default = master
> default = next
> default = pu
>
> [alias]
> co = checkout
> : xyzzy git.git/master; cat .git/remotes origin
> URL: http://repo.or.cz/r/alt-git.git/
> Pull: master:origin
> Pull: next:next
> Pull: +pu:pu
> Pull: maint:maint
> Pull: todo:todo
The strcmp fails because the config uses an abbreviation and the server
doesn't. Forget my first attempt, and try replacing the strcmp on line 105
with "!remote->fetch[0].pattern", which is what we're really checking,
anyway.
(If this is the first refspec we're on, and we don't have a per-branch
config, and we got a match, and the refspec isn't a pattern, merge it;
anything that matches according to get_fetch_map is a satisfactory match,
even if it doesn't look quite the same.)
I'll do up an actual patch after dinner if nobody beats me to it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-svn eliminating master
From: Junio C Hamano @ 2007-09-28 21:43 UTC (permalink / raw)
To: Russ Brown; +Cc: git
In-Reply-To: <46FD5DAF.7030204@gmail.com>
Russ Brown <pickscrape@gmail.com> writes:
> So I've been using git-svn for a while, and just decided to try
> publishing my repo via gitweb so I can experiment with showing others my
> local branches before I dcommit them to the subversion repository (i.e.
> allowing code review prior to commit).
>
> It's working pretty nicely: the only problem I have is the master
> branch. I don't use master at all, and I'm willing to be that a lot of
> other git-svn users don't either. I take all of my branches from either
> trunk or one of the other upstream svn server branches.
>
> The problem is gitweb appears to show the master branch by default,
> while I'd rather show trunk by default.
I think gitweb shows wherever HEAD points at. Update the file
on the server and see if it helps.
^ permalink raw reply
* git-cat-file "Not a valid object name"
From: Reza Roboubi @ 2007-09-28 22:05 UTC (permalink / raw)
To: git
git-cat-file -t 9b22b50f814b22224d6f838433f1e9cd36bfc2
says: "Not a valid object name".
So what is this thing in my .git:
../.git/objects/92/9b22b50f814b22224d6f838433f1e9cd36bfc2
Thanks in advance.
Reza.
^ permalink raw reply
* Re: git-cat-file "Not a valid object name"
From: Linus Torvalds @ 2007-09-28 22:12 UTC (permalink / raw)
To: Reza Roboubi; +Cc: git
In-Reply-To: <46FD7AA5.2080007@earthdetails.com>
On Fri, 28 Sep 2007, Reza Roboubi wrote:
>
> git-cat-file -t 9b22b50f814b22224d6f838433f1e9cd36bfc2
>
> says: "Not a valid object name".
>
> So what is this thing in my .git:
> ../.git/objects/92/9b22b50f814b22224d6f838433f1e9cd36bfc2
The object name for that thing is 929b22b5... You need the two first hex
digits too (which are used as the fan-out in the object directory).
Linus
^ permalink raw reply
* Re: [PATCH 1/2] Introduce remove_dir_recursively()
From: David Kastrup @ 2007-09-28 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0709281323300.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 28 Sep 2007, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > +int remove_dir_recursively(char *path, int len, int only_empty)
>> > +{
>> > ...
>> > + namlen = strlen(e->d_name);
>> > + if (len + namlen > PATH_MAX ||
>> > + !memcpy(path + len, e->d_name, namlen) ||
>> > + (path[len + namlen] = '\0') ||
>> > + lstat(path, &st))
>> > + ; /* fall thru */
>> > + else if (S_ISDIR(st.st_mode)) {
>> > + if (!remove_dir_recursively(path, len + namlen,
>> > + only_empty))
>> > + continue; /* happy */
>> > + } else if (!only_empty &&
>> > + len + namlen + 1 < PATH_MAX &&
>> > + !unlink(path))
>> > + continue; /* happy, too */
>> > +
>> > + /* path too long, stat fails, or non-directory still exists */
>> > + ret = -1;
>> > + break;
>>
>> Is it only me who finds the first if () condition way too
>> convoluted and needs to read three times to convince oneself
>> that it is doing a sane thing?
>>
>> Please, especially...
>>
>> * For $DEITY's sake, memcpy() returns pointer to dst which you
>> know is not NULL. so !memcpy() is always false here, which
>> might be _convenient_ for you and the compiler but not for
>> a human reader of the code who needs to blink twice wondering
>> if you meant !memcmp().
>>
>> * Same for (path[] = '\0'), wondering if it is misspelled
>> (path[] == '\0').
>
> Okay, will fix (with an evil goto).
Uh, C has a comma operator. And inverting the first condition makes
for a nicer flow, no goto.
namlen = strlen(e->d_name);
if (len + namlen <= PATH_MAX
&& (memcpy(path + len, e->d_name, namlen),
path[len + namlen] = '\0',
lstat(path, &st) == 0)
if (S_ISDIR(st.st_mode)) {
if (!remove_dir_recursively(path, len + namlen,
only_empty))
continue; /* happy */
} else if (!only_empty &&
len + namlen + 1 < PATH_MAX &&
!unlink(path))
continue; /* happy, too */
/* path too long, stat fails, or non-directory still exists */
ret = -1;
break;
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-cat-file "Not a valid object name"
From: Sean @ 2007-09-28 22:15 UTC (permalink / raw)
To: Reza Roboubi; +Cc: git
In-Reply-To: <46FD7AA5.2080007@earthdetails.com>
On Fri, 28 Sep 2007 15:05:25 -0700
Reza Roboubi <reza@earthdetails.com> wrote:
> git-cat-file -t 9b22b50f814b22224d6f838433f1e9cd36bfc2
>
>
> says: "Not a valid object name".
>
> So what is this thing in my .git:
> ../.git/objects/92/9b22b50f814b22224d6f838433f1e9cd36bfc2
Reza,
The first two digits of the sha1 appear before the final slash (/)..
Therefore the actual object name in the case you give is
929b22b50f814b22224d6f838433f1e9cd36bfc2. So the following command
should work:
$ git cat-file -t 929b22b5
Sean
^ permalink raw reply
* Re: git-svn eliminating master
From: Russ Brown @ 2007-09-28 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkaqo49n.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Russ Brown <pickscrape@gmail.com> writes:
>
>> So I've been using git-svn for a while, and just decided to try
>> publishing my repo via gitweb so I can experiment with showing others my
>> local branches before I dcommit them to the subversion repository (i.e.
>> allowing code review prior to commit).
>>
>> It's working pretty nicely: the only problem I have is the master
>> branch. I don't use master at all, and I'm willing to be that a lot of
>> other git-svn users don't either. I take all of my branches from either
>> trunk or one of the other upstream svn server branches.
>>
>> The problem is gitweb appears to show the master branch by default,
>> while I'd rather show trunk by default.
>
> I think gitweb shows wherever HEAD points at. Update the file
> on the server and see if it helps.
Nice tip. I've updated that now. I'll know if it's worked once trunk
gets committed to again: I've rebased master against it so both
currently point at the same commit.
--
Russ
^ permalink raw reply
* Re: [PATCH 2/2] fetch/push: readd rsync support
From: Johannes Schindelin @ 2007-09-28 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vtzpeo5ar.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 28 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/transport.c b/transport.c
> > index 4f9cddc..c8eed95 100644
> > --- a/transport.c
> > +++ b/transport.c
> > @@ -6,6 +6,330 @@
> > ...
> > +static int direntry_cmp(const void *a, const void *b)
> > +{
> > + const struct dirent *d1 = a;
> > + const struct dirent *d2 = b;
> > +
> > + return strcmp(d1->d_name, d2->d_name);
> > +}
> > ...
> > +/*
> > + * path is assumed to point to a buffer of PATH_MAX bytes, and
> > + * path + name_offset is expected to point to "refs/".
> > + */
> > +
> > +static int read_loose_refs(struct strbuf *path, int name_offset,
> > + struct ref **tail)
> > +{
> > + DIR *dir = opendir(path->buf);
> > + struct dirent *de;
> > + struct {
> > + char **entries;
> > + int nr, alloc;
> > + } list;
> > ...
> > + while ((de = readdir(dir))) {
> > + if (de->d_name[0] == '.' && (de->d_name[1] == '\0' ||
> > + (de->d_name[1] == '.' &&
> > + de->d_name[2] == '\0')))
> > + continue;
> > + ALLOC_GROW(list.entries, list.nr + 1, list.alloc);
> > + list.entries[list.nr++] = xstrdup(de->d_name);
> > + }
> > + closedir(dir);
> > +
> > + /* sort the list */
> > +
> > + qsort(list.entries, list.nr, sizeof(*de), direntry_cmp);
>
> Hmmmph...?
Ouch. Sorry.
Will resend in a few minutes. (After reading the patch -- again)
Ciao,
Dscho
^ permalink raw reply
* A tour of git: the basics (and notes on some unfriendly messages)
From: Carl Worth @ 2007-09-28 23:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]
I recently "ported" the introductory chapter of Bryan O’Sullivan's
Distributed revision control with Mercurial[1] from mercurial to
git. The result is here:
A tour of git: the basics
http://cworth.org/hgbook-git/tour/
I did this as an attempt to demonstrate that git and mercurial are
fundamentally equally "easy to learn", and definitely not as an effort
to try to leech Bryan's hard work, (nor would I even want to encourage
that kind of thing). More of my rationale is available here:
Git is easy to learn
http://cworth.org/hgbook-git/
I have two reasons for sharing this with the list. First, I'd
appreciate any feedback that the knowledgable readers on this list
might have. If anything could be made more clear, or if I have factual
mistakes in the text, I'd definitely like to fix those. Please let me
know.
Second, the process of porting the document highlighted a few issues
in git that I think would be nice to fix. I only noticed fairly
cosmetic issues, but I included them as XXX comments in the text. I'll
share them here as well: (all of these are with git 1.5.3.2).
* Is "git help" actually a builtin thing or just a way to call out to
"man"? Does it work at all in Windows ports of git, for example?
(OK, so that one's just a question, not an issue it git)
* Would it make sense to put much smaller amounts of text into "git
help" than the entire man page? For example, maybe just the
description and the most common options or maybe an example? Maybe
do something like "git -v help" for more details? See my text for
more on this, or compare "git help init" to "hg help init" and "hg
-v help init".
* The output from a git-clone operating locally is really confusing:
$ git clone hello hello-clone
Initialized empty Git repository in /tmp/hello-clone/.git/
0 blocks
Empty? Didn't I just clone it? What does "0 blocks" mean?
* git-log by default displays "Date" that is the author date, but
also only uses committer date for options such as --since. This is
confusing.
* It would be nice if all short-format options, (like "git log -p"), were
also available in a long-format option, (like "git log --patch").
* There's a ton of extraneous output from git-fetch. I would love to
see it reduced to a single-line progress bar, (even if a
multiple-staged progress bar). I'm imagining a final line
something like:
Computing (100%) Transferring (100%)
But you can imagine more accurate words than those, (I'm not even
sure what all of the things mean that git-fetch is currently
reporting progress on).
Obviously some of these would be pretty easy, and I should jump into
the git implementation to try them out, but I've just been typing this
stuff as fast as I could, and I'm about to go campout in the rain and
hail now, (fun, fun!), so I wanted to get this out before I forgot
anything.
Thanks in advance for any of your time, attention, or feedback, (and
especially any patches!).
-Carl
[1] http://hgbook.red-bean.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Allow abbreviations in the first refspec to be merged
From: Daniel Barkalow @ 2007-09-28 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The config item for a refspec side and the ref name that it matches
aren't necessarily character-for-character identical. We actually want
to merge a ref by default if: there is no per-branch config, it is the
found result of looking for the match for the first refspec, and the
first refspec is not a pattern. Beyond that, anything that
get_fetch_map() thinks matches is fine.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
This fixes the configuration you gave for me, and passes all the
usual tests.
builtin-fetch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 2f639cc..ac68ff5 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -102,7 +102,7 @@ static struct ref *get_ref_map(struct transport *transport,
remote->fetch[i].dst[0])
*autotags = 1;
if (!i && !has_merge && ref_map &&
- !strcmp(remote->fetch[0].src, ref_map->name))
+ !remote->fetch[0].pattern)
ref_map->merge = 1;
}
if (has_merge)
--
1.5.3.2.1107.ge9eab8-dirty
^ permalink raw reply related
* Re: [PATCH] Allow abbreviations in the first refspec to be merged
From: Shawn O. Pearce @ 2007-09-28 23:38 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0709281932550.5926@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> The config item for a refspec side and the ref name that it matches
> aren't necessarily character-for-character identical.
[snip]
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> index 2f639cc..ac68ff5 100644
> --- a/builtin-fetch.c
> +++ b/builtin-fetch.c
> @@ -102,7 +102,7 @@ static struct ref *get_ref_map(struct transport *transport,
> remote->fetch[i].dst[0])
> *autotags = 1;
> if (!i && !has_merge && ref_map &&
> - !strcmp(remote->fetch[0].src, ref_map->name))
> + !remote->fetch[0].pattern)
> ref_map->merge = 1;
> }
> if (has_merge)
Ooooooooooooh. Of course. That makes perfect sense now that I
see your explanation and patch. Thanks for fixing that! :-)
--
Shawn.
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Shawn O. Pearce @ 2007-09-29 0:00 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87ir5us82a.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> I recently "ported" the introductory chapter of Bryan O’Sullivan's
> Distributed revision control with Mercurial[1] from mercurial to
> git. The result is here:
>
> A tour of git: the basics
> http://cworth.org/hgbook-git/tour/
Interesting.
> * Is "git help" actually a builtin thing or just a way to call out to
> "man"? Does it work at all in Windows ports of git, for example?
> (OK, so that one's just a question, not an issue it git)
`git help` with no arguments displays a message compiled into git.
`git help init` runs `man git-init`. If you don't have any manual
pages installed, or if they aren't available to your man installation
then it fails with "No manual entry for git-init" or whatever your
local man implementation dumps.
Brett Schwartz started an asciidoc viewer for Tcl/Tk that I am still
playing around with and trying to get working right in git-gui.
In theory one could use that to display the manual right from the
asciidoc files, thus bypassing the need for asciidoc and xmlto.
On Cygwin we have man, so `git help init` (or `git init --help`) work
just fine to display the manual entry. No idea about the MSYS port.
> * The output from a git-clone operating locally is really confusing:
>
> $ git clone hello hello-clone
> Initialized empty Git repository in /tmp/hello-clone/.git/
> 0 blocks
>
> Empty? Didn't I just clone it? What does "0 blocks" mean?
Yea. That's because we realized its on the local disk and used
`cpio` with hardlinks to copy the files. So cpio says it copied
0 blocks as it actually just hardlinked everything for you. No
data was actually copied.
git-gui's new clone UI uses fancy progress meters here and tries
to shield the user from "plumbing and UNIX tools" spitting out
seemingly nonsense messages. We probably should try harder in
git-clone to do the same here.
> * git-log by default displays "Date" that is the author date, but
> also only uses committer date for options such as --since. This is
> confusing.
I've never thought about that. But when you say it I think its very
obvious that it could be confusing to a new user. Maybe we should
show the committer line and its date if it doesn't match the author
name/date. Usually I don't care who committed a change in git.git
(its a very small handful of people that Junio pulls from directly)
but at day-job committer name is usually just as interesting as
the author name *when they aren't the same*.
> * There's a ton of extraneous output from git-fetch. I would love to
> see it reduced to a single-line progress bar, (even if a
> multiple-staged progress bar). I'm imagining a final line
> something like:
>
> Computing (100%) Transferring (100%)
>
> But you can imagine more accurate words than those, (I'm not even
> sure what all of the things mean that git-fetch is currently
> reporting progress on).
Yea. About half of that output is from pack-objects and either
unpack-objects or index-pack. The other part is from git-fetch
itself as it updates the local tracking branches (if any are to be
updated). Now that git-fetch is in C and reasonably stable maybe
I can look into making this prettier. Few people really grok the
pack-objects/index-pack output, nor do they care. They just want
to know two things:
- Is git working or frozen in limbo?
- Is git frozen because my network sucks, or git sucks?
- When will this be done? Please $DIETY, I want to go home!
Make the fetch finish!
The C based git-fetch made the http protocol almost totally silent.
(No more got/walk messages.) But that's actually also bad as it
now doesn't even let you know its transferring anything at all.
There are serious issues here about getting the user the progress
they really want. The last item ("When will this be done?") is
actually not possible to determine under either the native git
protocol or HTTP/FTP. We have no idea up front how much data must
be transferred. In the native git case we do know how many objects,
but we don't know how many bytes that will be. It could be under
a kilobyte in one project. That same object count for a different
set of objects fetch could be 500M. Radically different transfer
times would be required.
--
Shawn.
^ permalink raw reply
* [PATCH v3 2/2] fetch/push: readd rsync support
From: Johannes Schindelin @ 2007-09-29 0:35 UTC (permalink / raw)
To: Junio C Hamano, spearce; +Cc: Daniel Barkalow, git
In-Reply-To: <7vtzpeo5ar.fsf@gitster.siamese.dyndns.org>
We lost rsync support when transitioning from shell to C. Support it
again (even if the transport is technically deprecated, some people just
do not have any chance to use anything else).
Also, add a test to t5510. Since rsync transport is not configured by
default on most machines, and especially not such that you can
write to rsync://127.0.0.1$(pwd)/, it is disabled by default; you can
enable it by setting the environment variable TEST_RSYNC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Sorry for the borked v2 of this patch...
I cleaned up some other parts, such as free()ing or close()ing
also in case of an error.
t/t5510-fetch.sh | 35 ++++++
transport.c | 328 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 362 insertions(+), 1 deletions(-)
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 439430f..73a4e3c 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -153,4 +153,39 @@ test_expect_success 'bundle should be able to create a full history' '
'
+test "$TEST_RSYNC" && {
+test_expect_success 'fetch via rsync' '
+ git pack-refs &&
+ mkdir rsynced &&
+ cd rsynced &&
+ git init &&
+ git fetch rsync://127.0.0.1$(pwd)/../.git master:refs/heads/master &&
+ git gc --prune &&
+ test $(git rev-parse master) = $(cd .. && git rev-parse master) &&
+ git fsck --full
+'
+
+test_expect_success 'push via rsync' '
+ mkdir ../rsynced2 &&
+ (cd ../rsynced2 &&
+ git init) &&
+ git push rsync://127.0.0.1$(pwd)/../rsynced2/.git master &&
+ cd ../rsynced2 &&
+ git gc --prune &&
+ test $(git rev-parse master) = $(cd .. && git rev-parse master) &&
+ git fsck --full
+'
+
+test_expect_success 'push via rsync' '
+ cd .. &&
+ mkdir rsynced3 &&
+ (cd rsynced3 &&
+ git init) &&
+ git push --all rsync://127.0.0.1$(pwd)/rsynced3/.git &&
+ cd rsynced3 &&
+ test $(git rev-parse master) = $(cd .. && git rev-parse master) &&
+ git fsck --full
+'
+}
+
test_done
diff --git a/transport.c b/transport.c
index 4f9cddc..a2ee8f3 100644
--- a/transport.c
+++ b/transport.c
@@ -6,6 +6,330 @@
#include "fetch-pack.h"
#include "walker.h"
#include "bundle.h"
+#include "dir.h"
+#include "refs.h"
+
+/* rsync support */
+
+/*
+ * We copy packed-refs and refs/ into a temporary file, then read the
+ * loose refs recursively (sorting whenever possible), and then inserting
+ * those packed refs that are not yet in the list (not validating, but
+ * assuming that the file is sorted).
+ *
+ * Appears refactoring this from refs.c is too cumbersome.
+ */
+
+static int str_cmp(const void *a, const void *b)
+{
+ const char *s1 = a;
+ const char *s2 = b;
+
+ return strcmp(s1, s2);
+}
+
+/* path->buf + name_offset is expected to point to "refs/" */
+
+static int read_loose_refs(struct strbuf *path, int name_offset,
+ struct ref **tail)
+{
+ DIR *dir = opendir(path->buf);
+ struct dirent *de;
+ struct {
+ char **entries;
+ int nr, alloc;
+ } list;
+ int i, pathlen;
+
+ if (!dir)
+ return -1;
+
+ memset (&list, 0, sizeof(list));
+
+ while ((de = readdir(dir))) {
+ if (de->d_name[0] == '.' && (de->d_name[1] == '\0' ||
+ (de->d_name[1] == '.' &&
+ de->d_name[2] == '\0')))
+ continue;
+ ALLOC_GROW(list.entries, list.nr + 1, list.alloc);
+ list.entries[list.nr++] = xstrdup(de->d_name);
+ }
+ closedir(dir);
+
+ /* sort the list */
+
+ qsort(list.entries, list.nr, sizeof(char *), str_cmp);
+
+ pathlen = path->len;
+ strbuf_addch(path, '/');
+
+ for (i = 0; i < list.nr; i++, strbuf_setlen(path, pathlen + 1)) {
+ strbuf_addstr(path, list.entries[i]);
+ if (read_loose_refs(path, name_offset, tail)) {
+ int fd = open(path->buf, O_RDONLY);
+ char buffer[40];
+ struct ref *next;
+
+ if (fd < 0)
+ continue;
+ next = alloc_ref(path->len - name_offset + 1);
+ if (read_in_full(fd, buffer, 40) != 40 ||
+ get_sha1_hex(buffer, next->old_sha1)) {
+ close(fd);
+ free(next);
+ continue;
+ }
+ close(fd);
+ strcpy(next->name, path->buf + name_offset);
+ (*tail)->next = next;
+ *tail = next;
+ }
+ }
+ strbuf_setlen(path, pathlen);
+
+ for (i = 0; i < list.nr; i++)
+ free(list.entries[i]);
+ free(list.entries);
+
+ return 0;
+}
+
+/* insert the packed refs for which no loose refs were found */
+
+static void insert_packed_refs(const char *packed_refs, struct ref **list)
+{
+ FILE *f = fopen(packed_refs, "r");
+ static char buffer[PATH_MAX];
+
+ if (!f)
+ return;
+
+ for (;;) {
+ int cmp, len;
+
+ if (!fgets(buffer, sizeof(buffer), f)) {
+ fclose(f);
+ return;
+ }
+
+ if (hexval(buffer[0]) > 0xf)
+ continue;
+ len = strlen(buffer);
+ if (buffer[len - 1] == '\n')
+ buffer[--len] = '\0';
+ if (len < 41)
+ continue;
+ while ((*list)->next &&
+ (cmp = strcmp(buffer + 41,
+ (*list)->next->name)) > 0)
+ list = &(*list)->next;
+ if (!(*list)->next || cmp < 0) {
+ struct ref *next = alloc_ref(len - 40);
+ buffer[40] = '\0';
+ if (get_sha1_hex(buffer, next->old_sha1)) {
+ warning ("invalid SHA-1: %s", buffer);
+ free(next);
+ continue;
+ }
+ strcpy(next->name, buffer + 41);
+ next->next = (*list)->next;
+ (*list)->next = next;
+ list = &(*list)->next;
+ }
+ }
+}
+
+static struct ref *get_refs_via_rsync(const struct transport *transport)
+{
+ struct strbuf buf = STRBUF_INIT, temp_dir = STRBUF_INIT;
+ struct ref dummy, *tail = &dummy;
+ struct child_process rsync;
+ const char *args[5];
+ int temp_dir_len;
+
+ /* copy the refs to the temporary directory */
+
+ strbuf_addstr(&temp_dir, git_path("rsync-refs-XXXXXX"));
+ if (!mkdtemp(temp_dir.buf))
+ die ("Could not make temporary directory");
+ temp_dir_len = temp_dir.len;
+
+ strbuf_addstr(&buf, transport->url);
+ strbuf_addstr(&buf, "/refs");
+
+ memset(&rsync, 0, sizeof(rsync));
+ rsync.argv = args;
+ rsync.stdout_to_stderr = 1;
+ args[0] = "rsync";
+ args[1] = transport->verbose ? "-rv" : "-r";
+ args[2] = buf.buf;
+ args[3] = temp_dir.buf;
+ args[4] = NULL;
+
+ if (run_command(&rsync))
+ die ("Could not run rsync to get refs");
+
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, transport->url);
+ strbuf_addstr(&buf, "/packed-refs");
+
+ args[2] = buf.buf;
+
+ if (run_command(&rsync))
+ die ("Could not run rsync to get refs");
+
+ /* read the copied refs */
+
+ strbuf_addstr(&temp_dir, "/refs");
+ read_loose_refs(&temp_dir, temp_dir_len + 1, &tail);
+ strbuf_setlen(&temp_dir, temp_dir_len);
+
+ tail = &dummy;
+ strbuf_addstr(&temp_dir, "/packed-refs");
+ insert_packed_refs(temp_dir.buf, &tail);
+ strbuf_setlen(&temp_dir, temp_dir_len);
+
+ if (remove_dir_recursively(&temp_dir, 0))
+ warning ("Error removing temporary directory %s.",
+ temp_dir.buf);
+
+ strbuf_release(&buf);
+ strbuf_release(&temp_dir);
+
+ return dummy.next;
+}
+
+static int fetch_objs_via_rsync(struct transport *transport,
+ int nr_objs, struct ref **to_fetch)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process rsync;
+ const char *args[8];
+ int result;
+
+ strbuf_addstr(&buf, transport->url);
+ strbuf_addstr(&buf, "/objects/");
+
+ memset(&rsync, 0, sizeof(rsync));
+ rsync.argv = args;
+ rsync.stdout_to_stderr = 1;
+ args[0] = "rsync";
+ args[1] = transport->verbose ? "-rv" : "-r";
+ args[2] = "--ignore-existing";
+ args[3] = "--exclude";
+ args[4] = "info";
+ args[5] = buf.buf;
+ args[6] = get_object_directory();
+ args[7] = NULL;
+
+ /* NEEDSWORK: handle one level of alternates */
+ result = run_command(&rsync);
+
+ strbuf_release(&buf);
+
+ return result;
+}
+
+static int write_one_ref(const char *name, const unsigned char *sha1,
+ int flags, void *data)
+{
+ struct strbuf *buf = data;
+ int len = buf->len;
+ FILE *f;
+
+ /* when called via for_each_ref(), flags is non-zero */
+ if (flags && prefixcmp(name, "refs/heads/") &&
+ prefixcmp(name, "refs/tags/"))
+ return 0;
+
+ strbuf_addstr(buf, name);
+ if (safe_create_leading_directories(buf->buf) ||
+ !(f = fopen(buf->buf, "w")) ||
+ fprintf(f, "%s\n", sha1_to_hex(sha1)) < 0 ||
+ fclose(f))
+ return error("problems writing temporary file %s", buf->buf);
+ strbuf_setlen(buf, len);
+ return 0;
+}
+
+static int write_refs_to_temp_dir(struct strbuf *temp_dir,
+ int refspec_nr, const char **refspec)
+{
+ int i;
+
+ for (i = 0; i < refspec_nr; i++) {
+ unsigned char sha1[20];
+ char *ref;
+
+ if (dwim_ref(refspec[i], strlen(refspec[i]), sha1, &ref) != 1)
+ return error("Could not get ref %s", refspec[i]);
+
+ if (write_one_ref(ref, sha1, 0, temp_dir)) {
+ free(ref);
+ return -1;
+ }
+ free(ref);
+ }
+ return 0;
+}
+
+static int rsync_transport_push(struct transport *transport,
+ int refspec_nr, const char **refspec, int flags)
+{
+ struct strbuf buf = STRBUF_INIT, temp_dir = STRBUF_INIT;
+ int result = 0, i;
+ struct child_process rsync;
+ const char *args[8];
+
+ /* first push the objects */
+
+ strbuf_addstr(&buf, transport->url);
+ strbuf_addch(&buf, '/');
+
+ memset(&rsync, 0, sizeof(rsync));
+ rsync.argv = args;
+ rsync.stdout_to_stderr = 1;
+ args[0] = "rsync";
+ args[1] = transport->verbose ? "-av" : "-a";
+ args[2] = "--ignore-existing";
+ args[3] = "--exclude";
+ args[4] = "info";
+ args[5] = get_object_directory();;
+ args[6] = buf.buf;
+ args[7] = NULL;
+
+ if (run_command(&rsync))
+ return error("Could not push objects to %s", transport->url);
+
+ /* copy the refs to the temporary directory; they could be packed. */
+
+ strbuf_addstr(&temp_dir, git_path("rsync-refs-XXXXXX"));
+ if (!mkdtemp(temp_dir.buf))
+ die ("Could not make temporary directory");
+ strbuf_addch(&temp_dir, '/');
+
+ if (flags & TRANSPORT_PUSH_ALL) {
+ if (for_each_ref(write_one_ref, &temp_dir))
+ return -1;
+ } else if (write_refs_to_temp_dir(&temp_dir, refspec_nr, refspec))
+ return -1;
+
+ i = (flags & TRANSPORT_PUSH_FORCE) ? 2 : 3;
+ args[i++] = temp_dir.buf;
+ args[i++] = transport->url;
+ args[i++] = NULL;
+ if (run_command(&rsync))
+ result = error("Could not push to %s", transport->url);
+
+ if (remove_dir_recursively(&temp_dir, 0))
+ warning ("Could not remove temporary directory %s.",
+ temp_dir.buf);
+
+ strbuf_release(&buf);
+ strbuf_release(&temp_dir);
+
+ return result;
+}
/* Generic functions for using commit walkers */
@@ -402,7 +726,9 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->url = url;
if (!prefixcmp(url, "rsync://")) {
- /* not supported; don't populate any ops */
+ ret->get_refs_list = get_refs_via_rsync;
+ ret->fetch = fetch_objs_via_rsync;
+ ret->push = rsync_transport_push;
} else if (!prefixcmp(url, "http://")
|| !prefixcmp(url, "https://")
--
1.5.3.2.1102.g9487
^ permalink raw reply related
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Junio C Hamano @ 2007-09-29 0:45 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87ir5us82a.wl%cworth@cworth.org>
Thanks for starting this. It was an interesting read.
----------------------------------------------------------------
#2.2.1
"git help init" would give man page. The time when the short
help is given is when you mistype options, as in:
$ git init --huh?
#2.4
By default this command prints a brief paragraph of output...
Not really. The default is to give you the entire log message,
unless you somehow made --pretty=short the default with your
copy of git.
The "git log" tool doesn't display the Committer...
You can ask it to, so "by default" is missing.
#2.7.1
But some poepl, (notably Linus...
typo.
#2.7.6
for which "git commit --amend" was
was what? "invented" perhaps?
#2.8.3
Using "git remote" to pull changes other repositories
"changes from other repositories".
----------------------------------------------------------------
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Johannes Schindelin @ 2007-09-29 0:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Carl Worth, git
In-Reply-To: <20070929000056.GZ3099@spearce.org>
Hi,
On Fri, 28 Sep 2007, Shawn O. Pearce wrote:
> On Cygwin we have man, so `git help init` (or `git init --help`) work
> just fine to display the manual entry. No idea about the MSYS port.
We open the html pages. That is, we don't yet, since we do not generate
the html pages just yet; asciidoc is a Python program, and Python is not
available as an MSys program as far as I know (and asciidoc insists on
finding files in a Unix-like file structure, so we _do_ need an MSys
Python).
... but all this would be easier if we succeeded in having a minimal
asciidoc lookalike in git.git...
> > * The output from a git-clone operating locally is really confusing:
> >
> > $ git clone hello hello-clone
> > Initialized empty Git repository in /tmp/hello-clone/.git/
> > 0 blocks
> >
> > Empty? Didn't I just clone it? What does "0 blocks" mean?
>
> Yea. That's because we realized its on the local disk and used
> `cpio` with hardlinks to copy the files. So cpio says it copied
> 0 blocks as it actually just hardlinked everything for you. No
> data was actually copied.
>
> git-gui's new clone UI uses fancy progress meters here and tries
> to shield the user from "plumbing and UNIX tools" spitting out
> seemingly nonsense messages. We probably should try harder in
> git-clone to do the same here.
AFAICT git-clone is a prime candidate for builtinification, after which
issues like this should be easy to address.
> > * git-log by default displays "Date" that is the author date, but
> > also only uses committer date for options such as --since. This is
> > confusing.
>
> I've never thought about that. But when you say it I think its very
> obvious that it could be confusing to a new user. Maybe we should show
> the committer line and its date if it doesn't match the author
> name/date. Usually I don't care who committed a change in git.git (its
> a very small handful of people that Junio pulls from directly) but at
> day-job committer name is usually just as interesting as the author name
> *when they aren't the same*.
--pretty=fuller
Ciao,
Dscho
^ permalink raw reply
* Re: Use of strbuf.buf when strbuf.len == 0
From: Linus Torvalds @ 2007-09-29 0:51 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20070927101300.GD10289@artemis.corp>
On Thu, 27 Sep 2007, Pierre Habouzit wrote:
>
> I can see a way, that would need special proof-reading of the strbuf
> module, but should not harm its users, that would be to change
> STRBUF_INIT to work this way:
>
> { .buf = "", .len = 0, .alloc = 0 }
I'd like to pipe up a bit here..
I think the above is a good fix for the current problem of wanting to
always be able to use "sb->buf", but I thinkit actually has the potential
to fix another issue entirely.
Namely strbuf's that are initialized from various static strings and/or
strings not directly allocated with malloc().
That's not necessarily something really unusual. Wanting to initialize a
string with a fixed constant value is a common problem.
And wouldn't it be nice if you could actually do that, with
{ .buf = "static initializer", .len = 18, .alloc = 0 }
and have all the strbuf routines that modify the initializer (including
making it shorter!) notice that the allocation is too short, and create a
new allocation?
Hmm?
Linus
^ permalink raw reply
* [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Johannes Schindelin @ 2007-09-29 1:31 UTC (permalink / raw)
To: gitster, git
When you do many rebases, you can get annoyed by having to type out
the actions "edit" or "squash" in total.
This commit helps that, by allowing you to enter "e" instead of "edit",
or "s" instead of "squash", and it also plays nice with "merge" or "amend"
as synonyms to "squash".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-rebase--interactive.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 823291d..0f9483e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -232,14 +232,14 @@ do_next () {
'#'*|'')
mark_action_done
;;
- pick)
+ pick|p)
comment_for_reflog pick
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
;;
- edit)
+ edit|e)
comment_for_reflog edit
mark_action_done
@@ -254,7 +254,7 @@ do_next () {
warn
exit 0
;;
- squash)
+ squash|s|merge|m|amend|a)
comment_for_reflog squash
has_action "$DONE" ||
@@ -263,7 +263,7 @@ do_next () {
mark_action_done
make_squash_message $sha1 > "$MSG"
case "$(peek_next_command)" in
- squash)
+ squash|s|merge|m|amend|a)
EDIT_COMMIT=
USE_OUTPUT=output
cp "$MSG" "$SQUASH_MSG"
--
1.5.3.2.1102.g9487
^ permalink raw reply related
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Junio C Hamano @ 2007-09-29 2:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0709290231300.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When you do many rebases, you can get annoyed by having to type out
> the actions "edit" or "squash" in total.
>
> This commit helps that, by allowing you to enter "e" instead of "edit",
> or "s" instead of "squash", and it also plays nice with "merge" or "amend"
> as synonyms to "squash".
I am not sure if we want to taint the words merge and amend like
this. I was hoping someday you would allow people to reorder
something like this...
e
\
---a---b---c---d
into something like this:
e
\
---b'--c'--a'+d'
The insn sequence you prepare for the user to edit would be:
pick a
pick b
merge c
pick d
and then the user would rewrite that to:
pick b
merge c
pick a
squash d
I do not think making 'amend' a synonym to 'squash' is correct
either; isn't it closer to 'edit'?
I however do agree that giving short-hand would be a good idea.
^ 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