Git development
 help / color / mirror / Atom feed
* [PATCH v2 01/11] gitweb: introduce remote_heads feature
From: Giuseppe Bilotta @ 2008-11-13 22:49 UTC (permalink / raw)
  To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1226616555-24503-1-git-send-email-giuseppe.bilotta@gmail.com>

With this feature enabled, remotes are retrieved (and displayed)
when getting (and displaying) the heads list.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
 gitweb/gitweb.perl |   31 +++++++++++++++++++++++++++++--
 1 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..b6c4233 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -327,6 +327,18 @@ our %feature = (
 	'ctags' => {
 		'override' => 0,
 		'default' => [0]},
+
+	# Make gitweb show remotes too in the heads list
+
+	# To enable system wide have in $GITWEB_CONFIG
+	# $feature{'remote_heads'}{'default'} = [1];
+	# To have project specific config enable override in $GITWEB_CONFIG
+	# $feature{'remote_heads'}{'override'} = 1;
+	# and in project config gitweb.remote_heads = 0|1;
+	'remote_heads' => {
+		'sub' => \&feature_remote_heads,
+		'override' => 0,
+		'default' => [0]},
 );
 
 sub gitweb_check_feature {
@@ -392,6 +404,18 @@ sub feature_pickaxe {
 	return ($_[0]);
 }
 
+sub feature_remote_heads {
+	my ($val) = git_get_project_config('remote_heads', '--bool');
+
+	if ($val eq 'true') {
+		return (1);
+	} elsif ($val eq 'false') {
+		return (0);
+	}
+
+	return ($_[0]);
+}
+
 # checking HEAD file with -e is fragile if the repository was
 # initialized long time ago (i.e. symlink HEAD) and was pack-ref'ed
 # and then pruned.
@@ -2642,10 +2666,12 @@ sub git_get_heads_list {
 	my $limit = shift;
 	my @headslist;
 
+	my ($remote_heads) = gitweb_check_feature('remote_heads');
+
 	open my $fd, '-|', git_cmd(), 'for-each-ref',
 		($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
 		'--format=%(objectname) %(refname) %(subject)%00%(committer)',
-		'refs/heads'
+		'refs/heads', ( $remote_heads ? 'refs/remotes' : '')
 		or return;
 	while (my $line = <$fd>) {
 		my %ref_item;
@@ -2656,8 +2682,9 @@ sub git_get_heads_list {
 		my ($committer, $epoch, $tz) =
 			($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
 		$ref_item{'fullname'}  = $name;
-		$name =~ s!^refs/heads/!!;
+		$name =~ s!^refs/(head|remote)s/!!;
 
+		$ref_item{'class'} = $1;
 		$ref_item{'name'}  = $name;
 		$ref_item{'id'}    = $hash;
 		$ref_item{'title'} = $title || '(no commit message)';
-- 
1.5.6.5

^ permalink raw reply related

* [PATCH v2 00/11] gitweb: display remote heads
From: Giuseppe Bilotta @ 2008-11-13 22:49 UTC (permalink / raw)
  To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta

This is a patchset I presented about a year ago or so, but after a lively
discussion it dropped into silence. I'm now presenting it again, with minor
cleanups and adjustements.

Giuseppe Bilotta (11):
  gitweb: introduce remote_heads feature
  gitweb: git_get_heads_list accepts an optional list of refs.
  gitweb: separate heads and remotes list in summary view
  gitweb: optional custom name for refs in git_heads_body
  gitweb: git_split_heads_body function.
  gitweb: use CSS to style split head lists.
  gitweb: add 'remotes' action
  gitweb: display HEAD in heads list when detached
  gitweb: git_is_head_detached() function
  gitweb: add HEAD to list of shortlog refs if detached
  gitweb: CSS style and refs mark for detached HEAD

 gitweb/gitweb.css  |   15 ++++++
 gitweb/gitweb.perl |  138 ++++++++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 143 insertions(+), 10 deletions(-)

^ permalink raw reply

* Re: [BUG] git ls-files -m --with-tree does double output
From: Junio C Hamano @ 2008-11-13 22:39 UTC (permalink / raw)
  To: Anders Melchiorsen; +Cc: gitster, git
In-Reply-To: <7vod0jfe51.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> What's the use case of using -m together with --with-tree to begin with?
> I think the only sensible other option that makes sense with --with-tree
> is --error-unmatch.

The reason I ask this question is that the cleanest fix to the issue might
turn out to be to forbid that combination of the options, if it turns out
that it does not make any sense.

^ permalink raw reply

* Re: [BUG] git ls-files -m --with-tree does double output
From: Junio C Hamano @ 2008-11-13 22:35 UTC (permalink / raw)
  To: Anders Melchiorsen; +Cc: gitster, git
In-Reply-To: <37512.N1gUGH5fRhE=.1226613228.squirrel@webmail.hotelhot.dk>

"Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:

> and@dylle:~/repo$ git ls-files -m --with-tree=HEAD
> a
> a
>
>
> Jeff King added:
> ...
> It isn't clear to me which code is _supposed_ to be pulling out such
> duplicates here. That is, is read_tree broken, or is
> overlay_tree_on_cache just calling it wrong?

I had to look up what -m meant in ls-files, as I never considered that
option as part of the plumbing.

What's the use case of using -m together with --with-tree to begin with?
I think the only sensible other option that makes sense with --with-tree
is --error-unmatch.

^ permalink raw reply

* Re: [BUG] fatal error during merge
From: Anders Melchiorsen @ 2008-11-13 22:25 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: Alex Riesen, git
In-Reply-To: <20081113180931.GE29274@neumann>

SZEDER Gábor wrote:

> Well, oddly enough, your second test case behaves somewhat differently
> than the first one, at least as far as bisect is concerned.  Bisect
> nails down the second test case to 0d5e6c97 (Ignore merged status of
> the file-level merge, 2007-04-26; put Alex on Cc).  Reverting this
> commit on master makes both of your test cases pass.

Hmm. With that one reverted, git prints out this error instead:

error: failed to create path 'after/one': perhaps a D/F conflict?

and still has the moved file disapper in the working tree. The merge is
successful, though, and the moved file is in the committed tree.


Anders.

^ permalink raw reply

* Re: [EGIT PATCH 1/7] Test the origName part of the key vs the ref itself
From: Robin Rosenberg @ 2008-11-13 22:13 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081111180520.GN2932@spearce.org>

tisdag 11 november 2008 19:05:20 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > @@ -127,4 +129,12 @@ public void testDeleteEmptyDirs() throws IOException {
> >  	private void assertExists(final boolean expected, final String name) {
> >  		assertEquals(expected, new File(db.getDirectory(), name).exists());
> >  	}
> > +
> > +	public void testRefKeySameAsOrigName() {
> > +		Map<String, Ref> allRefs = db.getAllRefs();
> > +		for (Entry<String, Ref> e : allRefs.entrySet()) {
> > +			assertEquals(e.getKey(), e.getValue().getOrigName());
> > +
> > +		}
> > +	}
> 
> Hmm, doesn't this have to go after "Keep original ref name ..."
> so getOrigName() is actually defined?

Oops, Seems we should try to build each new commit before accepting
a push. Shouldn't be too hard.

-- robin

^ permalink raw reply

* Re: post-update hook
From: Junio C Hamano @ 2008-11-13 22:06 UTC (permalink / raw)
  To: Jeremy Ramer; +Cc: Junio C Hamano, git
In-Reply-To: <b9fd99020811131048p741cd9aqdcdf4cf410830915@mail.gmail.com>

"Jeremy Ramer" <jdramer@gmail.com> writes:

> I had to make one change to this example to get it to work.  I'll put
> it here for completeness
>
> #!/bin/sh
> case "$*" in
> "refs/remotes/origin/master")
>     cd ..
>     GIT_DIR=".git"
>     git merge refs/remotes/origin/master
>     ;;
> esac

Yeah, thanks for correction.  My bad not resetting GIT_DIR.

By the way, I _did_ write these seemingly extra spaces around $* and the
refname on purpose.

^ permalink raw reply

* Re: [PATCH (GITK)] gitk: Make line origin search update the busy status.
From: Paul Mackerras @ 2008-11-13 22:00 UTC (permalink / raw)
  To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200811132343.13910.angavrilov@gmail.com>

Alexander Gavrilov writes:

> Currently the 'show origin of this line' feature does
> not update the status field of the gitk window, so it
> is not evident that any processing is going on. It may
> seem at first that clicking the item had no effect.
> 
> This commit adds calls to set and clear the busy
> status with an appropriate title, similar to other
> search commands.

I have been meaning to do this myself.  I want to find something
better than "Blaming" to put in the status field, though, since
"blaming" is jargon in this context.  Actually, "Searching" would
probably do.

Paul.

^ permalink raw reply

* Re: Any plans to support JTA and XA in jgit?
From: Robin Rosenberg @ 2008-11-13 21:54 UTC (permalink / raw)
  To: Farrukh Najmi; +Cc: git
In-Reply-To: <491C8DBE.9080105@wellfleetsoftware.com>

torsdag 13 november 2008 21:27:42 skrev Farrukh Najmi:
> A totally separate issue I have to sort out is how to handle multiple 
> unrelated transactions that are modifying the same git repo. If a 
> transaction needs to be rolled back how do roll back exactly some 
> changes in some files in git that were impacted by the transaction. This 
> is not easy because git (and most VCS) do not have transaction isolation 
> like databases do. Any suggestions?
Updating the head ref is the hard part, but we have locking already there
and it is atomic on any sane file system. There is no waiting implemented
so one gets an error if two threads try to update the same head simultaneously.
Seems doable I'd say. For server use one could wrap the repo with a real database,
and just let the disk based refs mirror the database view,  though that is quite a bit
off focus for my own needs.

> I am not very well versed in tag libraries myself. My situation is one 
> where everything happens inside a SOAP service endpoint and so I suspect 
> JSP tag libraries are not likely to be useful in that situation. Let me 
> know if I am wrong in this assessment.
not at all.

-- robin

^ permalink raw reply

* [BUG] git ls-files -m --with-tree does double output
From: Anders Melchiorsen @ 2008-11-13 21:53 UTC (permalink / raw)
  To: gitster; +Cc: git

Junio, I am resending this one because I am not sure whether you ignored
it on purpose, or it got lost during your vacation.

The combination of -m and --with-tree shows duplicate entries:

and@dylle:~$ mkdir repo ; cd repo
and@dylle:~/repo$ git init
Initialized empty Git repository in /home/and/repo/.git/
and@dylle:~/repo$ date >a ; git add a ; git commit -m'Add 1'
Created initial commit c027435: Add 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 a
and@dylle:~/repo$ date >a
and@dylle:~/repo$ git ls-files -m --with-tree=HEAD
a
a


Jeff King added:

I have confirmed this, and it looks like it has always been that way. It
looks like overlay_tree_on_cache just does a read_tree to pull the tree
into the index, and then we end up with duplicate entries.

I'm not too familiar with the read_tree code, so I am cc'ing Junio (who
is out of touch for a little while) and Linus, who are much more clueful
in this area.

It isn't clear to me which code is _supposed_ to be pulling out such
duplicates here. That is, is read_tree broken, or is
overlay_tree_on_cache just calling it wrong?



Anders.

^ permalink raw reply

* Re: problem with git gui on cygwin.
From: Pascal Obry @ 2008-11-13 21:06 UTC (permalink / raw)
  To: Jim Jensen; +Cc: git
In-Reply-To: <loom.20081111T155614-227@post.gmane.org>

Jim Jensen a écrit :
> I have been trying to use git for a small project using cygwin.  I copied my
> repository from one windows XP system to a Vista system using a usb drive.  On
> the new system when I use "git gui" I get a pop up that says "Git directory not
> found: .git"

I had some problems with Git UI and Tk. It does not look like the
problem you have but we never know. Can you try:

   $ CYGWIN="" gitk

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

^ permalink raw reply

* Re: hosting git on a nfs
From: Linus Torvalds @ 2008-11-13 21:05 UTC (permalink / raw)
  To: James Pickens, Bruce Fields, Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811131214020.3468@nehalem.linux-foundation.org>



On Thu, 13 Nov 2008, Linus Torvalds wrote:
> 
> If I were still using NFS (I gave up on it years ago exactly because it 
> was so painful for software development - and that was when I was using 
> CVS) I'd surely have done it long since.
> 
> Bit I'll think about it again. 

THIS IS TOTALLY UNTESTED! It's trivial, it's hacky, and it would need to 
be cleaned up before being merged, but I'm not even going to bother 
_trying_ to make it anything cleaner unless somebody can test it on a nice 
NFS setup.

Because it's entirely possible that there are various directory inode 
locks etc that means that doing parallel lookups in the same directory 
won't actually be doing a whole lot. Whatever. It's kind of cute, and it 
really isn't all that many lines of code, and even if it doesn't work due 
to some locking reason, maybe it's worth looking at.

It arbitrarily caps the number of threads to 10, and it has no way to turn 
it on or off. It actually _does_ seem to work in the sense than when 
cached, it can take advantage of the fact that I have a nice multi-core 
thing, but let's face it, it's not really worth it for that reason only. 

Before:

	[torvalds@nehalem linux]$ /usr/bin/time git diff > /dev/null 
	0.03user 0.04system 0:00.07elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k

After:

	0.02user 0.07system 0:00.04elapsed 243%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+2241minor)pagefaults 0swaps

ie it actually did cut elapsed time from 7 hundredths of a second to just 
4. And the CPU usage went from 100% to 243%. Ooooh. Magic.

But it's still hacky as hell. Who has NFS? Can you do the same thing over 
NFS and test it? I'm not going to set up NFS to test this, and as I 
suspected, on a local disk, the cold-cache case makes no difference 
what-so-ever, because whatever seek optimizations can be done are still 
totally irrelevant.

And if there are per-directory locking etc that screws this up, we can 
look at using different heuristics for the lstat() patterns. Right now I 
divvy it up so that thread 0 gets entries 0, 10, 20, 30.. and thread 1 
does entries 1, 11, 21, 31.., but we could easily split it up differently, 
and do 0,1,2,3.. and 1000,1001,1002,1003.. instead. That migth avoid some 
per-directory locks. Dunno.

Anyway, it was kind of fun writing this. The reason it threads so well is 
that all the lstat() code really works on private data already, so there 
are no global data structures that change that need to be worried about. 

So no locking necessary - just fire it up in parallel, and wait for the 
results. We already had everything else in place (ie the per-cache_entry 
flag to say "I've checked this entry on disk").

Of course, if a lot of entries do _not_ match, then this will actually 
generate more work (because we'll do the parallel thing to verify that 
the on-disk version matches, and if it doesn't match, then we'll end up 
re-doing it linearly later more carefully).

			Linus

---
 diff-lib.c |   67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/diff-lib.c b/diff-lib.c
index ae96c64..7d972c9 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -1,6 +1,7 @@
 /*
  * Copyright (C) 2005 Junio C Hamano
  */
+#include <pthread.h>
 #include "cache.h"
 #include "quote.h"
 #include "commit.h"
@@ -54,6 +55,70 @@ static int check_removed(const struct cache_entry *ce, struct stat *st)
 	return 0;
 }
 
+/* Hacky hack-hack start */
+#define MAX_PARALLEL (10)
+static int parallel_lstats = 1;
+
+struct thread_data {
+	pthread_t pthread;
+	struct index_state *index;
+	struct rev_info *revs;
+	int i, step;
+};
+
+static void *preload_thread(void *_data)
+{
+	int i;
+	struct thread_data *p = _data;
+	struct index_state *index = p->index;
+	struct rev_info *revs = p->revs;
+
+	for (i = p->i; i < index->cache_nr; i += p->step) {
+		struct cache_entry *ce = index->cache[i];
+		struct stat st;
+
+		if (ce_stage(ce))
+			continue;
+		if (ce_uptodate(ce))
+			continue;
+		if (!ce_path_match(ce, revs->prune_data))
+			continue;
+		if (lstat(ce->name, &st))
+			continue;
+		if (ie_match_stat(index, ce, &st, 0))
+			continue;
+		ce_mark_uptodate(ce);
+	}
+	return NULL;
+}
+
+static void preload_uptodate(struct rev_info *revs, struct index_state *index)
+{
+	int i;
+	int threads = index->cache_nr / 100;
+	struct thread_data data[MAX_PARALLEL];
+
+	if (threads < 2)
+		return;
+	if (threads > MAX_PARALLEL)
+		threads = MAX_PARALLEL;
+	for (i = 0; i < threads; i++) {
+		struct thread_data *p = data+i;
+		p->index = index;
+		p->revs = revs;
+		p->i = i;
+		p->step = threads;
+		if (pthread_create(&p->pthread, NULL, preload_thread, p))
+			die("unable to create threaded lstat");
+	}
+	for (i = 0; i < threads; i++) {
+		struct thread_data *p = data+i;
+		if (pthread_join(p->pthread, NULL))
+			die("unable to join threaded lstat");
+	}
+}
+/* Hacky hack-hack mostly ends */
+
 int run_diff_files(struct rev_info *revs, unsigned int option)
 {
 	int entries, i;
@@ -68,6 +133,8 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
 	if (diff_unmerged_stage < 0)
 		diff_unmerged_stage = 2;
 	entries = active_nr;
+	if (parallel_lstats)
+		preload_uptodate(revs, &the_index);
 	symcache[0] = '\0';
 	for (i = 0; i < entries; i++) {
 		struct stat st;

^ permalink raw reply related

* [PATCH (GITK)] gitk: Make line origin search update the busy status.
From: Alexander Gavrilov @ 2008-11-13 20:43 UTC (permalink / raw)
  To: git; +Cc: Paul Mackerras

Currently the 'show origin of this line' feature does
not update the status field of the gitk window, so it
is not evident that any processing is going on. It may
seem at first that clicking the item had no effect.

This commit adds calls to set and clear the busy
status with an appropriate title, similar to other
search commands.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
 gitk |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/gitk b/gitk
index e4562d7..3fb9c44 100755
--- a/gitk
+++ b/gitk
@@ -3400,6 +3400,7 @@ proc show_line_source {} {
 	error_popup [mc "Couldn't start git blame: %s" $err]
 	return
     }
+    nowbusy blaming [mc "Blaming"]
     fconfigure $f -blocking 0
     set i [reg_instance $f]
     set blamestuff($i) {}
@@ -3413,6 +3414,7 @@ proc stopblaming {} {
     if {[info exists blameinst]} {
 	stop_instance $blameinst
 	unset blameinst
+	notbusy blaming
     }
 }
 
@@ -3427,6 +3429,7 @@ proc read_line_source {fd inst} {
     }
     unset commfd($inst)
     unset blameinst
+    notbusy blaming
     fconfigure $fd -blocking 1
     if {[catch {close $fd} err]} {
 	error_popup [mc "Error running git blame: %s" $err]
-- 
1.6.0.3.15.gb8d36

^ permalink raw reply related

* Re: Any plans to support JTA and XA in jgit?
From: Farrukh Najmi @ 2008-11-13 20:27 UTC (permalink / raw)
  To: Robin Rosenberg; +Cc: git
In-Reply-To: <200811132059.16616.robin.rosenberg.lists@dewire.com>

Robin Rosenberg wrote:
> torsdag 13 november 2008 20:20:49 skrev Farrukh Najmi:
>   
>> Does the gjit team have any plans to implement support for JTA in gjit 
>> so as to allow distributed transactions using 2 phase commit? This would 
>> be very powerful when git is being used in conjunction with other 
>> transaction resource managers such as databases.
>>     
>
> No such plans exist. We do not even have a J2EE Resource Manager yet. I
> did some toying implementing one. As for XA support, I guess that would
> not be very hard per se, but my thoughts on JEE support was more in the direction
> of gitweb-like stuff, i.e. reading.
>   

I am not an expert on this but what I thought could be done is to 
enhance jgit so it can serve the role of a JTA compliant transactional 
resource manager similar to that in JDBC, JMS etc. As part of that it 
could serve resources as JTA XAResource.
Not sure how hard all this could be though.
> Trying to involve git in distributed database transactions might be cool, but seriously: Do you
> need it? 

The problem I am trying to solve is this. In my service I need to store 
metadata in a relational db and content in git such that both either 
commit or not in a single transaction. If one commits and the other does 
not that is a serious integrity issue. Seems to me, two phase commit 
would be the right solution for that in the long run. This what JDBC + 
JMS topologies do.

A totally separate issue I have to sort out is how to handle multiple 
unrelated transactions that are modifying the same git repo. If a 
transaction needs to be rolled back how do roll back exactly some 
changes in some files in git that were impacted by the transaction. This 
is not easy because git (and most VCS) do not have transaction isolation 
like databases do. Any suggestions?

> As for JEE my ideas are: A nice JSP tag library and a resource manager. When is
> an entirely different question, as is who. Did you look at  my experiment in a reply of mine
> in another recent jgit thread?
>   

I am not very well versed in tag libraries myself. My situation is one 
where everything happens inside a SOAP service endpoint and so I suspect 
JSP tag libraries are not likely to be useful in that situation. Let me 
know if I am wrong in this assessment.

> The term "distributed" in XA is not quite the same as in distributed verison control. 
That is correct.

> If it would,
> then we'd send SQL commands over e-mail (now, /that/ would be cool :)

+1

Thanks very much for your help and that of other colleagues on the list.

-- 
Regards,
Farrukh Najmi

Web: http://www.wellfleetsoftware.com

^ permalink raw reply

* [PATCH] revision.c: use proper data type in call to sizeof() within xrealloc
From: Brandon Casey @ 2008-11-13 20:20 UTC (permalink / raw)
  To: gitster; +Cc: git

A type char** was being used instead of char*.
---


Just a little typo, that doesn't make any difference but should be fixed.

-brandon


 revision.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/revision.c b/revision.c
index 2f646de..440d152 100644
--- a/revision.c
+++ b/revision.c
@@ -968,7 +968,7 @@ static void add_ignore_packed(struct rev_info *revs, const char *name)
 	int num = ++revs->num_ignore_packed;
 
 	revs->ignore_packed = xrealloc(revs->ignore_packed,
-				       sizeof(const char **) * (num + 1));
+				       sizeof(const char *) * (num + 1));
 	revs->ignore_packed[num-1] = name;
 	revs->ignore_packed[num] = NULL;
 }
-- 
1.6.0.3.552.g12334

^ permalink raw reply related

* Re: problem with git gui on cygwin.
From: tejus das @ 2008-11-13 20:15 UTC (permalink / raw)
  To: git
In-Reply-To: <loom.20081112T142853-15@post.gmane.org>

Jim Jensen <jhjjhjjhj <at> gmail.com> writes:

> 
> Jim Jensen <jhjjhjjhj <at> gmail.com> writes:> 
> Any more ideas on things to try?
> 
> 

try running cygwin as windows administrator.. i see the same problem on 
vista... works when i run as admin

^ permalink raw reply

* Re: hosting git on a nfs
From: Linus Torvalds @ 2008-11-13 20:18 UTC (permalink / raw)
  To: James Pickens; +Cc: git
In-Reply-To: <loom.20081113T174625-994@post.gmane.org>



On Thu, 13 Nov 2008, James Pickens wrote:
> 
> Is there any way to improve 'git status' performance on nfs?  I know nothing
> about how that code works, but if it's strictly serial, i.e. it waits for the
> result of each lstat() before doing the next lstat(), then perhaps it could be
> sped up by overlapping the lstat() calls via multi threading.

It's fairly doable. "git status" to some degree is actually the worst 
case, since it has to do readdir()'s etc to find new files, but I've 
occasionally considered trying to do a parallel version of the regular 
index file checking where we have the list of files a priori.

That would speed up "git diff" by potentially a big amount (it would also 
speed up git status, just not as much as also doing readdirs in parallel).

However, every time I think about it, I end up looking at my own setup 
which has effectively no parallelism. Sure, in theory parallel reads can 
help even with a local disk, but in practice the potential seek advantage 
is very small, and so I've never really had it as a high priority.

If I were still using NFS (I gave up on it years ago exactly because it 
was so painful for software development - and that was when I was using 
CVS) I'd surely have done it long since.

Bit I'll think about it again. 

		Linus

^ permalink raw reply

* [PATCH (GITK)] gitk: Avoid handling the Return key twice in Add Branch.
From: Alexander Gavrilov @ 2008-11-13 20:09 UTC (permalink / raw)
  To: git; +Cc: Paul Mackerras

This reverts commit 63767d5fb8fe236d8fdeba44297ac925701b27a0.

A similar change was made as part of commit 76f15947af7,
that added bindings to all dialogs, and this duplication
causes mkbrgo to be called twice, the second time after
the window has been destroyed. As a result, an error
window appears when the code tries to access widgets.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
 gitk |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/gitk b/gitk
index 3353f4a..46896a2 100755
--- a/gitk
+++ b/gitk
@@ -8208,7 +8208,6 @@ proc mkbranch {} {
     grid $top.id $top.sha1 -sticky w
     label $top.nlab -text [mc "Name:"]
     entry $top.name -width 40
-    bind $top.name <Key-Return> "[list mkbrgo $top]"
     grid $top.nlab $top.name -sticky w
     frame $top.buts
     button $top.buts.go -text [mc "Create"] -command [list mkbrgo $top]
-- 
1.6.0.3.15.gb8d36

^ permalink raw reply related

* [PATCH (GITK)] gitk: Add a menu option to start Git Gui.
From: Alexander Gavrilov @ 2008-11-13 20:12 UTC (permalink / raw)
  To: git; +Cc: Paul Mackerras

Git Gui already has menu commands to start gitk,
and this makes the relation symmetric. Since gitk and
git-gui complement each other, I think that it is
beneficial to integrate them where it makes sense.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
 gitk |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/gitk b/gitk
index 46896a2..e4562d7 100755
--- a/gitk
+++ b/gitk
@@ -1906,6 +1906,9 @@ proc makewindow {} {
 	    {mc "Reload" command reloadcommits -accelerator Meta1-F5}
 	    {mc "Reread references" command rereadrefs}
 	    {mc "List references" command showrefs -accelerator F2}
+	    {xx "" separator}
+	    {mc "Start Git Gui" command {exec git gui &}}
+	    {xx "" separator}
 	    {mc "Quit" command doquit -accelerator Meta1-Q}
 	}}
 	{mc "Edit" cascade {
-- 
1.6.0.3.15.gb8d36

^ permalink raw reply related

* [PATCH] repack: only unpack-unreachable if we are deleting redundant packs
From: Brandon Casey @ 2008-11-13 20:11 UTC (permalink / raw)
  To: gitster; +Cc: git

The -A option calls pack-objects with the --unpack-unreachable option so
that the unreachable objects in local packs are left in the local object
store loose. But if the -d option to repack was _not_ used, then these
unpacked loose objects are redundant and unnecessary.

Update tests in t7701.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---


Here is another patch for bc/maint-keep-pack that seems to make sense.
I can't think of a reason why porcelain repack should unpack the
unreferenced objects if it's not going to delete the packs they were in.

-brandon


 Documentation/git-repack.txt         |   11 +++++------
 git-repack.sh                        |    3 ++-
 t/t7701-repack-unpack-unreachable.sh |   18 +++++++++++++++---
 3 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index bbe1485..aaa8852 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -38,12 +38,11 @@ OPTIONS
 	dangling.
 
 -A::
-	Same as `-a`, but any unreachable objects in a previous
-	pack become loose, unpacked objects, instead of being
-	left in the old pack.  Unreachable objects are never
-	intentionally added to a pack, even when repacking.
-	When used with '-d', this option
-	prevents unreachable objects from being immediately
+	Same as `-a`, unless '-d' is used.  Then any unreachable
+	objects in a previous pack become loose, unpacked objects,
+	instead of being left in the old pack.  Unreachable objects
+	are never intentionally added to a pack, even when repacking.
+	This option prevents unreachable objects from being immediately
 	deleted by way of being left in the old pack and then
 	removed.  Instead, the loose unreachable objects
 	will be pruned according to normal expiry rules
diff --git a/git-repack.sh b/git-repack.sh
index 4d313d1..458a497 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -71,7 +71,8 @@ case ",$all_into_one," in
 				existing="$existing $e"
 			fi
 		done
-		if test -n "$args" -a -n "$unpack_unreachable"
+		if test -n "$args" -a -n "$unpack_unreachable" -a \
+			-n "$remove_redundant"
 		then
 			args="$args $unpack_unreachable"
 		fi
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index b48046e..63a8225 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -8,7 +8,7 @@ fsha1=
 csha1=
 tsha1=
 
-test_expect_success '-A option leaves unreachable objects unpacked' '
+test_expect_success '-A with -d option leaves unreachable objects unpacked' '
 	echo content > file1 &&
 	git add . &&
 	git commit -m initial_commit &&
@@ -58,7 +58,7 @@ compare_mtimes ()
 		' -- "$@"
 }
 
-test_expect_success 'unpacked objects receive timestamp of pack file' '
+test_expect_success '-A without -d option leaves unreachable objects packed' '
 	fsha1path=$(echo "$fsha1" | sed -e "s|\(..\)|\1/|") &&
 	fsha1path=".git/objects/$fsha1path" &&
 	csha1path=$(echo "$csha1" | sed -e "s|\(..\)|\1/|") &&
@@ -75,7 +75,19 @@ test_expect_success 'unpacked objects receive timestamp of pack file' '
 	git branch -D transient_branch &&
 	sleep 1 &&
 	git repack -A -l &&
-	compare_mtimes "$packfile" "$fsha1path" "$csha1path" "$tsha1path"
+	test ! -f "$fsha1path" &&
+	test ! -f "$csha1path" &&
+	test ! -f "$tsha1path" &&
+	git show $fsha1 &&
+	git show $csha1 &&
+	git show $tsha1
+'
+
+test_expect_success 'unpacked objects receive timestamp of pack file' '
+	tmppack=".git/objects/pack/tmp_pack" &&
+	ln "$packfile" "$tmppack" &&
+	git repack -A -l -d &&
+	compare_mtimes "$tmppack" "$fsha1path" "$csha1path" "$tsha1path"
 '
 
 test_done
-- 
1.6.0.3.552.g12334

^ permalink raw reply related

* Re: running out of memory when doing a clone of a large repository?
From: Paul E. Rybski @ 2008-11-13 20:09 UTC (permalink / raw)
  To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0811122206550.27509@xanadu.home>

Hi,
	Thanks for the great suggestions.  It turns out that running the command:

git repack -a -f -d

on the newly converted git repository seemed to fix my immediate
crashing-while-cloning problem.  I was able to clone via ssh from the
older Ubuntu machine with 1G of RAM using git version 1.5.4.3 (the
packaged version in Hardy Heron).

I also downloaded what seems to be the latest of the 1.5 series,
1.5.6.5, installed that from source, and successfully tested that out.
I'll try using that to avoid some of the memory problems of the previous
versions.  As I'm still comparatively a complete newbie when it comes to
git, I don't have a clue yet as to what's in the 1.6 codebase but
hopefully I'll be able to determine which version I want to work with soon.

Thanks again for the help!  I really appreciate it.

-Paul

Nicolas Pitre wrote:
> On Wed, 12 Nov 2008, Paul E. Rybski wrote:
> 
>> Hi,
>> 	I've recently started evaluating git for use on one of my projects.  I
>> used git-svn to convert a fairly large subversion repository and one of
>> its branches into two separate git repositories following the
>> instructions found here:
>>
>> http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/
>>
>> From that, I created a 1.5G repository from the trunk of the subversion
>> repo and a 1.1G repository from one of the branches.  I then tried to
>> clone the repositories from one machine to another via ssh and the
>> smaller 1.1G repository of the subversion branch (with 1932 commits)
>> came over just fine but the larger 1.5G repository of the subversion
>> trunk (5865 commits) died with the following error:
>>
>> remote: Counting objects: 48415, done.
>> remote: warning: suboptimal pack - out of memory
>> error: git-upload-pack: git-pack-objects died with error.
>> fatal: git-upload-pack: aborting due to possible repository corruption
>> on the remote side.
>> remote: aborting due to possible repository corruption on the remote side.
>> fatal: early EOF
>> fatal: index-pack failed
>>
>> Is this simply because the git repository is too large for the machine
>> that's trying to send it over ssh?
> 
> Possibly.
> 
>> Is there a way to restrict the memory usage of git or do I need to get 
>> more RAM or somehow not import the full subversion history of my 
>> original trunk?
> 
> It is possible that the inport from svn didn't produce a fully packed 
> repository.  Try a "git repack -a -f -d" on the server machine. If you 
> get the same out-of-memory problem then ideally you should copy the 
> whole directory to a bigger machine and run 'git repack -a -f -d" there.  
> Then you may copy it back to the small machine and subsequent clone 
> requests should be just fine.
> 
> You could also investigate the pack.windowMemory configuration variable 
> on the server side.  If you have lots of big files then setting this to 
> 64m for example may help.
> 
>> I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages
>> of git version 1.5.4.3.
> 
> There was a bug in versions prior to v1.5.6.4 affecting memory usage.  
> Upgrading to this version or later on the server machine might help too.
> 
>> The machine holding the repository is a 5-year
>> old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu.  The machine I'm
>> cloning the repository on is a more recent Intel Dual Core Quad Q6600
>> with 4GRAM and 64-bit Ubuntu.
>>
>> Any advice would be greatly appreciated.
>>
>> Thanks!
>>
>> -Paul

^ permalink raw reply

* Re: Any plans to support JTA and XA in jgit?
From: Robin Rosenberg @ 2008-11-13 20:07 UTC (permalink / raw)
  To: Farrukh Najmi; +Cc: git
In-Reply-To: <200811132057.32026.robin.rosenberg.lists@dewire.com>

torsdag 13 november 2008 20:57:31 skrev Robin Rosenberg:
> As for JEE my ideas are: A nice JSP tag library and a resource manager. When is
s/resource manager/resource connector/

-- robin

^ permalink raw reply

* Re: Any plans to support JTA and XA in jgit?
From: Robin Rosenberg @ 2008-11-13 19:59 UTC (permalink / raw)
  To: Farrukh Najmi; +Cc: git

torsdag 13 november 2008 20:20:49 skrev Farrukh Najmi:
> 
> Does the gjit team have any plans to implement support for JTA in gjit 
> so as to allow distributed transactions using 2 phase commit? This would 
> be very powerful when git is being used in conjunction with other 
> transaction resource managers such as databases.

No such plans exist. We do not even have a J2EE Resource Manager yet. I
did some toying implementing one. As for XA support, I guess that would
not be very hard per se, but my thoughts on JEE support was more in the direction
of gitweb-like stuff, i.e. reading.

Trying to involve git in distributed database transactions might be cool, but seriously: Do you
need it? As for JEE my ideas are: A nice JSP tag library and a resource manager. When is
an entirely different question, as is who. Did you look at  my experiment in a reply of mine
in another recent jgit thread?

The term "distributed" in XA is not quite the same as in distributed verison control. If it would,
then we'd send SQL commands over e-mail (now, /that/ would be cool :).

-- robin

^ permalink raw reply

* [PATCH (GIT-GUI) 2/3] git-gui: Add a Tools menu for arbitrary commands.
From: Alexander Gavrilov @ 2008-11-13 19:35 UTC (permalink / raw)
  To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226604950-18667-2-git-send-email-angavrilov@gmail.com>

Due to the emphasis on scriptability in the git
design, it is impossible to provide 100% complete
GUI. Currently unaccounted areas include git-svn
and other source control system interfaces, TopGit,
all custom scripts.

This problem can be mitigated by providing basic
customization capabilities in Git Gui. This commit
adds a new Tools menu, which can be configured
to contain items invoking arbitrary shell commands.

The interface is powerful enough to allow calling
both batch text programs like git-svn, and GUI editors.
To support the latter use, the commands have access
to the name of the currently selected file through
the environment.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
 git-gui.sh        |   17 ++++
 lib/tools.tcl     |  107 ++++++++++++++++++++++++
 lib/tools_dlg.tcl |  234 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 358 insertions(+), 0 deletions(-)
 create mode 100644 lib/tools.tcl
 create mode 100644 lib/tools_dlg.tcl

diff --git a/git-gui.sh b/git-gui.sh
index 34214b6..2efbe73 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2252,6 +2252,9 @@ if {[is_enabled transport]} {
 	.mbar add cascade -label [mc Merge] -menu .mbar.merge
 	.mbar add cascade -label [mc Remote] -menu .mbar.remote
 }
+if {[is_enabled multicommit] || [is_enabled singlecommit]} {
+	.mbar add cascade -label [mc Tools] -menu .mbar.tools
+}
 . configure -menu .mbar
 
 # -- Repository Menu
@@ -2526,6 +2529,20 @@ if {[is_MacOSX]} {
 		-command do_options
 }
 
+# -- Tools Menu
+#
+if {[is_enabled multicommit] || [is_enabled singlecommit]} {
+	set tools_menubar .mbar.tools
+	menu $tools_menubar
+	$tools_menubar add separator
+	$tools_menubar add command -label [mc "Add..."] -command tools_add::dialog
+	$tools_menubar add command -label [mc "Remove..."] -command tools_remove::dialog
+	set tools_tailcnt 3
+	if {[array names repo_config guitool.*.cmd] ne {}} {
+		tools_populate_all
+	}
+}
+
 # -- Help Menu
 #
 .mbar add cascade -label [mc Help] -menu .mbar.help
diff --git a/lib/tools.tcl b/lib/tools.tcl
new file mode 100644
index 0000000..0bef503
--- /dev/null
+++ b/lib/tools.tcl
@@ -0,0 +1,107 @@
+# git-gui Tools menu implementation
+
+proc tools_list {} {
+	global repo_config
+
+	set names {}
+	foreach item [array names repo_config guitool.*.cmd] {
+		lappend names [string range $item 8 end-4]
+	}
+	return [lsort $names]
+}
+
+proc tools_populate_all {} {
+	global tools_menubar tools_menutbl
+	global tools_tailcnt
+
+	set mbar_end [$tools_menubar index end]
+	set mbar_base [expr {$mbar_end - $tools_tailcnt}]
+	if {$mbar_base >= 0} {
+		$tools_menubar delete 0 $mbar_base
+	}
+
+	array unset tools_menutbl
+
+	foreach fullname [tools_list] {
+		tools_populate_one $fullname
+	}
+}
+
+proc tools_create_item {parent args} {
+	global tools_menubar tools_tailcnt
+	if {$parent eq $tools_menubar} {
+		set pos [expr {[$parent index end]-$tools_tailcnt+1}]
+		eval [list $parent insert $pos] $args
+	} else {
+		eval [list $parent add] $args
+	}
+}
+
+proc tools_populate_one {fullname} {
+	global tools_menubar tools_menutbl tools_id
+
+	if {![info exists tools_id]} {
+		set tools_id 0
+	}
+
+	set names [split $fullname '/']
+	set parent $tools_menubar
+	for {set i 0} {$i < [llength $names]-1} {incr i} {
+		set subname [join [lrange $names 0 $i] '/']
+		if {[info exists tools_menutbl($subname)]} {
+			set parent $tools_menutbl($subname)
+		} else {
+			set subid $parent.t$tools_id
+			tools_create_item $parent cascade \
+					-label [lindex $names $i] -menu $subid
+			menu $subid
+			set tools_menutbl($subname) $subid
+			set parent $subid
+			incr tools_id
+		}
+	}
+
+	tools_create_item $parent command \
+		-label [lindex $names end] \
+		-command [list tools_exec $fullname]
+}
+
+proc tools_exec {fullname} {
+	global repo_config env current_diff_path
+	global current_branch is_detached
+
+	if {[is_config_true "guitool.$fullname.needsfile"]} {
+		if {$current_diff_path eq {}} {
+			error_popup [mc "Running %s requires a selected file." $fullname]
+			return
+		}
+	}
+
+	if {[is_config_true "guitool.$fullname.confirm"]} {
+		if {[ask_popup [mc "Are you sure you want to run %s?" $fullname]] ne {yes}} {
+			return
+		}
+	}
+
+	set env(GIT_GUITOOL) $fullname
+	set env(FILENAME) $current_diff_path
+	if {$is_detached} {
+		set env(CUR_BRANCH) ""
+	} else {
+		set env(CUR_BRANCH) $current_branch
+	}
+
+	set cmdline $repo_config(guitool.$fullname.cmd)
+	if {[is_config_true "guitool.$fullname.noconsole"]} {
+		exec sh -c $cmdline &
+	} else {
+		set w [console::new \
+			[mc "Tool %s" $fullname] \
+			[mc "Running %s" $cmdline]]
+		console::exec $w [list sh -c $cmdline]
+	}
+
+	unset env(GIT_GUITOOL)
+	unset env(FILENAME)
+	unset env(CUR_BRANCH)
+}
diff --git a/lib/tools_dlg.tcl b/lib/tools_dlg.tcl
new file mode 100644
index 0000000..c221ba9
--- /dev/null
+++ b/lib/tools_dlg.tcl
@@ -0,0 +1,234 @@
+# git-gui Tools menu dialogs
+
+class tools_add {
+
+field w              ; # widget path
+field w_name         ; # new remote name widget
+field w_cmd          ; # new remote location widget
+
+field name         {}; # name of the tool
+field command      {}; # command to execute
+field add_global    0; # add to the --global config
+field no_console    0; # disable using the console
+field needs_file    0; # ensure filename is set
+field confirm       0; # ask for confirmation
+
+constructor dialog {} {
+	global repo_config
+
+	make_toplevel top w
+	wm title $top [append "[appname] ([reponame]): " [mc "Add Tool"]]
+	if {$top ne {.}} {
+		wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
+		wm transient $top .
+	}
+
+	label $w.header -text [mc "Add New Tool Command"] -font font_uibold
+	pack $w.header -side top -fill x
+
+	frame $w.buttons
+	checkbutton $w.buttons.global \
+		-text [mc "Add globally"] \
+		-variable @add_global
+	pack $w.buttons.global -side left -padx 5
+	button $w.buttons.create -text [mc Add] \
+		-default active \
+		-command [cb _add]
+	pack $w.buttons.create -side right
+	button $w.buttons.cancel -text [mc Cancel] \
+		-command [list destroy $w]
+	pack $w.buttons.cancel -side right -padx 5
+	pack $w.buttons -side bottom -fill x -pady 10 -padx 10
+
+	labelframe $w.desc -text [mc "Tool Details"]
+
+	label $w.desc.name_cmnt -anchor w\
+		-text [mc "Use '/' separators to create a submenu tree:"]
+	grid x $w.desc.name_cmnt -sticky we -padx {0 5} -pady {0 2}
+	label $w.desc.name_l -text [mc "Name:"]
+	set w_name $w.desc.name_t
+	entry $w_name \
+		-borderwidth 1 \
+		-relief sunken \
+		-width 40 \
+		-textvariable @name \
+		-validate key \
+		-validatecommand [cb _validate_name %d %S]
+	grid $w.desc.name_l $w_name -sticky we -padx {0 5}
+
+	label $w.desc.cmd_l -text [mc "Command:"]
+	set w_cmd $w.desc.cmd_t
+	entry $w_cmd \
+		-borderwidth 1 \
+		-relief sunken \
+		-width 40 \
+		-textvariable @command
+	grid $w.desc.cmd_l $w_cmd -sticky we -padx {0 5} -pady {0 3}
+
+	grid columnconfigure $w.desc 1 -weight 1
+	pack $w.desc -anchor nw -fill x -pady 5 -padx 5
+
+	checkbutton $w.confirm \
+		-text [mc "Ask for confirmation before running"] \
+		-variable @confirm
+	pack $w.confirm -anchor w -pady {5 0} -padx 5
+
+	checkbutton $w.noconsole \
+		-text [mc "Don't show the command output window"] \
+		-variable @no_console
+	pack $w.noconsole -anchor w -padx 5
+
+	checkbutton $w.needsfile \
+		-text [mc "Run only if a diff is selected (\$FILENAME not empty)"] \
+		-variable @needs_file
+	pack $w.needsfile -anchor w -padx 5
+
+	bind $w <Visibility> [cb _visible]
+	bind $w <Key-Escape> [list destroy $w]
+	bind $w <Key-Return> [cb _add]\;break
+	tkwait window $w
+}
+
+method _add {} {
+	global repo_config
+
+	if {$name eq {}} {
+		error_popup [mc "Please supply a name for the tool."]
+		focus $w_name
+		return
+	}
+
+	set item "guitool.$name.cmd"
+
+	if {[info exists repo_config($item)]} {
+		error_popup [mc "Tool '%s' already exists." $name]
+		focus $w_name
+		return
+	}
+
+	set cmd [list git config]
+	if {$add_global} { lappend cmd --global }
+	set items {}
+	if {$no_console} { lappend items "guitool.$name.noconsole" }
+	if {$confirm}    { lappend items "guitool.$name.confirm" }
+	if {$needs_file} { lappend items "guitool.$name.needsfile" }
+
+	if {[catch {
+		eval $cmd [list $item $command]
+		foreach citem $items { eval $cmd [list $citem yes] }
+	    } err]} {
+		error_popup [mc "Could not add tool:\n%s" $err]
+	} else {
+		set repo_config($item) $command
+		foreach citem $items { set repo_config($citem) yes }
+
+		tools_populate_all
+	}
+
+	destroy $w
+}
+
+method _validate_name {d S} {
+	if {$d == 1} {
+		if {[regexp {[~?*&\[\0\"\\\{]} $S]} {
+			return 0
+		}
+	}
+	return 1
+}
+
+method _visible {} {
+	grab $w
+	$w_name icursor end
+	focus $w_name
+}
+
+}
+
+class tools_remove {
+
+field w              ; # widget path
+field w_names        ; # name list
+
+constructor dialog {} {
+	global repo_config global_config system_config
+
+	load_config 1
+
+	make_toplevel top w
+	wm title $top [append "[appname] ([reponame]): " [mc "Remove Tool"]]
+	if {$top ne {.}} {
+		wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
+		wm transient $top .
+	}
+
+	label $w.header -text [mc "Remove Tool Commands"] -font font_uibold
+	pack $w.header -side top -fill x
+
+	frame $w.buttons
+	button $w.buttons.create -text [mc Remove] \
+		-default active \
+		-command [cb _remove]
+	pack $w.buttons.create -side right
+	button $w.buttons.cancel -text [mc Cancel] \
+		-command [list destroy $w]
+	pack $w.buttons.cancel -side right -padx 5
+	pack $w.buttons -side bottom -fill x -pady 10 -padx 10
+
+	frame $w.list
+	set w_names $w.list.l
+	listbox $w_names \
+		-height 10 \
+		-width 30 \
+		-selectmode extended \
+		-exportselection false \
+		-yscrollcommand [list $w.list.sby set]
+	scrollbar $w.list.sby -command [list $w.list.l yview]
+	pack $w.list.sby -side right -fill y
+	pack $w.list.l -side left -fill both -expand 1
+	pack $w.list -fill both -expand 1 -pady 5 -padx 5
+
+	set local_cnt 0
+	foreach fullname [tools_list] {
+		# Cannot delete system tools
+		if {[info exists system_config(guitool.$fullname.cmd)]} continue
+
+		$w_names insert end $fullname
+		if {![info exists global_config(guitool.$fullname.cmd)]} {
+			$w_names itemconfigure end -foreground blue
+			incr local_cnt
+		}
+	}
+
+	if {$local_cnt > 0} {
+		label $w.colorlbl -foreground blue \
+			-text [mc "(Blue denotes repository-local tools)"]
+		pack $w.colorlbl -fill x -pady 5 -padx 5
+	}
+
+	bind $w <Visibility> [cb _visible]
+	bind $w <Key-Escape> [list destroy $w]
+	bind $w <Key-Return> [cb _remove]\;break
+	tkwait window $w
+}
+
+method _remove {} {
+	foreach i [$w_names curselection] {
+		set name [$w_names get $i]
+
+		catch { git config --remove-section guitool.$name }
+		catch { git config --global --remove-section guitool.$name }
+	}
+
+	load_config 0
+	tools_populate_all
+
+	destroy $w
+}
+
+method _visible {} {
+	grab $w
+	focus $w_names
+}
+
+}
-- 
1.6.0.3.15.gb8d36

^ permalink raw reply related

* [PATCH (GIT-GUI) 1/3] git-gui: Implement system-wide configuration handling.
From: Alexander Gavrilov @ 2008-11-13 19:35 UTC (permalink / raw)
  To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1226604950-18667-1-git-send-email-angavrilov@gmail.com>

With the old implementation any system-wide options appear
to be set locally in the current repository. This commit
adds explicit handling of system options, essentially
interpreting them as customized default_config.

The difficulty in interpreting system options stems from
the fact that simple 'git config' lists all values, while
'git config --global' only values set in ~/.gitconfig,
excluding both local and system options.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
 git-gui.sh     |   12 +++++++++---
 lib/option.tcl |   12 ++++++------
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index cf9ef6e..34214b6 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -918,19 +918,25 @@ git-version proc _parse_config {arr_name args} {
 }
 
 proc load_config {include_global} {
-	global repo_config global_config default_config
+	global repo_config global_config system_config default_config
 
 	if {$include_global} {
+		_parse_config system_config --system
 		_parse_config global_config --global
 	}
 	_parse_config repo_config
 
 	foreach name [array names default_config] {
+		if {[catch {set v $system_config($name)}]} {
+			set system_config($name) $default_config($name)
+		}
+	}
+	foreach name [array names system_config] {
 		if {[catch {set v $global_config($name)}]} {
-			set global_config($name) $default_config($name)
+			set global_config($name) $system_config($name)
 		}
 		if {[catch {set v $repo_config($name)}]} {
-			set repo_config($name) $default_config($name)
+			set repo_config($name) $system_config($name)
 		}
 	}
 }
diff --git a/lib/option.tcl b/lib/option.tcl
index c80c939..1d55b49 100644
--- a/lib/option.tcl
+++ b/lib/option.tcl
@@ -25,7 +25,7 @@ proc config_check_encodings {} {
 
 proc save_config {} {
 	global default_config font_descs
-	global repo_config global_config
+	global repo_config global_config system_config
 	global repo_config_new global_config_new
 	global ui_comm_spell
 
@@ -49,7 +49,7 @@ proc save_config {} {
 	foreach name [array names default_config] {
 		set value $global_config_new($name)
 		if {$value ne $global_config($name)} {
-			if {$value eq $default_config($name)} {
+			if {$value eq $system_config($name)} {
 				catch {git config --global --unset $name}
 			} else {
 				regsub -all "\[{}\]" $value {"} value
@@ -284,17 +284,17 @@ proc do_options {} {
 }
 
 proc do_restore_defaults {} {
-	global font_descs default_config repo_config
+	global font_descs default_config repo_config system_config
 	global repo_config_new global_config_new
 
 	foreach name [array names default_config] {
-		set repo_config_new($name) $default_config($name)
-		set global_config_new($name) $default_config($name)
+		set repo_config_new($name) $system_config($name)
+		set global_config_new($name) $system_config($name)
 	}
 
 	foreach option $font_descs {
 		set name [lindex $option 0]
-		set repo_config(gui.$name) $default_config(gui.$name)
+		set repo_config(gui.$name) $system_config(gui.$name)
 	}
 	apply_config
 
-- 
1.6.0.3.15.gb8d36

^ 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