* [announce] colgit: manage git repository collections
From: martin f krafft @ 2007-09-06 10:11 UTC (permalink / raw)
To: git discussion list; +Cc: home in vcs discussion list
[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]
[Ob crosspost: please keep vcs-home on Cc all times. Please remove
git mailing list from Cc when the reply isn't enough about git]
Dear colleagues,
Last night, while Andy Roddick was giving his best against bored
world champion Roger Federer (and still lost after a game of many
crazy shots), I reached what I think is a milestone in my attempt to
let git manage my home directory across several machines. I called
it colgit, which attempts to hint at "collection of gits", and this
is the birth announcement of this shell script.
http://git.madduck.net/v/bin/colgit.git
The problem I am trying to solve is that I maintain different
projects in different repos, including scripts in ~/.bin and
configuration files, and that I use multiple computers on a daily
basis. Moreover, I might happen upon a new computer which I have to
use for a few days and would like to be able to set up my account
easily.
With SVN, I'd have a repository for each machine, which existed only
of svn:externals references pulling in other repos and thus
assembling my home directory. git-submodule isn't quite designed for
this sort of stuff, and thus I came up with colgit.
The idea is simple: ~ is a git repository with a .colgit/ directory,
which hosts a hierarchy of directories holding a selection of files
from .git directories. For instance, ~/.colgit/.etc/mutt/config is
the git-config file for the repository that I want to have in
~/.etc/mutt. Since all of ~/.colgit is checked in to the repo in ~,
I can easily clone that for another machine, or branch from it and
add yet other repositories, or remove some.
Each directory in ~/.colgit can also hold hooks, description, and
info/exclude, which are used to seed the repository in the plain
~ hierarchy. Right now, the design requires a central repository and
appropriate remote.origin.*/branch.master.merge entries in the
config file so that it can initialise repositories on new machines.
colgit currently is still very much a hack, but it already sports
the following commands:
update/init: for each leaf directory in ~/.colgit, create the
corresponding repository in ~, seed it, and run git-pull. If the
respository already exists, just pull.
register: given an existing repository somewhere under ~, obtain
the relevant config files from its $GIT_DIR and populate the
corresponding directory under ~/.colgit.
status: for each leaf directory in ~/.colgit, query the
corresponding repository in ~ and note to stdout if it has local
changes
I also envision the following commands:
add: given a repository URL and a local path, clone the repository
and run register
do: run the given git commands over each known repository
The process of initialising an account on a remote machine thus
becomes:
git clone -n ssh://.../machines/base temp && mv temp/.git ~
cd ~ && git checkout HEAD
...
colgit init
This is release early release often, so it's far from perfect and
and probably buggy. But suggestions and patches are welcome!
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
# vim:tw=70
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: [PATCH] Rework strbuf API and semantics.
From: Junio C Hamano @ 2007-09-06 10:03 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <11890199232110-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> diff --git a/strbuf.c b/strbuf.c
> ...
> +void strbuf_addvf(struct strbuf *sb, const char *fmt, va_list ap)
> +{
> + size_t len;
> + va_list ap2;
> +
> + va_copy(ap2, ap);
> +
> + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
> + if (len < 0) {
> + len = 0;
> + }
> + if (len >= sb->alloc - sb->len) {
> + strbuf_grow(sb, len);
> + len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap2);
> + if (len >= sb->alloc - sb->len) {
> + len = sb->alloc - sb->len - 1;
> + }
> + }
> + sb->len = sb->len + len;
> + sb->buf[sb->len] = '\0';
> }
Hmmmmm... Didn't we recently had a patch that used va_copy()
which was not available somewhere and was shot down?
Instead of that nice inline strbuf_addf(), you may have to do
something like:
strbuf_addf(..., fmt, ...) {
va_list ap;
va_start(ap, fmt);
len = vsnprintf(...);
va_end(ap);
if (len >= sb_avail(sb)) {
strbuf_grow(sb, len);
va_start(ap, fmt);
len = vsnprintf(...);
va_end(ap);
if (len >= sb_avail(sb))
gaah();
}
sb->len += len;
sb->buf[sb->len] = '\0';
}
> +ssize_t strbuf_read(struct strbuf *sb, int fd)
> +{
> + size_t oldlen = sb->len;
> +
> + for (;;) {
> + ssize_t cnt;
> +
> + strbuf_grow(sb, 8192);
> + cnt = xread(fd, sb->buf + sb->len, sb->alloc - sb->len - 1);
> + if (cnt < 0) {
> + sb->buf[sb->len = oldlen] = '\0';
Assignment inside array subscript is very hard to read.
Besides, what's the error semantics? On error, this behaves as
if no bytes are read (i.e. partial read results in the initial
round is lost forever)?
^ permalink raw reply
* Re: [PATCH 1/3] git-gui/Makefile: Replace libdir with gitgui_libdir
From: Dmitry V. Levin @ 2007-09-06 10:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070906023227.GH18160@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
On Wed, Sep 05, 2007 at 10:32:27PM -0400, Shawn O. Pearce wrote:
> "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> > On GNU/Linux, libdir is used to mean "/usr/lib or /usr/lib64"
> > depending on architecture. Different libdir meaning breaks
> > idiomatic expressions like rpm specfile "make libdir=%_libdir".
> >
> > Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
> > ---
> > git-gui/Makefile | 16 ++++++++--------
> > 1 files changed, 8 insertions(+), 8 deletions(-)
>
> Although I could apply this with `am -3` I'm NACK'ing this right
> now because...
[...]
> git-gui is its own project with its own Makefile. Junio includes
> it in git.git to help widen its audience, and because it is quite
> portable and easy for him to include. In the future git-gui will
> become a proper subproject of git.git.
The idea is that git-gui's libdir is not a traditional arch-dependent
libdir's subdirectory, but rather arch-independent datadir's subdirectory.
That is, I see no reason to call it libdir even in standalone project.
> If you want to define libdir in git's toplevel Makefile *and*
> that definition is being exported down into git-gui's Makefile
Yes, that was my first motivation, but the issue appears to be a bit more
complex.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-06 9:52 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, Dmitry Kakurin, Matthieu Moy, Git
In-Reply-To: <46DFC490.3060200@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Shawn O. Pearce wrote:
>> Dmitry Kakurin <dmitry.kakurin@gmail.com> wrote:
>>> When I first looked at Git source code two things struck me as odd:
>>> 1. Pure C as opposed to C++. No idea why. Please don't talk about
>>> portability, it's BS.
>>
>> It is also a relatively simple language that
>> a large number of open source programmers know. This makes it easy
>> for them to get involved in the project.
>
>
> This is important. Git contains code from more than 300 people. I'm
> guessing you could cut that number by 2/3 if it had been written in
> C++.
C++ is a language without design discipline. Its set of features and
syntactic elements is incontingent (for example, its templates started
as a ripoff of Ada generics which would have been ok except for the
completely braindead idea of taking the Ada angle bracket restriction
syntax along with it), and it is the task of each programmer to choose
a sane and manageable subset and style, and implement using that. As
a consequence, every C++ programmer writes his own personal dialect of
C++, and we have about 20 different incompatible implementations of
multidimensional numeric arrays, making a complete mockery of the
"code reuse" mantra: C++ _projects_ can't actually usefully achieve
"multiple inheritance" on a design/meta level: once you start with one
non-trivial design, fitting other separately evolved components with a
different style causes retrofitting nightmares.
So going to C++ means cutting down the amount of people who find
themselves comfortable with the actual design and layout down to maybe
10% of those who would actually feel ok with the actual _algorithms_
employed.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 3/9] Add strbuf_printf() to do formatted printing to a strbuf.
From: Pierre Habouzit @ 2007-09-06 9:50 UTC (permalink / raw)
To: Junio C Hamano, Kristian Høgsberg, git
In-Reply-To: <20070906094323.GB8451@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]
On Thu, Sep 06, 2007 at 09:43:23AM +0000, Pierre Habouzit wrote:
> On Thu, Sep 06, 2007 at 08:55:26AM +0000, Junio C Hamano wrote:
> > As you noted in your follow-up message, this one has overlaps
> > with the other strbuf series. I could adjust them if I wanted
> > to, but I do not have time for it right now. I might try over
> > the weekend but no promises.
>
> This one is exactly the same as the one that follows, I corrected a
> typo in the comment of the commit, and I forgot to cleanse my tree
> before running format-patch again, so you have the "second" patch twice
> (name of the patch changed, hence the new one did not replaced the
> previous, but created a 0002-foo.patch instead of overwriting the
> 0002-bar.patch).
>
> You just must drop the one I followup-ed to.
err sorry, I mixed up with another thread. Did not had coffee yet :/
Just nvm
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Rework strbuf API and semantics.
From: Pierre Habouzit @ 2007-09-06 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkbkb0na.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]
On Thu, Sep 06, 2007 at 09:31:37AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > A strbuf can be used to store byte arrays, or as an extended string
> > library. The `buf' member can be passed to any C legacy string function,
> > because strbuf operations always ensure there is a terminating \0 at the end
> > of the buffer, not accounted in the `len' field of the structure.
> >
> > A strbuf can be used to generate a string/buffer whose final size is not
> > really known, and then "strbuf_detach" can be used to get the built buffer,
> > and keep the wrapping "strbuf" structure usable for further work again.
> >
> > Other interesting feature: strbuf_grow(sb, size) ensure that there is
> > enough allocated space in `sb' to put `size' new octets of data in the
> > buffer. It helps avoiding reallocating data for nothing when the problem the
> > strbuf helps to solve has a known typical size.
>
> "Rework API semantics" needs to be accompanied with an API
> description, perhaps at the beginning of each externally
> visible function.
>
> Also the commit log message needs to explain what the old
> semantics was and what the improved one is, to highlight the
> changes needed to the callers. Especially...
>
> > @@ -1657,11 +1656,11 @@ static void *cmd_data (size_t *size)
> > if (term_len == command_buf.len
> > && !strcmp(term, command_buf.buf))
> > break;
> > - ALLOC_GROW(buffer, length + command_buf.len, sz);
> > + ALLOC_GROW(buffer, length + command_buf.len + 1, sz);
> > memcpy(buffer + length,
> > command_buf.buf,
> > - command_buf.len - 1);
> > - length += command_buf.len - 1;
> > + command_buf.len);
> > + length += command_buf.len;
> > buffer[length++] = '\n';
> > }
> > free(term);
>
> .... it is not all obvious why these off-by-one changes are
> needed without such a description. The other hunks in this
> patch to this file are all such changes.
Yes, as I suppose you know, but I state it here again so that
everybody understands, before strbuf's were merely a byte array, not
necessarily NUL-terminated. Hence many parts of the code that wanted to
pass the buffer to str* functions had to manually insert a NUL, hence it
was accounted in the length of the buffer.
Now, we always have a NUL after the "official" end of the buffer, so
it's not needed anymore. The off-by-ones are just that. The hunk you
quote is one where git's code was messing with strbufs internals
directly, so the ALLOC_GROW has to take the 1 octed needed to maintain
the internal invariant. Though, the patch after this one rewrites the
hunk to use strbuf's API's.
>
> > -static void inline strbuf_add(struct strbuf *sb, int ch) {
>
> > +static inline void strbuf_addch(struct strbuf *sb, size_t c) {
> > + strbuf_grow(sb, 1);
> > + sb->buf[sb->len++] = c;
> > + sb->buf[sb->len] = '\0';
> > +}
>
> You certainly did not mean size_t wide characters.
Oh boy, now I've been red-handed of :%s/\<int\>/\<size_t\>/ :)
I'll repost a _clean_ patch series soon with those things fixed, and
the wrong overflow test (that should be a >= and not a >) as well, as we
discussed it on IRC before.
Oh and FWIW I believe the details of the NUL always after the buffer
array has to be in strbuf.h and not in the commit comment, maybe I'll
put it in both to make everybody happy.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/9] Add strbuf_printf() to do formatted printing to a strbuf.
From: Pierre Habouzit @ 2007-09-06 9:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kristian Høgsberg, git
In-Reply-To: <7vwsv4b2bl.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
On Thu, Sep 06, 2007 at 08:55:26AM +0000, Junio C Hamano wrote:
> As you noted in your follow-up message, this one has overlaps
> with the other strbuf series. I could adjust them if I wanted
> to, but I do not have time for it right now. I might try over
> the weekend but no promises.
This one is exactly the same as the one that follows, I corrected a
typo in the comment of the commit, and I forgot to cleanse my tree
before running format-patch again, so you have the "second" patch twice
(name of the patch changed, hence the new one did not replaced the
previous, but created a 0002-foo.patch instead of overwriting the
0002-bar.patch).
You just must drop the one I followup-ed to.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Junio C Hamano @ 2007-09-06 9:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, Dmitry Kakurin, Matthieu Moy, Git
In-Reply-To: <46DFC490.3060200@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Git is cheating a bit though. Its primary audience was (and is) the
> various integrators working on the Linux kernel, all of whom are fairly
> competent C programmers.
Do we still have a huge overlap with the kernel people? I had
an impression that patches from the kernel folks, with notable
exception from a handful (you know who you are), have petered
out rapidly after the first several weeks.
^ permalink raw reply
* Re: [PATCH] Rework strbuf API and semantics.
From: Junio C Hamano @ 2007-09-06 9:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <11890199232110-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> A strbuf can be used to store byte arrays, or as an extended string
> library. The `buf' member can be passed to any C legacy string function,
> because strbuf operations always ensure there is a terminating \0 at the end
> of the buffer, not accounted in the `len' field of the structure.
>
> A strbuf can be used to generate a string/buffer whose final size is not
> really known, and then "strbuf_detach" can be used to get the built buffer,
> and keep the wrapping "strbuf" structure usable for further work again.
>
> Other interesting feature: strbuf_grow(sb, size) ensure that there is
> enough allocated space in `sb' to put `size' new octets of data in the
> buffer. It helps avoiding reallocating data for nothing when the problem the
> strbuf helps to solve has a known typical size.
"Rework API semantics" needs to be accompanied with an API
description, perhaps at the beginning of each externally
visible function.
Also the commit log message needs to explain what the old
semantics was and what the improved one is, to highlight the
changes needed to the callers. Especially...
> @@ -1657,11 +1656,11 @@ static void *cmd_data (size_t *size)
> if (term_len == command_buf.len
> && !strcmp(term, command_buf.buf))
> break;
> - ALLOC_GROW(buffer, length + command_buf.len, sz);
> + ALLOC_GROW(buffer, length + command_buf.len + 1, sz);
> memcpy(buffer + length,
> command_buf.buf,
> - command_buf.len - 1);
> - length += command_buf.len - 1;
> + command_buf.len);
> + length += command_buf.len;
> buffer[length++] = '\n';
> }
> free(term);
... it is not all obvious why these off-by-one changes are
needed without such a description. The other hunks in this
patch to this file are all such changes.
> -static void inline strbuf_add(struct strbuf *sb, int ch) {
> +static inline void strbuf_addch(struct strbuf *sb, size_t c) {
> + strbuf_grow(sb, 1);
> + sb->buf[sb->len++] = c;
> + sb->buf[sb->len] = '\0';
> +}
You certainly did not mean size_t wide characters.
^ permalink raw reply
* Re: People unaware of the importance of "git gc"?
From: Andreas Ericsson @ 2007-09-06 9:28 UTC (permalink / raw)
To: Russ Dill; +Cc: git
In-Reply-To: <loom.20070906T044017-727@post.gmane.org>
Russ Dill wrote:
>> Ok, how about doing something like this?
>>
>
> git add? merge? rebase? No, I have a sneakier place to invoke gc.
>
> Whenever $EDITOR gets invoked. Heck, whenever git is waiting for any user input,
> do some gc in the background, it'd just have to be incremental so that we could
> pick up where we left off.
>
I like it. Writing a commit-message takes anywhere from 30 seconds to 5 minutes
for me (sometimes having to check up bug id's, or verifying details in the code).
Sneaking in a repack here would be absolutely stellar :)
It's also nice in that it won't affect people who just follow a project's tip to
get the bleeding edge. For them it shouldn't matter much that they have multiple
small packs obtained while fetching, or if it's all bungled together in a big one.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andreas Ericsson @ 2007-09-06 9:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dmitry Kakurin, Matthieu Moy, Git
In-Reply-To: <20070906045942.GR18160@spearce.org>
Shawn O. Pearce wrote:
> Dmitry Kakurin <dmitry.kakurin@gmail.com> wrote:
>> When I first looked at Git source code two things struck me as odd:
>> 1. Pure C as opposed to C++. No idea why. Please don't talk about
>> portability, it's BS.
>
> It is also a relatively simple language that
> a large number of open source programmers know. This makes it easy
> for them to get involved in the project.
This is important. Git contains code from more than 300 people. I'm
guessing you could cut that number by 2/3 if it had been written in C++.
Git is cheating a bit though. Its primary audience was (and is) the
various integrators working on the Linux kernel, all of whom are fairly
competent C programmers.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git's database structure
From: Junio C Hamano @ 2007-09-06 9:09 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jon Smirl, Julian Phillips, Theodore Tso, Git Mailing List
In-Reply-To: <46DFBF13.9040109@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Estimated daily uses of git-blame, world-wide: few
> Estimated daily uses of git-{merge,diff}, worldwide: lots
Which makes the author of git-blame weep X-<.
The real issue is that embedding pathname in blob does _not_
help "git blame" but would actively hurt it. A file with the
identical contents moved between the parent to child commit
shares the same blob object and same object name in the real
git. Jon's modified system that hashes pathname together with
the contents would have them as two completely unrelated objects
with different object names, which only means that even 100%
similarity rename case becomes as expensive to find as renames
of lower similarity, which needs to expand and look into blob
contents.
^ permalink raw reply
* Re: [PATCH 3/9] Add strbuf_printf() to do formatted printing to a strbuf.
From: Junio C Hamano @ 2007-09-06 8:55 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <11890382243290-git-send-email-krh@redhat.com>
As you noted in your follow-up message, this one has overlaps
with the other strbuf series. I could adjust them if I wanted
to, but I do not have time for it right now. I might try over
the weekend but no promises.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-09-06 8:52 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* js/tag (Mon Sep 3 17:51:43 2007 +0100) 1 commit
+ verify-tag: also grok CR/LFs in the tag signature
Looks correct. Merge to 'master' this weekend.
* lh/svn-first-parent (Wed Sep 5 11:35:29 2007 +0200) 1 commit
+ git-svn: add support for --first-parent
Queued to 'next' with Eric's blessing. Perhaps merge to
'master' by the end of next week unless there are issues.
* rs/archive (Mon Sep 3 20:08:01 2007 +0200) 3 commits
+ Remove unused function convert_sha1_file()
+ archive: specfile support (--pretty=format: in archive files)
+ Export format_commit_message()
Waiting for the "$Format: ...$" updates.
* js/remote (Sun Sep 2 21:10:14 2007 +0100) 1 commit
+ Teach "git remote" a mirror mode
Waiting for tests. We should resurrect earlier "git remote rm"
and add tests for it as well.
* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
- rebase: allow starting from a dirty tree.
- stash: implement "stash create"
A quick hack to allow starting "git rebase" in a dirty work tree
by automatically stashing the changes first, and unstashing them
after rebase is done. Needs tests and documentation.
* np/delta (Thu Sep 6 02:13:11 2007 -0400) 4 commits
- basic threaded delta search
- rearrange delta search progress reporting
- localize window memory usage accounting
- straighten the list of objects to deltify
I do not know where Nico's "threaded pack generation" would lead
us to yet, so they are parked on 'pu' for now. The first in the
series should be applicable to 'next', though.
* jc/pack (Sat Sep 1 23:53:47 2007 -0700) 1 commit
+ Keep last used delta base in the delta window
Would need to straighten out the implementation from the one
that is suited for the original FIFO usage to another that is
more appropriate for LRU.
* jc/autogc (Wed Sep 5 14:59:59 2007 -0700) 2 commits
- Invoke "git gc --auto" from commit, merge, am and rebase.
- Implement git gc --auto
This has been updated since the ones I sent to the list earlier
in the day. It detects a situation where the user has too much
cruft in the repository that too many loose objects are left
unpruned, and issues a warning. Also 'rebase' is covered by
running "git gc --auto" from either merge or am.
* ph/strbuf (Wed Sep 5 21:18:43 2007 +0200) 7 commits
- Use strbuf in cache-tree.c
- Use strbuf in buitin-rerere.c
- Use strbuf in apply, blame, commit-tree and diff
- mktree: Simplify write_tree() using strbuf's.
- fast-import: Use strbuf API, and simplify cmd_data()
- Simplify strbuf uses in archive-tar.c using strbuf API
- Rework strbuf API and semantics.
The idea is good, and removes more code than it adds, but I find
it not 'next' material yet. I haven't checked every single line
yet, and this series needs that kind of vetting.
* jc/pathspec (Tue Sep 4 02:47:25 2007 -0700) 1 commit
- tree-diff.c: split out a function to match a single pattern.
Just started and not even started to cause breakage yet ;-).
I'd want to fix pathspec semantics of "diff-tree", "log" and
"ls-tree" so that they understand globs in addition to leading
directory prefix, just like "ls-files", "diff-files",
"diff-index" and "grep" does.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
Have been on hold for a long time. This is about traversing the
index, work tree and zero or more trees in parallel, which is
one way to rewrite the merge backend. I may end up reusing
merge-tree.c implementation which would make this series
unnecessary.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-09-06 8:52 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since v1.5.3.1
Dmitry V. Levin (1):
Makefile: Add cache-tree.h to the headers list
Junio C Hamano (1):
git-apply: do not read past the end of buffer
Shawn O. Pearce (3):
Don't allow contrib/workdir/git-new-workdir to trash existing dirs
Cleanup unnecessary file modifications in t1400-update-ref
Include a git-push example for creating a remote branch
* The 'master' branch has these since v1.5.3 in addition to the
above.
Carlos Rica (1):
Function for updating refs.
Douglas Stockwell (1):
send-email: Add support for SSL and SMTP-AUTH
Junio C Hamano (1):
Start 1.5.4 cycle
Simon Hausmann (8):
git-p4: Always call 'p4 sync ...' before submitting to Perforce.
git-p4: After submission to p4 always synchronize from p4 again
(into refs/remotes). Whether to rebase HEAD or not is still
left as question to the end-user.
git-p4: Cleanup; moved the code for getting a sorted list of p4
changes for a list of given depot paths into a standalone
method.
git-p4: Cleanup; moved the code to import a list of p4 changes
using fast-import into a separate member function of P4Sync.
git-p4: Cleanup; Turn self.revision into a function local variable
(it's not used anywhere outside the function).
git-p4: Cleanup; moved the code for the initial #head or revision
import into a separate function, out of P4Sync.run.
git-p4: Cleanup; moved the (duplicated) code for turning a branch
into a git ref (for example foo ->
refs/remotes/p4/<project>/foo) into a separate method.
git-p4: Added support for automatically importing newly appearing
perforce branches.
^ permalink raw reply
* Re: Git's database structure
From: Andreas Ericsson @ 2007-09-06 8:49 UTC (permalink / raw)
To: Jon Smirl; +Cc: Julian Phillips, Theodore Tso, Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910709050912i57ed7137o6abb02ee741d394b@mail.gmail.com>
Jon Smirl wrote:
> On 9/5/07, Julian Phillips <julian@quantumfyre.co.uk> wrote:
>> On Wed, 5 Sep 2007, Jon Smirl wrote:
>>
>>> On 9/5/07, Andreas Ericsson <ae@op5.se> wrote:
>>>> Jon Smirl wrote:
>>>>> The path name field needs to be moved back into the blobs to support
>>>>> alternative indexes. For example I want an index on the Signed-off-by
>>>>> field. I use this index to give me the SHAs for the blobs
>>>>> Signed-off-by a particular person. In the current design I have no way
>>>>> of recovering the path name for these blobs other than a brute force
>>>>> search following every path looking for the right SHA.
>>>>>
>>>> Ah, there we go. A use-case at last :)
>> But not a brilliant one. You sign off on commits not blobs. So you go
>> from the sign-off to paths, then to blobs. There is no need to go from
>> blob to path unless you deliberately introduce such a need.
>
> Use blame for an example. Blame has to crawl every commit to see if it
> touched the file. It keeps doing this until it figures out the last
> author for every line in the file. Worse case blame has to crawl every
> commit in the data store.
>
Estimated daily uses of git-blame, world-wide: few
Estimated daily uses of git-{merge,diff}, worldwide: lots
Code and benchmarks, or I'm not buying it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/3] Makefile: Add install-lib and install-include targets
From: Johannes Schindelin @ 2007-09-06 8:39 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070905232213.GB331@nomad.office.altlinux.org>
Hi,
On Thu, 6 Sep 2007, Dmitry V. Levin wrote:
> Several external projects (e.g. parsecvs) need libgit library
> and related header files.
but does that not pretend that we have a stable API? Which we have not at
all, thank you very much. However, Luiz created a thin libgit in his GSoC
project, and IMHO this would be the way to continue. If it is not
complete enough, well, complete it.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git-svn: add support for --first-parent
From: Lars Hjemli @ 2007-09-06 8:34 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Junio C Hamano
In-Reply-To: <20070906075104.GA10192@hand.yhbt.net>
On 9/6/07, Eric Wong <normalperson@yhbt.net> wrote:
> Lars Hjemli <hjemli@gmail.com> wrote:
> > On 9/5/07, Eric Wong <normalperson@yhbt.net> wrote:
> > > Lars Hjemli <hjemli@gmail.com> wrote:
> > > > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit
> > > > messages, it can get confused when local history contains merges with
> > > > other git-svn branches. But if --first-parent is supplied to git-log,
> > > > working_head_info() will only see 'branch-local' commits and thus the
> > > > first commit containing a 'git-svn-id' line should refer to the correct
> > > > subversion branch.
> > >
> > > Ideally, we'd probably stop, say something and give the user the choice
> > > of branches if multiple parents available.
> >
> > Could you elaborate? (I don't understand how following the first
> > parent of a merge could end up at the wrong svn branch)
>
> Well, if the user didn't know about --first-parent (like me yesterday
> :), they could still end up miscommitting to any branch. That's been a
> complaint of users for a while now. Thinking more about it,
> --first-parent should probably be the default.
>
> But, if they want to commit a different branch instead of the one they
> merged into (so the second/third/fourth parent), --first-parent would
> never give them that chance.
Ok, so maybe '--first-parent' should be the default unless the user
specified something like '--upstream <revspec>', like this:
diff --git a/git-svn.perl b/git-svn.perl
index d21eb7f..0590299 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -819,8 +819,13 @@ sub cmt_metadata {
sub working_head_info {
my ($head, $refs) = @_;
my @args = ('log', '--no-color');
- push @args, '--first-parent' if $_first_parent;
- my ($fh, $ctx) = command_output_pipe(@args, $head);
+ if ($_revspec) {
+ push @args, $_revspec;
+ } else {
+ push @args, '--first-parent';
+ push @args, $head;
+ }
+ my ($fh, $ctx) = command_output_pipe(@args);
my $hash;
my %max;
while (<$fh>) {
This should give the user plenty of rope ;-)
--
larsh
^ permalink raw reply related
* Re: [RFC/PATCH] git-svn: add support for --first-parent
From: David Kastrup @ 2007-09-06 8:05 UTC (permalink / raw)
To: Eric Wong; +Cc: Lars Hjemli, git, Junio C Hamano
In-Reply-To: <20070906075104.GA10192@hand.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Lars Hjemli <hjemli@gmail.com> wrote:
>> On 9/5/07, Eric Wong <normalperson@yhbt.net> wrote:
>> > Lars Hjemli <hjemli@gmail.com> wrote:
>> > > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit
>> > > messages, it can get confused when local history contains merges with
>> > > other git-svn branches. But if --first-parent is supplied to git-log,
>> > > working_head_info() will only see 'branch-local' commits and thus the
>> > > first commit containing a 'git-svn-id' line should refer to the correct
>> > > subversion branch.
>> >
>> > Ideally, we'd probably stop, say something and give the user the choice
>> > of branches if multiple parents available.
>>
>> Could you elaborate? (I don't understand how following the first
>> parent of a merge could end up at the wrong svn branch)
>
> Well, if the user didn't know about --first-parent (like me yesterday
> :), they could still end up miscommitting to any branch. That's been a
> complaint of users for a while now. Thinking more about it,
> --first-parent should probably be the default.
>
> But, if they want to commit a different branch instead of the one they
> merged into (so the second/third/fourth parent), --first-parent would
> never give them that chance.
If they want to commit to a different branch, they can b****y well
check out that branch and merge to _that_. That is the way all the
rest of git works and nobody whines that this is a restriction.
Quite the opposite: that git-svn does not feel constrained to actually
commit to the base of the checked-out branch is a complete nuisance.
_Why_ would anybody want to dcommit to a Subversion branch not
associated with the current branch?
Just yesterday, I _again_ had git-svn dcommit to a nonsensical branch
(this time, the commit was to branch instead of the trunk, while more
often the catastrophes happen the other way round). And it is not
like git-svn gives you a chance to override this bad decision: you
have to rebase -i all of your commit messages from potential
cherrypicks or whatever else and remove the git-svn taglines manually
for every commit before git-svn will deign to dcommit to the same
branch as before.
Eric, this is not "flexibility". This is madness. If you think that
it is essential to dcommit to a branch unrelated to the current HEAD,
then create a sane command line interface for it that takes effect at
the time of dcommit. But the current interface is just throwing dice
as far as the user is concerned, since the addition of git-svn tags to
commit messages happens behind his back, and any merge or cherrypick
or rebase 5 revisions back might come to bite you.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC/PATCH] git-svn: add support for --first-parent
From: Eric Wong @ 2007-09-06 7:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <8c5c35580709060018p50398071s32b271d52f4dc7e3@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
> On 9/5/07, Eric Wong <normalperson@yhbt.net> wrote:
> > Lars Hjemli <hjemli@gmail.com> wrote:
> > > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit
> > > messages, it can get confused when local history contains merges with
> > > other git-svn branches. But if --first-parent is supplied to git-log,
> > > working_head_info() will only see 'branch-local' commits and thus the
> > > first commit containing a 'git-svn-id' line should refer to the correct
> > > subversion branch.
> >
> > Ideally, we'd probably stop, say something and give the user the choice
> > of branches if multiple parents available.
>
> Could you elaborate? (I don't understand how following the first
> parent of a merge could end up at the wrong svn branch)
Well, if the user didn't know about --first-parent (like me yesterday
:), they could still end up miscommitting to any branch. That's been a
complaint of users for a while now. Thinking more about it,
--first-parent should probably be the default.
But, if they want to commit a different branch instead of the one they
merged into (so the second/third/fourth parent), --first-parent would
never give them that chance.
--
Eric Wong
^ permalink raw reply
* Re: [RFC/PATCH] git-svn: add support for --first-parent
From: Lars Hjemli @ 2007-09-06 7:18 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Junio C Hamano
In-Reply-To: <20070905101929.GB11074@soma>
On 9/5/07, Eric Wong <normalperson@yhbt.net> wrote:
> Lars Hjemli <hjemli@gmail.com> wrote:
> > When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit
> > messages, it can get confused when local history contains merges with
> > other git-svn branches. But if --first-parent is supplied to git-log,
> > working_head_info() will only see 'branch-local' commits and thus the
> > first commit containing a 'git-svn-id' line should refer to the correct
> > subversion branch.
>
> Ideally, we'd probably stop, say something and give the user the choice
> of branches if multiple parents available.
Could you elaborate? (I don't understand how following the first
parent of a merge could end up at the wrong svn branch)
--
larsh
^ permalink raw reply
* Re: Significant performance waste in git-svn and friends
From: Eric Wong @ 2007-09-06 7:04 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20070905184710.GA3632@glandium.org>
Mike Hommey <mh@glandium.org> wrote:
> Hi,
Hi Mike,
> Being a pervert abusing the way subversion doesn't deal with branches
> and tags, I'm actually not a user of git-svn or git-svnimport, because
> they just can't deal easily with my perversion. So I'm writing a script
> to do the conversion for me, and since I also like to learn new things
> when I'm coding, I'm writing it in ruby.
>
> Anyways, one of the things I'm trying to convert is my svk repository
> for debian packaging of xulrunner (so, a significant subset of the
> mozilla tree), which doesn't involve a lot of revisions (around 280,
> because I only imported releases or CVS snapshots), but involves a lot
> of files (roughly 20k).
>
> The first thing I noticed when twisting around the svk repo so that
> git-svn could somehow import it a while ago, is that running git-svn
> was in my case significantly slower than svnadmin dump | svnadmin load
> (more than 2 times slower).
>
> And now, with my own script, I got the same kind of "slowdown". So I
> investigated it, and it didn't take long to realize that replacing
> git-hash-object by a simple reimplementation in ruby was *way* faster.
> git-hash-object being more than probably what you do the most when you
> import a remote repository, it is not much of a surprise that forking
> thousands of times is a huge performance waste.
I haven't looked at the times in a while, but I suspect that exec()
is the (much bigger) culprit.
Since I usually import off remote repositories, so I notice network
latency way before I notice local performance problems with git-svn.
> So, just for the record, I did a lame hack of git-svn to see what kind
> of speedup could happen in git-svn. You can find this lame hack as a
> patch below. I did some tests (with a 1.5.2.1 release) and here are the
> results, importing only the trunk (192 revisions), with no checkout, and
> redirecting stdout to /dev/null:
>
> original git-svn:
> real 25m1.871s
> user 8m51.593s
> sys 12m31.659s
>
> patched git-svn:
> real 14m45.870s
> user 7m31.928s
> sys 4m1.047s
That's awesome.
> - It might be worth testing if git-cat-file is called a lot. If so,
> implementing a simple git-cat-file equivalent that would work for
> unpacked objects could improve speed.
IIRC git-cat-file is called a lot. Every modified file needs the
original cat-ed to make use of the delta.
> The same things obviously apply to git-cvsimport and other scripts
> calling git-hash-object a lot.
Making git-svn use fast-import would be very nice. I've got a bunch
of other git-svn things that I need to work on, but having git-svn
converted to use fast-import would be nice. Or allowing Git.pm
to access more of the git internals...
However, how well/poorly would fast-import work for incremental
fetches throughout the day?
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] basic threaded delta search
From: Junio C Hamano @ 2007-09-06 7:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <1189059193250-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> writes:
> this is still rough, hence it is disabled by default. You need to compile
> with "make THREADED_DELTA_SEARCH=1 ..." at the moment.
>
> Threading is done on different portions of the object list to be
> deltified. This is currently done by spliting the list into n parts and
> then a thread is spawned for each of them. A better method would consist
> of spliting the list into more smaller parts and have the n threads
> pick the next part available.
Hmmm. I wonder how the result is affected by such a partition;
aren't you going to have many objects that could have used
somebody else as a delta but gets stored as base because they
happen to be a very early part of their partition (and lacking
delta base candidates in the window)? You cannot solve it with
overlapping partitions without busting the depth limit easily
either, I suspect. Also how would this interact with the LRU
delta base window we discussed a week or two ago?
Separating the list into different object types would not have
any adverse impact coming from the "horizon" of delta base
candidates window (because we do not deltify across types), but
that is not very useful because we cannot gain much parallerism
from such a partition.
^ permalink raw reply
* Re: [PATCH] Include a git-push example for creating a remote branch
From: Junio C Hamano @ 2007-09-06 6:30 UTC (permalink / raw)
To: Miles Bader; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <fc339e4a0709052257m4ddc5784obe64a8b75b79b19@mail.gmail.com>
"Miles Bader" <miles@gnu.org> writes:
> Maybe I"m weird, but I tend to think of the refs/... syntax as being
> for "only if you're doing something funny" cases.
The "refs/" syntax is there as the lowest level that is
universally usable to create and any ref. It can be used to
push to branches, tags, or even remotes (aka "simulated fetch in
reverse").
It is just nobody felt strong enough reason to sugarcoat the
normalized syntax with something like:
git push --create remote foo v1.2.0
You can be a hero by updating git-push to take such, and make it
interpret as if the user passed the normalized syntax which is:
git push remote foo:refs/heads/foo v1.2.0:refs/tags/v1.2.0
^ permalink raw reply
* Re: [PATCH] basic threaded delta search
From: Nicolas Pitre @ 2007-09-06 6:23 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85ps0wfh8h.fsf@lola.goethe.zz>
On Thu, 6 Sep 2007, David Kastrup wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > this is still rough, hence it is disabled by default. You need to compile
> > with "make THREADED_DELTA_SEARCH=1 ..." at the moment.
> >
> > Threading is done on different portions of the object list to be
> > deltified. This is currently done by spliting the list into n parts and
> > then a thread is spawned for each of them. A better method would consist
> > of spliting the list into more smaller parts and have the n threads
> > pick the next part available.
>
> In my experience, the worst performance hit happens when the real
> memory is exhausted and things start paging. Threading on different
> portions of the object list is going to exacerbate the problem in the
> areas where it hits worst.
Just don't use it if you don't have 1) a SMP machine and 2) enough ram.
Threading will be enabled with a command line argument at some point.
Nicolas
^ 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