Git development
 help / color / mirror / Atom feed
* Re: Mergetool generating blank files (1.5.3)
From: Russ Brown @ 2007-09-27 19:00 UTC (permalink / raw)
  To: Pierre Habouzit, Kelvie Wong, git
In-Reply-To: <20070927185707.GC12427@artemis.corp>

Pierre Habouzit wrote:
> On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
>> At work, I've been using a git-svn import for my daily workflow (still
>> somewhat of a git newbie, but now has come to the point where it's
>> tough to work without it), and while rebasing from svn (on a rather
>> old branch), I found that the mergetool option does not work too well
>> for me.
> 
>   Which tool are you using ? kdiff3 ? I've noticed that it often fails
> miserably, or worse, create bad merges silentely with it.
> 
>   And as none of the other merge tool that are supported are able to
> either do 3way merges, or have a decent UI (that definitely seems to be
> exclusive features) I've given up on git-mergetool (and to be fair, it
> sucks, because it could be _sooo_ useful sometimes).
> 

What about meld? That does 3-way merge, and the UI is fine.

-- 

Russ

^ permalink raw reply

* Re: [EGIT] UTF-8 in author names in history views read as ISO-8859-1
From: Robin Rosenberg @ 2007-09-27 18:59 UTC (permalink / raw)
  To: José Fonseca; +Cc: git
In-Reply-To: <200709272053.41795.robin.rosenberg.lists@dewire.com>

torsdag 27 september 2007 skrev Robin Rosenberg:
> Encoding is largeley neglected. Actually conversions are made because one
> has to, but there is no consistency there. Git mostly neglect encodings and
> so does anything that attempt to be compatible with it. I have some patches
> towards improvement. A problem is that conversion to or from UTF-8 and back
> are not reversible, especially when the input is invalid for the conversion. This
> *will* happen when dealing with git repos that contain non-ascii comments or
> file names.

A confession. The only thing we do cater for is the encoding header in commits.

-- robin

^ permalink raw reply

* Re: Mergetool generating blank files (1.5.3)
From: Pierre Habouzit @ 2007-09-27 18:57 UTC (permalink / raw)
  To: Kelvie Wong; +Cc: git
In-Reply-To: <94ccbe710709271131o620bf1far8893328ce98f0ba4@mail.gmail.com>

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

On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
> At work, I've been using a git-svn import for my daily workflow (still
> somewhat of a git newbie, but now has come to the point where it's
> tough to work without it), and while rebasing from svn (on a rather
> old branch), I found that the mergetool option does not work too well
> for me.

  Which tool are you using ? kdiff3 ? I've noticed that it often fails
miserably, or worse, create bad merges silentely with it.

  And as none of the other merge tool that are supported are able to
either do 3way merges, or have a decent UI (that definitely seems to be
exclusive features) I've given up on git-mergetool (and to be fair, it
sucks, because it could be _sooo_ useful sometimes).

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

^ permalink raw reply

* Re: [EGIT] UTF-8 in author names in history views read as ISO-8859-1
From: Robin Rosenberg @ 2007-09-27 18:53 UTC (permalink / raw)
  To: José Fonseca; +Cc: git
In-Reply-To: <fdel0j$na4$3@sea.gmane.org>

torsdag 27 september 2007 skrev José Fonseca:
> Hi,
> 
> First, thanks for the work on egit -- it is progressively becoming more 
> and more useful.
> 
> I found that spite UTF-8 being the default encoding, egit is interpreting 
> (or displaying) names as ISO-8859-1 in the history view.

Encoding is largeley neglected. Actually conversions are made because one
has to, but there is no consistency there. Git mostly neglect encodings and
so does anything that attempt to be compatible with it. I have some patches
towards improvement. A problem is that conversion to or from UTF-8 and back
are not reversible, especially when the input is invalid for the conversion. This
*will* happen when dealing with git repos that contain non-ascii comments or
file names.

> BTW, something I really miss from egit is "Team > Compare With > HEAD 
> revision" or something like that.

Coming.. but no plan on when as for most ideas that I have. Lack of time means
most things come in small pieces that can be completed in an hour or two. OTOH
some things become clear and simple over time when not rushing them. This is
probably one of the simple features. Actually it's a good way to get started with
hacking the plugin ;]

> Keep up the good work!

Thanks

-- robin

^ permalink raw reply

* Mergetool generating blank files (1.5.3)
From: Kelvie Wong @ 2007-09-27 18:31 UTC (permalink / raw)
  To: git

At work, I've been using a git-svn import for my daily workflow (still
somewhat of a git newbie, but now has come to the point where it's
tough to work without it), and while rebasing from svn (on a rather
old branch), I found that the mergetool option does not work too well
for me.

I am using version 1.5.3 and I have tried all of the different diff
tools (save opendiff) that are supported by git -- but in the middle
of a rebase, whenever I run the mergetool, the LOCAL, REMOTE, and BASE
temporary files that are created are all empty.  The BACKUP file
remains, and still has the proper 3-way-merge conflict syntax (with
<<<< ==== >>>>) and such, but the other files are all empty -- and
thus the mergetool of choice does not read it (it shows up empty there
too, of course).

What could I do to fix this?  I'm confident that there are conflicts
(git tells me so, and I end up manually going through all the files in
emacs anyways, but it's very tedious); or is there another tool that
reads the 3-way-merge syntax (the < = >'s) and lets me pick one or the
other, or do I have to write my own?

I know there's just something funky on my system, because someone else
doesn't seem to have this problem on his computer -- maybe it is
because I use the svn rebase, but it does that when I rebase onto
another branch too.

Thanks.

-- 
Kelvie

^ permalink raw reply

* Re: Relating to some syntax error in the gitk script
From: Brett Schwarz @ 2007-09-27 17:00 UTC (permalink / raw)
  To: Ritwik Ghosh, git

> 
> When I am running the gitk command I get the following error message:-
> 
> ========================================================================
> ===========================
> Error in startup script: syntax error in expression "$i >= [llength
> $argv] && $revtreeargs ne {}"
>     while executing
> "if {$i >= [llength $argv] && $revtreeargs ne {}} {
>     # no -- on command line, but some arguments (other than -d)
>     if {[catch {
>         set f [eval exec..."
>     (file "./gitk" line 7912)
> ========================================================================
> ============================
> 
> Is there a problem with the script or is it a problem with my
> environment...?
> 

What version of Tcl are you running? You should be using >= 8.4





       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

^ permalink raw reply

* ignoring non-submodule subrepositories
From: martin f krafft @ 2007-09-27 17:07 UTC (permalink / raw)
  To: git discussion list

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

Hello,

I have a repository inside another, and for several reasons, I do
not want to use git-submodule in this case. My issue is that
git-status lists the subrepository as untracked.

Of course, I could add it to .gitignore alright, but instead
I wonder whether it would not make sense to ignore subdirectories
themselves containing .git/ directories, not explicitly so as to not
mess with git-submodule, but implicitly.

Thoughts?

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
never underestimate the power of human stupidity.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: Equivalent of `svn switch` for git-svn?
From: Pierre Habouzit @ 2007-09-27 17:02 UTC (permalink / raw)
  To: Adam Roben; +Cc: Johannes Schindelin, git
In-Reply-To: <46FBDCBF.7060909@apple.com>

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

On Thu, Sep 27, 2007 at 04:39:27PM +0000, Adam Roben wrote:
> Will doing this then change all the git-svn-id: lines in the commit logs 
> for those imported revisions? I'm asking because my understanding is that 
> git-svn uses those git-svn-id: lines to determine which branch you're on, 
> and if the URLs are now all out of date won't it then think it can't 
> determine the correct branch?

  fwiw If it breaks git-svn, then it's a deep git-svn misconception.
I've always believed that git-svn should always have done what git
checkout --track do, meaning set into the configuration which svn remote
branch you are following.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

^ permalink raw reply

* Re: Equivalent of `svn switch` for git-svn?
From: Adam Roben @ 2007-09-27 16:39 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0709271253040.28395@racer.site>


Johannes Schindelin wrote:
> Hi,
>
> On Thu, 27 Sep 2007, Pierre Habouzit wrote:
>
>   
>> On Thu, Sep 27, 2007 at 06:41:10AM +0000, Adam Roben wrote:
>>     
>>> Hi all-
>>>   I've recently been informed that the Subversion server I and several 
>>> others have been tracking with git-svn will be switching from using the 
>>> svn+ssh scheme to the http scheme. To handle this, users of svn will be 
>>> running `svn switch` to move their working copies to the new repository 
>>> URL. Is there some way to do the same for git-svn? I suspect the biggest 
>>> complication will come from the git-svn-id: lines in the commit logs, 
>>> since changing that line would require changing the commit hash as well.
>>>       
>>   edit your .git/config, in the section [svn-remote "svn"], change url =
>>     
>
> Or use git-config:
>
> 	git config svn-remote.svn.url <url>
>
> Or make it a global alias:
>
> 	git config --global alias svn-switch 'config svn-remote.svn.url'
>
> so that you can say
>
> 	git svn-switch <url>
>   
Will doing this then change all the git-svn-id: lines in the commit logs 
for those imported revisions? I'm asking because my understanding is 
that git-svn uses those git-svn-id: lines to determine which branch 
you're on, and if the URLs are now all out of date won't it then think 
it can't determine the correct branch?

Thanks for the suggestions so far.

-Adam

^ permalink raw reply

* Re: git push (mis ?)behavior
From: Benoit SIGOURE @ 2007-09-27 15:28 UTC (permalink / raw)
  To: Wincent Colaiuta; +Cc: git discussion list
In-Reply-To: <0CAD1C47-A396-46AA-9DC0-96BBD41EE4E4@wincent.com>

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

On Sep 27, 2007, at 3:30 PM, Wincent Colaiuta wrote:

> El 27/9/2007, a las 15:04, Pierre Habouzit escribió:
>
>>   There is a behavior of git-push that is the most annoying thing  
>> while
>> working with a central-repository: `git push` without any arguments
>> insists on pushing every local refspec that match one in origin.
>
> I kind of agree. Without reading the git-push man page I would  
> intuitively expect "git push" with no arguments to push only the  
> branch I currently have checked out, and "git push --all" to push all.

Same thing here, got bitten the same way.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

^ permalink raw reply

* Re: What's cooking in git.git (topics)
From: David Kastrup @ 2007-09-27 13:46 UTC (permalink / raw)
  To: git
In-Reply-To: <20070927133056.GA29674@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> On Thu, Sep 27, 2007 at 08:08:44AM +0200, David Kastrup wrote:
>
>> In itself, it does not look like there is all too much room for
>> optimization.  One can remove the temporary pointer "optimization" and
>> see whether this makes strength reduction possible for the compiler.
>> Making this an endless loop wrapped around a loop on bucket might also
>> help the compiler in that effect.
>
> I am considering reworking the data structure to be a hash table
> whose buckets never overflow. However, Junio indicated that he tried
> something similar at one point and was not successful. So we will
> see. I haven't had time to play with it yet, but I will post numbers
> when I do.

Linear probing is pretty efficient with regard to keeping memory
access locality.  With a reasonable table filling ratio (not more than
something like 75%, for which it is necessary to know the maximum
number of hashable entries in advance), there is no gain to be
expected in either speed or even memory usage (the waste of 25% is
offset by not needing space for link pointers) with escape lists.
Linear probing hashes are quite hard to resize: if the maximum member
count is _not_ to be guessed in advance, things might look different.

I don't have the time to look at the code right now, so I don't know
whether resizing or unknown maximum size is a relevant factor.

-- 
David Kastrup

^ permalink raw reply

* Re: [PATCH] Create .dotest-merge after validating options.
From: Matt Kraai @ 2007-09-27 14:03 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy10woqi.fsf@gitster.siamese.dyndns.org>

On Thu, Sep 27, 2007 at 12:29:09AM -0700, Junio C Hamano wrote:
> Matt Kraai <kraai@ftbfs.org> writes:
> 
> > Creating .dotest-merge before validating the options prevents both
> > --continue and --interactive from working if the options are invalid,
> > so only create it after validating the options.
> 
> Thanks.  Will apply with a minor fixup.  Next time, please make
> sure the testsuite passes before submitting.

Will do, thanks.

-- 
Matt

^ permalink raw reply

* [PATCH] strbuf_read_file enhancement, and use it.
From: Pierre Habouzit @ 2007-09-27 13:25 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <20070927133609.GJ10289@artemis.corp>

* make strbuf_read_file take a size hint (works like strbuf_read)
* use it in a couple of places.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---

 oh boy, once again I sent a half baked patch. okay, I'll stop for today :/
 strbuf_read_file returns 0 or -1, not the size read.

 builtin-apply.c |   12 ++----------
 builtin-blame.c |    8 ++------
 builtin-tag.c   |   19 +++++++------------
 strbuf.c        |    4 ++--
 strbuf.h        |    2 +-
 5 files changed, 14 insertions(+), 31 deletions(-)

diff --git a/builtin-apply.c b/builtin-apply.c
index 1f0a672..65447a1 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1421,8 +1421,6 @@ static void show_stats(struct patch *patch)
 
 static int read_old_data(struct stat *st, const char *path, struct strbuf *buf)
 {
-	int fd;
-
 	switch (st->st_mode & S_IFMT) {
 	case S_IFLNK:
 		strbuf_grow(buf, st->st_size);
@@ -1431,14 +1429,8 @@ static int read_old_data(struct stat *st, const char *path, struct strbuf *buf)
 		strbuf_setlen(buf, st->st_size);
 		return 0;
 	case S_IFREG:
-		fd = open(path, O_RDONLY);
-		if (fd < 0)
-			return error("unable to open %s", path);
-		if (strbuf_read(buf, fd, st->st_size) < 0) {
-			close(fd);
-			return -1;
-		}
-		close(fd);
+		if (strbuf_read_file(buf, path, st->st_size) < 0)
+			return error("unable to open or read %s", path);
 		convert_to_git(path, buf->buf, buf->len, buf);
 		return 0;
 	default:
diff --git a/builtin-blame.c b/builtin-blame.c
index 16c0ca8..099c363 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2002,7 +2002,6 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
 	unsigned char head_sha1[20];
 	struct strbuf buf;
 	const char *ident;
-	int fd;
 	time_t now;
 	int size, len;
 	struct cache_entry *ce;
@@ -2041,11 +2040,8 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
 		mode = canon_mode(st.st_mode);
 		switch (st.st_mode & S_IFMT) {
 		case S_IFREG:
-			fd = open(read_from, O_RDONLY);
-			if (fd < 0)
-				die("cannot open %s", read_from);
-			if (strbuf_read(&buf, fd, 0) != xsize_t(st.st_size))
-				die("cannot read %s", read_from);
+			if (strbuf_read_file(&buf, read_from, st.st_size) < 0)
+				die("cannot open or read %s", read_from);
 			break;
 		case S_IFLNK:
 			if (readlink(read_from, buf.buf, buf.alloc) != fin_size)
diff --git a/builtin-tag.c b/builtin-tag.c
index 6132cac..66e5a58 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -51,7 +51,7 @@ static void launch_editor(const char *path, struct strbuf *buffer)
 	if (run_command(&child))
 		die("There was a problem with the editor %s.", editor);
 
-	if (strbuf_read_file(buffer, path) < 0)
+	if (strbuf_read_file(buffer, path, 0) < 0)
 		die("could not read message file '%s': %s",
 		    path, strerror(errno));
 }
@@ -356,8 +356,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
 			continue;
 		}
 		if (!strcmp(arg, "-F")) {
-			int fd;
-
 			annotate = 1;
 			i++;
 			if (i == argc)
@@ -365,17 +363,14 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
 			if (message)
 				die("only one -F or -m option is allowed.");
 
-			if (!strcmp(argv[i], "-"))
-				fd = 0;
-			else {
-				fd = open(argv[i], O_RDONLY);
-				if (fd < 0)
-					die("could not open '%s': %s",
+			if (!strcmp(argv[i], "-")) {
+				if (strbuf_read(&buf, 0, 1024) < 0)
+					die("cannot read %s", argv[i]);
+			} else {
+				if (strbuf_read_file(&buf, argv[i], 1024) < 0)
+					die("could not open or read '%s': %s",
 						argv[i], strerror(errno));
 			}
-			if (strbuf_read(&buf, fd, 1024) < 0) {
-				die("cannot read %s", argv[i]);
-			}
 			message = 1;
 			continue;
 		}
diff --git a/strbuf.c b/strbuf.c
index 910acd0..5cac01e 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -183,14 +183,14 @@ int strbuf_getline(struct strbuf *sb, FILE *fp, int term)
 	return 0;
 }
 
-int strbuf_read_file(struct strbuf *sb, const char *path)
+int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint)
 {
 	int fd, len;
 
 	fd = open(path, O_RDONLY);
 	if (fd < 0)
 		return -1;
-	len = strbuf_read(sb, fd, 0);
+	len = strbuf_read(sb, fd, hint);
 	close(fd);
 	if (len < 0)
 		return -1;
diff --git a/strbuf.h b/strbuf.h
index 6deec78..9b9e861 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -108,7 +108,7 @@ extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
 extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
 /* XXX: if read fails, any partial read is undone */
 extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
-extern int strbuf_read_file(struct strbuf *sb, const char *path);
+extern int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint);
 
 extern int strbuf_getline(struct strbuf *, FILE *, int);
 
-- 
1.5.3.2.1110.gba7d6

^ permalink raw reply related

* [PATCH] strbuf_read_file enhancement, and use it.
From: Pierre Habouzit @ 2007-09-27 13:36 UTC (permalink / raw)
  To: Junio C Hamano, Kristian Høgsberg; +Cc: git

* make strbuf_read_file take a size hint (works like strbuf_read)
* use it in a couple of places.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---

I just noticed someone introduced a nice strbuf_read_file API, so here is
a patch that diverts this nice idea to simplify git further.

 builtin-apply.c |   12 ++----------
 builtin-blame.c |    8 ++------
 builtin-tag.c   |   19 +++++++------------
 strbuf.c        |    4 ++--
 strbuf.h        |    2 +-
 5 files changed, 14 insertions(+), 31 deletions(-)

diff --git a/builtin-apply.c b/builtin-apply.c
index 1f0a672..047a60d 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1421,8 +1421,6 @@ static void show_stats(struct patch *patch)
 
 static int read_old_data(struct stat *st, const char *path, struct strbuf *buf)
 {
-	int fd;
-
 	switch (st->st_mode & S_IFMT) {
 	case S_IFLNK:
 		strbuf_grow(buf, st->st_size);
@@ -1431,14 +1429,8 @@ static int read_old_data(struct stat *st, const char *path, struct strbuf *buf)
 		strbuf_setlen(buf, st->st_size);
 		return 0;
 	case S_IFREG:
-		fd = open(path, O_RDONLY);
-		if (fd < 0)
-			return error("unable to open %s", path);
-		if (strbuf_read(buf, fd, st->st_size) < 0) {
-			close(fd);
-			return -1;
-		}
-		close(fd);
+		if (strbuf_read_file(buf, path, st->st_size) != st->st_size)
+			return error("unable to open or read %s", path);
 		convert_to_git(path, buf->buf, buf->len, buf);
 		return 0;
 	default:
diff --git a/builtin-blame.c b/builtin-blame.c
index 16c0ca8..e3112a2 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2002,7 +2002,6 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
 	unsigned char head_sha1[20];
 	struct strbuf buf;
 	const char *ident;
-	int fd;
 	time_t now;
 	int size, len;
 	struct cache_entry *ce;
@@ -2041,11 +2040,8 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
 		mode = canon_mode(st.st_mode);
 		switch (st.st_mode & S_IFMT) {
 		case S_IFREG:
-			fd = open(read_from, O_RDONLY);
-			if (fd < 0)
-				die("cannot open %s", read_from);
-			if (strbuf_read(&buf, fd, 0) != xsize_t(st.st_size))
-				die("cannot read %s", read_from);
+			if (strbuf_read_file(&buf, read_from, st.st_size) != st.st_size)
+				die("cannot open or read %s", read_from);
 			break;
 		case S_IFLNK:
 			if (readlink(read_from, buf.buf, buf.alloc) != fin_size)
diff --git a/builtin-tag.c b/builtin-tag.c
index 6132cac..66e5a58 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -51,7 +51,7 @@ static void launch_editor(const char *path, struct strbuf *buffer)
 	if (run_command(&child))
 		die("There was a problem with the editor %s.", editor);
 
-	if (strbuf_read_file(buffer, path) < 0)
+	if (strbuf_read_file(buffer, path, 0) < 0)
 		die("could not read message file '%s': %s",
 		    path, strerror(errno));
 }
@@ -356,8 +356,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
 			continue;
 		}
 		if (!strcmp(arg, "-F")) {
-			int fd;
-
 			annotate = 1;
 			i++;
 			if (i == argc)
@@ -365,17 +363,14 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
 			if (message)
 				die("only one -F or -m option is allowed.");
 
-			if (!strcmp(argv[i], "-"))
-				fd = 0;
-			else {
-				fd = open(argv[i], O_RDONLY);
-				if (fd < 0)
-					die("could not open '%s': %s",
+			if (!strcmp(argv[i], "-")) {
+				if (strbuf_read(&buf, 0, 1024) < 0)
+					die("cannot read %s", argv[i]);
+			} else {
+				if (strbuf_read_file(&buf, argv[i], 1024) < 0)
+					die("could not open or read '%s': %s",
 						argv[i], strerror(errno));
 			}
-			if (strbuf_read(&buf, fd, 1024) < 0) {
-				die("cannot read %s", argv[i]);
-			}
 			message = 1;
 			continue;
 		}
diff --git a/strbuf.c b/strbuf.c
index 910acd0..5cac01e 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -183,14 +183,14 @@ int strbuf_getline(struct strbuf *sb, FILE *fp, int term)
 	return 0;
 }
 
-int strbuf_read_file(struct strbuf *sb, const char *path)
+int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint)
 {
 	int fd, len;
 
 	fd = open(path, O_RDONLY);
 	if (fd < 0)
 		return -1;
-	len = strbuf_read(sb, fd, 0);
+	len = strbuf_read(sb, fd, hint);
 	close(fd);
 	if (len < 0)
 		return -1;
diff --git a/strbuf.h b/strbuf.h
index 6deec78..9b9e861 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -108,7 +108,7 @@ extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
 extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
 /* XXX: if read fails, any partial read is undone */
 extern ssize_t strbuf_read(struct strbuf *, int fd, size_t hint);
-extern int strbuf_read_file(struct strbuf *sb, const char *path);
+extern int strbuf_read_file(struct strbuf *sb, const char *path, size_t hint);
 
 extern int strbuf_getline(struct strbuf *, FILE *, int);
 
-- 
1.5.3.2.1110.gba7d6

^ permalink raw reply related

* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-09-27 13:30 UTC (permalink / raw)
  To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <854phgfxn7.fsf@lola.goethe.zz>

On Thu, Sep 27, 2007 at 08:08:44AM +0200, David Kastrup wrote:

> In itself, it does not look like there is all too much room for
> optimization.  One can remove the temporary pointer "optimization" and
> see whether this makes strength reduction possible for the compiler.
> Making this an endless loop wrapped around a loop on bucket might also
> help the compiler in that effect.

I am considering reworking the data structure to be a hash table whose
buckets never overflow. However, Junio indicated that he tried something
similar at one point and was not successful. So we will see. I haven't
had time to play with it yet, but I will post numbers when I do.

-Peff

^ permalink raw reply

* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-09-27 13:30 UTC (permalink / raw)
  To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070927130447.GH10289@artemis.corp>

El 27/9/2007, a las 15:04, Pierre Habouzit escribió:

>   There is a behavior of git-push that is the most annoying thing  
> while
> working with a central-repository: `git push` without any arguments
> insists on pushing every local refspec that match one in origin.

I kind of agree. Without reading the git-push man page I would  
intuitively expect "git push" with no arguments to push only the  
branch I currently have checked out, and "git push --all" to push all.

>   I'm not sure what we can do about it, but I'm pretty sure it bites a
> lot of people out there. For now I use this alias in my .gitconfig:
>
>   p=!git-push origin `git-symbolic-ref HEAD`

Ah, nice alias! Thanks for sharing it.

Cheers,
Wincent

^ permalink raw reply

* git push (mis ?)behavior
From: Pierre Habouzit @ 2007-09-27 13:04 UTC (permalink / raw)
  To: git

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

  There is a behavior of git-push that is the most annoying thing while
working with a central-repository: `git push` without any arguments
insists on pushing every local refspec that match one in origin.

  While it's perfectly correct when you push to a public repository (you
do that seldom, and usually only after having prepared it with care),
it's not true for the central-repository layout. At work, I often have
this situation:

  [I'm in the devel branch, would be next for git e.g.]
  ... hack ... hack ... *OMG* what a nasty bug...
  $ git stash
  $ git checkout <stable branch>
  .. fix nasty bug ..
  $ git commit
  $ git push # so that co-workers have the fix asap
  $ git checkout <devel branch>
  $ git stash apply
  ... OOOOH NOES it pushed my WIP in my devel branch as well ...

  There has been (and still is atm) a quite heated discussion on IRC
about that. Some arguments were that pull/push were opposite words in
English, but weren't doing an opposite thing in git, which led to some
fight. But that's not close to the point IMHO.

  The real question is "what does users intend when they `git push`". In
a git/kernel/... like model, you don't think the same than in a
svn/cvs-like model. I mean, Junio or Linus likely don't push a lot to
their public repository. It happens probably a couple of time per day.
While I'm at work, it happens up way more frequentely, and I then want
to lazily type `git push` and not `git push origin <somebranch>`. it's
too long.

  I'm not sure what we can do about it, but I'm pretty sure it bites a
lot of people out there. For now I use this alias in my .gitconfig:

  p=!git-push origin `git-symbolic-ref HEAD`

but still, it feels really wrong to me. Not to mention that git-push(1)
says that it has a --all option that in fact is the current default
behavior, hence sounds pretty useless.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

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

^ permalink raw reply

* [PATCH] git-gui: fix typo in lib/blame.tcl
From: Michele Ballabio @ 2007-09-27 12:53 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
 lib/blame.tcl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/blame.tcl b/lib/blame.tcl
index a911c3c..00ecf21 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -905,7 +905,7 @@ method _open_tooltip {cur_w} {
 		set author_time {}
 		catch {set author_name $header($cmit,author)}
 		catch {set summary     $header($cmit,summary)}
-		catch {set author_time [foramt_date $header($cmit,author-time)]}
+		catch {set author_time [format_date $header($cmit,author-time)]}
 
 		$tooltip_t insert end [strcat [mc "Originally By:"] "\n"] section_header
 		$tooltip_t insert end "commit $cmit\n"
-- 
1.5.3

^ permalink raw reply related

* Relating to some syntax error in the gitk script
From: Ritwik Ghosh @ 2007-09-27 12:22 UTC (permalink / raw)
  To: git

 
Hi,

When I am running the gitk command I get the following error message:-

========================================================================
===========================
Error in startup script: syntax error in expression "$i >= [llength
$argv] && $revtreeargs ne {}"
    while executing
"if {$i >= [llength $argv] && $revtreeargs ne {}} { 
    # no -- on command line, but some arguments (other than -d)
    if {[catch {
        set f [eval exec..."
    (file "./gitk" line 7912)
========================================================================
============================

Is there a problem with the script or is it a problem with my
environment...?


Regards,


Ritwik
SASKEN BUSINESS DISCLAIMER
-------------------------
This message may contain confidential, proprietary or legally privileged information. In 
case you are not the original intended Recipient of the message, you must not, directly or 
indirectly, use, Disclose, distribute, print, or copy any part of this message and you are 
requested to delete it and inform the sender. Any views expressed in this message are 
those of the individual sender unless otherwise stated. Nothing contained in this message 
shall be construed as an offer or acceptance of any offer by Sasken Communication 
Technologies Limited ("Sasken") unless sent with that express intent and with due 
authority of Sasken. Sasken has taken enough precautions to prevent the spread of 
viruses. However the company accepts no liability for any damage caused by any virus 
transmitted by this email

^ permalink raw reply

* Re: [msysGit] [PATCH 1/2] contrib: Add diff viewing capability for Microsoft Word documents
From: Johannes Schindelin @ 2007-09-27 12:04 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git, msysgit
In-Reply-To: <11908935593618-git-send-email-johannes.sixt@telecom.at>

Hi,

On Thu, 27 Sep 2007, Johannes Sixt wrote:

> 	Ok, here's something that shows how git helps solve REAL PROBLEMS.

Hehe.

> +WINWORDEXE = C:/Program Files/Microsoft Office/Office/WINWORD.EXE

AFAICT this would be better written as $(PROGRAMFILES) (but you have to 
add proper quoting, I guess).

Or, alternatively, you can get it with a simple Tcl script

	package require registry 1.0
	puts [regsub "\\" [registry get \
		"HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Extensions" \
		 "doc"] "/"]

Or something like that.

Ciao,
Dscho

^ permalink raw reply

* Re: Equivalent of `svn switch` for git-svn?
From: Johannes Schindelin @ 2007-09-27 11:54 UTC (permalink / raw)
  To: Pierre Habouzit; +Cc: Adam Roben, git
In-Reply-To: <20070927100607.GC10289@artemis.corp>

Hi,

On Thu, 27 Sep 2007, Pierre Habouzit wrote:

> On Thu, Sep 27, 2007 at 06:41:10AM +0000, Adam Roben wrote:
> > Hi all-
> >   I've recently been informed that the Subversion server I and several 
> > others have been tracking with git-svn will be switching from using the 
> > svn+ssh scheme to the http scheme. To handle this, users of svn will be 
> > running `svn switch` to move their working copies to the new repository 
> > URL. Is there some way to do the same for git-svn? I suspect the biggest 
> > complication will come from the git-svn-id: lines in the commit logs, 
> > since changing that line would require changing the commit hash as well.
> 
>   edit your .git/config, in the section [svn-remote "svn"], change url =

Or use git-config:

	git config svn-remote.svn.url <url>

Or make it a global alias:

	git config --global alias svn-switch 'config svn-remote.svn.url'

so that you can say

	git svn-switch <url>

Ciao,
Dscho

^ permalink raw reply

* Re: [PATCH 2/4] This exports the update() function from builtin-add.c as
From: Johannes Schindelin @ 2007-09-27 11:47 UTC (permalink / raw)
  To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <1190868632-29287-2-git-send-email-krh@redhat.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 235 bytes --]

Hi,

On Thu, 27 Sep 2007, Kristian Høgsberg wrote:

>  builtin-add.c |    8 ++++----
>  commit.h      |    2 ++

Maybe move it to read-cache.c, just after "add_file_to_index()"?  And 
expose it via cache.h, not commit.h?

Ciao,
Dscho

^ permalink raw reply

* [PATCH 2/2] winworddiff: Check the path to winword.exe during the installation.
From: Johannes Sixt @ 2007-09-27 11:45 UTC (permalink / raw)
  To: git, msysgit; +Cc: Johannes Sixt
In-Reply-To: <11908935593618-git-send-email-johannes.sixt@telecom.at>

Since we do not find the path to winword.exe automatically, but rely on
what the user has told us, we better check the path for plausibility.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 contrib/winword/diff/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/contrib/winword/diff/Makefile b/contrib/winword/diff/Makefile
index 61de940..91b9328 100644
--- a/contrib/winword/diff/Makefile
+++ b/contrib/winword/diff/Makefile
@@ -1,3 +1,4 @@
+# You can override any of these from ../../../config.mak
 prefix = $(HOME)
 bindir = $(prefix)/bin
 datadir = $(prefix)/share/winworddiff
@@ -8,6 +9,9 @@ INSTALL = install
 all: winworddiff winworddiff.dot
 
 winworddiff: winworddiff.sh
+ifndef FORCE
+	exec < "$(WINWORDEXE)"	# check existence; override with 'make FORCE=1'
+endif
 	sed	-e 's|@@WINWORDEXE@@|$(WINWORDEXE)|' \
 		-e 's|@@PREFIX@@|$(prefix)|' \
 		< $@.sh > $@
-- 
1.5.3.3.gcc9e

^ permalink raw reply related

* [PATCH 1/2] contrib: Add diff viewing capability for Microsoft Word documents
From: Johannes Sixt @ 2007-09-27 11:45 UTC (permalink / raw)
  To: git, msysgit; +Cc: Johannes Sixt

A shell script opens WinWord with the documents and a document template.
The document template contains a VBA macro that is run automatically.
It looks up the two documents and performs the comparison.

Unfortunately, the user's help is needed to construct the document template
with the macro from a plain text file, so we print the instructions from
the Makefile.

The README file contains instructions how to use this feature.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
	Ok, here's something that shows how git helps solve REAL PROBLEMS.

	I've been using this for a day or two now with the MinGW port.
	Other Windows prisoners might be interested, too.
	Be sure to read the README and take a deap breath of the
	fresh air.

	;)

	This was only tested with a localized version Microsoft Office 2000,
	so your milage may vary.

	-- Hannes

 contrib/winword/diff/.gitignore      |    2 +
 contrib/winword/diff/Makefile        |   39 ++++++++++++++++++++++++++++++++++
 contrib/winword/diff/README          |   34 +++++++++++++++++++++++++++++
 contrib/winword/diff/winworddiff.bas |   13 +++++++++++
 contrib/winword/diff/winworddiff.sh  |   15 +++++++++++++
 5 files changed, 103 insertions(+), 0 deletions(-)
 create mode 100644 contrib/winword/diff/.gitignore
 create mode 100644 contrib/winword/diff/Makefile
 create mode 100644 contrib/winword/diff/README
 create mode 100644 contrib/winword/diff/winworddiff.bas
 create mode 100755 contrib/winword/diff/winworddiff.sh

diff --git a/contrib/winword/diff/.gitignore b/contrib/winword/diff/.gitignore
new file mode 100644
index 0000000..f37a3c4
--- /dev/null
+++ b/contrib/winword/diff/.gitignore
@@ -0,0 +1,2 @@
+winworddiff
+winworddiff.dot
diff --git a/contrib/winword/diff/Makefile b/contrib/winword/diff/Makefile
new file mode 100644
index 0000000..61de940
--- /dev/null
+++ b/contrib/winword/diff/Makefile
@@ -0,0 +1,39 @@
+prefix = $(HOME)
+bindir = $(prefix)/bin
+datadir = $(prefix)/share/winworddiff
+
+WINWORDEXE = C:/Program Files/Microsoft Office/Office/WINWORD.EXE
+INSTALL = install
+
+all: winworddiff winworddiff.dot
+
+winworddiff: winworddiff.sh
+	sed	-e 's|@@WINWORDEXE@@|$(WINWORDEXE)|' \
+		-e 's|@@PREFIX@@|$(prefix)|' \
+		< $@.sh > $@
+
+winworddiff.dot: winworddiff.bas
+	@echo
+	@echo '****  ATTENTION  ***'
+	@echo '* $@ must be created from $<'
+	@echo '* This cannot be done automatically, so your help is needed:'
+	@echo '* 1. Start Microsoft Word; create a new document *template*'
+	@echo '* 2. Open the Tools->Macro->Visual Basic Editor'
+	@echo '* 3. In the Project browser, locate and open:'
+	@echo '*        TemplateProject (Template1)'
+	@echo '*           Microsoft Word Objects'
+	@echo '*              ThisDocument'
+	@echo '* 4. Double-click "ThisDocument"'
+	@echo '* 5. Choose Insert->File... and select this file:'
+	@echo; echo "`pwd`/$<"; echo
+	@echo '* 6. Close the Visual Basic Editor'
+	@echo '* 7. Save the template as this file (overwrite if necessary):'
+	@echo; echo "`pwd`/$@"; echo
+	@echo '* 8. Run make again'
+	@exit 1
+
+-include ../../../config.mak
+
+install: all
+	$(INSTALL) winworddiff $(bindir)
+	$(INSTALL) winworddiff.dot $(datadir)
diff --git a/contrib/winword/diff/README b/contrib/winword/diff/README
new file mode 100644
index 0000000..dfbcdc3
--- /dev/null
+++ b/contrib/winword/diff/README
@@ -0,0 +1,34 @@
+This directory contains facilities that allow to highlight changes
+between two revisions of WinWord documents.
+
+1.	Installation:
+	a.	Set the variable WINWORDEXE in ../../../config.mak to point
+		to your installed WinWord.exe
+	b.	Run 'make'. This will fail with instructions to
+		create a document template. (It boils down to import
+		a macro file into the template.) Once you have completed
+		the instructions, 'make' will no longer fail.
+	c.	Run 'make install'
+
+2.	Activate diff in your repository
+	a.	Define a custom diff driver:
+
+			$ git config diff.docdiff.command winworddiff
+
+	b.	Use the custom driver for your Word documents, i.e. put
+		a line like this in your .git/info/attributes:
+
+			*.doc	diff=docdiff
+
+3.	Enjoy the diffs:
+
+		$ git diff HEAD~1.. -- UserManual.doc
+
+4.	Caveats:
+
+	-	Macros must be enabled.
+
+	-	A new WinWord instance is started *for*each*document* that
+		is covered by the 'git diff' invocation; therefore, to be
+		on the safe side, always specify a path limiter. Use git-gui
+		and gitk to inspect diffs without path limiters.
diff --git a/contrib/winword/diff/winworddiff.bas b/contrib/winword/diff/winworddiff.bas
new file mode 100644
index 0000000..c7c7630
--- /dev/null
+++ b/contrib/winword/diff/winworddiff.bas
@@ -0,0 +1,13 @@
+Sub Document_Open()
+    ' pick the last 2 documents, present changes from second-last to last
+    ' (the third document is this one)
+    Dim olddoc As Document, newdoc As Document
+    With Application.Documents
+        If .Count < 3 Then Exit Sub
+        Set newdoc = .Item(.Count)
+        Set olddoc = .Item(.Count - 1)
+    End With
+    newdoc.Activate
+    newdoc.Compare Name:=olddoc.FullName
+    newdoc.ShowRevisions = True
+End Sub
diff --git a/contrib/winword/diff/winworddiff.sh b/contrib/winword/diff/winworddiff.sh
new file mode 100755
index 0000000..5adb97d
--- /dev/null
+++ b/contrib/winword/diff/winworddiff.sh
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+word="@@WINWORDEXE@@"
+difftempl="@@PREFIX@@/share/winworddiff/winworddiff.dot"
+
+test $# = 7 || {
+	echo >&2 "$0: expected 7 arguments:"
+	echo >&2 "	path old oldsha1 oldmode new newsha1 newmode"
+	exit 1;
+}
+
+of="$2"
+nf="$5"
+
+"$word" -w "$nf" "$of" "$difftempl"
-- 
1.5.3.3.gcc9e

^ permalink raw reply related

* [PROPER PATCH 1/1] Make read_patch_file work on a strbuf.
From: Pierre Habouzit @ 2007-09-27 11:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <20070927112204.GE10289@artemis.corp>

So that we don't need to use strbuf_detach.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---

Sorry, in the hurry I sent a wrong patch before, this one works :)

 builtin-apply.c |   27 +++++++++++----------------
 1 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/builtin-apply.c b/builtin-apply.c
index 833b142..1f0a672 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -178,12 +178,9 @@ static void say_patch_name(FILE *output, const char *pre, struct patch *patch, c
 #define CHUNKSIZE (8192)
 #define SLOP (16)
 
-static void *read_patch_file(int fd, size_t *sizep)
+static void read_patch_file(struct strbuf *sb, int fd)
 {
-	struct strbuf buf;
-
-	strbuf_init(&buf, 0);
-	if (strbuf_read(&buf, fd, 0) < 0)
+	if (strbuf_read(sb, fd, 0) < 0)
 		die("git-apply: read returned %s", strerror(errno));
 
 	/*
@@ -191,9 +188,8 @@ static void *read_patch_file(int fd, size_t *sizep)
 	 * so that we can do speculative "memcmp" etc, and
 	 * see to it that it is NUL-filled.
 	 */
-	strbuf_grow(&buf, SLOP);
-	memset(buf.buf + buf.len, 0, SLOP);
-	return strbuf_detach(&buf, sizep);
+	strbuf_grow(sb, SLOP);
+	memset(sb->buf + sb->len, 0, SLOP);
 }
 
 static unsigned long linelen(const char *buffer, unsigned long size)
@@ -2648,22 +2644,22 @@ static void prefix_patches(struct patch *p)
 
 static int apply_patch(int fd, const char *filename, int inaccurate_eof)
 {
-	unsigned long offset, size;
-	char *buffer = read_patch_file(fd, &size);
+	size_t offset;
+	struct strbuf buf;
 	struct patch *list = NULL, **listp = &list;
 	int skipped_patch = 0;
 
+	strbuf_init(&buf, 0);
 	patch_input_file = filename;
-	if (!buffer)
-		return -1;
+	read_patch_file(&buf, fd);
 	offset = 0;
-	while (size > 0) {
+	while (offset < buf.len) {
 		struct patch *patch;
 		int nr;
 
 		patch = xcalloc(1, sizeof(*patch));
 		patch->inaccurate_eof = inaccurate_eof;
-		nr = parse_chunk(buffer + offset, size, patch);
+		nr = parse_chunk(buf.buf + offset, buf.len, patch);
 		if (nr < 0)
 			break;
 		if (apply_in_reverse)
@@ -2681,7 +2677,6 @@ static int apply_patch(int fd, const char *filename, int inaccurate_eof)
 			skipped_patch++;
 		}
 		offset += nr;
-		size -= nr;
 	}
 
 	if (whitespace_error && (new_whitespace == error_on_whitespace))
@@ -2716,7 +2711,7 @@ static int apply_patch(int fd, const char *filename, int inaccurate_eof)
 	if (summary)
 		summary_patch_list(list);
 
-	free(buffer);
+	strbuf_release(&buf);
 	return 0;
 }
 
-- 
1.5.3.2.1102.gefa87-dirty

^ permalink raw reply related


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