Git development
 help / color / mirror / Atom feed
* Re: Official Git Homepage change? Re: git-scm.com
From: Jakub Narebski @ 2008-07-26 20:24 UTC (permalink / raw)
  To: Petr Baudis; +Cc: Scott Chacon, Junio C Hamano, git
In-Reply-To: <20080726201751.GU10151@machine.or.cz>

Petr Baudis <pasky@suse.cz> writes:

> On Fri, Jul 25, 2008 at 11:43:55PM -0700, Scott Chacon wrote:
> > However, I have evangelized Git in person to literally thousands of
> > people, and tens of thousands more online.  GitHub hosts over 10,000
> > public git projects completely for free, and has contributed a ton
> > back to the community, both in code and proselytization efforts.
> 
> I certainly agree that GitHub has done a lot for spreading Git; the
> mention of code is interesting, though. There is Grist and the GitHooks;
> anything else? It's a pity Grist wasn't even announced at the mailing
> list. :-(

And neither project was added to Git Wiki:
  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools

It looks like GitHub-bers are a bit of splinter faction.  Thank you
Scott Chacon for trying to change this...

P.S. What about http://git-scm.org/ ?
-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply

* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 20:32 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Scott Chacon, Junio C Hamano, jonas.fonseca, git
In-Reply-To: <m34p6cv1gl.fsf@localhost.localdomain>

On Sat, Jul 26, 2008 at 01:24:05PM -0700, Jakub Narebski wrote:
> P.S. What about http://git-scm.org/ ?

This domain is kept by Jonas Fonseca and it seems to be used at
occassions. It traditionally pointed to git.or.cz; thus I think it would
make sense for it to keep following git.or.cz unless/until we decide to
repoint that to git-scm.com. Jonas?

				Petr "Pasky" Baudis

^ permalink raw reply

* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Sixt @ 2008-07-26 20:37 UTC (permalink / raw)
  To: Steffen Prohaska; +Cc: git, Junio C Hamano
In-Reply-To: <1217065304-27815-1-git-send-email-prohaska@zib.de>

Zitat von Steffen Prohaska <prohaska@zib.de>:
> With MinGW's
>
>    gcc.exe (GCC) 3.4.5 (mingw special)
>    GNU ld version 2.17.50 20060824
>
> the old define caused link errors:
>
>    git.o: In function `main':
>    C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
>    collect2: ld returned 1 exit status
>
> The modified define works.

I have the same tools, but not this error. ???

-- Hannes

^ permalink raw reply

* Re: [PATCH v2] Support copy and rename detection in fast-export.
From: Alexander Gavrilov @ 2008-07-26 20:52 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <20080726202103.GA15769@spearce.org>

Although it does not matter for Git itself, tools that
export to systems that explicitly track copies and
renames can benefit from such information.

This patch makes fast-export output correct action
logs when -M or -C are enabled.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---

	On Sunday 27 July 2008 00:21:03 Shawn O. Pearce wrote:
	> Do you mean to say git-fast-export in the end of the first line of
	> that last paragraph?

	Yes, of course. Thank you.

	By the way, I see that http://git.kernel.org/?p=gitk/gitk.git;a=summary
	hasn't been updated for 2 months. Did the main gitk repository move
	to some other place?

	-- Alexander

 Documentation/git-fast-export.txt |    9 +++++++
 builtin-fast-export.c             |   28 +++++++++++++++++++++-
 t/t9301-fast-export.sh            |   46 +++++++++++++++++++++++++++++++++++++
 3 files changed, 81 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
index 332346c..bb2f9a8 100644
--- a/Documentation/git-fast-export.txt
+++ b/Documentation/git-fast-export.txt
@@ -36,6 +36,15 @@ when encountering a signed tag.  With 'strip', the tags will be made
 unsigned, with 'verbatim', they will be silently exported
 and with 'warn', they will be exported, but you will see a warning.
 
+-M, -C::
+	Perform move and/or copy detection, as described in the
+	linkgit:git-diff[1] manual page, and use it to generate
+	rename and copy commands in the output dump.
++
+Note that these options were always accepted by git-fast-export,
+but before a certain version it silently produced wrong results.
+You should always check the git version before using them.
+
 
 EXAMPLES
 --------
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 8bea269..3225e8f 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -118,10 +118,27 @@ static void show_filemodify(struct diff_queue_struct *q,
 {
 	int i;
 	for (i = 0; i < q->nr; i++) {
+		struct diff_filespec *ospec = q->queue[i]->one;
 		struct diff_filespec *spec = q->queue[i]->two;
-		if (is_null_sha1(spec->sha1))
+
+		switch (q->queue[i]->status) {
+		case DIFF_STATUS_DELETED:
 			printf("D %s\n", spec->path);
-		else {
+			break;
+
+		case DIFF_STATUS_COPIED:
+		case DIFF_STATUS_RENAMED:
+			printf("%c \"%s\" \"%s\"\n", q->queue[i]->status,
+			       ospec->path, spec->path);
+
+			if (!hashcmp(ospec->sha1, spec->sha1) &&
+			    ospec->mode == spec->mode)
+				break;
+			/* fallthrough */
+
+		case DIFF_STATUS_TYPE_CHANGED:
+		case DIFF_STATUS_MODIFIED:
+		case DIFF_STATUS_ADDED:
 			/*
 			 * Links refer to objects in another repositories;
 			 * output the SHA-1 verbatim.
@@ -134,6 +151,13 @@ static void show_filemodify(struct diff_queue_struct *q,
 				printf("M %06o :%d %s\n", spec->mode,
 				       get_object_mark(object), spec->path);
 			}
+			break;
+
+		default:
+			die("Unexpected comparison status '%c' for %s, %s",
+				q->queue[i]->status,
+				ospec->path ? ospec->path : "none",
+				spec->path ? spec->path : "none");
 		}
 	}
 }
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index f18eec9..bb595b7 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -162,4 +162,50 @@ test_expect_success 'submodule fast-export | fast-import' '
 
 '
 
+export GIT_AUTHOR_NAME='A U Thor'
+export GIT_COMMITTER_NAME='C O Mitter'
+
+test_expect_success 'setup copies' '
+
+	git config --unset i18n.commitencoding &&
+	git checkout -b copy rein &&
+	git mv file file3 &&
+	git commit -m move1 &&
+	test_tick &&
+	cp file2 file4 &&
+	git add file4 &&
+	git mv file2 file5 &&
+	git commit -m copy1 &&
+	test_tick &&
+	cp file3 file6 &&
+	git add file6 &&
+	git commit -m copy2 &&
+	test_tick &&
+	echo more text >> file6 &&
+	echo even more text >> file6 &&
+	git add file6 &&
+	git commit -m modify &&
+	test_tick &&
+	cp file6 file7 &&
+	echo test >> file7 &&
+	git add file7 &&
+	git commit -m copy_modify
+
+'
+
+test_expect_success 'fast-export -C -C | fast-import' '
+
+	ENTRY=$(git rev-parse --verify copy) &&
+	rm -rf new &&
+	mkdir new &&
+	git --git-dir=new/.git init &&
+	git fast-export -C -C --signed-tags=strip --all > output &&
+	grep "^C \"file6\" \"file7\"\$" output &&
+	cat output |
+	(cd new &&
+	 git fast-import &&
+	 test $ENTRY = $(git rev-parse --verify refs/heads/copy))
+
+'
+
 test_done
-- 
1.5.6.3.18.gfe82

^ permalink raw reply related

* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-26 21:36 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <1217104655.488b8b0f5ca48@webmail.nextra.at>


On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:

> Zitat von Steffen Prohaska <prohaska@zib.de>:
>> With MinGW's
>>
>>   gcc.exe (GCC) 3.4.5 (mingw special)
>>   GNU ld version 2.17.50 20060824
>>
>> the old define caused link errors:
>>
>>   git.o: In function `main':
>>   C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
>>   collect2: ld returned 1 exit status
>>
>> The modified define works.
>
> I have the same tools, but not this error. ???

I cleaned my work tree and built several times but did not
find out what exactly is causing the error.  So I came up
with the modified define, which declares the static
mingw_main in global scope.  I have no clue why I see the
error that you don't have.

	Steffen

^ permalink raw reply

* [PATCH 3/7] builtin-help: make list_commands() a bit more generic
From: Miklos Vajna @ 2008-07-26 21:40 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807261319310.16184@harper.uchicago.edu>

That function now takes two paramters to control the prefix of the
listed commands, and a second parameter to specify the title of the
table. This can be useful for listing not only all git commands, but
specific ones, like merge strategies.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---

On Sat, Jul 26, 2008 at 01:28:39PM -0500, Jonathan Nieder <jrnieder@uchicago.edu> wrote:
> >     if (main_cmds.cnt) {
> > -           printf("available git commands in '%s'\n", exec_path);
> > +           printf("available %s in '%s'\n", title, exec_path);
> >             printf("----------------------------");
> >             mput_char('-', strlen(exec_path));
> >             putchar('\n');
>
> Should this be
>
>       printf("available %s in '%s'\n", title, exec_path);
>       printf("----------------");
>       mput_char('-', strlen(exec_path) + strlen(title));
>       putchar('\n');
>
> ?
>
> (same question goes for the if(other_cmds.cnt) block, too)

Right. Here is an updated patch.

Also available at git://repo.or.cz/git/vmiklos.git, branch 'merge-custom'.

 help.c |   18 ++++++++++--------
 help.h |    1 +
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/help.c b/help.c
index d71937e..ec7999d 100644
--- a/help.c
+++ b/help.c
@@ -501,23 +501,25 @@ static unsigned int load_command_list(const char *prefix)
 	return longest;
 }
 
-static void list_commands(void)
+void list_commands(const char *prefix, const char *title)
 {
-	unsigned int longest = load_command_list(NULL);
+	unsigned int longest = load_command_list(prefix);
 	const char *exec_path = git_exec_path();
 
 	if (main_cmds.cnt) {
-		printf("available git commands in '%s'\n", exec_path);
-		printf("----------------------------");
-		mput_char('-', strlen(exec_path));
+		printf("available %s in '%s'\n", title, exec_path);
+		printf("----------------");
+		mput_char('-', strlen(title) + strlen(exec_path));
 		putchar('\n');
 		pretty_print_string_list(&main_cmds, longest);
 		putchar('\n');
 	}
 
 	if (other_cmds.cnt) {
-		printf("git commands available from elsewhere on your $PATH\n");
-		printf("---------------------------------------------------\n");
+		printf("%s available from elsewhere on your $PATH\n", title);
+		printf("---------------------------------------");
+		mput_char('-', strlen(title));
+		putchar('\n');
 		pretty_print_string_list(&other_cmds, longest);
 		putchar('\n');
 	}
@@ -697,7 +699,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
 
 	if (show_all) {
 		printf("usage: %s\n\n", git_usage_string);
-		list_commands();
+		list_commands("git-", "git commands");
 		printf("%s\n", git_more_info_string);
 		return 0;
 	}
diff --git a/help.h b/help.h
index 73da8d6..0741662 100644
--- a/help.h
+++ b/help.h
@@ -2,5 +2,6 @@
 #define HELP_H
 
 int is_git_command(const char *s, const char *prefix);
+void list_commands(const char *prefix, const char *title);
 
 #endif /* HELP_H */
-- 
1.6.0.rc0.14.g95f8.dirty

^ permalink raw reply related

* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Shawn O. Pearce @ 2008-07-26 21:50 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Junio C Hamano, Johannes Schindelin, Marek Zawirski, git
In-Reply-To: <200807261254.53939.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> wrote:
> So you would like to see something like the following question in the
> upcoming Git User's Survey?
> 
>    xx. Which editors/IDEs/RADs do you use?
>        (zero or more; multiple choice with 'other')
>     -  Emacs, Vim, Eclipse, KDevelop, Anjuta, TextMate, Notepad++,
>        Visual Studio, other
>     +  what choices should be in the list of editors and IDE;
>        or should perhaps this question be free-form?

I think we should list explicitly any editor that we have Git
integration for, or which we know is popular and people have asked
about in the past, and leave an other for people to enter other
editors.

We know about Emacs, Vim, Eclipse, TextMate all having some sort
of Git integration.  We know people have asked about NetBeans,
KDevelop and Anjuta.  After that yea, Notepad++ and Visual Studio
are two commonly used tools that people may use.

Anyone know of anything missing from this list?

-- 
Shawn.

^ permalink raw reply

* Re: [PATCH] bash completion: Add long options for 'git describe'
From: Shawn O. Pearce @ 2008-07-26 21:52 UTC (permalink / raw)
  To: Thomas Rast; +Cc: git, gitster, SZEDER GGGbor
In-Reply-To: <1217068016-10954-1-git-send-email-trast@student.ethz.ch>

Thomas Rast <trast@student.ethz.ch> wrote:
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>

Much shorter, thanks.

Acked-by: Shawn O. Pearce <spearce@spearce.org>

> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 3b04934..4ae8b36 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -665,6 +665,15 @@ _git_commit ()
>  
>  _git_describe ()
>  {
> +	local cur="${COMP_WORDS[COMP_CWORD]}"
> +	case "$cur" in
> +	--*)
> +		__gitcomp "
> +			--all --tags --contains --abbrev= --candidates=
> +			--exact-match --debug --long --match --always
> +			"
> +		return
> +	esac
>  	__gitcomp "$(__git_refs)"
>  }
>  

-- 
Shawn.

^ permalink raw reply

* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Jean-François Veillette @ 2008-07-26 21:52 UTC (permalink / raw)
  To: Shawn O. Pearce
  Cc: Jakub Narebski, Junio C Hamano, Johannes Schindelin,
	Marek Zawirski, git
In-Reply-To: <20080726215031.GB16219@spearce.org>


Le 08-07-26 à 17:50, Shawn O. Pearce a écrit :

> Jakub Narebski <jnareb@gmail.com> wrote:
>> So you would like to see something like the following question in the
>> upcoming Git User's Survey?
>>
>>    xx. Which editors/IDEs/RADs do you use?
>>        (zero or more; multiple choice with 'other')
>>     -  Emacs, Vim, Eclipse, KDevelop, Anjuta, TextMate, Notepad++,
>>        Visual Studio, other
>>     +  what choices should be in the list of editors and IDE;
>>        or should perhaps this question be free-form?
>
> I think we should list explicitly any editor that we have Git
> integration for, or which we know is popular and people have asked
> about in the past, and leave an other for people to enter other
> editors.
>
> We know about Emacs, Vim, Eclipse, TextMate all having some sort
> of Git integration.  We know people have asked about NetBeans,
> KDevelop and Anjuta.  After that yea, Notepad++ and Visual Studio
> are two commonly used tools that people may use.
>
> Anyone know of anything missing from this list?

XCode

- jfv

^ permalink raw reply

* Re: [EGIT PATCH] Support linked resources
From: Shawn O. Pearce @ 2008-07-26 21:59 UTC (permalink / raw)
  To: Robin Rosenberg; +Cc: Richie Vos, git
In-Reply-To: <200807261707.18299.robin.rosenberg.lists@dewire.com>

Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:
> > I have a project that outputs to a linked directory (for example the
> > project is in /projects/foo and the project outputs to /projects/bar).
...
> I'd be inclined to prefer ignoring any non-plain resource, always. Linked
> resources are either absolute or relative to a variable. Other than that 
> there is an analogy to symbolic links. Git manages the link, not its
> content (unless handled elsewhere). The link in this case is in the
> .project file and thus managed there.
> 
> EGit could still managed the resource, but not via the link, but rather at
> the place it is located, iff that happens to be in a project managed by Egit.

My last day-job used a project layout in the filesystem of:

	GIT_REPO/
	  .git/
      .gitignore
      _eclipse_projects/
          com.sekret.foo/.project
          com.sekret.bar/.project
      foo/
          com/sekret/foo/Foo.java
      bar/
          com/sekret/bar/Bar.java

The two .project files contained links called "src" to "foo" and
"bar" respectively.  The _eclipse_projects folder is ignored by
.gitignore, and the .project files were actually generated on the
fly by our non-Eclipse based buildsystem.

Consequently I wanted egit to be able to manage the stuff inside of
a linked folder, so long as it mapped onto the same repository that
the project mapped onto.  Without that the "src" folder contents
wouldn't be available to egit, and egit would be more-or-less
useless on this sort of layout.

-- 
Shawn.

^ permalink raw reply

* Re: git-scm.com
From: Junio C Hamano @ 2008-07-26 23:11 UTC (permalink / raw)
  To: Wincent Colaiuta
  Cc: Scott Chacon, david, Petr Baudis, Patrick Aljord, git list
In-Reply-To: <F3D70DCD-E9A9-42C3-8870-ABB7EECF83CC@wincent.com>

Wincent Colaiuta <win@wincent.com> writes:

> I'd like to see the "official" Git homepage as distanced as possible  
> from GitHub. They've taken Git (free as in speech, free as in beer)  
> and built a closed-source commercial product on top of it -- curiously  
> for something which you can do for free yourself anyway ...

I do not share that sentiment.  It is perfectly fine for somebody to offer
managed git repositories as a commercial _service_ to people who want to
just _use_ git.  It is what they could do themselves, but from the end
user's point of view, it's just "outsourcing" and is nothing unusual.

If GitHub folks improved the core part of the system while building their
service, we would want to get the changes back, and we will, _if_ they
distribute their software (i.e. they are not allowed to just distribute
binaries, if it links with git).

At the emotional level, if some people make the world a better place by
building new software around what I wrote, I would like to have the same
kind of access to its source as I gave them access to my sources, whether
they distribute the end product as packaged software or they offer it as a
service to be used by others without ever distributing anything.  But that
is merely my _wish_; it is different from the terms git is distributed
under.

I think you are going a bit too far to hate them for not opening up their
sources they use to implement "managed git repositories service", which is
a _user_ of the core git, but most likely is not a derivative of git
itself.  IOW, it's not your code.

^ permalink raw reply

* [PATCH] gitweb: More about how gitweb gets 'owner' of repository
From: Jakub Narebski @ 2008-07-26 23:23 UTC (permalink / raw)
  To: git

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Just an improvement in gitweb documentation...

 gitweb/README |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/gitweb/README b/gitweb/README
index 6908036..825162a 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -277,7 +277,8 @@ You can use the following files in repository:
  * gitweb.owner
    You can use the gitweb.owner repository configuration variable to set
    repository's owner. It is displayed in the project list and summary
-   page. If it's not set, filesystem directory's owner is used.
+   page. If it's not set, filesystem directory's owner is used
+   (via GECOS field / real name field from getpwiud(3)).
  * various gitweb.* config variables (in config)
    Read description of %feature hash for detailed list, and some
    descriptions.

^ permalink raw reply related

* Summer of Code 2008 Midterm Summary
From: Shawn O. Pearce @ 2008-07-26 23:27 UTC (permalink / raw)
  To: git

Part of the Google Summer of Code program is to ask the students
to evaluate their mentors, and their own involvement with their
community.  That evaluation period closed on July 14th, but I
haven't had a chance to go through the results until now.

At the mid-term all 6 of our students "passed" their evaluations.
This means we asked Google to pay out their $2000 USD stipend, and
allow the student to continue the program for the rest of the summer.
This decision was made by each individual mentor.  Payment of the
remaining $2000 USD stipend will be determined during the final
evaluations, which are after August 11th.

What follows is a condensed summary of the student responses from
the mid-term survey.

Q: At what point did you first make contact with your
   mentoring organization?

   This was about split 50/50 between "after the organization was
   accepted" and "during the student application and acceptance
   phase of the program".  As you may well know, Summer of Code
   takes a short 'break' between announcing what organizations will
   participate as mentors, and when students can begin applying.

   The fact that about 50% of our accepted students were talking to
   our potential mentors before they could even submit applications
   suggests that it worked in their favor, and improved their odds
   of being selected.

   Since this was a significant part of our application selection
   process, I am not surprised by this figure.

Q: How often do you and your mentor interact?

   2 students answered "Every day" and 4 answered "once every few
   days".  By and large our mentors are active with their students.

Q: How do you communicate with your mentor?

   Overwhelmingly our students use IRC and private emails to
   communicate with their mentors.

   Most of them also keep a private Git repository with a list of
   notes they want to share with their mentor, and their mentors
   monitor this notes file by git-fetch'ing it every so often.
   It seems we eat our own dog food quite a bit around here.  :-)

Q: How much time have you spent per week interacting with your
   mentor, on average?

   All of our students (except 1) said 0-5 hours per week, and the
   lone dissenter said 6-10 hours per week.  Nearly all of the
   mentors on the other hand chose 6-10 hours per week in their
   own surveys.

   It may be safe to say that in the average case we are spending
   about 10 hours per week as mentors just communicating with our
   students and helping them to meet their goals.

Q: How would you describe your interaction with your overall
   project community?

   5 out of 6 of our students said "Somewhat active (e.g. I read
   and sometimes responds to mailing lists, some interaction in
   community communication channels)".  I think most of them really
   should have chosen instead "Very active (e.g. I send code reviews
   to development mailing lists, am active and ask/answer questions
   in our IRC channel or project forums)".

   Most of our summer of code students _are_ sending code reviews
   to this mailing list, and are taking advantage of the fantastic
   contributors we have to help them out.  They also tend to answer
   questions on IRC and the mailing list when they are pretty sure
   they know the answer and can take the time to help someone else.

   Certainly our students aren't as active as our intrepid maintainer
   is, but most of them aren't lurking in the shadows either.

Q: If you cannot reach your mentor, how do you go about getting
   help when you need it?

   3 of our students selected "I hope I can figure it out myself
   before my mentor resurfaces.".  This is a less-than-optimal result
   in my opinion.  Despite the prior question indicating that our
   students may actually be actively involved in the community
   they don't feel involved enough to obtain assistance without
   their mentor.

   3 students also chose "I ask questions on our project's developer
   or other main mailing list.".

   This was a multiple choice question, so there is some overlap,
   but I do know that at least one student chose _only_ "I hope
   I can figure it out myself before my mentor resurfaces".

   In terms of community building this question's answers seem to
   suggest we need to try harder to make our students included,
   and get help beyond just their mentor/co-mentor.

Q: How responsive was your mentor to any questions or other requests
   for communication from you?

   All of our students chose "Mentor responded quickly with the
   information I requested" (which is the best rating available),
   though one of them qualified it with "For some values of
   'quickly'".  ;-)

Q: Do you feel that you are on track to complete your project?

   I'm not sure if this is good or bad.  3 students (50%!) are
   ahead of schedule, 1 is on schedule, and 2 are behind.

   On the one hand I applaud our 3 students who happen to be ahead
   of schedule.  They have clearly worked hard and produced some
   useful code, much of which will be in the next release of their
   respective projects.

   On the other hand I wonder if as mentors we didn't demand
   enough of our students?  Looking at the students who are ahead
   of schedule, I know that at least 2 of them had what we thought
   as mentors to be difficult, time consuming tasks in front them.
   So we did intentially try to define the project such that it
   would be more likely to succeed.

Q: What areas were the most difficult for you in preparing
   for/working on Summer of Code?

   Most of our students (5/6) had trouble balancing their time
   between their Git project and school (exams, etc.).  This is a
   common theme in Summer of Code and Git isn't alone in seeing it.
   As I understand it a number of our students are in European
   based university programs, which causes exams to fall in the
   early part of the Summer of Code timeline.

   Half of our students found getting up to speed with our code
   base and/or documentation was difficult.  In other words, they
   did not feel that Git was "new contributor friendly".

   A couple of students have had time-zone issues with their mentors,
   but looking at the progress of most projects that doesn't seem
   to be a major issue.

-- 
Shawn.

^ permalink raw reply

* Re: [PATCH] gitweb: More about how gitweb gets 'owner' of repository
From: Petr Baudis @ 2008-07-26 23:27 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git
In-Reply-To: <20080726232316.23589.62384.stgit@localhost.localdomain>

On Sun, Jul 27, 2008 at 01:23:46AM +0200, Jakub Narebski wrote:
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> Just an improvement in gitweb documentation...

Acked-by: Petr Baudis <pasky@suse.cz>

^ permalink raw reply

* Re: fetch refspec foo/* matches foo*
From: Junio C Hamano @ 2008-07-27  0:18 UTC (permalink / raw)
  To: Jeff King; +Cc: Daniel Barkalow, git
In-Reply-To: <20080726082405.GA10104@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> On Fri, Jul 25, 2008 at 02:02:15PM -0700, Junio C Hamano wrote:
>
>> BTW, has anybody taken a look at this one?
>> 
>>   Subject: BUG: fetch incorrect interpretation of globing patterns in refspecs
>>   Date: Thu, 24 Jul 2008 09:07:21 +0200
>>   Message-ID: <71295b5a0807240007k246973abj1897895d0d67bb6c@mail.gmail.com>
>> 
>> If not, I think I probably need to take a look at this, reproducing and
>> possibly fixing, before applying non-fix patches.
>
> I have been meaning to look at it for days, so I finally took a peek.  I
> was able to reproduce the problem easily. I think it is (almost) as
> simple as the patch below. In the refspec parsing, we already require
> globs to come after '/', so this is the analagous check during match.
>
> Unfortunately, this breaks t1020 (something about failing to clone HEAD

Your patch expects that the parsed refspec->{src,dst} omit the terminating
slash, which is in line with what parse_refspec_internal() in remote.c
does.  The problem is that builtin-clone.c uses a refspec that is
incompatible from that assumption.  The static "tag_refspec" variable
defined in remote.c has the same problem.  These two have trailing slash
e.g. "refs/heads/", "refs/tags/", that should be dropped for your updated
check to work.

The attached patch, that includes your one-liner change, makes all tests
pass.

I have a nagging suspicion that it might be a simpler and cleaner change
to change parse_refspec_internal() to keep the trailing slash, instead of
dropping it.  Then the check you added is not needed (the trailing slash
guarantees that the pattern matches at the hierarchy boundary), neither
any of the change in this patch.

---
 builtin-clone.c        |    9 +++++----
 remote.c               |    7 ++++---
 t/t5513-fetch-track.sh |   30 ++++++++++++++++++++++++++++++
 3 files changed, 39 insertions(+), 7 deletions(-)

diff --git a/builtin-clone.c b/builtin-clone.c
index e086a40..022ffb9 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -440,12 +440,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 	git_config(git_default_config, NULL);
 
 	if (option_bare) {
-		strcpy(branch_top, "refs/heads/");
+		strcpy(branch_top, "refs/heads");
 
 		git_config_set("core.bare", "true");
 	} else {
 		snprintf(branch_top, sizeof(branch_top),
-			 "refs/remotes/%s/", option_origin);
+			 "refs/remotes/%s", option_origin);
 
 		/* Configure the remote */
 		snprintf(key, sizeof(key), "remote.%s.url", option_origin);
@@ -453,13 +453,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 
 		snprintf(key, sizeof(key), "remote.%s.fetch", option_origin);
 		snprintf(value, sizeof(value),
-				"+refs/heads/*:%s*", branch_top);
+				"+refs/heads/*:%s/*", branch_top);
 		git_config_set_multivar(key, value, "^$", 0);
 	}
 
 	refspec.force = 0;
 	refspec.pattern = 1;
-	refspec.src = "refs/heads/";
+	refspec.src = "refs/heads";
 	refspec.dst = branch_top;
 
 	if (path && !is_bundle)
@@ -514,6 +514,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 
 			strbuf_init(&head_ref, 0);
 			strbuf_addstr(&head_ref, branch_top);
+			strbuf_addch(&head_ref, '/');
 			strbuf_addstr(&head_ref, "HEAD");
 
 			/* Remote branch link */
diff --git a/remote.c b/remote.c
index 0d6020b..6b313fb 100644
--- a/remote.c
+++ b/remote.c
@@ -9,8 +9,8 @@ static struct refspec s_tag_refspec = {
 	0,
 	1,
 	0,
-	"refs/tags/",
-	"refs/tags/"
+	"refs/tags",
+	"refs/tags"
 };
 
 const struct refspec *tag_refspec = &s_tag_refspec;
@@ -1108,7 +1108,8 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
 	for (ref = remote_refs; ref; ref = ref->next) {
 		if (strchr(ref->name, '^'))
 			continue; /* a dereference item */
-		if (!prefixcmp(ref->name, refspec->src)) {
+		if (!prefixcmp(ref->name, refspec->src) &&
+		    ref->name[remote_prefix_len] == '/') {
 			const char *match;
 			struct ref *cpy = copy_ref(ref);
 			match = ref->name + remote_prefix_len;
diff --git a/t/t5513-fetch-track.sh b/t/t5513-fetch-track.sh
new file mode 100755
index 0000000..9e74862
--- /dev/null
+++ b/t/t5513-fetch-track.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='fetch follows remote tracking branches correctly'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+	>file &&
+	git add . &&
+	test_tick &&
+	git commit -m Initial &&
+	git branch b-0 &&
+	git branch b1 &&
+	git branch b/one &&
+	test_create_repo other &&
+	(
+		cd other &&
+		git config remote.origin.url .. &&
+		git config remote.origin.fetch "+refs/heads/b/*:refs/remotes/b/*"
+	)
+'
+
+test_expect_success fetch '
+	(
+		cd other && git fetch origin &&
+		test "$(git for-each-ref --format="%(refname)")" = refs/remotes/b/one
+	)
+'
+
+test_done

^ permalink raw reply related

* [PATCH] Optional grouping of projects by category.
From: Sebastien Cevey @ 2008-07-27  0:36 UTC (permalink / raw)
  To: git

This adds the GITWEB_GROUP_CATEGORIES option which, if enabled, will
result in grouping projects by category on the project list page.  The
category is specified for each project by the $GIT_DIR/category file
or the 'category' variable in its configuration file.

The feature is inspired from Sham Chukoury's patch for the XMMS2
gitweb, but has been rewritten for the current gitweb development
HEAD.

Thanks to Florian Ragwitz for Perl tips.

Signed-off-by: Sebastien Cevey <seb@cine7.net>
---

We used to run a modified gitweb for XMMS2 Git repositories which,
among other things, grouped projects by categories.  The feature was
lost when we caught up with upstream gitweb, but I've rehacked this
feature back on top of the current HEAD.

I assume this might be a wanted feature, or at least it was in Jakub's
old wishlist he posted on 2006-06-21 02:51:18.

Feedback on the idea and implementation are welcome.

 Makefile           |    2 +
 gitweb/README      |   11 ++++
 gitweb/gitweb.css  |    5 ++
 gitweb/gitweb.perl |  129 ++++++++++++++++++++++++++++++++++++++--------------
 4 files changed, 112 insertions(+), 35 deletions(-)

diff --git a/Makefile b/Makefile
index 798a2f2..2309260 100644
--- a/Makefile
+++ b/Makefile
@@ -208,6 +208,7 @@ GITWEB_EXPORT_OK =
 GITWEB_STRICT_EXPORT =
 GITWEB_BASE_URL =
 GITWEB_LIST =
+GITWEB_GROUP_CATEGORIES =
 GITWEB_HOMETEXT = indextext.html
 GITWEB_CSS = gitweb.css
 GITWEB_LOGO = git-logo.png
@@ -1145,6 +1146,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
 	    -e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
 	    -e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
 	    -e 's|++GITWEB_LIST++|$(GITWEB_LIST)|g' \
+	    -e 's|++GITWEB_GROUP_CATEGORIES++|$(GITWEB_GROUP_CATEGORIES)|g' \
 	    -e 's|++GITWEB_HOMETEXT++|$(GITWEB_HOMETEXT)|g' \
 	    -e 's|++GITWEB_CSS++|$(GITWEB_CSS)|g' \
 	    -e 's|++GITWEB_LOGO++|$(GITWEB_LOGO)|g' \
diff --git a/gitweb/README b/gitweb/README
index 6908036..2b77c20 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -38,6 +38,11 @@ You can specify the following configuration variables when building GIT:
    using gitweb" in INSTALL file for gitweb to find out how to generate
    such file from scan of a directory. [No default, which means use root
    directory for projects]
+ * GITWEB_GROUP_CATEGORIES
+   Groups projects by category on the main projects list page if set
+   to true.  The category of a project is determined by the
+   $GIT_DIR/category file or the 'category' variable in its
+   configuration file.  [No default / Not set]
  * GITWEB_EXPORT_OK
    Show repository only if this file exists (in repository).  Only
    effective if this variable evaluates to true.  [No default / Not set]
@@ -188,6 +193,12 @@ not include variables usually directly set during build):
    full description is available as 'title' attribute (usually shown on
    mouseover).  By default set to 25, which might be too small if you
    use long project descriptions.
+ * $projects_list_group_categories
+   Enables the grouping of projects by category on the project list page.
+ * $project_list_default_category
+   Default category for projects for which none is specified.  If set
+   to the empty string, such projects will remain uncategorized and
+   listed at the top, above categorized projects.
  * @git_base_url_list
    List of git base URLs used for URL to where fetch project from, shown
    in project summary page.  Full URL is "$git_base_url/$project".
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index aa0eeca..7f1e2cc 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -264,6 +264,11 @@ td.current_head {
 	text-decoration: underline;
 }
 
+td.category {
+	padding-top: 1em;
+	font-weight: bold;
+}
+
 table.diff_tree span.file_status.new {
 	color: #008000;
 }
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..fe8ae72 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -78,6 +78,13 @@ our $projects_list = "++GITWEB_LIST++";
 # the width (in characters) of the projects list "Description" column
 our $projects_list_description_width = 25;
 
+# group projects by category on the projects list
+our $projects_list_group_categories = "++GITWEB_GROUP_CATEGORIES++";
+
+# default category if none specified
+# (leave the empty string for no category)
+our $project_list_default_category = "";
+
 # default order of projects list
 # valid values are none, project, descr, owner, and age
 our $default_projects_order = "project";
@@ -1710,18 +1717,28 @@ sub git_get_path_by_hash {
 ## ......................................................................
 ## git utility functions, directly accessing git repository
 
-sub git_get_project_description {
-	my $path = shift;
+sub git_get_project_config_from_file {
+	my ($name, $path) = @_;
 
 	$git_dir = "$projectroot/$path";
-	open my $fd, "$git_dir/description"
-		or return git_get_project_config('description');
-	my $descr = <$fd>;
+	open my $fd, "<", "$git_dir/$name"
+		or return git_get_project_config($name);
+	my $conf = <$fd>;
 	close $fd;
-	if (defined $descr) {
-		chomp $descr;
+	if (defined $conf) {
+		chomp $conf;
 	}
-	return $descr;
+	return $conf;
+}
+
+sub git_get_project_description {
+	my $path = shift;
+	return git_get_project_config_from_file('description', $path);
+}
+
+sub git_get_project_category {
+	my $path = shift;
+	return git_get_project_config_from_file('category', $path);
 }
 
 sub git_get_project_url_list {
@@ -3535,8 +3552,9 @@ sub git_patchset_body {
 
 # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
-# fills project list info (age, description, owner, forks) for each
-# project in the list, removing invalid projects from returned list
+# fills project list info (age, description, owner, category, forks)
+# for each project in the list, removing invalid projects from
+# returned list
 # NOTE: modifies $projlist, but does not remove entries from it
 sub fill_project_list_info {
 	my ($projlist, $check_forks) = @_;
@@ -3558,6 +3576,11 @@ sub fill_project_list_info {
 		if (!defined $pr->{'owner'}) {
 			$pr->{'owner'} = git_get_project_owner("$pr->{'path'}") || "";
 		}
+		if ($projects_list_group_categories && !defined $pr->{'cat'}) {
+			my $cat = git_get_project_category($pr->{'path'}) ||
+			                                   $project_list_default_category;
+			$pr->{'cat'} = to_utf8($cat);
+		}
 		if ($check_forks) {
 			my $pname = $pr->{'path'};
 			if (($pname =~ s/\.git$//) &&
@@ -3574,6 +3597,17 @@ sub fill_project_list_info {
 	return @projects;
 }
 
+sub build_sorted_category_list {
+	my ($projlist) = @_;
+	my %categories;
+
+	for my $pr (@{ $projlist }) {
+		push @{$categories{ $pr->{'cat'} }}, $pr;
+	}
+
+	return %categories;
+}
+
 # print 'sort by' <th> element, either sorting by $key if $name eq $order
 # (changing $list), or generating 'sort by $name' replay link otherwise
 sub print_sort_th {
@@ -3604,36 +3638,15 @@ sub print_sort_th_num {
 	print_sort_th(0, @_);
 }
 
-sub git_project_list_body {
-	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
-
-	my ($check_forks) = gitweb_check_feature('forks');
-	my @projects = fill_project_list_info($projlist, $check_forks);
+sub print_project_rows {
+	my ($projects, $from, $to, $check_forks) = @_;
 
-	$order ||= $default_projects_order;
 	$from = 0 unless defined $from;
-	$to = $#projects if (!defined $to || $#projects < $to);
+	$to = $#$projects if (!defined $to || $#$projects < $to);
 
-	print "<table class=\"project_list\">\n";
-	unless ($no_header) {
-		print "<tr>\n";
-		if ($check_forks) {
-			print "<th></th>\n";
-		}
-		print_sort_th_str('project', $order, 'path',
-		                  'Project', \@projects);
-		print_sort_th_str('descr', $order, 'descr_long',
-		                  'Description', \@projects);
-		print_sort_th_str('owner', $order, 'owner',
-		                  'Owner', \@projects);
-		print_sort_th_num('age', $order, 'age',
-		                  'Last Change', \@projects);
-		print "<th></th>\n" . # for links
-		      "</tr>\n";
-	}
 	my $alternate = 1;
 	for (my $i = $from; $i <= $to; $i++) {
-		my $pr = $projects[$i];
+		my $pr = $projects->[$i];
 		if ($alternate) {
 			print "<tr class=\"dark\">\n";
 		} else {
@@ -3665,6 +3678,52 @@ sub git_project_list_body {
 		      "</td>\n" .
 		      "</tr>\n";
 	}
+}
+
+sub git_project_list_body {
+	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
+
+	my ($check_forks) = gitweb_check_feature('forks');
+	my @all_projects = fill_project_list_info($projlist, $check_forks);
+
+	$order ||= $default_projects_order;
+
+	print "<table class=\"project_list\">\n";
+	unless ($no_header) {
+		print "<tr>\n";
+		if ($check_forks) {
+			print "<th></th>\n";
+		}
+		print_sort_th_str('project', $order, 'path',
+		                  'Project', \@all_projects);
+		print_sort_th_str('descr', $order, 'descr_long',
+		                  'Description', \@all_projects);
+		print_sort_th_str('owner', $order, 'owner',
+		                  'Owner', \@all_projects);
+		print_sort_th_num('age', $order, 'age',
+		                  'Last Change', \@all_projects);
+		print "<th></th>\n" . # for links
+		      "</tr>\n";
+	}
+
+	if ($projects_list_group_categories) {
+		my %categories = build_sorted_category_list(\@all_projects);
+		foreach my $cat (sort keys %categories) {
+			unless ($cat eq "") {
+				print "<tr>\n";
+				if ($check_forks) {
+					print "<td></td>\n";
+				}
+				print "<td class=\"category\" colspan=\"5\">" . $cat . "</td>\n";
+				print "</tr>\n";
+			}
+
+			print_project_rows($categories{$cat}, $from, $to, $check_forks);
+		}
+	} else {
+		print_project_rows(\@all_projects, $from, $to, $check_forks);
+	}
+
 	if (defined $extra) {
 		print "<tr>\n";
 		if ($check_forks) {
-- 
1.5.3.7

^ permalink raw reply related

* [PATCH] Documentation/git-rev-parse.txt: update for new git-describe output format
From: Cesar Eduardo Barros @ 2008-07-27  0:46 UTC (permalink / raw)
  To: git, gitster; +Cc: Cesar Eduardo Barros

Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
---
 Documentation/git-rev-parse.txt |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 5c93669..2921da3 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -155,8 +155,9 @@ blobs contained in a commit.
   name the same commit object if there are no other object in
   your repository whose object name starts with dae86e.
 
-* An output from 'git-describe'; i.e. a closest tag, followed by a
-  dash, a `g`, and an abbreviated object name.
+* An output from 'git-describe'; i.e. a closest tag, optionally
+  followed by a dash and a number of commits, followed by a dash, a
+  `g`, and an abbreviated object name.
 
 * A symbolic ref name.  E.g. 'master' typically means the commit
   object referenced by $GIT_DIR/refs/heads/master.  If you
-- 
1.5.6.4

^ permalink raw reply related

* [JGIT PATCH 2/2] Extended test cases for RepositoryConfigTest
From: Shawn O. Pearce @ 2008-07-27  2:11 UTC (permalink / raw)
  To: Robin Rosenberg, Marek Zawirski; +Cc: git, Marek Zawirski
In-Reply-To: <1217124716-12063-1-git-send-email-spearce@spearce.org>

From: Marek Zawirski <marek.zawirski@gmail.com>

Add cases for getting values after setting them. It's something
different from reading config file from scratch or writing it out after
modifications. It's case for getting values after modifications in
object model.

Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 .../org/spearce/jgit/lib/RepositoryConfigTest.java |   20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java
index 8c55fe8..da7e704 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryConfigTest.java
@@ -2,6 +2,7 @@
  * Copyright (C) 2007, Dave Watson <dwatson@mimvista.com>
  * Copyright (C) 2008, Robin Rosenberg <robin.rosenberg@dewire.com>
  * Copyright (C) 2008, Shawn O. Pearce <spearce@spearce.org>
+ * Copyright (C) 2008, Marek Zawirski <marek.zawirski@gmail.com>
  *
  * All rights reserved.
  *
@@ -41,6 +42,8 @@ package org.spearce.jgit.lib;
 
 import java.io.File;
 import java.io.IOException;
+import java.util.Arrays;
+import java.util.LinkedList;
 
 /**
  * Test reading of git config
@@ -84,11 +87,26 @@ public class RepositoryConfigTest extends RepositoryTestCase {
 		checkFile(cfgFile, "[sec \"ext\"]\n\tname = value\n\tname2 = value2\n");
 	}
 
-	public void test004_PutSimple() throws IOException {
+	public void test004_PutGetSimple() throws IOException {
 		File cfgFile = writeTrashFile("config_004", "");
 		RepositoryConfig repositoryConfig = new RepositoryConfig(null, cfgFile);
 		repositoryConfig.setString("my", null, "somename", "false");
 		repositoryConfig.save();
 		checkFile(cfgFile, "[my]\n\tsomename = false\n");
+		assertEquals("false", repositoryConfig
+				.getString("my", null, "somename"));
+	}
+
+	public void test005_PutGetStringList() throws IOException {
+		File cfgFile = writeTrashFile("config_005", "");
+		RepositoryConfig repositoryConfig = new RepositoryConfig(null, cfgFile);
+		final LinkedList<String> values = new LinkedList<String>();
+		values.add("value1");
+		values.add("value2");
+		repositoryConfig.setStringList("my", null, "somename", values);
+		repositoryConfig.save();
+		assertTrue(Arrays.equals(values.toArray(), repositoryConfig
+				.getStringList("my", null, "somename")));
+		checkFile(cfgFile, "[my]\n\tsomename = value1\n\tsomename = value2\n");
 	}
 }
-- 
1.6.0.rc0.182.gb96c7

^ permalink raw reply related

* [JGIT PATCH 1/2] Fix RepositoryConfig.setStringList to not corrupt internal state
From: Shawn O. Pearce @ 2008-07-27  2:11 UTC (permalink / raw)
  To: Robin Rosenberg, Marek Zawirski; +Cc: git

Calling setStringList was incorrectly storing the String objects
directly in byName.  The byName table should have either an Entry or
a List<Entry> stored within its value position.  Storing the String
(or List<String>) directly confused our get code as it did not find
the object type it expected.  This caused the get code to fallback
to the base configuration (e.g. ~/.gitconfig) or just return null
(claiming the value was never set).

A test case for this appears in the next commit.

Noticed-by: Marek Zawirski <marek.zawirski@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 .../src/org/spearce/jgit/lib/RepositoryConfig.java |   23 ++++++++++++++++---
 1 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java
index 1431f1f..d1cd5fc 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RepositoryConfig.java
@@ -381,10 +381,25 @@ public class RepositoryConfig {
 		key += "." + name.toLowerCase();
 		if (values.size() == 0)
 			byName.remove(key);
-		else if (values.size() == 1)
-			byName.put(key, values.get(0));
-		else
-			byName.put(key, new ArrayList<String>(values));
+		else if (values.size() == 1) {
+			final Entry e = new Entry();
+			e.base = section;
+			e.extendedBase = subsection;
+			e.name = name;
+			e.value = values.get(0);
+			byName.put(key, e);
+		} else {
+			final ArrayList<Entry> eList = new ArrayList<Entry>(values.size());
+			for (final String v : values) {
+				final Entry e = new Entry();
+				e.base = section;
+				e.extendedBase = subsection;
+				e.name = name;
+				e.value = v;
+				eList.add(e);
+			}
+			byName.put(key, eList);
+		}
 
 		int entryIndex = 0;
 		int valueIndex = 0;
-- 
1.6.0.rc0.182.gb96c7

^ permalink raw reply related

* [PATCH] fsck: Don't require tmp_obj_ file names are 14 bytes in length
From: Shawn O. Pearce @ 2008-07-27  2:33 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <6ruv3Y98_kSSVnJFTkV0PNdiNcQ3g-a3M4BhGoT7S1PorElp5tJAkw@cipher.nrlssc.navy.mil>

Not all temporary file creation routines will ensure 14 bytes are
used to generate the temporary file name.  In C Git this may be
true, but alternate implementations such as jgit are not always
able to generate a temporary file name with a specific prefix and
also ensure the file name length is 14 bytes long.

Since temporary files in a directory we are fsck'ing should be
uncommon (as they are short lived only long enough for an active
writer to finish writing the file and rename it) we shouldn't see
these show up very often.  Always using a prefixcmp() call and
ignoring the length opens up room for other implementations to use
different name generation schemes.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---

  Brandon Casey <casey@nrlssc.navy.mil> wrote:
  > Since 5723fe7e, temporary objects are now created in their final destination
  > directories, rather than in .git/objects/. Teach fsck to recognize and
  > ignore the temporary objects it encounters, and teach prune to remove them.

  jgit can't exactly follow the 14 character naming rule.
  This should be a safe way around it.

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

diff --git a/builtin-fsck.c b/builtin-fsck.c
index 7a4a4f1..6eb7da8 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -377,10 +377,6 @@ static void fsck_dir(int i, char *path)
 			if (de->d_name[0] != '.')
 				break;
 			continue;
-		case 14:
-			if (prefixcmp(de->d_name, "tmp_obj_"))
-				break;
-			continue;
 		case 38:
 			sprintf(name, "%02x", i);
 			memcpy(name+2, de->d_name, len+1);
@@ -389,6 +385,8 @@ static void fsck_dir(int i, char *path)
 			add_sha1_list(sha1, DIRENT_SORT_HINT(de));
 			continue;
 		}
+		if (prefixcmp(de->d_name, "tmp_obj_"))
+			continue;
 		fprintf(stderr, "bad sha1 file: %s/%s\n", path, de->d_name);
 	}
 	closedir(dir);
-- 
1.6.0.rc0.182.gb96c7

-- 
Shawn.

^ permalink raw reply related

* Re: [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Christian Couder @ 2008-07-27  3:19 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Mike Hommey, git
In-Reply-To: <Pine.GSO.4.62.0807240233310.27074@harper.uchicago.edu>

Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
> status when asked to list nonexistent files.  Unfortunately,
> /bin/ls on Mac OS X 10.3 exits with exit code 0.  So look at
> its output instead.
>
> Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>

Acked-by: Christian Couder <chriscool@tuxfamily.org>

Thanks,
Christian.

> ---
>
> Mike Hommey wrote:
> > On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> >> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> >>> -	test_must_fail ls .git/BISECT_* &&
> >>> +	echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
> >>
> >> Perhaps the following is simpler:
> >>
> >> +	test -z "$(ls .git/BISECT_*)" &&
> >
> > That is still a useless use of ls ;)
>
> It is much better than what I wrote, at least.
>
> Good night (well, good morning I guess), and thanks.
>
>  t/t6030-bisect-porcelain.sh |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index 0626544..244fda6 100755
> --- a/t/t6030-bisect-porcelain.sh
> +++ b/t/t6030-bisect-porcelain.sh
> @@ -76,7 +76,7 @@ test_expect_success 'bisect fails if given any junk
> instead of revs' ' test_must_fail git bisect start foo $HASH1 -- &&
>  	test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
>  	test -z "$(git for-each-ref "refs/bisect/*")" &&
> -	test_must_fail ls .git/BISECT_* &&
> +	test -z "$(ls .git/BISECT_* 2>/dev/null)" &&
>  	git bisect start &&
>  	test_must_fail git bisect good foo $HASH1 &&
>  	test_must_fail git bisect good $HASH1 bar &&

^ permalink raw reply

* Re: problem using jgit
From: Shawn O. Pearce @ 2008-07-27  3:21 UTC (permalink / raw)
  To: Marek Zawirski; +Cc: Stephen Bannasch, git, Robin Rosenberg
In-Reply-To: <4889E88E.8000701@gmail.com>

Marek Zawirski <marek.zawirski@gmail.com> wrote:
> Shawn O. Pearce wrote:
>> Marek Zawirski <marek.zawirski@gmail.com> wrote:
>>> 
>>> It's caused by 14a630c3: Cached modification times for symbolic refs too
>>> Changes introduced by this patch made Repository#getAllRefs() 
>>> including  Ref objects with null ObjectId in case of unresolvable 
>>> (invalid?) HEAD  symbolic ref, and null Ref for HEAD  when it doesn't 
>>> exist. Previous  behavior was just not including such refs in result.
>>
>> My intention here was that if a ref cannot be resolved, it should
>> not be reported. [...]
>  
> Beside of my temporary fix for that that filters null Ref and Ref with  
> null objectId, I think that 2 more issues may need to be resolved:

Well, I think your temporary fix is correct.  I don't see another way
to implement around it.

> 1) readRefBasic() method is used for reading arbitrary refs, potentially  
> not only those from well-known prefixes as readRefs() does. Is calling  
> setModified()  appropriate for those other refs?

Yes.  If we read something and it is different from what we have cached
we need to signal that the cached data is invalid (which is setModified).
Doing so allows listeners to (eventually) find out that there are changes
made on disk which their subscribers don't know about, but may need to be
informed of.  This way we can identify changes made by command line tools
to a repository that egit has open in the workbench.

> 2) Am I wrong that setModified() is not called in all cases? Consider  
> empty ref file and just...
> if (line == null || line.length() == 0)
>            return new Ref(Ref.Storage.LOOSE, name, null);
>

In this case (and the other like it) we don't call setModified
because there hasn't been a change on disk.  The file wasn't
previously in our cache and the file is empty now.  Either way
the ref has no data so there is no need to notify listeners.

Now there may be other cases that are missing, but this one
is fine as is.

So I'm thinking of applying this:

--8<--
From: Marek Zawirski <marek.zawirski@gmail.com>
Subject: [PATCH] Fix Repository.getAllRefs to skip HEAD if it points to an unborn branch

If HEAD is a symbolic reference pointing to an unborn branch (branch
not yet created) we get a Ref object back for it supplying the name
of the branch, but its ObjectId is null as the branch file itself is
not present in the repository.  In such cases we should not include
the HEAD reference in the returned output.

Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 .../src/org/spearce/jgit/lib/RefDatabase.java      |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index 82b995e..b9c8c8c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -209,7 +209,9 @@ class RefDatabase {
 		readPackedRefs(avail);
 		readLooseRefs(avail, REFS_SLASH, refsDir);
 		try {
-			avail.put(Constants.HEAD, readRefBasic(Constants.HEAD, 0));
+			final Ref r = readRefBasic(Constants.HEAD, 0);
+			if (r != null && r.getObjectId() != null)
+				avail.put(Constants.HEAD, r);
 		} catch (IOException e) {
 			// ignore here
 		}
-- 
1.6.0.rc0.182.gb96c7


-- 
Shawn.

^ permalink raw reply related

* [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-27  3:33 UTC (permalink / raw)
  To: git, Junio C Hamano, Johannes Schindelin; +Cc: Miklos Vajna

Before this patch "git merge-base" accepted only 2 arguments, so
only merge bases between 2 references could be computed.

The purpose of this patch is to make "git merge-base" accept more
than 2 arguments, so that the merge bases between the first given
reference and all the other references can be computed.

This is easily implemented because the "get_merge_bases_many"
function in "commit.c" already implements the needed computation.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
 Documentation/git-merge-base.txt |   27 +++++++++++++++-------
 builtin-merge-base.c             |   45 ++++++++++++++++++++++++++-----------
 commit.h                         |    2 +
 3 files changed, 51 insertions(+), 23 deletions(-)

	Hi,

	No tests yet, but the following changes since the first version:

	- added documentation
	- don't use static variables anymore

	Thanks for your comments,
	Christian.

diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 1a7ecbf..463c230 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -8,26 +8,35 @@ git-merge-base - Find as good common ancestors as possible for a merge
 
 SYNOPSIS
 --------
-'git merge-base' [--all] <commit> <commit>
+'git merge-base' [--all] <commit> <commit>...
 
 DESCRIPTION
 -----------
 
-'git-merge-base' finds as good a common ancestor as possible between
-the two commits. That is, given two commits A and B, `git merge-base A
-B` will output a commit which is reachable from both A and B through
-the parent relationship.
+'git-merge-base' finds as good common ancestors as possible between
+the first commit and the other commits. The default behavior is to
+output only one as good as possible common ancestor, called a merge
+base.
+
+For example, given two commits A and B, `git merge-base A B` will
+output a commit which is reachable from both A and B through the
+parent relationship.
+
+Given three commits A, B and C, `git merge-base A B C` will output a
+commit which is reachable through the parent relationship from both A
+and B, or from both A and C.
 
 Given a selection of equally good common ancestors it should not be
 relied on to decide in any particular way.
 
-The 'git-merge-base' algorithm is still in flux - use the source...
-
 OPTIONS
 -------
 --all::
-	Output all common ancestors for the two commits instead of
-	just one.
+	Output all merge bases for the commits instead of just one. No
+	merge bases in the output should be an ancestor of another
+	merge base in the output. Each common ancestor of the first
+	commit and any of the other commits passed as arguments,
+	should be an ancestor of one of the merge bases in the output.
 
 Author
 ------
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 1cb2925..f2c9756 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -2,9 +2,11 @@
 #include "cache.h"
 #include "commit.h"
 
-static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_all)
+static int show_merge_base(struct commit *rev1, int prev2_nr,
+			   struct commit **prev2, int show_all)
 {
-	struct commit_list *result = get_merge_bases(rev1, rev2, 0);
+	struct commit_list *result = get_merge_bases_many(rev1, prev2_nr,
+							  prev2, 0);
 
 	if (!result)
 		return 1;
@@ -20,12 +22,20 @@ static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_al
 }
 
 static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>";
+"git merge-base [--all] <commit-id> <commit-id>...";
+
+static struct commit *get_commit_reference(const char *arg)
+{
+	unsigned char revkey[20];
+	if (get_sha1(arg, revkey))
+		die("Not a valid object name %s", arg);
+	return lookup_commit_reference(revkey);
+}
 
 int cmd_merge_base(int argc, const char **argv, const char *prefix)
 {
-	struct commit *rev1, *rev2;
-	unsigned char rev1key[20], rev2key[20];
+	struct commit *rev1, **prev2 = NULL;
+	size_t prev2_nr = 0, prev2_alloc = 0;
 	int show_all = 0;
 
 	git_config(git_default_config, NULL);
@@ -38,15 +48,22 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
 			usage(merge_base_usage);
 		argc--; argv++;
 	}
-	if (argc != 3)
+	if (argc < 3)
 		usage(merge_base_usage);
-	if (get_sha1(argv[1], rev1key))
-		die("Not a valid object name %s", argv[1]);
-	if (get_sha1(argv[2], rev2key))
-		die("Not a valid object name %s", argv[2]);
-	rev1 = lookup_commit_reference(rev1key);
-	rev2 = lookup_commit_reference(rev2key);
-	if (!rev1 || !rev2)
+
+	rev1 = get_commit_reference(argv[1]);
+	if (!rev1)
 		return 1;
-	return show_merge_base(rev1, rev2, show_all);
+	argc--; argv++;
+
+	do {
+		struct commit *rev2 = get_commit_reference(argv[1]);
+		if (!rev2)
+			return 1;
+		ALLOC_GROW(prev2, prev2_nr + 1, prev2_alloc);
+		prev2[prev2_nr++] = rev2;
+		argc--; argv++;
+	} while (argc > 1);
+
+	return show_merge_base(rev1, prev2_nr, prev2, show_all);
 }
diff --git a/commit.h b/commit.h
index 77de962..4829a5c 100644
--- a/commit.h
+++ b/commit.h
@@ -121,6 +121,8 @@ int read_graft_file(const char *graft_file);
 struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
 
 extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
+extern struct commit_list *get_merge_bases_many(struct commit *one,
+		int n, struct commit **twos, int cleanup);
 extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
 
 extern int register_shallow(const unsigned char *sha1);
-- 
1.6.0.rc0.43.g00eb.dirty

^ permalink raw reply related

* Re: [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Christian Couder @ 2008-07-27  4:04 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Mike Hommey, git
In-Reply-To: <200807270519.41441.chriscool@tuxfamily.org>

Le dimanche 27 juillet 2008, Christian Couder a écrit :
> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> > t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
> > status when asked to list nonexistent files.  Unfortunately,
> > /bin/ls on Mac OS X 10.3 exits with exit code 0.  So look at
> > its output instead.
> >
> > Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
>
> Acked-by: Christian Couder <chriscool@tuxfamily.org>

It seems that there is a problem with the message itself though. When I "git 
am" it, I get:

fatal: cannot convert from x-unknown to utf-8

It seems that it is mime encoded or something and my git 
(1.6.0.rc0.80.gf54f0) doesn't like it.

Regards,
Christian.

^ permalink raw reply

* [JGIT PATCH 1/1] Compile all Java sources in jgit as UTF-8
From: Shawn O. Pearce @ 2008-07-27  4:11 UTC (permalink / raw)
  To: Robin Rosenberg, Marek Zawirski; +Cc: git

We use a UTF-8 encoding in our source files whenever possible.
If the compiler assumes ASCII we sometimes get warnings parsing
copyright information for authors whose names aren't representable
in US-ASCII.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 make_jgit.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/make_jgit.sh b/make_jgit.sh
index 89df80c..13d0e32 100755
--- a/make_jgit.sh
+++ b/make_jgit.sh
@@ -58,6 +58,7 @@ do
 	 xargs javac \
 		-source 1.5 \
 		-target 1.5 \
+		-encoding UTF-8 \
 		-g \
 		-d ../bin2) || die "Building $p failed."
 	CLASSPATH="$CLASSPATH:$R/$p/bin2"
-- 
1.6.0.rc0.182.gb96c7

^ 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