* Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-28 23:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807290153300.2725@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
On Tue, Jul 29, 2008 at 01:54:17AM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Actually, this _is_ the opposite of -s ours, no? -s ours just takes our
> tree, your -s theirs just takes their tree.
>
> Sorry for the confusion I caused,
Aah. :-)
I did not read the source of git-merge-ours and based on your
description I thought my knowledge / the doc about -s ours was not
correct.
So I guess my original patch was right, then.
Note to self: "take 2" gets messy, time to send a "take 3" soon. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] builtin-merge: allow using a custom strategy
From: Johannes Schindelin @ 2008-07-28 23:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1217288908-21124-1-git-send-email-vmiklos@frugalware.org>
Hi,
On Tue, 29 Jul 2008, Miklos Vajna wrote:
> On Mon, Jul 28, 2008 at 03:06:09PM +0200, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > The change in the signature of list_commands() is not part of this
> > patch. So at least one of your commits should result in an
> > uncompileable revision...
>
> Right. I just squashed patch 4 and 5, and this solves the problem: patch
> 3 changes the signature and fixes all usage (in help.c, it's not used
> outside help.c), then the squashed patch introduces the usage of the new
> list_commands() in builtin-merge.c.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807290137370.2725@eeepc-johanness>
Hi,
On Tue, 29 Jul 2008, Johannes Schindelin wrote:
> BTW I have no idea how we could test for this, short of introducing the
> "sleep 1" I did earlier. Maybe guard it with a TEST_EXPENSIVE_CTIME
> variable or something similar. Dunno.
IOW something like this squashed into your patch:
-- snipsnap --
t/t7001-mv.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b0fa407..c749059 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -179,6 +179,10 @@ test_expect_success 'git mv should overwrite symlink to a file' '
git init &&
echo 1 >moved &&
ln -s moved symlink &&
+ if test ! -z "$TEST_EXPENSIVE_CTIME"
+ then
+ sleep 1
+ fi &&
git add moved symlink &&
test_must_fail git mv moved symlink &&
git mv -f moved symlink &&
^ permalink raw reply related
* Re: Showing changes about to be commited via git svn dcommit
From: Miklos Vajna @ 2008-07-28 23:53 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <7968d7490807281554u3954cf51qe2cd87b94284c77f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Mon, Jul 28, 2008 at 04:54:19PM -0600, Lee Marlow <lee.marlow@gmail.com> wrote:
> $> git svn dcommit --dry-run | grep -E '^diff-tree ' | cut -b 11- |
> git diff-tree --stdin -p -v
>
> Is this the real way to do it? Do others do something similar?
Depends on how did you created your git-svn repo. If you have only one
branch with no prefix, then I would try:
git log git-svn..master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Johannes Schindelin @ 2008-07-28 23:54 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <f3af7df2dda2dcb7801314cc993470264259f970.1217288180.git.vmiklos@frugalware.org>
Hi,
On Tue, 29 Jul 2008, Miklos Vajna wrote:
> Testing is done by creating a simple git-merge-theirs strategy which
> just picks the upstream tree. (In other words, this is not the opposite
> of -s ours.)
Actually, this _is_ the opposite of -s ours, no? -s ours just takes our
tree, your -s theirs just takes their tree.
Sorry for the confusion I caused,
Dscho
^ permalink raw reply
* [PATCH] builtin-merge: allow using a custom strategy
From: Miklos Vajna @ 2008-07-28 23:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807281505010.2725@eeepc-johanness>
Allow using a custom strategy, as long as it's named git-merge-foo. The
error handling is now done using is_git_command(). The list of available
strategies is now shown by list_commands().
If an invalid strategy is supplied, like -s foobar, then git-merge would
list all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are removed from the output by scanning the list of main commands;
if the git-merge-foo command is listed in the all_strategy list, then
it's shown, otherwise excluded. This does not exclude commands somewhere
else in the PATH, where custom strategies are expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Mon, Jul 28, 2008 at 03:06:09PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> The change in the signature of list_commands() is not part of this
> patch. So at least one of your commits should result in an
> uncompileable revision...
Right. I just squashed patch 4 and 5, and this solves the problem: patch
3 changes the signature and fixes all usage (in help.c, it's not used
outside help.c), then the squashed patch introduces the usage of the new
list_commands() in builtin-merge.c.
(Also in the 'merge-custom' branch of vmiklos.git on repo.or.cz.)
builtin-merge.c | 32 +++++++++++++++++++++++++-------
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..29826b1 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "help.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -77,7 +78,7 @@ static int option_parse_message(const struct option *opt,
static struct strategy *get_strategy(const char *name)
{
int i;
- struct strbuf err;
+ struct strategy *ret;
if (!name)
return NULL;
@@ -86,12 +87,29 @@ static struct strategy *get_strategy(const char *name)
if (!strcmp(name, all_strategy[i].name))
return &all_strategy[i];
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
+ if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ struct cmdname *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len)
+ && !all_strategy[j].name[ent->len])
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
+ fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
+ list_commands("git-merge-", "strategies", ¬_strategies);
+ exit(1);
+ }
+
+ ret = xmalloc(sizeof(struct strategy));
+ memset(ret, 0, sizeof(struct strategy));
+ ret->name = xstrdup(name);
+ return ret;
}
static void append_strategy(struct strategy *s)
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 23:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, Petr Baudis, git
In-Reply-To: <7vwsj5rf48.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1943 bytes --]
Hi,
On Mon, 28 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 28 Jul 2008, SZEDER Gábor wrote:
> >
> >> there is a race somewhere in these 'git-mv: Keep moved index entries
> >> inact' changes.
> >>
> >> The test cases 'git mv should overwrite symlink to a file' or 'git mv
> >> should overwrite file with a symlink' fail occasionaly. It's quite
> >> non-deterministic: I have run t7001-mv.sh in a loop (see below) and
> >> one or the other usually fails around 50 runs (but sometimes only
> >> after 150). Adding some tracing echos to the tests shows that both
> >> tests fail when running 'git diff-files' at the end.
> >
> > To make it more convenient to test: with this patch it fails all the time:
>
> It's because we rename(2) but do not read back ctime, and reuse the cached
> data from the old path that was renamed. After the failed test that moves
> a regular file "move" to "symlink":
>
> $ stat symlink
> File: `symlink'
> Size: 2 Blocks: 8 IO Block: 4096 regular file
> Device: 30ah/778d Inode: 18104337 Links: 1
> Access: (0664/-rw-rw-r--) Uid: ( 1012/ junio) Gid: ( 40/ src)
> Access: 2008-07-28 11:49:55.000000000 -0700
> Modify: 2008-07-28 11:48:41.000000000 -0700
> Change: 2008-07-28 11:48:42.000000000 -0700
>
> But the cached stat information looks like this:
>
> $ ../../git-ls-files --stat
> ctime=1217270921, mtime=1217270921, ino=18104337, mode=100644, uid=1012, gid=40symlink
>
> We need to refresh the entry to pick up potential ctime changes.
Yep.
Tested-by: me
BTW I have no idea how we could test for this, short of introducing the
"sleep 1" I did earlier. Maybe guard it with a TEST_EXPENSIVE_CTIME
variable or something similar. Dunno.
And my suggestion to use test-chmtime: please just forget about it, and
just assume that I had some very good wiid(1) in my pipe(2).
Ciao,
Dscho
^ permalink raw reply
* [PATCH 6/6] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-28 23:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807281506510.2725@eeepc-johanness>
Testing is done by creating a simple git-merge-theirs strategy which
just picks the upstream tree. (In other words, this is not the opposite
of -s ours.)
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Mon, Jul 28, 2008 at 03:12:59PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Note that what was asked for, and what Junio implemented before
> deciding
> that it would do more harm than good in git.git, is not the same as
> what
> you provide.
Thanks, now I see the difference. The updated commit message is
hopefully better.
Also I added a check to make sure the upstream and the result tree is
the same as well.
t/t7606-merge-custom.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100755 t/t7606-merge-custom.sh
diff --git a/t/t7606-merge-custom.sh b/t/t7606-merge-custom.sh
new file mode 100755
index 0000000..13e8ff5
--- /dev/null
+++ b/t/t7606-merge-custom.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing a custom strategy.'
+
+. ./test-lib.sh
+
+cat > git-merge-theirs << EOF
+#!/bin/sh
+eval git read-tree --reset -u \\\$\$#
+EOF
+chmod +x git-merge-theirs
+PATH=.:$PATH
+export PATH
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ git reset --hard c0 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2
+'
+
+test_expect_success 'merge c2 with a custom strategy' '
+ git reset --hard c1 &&
+ git merge -s theirs c2 &&
+ test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
+ test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
+ test "$(git rev-parse c2^{tree})" = "$(git rev-parse HEAD^{tree})" &&
+ git diff --exit-code &&
+ test -f c0.c &&
+ test ! -f c1.c &&
+ test -f c2.c
+'
+
+test_done
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Johannes Schindelin @ 2008-07-28 23:27 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080728192651.GA26677@sigill.intra.peff.net>
Hi,
On Mon, 28 Jul 2008, Jeff King wrote:
> On Mon, Jul 28, 2008 at 08:09:55PM +0100, Johannes Schindelin wrote:
>
> > Well, I have to say that the workflow is a bit backwards if the person
> > who _publishes_ the thing is the one saying "Ooops, my version no
> > goodie, other version please, but so that pull still works".
> >
> > I would have expected the one who has the good version to make the
> > choice.
>
> My situation was two long-running branches, "stable" and "devel", both
> of which were worked on by many developers. One person was in charge of
> integration and branch management. They wanted "stable" to get the
> contents of "devel" (which were now ready for release), ignoring any
> small fixes that had been done on "stable" (since they had all been
> moved over to "devel" previously, but in subtly different ways that
> would create conflicts). And "git reset" was not an option, because they
> wanted to keep the history of "stable" in case those fixes needed to be
> looked at later.
>
> So the logical sequence was:
>
> git checkout production
> git merge -s theirs master
To me, this suggests that they were too married to 'production' being the
"dominant" branch.
Thing is: they had two branches. They should be merged, but one should
prevail: 'master'.
So if I have two branches, say "x" and "y", and I want to merge them, but
really throw away the tree of "x", I would check out 'y', naturally. Then
'git merge -s ours x'.
If the result should become the state of 'x', too, I would then just
'git push origin y:x'.
Maybe I am "Git-braindead" by now, so that you can make fun of me like I
used to make fun of CVSers and SVNers...
Ciao,
Dscho
^ permalink raw reply
* [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-28 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr69ex00x.fsf@gitster.siamese.dyndns.org>
The supposed method is to build a list of commands to be excluded using
add_cmdname(), then pass the list as the new exclude parameter. If no
exclude is needed, NULL should be used.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sun, Jul 27, 2008 at 06:36:30PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> > + struct cmdname {
> > + size_t len;
> > + char name[1];
> > + } **names;
> > +};
>
> I thought we do this kind of thing using FLEX_ARRAY macro. Is there
> any
> reason its use is not appropriate here?
Now I'm using it. :-)
Note that FLEX_ARRAY would be a drop-in replacement only in case it
would be name[0], so I needed
- struct cmdname *ent = xmalloc(sizeof(*ent) + len);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len + 1);
later in add_cmdname().
help.c | 26 +++++++++++---------------
help.h | 14 +++++++++++++-
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/help.c b/help.c
index 7a42517..858f76a 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
+#include "help.h"
static struct man_viewer_list {
struct man_viewer_list *next;
@@ -300,18 +301,11 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdnames {
- int alloc;
- int cnt;
- struct cmdname {
- size_t len;
- char name[1];
- } **names;
-} main_cmds, other_cmds;
+struct cmdnames main_cmds, other_cmds;
-static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
+void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
- struct cmdname *ent = xmalloc(sizeof(*ent) + len);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len + 1);
ent->len = len;
memcpy(ent->name, name, len);
@@ -463,7 +457,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(const char *prefix)
+static unsigned int load_command_list(const char *prefix, struct cmdnames *exclude)
{
unsigned int longest = 0;
unsigned int len;
@@ -502,13 +496,15 @@ static unsigned int load_command_list(const char *prefix)
sizeof(*other_cmds.names), cmdname_compare);
uniq(&other_cmds);
exclude_cmds(&other_cmds, &main_cmds);
+ if (exclude)
+ exclude_cmds(&main_cmds, exclude);
return longest;
}
-void list_commands(const char *prefix, const char *title)
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude)
{
- unsigned int longest = load_command_list(prefix);
+ unsigned int longest = load_command_list(prefix, exclude);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -558,7 +554,7 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
int is_git_command(const char *s, const char *prefix)
{
- load_command_list(prefix);
+ load_command_list(prefix, NULL);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -704,7 +700,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands("git-", "git commands");
+ list_commands("git-", "git commands", NULL);
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 0741662..3eb8cfb 100644
--- a/help.h
+++ b/help.h
@@ -1,7 +1,19 @@
#ifndef HELP_H
#define HELP_H
+struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[FLEX_ARRAY];
+ } **names;
+};
+
int is_git_command(const char *s, const char *prefix);
-void list_commands(const char *prefix, const char *title);
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude);
+void add_cmdname(struct cmdnames *cmds, const char *name, int len);
+
+extern struct cmdnames main_cmds, other_cmds;
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: git-scm.com
From: Pieter de Bie @ 2008-07-28 22:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Tom Werner, git
In-Reply-To: <7vk5f5ptwu.fsf@gitster.siamese.dyndns.org>
On 28 jul 2008, at 23:42, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Sun, 27 Jul 2008, Tom Werner wrote:
>>
>>> I find it a bit confusing that some here seem to have a strong
>>> dislike
>>> for GitHub. It's true that we haven't been active on the developer
>>> list
>>> or in the #git channel on freenode, but we are constantly in
>>> #github and
>>> have answered a *great* many questions from developers that are
>>> new to
>>> git.
>>
>> Speaking for myself, I will probably direct some users from #git to
>> #github, then.
>
> I saw more than several times that people asked github specific
> questions
> on #git; when they were lucky, there was somebody who knew github
> and they
> got necessary help. Otherwise the answer was "eh, sorry, that's a
> closed
> service and we cannot help diagnosing the problem you are having". It
> would have been the right way to help them to refer to the #github
> support
> channel.
For what it's worth, I regularly redirect people from #git to #github,
so at
least they aren't always left in the dark ;)
- Pieter
^ permalink raw reply
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v63qqv7ex.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> This new action needs to be in a conditional to keep it from removing
>>> the ONLY git executable when bindir and execdir are the same dir.
>> Heh, I love bug reports that come immediately after I tag the tip of
>> 'master' as -rc1.
>
> This should do, but to be very honest, I really hate the output from the
> foreach that precedes this section.
>
> Makefile | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 798a2f2..92df61c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1362,7 +1362,10 @@ endif
> cp "$$bindir/git$X" "$$execdir/git$X"; \
> fi && \
> { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
> - $(RM) "$$execdir/git$X" && \
> + if test "z$$bindir" != "z$$execdir"; \
> + then \
> + $(RM) "$$execdir/git$X"; \
> + fi && \
> ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
>
> install-doc:
>
Tested by: A Large Angry SCM <gitzilla@gmail.com>
^ permalink raw reply
* Showing changes about to be commited via git svn dcommit
From: Lee Marlow @ 2008-07-28 22:54 UTC (permalink / raw)
To: git
git-svners,
I often like to look at the diff of what I'm about to commit before
taking the plunge. I'd really like an easy way to see a 'git log -p'
output of what would be committed to the central svn repository with a
dcommit. I found --dry-run and finally made a "one-liner" that
outputs what I want, but it seems like a lot of work for something I
do quite often. The one-liner I used is:
$> git svn dcommit --dry-run | grep -E '^diff-tree ' | cut -b 11- |
git diff-tree --stdin -p -v
Is this the real way to do it? Do others do something similar?
Curious and looking for a better way.
-Lee
^ permalink raw reply
* Re: git submodules
From: Junio C Hamano @ 2008-07-28 22:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Pierre Habouzit, Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <m3r69dtzm9.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Pierre Habouzit <madcoder@debian.org> writes:
>> On Mon, Jul 28, 2008 at 09:40:22PM +0000, Avery Pennarun wrote:
>
>> > Further, if you don't have a separate .git directory for each
>> > submodule, you can't *switch* branches on the submodule independently
>> > of the supermodule in any obvious way.
>>
>> Yes you can, in what I propose you have a dummy .git in each submodule,
>> with probably an index, a HEAD and a config file (maybe some other
>> things along) to allow that especially.
>
> What you are (re)inventing here is something called gitlink (.git which
> is a file, or .gitlink file); not to be confused with 'sumbodule'/'commit'
> entry in a tree which is sometimes called gitlink....
> ...
> There was even some preliminary implementation IIRC, but AFAIR it
> was abandoned because of no "real usage".
I am afraid you are confused. I think you are talking about "gitfile",
not "gitlink".
It is not abandoned; see e.g. read_gitfile_gently() in setup.c.
I suspect the use of it may help the use case Pierre proposes, but its
main attractiveness as I understood it back when we discussed the facility
was that you could switch branches between 'maint' that did not have a
submodule at "path" back then, and 'master' that does have one now,
without losing the submodule repository. When checking out 'master' (and
that would probably mean you would update 'git-submodule init' and
'git-submodule update' implementation), you would instanciate subdirectory
"path", create "path/.git" that is such a regular file that that points at
somewhere inside the $GIT_DIR of superproject (say ".git/submodules/foo").
By storing refs and object store are all safely away in the superproject
$GIT_DIR, you can now safely switch back to 'maint', which would involve
making sure there is no local change that will be lost and then removing
the "path" and everything underneath it.
^ permalink raw reply
* Re: git-scm.com
From: Martin Langhoff @ 2008-07-28 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Tom Werner, git
In-Reply-To: <7vk5f5ptwu.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 29, 2008 at 9:42 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Active contributers of all kinds, ranging from "C coders", "scripters", to
> "Documentation people" and "dropped patch naggers", have been helping me
> quite a lot. Corporate sponsors that can pay back in money but not in
> patches may be able to find other ways to help us, but I do not offhand
> know what's the most effective way for them to do so if they wanted to.
FWIW - not much probably - anything that pushes towards
"gui-completeness" is a good step.
We have fantastic gui tools that complement the awesome cli UI, and we
have some complete-ish GUIs, but the git-cheetah and Eclipse tracks
are lacking. Work on those is needed - whether money can help I do not
know. However, not many people work on polishing smooth UIs for love
and fun.
cheers,
martin
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: git submodules
From: Avery Pennarun @ 2008-07-28 22:32 UTC (permalink / raw)
To: Pierre Habouzit, Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <20080728220308.GF10409@artemis.madism.org>
On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> > It's unfortunate that submodules involve a commit->tree->commit link
> > structure.
>
> Actually it's not a big problem, you just have to "dereference" twice
> instead of one, and be prepared to the fact that the second dereference
> may fail (because you miss some objects). I instead believe that
> gitlinks are a good idea.
It's actually complicated to generate the log, however. To be 100%
accurate in creating a combined log of the supermodule and submodule,
you'd have to check *for each supermodule commit* whether there were
any changes in gitlinks. And gitlinks might move around between
revisions, so you can't just look up a particular path in each
revision; you have to traverse the entire tree. And you can't just
look at the start and end supermodule commits to see if the gitlinks
changed; they might have changed and then changed back, which is quite
relevant to log messages.
Probably it's more useful to just commit the git-shortlog of the
submodule whenever you update the gitlink. It won't work with bisect,
exactly, but that's less important than generally having an idea of
what happened by reading the log. ISTR somenoe submitted a
git-submodule patch for that already somewhere, but I've been known to
imagine things.
> Well, using the same [branch] as the supermodule is probably the less confusing
> way. Of course, not being in the "same" branch as the supermodule would
> clearly be a case of your tree being "dirty", and it would prevent a
> "git checkout" to work in the very same way that git checkout doesn't
> work if you have locally modified files.
>
> If your submodule branching layout uses the same names as the
> supermodule branches then yes, it's going to hurt, but I believe it to
> be unlikely (else you would become insane just trying to remember what
> you are doing ;p).
I think this is much more common than you think. An easy example is
that I'm developing a new version of my application in the
supermodule's "master", but it relies on a released version of my
submodule, definitely not the experimental "master" version. Using
your logic, the local branch of the submodule would be called master,
but wouldn't correspond at all to the remote submodule's master.
I believe such a situation would be even worse than no branch at all.
It could lead to people pushing/pulling all sorts of bad things from
the wrong places. At least right now, people become confused and ask
for help instead of becoming confused and making a mess.
Have fun,
Avery
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Johannes Schindelin @ 2008-07-28 22:30 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <1217273166.25690.20.camel@maia.lan>
Hi,
On Tue, 29 Jul 2008, Sam Vilain wrote:
> On Mon, 2008-07-28 at 14:01 +0200, Johannes Schindelin wrote:
> > > - the reel has a defined object order (which as I hoped to
> > > demonstrate in the test cases, is just a refinement of rev-list
> > > --date-order)
> >
> > Do you mean that the commit reel is a list pointing to bundles that
> > can be sorted topologically by their contained commits?
>
> Yes, but it is more defined than that. There are still ambiguities with
> topological sort, so the gittorrent spec specified exactly how all ties
> are broken. They happen to be a further refinement of --date-order,
> with respect to the ordering of commits.
But does that not mean that any new ref branching off of an ancient commit
changes all the pack boundaries?
I'd rather have an intelligent incremental updater, and keep most of the
existing bundles immutable. That way, a new ref, or a changed one, can be
mostly served from peers, not exclusively from the seeders.
> > > - deltas always point in one direction, to objects "earlier" on
> > > the reel, so that slices of the reel sent on the network can be
> > > made thin without resulting in unresolvable deltas (which should
> > > be possible to do on commit boundaries using rev-list
> > > --objects-edge)
> >
> > That is exactly what bundles do. They are thin, as they assume that a
> > few "preconditions", i.e. refs, are present.
>
> Ok. I think there are also some other trivial differences such as
> bundles containing refs (which in the context of gittorrent will be
> useless).
Yeah, I think that bundles themselves are pretty useless in gitorrent.
But what they _contain_ is pretty much what you need as blocks.
> > > - the behaviour at the beginning of the reel is precisely defined
> > > (although as I said, I think that the decision might be worth
> > > revisiting - perhaps getting just the latest reel is a useful
> > > 'shallow clone')
> >
> > If you want to allow shallow clones, you must make the bundles
> > non-thin. That would be a major bandwidth penalty.
> >
> > I'd rather not allow shallow clones with Gitorrent.
>
> By "Shallow" I think I mean a different thing to you. I mean something
> akin to just the last pack's worth of commits.
That _is_ a shallow clone. And that is exactly what I meant. If you want
to have all objects of the commits in the same pack, then you are
basically making fat packs. Which come with a hefty bandwidth penalty.
That is why I would suggest not allowing shallow clones; if you want to
allow them, I have to ask myself why bother with a torrent at all... It
is not like the shallow clones are large, or that the people fetching them
will stay around long to seed anything, and the packs would change
frequently, making the whole torrent business pretty inefficient.
> > > It's the lack of guarantees which is the issue, really.
> >
> > It should not be too difficult to provide a rev-list option (which is
> > inherited by git-bundle, then) to pay an extra time to make sure that
> > the bundle is minimal.
>
> Ok. But from the current implementation's perspective, this is not yet
> needed, we are just using the existing API.
Why make it hard? We have a lively community with brilliant people, and
they frequently have fun solving puzzles like this: what is the best
strategy to make equally sized, rarely (or maybe never?) changing packs
from a set of given refs.
> Actually what would be useful would be for the thin pack generation to
> also allow any object to be specified as its input list, not just
> commits... then we wouldn't have to break blocks on commit boundaries
> (see http://gittorrent.utsl.gen.nz/rfc.html#org-blocks).
That should be easy, but I think that it would be _even better_ if we ask
pack-objects to generate several packs from the needed objects. Ooops.
That already exists:
$ git pack-objects --max-pack-size=<n>
Storing the packs in a second GIT_OBJECT_DIRECTORY that has the
original as an alternate, together with the --local flag, should help even
further: You can mark the last pack (which does not reach max-pack-size,
most likely), remove it and just rerun the packing.
Of course, this needs some thought when large chunks of the object
database become stale when a long branch was just deleted. Not a major
obstacle, though.
Ciao,
Dscho
^ permalink raw reply
* Re: git submodules
From: Jakub Narebski @ 2008-07-28 22:26 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <20080728220308.GF10409@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> On Mon, Jul 28, 2008 at 09:40:22PM +0000, Avery Pennarun wrote:
> > Further, if you don't have a separate .git directory for each
> > submodule, you can't *switch* branches on the submodule independently
> > of the supermodule in any obvious way.
>
> Yes you can, in what I propose you have a dummy .git in each submodule,
> with probably an index, a HEAD and a config file (maybe some other
> things along) to allow that especially.
What you are (re)inventing here is something called gitlink (.git which
is a file, or .gitlink file); not to be confused with 'sumbodule'/'commit'
entry in a tree which is sometimes called gitlink. Alternate idea was
'unionfs' like "shadowing" .git, with 'core.gitdir' in .git/config
(which would contain .git/HEAD and .git/index, and all missing files
and config would be taken from `core.gitdir').
There was even some preliminary implementation IIRC, but AFAIR it
was abandoned because of no "real usage".
See
http://permalink.gmane.org/gmane.comp.version-control.msysgit/1868
http://permalink.gmane.org/gmane.comp.version-control.git/72449
http://permalink.gmane.org/gmane.comp.version-control.git/72457
http://permalink.gmane.org/gmane.comp.version-control.git/72296
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 22:03 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nigel Magnay, Git ML
In-Reply-To: <32541b130807281440v64f3cb9ci50cf6d16be4f2f82@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5928 bytes --]
On Mon, Jul 28, 2008 at 09:40:22PM +0000, Avery Pennarun wrote:
> On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> > On Mon, Jul 28, 2008 at 08:55:45PM +0000, Pierre Habouzit wrote:
> > > That too indeed (the "easier to clone" bit). OTOH, I don't like the
> > > .git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
> > > inside of it. With what I propose, you find objects for all your
> > > super/sub-modules in the usual store, which eases many things.
> > > Especially, I believe that when you replace a subdirectory of a project
> > > with a submodule, git-blame could benefit quite a lot from this to be
> > > able to glue history back through the submodule limits, without having
> > > to refactor a _lot_ of code: it would merely have to dereference so
> > > called "gitlinks" to the commit then tree, hence twice, and just do its
> > > usual work, with your proposal, we still rely on having to recurse in
> > > subdirectories which requires more boilerplate code.
> >
> > And of _course_ this is also true for git-log, which is like 10x as
> > important for me (like I don't remember if I used git-blame this year,
> > whereas I used git-log in the last 10 minutes ;p)
>
> I don't think you're going to get away with *not* having a separate
> ..git directory for each submodule. You'll just plain lose almost all
> the features of submodules if you try to do that.
>
> Most importantly in my case, my submodules (libraries shared between
> apps) have a very different branching structure than my supermodules.
> It wouldn't be particularly meaningful to force them to use the same
> branch names.
Why not ? We're talking local branches, that can track whatever you like
on the remote side. Of course, the globing refspec are probably going to
be too simple for you if your branching scheme is _that_ different, but
if you can deal with that by hand _now_, I can't see why writing the
adequate tracking maps by hand would be any harder.
> Further, if you don't have a separate .git directory for each
> submodule, you can't *switch* branches on the submodule independently
> of the supermodule in any obvious way.
Yes you can, in what I propose you have a dummy .git in each submodule,
with probably an index, a HEAD and a config file (maybe some other
things along) to allow that especially.
> This is also useful; I might want to test updating to the latest
> master of my submodule, see if it still works with my supermodule, and
> if so, commit the new gitlink in the supermodule. This is a very
> common workflow for me.
I agree.
> It's unfortunate that submodules involve a commit->tree->commit link
> structure.
Actually it's not a big problem, you just have to "dereference" twice
instead of one, and be prepared to the fact that the second dereference
may fail (because you miss some objects). I instead believe that
gitlinks are a good idea.
> > One irritating problem with submodules, is
> > that when someone else commited, and that you git submodule update,
> > you're on a detached head. Absolutely horrible.
>
> I think that roughly everyone agrees with the above statement by now.
> It would also be trivial to fix it, if only we knew what "fix" means.
> So far, I haven't seen any good suggestions for what branch name to
> use automatically in a submodule, and believe me, I've been looking
> for one :)
Well, using the same as the supermodule is probably the less confusing
way. Of course, not being in the "same" branch as the supermodule would
clearly be a case of your tree being "dirty", and it would prevent a
"git checkout" to work in the very same way that git checkout doesn't
work if you have locally modified files.
If your submodule branching layout uses the same names as the
supermodule branches then yes, it's going to hurt, but I believe it to
be unlikely (else you would become insane just trying to remember what
you are doing ;p). So even if say your work in `master` in your
supermodule, but for some reason use what is on the remote
`release/10.2` branch for a given submodule, nothing prevents you to
have a local `master` branch in that submodule as well that tracks
`release/10.2`. It's actually a quite sensible thing to do I believe.
It doesn't prevent you from switching your submodule to the `devel`
branch to perform some tests, or even make it the new state of the
submodule inside your supermodule. This operation would just then move
what is `master` in your submodule to track `devel` instead of
`release/10.2`[0].
I fail to see which current submodules features you would lose with this
scheme. In fact, said differently, I more or less propose that when you
commit your supermodule state (providing some checks hold see [0]) it
updates the 'associated' branch in the submodule. The goal here, is that
you're always on a branch, set up to track a given remote branch, that
we can check against so that we can:
(1) avoid the usual caveats of git-submodules (one can check when
pushing the supermodule that all submodules are indeed pushed in
the remote branch they track);
(2) user can commit and don't bother resetting branches and doing
tricks to be "on branch again".
I don't think it prevents you from e.g. having topic branches in your
submodules, provided that before commiting a new submodule change, you
somehow merge those in the "matching" branch that was set up for you.
[0] of course we probably want to refuse such a thing if `devel` isn't
a fast-forward from release/10.2. But that's not the point of the
explanation so I skipped this bit for clarity of my point.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-28 21:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tom Werner, git
In-Reply-To: <alpine.DEB.1.00.0807281201350.2725@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 27 Jul 2008, Tom Werner wrote:
>
>> I find it a bit confusing that some here seem to have a strong dislike
>> for GitHub. It's true that we haven't been active on the developer list
>> or in the #git channel on freenode, but we are constantly in #github and
>> have answered a *great* many questions from developers that are new to
>> git.
>
> Speaking for myself, I will probably direct some users from #git to
> #github, then.
I saw more than several times that people asked github specific questions
on #git; when they were lucky, there was somebody who knew github and they
got necessary help. Otherwise the answer was "eh, sorry, that's a closed
service and we cannot help diagnosing the problem you are having". It
would have been the right way to help them to refer to the #github support
channel.
If a company can fund somebody to help new users with git problems on #git
while helping people with github problems on #github, that would be a good
gesture towards the git community, I'd suppose.
> Also note that one of the major gripe with you making money off of Git
> could be the following: we have over 500 contributors, and most of them --
> first and foremost of all, the two major contributors, Junio and Shawn --
> cannot make money from Git. Envy is wrong, but it is real.
I do not talk for Shawn, but I think that comment misses the mark by a
large margin, at least for me.
I haven't been in this for money. The original motivation of my
involvement was to help sending Linus back to the kernel as quickly as
possible, but now I primarily do this for fun. Doing it for money would
risk removing the fun factor.
What I personally lack right now is time and mental bandwidth.
Active contributers of all kinds, ranging from "C coders", "scripters", to
"Documentation people" and "dropped patch naggers", have been helping me
quite a lot. Corporate sponsors that can pay back in money but not in
patches may be able to find other ways to help us, but I do not offhand
know what's the most effective way for them to do so if they wanted to.
^ permalink raw reply
* Re: git submodules
From: Avery Pennarun @ 2008-07-28 21:40 UTC (permalink / raw)
To: Pierre Habouzit, Nigel Magnay, Git ML
In-Reply-To: <20080728205923.GC10409@artemis.madism.org>
On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> On Mon, Jul 28, 2008 at 08:55:45PM +0000, Pierre Habouzit wrote:
> > That too indeed (the "easier to clone" bit). OTOH, I don't like the
> > .git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
> > inside of it. With what I propose, you find objects for all your
> > super/sub-modules in the usual store, which eases many things.
> > Especially, I believe that when you replace a subdirectory of a project
> > with a submodule, git-blame could benefit quite a lot from this to be
> > able to glue history back through the submodule limits, without having
> > to refactor a _lot_ of code: it would merely have to dereference so
> > called "gitlinks" to the commit then tree, hence twice, and just do its
> > usual work, with your proposal, we still rely on having to recurse in
> > subdirectories which requires more boilerplate code.
>
> And of _course_ this is also true for git-log, which is like 10x as
> important for me (like I don't remember if I used git-blame this year,
> whereas I used git-log in the last 10 minutes ;p)
I don't think you're going to get away with *not* having a separate
.git directory for each submodule. You'll just plain lose almost all
the features of submodules if you try to do that.
Most importantly in my case, my submodules (libraries shared between
apps) have a very different branching structure than my supermodules.
It wouldn't be particularly meaningful to force them to use the same
branch names.
Further, if you don't have a separate .git directory for each
submodule, you can't *switch* branches on the submodule independently
of the supermodule in any obvious way. This is also useful; I might
want to test updating to the latest master of my submodule, see if it
still works with my supermodule, and if so, commit the new gitlink in
the supermodule. This is a very common workflow for me.
On the other hand, your thought about combining the "git log" messages
is quite interesting. That *is* something I'd benefit from, along
with being able to git-bisect across submodules. If I'm in the
supermodule, I want to see *all* the commits that might have changed
in my application, not just the ones in the supermodule itself. I
suspect this isn't simple at all to implement, however, as you'd have
to look inside the file tree of a given commit in order to find
whether any submodule links have changed in that commit. It's
unfortunate that submodules involve a commit->tree->commit link
structure.
> One irritating problem with submodules, is
> that when someone else commited, and that you git submodule update,
> you're on a detached head. Absolutely horrible.
I think that roughly everyone agrees with the above statement by now.
It would also be trivial to fix it, if only we knew what "fix" means.
So far, I haven't seen any good suggestions for what branch name to
use automatically in a submodule, and believe me, I've been looking
for one :)
Have fun,
Avery
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 21:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vr69dpu9i.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 23:35, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> The quoted sentence by me in that message was after I explained why "per
>> hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
>> say "by the way, '-s theirs' is even worse and here is why".
Aaah, ok, now I see where my confusion came from. Thank you for
clarifying that. Then remains the question, what to tell those that
want '-s theirs' not to keep track of their changes, but to keep a
fast-forwardable master?
> Heh, I ended up doing the "digging" myself. The quote came from this:
>
> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89024
>
> and "tried not to sound too negative" there refers to:
>
> http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021
>
> which _was_ about the "-Xtheirs", not "-s theirs".
Understood, it makes sense now.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 21:35 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Jeff King, Git Mailinglist,
Miklos Vajna
In-Reply-To: <7vvdyppv4c.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>
>> On Mon, Jul 28, 2008 at 22:20, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Sverre Rabbelier" <alturin@gmail.com> writes:
>>>> Mhhh, but the proposed strategy there was in response to the 'insane'
>>>> git-merge-theirs version, not to the 'exact opposite of
>>>> git-merge-ours' that I refer to now, yes?
>>>
>>> No.
>>
>> Nanako Shiraishi's patch was not in response to the "git-merge-theirs"
>> thread, or I am missing something here....?
>
> The quoted sentence by me in that message was after I explained why "per
> hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
> say "by the way, '-s theirs' is even worse and here is why".
Heh, I ended up doing the "digging" myself. The quote came from this:
http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89024
and "tried not to sound too negative" there refers to:
http://thread.gmane.org/gmane.comp.version-control.git/89010/focus=89021
which _was_ about the "-Xtheirs", not "-s theirs".
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 21:16 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Jeff King, Git Mailinglist,
Miklos Vajna
In-Reply-To: <bd6139dc0807281324k38198fffwd3b586394b354ed2@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Mon, Jul 28, 2008 at 22:20, Junio C Hamano <gitster@pobox.com> wrote:
>> "Sverre Rabbelier" <alturin@gmail.com> writes:
>>> Mhhh, but the proposed strategy there was in response to the 'insane'
>>> git-merge-theirs version, not to the 'exact opposite of
>>> git-merge-ours' that I refer to now, yes?
>>
>> No.
>
> Nanako Shiraishi's patch was not in response to the "git-merge-theirs"
> thread, or I am missing something here....?
The quoted sentence by me in that message was after I explained why "per
hunk theirs" aka "-Xtheirs" was not such a great idea I further went on to
say "by the way, '-s theirs' is even worse and here is why".
^ permalink raw reply
* [ANN] ditz 0.4 released
From: William Morgan @ 2008-07-28 20:26 UTC (permalink / raw)
To: Git Mailing List
Ditz version 0.4 has been released! This release features improved git
integration.
http://ditz.rubyforge.org
Ditz is a simple, light-weight distributed issue tracker designed to work with
distributed version control systems like git, darcs, Mercurial, and Bazaar. It
can also be used with centralized systems like SVN.
Ditz maintains an issue database directory on disk, with files written in a
line-based and human-editable format. This directory can be kept under version
control, alongside project code.
Ditz provides a simple, console-based interface for creating and updating the
issue database file, and some rudimentary HTML generation capabilities for
producing world-readable status pages. It currently offers no central public
method of bug submission.
Synopsis:
# set up project. creates the bugs.yaml file.
1. ditz init
2. ditz add-release
# add an issue
3. ditz add
# where am i?
4. ditz status
5. ditz todo (or simply "ditz")
# do work
6. write code
7. ditz close <issue-id>
8. commit
9. goto 3
# finished!
10. ditz release <release-name>
Changes:
## 0.4 / 2008-07-27
* bugfix: HOME environment variable now correctly detected on windows
* hooks loaded from both home directory and project directory
* added bash shell completion
* plugin architecture for tighter SCM integration, etc
* 'ditz grep' should also grep against comments, log messages, etc
* added man page
* removed ditz-convert-from-monolith
* lots of HTML output tweaking
--
William <wmorgan-git@masanjin.net>
^ 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