Re: your mail

Re: your mail

[Elfyn McBratney]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Wed, Oct 05, 2005 at 08:10:24AM +0200, Willem Swart wrote:
 > subscribe git
 > -
 > To unsubscribe from this list: send the line "unsubscribe git" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
s/unsubscribe/subscribe/g

Might want to re-send that to majordomo@vger.kernel.org ;)

Best,
Elfyn

-- 
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: your mail

[J. Bruce Fields]

On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>

Oops, sorry, I screwed up sending those; let me know if you'd like them
resent....

--b.

Re: your mail

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
>> >From nobody Mon Sep 17 00:00:00 2001
>> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> Oops, sorry, I screwed up sending those; let me know if you'd like them
> resent....

That's OK.  I just cooked up this one ;-).

-- >8 --
From 03946787890c12fbb6ecfbe0382cbf02ac209801 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 21 May 2006 17:15:06 -0700
Subject: [PATCH] mailinfo: skip bogus UNIX From line inside body

Sometimes people just include the whole format-patch output in
the commit e-mail.  Detect it and skip the bogus ">From " line.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 mailinfo.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/mailinfo.c b/mailinfo.c
index b276519..a133e6d 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -237,10 +237,17 @@ static int eatspace(char *line)
 #define SEEN_FROM 01
 #define SEEN_DATE 02
 #define SEEN_SUBJECT 04
+#define SEEN_BOGUS_UNIX_FROM 010
 
 /* First lines of body can have From:, Date:, and Subject: */
 static int handle_inbody_header(int *seen, char *line)
 {
+	if (!memcmp(">From", line, 5) && isspace(line[5])) {
+		if (!(*seen & SEEN_BOGUS_UNIX_FROM)) {
+			*seen |= SEEN_BOGUS_UNIX_FROM;
+			return 1;
+		}
+	}
 	if (!memcmp("From:", line, 5) && isspace(line[5])) {
 		if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
 			*seen |= SEEN_FROM;
-- 
1.3.3.g292f

Re: your mail

[J. Bruce Fields]

On Sun, May 21, 2006 at 05:16:44PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >> >From nobody Mon Sep 17 00:00:00 2001
> >> From: J. Bruce Fields <bfields@citi.umich.edu>
> >
> > Oops, sorry, I screwed up sending those; let me know if you'd like them
> > resent....
> 
> That's OK.  I just cooked up this one ;-).

Thanks!--b.

Re: your mail

[Linus Torvalds]

On Tue, 26 Sep 2006, Zhao, Jing wrote:
> 
>  I subscribed git emailing list (git@vger.kernel.org). I don't know for 
> what reason, my post emails all have been rejected. Could you post this 
> for me and shed some light on this issue? thanks,

The vger.kernel.org lists have various spam detectors, and I suspect a 
combination of your email address and the signature you use just triggers 
that system to believe that you are trying to sell us house payment plans 
or something..

So I would suggest removing your signature in particular, that points to a 
web-site that is associated with an industry that has over-used the email 
medium for selling their services...

> I tried to port git to VOS system (Stratus). When i compiled it, i 
> found it did not have 'regex.h' and its library. Do you know any 
> workaround for this problem? Or which package contains these code i can 
> port at first?

I do not know if stratus has regex libraries anywhere, but googling for 
"VOS Stratus regex" seems to be saying that this isn't the first time that 
platform has had problems compiling various programs.

I suspect you'd just have to compile one of the regex libraries that are 
out there as source. I think Henry Spencer's libraries are likely the 
canonical ones, but there's a "GNU regex" too, and that's probably the 
basis for the ones that are used in glibc. Dunno.

Google for either of those, you'll find them. It's not new code, but I 
doubt it needs to be ;)

			Linus

Re: your mail

[Johannes Schindelin]

Hi,

your email is horridly mixed here. I get an empty subject here, and the 
complete email header at the beginning of the email:

On Fri, 20 Oct 2006, andyparkins@gmail.com wrote:

> >From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> [... complete email header including MIME header ...]
> Content-Disposition: inline
> 
> git-send-email doesn't exist; so don't refer to it in the documentation.

But it does! I just removed it, and "make" remade it. I don't even see in 
the Makefile why it should _not_ be made...

Ciao,
Dscho

Re: your mail

[Davide Libenzi]

On Tue, 21 Nov 2006, Johannes Schindelin wrote:

> [PATCH] xdiff: add xdl_merge()
> 
> This new function implements the functionality of RCS merge, but
> in-memory. It returns < 0 on error, otherwise the number of conflicts.
> 
> Finding the conflicting lines can be a very expensive task. You can
> control the eagerness of this algorithm:
> 
> - a level value of 0 means that all overlapping changes are treated
>   as conflicts,
> - a value of 1 means that if the overlapping changes are identical,
>   it is not treated as a conflict.
> - If you set level to 2, overlapping changes will be analyzed, so that
>   almost identical changes will not result in huge conflicts. Rather,
>   only the conflicting lines will be shown inside conflict markers.
> 
> With each increasing level, the algorithm gets slower, but more accurate.
> Note that the code for level 2 depends on the simple definition of
> mmfile_t specific to git, and therefore it will be harder to port that
> to LibXDiff.

Johannes, at the moment I'm chased by a huge storm of never ending emails, 
so I won't be able to follow up this one soon. A smart 3-way merge is in 
my plans for LibXDiff though.
There is quite some nice code around, that does pretty smart tricks and 
goes down to resolve sub-hunk non-trivial conflicts. You may want to take 
a look at that code too.



- Davide

Re: your mail

[Jeff King]

On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:

> Now that you mention it, I think the best approach would be to:
> 	
> 	(1) cvsexportcommit
> 	(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
> 	(3) git cvsimport ..... # and merge
>
> I think this is what you mean; it seems to me that rebasing isn't quite 
> that.

No, I mean rebasing instead of merge. As in, you have a history like
this:

    /--C---D  <-- your master
A--B
    \--C'--D' <-- cvsimport merge tip

where "C" and "D" are your commits in git, and C' and D' are pulled in
from cvsimport. You want to rebase your work like this:

A--B--C'--D'--C--D

except that git-rebase is smart enough to realize that C == C' and skip
it (so it's a "safe" way of moving forward).

> However, this will not preserve more complicated history such as merges
> from another git repository.

Correct. Rebasing doesn't really handle merges, but I assumed you were
just making simple commits on top of a cvs master.

> Basically, I want to treat my git repository as the official
> repository; the CVS repo is just their for the old farts to get the
> latest stuff ;-P

Then my suggestion doesn't really work. You might consider using git as
the official server and letting the old farts use git-cvsserver.

HTH,
-Peff

[PATCH 0/6] builtin-remote

[Johannes Schindelin]

Hi,

this series introduces remote as a builtin, and fixes a long-standing bug 
(if you created a remote with --mirror, prune would not do the right 
thing).

I know it is pretty late in the game for 1.5.4, but then, I do not expect 
this to go into that version...

Ciao,
Dscho

(unknown)

[Johannes Schindelin]

[PATCH 1/6] path-list: add functions to work with unsorted lists

Up to now, path-lists were sorted at all times.  But sometimes it
is much more convenient to build the list and sort it at the end,
or sort it not at all.

Add path_list_append() and sort_path_list() to allow that.

Also, add the unsorted_path_list_has_path() function, to do a linear
search.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	I should have done this much earlier...

 path-list.c |   30 ++++++++++++++++++++++++++++++
 path-list.h |    8 +++++++-
 2 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/path-list.c b/path-list.c
index 3d83b7b..92e5cf2 100644
--- a/path-list.c
+++ b/path-list.c
@@ -102,3 +102,33 @@ void print_path_list(const char *text, const struct path_list *p)
 	for (i = 0; i < p->nr; i++)
 		printf("%s:%p\n", p->items[i].path, p->items[i].util);
 }
+
+struct path_list_item *path_list_append(const char *path, struct path_list *list)
+{
+	ALLOC_GROW(list->items, list->nr + 1, list->alloc);
+	list->items[list->nr].path =
+		list->strdup_paths ? xstrdup(path) : (char *)path;
+	return list->items + list->nr++;
+}
+
+static int cmp_items(const void *a, const void *b)
+{
+	const struct path_list_item *one = a;
+	const struct path_list_item *two = b;
+	return strcmp(one->path, two->path);
+}
+
+void sort_path_list(struct path_list *list)
+{
+	qsort(list->items, list->nr, sizeof(*list->items), cmp_items);
+}
+
+int unsorted_path_list_has_path(struct path_list *list, const char *path)
+{
+	int i;
+	for (i = 0; i < list->nr; i++)
+		if (!strcmp(path, list->items[i].path))
+			return 1;
+	return 0;
+}
+
diff --git a/path-list.h b/path-list.h
index 5931e2c..ca2cbba 100644
--- a/path-list.h
+++ b/path-list.h
@@ -13,10 +13,16 @@ struct path_list
 };
 
 void print_path_list(const char *text, const struct path_list *p);
+void path_list_clear(struct path_list *list, int free_util);
 
+/* Use these functions only on sorted lists: */
 int path_list_has_path(const struct path_list *list, const char *path);
-void path_list_clear(struct path_list *list, int free_util);
 struct path_list_item *path_list_insert(const char *path, struct path_list *list);
 struct path_list_item *path_list_lookup(const char *path, struct path_list *list);
 
+/* Use these functions only on unsorted lists: */
+struct path_list_item *path_list_append(const char *path, struct path_list *list);
+void sort_path_list(struct path_list *list);
+int unsorted_path_list_has_path(struct path_list *list, const char *path);
+
 #endif /* PATH_LIST_H */
-- 
1.5.3.7.2157.g9598e

[PATCH 2/6] parseopt: add flag to stop on first non option

[Johannes Schindelin]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	This allows "git remote --option command --command-option".

 parse-options.c |    2 ++
 parse-options.h |    1 +
 2 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/parse-options.c b/parse-options.c
index e12b428..6df1230 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -229,6 +229,8 @@ int parse_options(int argc, const char **argv, const struct option *options,
 		const char *arg = args.argv[0];
 
 		if (*arg != '-' || !arg[1]) {
+			if (flags & PARSE_OPT_STOP_AT_NON_OPTION)
+				break;
 			argv[j++] = args.argv[0];
 			continue;
 		}
diff --git a/parse-options.h b/parse-options.h
index 102ac31..0d40cd2 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -18,6 +18,7 @@ enum parse_opt_type {
 
 enum parse_opt_flags {
 	PARSE_OPT_KEEP_DASHDASH = 1,
+	PARSE_OPT_STOP_AT_NON_OPTION = 2,
 };
 
 enum parse_opt_option_flags {
-- 
1.5.3.7.2157.g9598e

Re: your mail

[Johannes Schindelin]

Hi,

On Wed, 5 Dec 2007, Johannes Schindelin wrote:

> [PATCH 1/6] path-list: add functions to work with unsorted lists

Ooops.

Sorry,
Dscho

[PATCH 3/6] Test "git remote show" and "git remote prune"

[Johannes Schindelin]

While at it, also fix a few instances where a cd was done outside of a
subshell.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t5505-remote.sh |   34 ++++++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 636aec2..c7d7242 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -97,4 +97,38 @@ test_expect_success 'remove remote' '
 )
 '
 
+cat > test/expect << EOF
+* remote origin
+  URL: $(pwd)/one/.git
+  Remote branch(es) merged with 'git pull' while on branch master
+    master
+  New remote branches (next fetch will store in remotes/origin)
+    master
+  Tracked remote branches
+    side master
+EOF
+
+test_expect_success 'show' '
+	(cd test &&
+	 git config --add remote.origin.fetch \
+		refs/heads/master:refs/heads/upstream &&
+	 git fetch &&
+	 git branch -d -r origin/master &&
+	 (cd ../one &&
+	  echo 1 > file &&
+	  git commit -m update file) &&
+	 git remote show origin > output &&
+	 git diff expect output)
+'
+
+test_expect_success 'prune' '
+	(cd one &&
+	 git branch -m side side2) &&
+	(cd test &&
+	 git fetch origin &&
+	 git remote prune origin &&
+	 git rev-parse refs/remotes/origin/side2 &&
+	 ! git rev-parse refs/remotes/origin/side)
+'
+
 test_done
-- 
1.5.3.7.2157.g9598e

[PATCH 4/6] Make git-remote a builtin

[Johannes Schindelin]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Makefile                                           |    3 +-
 builtin-remote.c                                   |  517 ++++++++++++++++++++
 builtin.h                                          |    1 +
 .../examples/git-remote.perl                       |    0 
 git.c                                              |    1 +
 remote.c                                           |    3 +-
 remote.h                                           |    1 +
 t/t5505-remote.sh                                  |    4 +-
 8 files changed, 526 insertions(+), 4 deletions(-)
 create mode 100644 builtin-remote.c
 rename git-remote.perl => contrib/examples/git-remote.perl (100%)

diff --git a/Makefile b/Makefile
index 233bb5f..e840ca3 100644
--- a/Makefile
+++ b/Makefile
@@ -228,7 +228,7 @@ SCRIPT_SH = \
 SCRIPT_PERL = \
 	git-add--interactive.perl \
 	git-archimport.perl git-cvsimport.perl git-relink.perl \
-	git-cvsserver.perl git-remote.perl git-cvsexportcommit.perl \
+	git-cvsserver.perl git-cvsexportcommit.perl \
 	git-send-email.perl git-svn.perl
 
 SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
@@ -362,6 +362,7 @@ BUILTIN_OBJS = \
 	builtin-push.o \
 	builtin-read-tree.o \
 	builtin-reflog.o \
+	builtin-remote.o \
 	builtin-send-pack.o \
 	builtin-config.o \
 	builtin-rerere.o \
diff --git a/builtin-remote.c b/builtin-remote.c
new file mode 100644
index 0000000..41ac4a1
--- /dev/null
+++ b/builtin-remote.c
@@ -0,0 +1,517 @@
+#include "cache.h"
+#include "parse-options.h"
+#include "transport.h"
+#include "remote.h"
+#include "path-list.h"
+#include "strbuf.h"
+#include "run-command.h"
+#include "refs.h"
+
+static const char * const builtin_remote_usage[] = {
+	"git remote",
+        "git remote add <name> <url>",
+        "git remote rm <name>",
+        "git remote show <name>",
+        "git remote prune <name>",
+        "git remote update [group]",
+	NULL
+};
+
+static int verbose;
+
+static inline int postfixcmp(const char *string, const char *postfix)
+{
+	int len1 = strlen(string), len2 = strlen(postfix);
+	if (len1 < len2)
+		return 1;
+	return strcmp(string + len1 - len2, postfix);
+}
+
+static inline const char *skip_prefix(const char *name, const char *prefix)
+{
+	return !name ? "" :
+		prefixcmp(name, prefix) ?  name : name + strlen(prefix);
+}
+
+static int opt_parse_track(const struct option *opt, const char *arg, int not)
+{
+	struct path_list *list = opt->value;
+	if (not)
+		path_list_clear(list, 0);
+	else
+		path_list_append(arg, list);
+	return 0;
+}
+
+static int fetch_remote(const char *name)
+{
+	const char *argv[] = { "fetch", name, NULL };
+	if (run_command_v_opt(argv, RUN_GIT_CMD))
+		return error ("Could not fetch %s", name);
+	return 0;
+}
+
+static int add(int argc, const char **argv)
+{
+	int fetch = 0, mirror = 0;
+	struct path_list track = { NULL, 0, 0 };
+	const char *master = NULL;
+	struct remote *remote;
+	struct strbuf buf, buf2;
+	const char *name, *url;
+	int i;
+
+	struct option options[] = {
+		OPT_GROUP("add specific options"),
+		OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
+		OPT_CALLBACK('t', "track", &track, "branch",
+			"branch(es) to track", opt_parse_track),
+		OPT_STRING('m', "master", &master, "branch", "master branch"),
+		OPT_BOOLEAN(0, "mirror", &mirror, "no separate remotes"),
+		OPT_END()
+	};
+
+	argc = parse_options(argc, argv, options, builtin_remote_usage, 0);
+
+	if (argc < 2)
+		usage_with_options(builtin_remote_usage, options);
+
+	name = argv[0];
+	url = argv[1];
+
+	remote = remote_get(name);
+	if (remote && (remote->url_nr > 1 || strcmp(name, remote->url[0]) ||
+			remote->fetch_refspec_nr))
+		die ("remote %s already exists.", name);
+
+	strbuf_init(&buf, 0);
+	strbuf_init(&buf2, 0);
+
+	strbuf_addf(&buf, "remote.%s.url", name);
+	if (git_config_set(buf.buf, url))
+		return 1;
+
+	if (track.nr == 0)
+		path_list_append("*", &track);
+	for (i = 0; i < track.nr; i++) {
+		struct path_list_item *item = track.items + i;
+
+		strbuf_reset(&buf);
+		strbuf_addf(&buf, "remote.%s.fetch", name);
+
+		strbuf_reset(&buf2);
+		if (mirror)
+			strbuf_addf(&buf2, "refs/%s:refs/%s",
+					item->path, item->path);
+		else
+			strbuf_addf(&buf2, "refs/heads/%s:refs/remotes/%s/%s",
+					item->path, name, item->path);
+		if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+			return 1;
+	}
+
+	if (fetch && fetch_remote(name))
+		return 1;
+
+	if (master) {
+		strbuf_reset(&buf);
+		strbuf_addf(&buf, "refs/remotes/%s/HEAD", name);
+
+		strbuf_reset(&buf2);
+		strbuf_addf(&buf2, "refs/remotes/%s/%s", name, master);
+
+		if (create_symref(buf.buf, buf2.buf, "remote add"))
+			return error ("Could not setup master '%s'", master);
+	}
+
+	strbuf_release(&buf);
+	strbuf_release(&buf2);
+	path_list_clear(&track, 0);
+
+	return 0;
+}
+
+struct branch_info {
+	char *remote;
+	struct path_list merge;
+};
+
+static struct path_list branch_list;
+
+static int config_read_branches(const char *key, const char *value)
+{
+	if (!prefixcmp(key, "branch.")) {
+		char *name;
+		struct path_list_item *item;
+		struct branch_info *info;
+		enum { REMOTE, MERGE } type;
+
+		key += 7;
+		if (!postfixcmp(key, ".remote")) {
+			name = xstrndup(key, strlen(key) - 7);
+			type = REMOTE;
+		} else if (!postfixcmp(key, ".merge")) {
+			name = xstrndup(key, strlen(key) - 6);
+			type = MERGE;
+		} else
+			return 0;
+
+		item = path_list_insert(name, &branch_list);
+
+		if (!item->util)
+			item->util = xcalloc(sizeof(struct branch_info), 1);
+		info = item->util;
+		if (type == REMOTE) {
+			if (info->remote)
+				warning ("more than one branch.%s", key);
+			info->remote = xstrdup(value);
+		} else {
+			char *space = strchr(value, ' ');
+			value = skip_prefix(value, "refs/heads/");
+			while (space) {
+				char *merge;
+				merge = xstrndup(value, space - value);
+				path_list_append(merge, &info->merge);
+				value = skip_prefix(space + 1, "refs/heads/");
+				space = strchr(value, ' ');
+			}
+			path_list_append(xstrdup(value), &info->merge);
+		}
+	}
+	return 0;
+}
+
+static void read_branches()
+{
+	if (branch_list.nr)
+		return;
+	git_config(config_read_branches);
+	sort_path_list(&branch_list);
+}
+
+struct ref_states {
+	struct remote *remote;
+	struct strbuf remote_prefix;
+	struct path_list new, stale, tracked;
+};
+
+static int handle_one_branch(const char *refname,
+	const unsigned char *sha1, int flags, void *cb_data)
+{
+	struct ref_states *states = cb_data;
+	struct refspec refspec;
+
+	memset(&refspec, 0, sizeof(refspec));
+	refspec.dst = (char *)refname;
+	if (!remote_find_tracking(states->remote, &refspec)) {
+		struct path_list_item *item;
+		const char *name = skip_prefix(refspec.src, "refs/heads/");
+		if (unsorted_path_list_has_path(&states->tracked, name) ||
+				unsorted_path_list_has_path(&states->new,
+					name))
+			return 0;
+		item = path_list_append(name, &states->stale);
+		item->util = xstrdup(refname);
+	}
+	return 0;
+}
+
+static int get_ref_states(const struct ref *ref, struct ref_states *states)
+{
+	struct ref *fetch_map = NULL, **tail = &fetch_map;
+	int i;
+
+	for (i = 0; i < states->remote->fetch_refspec_nr; i++)
+		if (get_fetch_map(ref, states->remote->fetch +i, &tail, 1))
+			die ("Could not get fetch map for refspec %s",
+				states->remote->fetch_refspec[i]);
+
+	states->new.strdup_paths = states->tracked.strdup_paths = 1;
+	for (ref = fetch_map; ref; ref = ref->next) {
+		struct path_list *target = &states->tracked;
+		unsigned char sha1[20];
+		void *util = NULL;
+
+		if (!ref->peer_ref || read_ref(ref->peer_ref->name, sha1))
+			target = &states->new;
+		else {
+			target = &states->tracked;
+			if (hashcmp(sha1, ref->new_sha1))
+				util = &states;
+		}
+		path_list_append(skip_prefix(ref->name, "refs/heads/"),
+				target)->util = util;
+	}
+	free_refs(fetch_map);
+
+	strbuf_addf(&states->remote_prefix,
+		"refs/remotes/%s/", states->remote->name);
+	for_each_ref(handle_one_branch, states);
+	sort_path_list(&states->stale);
+
+	return 0;
+}
+
+static int remove_tracking_branch(const char *refname,
+	const unsigned char *sha1, int flags, void *cb_data)
+{
+	const char *remote_prefix = cb_data;
+
+	if (!prefixcmp(refname, remote_prefix) &&
+			delete_ref(refname, sha1))
+		return error("Could not remove branch %s", refname);
+	return 0;
+}
+
+static int rm(int argc, const char **argv)
+{
+	struct option options[] = {
+		OPT_END()
+	};
+	struct remote *remote;
+	struct strbuf buf;
+	int i;
+
+	if (argc != 2)
+		usage_with_options(builtin_remote_usage, options);
+
+	remote = remote_get(argv[1]);
+	if (!remote)
+		die ("No such remote: %s", argv[1]);
+
+	strbuf_init(&buf, 0);
+	strbuf_addf(&buf, "remote.%s", remote->name);
+	if (git_config_rename_section(buf.buf, NULL) < 1)
+		return error("Could not remove config section '%s'", buf.buf);
+
+	read_branches();
+	for (i = 0; i < branch_list.nr; i++) {
+		struct path_list_item *item = branch_list.items +i;
+		struct branch_info *info = item->util;
+		if (info->remote && !strcmp(info->remote, remote->name)) {
+			const char *keys[] = { "remote", "merge", NULL }, **k;
+			for (k = keys; *k; k++) {
+				strbuf_reset(&buf);
+				strbuf_addf(&buf, "branch.%s.%s",
+						item->path, *k);
+				if (git_config_set(buf.buf, NULL)) {
+					strbuf_release(&buf);
+					return -1;
+				}
+			}
+		}
+	}
+
+	/*
+	 * NEEDSTHOUGHT: this could check something like
+	 * !remote_find_tracking(remote, &refspec) to know if the
+	 * branch was really tracked.  But then we'll have to make
+	 * sure that no other remote writes into that branch.
+	 * Probably not worth it.
+	 */
+	strbuf_reset(&buf);
+	strbuf_addf(&buf, "refs/remotes/%s/", remote->name);
+	i = for_each_ref(remove_tracking_branch, buf.buf);
+	strbuf_release(&buf);
+
+	return i;
+}
+
+static void show_list(const char *title, struct path_list *list)
+{
+	int i;
+
+	if (!list->nr)
+		return;
+
+	printf(title, list->nr > 1 ? "es" : "");
+	printf("\n    ");
+	for (i = 0; i < list->nr; i++)
+		printf("%s%s", i ? " " : "", list->items[i].path);
+	printf("\n");
+}
+
+static int show_or_prune(int argc, const char **argv, int prune)
+{
+	int dry_run = 0, result = 0;
+	struct option options[] = {
+		OPT_GROUP("show specific options"),
+		OPT__DRY_RUN(&dry_run),
+		OPT_END()
+	};
+	struct ref_states states;
+
+	argc = parse_options(argc, argv, options, builtin_remote_usage, 0);
+
+	if (argc < 1)
+		usage_with_options(builtin_remote_usage, options);
+
+	memset(&states, 0, sizeof(states));
+	for (; argc; argc--, argv++) {
+		struct transport *transport;
+		const struct ref *ref;
+		struct strbuf buf;
+		int i, got_states;
+
+		states.remote = remote_get(*argv);
+		if (!states.remote)
+			return error("No such remote: %s", *argv);
+		transport = transport_get(NULL, states.remote->url[0]);
+		ref = transport_get_remote_refs(transport);
+
+		read_branches();
+		got_states = get_ref_states(ref, &states);
+		if (got_states)
+			result = error("Error getting local info for '%s'",
+					states.remote->name);
+
+		if (prune) {
+			struct strbuf buf;
+
+			strbuf_init(&buf, 0);
+			for (i = 0; i < states.stale.nr; i++) {
+				strbuf_reset(&buf);
+				strbuf_addf(&buf, "refs/remotes/%s/%s", *argv,
+						states.stale.items[i].path);
+				result |= delete_ref(buf.buf, NULL);
+			}
+
+			strbuf_release(&buf);
+			goto cleanup_states;
+		}
+
+		printf("* remote %s\n  URL: %s\n", *argv,
+			states.remote->url[0] ?
+				states.remote->url[0] : "(no URL)");
+
+		for (i = 0; i < branch_list.nr; i++) {
+			struct path_list_item *branch = branch_list.items + i;
+			struct branch_info *info = branch->util;
+			int j;
+
+			if (!info->merge.nr || strcmp(*argv, info->remote))
+				continue;
+			printf("  Remote branch%s merged with 'git pull' "
+				"while on branch %s\n   ",
+				info->merge.nr > 1 ? "es" : "",
+				branch->path);
+			for (j = 0; j < info->merge.nr; j++)
+				printf(" %s", info->merge.items[j].path);
+			printf("\n");
+		}
+
+		if (got_states)
+			continue;
+		strbuf_init(&buf, 0);
+		strbuf_addf(&buf, "  New remote branch%%s (next fetch will "
+			"store in remotes/%s)", states.remote->name);
+		show_list(buf.buf, &states.new);
+		strbuf_release(&buf);
+		show_list("  Stale tracking branch%s (use 'git remote prune')",
+				&states.stale);
+		show_list("  Tracked remote branch%s",
+				&states.tracked);
+
+		if (states.remote->push_refspec_nr) {
+			printf("  Local branch%s pushed with 'git push'\n   ",
+				states.remote->push_refspec_nr > 1 ?
+					"es" : "");
+			for (i = 0; i < states.remote->push_refspec_nr; i++) {
+				struct refspec *spec = states.remote->push + i;
+				printf(" %s%s%s%s", spec->force ? "+" : "",
+					skip_prefix(spec->src, "refs/heads/"),
+					spec->dst ? ":" : "",
+					skip_prefix(spec->dst, "refs/heads/"));
+			}
+		}
+cleanup_states:
+		/* NEEDSWORK: free remote */
+		path_list_clear(&states.new, 0);
+		path_list_clear(&states.stale, 0);
+		path_list_clear(&states.tracked, 0);
+	}
+
+	return result;
+}
+
+static int update_one(struct remote *remote, void *priv)
+{
+	if (!remote->skip_default_update)
+		return fetch_remote(remote->name);
+	return 0;
+}
+
+static int update(int argc, const char **argv)
+{
+	int i;
+
+	if (argc < 2)
+		return for_each_remote(update_one, NULL);
+
+	for (i = 1; i < argc; i++)
+		if (fetch_remote(argv[i]))
+			return 1;
+	return 0;
+}
+
+static int get_one_entry(struct remote *remote, void *priv)
+{
+	struct path_list *list = priv;
+
+	path_list_append(remote->name, list)->util = (void *)remote->url[0];
+	if (remote->url[0] && remote->url[1])
+		warning ("Remote %s has more than one URL", remote->name);
+
+	return 0;
+}
+
+static int show_all()
+{
+	struct path_list list = { NULL, 0, 0 };
+	int result = for_each_remote(get_one_entry, &list);
+
+	if (!result) {
+		int i;
+
+		sort_path_list(&list);
+		for (i = 0; i < list.nr; i++) {
+			struct path_list_item *item = list.items + i;
+			printf("%s%s%s\n", item->path,
+				verbose ? "\t" : "",
+				verbose && item->util ?
+					(const char *)item->util : "");
+		}
+	}
+	return result;
+}
+
+int cmd_remote(int argc, const char **argv, const char *prefix)
+{
+	struct option options[] = {
+		OPT__VERBOSE(&verbose),
+		OPT_END()
+	};
+	int result;
+
+	argc = parse_options(argc, argv, options, builtin_remote_usage,
+		PARSE_OPT_STOP_AT_NON_OPTION);
+
+	if (argc < 1)
+		result = show_all();
+	else if (!strcmp(argv[0], "add"))
+		result = add(argc, argv);
+	else if (!strcmp(argv[0], "rm"))
+		result = rm(argc, argv);
+	else if (!strcmp(argv[0], "show"))
+		result = show_or_prune(argc, argv, 0);
+	else if (!strcmp(argv[0], "prune"))
+		result = show_or_prune(argc, argv, 1);
+	else if (!strcmp(argv[0], "update"))
+		result = update(argc, argv);
+	else {
+		error ("Unknown subcommand: %s", argv[0]);
+		usage_with_options(builtin_remote_usage, options);
+	}
+
+	return result ? 1 : 0;
+}
diff --git a/builtin.h b/builtin.h
index cb675c4..20b6e75 100644
--- a/builtin.h
+++ b/builtin.h
@@ -66,6 +66,7 @@ extern int cmd_prune_packed(int argc, const char **argv, const char *prefix);
 extern int cmd_push(int argc, const char **argv, const char *prefix);
 extern int cmd_read_tree(int argc, const char **argv, const char *prefix);
 extern int cmd_reflog(int argc, const char **argv, const char *prefix);
+extern int cmd_remote(int argc, const char **argv, const char *prefix);
 extern int cmd_config(int argc, const char **argv, const char *prefix);
 extern int cmd_rerere(int argc, const char **argv, const char *prefix);
 extern int cmd_reset(int argc, const char **argv, const char *prefix);
diff --git a/git-remote.perl b/contrib/examples/git-remote.perl
similarity index 100%
rename from git-remote.perl
rename to contrib/examples/git-remote.perl
diff --git a/git.c b/git.c
index c8b7e74..80e9082 100644
--- a/git.c
+++ b/git.c
@@ -349,6 +349,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "push", cmd_push, RUN_SETUP },
 		{ "read-tree", cmd_read_tree, RUN_SETUP },
 		{ "reflog", cmd_reflog, RUN_SETUP },
+		{ "remote", cmd_remote, RUN_SETUP },
 		{ "repo-config", cmd_config },
 		{ "rerere", cmd_rerere, RUN_SETUP },
 		{ "reset", cmd_reset, RUN_SETUP },
diff --git a/remote.c b/remote.c
index 3fb0f99..ae7abe4 100644
--- a/remote.c
+++ b/remote.c
@@ -280,7 +280,8 @@ static int handle_config(const char *key, const char *value)
 			remote->fetch_tags = -1;
 	} else if (!strcmp(subkey, ".proxy")) {
 		remote->http_proxy = xstrdup(value);
-	}
+	} else if (!strcmp(subkey, ".skipdefaultupdate"))
+		remote->skip_default_update = 1;
 	return 0;
 }
 
diff --git a/remote.h b/remote.h
index 86e036d..bb26d3c 100644
--- a/remote.h
+++ b/remote.h
@@ -22,6 +22,7 @@ struct remote {
 	 * 2 to always fetch tags
 	 */
 	int fetch_tags;
+	int skip_default_update;
 
 	const char *receivepack;
 	const char *uploadpack;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c7d7242..d343a96 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -100,9 +100,9 @@ test_expect_success 'remove remote' '
 cat > test/expect << EOF
 * remote origin
   URL: $(pwd)/one/.git
-  Remote branch(es) merged with 'git pull' while on branch master
+  Remote branch merged with 'git pull' while on branch master
     master
-  New remote branches (next fetch will store in remotes/origin)
+  New remote branch (next fetch will store in remotes/origin)
     master
   Tracked remote branches
     side master
-- 
1.5.3.7.2157.g9598e

[PATCH 5/6] builtin-remote: prune remotes correctly that were added with --mirror

[Johannes Schindelin]

This adds special handling for mirror remotes.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	This fixes a real bug in git-remote, which I tried to fix in the
	perl script, failing.

 builtin-remote.c  |   16 +++++++++++++---
 t/t5505-remote.sh |   16 ++++++++++++++++
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/builtin-remote.c b/builtin-remote.c
index 41ac4a1..142eb97 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -367,12 +367,22 @@ static int show_or_prune(int argc, const char **argv, int prune)
 
 		if (prune) {
 			struct strbuf buf;
+			int prefix_len;
 
 			strbuf_init(&buf, 0);
+			if (states.remote->fetch_refspec_nr == 1 &&
+					states.remote->fetch->pattern &&
+					!strcmp(states.remote->fetch->src,
+						states.remote->fetch->dst))
+				/* handle --mirror remote */
+				strbuf_addstr(&buf, "refs/heads/");
+			else
+				strbuf_addf(&buf, "refs/remotes/%s/", *argv);
+			prefix_len = buf.len;
+
 			for (i = 0; i < states.stale.nr; i++) {
-				strbuf_reset(&buf);
-				strbuf_addf(&buf, "refs/remotes/%s/%s", *argv,
-						states.stale.items[i].path);
+				strbuf_setlen(&buf, prefix_len);
+				strbuf_addstr(&buf, states.stale.items[i].path);
 				result |= delete_ref(buf.buf, NULL);
 			}
 
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index d343a96..2376e0a 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -131,4 +131,20 @@ test_expect_success 'prune' '
 	 ! git rev-parse refs/remotes/origin/side)
 '
 
+test_expect_success 'add --mirror && prune' '
+	(mkdir mirror &&
+	 cd mirror &&
+	 git init &&
+	 git remote add --mirror -f origin ../one) &&
+	(cd one &&
+	 git branch -m side2 side) &&
+	(cd mirror &&
+	 git rev-parse --verify refs/heads/side2 &&
+	 ! git rev-parse --verify refs/heads/side &&
+	 git fetch origin &&
+	 git remote prune origin &&
+	 ! git rev-parse --verify refs/heads/side2 &&
+	 git rev-parse --verify refs/heads/side)
+'
+
 test_done
-- 
1.5.3.7.2157.g9598e

[PATCH 6/6] DWIM "git add remote ..."

[Johannes Schindelin]

It is wrong to divert to "git remote add" when you typed the
(more English) "git add remote".  But is it also pretty convenient.

So implement it, but do not document it ;-)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 builtin-add.c     |    7 +++++++
 t/t5505-remote.sh |    6 ++++++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/builtin-add.c b/builtin-add.c
index 5c29cc2..b5b4c2f 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -196,6 +196,13 @@ int cmd_add(int argc, const char **argv, const char *prefix)
 	const char **pathspec;
 	struct dir_struct dir;
 
+	if (argc > 1 && !strcmp(argv[1], "remote") &&
+			access("remote", F_OK)) {
+		argv[1] = argv[0];
+		argv[0] = "remote";
+		return cmd_remote(argc, argv, prefix);
+	}
+
 	argc = parse_options(argc, argv, builtin_add_options,
 			  builtin_add_usage, 0);
 	if (patch_interactive)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 2376e0a..83ed70c 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -147,4 +147,10 @@ test_expect_success 'add --mirror && prune' '
 	 git rev-parse --verify refs/heads/side)
 '
 
+test_expect_success 'add remote' '
+	(cd test &&
+	 git add remote -f another-one ../one &&
+	 git diff master remotes/another-one/master)
+'
+
 test_done
-- 
1.5.3.7.2157.g9598e

[PATCH 1/6] path-list: add functions to work with unsorted lists

[Johannes Schindelin]

Up to now, path-lists were sorted at all times.  But sometimes it
is much more convenient to build the list and sort it at the end,
or sort it not at all.

Add path_list_append() and sort_path_list() to allow that.

Also, add the unsorted_path_list_has_path() function, to do a linear
search.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	I should have done that long ago.

 path-list.c |   30 ++++++++++++++++++++++++++++++
 path-list.h |    8 +++++++-
 2 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/path-list.c b/path-list.c
index 3d83b7b..92e5cf2 100644
--- a/path-list.c
+++ b/path-list.c
@@ -102,3 +102,33 @@ void print_path_list(const char *text, const struct path_list *p)
 	for (i = 0; i < p->nr; i++)
 		printf("%s:%p\n", p->items[i].path, p->items[i].util);
 }
+
+struct path_list_item *path_list_append(const char *path, struct path_list *list)
+{
+	ALLOC_GROW(list->items, list->nr + 1, list->alloc);
+	list->items[list->nr].path =
+		list->strdup_paths ? xstrdup(path) : (char *)path;
+	return list->items + list->nr++;
+}
+
+static int cmp_items(const void *a, const void *b)
+{
+	const struct path_list_item *one = a;
+	const struct path_list_item *two = b;
+	return strcmp(one->path, two->path);
+}
+
+void sort_path_list(struct path_list *list)
+{
+	qsort(list->items, list->nr, sizeof(*list->items), cmp_items);
+}
+
+int unsorted_path_list_has_path(struct path_list *list, const char *path)
+{
+	int i;
+	for (i = 0; i < list->nr; i++)
+		if (!strcmp(path, list->items[i].path))
+			return 1;
+	return 0;
+}
+
diff --git a/path-list.h b/path-list.h
index 5931e2c..ca2cbba 100644
--- a/path-list.h
+++ b/path-list.h
@@ -13,10 +13,16 @@ struct path_list
 };
 
 void print_path_list(const char *text, const struct path_list *p);
+void path_list_clear(struct path_list *list, int free_util);
 
+/* Use these functions only on sorted lists: */
 int path_list_has_path(const struct path_list *list, const char *path);
-void path_list_clear(struct path_list *list, int free_util);
 struct path_list_item *path_list_insert(const char *path, struct path_list *list);
 struct path_list_item *path_list_lookup(const char *path, struct path_list *list);
 
+/* Use these functions only on unsorted lists: */
+struct path_list_item *path_list_append(const char *path, struct path_list *list);
+void sort_path_list(struct path_list *list);
+int unsorted_path_list_has_path(struct path_list *list, const char *path);
+
 #endif /* PATH_LIST_H */
-- 
1.5.3.7.2157.g9598e

Re: [PATCH 6/6] DWIM "git add remote ..."

[Linus Torvalds]

On Wed, 5 Dec 2007, Johannes Schindelin wrote:
> 
> It is wrong to divert to "git remote add" when you typed the
> (more English) "git add remote".  But is it also pretty convenient.

Please don't do cute things like this. Suddenly "git add remote" has two 
different meanings depending on whether you have a file called "remote" or 
not. That is *not* ok.

Not to mention the fact that your patch is also a horrible piece of 
bug-infested shit, to put it less-than-politely. Namely, you now broke 
"git add remote" when "remote" is a symbolic link pointing to hyperspace.

But even if you fix that bug, it only goes to show just how misguided 
things like these are. It's a *lot* more important to make sense and not 
have surprising special cases, than to try to make git command lines act 
as if they were free-form English.

		Linus

Re: [PATCH 6/6] DWIM "git add remote ..."

[Johannes Schindelin]

Hi,

On Wed, 5 Dec 2007, Linus Torvalds wrote:

> On Wed, 5 Dec 2007, Johannes Schindelin wrote:
> > 
> > It is wrong to divert to "git remote add" when you typed the (more 
> > English) "git add remote".  But is it also pretty convenient.
> 
> Please don't do cute things like this. Suddenly "git add remote" has two 
> different meanings depending on whether you have a file called "remote" 
> or not. That is *not* ok.
> 
> Not to mention the fact that your patch is also a horrible piece of 
> bug-infested shit, to put it less-than-politely. Namely, you now broke 
> "git add remote" when "remote" is a symbolic link pointing to 
> hyperspace.
> 
> But even if you fix that bug, it only goes to show just how misguided 
> things like these are. It's a *lot* more important to make sense and not 
> have surprising special cases, than to try to make git command lines act 
> as if they were free-form English.

Hehe.  You're right, of course.  But I could not resist showing off that 
patch which I wrote after I mixed up the command line of "remote add" for 
the 926th time.

Ciao,
Dscho

[PATCH 7/6] builtin-remote: guard remote->url accesses by remote->url_nr check

[Johannes Schindelin]

struct remote's url member is not a NULL terminated list.  Instead, we
have to check url_nr before accessing it.

Noticed by Johannes Sixt.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	For your viewing pleasure, this is not a resend, but an amend.  
	Feel free to squash with 4/6, or to bug me to do it.

 builtin-remote.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/builtin-remote.c b/builtin-remote.c
index 142eb97..ea323e2 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -356,7 +356,8 @@ static int show_or_prune(int argc, const char **argv, int prune)
 		states.remote = remote_get(*argv);
 		if (!states.remote)
 			return error("No such remote: %s", *argv);
-		transport = transport_get(NULL, states.remote->url[0]);
+		transport = transport_get(NULL, states.remote->url_nr > 0 ?
+			states.remote->url[0] : NULL);
 		ref = transport_get_remote_refs(transport);
 
 		read_branches();
@@ -391,7 +392,7 @@ static int show_or_prune(int argc, const char **argv, int prune)
 		}
 
 		printf("* remote %s\n  URL: %s\n", *argv,
-			states.remote->url[0] ?
+			states.remote->url_nr > 0 ?
 				states.remote->url[0] : "(no URL)");
 
 		for (i = 0; i < branch_list.nr; i++) {
@@ -468,8 +469,9 @@ static int get_one_entry(struct remote *remote, void *priv)
 {
 	struct path_list *list = priv;
 
-	path_list_append(remote->name, list)->util = (void *)remote->url[0];
-	if (remote->url[0] && remote->url[1])
+	path_list_append(remote->name, list)->util = remote->url_nr ?
+		(void *)remote->url[0] : NULL;
+	if (remote->url_nr > 1)
 		warning ("Remote %s has more than one URL", remote->name);
 
 	return 0;
-- 
1.5.3.7.2157.g9598e

Re: [PATCH 3/6] Test "git remote show" and "git remote prune"

[René Scharfe]

Johannes Schindelin schrieb:
> While at it, also fix a few instances where a cd was done outside of a
> subshell.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  t/t5505-remote.sh |   34 ++++++++++++++++++++++++++++++++++
>  1 files changed, 34 insertions(+), 0 deletions(-)

It seems to me the patch only adds tests, but doesn't fix existing ones.
 And looking at t5505-remote.sh, every call of cd is already done inside
of a subshell, so there doesn't seem to be anything to fix either. :-?

Re: [PATCH 3/6] Test "git remote show" and "git remote prune"

[Johannes Schindelin]

Hi,

On Wed, 5 Dec 2007, Ren? Scharfe wrote:

> Johannes Schindelin schrieb:
> > While at it, also fix a few instances where a cd was done outside of a 
> > subshell.
> > 
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  t/t5505-remote.sh |   34 ++++++++++++++++++++++++++++++++++
> >  1 files changed, 34 insertions(+), 0 deletions(-)
> 
> It seems to me the patch only adds tests, but doesn't fix existing ones. 
> And looking at t5505-remote.sh, every call of cd is already done inside 
> of a subshell, so there doesn't seem to be anything to fix either. :-?

Right.  This comment is from a long time ago, back when I had my own 
(incomplete) t5505-remote.sh.  It was funny to me that Junio chose exactly 
the same name... but his implementation was different ;-)

I agree that this comment is obsolete.

Thanks,
Dscho

Re: your mail

[Aneesh Kumar K.V]

On Wed, Aug 13, 2008 at 08:24:28PM +0530, aneesh.kumar@gmail.com wrote:
> From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> topgit: Implement tg-import
> 
> This can be used to import a set of commits
> between range specified by range1..range2
> This should help us to convert an already
> existing quilt, stgit branches to topgit
> managed one
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> ---
>  Makefile     |    2 +-
>  README       |    7 ++++++
>  tg-create.sh |   22 ++++++++----------
>  tg-export.sh |    2 +-
>  tg-import.sh |   68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 87 insertions(+), 14 deletions(-)
> 

tg-create.sh and tg-export.sh should not be part of this patch. I will
send a new version.

-aneesh

Re: your mail

[Marcus Karlsson]

On Sun, May 06, 2012 at 10:17:07PM +0800, Bruce Zu wrote:
> I want subscribe this git mail list
> thanks!
> Bruce Zu

Great idea. The instructions for how to subscribe can be found on
http://vger.kernel.org/. Then subscribe to the list named 'git'.

	Marcus

Re: your mail

[Magnus Bäck]

On Friday, May 17, 2013 at 14:02 EDT,
     ASHISH VERMA <ashunew1989@gmail.com> wrote:

> Hi,  i am using git to push my code from eclipse to heroku , but
> recently iam  getting error like::
> 
> master:master rejected:non fast forward
> 
> and i am not able to resolve it .I tried a git pull but that says -
> conflicts shud be resolved before git pull can be implemented.I can;t
> find the solution Please help ASAP...

Resolve the conflicts by either hand-editing the files (you'll see the
markers where the conflicts are) add running 'git add' to tell git that
you're done resolving them, or set up Git to use a graphical tool like
kdiff3. When you're done, run 'git commit' to create the merge commit.
After that you'll be able to push to your upstream (unless things have
moved again while you were resolving the initial conflict).

This guide to merge conflicts looks pretty good:
http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool/

-- 
Magnus Bäck
baeck@google.com

Re: your mail

[Jeff King]

On Mon, Apr 11, 2016 at 07:04:23PM +0000, miwilliams@google.com wrote:

> From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
> From: Mike Williams <miwilliams@google.com>
> Date: Mon, 11 Apr 2016 14:18:39 -0400
> Subject: [PATCH 1/1] wt-status: Remove '!!' from
> wt_status_collect_changed_cb

These bits (minus the initial "From ..." line) should go into your
actual email headers. As it is, your email has no subject line.

> The wt_status_collect_changed_cb function uses an extraneous double
> negation (!!) when determining whether or not a submodule has new
> commits.
> [...]
> -			d->new_submodule_commits = !!hashcmp(p->one->sha1, p->two->sha1);
> +			d->new_submodule_commits = hashcmp(p->one->sha1, p->two->sha1);

It's not extraneous. hashcmp() returns 0 for equality, but an arbitrary
positive or negative value depending on how the two arguments differ.
The assigned "new_submodule_commits" is a bitfield of size 1. So the
"!!" is normalizing the value into "0" or "1".

-Peff

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 11:50:01AM +0200, Jessie Hernandez wrote:
> subscribe git

You need to write to majordomo@vger.kernel.org (with subscribe
git in the body) to subscribe.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 01:35:33PM +0000, Patrick Lehmann wrote:
> But how can he write to the mailing list without a subscription?
> Is this a security bug or is he already subscribed?

Everybody can send to this mailing list. This is by design so
contributors/bug reporters can send mails without having to
subscribe.

Regards
Simon
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
> The description on https://github.com/git/git doesn't reflect that policy.
>
> a)
> It explains that discussions take place in the mentioned mailing list.
> b)
> It describes how to subscribe.

However it doesn't say that you have to subscribe to send, only
how to subscribe.

> With knowledge of other mailing lists (mostly managed by mailman),
> subscription is required for participation.

That depends on the mailing list, some require subscription to
prevent spams but not all do.

Somebody might want to update the documentation, but personally
I see no reason to change anything. If you want to send a patch
to improve it, that would be great of course.

Regards
Simon

PS: Please don't top-post on this mailing list.
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

Re: your mail

[Junio C Hamano]

Simon Ruderich <simon@ruderich.org> writes:

> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>> The description on https://github.com/git/git doesn't reflect that policy.
>>
>> a)
>> It explains that discussions take place in the mentioned mailing list.
>> b)
>> It describes how to subscribe.
>
> However it doesn't say that you have to subscribe to send, only
> how to subscribe.

For that matter, we also say "everyone is welcome to post", which
makes it clear that no subscription is required.

But I view these merely being technically correct.  And making it
absolutely obvious does not cost too much.

>> With knowledge of other mailing lists (mostly managed by mailman),
>> subscription is required for participation.
>
> That depends on the mailing list, some require subscription to
> prevent spams but not all do.

Yes.  But not many people realize that the world they know is the
only world.  We are used to an open list and are shocked when we
encouter a closed one; let's not forget that shock.

How about doing it like this?

 README.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/README.md b/README.md
index f17af66a97..bbaf54bffb 100644
--- a/README.md
+++ b/README.md
@@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
 mailing list -- everyone is welcome to post bug reports, feature
 requests, comments and patches to git@vger.kernel.org (read
 [Documentation/SubmittingPatches][] for instructions on patch submission).
+
+You can send messages without subscribing to the list, but it is 
+recommended to read what other people are saying on the list before
+you speak.
 To subscribe to the list, send an email with just "subscribe git" in
 the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,

Re: your mail

[Ævar Arnfjörð Bjarmason]

On Thu, Jun 22 2017, Junio C. Hamano jotted:

> Simon Ruderich <simon@ruderich.org> writes:
>
>> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>>> The description on https://github.com/git/git doesn't reflect that policy.
>>>
>>> a)
>>> It explains that discussions take place in the mentioned mailing list.
>>> b)
>>> It describes how to subscribe.
>>
>> However it doesn't say that you have to subscribe to send, only
>> how to subscribe.
>
> For that matter, we also say "everyone is welcome to post", which
> makes it clear that no subscription is required.
>
> But I view these merely being technically correct.  And making it
> absolutely obvious does not cost too much.
>
>>> With knowledge of other mailing lists (mostly managed by mailman),
>>> subscription is required for participation.
>>
>> That depends on the mailing list, some require subscription to
>> prevent spams but not all do.
>
> Yes.  But not many people realize that the world they know is the
> only world.  We are used to an open list and are shocked when we
> encouter a closed one; let's not forget that shock.
>
> How about doing it like this?
>
>  README.md | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/README.md b/README.md
> index f17af66a97..bbaf54bffb 100644
> --- a/README.md
> +++ b/README.md
> @@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
>  mailing list -- everyone is welcome to post bug reports, feature
>  requests, comments and patches to git@vger.kernel.org (read
>  [Documentation/SubmittingPatches][] for instructions on patch submission).
> +
> +You can send messages without subscribing to the list, but it is
> +recommended to read what other people are saying on the list before
> +you speak.
>  To subscribe to the list, send an email with just "subscribe git" in
>  the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,

It's unclear what that means. I *think* it means "consider taking a look
around the list before you post", but then it's probably better advice
to tell people to skim the archives first to get an idea of the traffic.

E.g. if I page through the first 2 pages of public-inbox.org I get
messages going back to the 19th, but if I were to subscribe to the list
I'd need to wait 4 days to get the same mail.

Which, in the context of what this follows (how to submit a bug,
questions etc.) isn't a good use of time for the person reading the
instructions.

Maybe something more like:

diff --git a/README.md b/README.md
index f17af66a97..dc175757fa 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,
 <http://marc.info/?l=git> and other archival sites.

+You don't need to be subscribed to the list to send mail to it, and
+others on-list will generally CC you when replying (although some
+forget this). It's adviced to subscribe to the list if you want to be
+sure you're not missing follow-up discussion, or if your interest in
+the project is wider than a one-off bug report, question or patch.
+
 The maintainer frequently sends the "What's cooking" reports that
 list the current status of various development topics to the mailing
 list.  The discussion following them give a good reference for

Re: your mail

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Maybe something more like:

Much better.

> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
>
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

Re: your mail

[Jeff King]

On Thu, Jun 22, 2017 at 11:58:08PM +0200, Ævar Arnfjörð Bjarmason wrote:

> Which, in the context of what this follows (how to submit a bug,
> questions etc.) isn't a good use of time for the person reading the
> instructions.
> 
> Maybe something more like:
> 
> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
> 
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

You perhaps already read it, but you may want to steal wording or
suggestions from the mailing list section at:

  https://git-scm.com/community

which is covering the same ideas (and vice versa, patches to that page
are welcome if the README says something better).

-Peff

Re: your mail

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> +You don't need to be subscribed to the list to send mail to it, and
>> +others on-list will generally CC you when replying (although some
>> +forget this). It's adviced to subscribe to the list if you want to be
>> +sure you're not missing follow-up discussion, or if your interest in
>> +the project is wider than a one-off bug report, question or patch.
>> +
>>  The maintainer frequently sends the "What's cooking" reports that
>>  list the current status of various development topics to the mailing
>>  list.  The discussion following them give a good reference for
>
> You perhaps already read it, but you may want to steal wording or
> suggestions from the mailing list section at:
>
>   https://git-scm.com/community
>
> which is covering the same ideas (and vice versa, patches to that page
> are welcome if the README says something better).

OK, so... Ævar's version does not mention:

 - text/plain, which is a very good addition.

 - note about CC in a way as useful as the "community" page does,
   which may want to steal from the latter.

 - the archive, but it may not be needed in the context of this
   document.  "Read the archive to make sure you are not repeating
   somebody else said before speaking" is something we silently wish
   everybody to follow, but it is something we do not want to say
   out loud, especially to new people.

 - Windows, but I am not sure if it is necessary or even healthy.
   One thing I would rather not to see is the Windows mailing list
   becomes the first line triage place for any and all issues that
   were experienced by a user who happened to be using Windows, and
   majority of the issues turn out to be unspecific to Windows.  I'd
   suspect that all of us rather would want to see the referral go
   the other way around.

Otoh, "community" page does not encourage subscription as a way to
ensure you'll see follow-up discussion, which may be a good thing to
add.

A tangent I just found funny is this paragraph on the "community"
page:

    The archive can be found on public-inbox. Click here to
    subscribe.

Of course clicking does not take you to a subscription page for
public-inbox, even though the two sentences appear to be related.

Perhaps swap the order of the two, like so, with a bit richer
explanation taken from Ævar's version:

	... disable HTML in your outgoing messages.

	By subscribing (click here), you can make sure you're not
	missing follow-up discussion and also learn from other
	development in the community.  The list archive can be found
	on public-inbox.

Re: your mail

[demerphq]

On 22 June 2017 at 23:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be

FWIW: "adviced" is misspelled, it should be "advised", and IMO, it
feels like poor style to begin a sentence with a contraction. Not
strictly wrong, but sufficiently informal that I think it is out of
place in docs like this. Better to just say "It is", or even just "You
are", especially as you use "you" later in the sentence.

I actually think simplifying that sentence considerably is preferable:

"To be sure you receive all follow-up mails you should subscribe to the list."

flows better and is more succinct than

"It's advised to subscribe to the list if you want to be sure you're
not missing follow-up discussion".

> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.

cheers,
yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: your mail

[Jeff King]

On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:

> Otoh, "community" page does not encourage subscription as a way to
> ensure you'll see follow-up discussion, which may be a good thing to
> add.
> 
> A tangent I just found funny is this paragraph on the "community"
> page:
> 
>     The archive can be found on public-inbox. Click here to
>     subscribe.
> 
> Of course clicking does not take you to a subscription page for
> public-inbox, even though the two sentences appear to be related.
> 
> Perhaps swap the order of the two, like so, with a bit richer
> explanation taken from Ævar's version:
> 
> 	... disable HTML in your outgoing messages.
> 
> 	By subscribing (click here), you can make sure you're not
> 	missing follow-up discussion and also learn from other
> 	development in the community.  The list archive can be found
> 	on public-inbox.

Yeah, I think that's a good suggestion. Do you want to phrase it in the
form of a patch? :)

-Peff

Re: your mail

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:
>
>> Otoh, "community" page does not encourage subscription as a way to
>> ensure you'll see follow-up discussion, which may be a good thing to
>> add.
>> 
>> A tangent I just found funny is this paragraph on the "community"
>> page:
>> 
>>     The archive can be found on public-inbox. Click here to
>>     subscribe.
>> 
>> Of course clicking does not take you to a subscription page for
>> public-inbox, even though the two sentences appear to be related.
>> 
>> Perhaps swap the order of the two, like so, with a bit richer
>> explanation taken from Ævar's version:
>> 
>> 	... disable HTML in your outgoing messages.
>> 
>> 	By subscribing (click here), you can make sure you're not
>> 	missing follow-up discussion and also learn from other
>> 	development in the community.  The list archive can be found
>> 	on public-inbox.
>
> Yeah, I think that's a good suggestion. Do you want to phrase it in the
> form of a patch? :)

OK. Letme try.

Re: your mail

[Kevin Daudt]

On Fri, Jan 25, 2019 at 12:47:35PM +0300, Furkan DURUL wrote:
> Hello,
> My name is Furkan. I'm a new graduated Electronics and Communication
> Engineer in Turkey. In my current workplace, we use Git in all our
> projects and I really learned a lot from your Pro Git Book. I would
> like to contribute to translation of this book to Turkish. I'm also a
> freelance translator and have experience about translation.
> Look forward to hear you
> Cheers

Hello Furkan,

Welcome to the community. Pro Git is not maintained by the git
community, but is a separate project.

You can find details on how to provide translations here[0]. It looks
from that document that someone started translating the book in Turkish
as well[1].

Kind regards, Kevin


[0]:https://github.com/progit/progit2/blob/master/TRANSLATING.md
[1]:https://github.com/progit/progit2-tr

Re: your mail

[Kevin Daudt]

On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> subscribe git

You need to send this to majordomo@vger.kernel.org. Sending it to the
git mailing list will not do a lot.

Kevin

Re: your mail

[Robert Morgan]

Apologies list!  Thanks Kevin.  That's what I get for troubleshooting
plain-text in Gmail and quickly sending a subscribe email before
walking out.

Robert


On Thu, Jul 11, 2019 at 3:18 PM Kevin Daudt <me@ikke.info> wrote:
>
> On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> > subscribe git
>
> You need to send this to majordomo@vger.kernel.org. Sending it to the
> git mailing list will not do a lot.
>
> Kevin

Re: your mail

[Taylor Blau]

Hi Han-Wen,


On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> Hey folks,
>
> I spent the last few weeks cobbling together an implementation of the
> reftable format in C and in Go. I thought this would be cool to add to
> git-core, but I doubt whether I will have enough time to see such an
> effort through. Maybe some of you would want to try integrating it
> into the Git-core code base?  Example code is here:
>
>   https://github.com/google/reftable/blob/master/c/api.h#L153

Very exciting, and thanks for your work on this. I haven't taken a
close look at the code yet, so I'm sure taking this further involves a
much more careful examination.

I know that Christian Couder (who you CC-d on this thread) was also
working on this for either GitLab or Booking.com.

Christian -- are you still working on this for either one of those
entities? If so, is there some way to unify these two efforts?

> cheers!
> --

Thanks,
Taylor

Re: your mail

[Christian Couder]

Hi Taylor and Han-Wen,

On Wed, Nov 20, 2019 at 6:30 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> >
> > I spent the last few weeks cobbling together an implementation of the
> > reftable format in C and in Go. I thought this would be cool to add to
> > git-core, but I doubt whether I will have enough time to see such an
> > effort through. Maybe some of you would want to try integrating it
> > into the Git-core code base?  Example code is here:
> >
> >   https://github.com/google/reftable/blob/master/c/api.h#L153

Interesting!

> Very exciting, and thanks for your work on this. I haven't taken a
> close look at the code yet, so I'm sure taking this further involves a
> much more careful examination.
>
> I know that Christian Couder (who you CC-d on this thread) was also
> working on this for either GitLab or Booking.com.
>
> Christian -- are you still working on this for either one of those
> entities? If so, is there some way to unify these two efforts?

Yeah, I started working on this last year for Booking.com, and I am
now slowly working on it for GitLab. It is not yet finished because it
has been low priority work.

I took a very quick look at Han-Wen's implementation and it looks very
different from mine from the outside. It seems more complete, but
might be less integrated into the Git code base.

Best,
Christian.

Re: your mail

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]

On 2020-06-24 at 00:38:39, shejan shuza wrote:
> Hi, I have a repository with about 55GB of contents, with binary files
> that are less than 100MB each (so no LFS mode) from a project which
> has almost filled up an entire hard drive. I am trying to add all of
> the contents to a git repo and push it to GitHub but every time I do
> 
> git add .
> 
> in the folder with my contents after initializing and setting my
> remote, git starts caching all the files to .git/objects, making the
> .git folder grow in size rapidly. All the files are binaries, so git
> cannot stage changes between versions anyway, so there is no reason to
> cache versions.

What you're experiencing is normal; storing files in the .git directory
is how Git keeps track of them.  It can't rely on the copies in your
working tree because you can modify those files at any time, and if you
did so, relying on them would corrupt the repository.

Also, note that Git can and does deltify changes between revisions once
the data is packed, regardless of whether the file is binary, but how
well it does so depends on your data.  For example, if it's compressed,
it likely doesn't deltify very well, so storing things like compressed
images or zip files using deflate is generally going to result in a
bloated repository.

However, if you don't need versioning for these files, then you don't
need a Git repository.  Git is a tool for versioning files, not a
general storage mechanism.  You may find a cloud storage bucket or some
other artifact storage service may meet your needs better.

I will also tell you from a practical point of view that almost nobody
(including you) will want to host a 55 GB repository filled with binary
blobs.  Usually repacking these repositories is very expensive,
requiring extensive CPU and memory usage for a prolonged time for little
useful benefit.

> Is there any way, such as editing the git attributes or changing
> something about how files are staged in the git repository, to only
> just add indexes or references to files in the repository rather than
> cache them into the .git folder, while also being able to push all the
> data to GitHub?

This is how Git LFS and similar tools, like git-annex, work.  Git LFS
will create copies of the objects in your .git directory though, at
least until they're pushed to the server, at which point they can be
pruned.  Git LFS has the same limitation as Git here.  I'm less familiar
with git-annex, but it is also a popular choice.

However, as mentioned, it sounds like you don't need versioning at all,
so unless you do, Git with Git LFS will be no more suitable for this
than plain Git.  If that's the case, I encourage you to explore
alternate solutions.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]