Git development
 help / color / mirror / Atom feed
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-29  8:54 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git
In-Reply-To: <20050729081051.GH24895@pasky.ji.cz>

Petr Baudis <pasky@suse.cz> writes:

> Exactly. I want much more freedom in pushing, the only requirement being
> that "the to-be-replaced remote head is ancestor of the to-be-pushed
> local head". I think (am I wrong?) git-send-pack localhead:remotehead
> would work just fine for me, the only thing I need is the support for
> different local and remote head names.

Now I see where you are coming from; I tend to agree why you
might want to have different names on the remote end.  I however
still suspect that you might be spreading chaos under the name
of more flexibility.  The fact that you can push into it by
definition means you have some control over the other end, and
obviously you are in total control on your end.  I do not see
why you cannot rename branches where needed so that whatever you
are pushing match.  That would also be one less thing to keep
track of for yourself [*1*].

Yes, I am aware that you brought up the example of pushing to
two separate places, but does it happen in practice that you can
push to two places, and at the same time neither of them
cooperates with you to make it easier for you to work on these
three machines by having the same head names?

Having said that, I do not particulary think allowing push to
write into different ref is an unreasonable thing.  As you
pointed out long time ago when send-pack was first done, the
protocol is not so easily extensible, so this may require either
backward incompatible protocol change, or introduction of a new
program pair send-pack-2 / receive-pack-2.  I'll take a look
sometime this weekend.  Bedtime.


[Footnote]

*1* In a hypothetical situation ``I use branch "b00" in this
repository to do XYZ work but I use branch "b24" in the other
repository for the same XYZ work'', Porcelain can keep track of
mapping between b00:b24 for you, but you still need to keep
track of b00:XYZ and b24:XYZ mapping in your head.

^ permalink raw reply
* [PATCH 0/2] Bits from git-pb
From: Petr Baudis @ 2005-07-29  8:58 UTC (permalink / raw)
  To: junkio; +Cc: git

  Hi,

  those two bits were long kept local to git-pb. You can either apply
the patches or pull:

	www.kernel.org/pub/scm/cogito/git-pb.git

The bits are mostly cosmetic but I want to get rid of them. :-)

  I'd like to know what to do with the git-pb branch in the future.
Based on what do you think, I can either:

  (i) Keep the git-pb branch polished and nice-to-merge, if you want to
pull from it.

  (ii) Keep the git-pb branch polished and nice-to-merge and rebase it
regularily if you don't want loong edges in your history graph, but
want to pull from it.

  (ii) Do wild things in the git-pb branch and send you patches.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

^ permalink raw reply
* [PATCH 1/2] Trivial tidyups
From: Petr Baudis @ 2005-07-29  9:00 UTC (permalink / raw)
  To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>

Simple whitespace-related tidyups ensuring style consistency.

This is carried over from my old git-pb branch.

Signed-off-by: Petr Baudis <pasky@ucw.cz>

---
commit 83b1762040b111b4736d108cd91b8a9d75aad3a9
tree e07192546e9bd6a972e3945dd941fc7a29ec1a4b
parent d854f783af2a441827d66b4b70e9d0d9e3434b15
author Petr Baudis <pasky@suse.cz> Sat, 23 Jul 2005 00:21:48 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Sat, 23 Jul 2005 00:21:48 +0200

 Documentation/git-write-tree.txt |    3 +--
 git-merge-one-file-script        |    7 +++----
 write-tree.c                     |    4 ++--
 3 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/Documentation/git-write-tree.txt b/Documentation/git-write-tree.txt
--- a/Documentation/git-write-tree.txt
+++ b/Documentation/git-write-tree.txt
@@ -9,8 +9,7 @@ git-write-tree - Creates a tree from the
 
 SYNOPSIS
 --------
-'git-write-tree'
-		[--missing-ok]
+'git-write-tree' [--missing-ok]
 
 DESCRIPTION
 -----------
diff --git a/git-merge-one-file-script b/git-merge-one-file-script
--- a/git-merge-one-file-script
+++ b/git-merge-one-file-script
@@ -22,11 +22,10 @@ case "${1:-.}${2:-.}${3:-.}" in
 #
 "$1.." | "$1.$1" | "$1$1.")
 	echo "Removing $4"
-	if test -f "$4"
-	then
+	if test -f "$4"; then
 		rm -f -- "$4"
 	fi &&
-	exec git-update-cache --remove -- "$4"
+		exec git-update-cache --remove -- "$4"
 	;;
 
 #
@@ -62,7 +61,7 @@ case "${1:-.}${2:-.}${3:-.}" in
 
 	# We reset the index to the first branch, making
 	# git-diff-file useful
-	git-update-cache --add --cacheinfo "$6" "$2" "$4" 
+	git-update-cache --add --cacheinfo "$6" "$2" "$4"
 		git-checkout-cache -u -f -- "$4" &&
 		merge "$4" "$orig" "$src2"
 	ret=$?
diff --git a/write-tree.c b/write-tree.c
--- a/write-tree.c
+++ b/write-tree.c
@@ -89,14 +89,14 @@ int main(int argc, char **argv)
 	int entries = read_cache();
 	unsigned char sha1[20];
 	
-	if (argc==2) {
+	if (argc == 2) {
 		if (!strcmp(argv[1], "--missing-ok"))
 			missing_ok = 1;
 		else
 			die("unknown option %s", argv[1]);
 	}
 	
-	if (argc>2)
+	if (argc > 2)
 		die("too many options");
 
 	if (entries < 0)

^ permalink raw reply
* [PATCH 2/2] Unify usage strings declaration
From: Petr Baudis @ 2005-07-29  9:01 UTC (permalink / raw)
  To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>

All usage strings are now declared as static const char [].

This is carried over from my old git-pb branch.

Signed-off-by: Petr Baudis <pasky@ucw.cz>

---
commit 1e02de8f49a8fca696b3cb363545fad3c98fd662
tree feee1ccdea90d33fae2bf41621a876c5aa2ecfe5
parent 83b1762040b111b4736d108cd91b8a9d75aad3a9
author Petr Baudis <pasky@suse.cz> Sat, 23 Jul 2005 00:30:06 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Sat, 23 Jul 2005 00:30:06 +0200

 checkout-cache.c |    2 +-
 commit-tree.c    |    2 +-
 diff-cache.c     |    2 +-
 diff-files.c     |    2 +-
 diff-helper.c    |    2 +-
 diff-stages.c    |    2 +-
 diff-tree.c      |    2 +-
 hash-object.c    |    2 +-
 local-pull.c     |    2 +-
 ls-files.c       |    2 +-
 ls-tree.c        |    2 +-
 read-tree.c      |    2 +-
 ssh-push.c       |    2 +-
 tar-tree.c       |    2 +-
 test-delta.c     |    2 +-
 var.c            |    2 +-
 verify-pack.c    |    2 +-
 17 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/checkout-cache.c b/checkout-cache.c
--- a/checkout-cache.c
+++ b/checkout-cache.c
@@ -75,7 +75,7 @@ static int checkout_all(void)
 	return 0;
 }
 
-static const char *checkout_cache_usage =
+static const char checkout_cache_usage[] =
 "git-checkout-cache [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] [--] <file>...";
 
 int main(int argc, char **argv)
diff --git a/commit-tree.c b/commit-tree.c
--- a/commit-tree.c
+++ b/commit-tree.c
@@ -64,7 +64,7 @@ static void check_valid(unsigned char *s
 #define MAXPARENT (16)
 static unsigned char parent_sha1[MAXPARENT][20];
 
-static char *commit_tree_usage = "git-commit-tree <sha1> [-p <sha1>]* < changelog";
+static const char commit_tree_usage[] = "git-commit-tree <sha1> [-p <sha1>]* < changelog";
 
 static int new_parent(int idx)
 {
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -163,7 +163,7 @@ static void mark_merge_entries(void)
 	}
 }
 
-static char *diff_cache_usage =
+static const char diff_cache_usage[] =
 "git-diff-cache [-m] [--cached] "
 "[<common diff options>] <tree-ish> [<path>...]"
 COMMON_DIFF_OPTIONS_HELP;
diff --git a/diff-files.c b/diff-files.c
--- a/diff-files.c
+++ b/diff-files.c
@@ -6,7 +6,7 @@
 #include "cache.h"
 #include "diff.h"
 
-static const char *diff_files_usage =
+static const char diff_files_usage[] =
 "git-diff-files [-q] "
 "[<common diff options>] [<path>...]"
 COMMON_DIFF_OPTIONS_HELP;
diff --git a/diff-helper.c b/diff-helper.c
--- a/diff-helper.c
+++ b/diff-helper.c
@@ -20,7 +20,7 @@ static void flush_them(int ac, const cha
 	diff_flush(DIFF_FORMAT_PATCH, '\n');
 }
 
-static const char *diff_helper_usage =
+static const char diff_helper_usage[] =
 "git-diff-helper [-z] [-O<orderfile>] [-S<string>] [--pickaxe-all] [<path>...]";
 
 int main(int ac, const char **av) {
diff --git a/diff-stages.c b/diff-stages.c
--- a/diff-stages.c
+++ b/diff-stages.c
@@ -17,7 +17,7 @@ static int diff_break_opt = -1;
 static const char *orderfile = NULL;
 static const char *diff_filter = NULL;
 
-static char *diff_stages_usage =
+static const char diff_stages_usage[] =
 "git-diff-stages [<common diff options>] <stage1> <stage2> [<path>...]"
 COMMON_DIFF_OPTIONS_HELP;
 
diff --git a/diff-tree.c b/diff-tree.c
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -395,7 +395,7 @@ static int diff_tree_stdin(char *line)
 	return diff_tree_commit(commit, line);
 }
 
-static char *diff_tree_usage =
+static const char diff_tree_usage[] =
 "git-diff-tree [--stdin] [-m] [-s] [-v] [--pretty] [-t] "
 "[<common diff options>] <tree-ish> <tree-ish>"
 COMMON_DIFF_OPTIONS_HELP;
diff --git a/hash-object.c b/hash-object.c
--- a/hash-object.c
+++ b/hash-object.c
@@ -21,7 +21,7 @@ static void hash_object(const char *path
 	printf("%s\n", sha1_to_hex(sha1));
 }
 
-static const char *hash_object_usage =
+static const char hash_object_usage[] =
 "git-hash-object [-t <type>] [-w] <file>...";
 
 int main(int argc, char **argv)
diff --git a/local-pull.c b/local-pull.c
--- a/local-pull.c
+++ b/local-pull.c
@@ -101,7 +101,7 @@ int fetch_ref(char *ref, unsigned char *
 	return 0;
 }
 
-static const char *local_pull_usage = 
+static const char local_pull_usage[] =
 "git-local-pull [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [-l] [-s] [-n] commit-id path";
 
 /* 
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -285,7 +285,7 @@ static void show_files(void)
 	}
 }
 
-static const char *ls_files_usage =
+static const char ls_files_usage[] =
 	"git-ls-files [-z] [-t] (--[cached|deleted|others|stage|unmerged|killed])* "
 	"[ --ignored [--exclude=<pattern>] [--exclude-from=<file>) ]";
 
diff --git a/ls-tree.c b/ls-tree.c
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -208,7 +208,7 @@ static int list(char **path)
 	return err;
 }
 
-static const char *ls_tree_usage =
+static const char ls_tree_usage[] =
 	"git-ls-tree [-d] [-r] [-z] <tree-ish> [path...]";
 
 int main(int argc, char **argv)
diff --git a/read-tree.c b/read-tree.c
--- a/read-tree.c
+++ b/read-tree.c
@@ -510,7 +510,7 @@ static int read_cache_unmerged(void)
 	return deleted;
 }
 
-static char *read_tree_usage = "git-read-tree (<sha> | -m [-u] <sha1> [<sha2> [<sha3>]])";
+static const char read_tree_usage[] = "git-read-tree (<sha> | -m [-u] <sha1> [<sha2> [<sha3>]])";
 
 static struct cache_file cache_file;
 
diff --git a/ssh-push.c b/ssh-push.c
--- a/ssh-push.c
+++ b/ssh-push.c
@@ -96,7 +96,7 @@ static void service(int fd_in, int fd_ou
 	} while (1);
 }
 
-static const char *ssh_push_usage =
+static const char ssh_push_usage[] =
 	"git-ssh-push [-c] [-t] [-a] [-w ref] commit-id url";
 
 int main(int argc, char **argv)
diff --git a/tar-tree.c b/tar-tree.c
--- a/tar-tree.c
+++ b/tar-tree.c
@@ -17,7 +17,7 @@
 #define EXT_HEADER_PATH		1
 #define EXT_HEADER_LINKPATH	2
 
-static const char *tar_tree_usage = "git-tar-tree <key> [basedir]";
+static const char tar_tree_usage[] = "git-tar-tree <key> [basedir]";
 
 static char block[BLOCKSIZE];
 static unsigned long offset;
diff --git a/test-delta.c b/test-delta.c
--- a/test-delta.c
+++ b/test-delta.c
@@ -17,7 +17,7 @@
 #include <sys/mman.h>
 #include "delta.h"
 
-static const char *usage =
+static const char usage[] =
 	"test-delta (-d|-p) <from_file> <data_file> <out_file>";
 
 int main(int argc, char *argv[])
diff --git a/var.c b/var.c
--- a/var.c
+++ b/var.c
@@ -8,7 +8,7 @@
 #include <errno.h>
 #include <string.h>
 
-static char *var_usage = "git-var [-l | <variable>]";
+static const char var_usage[] = "git-var [-l | <variable>]";
 
 struct git_var {
 	const char *name;
diff --git a/verify-pack.c b/verify-pack.c
--- a/verify-pack.c
+++ b/verify-pack.c
@@ -27,7 +27,7 @@ static int verify_one_pack(char *arg, in
 	return verify_pack(g, verbose);
 }
 
-static const char *verify_pack_usage = "git-verify-pack [-v] <pack>...";
+static const char verify_pack_usage[] = "git-verify-pack [-v] <pack>...";
 
 int main(int ac, char **av)
 {

^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Josef Weidendorfer @ 2005-07-29  9:10 UTC (permalink / raw)
  To: git
In-Reply-To: <7vmzo6jbme.fsf@assigned-by-dhcp.cox.net>

Hi,

On Friday 29 July 2005 09:48, you wrote:
> Petr Baudis <pasky@suse.cz> writes:
> > So, what do you mean by "clone" here? And what command should I use for
> > pushing then?
...
> Now, A may happen to be on my home machine and B may happen be
> on my notebook, meaning the owner of A and B are both myself.
> But even in that case I would still work by "pulling from A"
> when I am on B, and "pulling from B" when I am on A.  In other
> words, "pulling" is the only patch flow mechanism I would use.

OK, that is your opinion and your work flow. But porcelains perhaps would like 
to allow other work flows, even if it seems confusing for you.

And I think the problem here simple is that send-pack *forces* local and 
remote head names to be the same. This is forcing policy to porcelains, but 
GIT should be only about plumbing.

Perhaps the solution is to allow more flexibility in GIT.
What about introducing an additional environment GIT_REFS_DIR?
When using send-pack, the porcelain would set this variable to a directory 
containing a 1:1 name relationship to the remote repository.

Josef

^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Timo Hirvonen @ 2005-07-29  9:12 UTC (permalink / raw)
  To: Petr Baudis; +Cc: sam, ryan, junkio, git
In-Reply-To: <20050729074614.GF24895@pasky.ji.cz>

On Fri, 29 Jul 2005 09:46:14 +0200
Petr Baudis <pasky@suse.cz> wrote:

> FWIW, I made tiny "build system" (inspired by kconfig) for smaller
> projects I work on:

Me too! :)

http://onion.dynserv.net/~timo/index.php?page=Projects/build

It also has configuration system written in bash.

-- 
http://onion.dynserv.net/~timo/

^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-29  9:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek9igfgw.fsf@assigned-by-dhcp.cox.net>

Dear diary, on Fri, Jul 29, 2005 at 10:54:07AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I however still suspect that you might be spreading chaos under the
> name of more flexibility.

I'm such a villain! ;-))

> The fact that you can push into it by definition means you have some
> control over the other end, and obviously you are in total control on
> your end.  I do not see why you cannot rename branches where needed so
> that whatever you are pushing match.  That would also be one less
> thing to keep track of for yourself [*1*].

You might get the push access rather lately in the process (this "lazy
development privileges granting" is one of the point of distributed
VCSes), at point where other people are used to pull from you and
renaming your branch locally might mean some trouble.

> Yes, I am aware that you brought up the example of pushing to
> two separate places, but does it happen in practice that you can
> push to two places, and at the same time neither of them
> cooperates with you to make it easier for you to work on these
> three machines by having the same head names?

Yes, they may have incompatible but strict head naming conventions. And
wouldn't it be easier to just have different head names rather than
forcing to increase administrative load 'n stuff?

> [Footnote]
> 
> *1* In a hypothetical situation ``I use branch "b00" in this
> repository to do XYZ work but I use branch "b24" in the other
> repository for the same XYZ work'', Porcelain can keep track of
> mapping between b00:b24 for you, but you still need to keep
> track of b00:XYZ and b24:XYZ mapping in your head.

I think 95% of the cases will be "master locally, non-master remotely".
That's not really that difficult at all.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-29  9:55 UTC (permalink / raw)
  To: Petr Baudis
  Cc: Junio C Hamano, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <20050728194748.GD24948@pasky.ji.cz>

Petr Baudis <pasky@suse.cz> wrote:
> The committer field generally identifies the committer "physically", and
> isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my
> committer field, e.g.

I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override
the defaults like username@localmachine.

The latest StGIT snapshot uses, by default, the committer's details
for the From: line when sending patches by e-mail, assuming that this
is a valid e-mail address. One can define his own e-mail template and
use a different From: line but I thought it would be simpler to
provide some defaults based on this.

If StGIT users don't like this default template, I can change it.

-- 
Catalin

^ permalink raw reply
* Re: [PATCH] support older versions of libcurl
From: Johannes Schindelin @ 2005-07-29 10:23 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll3qqrhu.fsf@assigned-by-dhcp.cox.net>

Hi,

On Thu, 28 Jul 2005, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Some newer features of libcurl are used which are not strictly necessary
> > for http-pull. Use them only if libcurl is new enough to know about them.
>
> Do you need to check against that many versions?  Especially
> cleanup and init not depending on the same version number looks
> really suspicious.

I investigated the issue using curl's CVS. The different version numbers
are easily explained: While curl_global_init is defined starting from
0x070704, CURL_GLOBAL_ALL is only defined starting from 0x070800.

> Assuming that the answer is still yes, how about doing things
> this way instead?

Looks better.

Ciao,
Dscho

^ permalink raw reply
* Re: [RFD] socklen_t needs to be defined and libssl to be linked on old Mac OS X
From: Johannes Schindelin @ 2005-07-29 10:27 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfytyqrhq.fsf@assigned-by-dhcp.cox.net>

Hi,

On Thu, 28 Jul 2005, Junio C Hamano wrote:

> I'll keep this in the proposed updates queue until somebody
> comes up with a bit cleaner solution.

Agreed. That's why I put in "RFD", not "PATCH"

> By the way, Johannes, what mailer do you use?  Many of your
> patches seem to be whitespace damaged.

Why, I use pine! The whitespace could be the consequence of a very tired
yours truly doing copy and paste. Anyway, this was not really meant as a
patch, but rather as documentation of my thoughts.

Ciao,
Dscho

^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-29 10:57 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050729094046.GO24895@pasky.ji.cz>

Hi,

On Fri, 29 Jul 2005, Petr Baudis wrote:

> You might get the push access rather lately in the process (this "lazy
> development privileges granting" is one of the point of distributed
> VCSes), at point where other people are used to pull from you and
> renaming your branch locally might mean some trouble.

I still do not get it. What is so wrong with

	git-switch-tree remotehead
	git-merge master
	git-push remoteside remotehead

which would have the further advantage of documenting what you really did
in the history.

And if you really want to be able to spread chaos in your own head, you
can do something like

	ln -s master .git/refs/heads/remotehead
	git-push remoteside remotehead

A change in the protocol is not needed IMHO, and the protocol itself
suggests that you rather use a simple setup. After all, Murphy is lurking
behind every bash script!

Ciao,
Dscho

^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v3
From: Johannes Schindelin @ 2005-07-29 10:58 UTC (permalink / raw)
  To: Ryan Anderson; +Cc: git
In-Reply-To: <20050729082941.GD32263@mythryan2.michonline.com>

I like it!

Ciao,
Dscho

^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Petr Baudis @ 2005-07-29 11:10 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: Junio C Hamano, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <tnxfytyey1j.fsf@arm.com>

Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
where Catalin Marinas <catalin.marinas@gmail.com> told me that...
> Petr Baudis <pasky@suse.cz> wrote:
> > The committer field generally identifies the committer "physically", and
> > isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my
> > committer field, e.g.
> 
> I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override
> the defaults like username@localmachine.

Yes, but IIRC only for rather special cases like recommitting older
commits, importing from other VCSes, etc.

> The latest StGIT snapshot uses, by default, the committer's details
> for the From: line when sending patches by e-mail, assuming that this
> is a valid e-mail address. One can define his own e-mail template and
> use a different From: line but I thought it would be simpler to
> provide some defaults based on this.

Why don't you rather use the GIT_AUTHOR_* variables?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

^ permalink raw reply
* Re: [PATCH] add "-f" option to git-commit-script to force commit withoutchanges
From: Johannes Schindelin @ 2005-07-29 11:06 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslxypcw6.fsf@assigned-by-dhcp.cox.net>

Hi,

On Thu, 28 Jul 2005, Junio C Hamano wrote:

> While I agree there should be a graceful way to go back to the
> original head from a failed merge situation, I do not think
> "committing the current HEAD" is the right model for the end
> user to think about it.
>
> Wouldn't using "checkout -f" to revert to the version you would
> want to go back work as expected?

I had the following situation: in a throw away tree I made some changes.
The last conflicted with a change I pulled from somewhere else into the
master, and the best solution was to revert that last change from the
throw away tree. Basically, the result of the merge was identical to
master, i.e. git-status says "nothing to commit". I wanted to document,
however, that I do not want that change from the throw away tree in my
master, even if I keep it in the throw away tree.

I am no longer sure if that was a good thing to do, maybe I should have
fixed it in the throw away tree by merging master there. Or, alternatively
git-commit could check for "nothing to commit" OR "MERGE_HEAD exists".
Dunno.

Ciao,
Dscho

^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-29 11:13 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507291254100.5849@wgmdd8.biozentrum.uni-wuerzburg.de>

Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,

Hello,

> On Fri, 29 Jul 2005, Petr Baudis wrote:
> 
> > You might get the push access rather lately in the process (this "lazy
> > development privileges granting" is one of the point of distributed
> > VCSes), at point where other people are used to pull from you and
> > renaming your branch locally might mean some trouble.
> 
> I still do not get it. What is so wrong with
> 
> 	git-switch-tree remotehead
> 	git-merge master
> 	git-push remoteside remotehead
> 
> which would have the further advantage of documenting what you really did
> in the history.

How would that document anything normal push wouldn't?

> And if you really want to be able to spread chaos in your own head, you
> can do something like
> 
> 	ln -s master .git/refs/heads/remotehead
> 	git-push remoteside remotehead

I'd argue that's much more messy and evil than pushing to heads with
different names. If you compare what you just proposed with pushing to
heads with different names, what's the advantage?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-29 12:26 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050729111304.GS24895@pasky.ji.cz>

Hi,

On Fri, 29 Jul 2005, Petr Baudis wrote:

> Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
>
> > 	git-switch-tree remotehead
> > 	git-merge master
> > 	git-push remoteside remotehead
> >
> > which would have the further advantage of documenting what you really did
> > in the history.
>
> How would that document anything normal push wouldn't?

git-merge?

> > And if you really want to be able to spread chaos in your own head, you
> > can do something like
> >
> > 	ln -s master .git/refs/heads/remotehead
> > 	git-push remoteside remotehead
>
> I'd argue that's much more messy and evil than pushing to heads with
> different names. If you compare what you just proposed with pushing to
> heads with different names, what's the advantage?

It makes it hard. It tells you to be real careful here. It tells you that
you are not babysitted from here on.

Ciao,
Dscho

^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-29 12:28 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507291424070.6247@wgmdd8.biozentrum.uni-wuerzburg.de>

Dear diary, on Fri, Jul 29, 2005 at 02:26:51PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,
> 
> On Fri, 29 Jul 2005, Petr Baudis wrote:
> 
> > Dear diary, on Fri, Jul 29, 2005 at 12:57:50PM CEST, I got a letter
> > where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> >
> > > 	git-switch-tree remotehead
> > > 	git-merge master
> > > 	git-push remoteside remotehead
> > >
> > > which would have the further advantage of documenting what you really did
> > > in the history.
> >
> > How would that document anything normal push wouldn't?
> 
> git-merge?

You have to git-merge anyway if remote head is not your ancestor yet,
otherwise the push cannot proceed.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

^ permalink raw reply
* Re: [PATCH 1/1] Tell vim the textwidth is 75.
From: Catalin Marinas @ 2005-07-29 12:34 UTC (permalink / raw)
  To: Petr Baudis
  Cc: Junio C Hamano, Linus Torvalds, git, Bryan larsen, Sam Ravnborg
In-Reply-To: <20050729111056.GR24895@pasky.ji.cz>

Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
> where Catalin Marinas <catalin.marinas@gmail.com> told me that...
>> The latest StGIT snapshot uses, by default, the committer's details
>> for the From: line when sending patches by e-mail, assuming that this
>> is a valid e-mail address. One can define his own e-mail template and
>> use a different From: line but I thought it would be simpler to
>> provide some defaults based on this.
>
> Why don't you rather use the GIT_AUTHOR_* variables?

It was simpler since the template variables were based on the patch
details. Anyway, it's not hard to modify.

-- 
Catalin

^ permalink raw reply
* [PATCH 3/2] git-merge-cache -q doesn't complain about failing merge program
From: Petr Baudis @ 2005-07-29 12:53 UTC (permalink / raw)
  To: junkio; +Cc: git
In-Reply-To: <20050729085819.GL24895@pasky.ji.cz>

git-merge-cache reporting failed merge program is undesirable for
Cogito, since it emits its own more appropriate error message in that
case. However, I want to show other possible git-merge-cache error
messages. So -q will just silence this particular error.

Signed-off-by: Petr Baudis <pasky@ucw.cz>

---

There's more of patches to come. All those which are overflowing this
series are in the git-pb branch as well and you'd get them by pulling
it.

commit 8ddefe85adc8e035864be615c87844ef982f4bc6
tree d5e6c49f93d2e4138ad63faa7fcfb893f4843c88
parent 527a155a0400df1af2e1da64fc02f2dd003413a8
author Petr Baudis <pasky@suse.cz> Fri, 29 Jul 2005 14:52:53 +0200
committer Petr Baudis <xpasky@machine.sinus.cz> Fri, 29 Jul 2005 14:52:53 +0200

 Documentation/git-merge-cache.txt |    9 +++++++--
 merge-cache.c                     |   23 +++++++++++++++--------
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/Documentation/git-merge-cache.txt b/Documentation/git-merge-cache.txt
--- a/Documentation/git-merge-cache.txt
+++ b/Documentation/git-merge-cache.txt
@@ -9,7 +9,7 @@ git-merge-cache - Runs a merge for files
 
 SYNOPSIS
 --------
-'git-merge-cache' [-o] <merge-program> (-a | -- | <file>\*) 
+'git-merge-cache' [-o] [-q] <merge-program> (-a | -- | <file>\*) 
 
 DESCRIPTION
 -----------
@@ -32,6 +32,11 @@ OPTIONS
 	returned errors, and only return the error code after all the
 	merges are over.
 
+-q::
+	Do not complain about failed merge program (the merge program
+	failure usually indicates conflicts during merge). This is for
+	porcelains which might want to emit custom messages.
+
 If "git-merge-cache" is called with multiple <file>s (or -a) then it
 processes them in turn only stopping if merge returns a non-zero exit
 code.
@@ -40,7 +45,7 @@ Typically this is run with the a script 
 the RCS package.
 
 A sample script called "git-merge-one-file-script" is included in the
-ditribution.
+distribution.
 
 ALERT ALERT ALERT! The git "merge object order" is different from the
 RCS "merge" program merge object order. In the above ordering, the
diff --git a/merge-cache.c b/merge-cache.c
--- a/merge-cache.c
+++ b/merge-cache.c
@@ -5,7 +5,7 @@
 
 static const char *pgm = NULL;
 static const char *arguments[8];
-static int one_shot;
+static int one_shot, quiet;
 static int err;
 
 static void run_program(void)
@@ -27,10 +27,13 @@ static void run_program(void)
 		die("unable to execute '%s'", pgm);
 	}
 	if (waitpid(pid, &status, 0) < 0 || !WIFEXITED(status) || WEXITSTATUS(status)) {
-		if (one_shot)
+		if (one_shot) {
 			err++;
-		else
-			die("merge program failed");
+		} else {
+			if (quiet)
+				die("merge program failed");
+			exit(1);
+		}
 	}
 }
 
@@ -97,15 +100,19 @@ int main(int argc, char **argv)
 	int i, force_file = 0;
 
 	if (argc < 3)
-		usage("git-merge-cache [-o] <merge-program> (-a | <filename>*)");
+		usage("git-merge-cache [-o] [-q] <merge-program> (-a | <filename>*)");
 
 	read_cache();
 
 	i = 1;
-	if (!strcmp(argv[1], "-o")) {
+	if (!strcmp(argv[i], "-o")) {
 		one_shot = 1;
 		i++;
 	}
+	if (!strcmp(argv[i], "-q")) {
+		quiet = 1;
+		i++;
+	}
 	pgm = argv[i++];
 	for (; i < argc; i++) {
 		char *arg = argv[i];
@@ -122,7 +129,7 @@ int main(int argc, char **argv)
 		}
 		merge_file(arg);
 	}
-	if (err)
+	if (err && quiet)
 		die("merge program failed");
-	return 0;
+	return err;
 }

^ permalink raw reply
* [PACKAGERS] Makefile: DESTDIR vs. dest
From: Petr Baudis @ 2005-07-29 13:30 UTC (permalink / raw)
  To: git

  Hello,

  git has $dest in its Makefile while Cogito uses $DESTDIR. I'd like to
ask the potential users of those variables (probably mostly distribution
package maintainers) what's easier for them and what do they prefer, as
I would like to unify this.

  Thanks,

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

^ permalink raw reply
* Makefile: COPTS vs CFLAGS
From: Petr Baudis @ 2005-07-29 13:40 UTC (permalink / raw)
  To: git

  Hello,

  one more thing - should we keep the $COPTS variable? Most projects
(including Cogito) have the C flags controlled by the $CFLAGS variable.

  What I would propose:

	-COPTS=-g -O2
	-CFLAGS=$(COPTS) -Wall
	+CFLAGS?=-g -O2
	+CFLAGS+=-Wall

  That is, if user does not specify custom $CFLAGS, default to "-g -O2",
and always append -Wall (and more after I'll send my Makefile patches).

  Opinions?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox

^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: A Large Angry SCM @ 2005-07-29 13:49 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Matthias Urlichs, git
In-Reply-To: <20050729072157.GD24895@pasky.ji.cz>

Petr Baudis wrote:
> Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter
> where Matthias Urlichs <smurf@smurf.noris.de> told me that...
>>Hi, A Large Angry SCM wrote:
>>
>>>So you're arguing for "last match wins" versus "first match wins". I, 
>>>personally, find the former more natural and easier to debug by hand.
>>You know, up until five minutes ago, I thought so too.
> 
> So is the Large Angry SCM agreeing with me or not? I wrote long reply to
> his mail, then reread what he wrote again, and decided that he is
> _agreeing_ with me and you that "last match wins" is better. :-)
> 

*Oops!*

Yes, it looks that way doesn't it. But I had accidentally [*1*] typed 
"former" where I wanted "later". Either way works as long as it's well 
documented/understood.

[*1*] Either too much or too little caffeine at the time I suspect.

^ permalink raw reply
* Re: Makefile: COPTS vs CFLAGS
From: Timo Hirvonen @ 2005-07-29 14:03 UTC (permalink / raw)
  To: Petr Baudis, git
In-Reply-To: <20050729134011.GD21909@pasky.ji.cz>

On Fri, 29 Jul 2005 15:40:11 +0200
Petr Baudis <pasky@suse.cz> wrote:

>   What I would propose:
> 
> 	-COPTS=-g -O2
> 	-CFLAGS=$(COPTS) -Wall
> 	+CFLAGS?=-g -O2
> 	+CFLAGS+=-Wall

Sounds good. I've never heard of anyone using COPTS variable before. And
"-g -O2" seems to be a good default value.

Using $DESTDIR instead of $dest would be nice too because DESTDIR is used
by Autotools.

-- 
http://onion.dynserv.net/~timo/

^ permalink raw reply
* Re: Dump http servers still slow?
From: Darrin Thompson @ 2005-07-29 14:03 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy87qpcwg.fsf@assigned-by-dhcp.cox.net>

On Thu, 2005-07-28 at 19:24 -0700, Junio C Hamano wrote:
> The thing is, the base pack for the git repository is 1.8MB
> currently containing 4500+ objects, while we accumulated 600+
> unpacked objects since then which is about ~5MB.  The commit
> walker needs to fetched the latter one by one in the old way.
> 
> When packed incrementally on top of the base pack, these 600+
> unpacked objects compress down to something like 400KB, and I
> was hoping we could wait until we accumulate enough to produce
> an incremental about a meg or so ...

Ok... so lets check my assumptions:

1. Pack files should reduce the number of http round trips.
2. What I'm seeing when I check out mainline git is the acquisition of a
single large pack, then 600+ more recent objects. Better than before,
but still hundreds of round trips.
3. If I wanted to further speed up the initial checkout on my own
repositories I could frequently repack my most recent few hundred
objects.
4. If curl had pipelining then less pack management would be needed.

Where is the code for gitweb? (i.e. http://kernel.org/git ) Seems like
it could benefit from some git-send-pack superpowers.

--
Darrin

^ permalink raw reply
* Re: Tutorial problem a/a a/b
From: Darrin Thompson @ 2005-07-29 14:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy87qkwdp.fsf@assigned-by-dhcp.cox.net>

On Thu, 2005-07-28 at 22:35 -0700, Junio C Hamano wrote:
> Darrin Thompson <darrint@progeny.com> writes:
> 
> > In the tutorial the user is instructed to create two files: a and b.
> >
> > Then when the user diffs the files, they see this:
> >
> > diff --git a/a b/a
> >
> > That really confused somebody and I had to untangle their brain. :-)
> 
> Yes I was confused when I read it for the first time.
> How does this look?

Looks good to me and guy with the original question.

--
Darrin

^ permalink raw reply
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox