* [PATCH] When re-initializing, set shared permissions on all directories.
From: Jon Jensen @ 2007-11-21 3:48 UTC (permalink / raw)
To: git
Hi.
Below is a small patch to make git-init --shared change permissions not
just of .git/refs/ but of the other directories too.
Also a documentation patch for git-init, though after reading discussion
in the list archives from a few weeks ago, I realize people may not be
interested in documentation that shows explicit UNIX commands that may not
apply or could be considered pedantic. Let me know if there's a better way
I can approach this.
Thanks,
Jon
--
From b2895649165d7e6c4bcbe6484d66c84ea7124bd9 Mon Sep 17 00:00:00 2001
From: Jon Jensen <jon@endpoint.com>
Date: Tue, 20 Nov 2007 20:01:14 -0700
Subject: [PATCH] When re-initializing, set shared permissions on all directories.
Before this patch, when re-initializing an existing repository e.g.
as --shared=group, only .git/refs/ was set chmod g+ws. Now the
other directories get that too.
This is probably only helpful when not much has been done with the
repository yet, since it doesn't include subdirectories and files,
so add an example to the documentation to point the way for people
to finish the job.
---
Documentation/git-init.txt | 13 +++++++++++++
builtin-init-db.c | 8 +++++++-
2 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 07484a4..c4a4757 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -101,6 +101,19 @@ $ git-add . <2>
<2> add all existing file to the index
+Adjust an existing git repository to work as if it had been created with git init --shared::
++
+----------------
+$ GIT_DIR=/path/to/my/.git git-init --shared <1>
+$ chgrp -R mygroup /path/to/my/.git <2>
+$ find /path/to/my/.git -type d -exec chmod g+ws {} \; <3>
+----------------
++
+<1> adjust configuration for shared repository
+<2> correct group ownership of any existing directories and files; needed if group shared by users is different than the group ownership of repository files
+<3> make all directories set group ownership of newly created files correctly in the future
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 763fa55..d16efa5 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -24,7 +24,13 @@ static void safe_create_dir(const char *dir, int share)
exit(1);
}
}
- else if (share && adjust_shared_perm(dir))
+
+ /*
+ * If the directory already existed, we may still need
+ * to adjust permissions if this is a reinitialization
+ * for a shared repository.
+ */
+ if (share && adjust_shared_perm(dir))
die("Could not make %s writable by group\n", dir);
}
--
1.5.3.6.737.gb2895
^ permalink raw reply related
* Re: [PATCH] autoconf: Add tests for memmem, strtoumax and mkdtemp functions
From: Matt Kraai @ 2007-11-21 0:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vd4u5l29v.fsf@gitster.siamese.dyndns.org>
On Tue, Nov 20, 2007 at 01:00:44AM -0800, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > * Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
> > that tells runtime paths to dynamic libraries;
> > "-Wl,-rpath=/path/lib" is used instead.
>
> Try with -R/path/lib and see if it complains, perhaps?
>
> 206488774238c94ff337dd5c997be441dbde5112 (Correct the name of
> NO_R_TO_GCC_LINKER in the comment describing it.)
I don't know how to test this, unfortunately. I'll be happy to test
any tests you'd like me to try, though.
> > MakeMaker (e.g. using ActiveState under Cygwin).
>
> f848718a6980ebda0eb5afb2ca49c3bc1e7b2b1d (Make perl/ build
> procedure ActiveState friendly.)
>
> Alex CC'ed.
>
> > * Define ASCIIDOC8 if you want to format documentation with AsciiDoc 8
>
> case "$(asciidoc --version)" in
> asciidoc' '7*) : not def ;;
> asciidoc' '8) : def ;;
> esac
>
> > * Define DOCBOOK_XSL_172 if you want to format man pages with DocBook XSL v1.72.
> >
> > - it needs some portable way to check asciidoc and docbook-xsl version
>
> Hmmm.
>
> > * Define OLD_ICONV if your library has an old iconv(), where the second
> > (input buffer pointer) parameter is declared with type (const char **).
> >
> > - perhaps compile with new iconv and check for compile errors?
>
> Yeah, with appropriate includes,
>
> char *ibp, *obp;
> size_t insz, outsz;
> iconv(conv, &ibp, &insz, &obp, &outsz);
>
> would cause compilation trouble if iconv() wants "const char *"
> for ibp.
--
Matt
^ permalink raw reply
* Re: t9106 failure, bisect weirdness
From: Christian Couder @ 2007-11-21 4:08 UTC (permalink / raw)
To: carbonated beverage; +Cc: git, Eric Wong
In-Reply-To: <20071120061314.GA21819@net-ronin.org>
Le mardi 20 novembre 2007, carbonated beverage a écrit :
> > Could you try running the test twice when you bisect ?
> > This way bisecting should give you the real first bad commit.
>
> I re-ran it several times, and also manually -- there were times it'd
> succeed 6 times in a row before failing. Weird.
>
> Finally, the bisect came down to:
>
> ramune/lycaeum:git: git bisect good
> c74d9acf20ba0c69bbd67c5b0bb3bd3c2349cebe is first bad commit
> commit c74d9acf20ba0c69bbd67c5b0bb3bd3c2349cebe
> Author: Eric Wong <normalperson@yhbt.net>
> Date: Mon Nov 5 03:21:47 2007 -0800
>
> git-svn: fix dcommit clobbering when committing a series of diffs
Thanks for having done that. Unfortunately I don't know this part of the
code, so I cc'ed Eric.
> Modifying the failing t9106-git-svn-dcommit-clobber-series.sh test to
> add touch statements as so:
>
> test x\"\`sed -n -e 4p < file\`\" = x4444 && touch '/tmp/eleven' &&
> test x\"\`sed -n -e 7p < file\`\" = x7777 && touch '/tmp/twelve' &&
> test x\"\`sed -n -e 58p < file\`\" = x5588 && touch '/tmp/thirteen' &&
> test x\"\`sed -n -e 61p < file\`\" = x6611
>
> Line 52 was the culprit:
>
> test x\"\`sed -n -e 58p < file\`\" = x5588 &&
Ok thanks for doing that too.
Could you also look at the "file" when the test succeed and when it does not
and send us both versions and a diff between them (if it's not too big).
Thanks in advance,
Christian.
^ permalink raw reply
* [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-21 3:40 UTC (permalink / raw)
To: git
[WIP: this does not handle tags yet, and it lacks a test script
as well as documentation.]
This program dumps (parts of) a git repository in the format that
fast-import understands.
For clarity's sake, it does not use the 'inline' method of specifying
blobs in the commits, but builds the blobs before building the commits.B
---
I am way too tired now to continue, but maybe someone else wants
to pick up the ball.
Oh, and it relies on "int" being castable to void * and vice
versa. Is anybody aware of a platform where this can lead to
problems?
And yes, I will add a copyright when I woke up again.
.gitignore | 1 +
Makefile | 1 +
builtin-fast-export.c | 202 +++++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
5 files changed, 206 insertions(+), 0 deletions(-)
create mode 100755 builtin-fast-export.c
diff --git a/.gitignore b/.gitignore
index 507e351..ef69e2f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,7 @@ git-diff-files
git-diff-index
git-diff-tree
git-describe
+git-fast-export
git-fast-import
git-fetch
git-fetch--tool
diff --git a/Makefile b/Makefile
index dd3ba6f..8784eff 100644
--- a/Makefile
+++ b/Makefile
@@ -336,6 +336,7 @@ BUILTIN_OBJS = \
builtin-diff-files.o \
builtin-diff-index.o \
builtin-diff-tree.o \
+ builtin-fast-export.o \
builtin-fetch.o \
builtin-fetch-pack.o \
builtin-fetch--tool.o \
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
new file mode 100755
index 0000000..2e8e3dd
--- /dev/null
+++ b/builtin-fast-export.c
@@ -0,0 +1,202 @@
+#include "builtin.h"
+#include "cache.h"
+#include "commit.h"
+#include "object.h"
+#include "tag.h"
+#include "diff.h"
+#include "diffcore.h"
+#include "log-tree.h"
+#include "revision.h"
+#include "decorate.h"
+#include "path-list.h"
+
+static struct decoration idnums;
+static uint32_t last_idnum;
+
+static const char *fast_export_usage = "git-fast-export [rev-list-opts]";
+
+static int has_unshown_parent(struct commit *commit)
+{
+ struct commit_list *parent;
+
+ for (parent = commit->parents; parent; parent = parent->next)
+ if (!(parent->item->object.flags & SHOWN))
+ return 1;
+ return 0;
+}
+
+static void handle_object(const unsigned char *sha1)
+{
+ unsigned long size;
+ enum object_type type;
+ char *buf;
+ struct object *object;
+
+ if (is_null_sha1(sha1))
+ return;
+
+ object = parse_object(sha1);
+ if (!object)
+ die ("Could not read blob %s", sha1_to_hex(sha1));
+
+ if (object->flags & SHOWN)
+ return;
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ die ("Could not read blob %s", sha1_to_hex(sha1));
+
+ last_idnum++;
+ add_decoration(&idnums, object, (void *)last_idnum);
+
+ printf("blob\nmark :%d\ndata %lu\n", last_idnum, size);
+ if (fwrite(buf, size, 1, stdout) != 1)
+ die ("Could not write blob %s", sha1_to_hex(sha1));
+ printf("\n");
+
+ object->flags |= SHOWN;
+ free(buf);
+}
+
+static void show_filemodify(struct diff_queue_struct *q,
+ struct diff_options *options, void *data)
+{
+ int i;
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filespec *spec = q->queue[i]->two;
+ if (is_null_sha1(spec->sha1))
+ printf("D %s\n", spec->path);
+ else {
+ struct object *object = lookup_object(spec->sha1);
+ printf("M 0%06o :%d %s\n", spec->mode,
+ (int)lookup_decoration(&idnums, object),
+ spec->path);
+ }
+ }
+}
+
+static void handle_commit(struct commit *commit, struct rev_info *rev)
+{
+ const char *author, *author_end, *committer, *committer_end, *message;
+ int saved_output_format = rev->diffopt.output_format;
+ int i;
+
+ rev->diffopt.output_format = DIFF_FORMAT_CALLBACK;
+
+ parse_commit(commit);
+ author = strstr(commit->buffer, "\nauthor ");
+ if (!author)
+ die ("Could not find author in commit %s",
+ sha1_to_hex(commit->object.sha1));
+ author++;
+ author_end = strchrnul(author, '\n');
+ committer = strstr(author_end, "\ncommitter ");
+ if (!committer)
+ die ("Could not find committer in commit %s",
+ sha1_to_hex(commit->object.sha1));
+ committer++;
+ committer_end = strchrnul(committer, '\n');
+ message = strstr(committer_end, "\n\n");
+ if (message)
+ message += 2;
+
+ if (commit->parents) {
+ parse_commit(commit->parents->item);
+ diff_tree_sha1(commit->parents->item->tree->object.sha1,
+ commit->tree->object.sha1, "", &rev->diffopt);
+ }
+ else
+ diff_root_tree_sha1(commit->tree->object.sha1,
+ "", &rev->diffopt);
+
+ for (i = 0; i < diff_queued_diff.nr; i++)
+ handle_object(diff_queued_diff.queue[i]->two->sha1);
+
+ last_idnum++;
+ add_decoration(&idnums, &commit->object, (void *)last_idnum);
+ printf("commit %s\nmark :%d\n%.*s\n%.*s\ndata %u\n%s",
+ (const char *)commit->util, last_idnum,
+ author_end - author, author,
+ committer_end - committer, committer,
+ message ? strlen(message) : 0, message ? message : "");
+
+ log_tree_diff_flush(rev);
+ rev->diffopt.output_format = saved_output_format;
+
+ printf("\n");
+}
+
+static void handle_tail(struct object_array *commits, struct rev_info *revs)
+{
+ struct commit *commit;
+ while (commits->nr) {
+ commit = (struct commit *)commits->objects[commits->nr - 1].item;
+ if (has_unshown_parent(commit))
+ return;
+ handle_commit(commit, revs);
+ commits->nr--;
+ }
+}
+
+int cmd_fast_export(int argc, const char **argv, const char *prefix)
+{
+ struct rev_info revs;
+ struct object_array commits = { 0, 0, NULL };
+ struct path_list extra_refs = { NULL, 0, 0, 0 };
+ struct commit *commit;
+ int i;
+
+ init_revisions(&revs, prefix);
+ argc = setup_revisions(argc, argv, &revs, NULL);
+ if (argc > 1)
+ usage (fast_export_usage);
+
+ for (i = 0; i < revs.pending.nr; i++) {
+ struct object_array_entry *e = revs.pending.objects + i;
+ unsigned char sha1[20];
+ char *full_name;
+
+ /* TODO: handle tags */
+ commit = (struct commit *)e->item;
+ if (dwim_ref(e->name, strlen(e->name), sha1, &full_name) != 1)
+ die ("Could not get a unique ref name for '%s'",
+ e->name);
+ if (commit->util)
+ /* more than one name for the same object */
+ path_list_insert(full_name, &extra_refs)->util = commit;
+ else
+ commit->util = full_name;
+ }
+
+ prepare_revision_walk(&revs);
+ revs.diffopt.format_callback = show_filemodify;
+ revs.diffopt.recursive = 1;
+ while ((commit = get_revision(&revs))) {
+ if (has_unshown_parent(commit)) {
+ struct commit_list *parent = commit->parents;
+ add_object_array(&commit->object, NULL, &commits);
+ for (; parent; parent = parent->next)
+ if (!parent->item->util)
+ parent->item->util = commit->util;
+ }
+ else {
+ handle_commit(commit, &revs);
+ handle_tail(&commits, &revs);
+ }
+ }
+
+ if (commits.nr)
+ die ("This should not happen: there were %d commits left!",
+ commits.nr);
+
+ for (i = 0; i < extra_refs.nr; i++) {
+ /* create refs pointing to already seen commits */
+ commit = extra_refs.items[i].util;
+ printf("reset %s\nfrom :%d\n\n",
+ extra_refs.items[i].path,
+ (int)lookup_decoration(&idnums,
+ &commit->object));
+ }
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index e76f5da..5723f9e 100644
--- a/builtin.h
+++ b/builtin.h
@@ -31,6 +31,7 @@ extern int cmd_diff_files(int argc, const char **argv, const char *prefix);
extern int cmd_diff_index(int argc, const char **argv, const char *prefix);
extern int cmd_diff(int argc, const char **argv, const char *prefix);
extern int cmd_diff_tree(int argc, const char **argv, const char *prefix);
+extern int cmd_fast_export(int argc, const char **argv, const char *prefix);
extern int cmd_fetch(int argc, const char **argv, const char *prefix);
extern int cmd_fetch_pack(int argc, const char **argv, const char *prefix);
extern int cmd_fetch__tool(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 0b6825e..deda6dd 100644
--- a/git.c
+++ b/git.c
@@ -301,6 +301,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "diff-files", cmd_diff_files },
{ "diff-index", cmd_diff_index, RUN_SETUP },
{ "diff-tree", cmd_diff_tree, RUN_SETUP },
+ { "fast-export", cmd_fast_export, RUN_SETUP },
{ "fetch", cmd_fetch, RUN_SETUP },
{ "fetch-pack", cmd_fetch_pack, RUN_SETUP },
{ "fetch--tool", cmd_fetch__tool, RUN_SETUP },
--
1.5.3.5.1751.gf6fb4
^ permalink raw reply related
* Re: gitweb: kernel versions in the history (feature request, probably)
From: J. Bruce Fields @ 2007-11-21 3:20 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Petr Baudis, linux-kernel, git
In-Reply-To: <47436E0F.6080003@o2.pl>
On Wed, Nov 21, 2007 at 12:30:23AM +0100, Jarek Poplawski wrote:
> I don't know git, but it seems, at least if done for web only, this
> shouldn't be so 'heavy'. It could be a 'simple' translation of commit
> date by querying a small database with kernel versions & dates.
If I create a commit in my linux working repo today, but Linus doesn't
merge it into his repository until after he releases 2.6.24, then my
commit will be created with an earlier date than 2.6.24, even though it
isn't included until 2.6.25.
So you have to actually examine the history graph to figure this out
this sort of thing.
--b.
^ permalink raw reply
* [PATCH] git-p4: Fix typo in --detect-labels
From: Shun Kei Leung @ 2007-11-21 3:01 UTC (permalink / raw)
To: Git ML; +Cc: Junio C Hamano, shausman
Signed-off-by: Kevin Leung <kevinlsk@gmail.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 65c57ac..66b79b6 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1026,7 +1026,7 @@ class P4Sync(Command):
l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
if len(l) > 0 and not self.silent:
- print "Finding files belonging to labels in %s" % `self.depotPath`
+ print "Finding files belonging to labels in %s" % `self.depotPaths`
for output in l:
label = output["label"]
--
1.5.3.6.5.g154c7
^ permalink raw reply related
* Re: [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Ping Yin @ 2007-11-21 2:38 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <474308A5.8070301@viscovery.net>
On Nov 21, 2007 12:17 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Ping Yin schrieb:
> > This patch disables the auto closing behavious of start_command
> > and corrects all codes which depend on this kind of behaviour.
>
> I've thought about this a bit more, and I think that it is better to leave
> this auto-closing behavior unchanged and change your usage of this feature,
> like so:
>
> > +static void wt_status_print_submodule_summary(struct wt_status *s)
> > +{
> > + struct child_process sm_summary;
> > + memset(&sm_summary, 0, sizeof(sm_summary));
> > + ...
> > + sm_summary.out = fileno(s->fp);
>
> fflush(s->fp);
> sm_summary.out = dup(fileno(s->fp)); /* run_command closes it */
>
> > + ...
> > + run_command(&sm_summary);
> > +}
>
> This way the change is more local without affecting well-tested other callers.
>
This way works, but it is a tricky one, not a natural or graceful one.
> Furthermore, I don't think that it's correct to just set the .close_in or
> .close_out flags. This will close the fd only in finish_command(), which can
> be too late: Think again of a writable pipe end that remains open and keeps
> the reader waiting for input that is not going to happen.
This may happen. However, i have scanned all the git codes using the
auto closing behaviour and i don't discover the problem you mentioned.
So i think it deserves to correct the misbehaviour after carefully
testing. And we can make a clarification for that if necessary.
>
> -- Hannes
>
>
--
Ping Yin
^ permalink raw reply
* Re: quilt/0.46-1 misbehaviour...
From: Junio C Hamano @ 2007-11-21 0:06 UTC (permalink / raw)
To: Matti Aarnio; +Cc: Alex Riesen, git
In-Reply-To: <20071120235458.GT6372@mea-ext.zmailer.org>
Matti Aarnio <matti.aarnio@zmailer.org> writes:
> On Tue, Nov 20, 2007 at 07:34:02PM +0100, Alex Riesen wrote:
> ...
>> Is this the problem: duplicate From: and quadriplicate Cc:?
>
> That kind of header multiples are are triggering spam filters
> all over the place, because spammers used to use such tricks
> as recently as 2 years ago.
>
> Duplicate "From:" is plain simply broken, multiple "Cc:" is
> just questionable..
My condolences.
> git-tools should not produce such.
I have one fundamental question.
What help can git people offer to help you resolve this issue?
What does a message that says:
Message-Id: <20071120011333.850453474@sgi.com>
References: <20071120011132.143632442@sgi.com>
User-Agent: quilt/0.46-1
Date: Mon, 19 Nov 2007 17:11:41 -0800
(a part from your original message that Alex did not quote)
have to do with anything with the git mailing list?
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Jakub Narebski @ 2007-11-21 0:04 UTC (permalink / raw)
To: git
In-Reply-To: <20071120181932.GA20705@pvv.org>
Finn Arne Gangstad wrote:
> I'll try to boil this down to the simplest case possible. If
> submodules can do this I'll be really happy :)
>
> Developer A makes a change in submodule1 and in submodule2
> Developer B makes a change in submodule2 and in submodule3
And committed changes to submodules and supermodule, I guess,
so developer A has submodule1 in state 1a, submodule2 in state 2a.
sumbodule3 in state 3, and supermodule in state [1a, 2a, 3], while
developer B has submodule1 in state 1, submodule2 in state 2b,
submodule3 in state 3b, and supermodule in state [1, 2b, 3b].
> A and B don't know about eachother. They send their modifications
> somewhere (push to a shared repository with a well chosen branch name,
> for example), or send a mail "please pull from my repo" to the patch
> queue manager.
>
> It is absolutely crucial that for each developer, either both their
> modifications go in, or none of them. Git should make picking only
> one of their modifications hard.
Git treats submodules as whole, so merging A and B supermodules will result
in [1a, CONFLICT(2a/2b), 3b]. 2a/2b _might_ resolve cleanly to 2ab,
but this requires submodule2 to be checked out. I'm not sure what git does
in such case, but it is not much different from the case when both sides A
and B modified the same file, but it merges on file-level cleanly; here we
have subprojects and tree-level in-subproject clean merge.
[...]
By the way, submodules in supermodule should be thought as on
'detached HEAD'.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jakub Narebski @ 2007-11-20 23:57 UTC (permalink / raw)
To: git
In-Reply-To: <3057F6F3-BEAA-447A-AB79-A0AFB7DB8826@lrde.epita.fr>
Benoit Sigoure wrote:
> On Nov 19, 2007, at 5:14 PM, Jonas Juselius wrote:
>> On Mon, 2007-11-19 at 17:05 +0100, Jakub Narebski wrote:
>>> Do I understand correctly that you don't support cloning via git://
>>> protocol?
>>
>> Yes, that is correct. The machine is behind a number of firewalls,
>> and I simply cannot be bothered to go through the bureaucracy...
>
> You can create a repository on repo.or.cz then :)
Which can then function as a mirror.
> One of the things you said in your guide is that Git is easy to
> learn. I think this is wrong. Git is way more complicated than most
> other SCMs, especially compared to SVN. Its documentation is far
> behind, compared to what other SCMs have. There is no real user
> guide
What about "Git User's Manual"?
> and the man pages are incomplete, at best. I know saying this
> is a bit harsh, especially to the people out there that are working
> and sending patches to improve the documentation, but I think we have
> to admit that it's true, even though Git is making progress on this
> aspect.
That's sadly true, and confirmed (somewhat) by the fact that both in 2006
user's survey and in 2007 survey (see Git Wiki for summaries) one of more
common requests are for "better documentation" and "The Git Book" (showing
svnbook and hgbook as examples).
[cut]
I think that writing proper "Git Guide" aka "The Git Book" is hard because
of some things:
1. Git has many useful advanced features. Describing those advanced
features is not easy. For example git uses multiple branches in single
repository paradigm freely, which makes learning curve a bit steeper;
IIRC hgbook describes one branch per repos situation (at least at
beginning), which is easier.
2. Git has some historical cruft, including the fact that it began as
series of low level tools (plumbing) and became proper SCM (acquired
proper porcelain) later, what can be even now seen in documentation...
3. Explanation of some features (like object model) would be much easier
with some graphics (diagrams etc.), but chosen documentation format,
AsciiDoc, doesn't make it easy...
Yust my 2 eurocents.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: quilt/0.46-1 misbehaviour...
From: Matti Aarnio @ 2007-11-20 23:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: Matti Aarnio, git
In-Reply-To: <20071120183402.GC3461@steel.home>
On Tue, Nov 20, 2007 at 07:34:02PM +0100, Alex Riesen wrote:
> Matti Aarnio, Tue, Nov 20, 2007 06:51:49 +0100:
> > .. or perhaps Exim, but odd result in arriving and thus outgoing headers anyway.
> >
> ...
> > Diagnostic-Code: smtp; 554 (Reject, id=10432-16 - BAD_HEADER: Duplicate header field: "From")
> >
> > From: clameter@sgi.com
> > From: Christoph Lameter <clameter@sgi.com>
> > To: ak@suse.de
> > Cc: akpm@linux-foundation.org
> > Cc: travis@sgi.com
> > Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> > Cc: linux-kernel@vger.kernel.org
> ...
> > Remote-MTA: dns; cartero.cs.tu-berlin.de (130.149.17.20|25|209.132.176.167|39031)
> > Last-Attempt-Date: Mon, 19 Nov 2007 20:17:31 -0500
> > Diagnostic-Code: smtp; 554 (Reject, id=10432-16 - BAD_HEADER: Duplicate header field: "From")
> ...
> > Date: Mon, 19 Nov 2007 17:11:41 -0800
> > Subject: [rfc 09/45] cpu alloc: IA64 support
> > From: clameter@sgi.com
> > From: Christoph Lameter <clameter@sgi.com>
> > Message-Id: <20071120011333.850453474@sgi.com>
>
> Is this the problem: duplicate From: and quadriplicate Cc:?
That kind of header multiples are are triggering spam filters all over the place,
because spammers used to use such tricks as recently as 2 years ago.
Duplicate "From:" is plain simply broken, multiple "Cc:" is just questionable..
git-tools should not produce such.
/Matti Aarnio
^ permalink raw reply
* Re: gitweb: kernel versions in the history (feature request, probably)
From: Jarek Poplawski @ 2007-11-20 23:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: linux-kernel, git
In-Reply-To: <20071120215904.GF1001@machine.or.cz>
Petr Baudis wrote, On 11/20/2007 10:59 PM:
> Hi,
>
> On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
>> I see gitweb is much more usable (faster) than a few months ago, but
>> there is one thing a bit problematic: in the history of patches I'm
>> very often interested in which kernel version of Linus' tree the patch
>> appeared for the first time. If it's not some big problem, and maybe
>> somebody else finds this useful too, I'd really appreciate adding such
>> a feature.
>
> in git terms, you'd like gitweb to provide output for command:
>
> git describe --contains
>
> This is interesting feature request. I guess the support would be nice,
> though in theory this operation can be a bit resource-intensive in case
> there is not many tags and a lot of development (with uncached
> repository, this query took quite a bit of time on my copy of the kernel
> git tree). Probably this should be an optional feature and somehow dwell
> on a separate page, which doesn't fit too well in the current gitweb
> page structure...
I don't know git, but it seems, at least if done for web only, this
shouldn't be so 'heavy'. It could be a 'simple' translation of commit
date by querying a small database with kernel versions & dates. And it
would suffice if it were shown on the commit page only. But, of course,
it's not urgent at all! (And alas I'm no webmaster, so I can miss
something.)
>> Petr, I hope there is no necessity to subscribe to the git list for
>> this one question, so I'd really feel greteful for forwarding, if you
>> find this request reasonable.
>
> Yes, there is no necessity - you can post this on the git mailing list
> without subscribing yourself.
Great! I misunderstood the page message. Btw., I know it's not the kernel,
but IMHO there should be some place for it in the MAINTAINERS!
Thanks,
Jarek P.
^ permalink raw reply
* RE: git-daemon
From: Medve Emilian @ 2007-11-20 22:04 UTC (permalink / raw)
To: git
In-Reply-To: <20071120182606.GA9646@sigill.intra.peff.net>
Hi Jeff,
I think I found the explanation why v1.5.3.6 works for me (and others
apparently) but master and next don't. The fairly recent changes to the
PATH handling in exec_cmd.c done by Scott R Parish <srp@srparish.net>, I
believe, didn't make it into maint. Adjusting the PATH git-daemon sees
is fixing my problem even in master and next.
Thanks for your help and time.
Cheers,
Emil.
> -----Original Message-----
> From: Jeff King [mailto:peff@peff.net]
> Sent: Tuesday, November 20, 2007 12:26 PM
> To: Medve Emilian
> Cc: git@vger.kernel.org
> Subject: Re: git-daemon
>
> On Tue, Nov 20, 2007 at 09:54:13AM -0700, Medve Emilian wrote:
>
> > I just built and installed the latest master (and next) and
> then I tried
> > to clone (as I usualy do) one of my repositories. I run
> git-daemon only
> > with the upload-pack service enabled.
> > [...]
> >
> > Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Connection from
> > 10.82.124.104:2978
> > Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Extended
> attributes (18
> > bytes) exist <host=server>
> > Nov 20 10:17:04 emmedve1-12 git-daemon: [3921] Request
> upload-pack for
> > '/srv/scm/linux-2.6.git'
>
> I don't see anything useful there. Have you tried running git-daemon
> with --verbose? If that doesn't turn up anything, can you try running
> with GIT_TRACE=1 to see the upload pack command that is being executed
> (and try running it yourself)?
>
> > Did you try this and is working for you?
>
> Yes, it works fine (though I ran it under tcpserver, not xinetd).
>
> -Peff
^ permalink raw reply
* Re: [PATCH] Improve documentation of git-filter-branch rev-list specification.
From: Johannes Schindelin @ 2007-11-20 22:28 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git
In-Reply-To: <877ikc3gzc.wl%cworth@cworth.org>
Hi,
On Tue, 20 Nov 2007, Carl Worth wrote:
> diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
> index ba9b4fb..985d7d5 100644
> --- a/Documentation/git-filter-branch.txt
> +++ b/Documentation/git-filter-branch.txt
> @@ -13,23 +13,29 @@ SYNOPSIS
> [--msg-filter <command>] [--commit-filter <command>]
> [--tag-name-filter <command>] [--subdirectory-filter <directory>]
> [--original <namespace>] [-d <directory>] [-f | --force]
> - [<rev-list options>...]
> + <rev-list options>...
This is correct AFAICT.
> DESCRIPTION
> -----------
> -Lets you rewrite git revision history by rewriting the branches mentioned
> -in the <rev-list options>, applying custom filters on each revision.
> -Those filters can modify each tree (e.g. removing a file or running
> -a perl rewrite on all files) or information about each commit.
> -Otherwise, all information (including original commit times or merge
> -information) will be preserved.
> -
> -The command will only rewrite the _positive_ refs mentioned in the
> -command line (i.e. if you pass 'a..b', only 'b' will be rewritten).
> -If you specify no filters, the commits will be recommitted without any
> -changes, which would normally have no effect. Nevertheless, this may be
> -useful in the future for compensating for some git bugs or such,
> -therefore such a usage is permitted.
> +Rewrites git revision history by applying one or more filters to a set
> +of commits. The set of commits to be rewritten is supplied in
> +<rev-list options> and can be as simple as one or more branch names,
> +(in which case all commits reachable from those branch names will be
> +rewritten).
I do not particularly like that you say "commits to be rewritten".
Because not the commits, but the branches are rewritten. For example, if
you have branch A and B pointing to the same commit and you call
filter-branch on A, B will be left untouched _along with its commits_.
IMHO the old version -- while maybe not as eloquent as yours -- made that
very clear.
This was probably the reason you confused the comment about a..b earlier.
So I would appreciate rewriting the documentation in such a way that the
distinction between a commit and a ref is maintained clearly.
Ciao,
Dscho
^ permalink raw reply
* Re: gitweb: kernel versions in the history (feature request, probably)
From: Petr Baudis @ 2007-11-20 21:59 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: linux-kernel, git
In-Reply-To: <20071120142042.GA4157@ff.dom.local>
Hi,
On Tue, Nov 20, 2007 at 03:20:42PM +0100, Jarek Poplawski wrote:
> I see gitweb is much more usable (faster) than a few months ago, but
> there is one thing a bit problematic: in the history of patches I'm
> very often interested in which kernel version of Linus' tree the patch
> appeared for the first time. If it's not some big problem, and maybe
> somebody else finds this useful too, I'd really appreciate adding such
> a feature.
in git terms, you'd like gitweb to provide output for command:
git describe --contains
This is interesting feature request. I guess the support would be nice,
though in theory this operation can be a bit resource-intensive in case
there is not many tags and a lot of development (with uncached
repository, this query took quite a bit of time on my copy of the kernel
git tree). Probably this should be an optional feature and somehow dwell
on a separate page, which doesn't fit too well in the current gitweb
page structure...
> Petr, I hope there is no necessity to subscribe to the git list for
> this one question, so I'd really feel greteful for forwarding, if you
> find this request reasonable.
Yes, there is no necessity - you can post this on the git mailing list
without subscribing yourself.
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Junio C Hamano @ 2007-11-20 20:21 UTC (permalink / raw)
To: Sergei Organov; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <87ejekzpx3.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> [...]
>> Oops, forgot to say "no need to resend". I asked only because I
>> wanted an independent datapoint for Emacs diff mode breakage.
>
> I bet I can damage any patch using any editor ;)
>
> More interesting is what version of Emacs it was?
To be fair and honest, I do not think there is a simple fix for
this, although it probably is possible to fix it.
What is causing the "breakage" is the fact that format-patch
output ends with the signature delimiter line "^-- $" that
immediately follows the patch text. The number of preimage
lines recorded in the hunk header of course does not initially
count it, but you are asking the diff editing mode to help you
edit the patch.
In diff editing mode, you can not only edit the contents of
postimage lines, but also add and delete the preimage and
postimage lines, and the diff editimg mode recounts the lines
and adjusts the number of lines recorded in the hunk header when
you do it. It is very handy if it worked reliably (and often
it does).
But if you edit the last hunk of the format-patch output, unless
the editor very carefully keeps track of what you edited and
what was in the original, it is understandable that it would
mistake the signature delimiter line as the last preimage line
that is "^- $", and ends up miscounting the length of the hunk.
The signature delimiter was there from the beginning in the
patch file, but outside of the hunk in question. We could argue
that it is a bug to mistake that as a preimage line added by the
user (after all the editor knows what was modified and what was
from the beginning), but it still is understandable.
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Daniel Barkalow @ 2007-11-20 20:18 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: skimo, git
In-Reply-To: <20071120192231.GA23240@pvv.org>
On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:
> On Tue, Nov 20, 2007 at 01:59:41PM -0500, Daniel Barkalow wrote:
> > On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:
> >
> > > I'll try to boil this down to the simplest case possible. If
> > > submodules can do this I'll be really happy :)
> > >
> > > Developer A makes a change in submodule1 and in submodule2
> > > Developer B makes a change in submodule2 and in submodule3
> > >
> > > A and B don't know about eachother. They send their modifications
> > > somewhere (push to a shared repository with a well chosen branch name,
> > > for example), or send a mail "please pull from my repo" to the patch
> > > queue manager.
> > >
> > > It is absolutely crucial that for each developer, either both their
> > > modifications go in, or none of them. Git should make picking only
> > > one of their modifications hard.
> >
> > This is the case; if developer A changes 2 from 2-O to 2-A, and developer
> > B changes 2 from 2-O to 2-B, merging both supermodule commits gets a
> > conflict, which requires a merge in submodule 2 before the supermodule
> > merge can be committed.
>
> And this is partly why I wanted to branch all the involved modules: In
> ~99% of the cases, 2-A and 2-B modify different files, or at least
> wildly different parts of the same file, so the merge should be
> trivial/automatic. Therefore, the supermodule merge should also be a
> trivial/automatic merge - but it isn't, is it?
It's an automatic merge if you've got the submodule; if you don't have the
submodule, you can't tell that the merge would be trivial, because you
can't even see the order of the history in the submodule, let alone which
files change and how. This just means that the patch queue manager is
going to have to have all of the submodules, which is probably reasonable
if the patch queue manager is responsible for making sure that the
combination works.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc
From: Martin Mares @ 2007-11-20 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Guido Ostkamp, Björn Steinbrink, raa.lkml, git
In-Reply-To: <7vzlx8k7dl.fsf@gitster.siamese.dyndns.org>
Hello!
> How about doing it this way?
Yes, this looks perfect.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
^ permalink raw reply
* Re: [PATCH] Fix "identifier redeclared" compilation error with SUN cc
From: Junio C Hamano @ 2007-11-20 20:08 UTC (permalink / raw)
To: Martin Mares; +Cc: Guido Ostkamp, Björn Steinbrink, raa.lkml, git
In-Reply-To: <mj+md-20071120.182204.515.nikam@ucw.cz>
Martin Mares <mj@ucw.cz> writes:
> Do we really want to use empty FLEX_ARRAY only for a new gcc? Shouldn't
> we test for C99 instead (__STDC_VERSION__ >= 199901L) and only if it
> isn't C99, choose between 0 and 1 depending on gccness of the compiler?
How about doing it this way?
-- >8 --
[PATCH] git-compat-util.h: auto-adjust to compiler support of FLEX_ARRAY a bit better
When declaring a structure with a flexible array member, instead
of defaulting to the c99 syntax for non-gnu compilers (which
burned people with older compilers), default to the traditional
and more portable "member[1]; /* more */" syntax.
At the same time, other c99 compilers should be able to take
advantage of the modern syntax to flexible array members without
being gcc. Check __STDC_VERSION__ for that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-compat-util.h | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 276a437..454d25e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -4,10 +4,24 @@
#define _FILE_OFFSET_BITS 64
#ifndef FLEX_ARRAY
-#if defined(__GNUC__) && (__GNUC__ < 3)
-#define FLEX_ARRAY 0
-#else
-#define FLEX_ARRAY /* empty */
+/*
+ * See if our compiler is known to support flexible array members.
+ */
+#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
+# define FLEX_ARRAY /* empty */
+#elif defined(__GNUC__)
+# if (__GNUC__ >= 3)
+# define FLEX_ARRAY /* empty */
+# else
+# define FLEX_ARRAY 0 /* older GNU extension */
+# endif
+#endif
+
+/*
+ * Otherwise, default to safer but a bit wasteful traditional style
+ */
+#ifndef FLEX_ARRAY
+# define FLEX_ARRAY 1
#endif
#endif
--
1.5.3.6.1797.g67f5d
^ permalink raw reply related
* Ideas for improving the filter-branch workflow
From: Carl Worth @ 2007-11-20 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <877ikc3gzc.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]
On Tue, 20 Nov 2007 10:32:39 -0800, Carl Worth wrote:
> The rev-list is not optional, and a range of a..b will not rewrite
> only b.
It has since been explained to me that the original text was intended
to describe which branch tips will get updated. In that case, my
rewrite of the documentation leaves that part out.
Even so, I'm a bit confused by what the behavior is. When I run:
git filter-branch HEAD
The output I get is:
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
And nothing else after that. That's definitely confusing.
Also confusing is that the documentation emphasizes that I should
verify the newly rewritten heads against the backups in
refs/original. But I'm not given any guidance on how to access the
refs in refs/original. I don't know of standard git tools to list
these, ("git branch", "git branch -r", and "gitk --all" don't show
them for example). I can use something like "git log
original/refs/heads/master" but it takes a fair amount of knowledge to
get to that point.
Finally, I did my filter in multiple steps and found myself having to
do lots of manual cleanup. For example, on my second run of
git-filter-branch:
Error: Namespace refs/original/ not empty
Cleanup: rm -r .git/refs/original
And that failed attempt then triggers another problem:
Error: .git-rewrite already exists, please remove it
Cleanup: rm -r .git-rewrite
The second error was nice enough to tell me how to fix the problem,
(nothing ever indicates the need to cleanup refs/original that I can
tell). But I think this second error should never occur. The
filter-branch program should cleanup after itself if it fails.
Finally, I wonder if there's a better solution to the messiness of
making backups in refs/original, correctly documenting what branch
heads get rewritten, and then hoping that the user can find the
backups, use them to verify the new heads, and then clean them up.
One idea is to have two new sub-commands for git-filter-branch. Maybe
something like:
git filter-branch --accept
git filter-branch --reject # or --undo or whatever
And these would do all the cleanup necessary.
During the intermediate state, (after filter-branch and before
"filter-branch --accept"), it would be nice if it were easier to
verify the results. For example, if filter-branch stored its backups
in refs/heads/rewrite-original/* instead of refs/original/refs/heads/*
then they would show up automatically in "gitk --all" for example.
Anyway, those are some ideas if anyone wants to hack on this further.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Finn Arne Gangstad @ 2007-11-20 19:22 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: skimo, git
In-Reply-To: <Pine.LNX.4.64.0711201336530.32410@iabervon.org>
On Tue, Nov 20, 2007 at 01:59:41PM -0500, Daniel Barkalow wrote:
> On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:
>
> > I'll try to boil this down to the simplest case possible. If
> > submodules can do this I'll be really happy :)
> >
> > Developer A makes a change in submodule1 and in submodule2
> > Developer B makes a change in submodule2 and in submodule3
> >
> > A and B don't know about eachother. They send their modifications
> > somewhere (push to a shared repository with a well chosen branch name,
> > for example), or send a mail "please pull from my repo" to the patch
> > queue manager.
> >
> > It is absolutely crucial that for each developer, either both their
> > modifications go in, or none of them. Git should make picking only
> > one of their modifications hard.
>
> This is the case; if developer A changes 2 from 2-O to 2-A, and developer
> B changes 2 from 2-O to 2-B, merging both supermodule commits gets a
> conflict, which requires a merge in submodule 2 before the supermodule
> merge can be committed.
And this is partly why I wanted to branch all the involved modules: In
~99% of the cases, 2-A and 2-B modify different files, or at least
wildly different parts of the same file, so the merge should be
trivial/automatic. Therefore, the supermodule merge should also be a
trivial/automatic merge - but it isn't, is it?
- Finn Arne
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Sergei Organov @ 2007-11-20 19:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <7v8x4slovk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
[...]
> Oops, forgot to say "no need to resend". I asked only because I
> wanted an independent datapoint for Emacs diff mode breakage.
I bet I can damage any patch using any editor ;)
More interesting is what version of Emacs it was?
--
Sergei.
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Daniel Barkalow @ 2007-11-20 19:15 UTC (permalink / raw)
To: Sergei Organov; +Cc: Steven Grimm, Finn Arne Gangstad, git
In-Reply-To: <87ir3wzqzj.fsf@osv.gnss.ru>
On Tue, 20 Nov 2007, Sergei Organov wrote:
> I got the same impression, and then I wonder if the next logical thing
> the OP will need is, say, support for content moves between
> submodules. Somehow I doubt git will ever support that.
I don't see why not. If you tell the diff engine to look for content
moves, and you tell it to descend into submodules that you have, and you
have both ends of the content move, and you're looking at a supermodule
commit where such a content move happened, it should show it.
If any of these aren't true (and I don't think we have a "descend into
available submodules" option currently), you won't see it as a content
move, but you wouldn't expect to; you don't want to get a diff that says:
"move from (path you don't have) to (path you have)", with the diff
showing changes in the process, when you didn't have the original.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Junio C Hamano @ 2007-11-20 19:04 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <7A3DDFA5-085D-4D92-BE96-A405FF1FB029@develooper.com>
Ask Bjørn Hansen <ask@develooper.com> writes:
> On Nov 19, 2007, at 23:52, Junio C Hamano wrote:
>
>> How did you prepare and send this patch?
>
> git format-patch + tweak in emacs.
>
>> I see 7 preimage lines and 11 postimage lines, although the hunk
>> header claims otherwise.
>>
>> Did you edit the patch in Emacs diff mode or something?
>
> Indeed! I take it you've seen that particular way of botching it
> before. :-)
Yes and a heavy advocate of Emacs on this list wanted to get a
breakage example out of me which I forgot to supply but now we
have it. Unfortunately I do not offhand recall who it was.
> When I was about to send the patch I realized I had added whitespace
> at the end of one of the lines. Ironically then I ended up just
> sending the messed up patch because I couldn't apply it to my working
> copy after doing a reset. Being a new git user I convinced myself
> that I had messed up the reset rather than the patch. Doh. My
> apologies! A new patch should be on the list momentarily.
Oops, forgot to say "no need to resend". I asked only because I
wanted an independent datapoint for Emacs diff mode breakage.
^ permalink raw reply
* Re: Partial checkouts / submodules
From: Daniel Barkalow @ 2007-11-20 18:59 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: skimo, git
In-Reply-To: <20071120181932.GA20705@pvv.org>
On Tue, 20 Nov 2007, Finn Arne Gangstad wrote:
> On Tue, Nov 20, 2007 at 06:33:50PM +0100, Sven Verdoolaege wrote:
>
> > Just "submodule init" and "submodule update" these submodules and
> > it looks like you would get what you want...
> >
> > > If I make a branch on submodule71, the branch is made in all submodules &
> > > the supermodule.
> >
> > ... except this one.
> > It's not clear why you would even want this.
>
> I'll try to boil this down to the simplest case possible. If
> submodules can do this I'll be really happy :)
>
> Developer A makes a change in submodule1 and in submodule2
> Developer B makes a change in submodule2 and in submodule3
>
> A and B don't know about eachother. They send their modifications
> somewhere (push to a shared repository with a well chosen branch name,
> for example), or send a mail "please pull from my repo" to the patch
> queue manager.
>
> It is absolutely crucial that for each developer, either both their
> modifications go in, or none of them. Git should make picking only
> one of their modifications hard.
This is the case; if developer A changes 2 from 2-O to 2-A, and developer
B changes 2 from 2-O to 2-B, merging both supermodule commits gets a
conflict, which requires a merge in submodule 2 before the supermodule
merge can be committed.
On the other hand, 3-B will sort of enter the history of submodule 3
without the submodule 2 merge getting done; however, there's no way for
anybody to find it if it's not referenced by any supermodule commit yet
and people don't look at the individual histories of submodules.
One thing that might be an issue is that, if developer A of supermodule I
makes a commit that changes submodule 1 and submodule 2, and developer B
on supermodule II decides to merge supermodule I's submodule 1, and
supermodule II also includes submodule 2, but developer B doesn't care
about it, supermodule II could end up with only half of developer A's
change.
> Also - it would be very good if the history in the master repo would
> match the history in all developers' repositories (as the
> modifications are merged in by the patch queue manager). I.e. - you
> should see a "gif support" feature branch, see the commits on it, and
> finally the merge.
This is independant of submodule support, and depends on the patch queue
manager's policy. In some cases, it's desirable to simplify the history of
the feature branch when it's being merged into the master repo, so that
the master repo gets an idealized version of the feature branch (i.e.,
bugs introduced early in the development of the branch and fixed later,
but never affected the master repo, are not introduced in the first place;
also, the historical accident of the work on the topic being started
before other features but completed after them can be smoothed over, with
the resolution of merge conflicts distributed back to the sites where the
second set of changes was made). If the patch queue manager does this sort
of thing, the master repo's history will be different from the feature
branch's history as it appeared to the developers at the time, but the
feature branch also generally goes away at this point anyway, so it
doesn't matter too much.
-Daniel
*This .sig left intentionally blank*
^ 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