Git development
 help / color / mirror / Atom feed
* Re: [PATCH 1/4] quote: implement "sq_dequote_many" to unwrap many args in one string
From: Junio C Hamano @ 2009-03-31  5:09 UTC (permalink / raw)
  To: Christian Couder; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <200903310704.52864.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

> But you might want to change the function name in the 
> patch title too.

Thanks, sure I might ;-)

^ permalink raw reply

* Re: [PATCH 1/4] quote: implement "sq_dequote_many" to unwrap many args in one string
From: Christian Couder @ 2009-03-31  5:04 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, John Tapsell, Johannes Schindelin
In-Reply-To: <7vocvjjyqa.fsf@gitster.siamese.dyndns.org>

Le lundi 30 mars 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > @@ -92,6 +92,8 @@ char *sq_dequote(char *arg)
> >  		switch (*++src) {
> >  		case '\0':
> >  			*dst = 0;
> > +			if (next)
> > +				*next = 0;
>
> 	*next = NULL;
>
> >  			return arg;
> >  		case '\\':
> >  			c = *++src;
> >
> >
> >
> > diff --git a/quote.h b/quote.h
> > index c5eea6f..c2f98e7 100644
> > --- a/quote.h
> > +++ b/quote.h
> > @@ -39,6 +39,14 @@ extern void sq_quote_argv(struct strbuf *, const
> > char **argv, size_t maxlen); */
> >  extern char *sq_dequote(char *);
> >
> > +/*
> > + * Same as the above, but can unwraps many arguments in the same
> > string
>
> "can unwrap"
>
> > + * separated by space. "next" is changed to point to the next argument
> > + * that should be passed as first parameter. When there are no more
> > + * arguments to be dequoted, then "next" is changed to point to NULL.
> > + */
> > +extern char *sq_dequote_many(char *arg, char **next);
> > +
> >  extern int unquote_c_style(struct strbuf *, const char *quoted, const
> > char **endp); extern size_t quote_c_style(const char *name, struct
> > strbuf *, FILE *, int no_dq); extern void quote_two_c_style(struct
> > strbuf *, const char *, const char *, int);
>
> I think dequote_many() is misnamed, as it only does one but has a
> slightly more helpful interface than the bare sq_dequote() when the
> caller is willing to dequote many.  It probably should be called
> dequote_step().

Yeah, you are right. But you might want to change the function name in the 
patch title too.

Thanks,
Christian.

^ permalink raw reply

* Re: "git reflog expire --all" very slow
From: Junio C Hamano @ 2009-03-31  4:34 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903301803190.4093@localhost.localdomain>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> I have not checked if there is anything really obvious going on that could 
> change that whole logic that causes us to do merge-bases into something 
> saner, since the reflog code is not a part of git I'm familiar with. 

When we look at one reflog entry with old and new commit, we decide to
prune an old entry if either side is unreachable from the tip of the
branch:

	if (timestamp < cb->cmd->expire_unreachable) {
		if (!cb->ref_commit)
			goto prune;
		if (!old && !is_null_sha1(osha1))
			old = lookup_commit_reference_gently(osha1, 1);
		if (!new && !is_null_sha1(nsha1))
			new = lookup_commit_reference_gently(nsha1, 1);
		if ((old && !in_merge_bases(old, &cb->ref_commit, 1)) ||
		    (new && !in_merge_bases(new, &cb->ref_commit, 1)))
			goto prune;
	}

Most of your reflog entries are expected to be reachable from the tip, so
one optimization would be to mark all commits reachable from the tip
upfront, and omit the in_merge_bases() computation for the ones that are
already marked.  Perhaps something like this...

 builtin-reflog.c |   49 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/builtin-reflog.c b/builtin-reflog.c
index d95f515..f0d61bd 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -52,6 +52,7 @@ struct collect_reflog_cb {
 
 #define INCOMPLETE	(1u<<10)
 #define STUDYING	(1u<<11)
+#define REACHABLE	(1u<<12)
 
 static int tree_is_complete(const unsigned char *sha1)
 {
@@ -209,6 +210,43 @@ static int keep_entry(struct commit **it, unsigned char *sha1)
 	return 1;
 }
 
+static void mark_reachable(struct commit *commit, unsigned long expire_limit)
+{
+	/*
+	 * We need to compute if commit on either side of an reflog
+	 * entry is reachable from the tip of the ref for all entries.
+	 * Mark commits that are reachable from the tip down to the
+	 * time threashold first; we know a commit marked thusly is
+	 * reachable from the tip without running in_merge_bases()
+	 * at all.
+	 */
+	struct commit_list *pending = NULL;
+
+	commit_list_insert(commit, &pending);
+	while (pending) {
+		struct commit_list *entry = pending;
+		struct commit_list *parent;
+		pending = entry->next;
+		commit = entry->item;
+		free(entry);
+		if (commit->object.flags & REACHABLE)
+			continue;
+		commit->object.flags |= REACHABLE;
+		parent = commit->parents;
+		while (parent) {
+			commit = parent->item;
+			parent = parent->next;
+			if (commit->object.flags & REACHABLE)
+				continue;
+			if (parse_commit(commit))
+				continue;
+			if (commit->date < expire_limit)
+				continue;
+			commit_list_insert(commit, &pending);
+		}
+	}
+}
+
 static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
 		const char *email, unsigned long timestamp, int tz,
 		const char *message, void *cb_data)
@@ -234,8 +272,12 @@ static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
 			old = lookup_commit_reference_gently(osha1, 1);
 		if (!new && !is_null_sha1(nsha1))
 			new = lookup_commit_reference_gently(nsha1, 1);
-		if ((old && !in_merge_bases(old, &cb->ref_commit, 1)) ||
-		    (new && !in_merge_bases(new, &cb->ref_commit, 1)))
+		if ((old &&
+		     !(old->object.flags & REACHABLE) &&
+		     !in_merge_bases(old, &cb->ref_commit, 1)) ||
+		    (new &&
+		     !(new->object.flags & REACHABLE) &&
+		     !in_merge_bases(new, &cb->ref_commit, 1)))
 			goto prune;
 	}
 
@@ -288,7 +330,10 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
 	cb.ref_commit = lookup_commit_reference_gently(sha1, 1);
 	cb.ref = ref;
 	cb.cmd = cmd;
+
+	mark_reachable(cb.ref_commit, cmd->expire_unreachable);
 	for_each_reflog_ent(ref, expire_reflog_ent, &cb);
+	clear_commit_marks(cb.ref_commit, REACHABLE);
  finish:
 	if (cb.newlog) {
 		if (fclose(cb.newlog)) {

^ permalink raw reply related

* Re: [Q] merging from one (kernel) stable to another?
From: Kris Shannon @ 2009-03-31  4:20 UTC (permalink / raw)
  To: Git Mailing List
In-Reply-To: <49D09207.9080407@op5.se>

2009/3/30 Andreas Ericsson <ae@op5.se>
>
> Brian Foster wrote:
>>
>>  Whilst this question involves linux(-mips) kernel tree,
>>  it's a git(-related?) question, not a kernel question ....
>>
...
>>  But (using 2.6.21-stable and 2.6.22-stable as proxies),
>>  tests indicate that going from .26.8 to .27 or anything
>>  later will have numerous conflicts (100s? in more than
>>  30 files).  Thinking about it, this isn't too surprising
>>  since the -stable branches cherry-pick important/benign
>>  fixes from later revisions.
>>
>>  What's frustrating is that in essentially all “conflict”
>>  cases, the resolution is simple:  Use the later version.
>
> The trouble is "essentially all", as opposed to "all". Git
> can never know which of the conflicts are which, so it will
> leave it all up to you.

git mailing list <git@vger.kernel.org>

What you could do is something like:

git checkout -b mystable-27 linux-2.6.27-stable
git merge -s ours linux-2.6.26-stable
git checkout local-changes-26
git merge mystable-27

The extra merge might allow git to distinguish between 26->27
conflicts and conflicts due to your local-changes.

BTW, when doing these merges between release branches you
probably want to increase merge.renamelimit.

^ permalink raw reply

* diff: unmerged path?
From: Jon Smirl @ 2009-03-31  2:47 UTC (permalink / raw)
  To: Git Mailing List

What does it mean when I have an unmerged path?

jonsmirl@terra:/home/apps/u-boot$ git diff
* Unmerged path api_examples/intellon.c
jonsmirl@terra:/home/apps/u-boot$

api_examples/intellon.c is a newly created file under stgit.

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* "git reflog expire --all" very slow
From: Linus Torvalds @ 2009-03-31  1:43 UTC (permalink / raw)
  To: Junio C Hamano, Brandon Casey, Johannes Schindelin; +Cc: Git Mailing List


I haven't checked in detail what is up, but I just did a "git gc --prune", 
and it was quiet for about half a minute before anything seemed to happen.

Very irritating, as normally the expensive stuff at least gives you some 
kind of indication of what it's doing.

It turns out that it's the reflog expiration. On my crazy beefy 
Nehalem machine:

	[torvalds@nehalem linux]$ time git reflog expire --all

	real	0m37.596s
	user	0m37.554s
	sys	0m0.040s

and that really isn't good. 37 cpu-seconds on this machine is like half a 
decade on some laptops I could name.

The flat pgprof for this thing (user-land oprofile isn't doing Nehalem 
yet) looks like this:

      %   cumulative   self              self     total           
     time   seconds   seconds    calls   s/call   s/call  name    
     60.94     30.24    30.24 301120211     0.00     0.00  interesting
     12.37     36.38     6.14 301338513     0.00     0.00  insert_by_date
     11.35     42.01     5.63     8776     0.00     0.00  clear_commit_marks
      9.96     46.95     4.94     4388     0.00     0.01  merge_bases_many
      2.16     48.02     1.07 301486366     0.00     0.00  commit_list_insert
      1.21     48.62     0.60 301329737     0.00     0.00  parse_commit
      0.87     49.05     0.43 301637945     0.00     0.00  xmalloc
      0.34     49.22     0.17       24     0.01     0.01  xstrdup
      ...

Ok, so my reflog on this thing has 1583 entries on HEAD (yes, in the last 
90 days, the problem is _not_ that I have a long reflog and am pruning it, 
it _is_ already pruned). Add to that the reflogs for the branches (mainly 
master: 1294), and you end up with apparently a nice total of 4388 reflog 
entries.

And then it looks like for _each_ reflog entry we have:

  expire_reflog_ent()
    in_merge_bases()

which then calls 

  get_merge_bases()
    get_merge_bases_many()
      ..

each of which probably often traverses an appreciable part of the kernel 
tree, since my reflog entries are often merges, and the merge bases need 
easily thousands of commits to look up.

Which explains how you end up with 301 _million_ commits inserted into the 
lists and checked if they are interesting. Since the whole kernel tree has 
only something like 140k commits, and my revlog doesn't even go back more 
than three months, I guess that means that we'll be traversing the same 
commits tens of thousands of times each.

Even on this machine, that whole cluster-f*ck takes a little while. Oops.

I have not checked if there is anything really obvious going on that could 
change that whole logic that causes us to do merge-bases into something 
saner, since the reflog code is not a part of git I'm familiar with. 

Instead, I'm just sending this to Junio, Brandon, and Dscho, who are 
getting the main blame for 'builtin-reflog.c'. Although I'm pretty sure 
this is all Junio, but just in case..

			Linus

^ permalink raw reply

* nomad workflow -- dont pull ... more like...   snatch ...or.. tear!
From: Florian Mickler @ 2009-03-31  0:59 UTC (permalink / raw)
  To: git

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

Hi!

I'm working on many different work stations during the week and have
one central repo, where i interface with an svn upstream. 

because of (but not only because of) git svn's metadata-changes i have
the following workflow, which is currently not well supported with git.

<summary>  (for the busy reader)
    i want to be able to drop my local tracking branches in favor of
    the remote ones, but keep backup-refs and have the opportunity to
    abort if something looks funny.
   
i have a script which does this, which i could submit for starters...

</summary>

my workflow:

i have a remote git repository following an svn upstream. (via git svn) 

there are 2 svn branches i do work on and some topic-branches in
which i prepare features to integrate into the svn branches. 

When i come to work (to any random workstation), i do basically the
following:

firsy i run git-svn-rebase on my central git repo.

then i run my script, which does:

a) run git-fetch origin in my workstations git-repo.

b) for all the branches i currently work on: (eg
origin/svnStableBranch) 

	1. git cherry origin/svnStableBranch svnStableBranch

	2. if everything is contained it skips the next 2 steps

	3. else it shows the not contained commits and waits for
	userinput (strg-c, f for full commit descriptions, or anykey to
	continue) 

	4. it creates backup branch (named tmp_[unixtimestamp])  

	5. it drops local branch and creates a new tracking branch with
	the same name

at the end of my workday, i run svn rebase on origin and run my script
again.

if smth got committed before i could push my changes to the svn, i
decide if i create a new branch on origin for my work, so i can
integrate it next time, or just merge / rebase my commits now.
(recovering them from the backup-branch)

whatever i do i somehow sync my repo onto origin and dcommit
there ...maybe...

the next day i go to any workstation (probably with a working state
from a week ago), run my script to drop the local refs, and continue
working. 

if i have rebased one of my working branches during the week,
i see the refactored log vs the old log and can happily drop the backup
branches. if i see some piece of work which i forgot to push to origin,
and which is worth saving i can do it now.

if not ... good.

Do you see my point? Is smth like this deemed useful? is this
an acceptable workflow? (dropping local refs in favor of remote ones) 

it saves me the hazle of doublecheking the state of my
current workstation every time i change it and if i forgot to push
something a week ago or yesterday, nothing is lost.

is there any possibility that if i submitted a cleaned up version for
this called ''git snatch'' or something like this, it would be
integrated into mainline?

(because of its disruptive nature, maybe git tear would be a better
name?)


Sincerely,
Florian

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

^ permalink raw reply

* Re: [PATCH] Add warning about known issues to documentation of cvsimport
From: Junio C Hamano @ 2009-03-31  0:51 UTC (permalink / raw)
  To: Heiko Voigt; +Cc: Jeff King, git
In-Reply-To: <20090330223646.GC68118@macbook.lan>

Heiko Voigt <hvoigt@hvoigt.net> writes:

> On Mon, Mar 23, 2009 at 11:14:48PM -0400, Jeff King was talking about:
>> On Mon, Mar 23, 2009 at 08:53:05PM +0100, Heiko Voigt wrote:
>> 
>> > The described issues are compiled from the tests by Michael Haggerty and me.
>> > Because it is not apparent that these can be fixed anytime soon at least warn
>> > unwary users not to rely on the inbuilt cvsimport to much.
>> 
>> I think this change is good in concept.
>> 
>> > +[[issues]]
>> > +ISSUES
>> > +------
>> > +Problems related to timestamps:
>> > +
>> > + * If timestamps of commits in the cvs repository are not stable enough
>> > +   to be used for ordering commits
>> > + * If any files were ever "cvs import"ed more than once (e.g., import of
>> > +   more than one vendor release)
>> > + * If the timestamp order of different files cross the revision order
>> > +   within the commit matching time window
>> 
>> Reading this, I kept waiting for the "then" to your "if". I think the
>> implication is "your import will be incorrect". But it would be nice to
>> say _how_, even if it's something as simple as "changes may show up in
>> the wrong commit, the wrong branch, be omitted" or whatever. Just give a
>> general idea of what can happen.
>
> You are right, I actually wanted to update my patch but as I've seen
> today my patch already made it into master. So I guess I will prepare an
> update patch to address these issues.

Thanks.

^ permalink raw reply

* [PATCH] mailmap: resurrect lower-casing of email addresses
From: Johannes Schindelin @ 2009-03-31  0:18 UTC (permalink / raw)
  To: git, gitster; +Cc: Marius Storm-Olsen
In-Reply-To: <cover.1238458535u.git.johannes.schindelin@gmx.de>

Commit 0925ce4(Add map_user() and clear_mailmap() to mailmap) broke the
lower-casing of email addresses.  This mostly did not matter if your
.mailmap has only lower-case email addresses;  However, we did not
require .mailmap to contain lowercase-only email addresses.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 lezzee how that goes
 mailmap.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/mailmap.c b/mailmap.c
index f12bb45..6be91b6 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -50,6 +50,15 @@ static void add_mapping(struct string_list *map,
 {
 	struct mailmap_entry *me;
 	int index;
+	char *p;
+
+	if (old_email)
+		for (p = old_email; *p; p++)
+			*p = tolower(*p);
+	if (new_email)
+		for (p = new_email; *p; p++)
+			*p = tolower(*p);
+
 	if (old_email == NULL) {
 		old_email = new_email;
 		new_email = NULL;
-- 
1.6.2.1.613.g25746

^ permalink raw reply related

* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Giuseppe Bilotta @ 2009-03-30 22:49 UTC (permalink / raw)
  To: Shawn O. Pearce, msysgit, git, Markus Heidelberg
In-Reply-To: <20090330141510.GW23521@spearce.org>


On Monday 30 March 2009 16:15, Shawn O. Pearce wrote:

> Markus Heidelberg <markus.heidelberg@web.de> wrote:
>> 
>> But I just noticed, that it will obviously "cd .." forever, if no .git/
>> was found. Somehow the root directory has to be catched.
> 
> Yup.  I'm dropping this patch for now because of this issue, but
> I'll look at it again if its addressed in another version.  :-)

I have a couple of pending patches to fix git gui handling of repositories,
including support for nonstandard repository locations and bare repositories.
You can find them at

http://git.oblomov.eu/git

and specifically

http://git.oblomov.eu/git/patches/b2e4c32e13df1b7f18e7b4a9f746650471a3122e..a63526bf3238cf25d9a5521f7ee35ed1bd11cb16

I got distracted by real-life issue and forgot to resend them. I'll try
to find the time again later on this week. I'm not entirely sure these
solve Markus' problem though.

-- 
Giuseppe "Oblomov" Bilotta

^ permalink raw reply

* Re: Implementing stat() with FindFirstFile()
From: Johannes Schindelin @ 2009-03-30 23:29 UTC (permalink / raw)
  To: Heiko Voigt; +Cc: Björn Steinbrink, Magnus Bäck, Johannes Sixt, git
In-Reply-To: <20090330220709.GA68118@macbook.lan>

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

Hi,

On Tue, 31 Mar 2009, Heiko Voigt wrote:

> On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:
> > On 2009.03.30 02:52:47 +0200, Johannes Schindelin wrote:
> > > On Mon, 30 Mar 2009, Magnus Bäck wrote:
> > > > On Friday, March 27, 2009 at 03:25 CET, Johannes Schindelin 
> > > > <Johannes.Schindelin@gmx.de> wrote:
> > > > > On Thu, 26 Mar 2009, Magnus Bäck wrote:
> > > > > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always 
> > > > > > been around (I just verified ntdll.dll from NT 4.0), so that's 
> > > > > > not a worry. Don't know why MSDN reports it as introduced in 
> > > > > > XP.
> > > > >
> > > > > As the current maintainer of msysGit, I refuse to have something 
> > > > > in the installer I ship that relies on not-at-all guaranteed 
> > > > > interfaces.
> > > > 
> > > > Although I do appreciate the importance of guaranteed interfaces, 
> > > > I am also pragmatic. An incompatible change in ntdll.dll would 
> > > > break vast amounts of programs, including cygwin. There is a lot 
> > > > to be said about Microsoft and their APIs, but I don't think they 
> > > > have a habit of changing ABIs or function semantics for userland 
> > > > libraries that have been around for 15 years.
> > > 
> > > Had you pointed to some document that states that the function has 
> > > been in all NT-based versions, that would have done the trick.
> > 
> > Not official documentation, but at least from some MS guy it seems: 
> > http://www.osronline.com/showThread.cfm?link=73086 (last message).
> > 
> > Apparently, it was in NT3.x, but they document only what's actually 
> > defined in the header.
> 
> How about runtime checking? You could do GetProcAddress(...) and if you 
> don't get it use the old behaviour. I mean if it really is faster why 
> not let Users of recent systems benefit from it.

While my first reaction was negative, I have to admit that thinking about 
it longer, it does seem to make a whole lot of sense.

Thanks,
Dscho

^ permalink raw reply

* Re: [PATCH] git-svn: fix ls-tree usage with dash-prefixed paths
From: Eric Wong @ 2009-03-30 22:58 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Anton Gyllenberg, Björn Steinbrink
In-Reply-To: <7vy6umdgxq.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> I think that is an independent bug.  Not just "--" but it appears "--d"
> >> seems to hit it (and this is an ancient bug---even v1.0.0 seems to have
> >> it).
> >
> >> I suspect that ls-tree needs a fix, not about "--" but about the pathspec
> >> filtering.  It appears that the part that decides if a subtree is worth
> >> traversing into uses the correct "is a pathspec pattern match leading path
> >> components?" semantics (i.e. "--dashed" matches but "--" doesn't), but
> >> after traversing into subtrees, the part that emits the output uses a
> >> broken semantics "does the path have any pathspec patter as its prefix?"
> >> It shouldn't check for "prefix", but for "leading path components", in
> >> other words, the match must happen at directory boundaries.
> >> 
> >> And I do not think *this* bug is too late to fix.  We should fix it.
> >
> > From the ls-tree documentation, I was under the impression that "--"
> > matching "--dashed" was intended:
> >
> >   When paths are given, show them (note that this isn't really raw
> >   pathnames, but rather a list of patterns to match).
> >
> > It doesn't make sense to me match like this, either; but I do think it
> > was intended and it will break things if people depend on the
> > existing behavior.
> 
> Ok, but then the decision to descend into --dashed should be consistent
> with that policy, no?  Right now, it appears that giving "--" alone says
> "Anything under --dashed can never match that pattern, so I wouldn't
> bother recursing into it".

Right.  Except in the case when there are multiple files inside --dashed/
as Björn's email illustrated.  So there seems to be a bug in the way
the number of files inside --dashed/ affects what "--" does when used
with "--dashed/1" (if --dashed/2 also exists).  Very confusing :x

-- 
Eric Wong

^ permalink raw reply

* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Giuseppe Bilotta @ 2009-03-30 22:49 UTC (permalink / raw)
  To: Shawn O. Pearce, msysgit, git, Markus Heidelberg
In-Reply-To: <20090330141510.GW23521@spearce.org>

On Monday 30 March 2009 16:15, Shawn O. Pearce wrote:

> Markus Heidelberg <markus.heidelberg@web.de> wrote:
>> 
>> But I just noticed, that it will obviously "cd .." forever, if no .git/
>> was found. Somehow the root directory has to be catched.
> 
> Yup.  I'm dropping this patch for now because of this issue, but
> I'll look at it again if its addressed in another version.  :-)

I have a couple of pending patches to fix git gui handling of repositories,
including support for nonstandard repository locations and bare repositories.
You can find them at

http://git.oblomov.eu/git

and specifically

http://git.oblomov.eu/git/patches/b2e4c32e13df1b7f18e7b4a9f746650471a3122e..a63526bf3238cf25d9a5521f7ee35ed1bd11cb16

I got distracted by real-life issue and forgot to resend them. I'll try
to find the time again later on this week. I'm not entirely sure these
solve Markus' problem though.

-- 
Giuseppe "Oblomov" Bilotta


^ permalink raw reply

* What's cooking in git.git (Mar 2009, #07; Mon, 30)
From: Junio C Hamano @ 2009-03-30 22:48 UTC (permalink / raw)
  To: git

Here are the topics that have been cooking.  Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.  The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.

The topics list the commits in reverse chronological order.  The topics
meant to be merged to the maintenance series have "maint-" in their names.

----------------------------------------------------------------
[New Topics]

* cj/doc-format (Fri Mar 27 00:36:47 2009 -0700) 11 commits
 + Merge branch 'cj/doc-quiet' into cj/doc-format
 + Documentation: option to render literal text as bold for manpages
 + Documentation: asciidoc.conf: fix verse block with block titles
 + Documentation: asciidoc.conf: always use <literallayout> for
   [blocktext]
 + Documentation: move "spurious .sp" code into manpage-base.xsl
 + Documentation: move quieting params into manpage-base.xsl
 + Documentation: rename docbook-xsl-172 attribute to git-asciidoc-
   no-roff
 + Documentation: use parametrized manpage-base.xsl with manpage-
   {1.72,normal}.xsl
 + Documentation: move callouts.xsl to manpage-{base,normal}.xsl
 + Documentation/Makefile: break up texi pipeline
 + Documentation/Makefile: make most operations "quiet"

* cj/doc-quiet (Fri Mar 27 01:49:39 2009 -0500) 2 commits
 + Documentation/Makefile: break up texi pipeline
 + Documentation/Makefile: make most operations "quiet"

I think these are ready for 'master'.

* jc/name-branch-iffy (Sat Mar 21 14:30:21 2009 -0700) 3 commits
 - checkout -: make "-" to mean "previous branch" everywhere
 - Don't permit ref/branch names to end with ".lock"
 - check_ref_format(): tighten refname rules

After all the bottom two are probably not so iffy.

* jc/name-branch (Sat Mar 21 14:35:51 2009 -0700) 5 commits
 + strbuf_check_branch_ref(): a helper to check a refname for a
   branch
 + Fix branch -m @{-1} newname
 + check-ref-format --branch: give Porcelain a way to grok branch
   shorthand
 + strbuf_branchname(): a wrapper for branch name shorthands
 + Rename interpret/substitute nth_last_branch functions

* sb/format-patch-patchname (Fri Mar 27 01:13:01 2009 +0100) 7 commits
 + log-tree: fix patch filename computation in "git format-patch"
 + format-patch: --numbered-files and --stdout aren't mutually
   exclusive
 + format-patch: --attach/inline uses filename instead of SHA1
 + format-patch: move get_patch_filename() into log-tree
 + format-patch: pass a commit to reopen_stdout()
 + format-patch: construct patch filename in one function
 + pretty.c: add %f format specifier to format_commit_message()

* mg/tracked-local-branches (Thu Mar 26 21:53:25 2009 +0100) 2 commits
 - [Reroll requested] Make local branches behave like remote branches
   when --tracked
 - Test for local branches being followed with --track

* cc/bisect-filter (Mon Mar 30 06:59:59 2009 +0200) 15 commits
 - bisect--helper: string output variables together with "&&"
 - rev-list: pass "int flags" as last argument of "show_bisect_vars"
 - t6030: test bisecting with paths
 - bisect: use "bisect--helper" and remove "filter_skipped" function
 - bisect: implement "read_bisect_paths" to read paths in
   "$GIT_DIR/BISECT_NAMES"
 - bisect--helper: implement "git bisect--helper"
 - rev-list: call new "filter_skip" function
 + rev-list: pass "revs" to "show_bisect_vars"
 + rev-list: make "show_bisect_vars" non static
 + rev-list: move code to show bisect vars into its own function
 + rev-list: move bisect related code into its own file
 + rev-list: make "bisect_list" variable local to "cmd_rev_list"
 + refs: add "for_each_ref_in" function to refactor "for_each_*_ref"
   functions
 + quote: add "sq_dequote_to_argv" to put unwrapped args in an argv
   array
 + quote: implement "sq_dequote_many" to unwrap many args in one
   string

I've reordered them to make the early three patches independent to the
rest of the series.  Dscho had a suggestion on the search it internally
does, so we might see further reroll of some patches in the series.

* jc/shared-literally (Fri Mar 27 23:21:00 2009 -0700) 4 commits
 + set_shared_perm(): sometimes we know what the final mode bits
   should look like
 + move_temp_to_file(): do not forget to chmod() in "Coda hack"
   codepath
 + Move chmod(foo, 0444) into move_temp_to_file()
 + "core.sharedrepository = 0mode" should set, not loosen

* tr/maint-1.6.1-doc-format-patch--root (Thu Mar 26 18:29:25 2009 +0100) 1 commit
 + Documentation: format-patch --root clarifications

* mh/format-patch-add-header (Thu Mar 26 10:51:05 2009 -0600) 1 commit
 + format-patch: add arbitrary email headers

* ef/fast-export (Mon Mar 23 12:53:09 2009 +0000) 4 commits
 + builtin-fast-export.c: handle nested tags
 + builtin-fast-export.c: fix crash on tagged trees
 + builtin-fast-export.c: turn error into warning
 + test-suite: adding a test for fast-export with tag variants

----------------------------------------------------------------
[Graduated to "master"]

* jk/reflog-date (Fri Mar 20 02:00:43 2009 -0400) 1 commit
 + make oneline reflog dates more consistent with multiline format

* js/maint-1.6.0-exec-path-env (Wed Mar 18 08:42:53 2009 +0100) 1 commit
 + export GIT_EXEC_PATH when git is run with --exec-path

* jc/maint-1.6.0-blame-s (Wed Mar 18 00:13:03 2009 -0700) 1 commit
 + blame: read custom grafts given by -S before calling
   setup_revisions()

The above are all ready for 'next'.

* dm/maint-docco (Thu Mar 19 20:35:34 2009 -0700) 6 commits
 + Documentation: reword example text in git-bisect.txt.
 + Documentation: reworded the "Description" section of git-
   bisect.txt.
 + Documentation: minor grammatical fixes in git-branch.txt.
 + Documentation: minor grammatical fixes in git-blame.txt.
 + Documentation: reword the "Description" section of git-bisect.txt.
 + Documentation: minor grammatical fixes in git-archive.txt.

* mg/test-installed (Mon Mar 16 18:03:12 2009 +0100) 2 commits
 + test-lib.sh: Allow running the test suite against installed git
 + test-lib.sh: Test for presence of git-init in the right path.

* jc/attributes-checkout (Fri Mar 20 10:32:09 2009 +0100) 2 commits
 + Add a test for checking whether gitattributes is honored by
   checkout.
 + Read attributes from the index that is being checked out

Original issue identified, and test provided by Kristian Amlie.

* fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits
 + Display warning for default git push with no push.default config
 + New config push.default to decide default behavior for push

* mg/http-auth (Wed Mar 18 18:46:41 2009 -0500) 6 commits
 + http-push.c: use a faux remote to pass to http_init
 + Do not name "repo" struct "remote" in push_http.c
 + http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient
   versions of cURL
 + http authentication via prompts
 + http_init(): Fix config file parsing
 + http.c: style cleanups

Amos King added push side support on top of my fetch side support.

We may want to also pass --remote parameter from git-push to this backend
as Daniel did as an interim solution for the fetch side, so that we can
handle the configuration better.

* db/push-cleanup (Sun Mar 8 21:06:07 2009 -0400) 2 commits
 + Move push matching and reporting logic into transport.c
 + Use a common function to get the pretty name of refs

----------------------------------------------------------------
[Will merge to 'master' soon]

* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
 + stat_tracking_info(): only count real commits

This gives the merge commits zero weight when talking about how many
commits you have ahead (or behind) of the branch you are tracking.  Even
though I agree that they should carry much less weight than the "real"
commits, because your repeated merge from the other branch does not really
add any real value to the end result, giving them absolute zero weight
somehow feels wrong. At least it shows that your have been _active_ on the
branch.  But I do not feel very strongly about it.

* jc/maint-1.6.0-keep-pack (Sat Mar 21 17:26:11 2009 -0500) 6 commits
 + pack-objects: don't loosen objects available in alternate or kept
   packs
 + t7700: demonstrate repack flaw which may loosen objects
   unnecessarily
 + Remove --kept-pack-only option and associated infrastructure
 + pack-objects: only repack or loosen objects residing in "local"
   packs
 + git-repack.sh: don't use --kept-pack-only option to pack-objects
 + t7700-repack: add two new tests demonstrating repacking flaws

----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]

* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit
 - blame.c: start libifying the blame infrastructure

A few minor point remains in this initial one.

* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
 - Allow --date=local --date=other-format to work as expected

The one I posted had a few corner-case bugs that was caught with the test
suite; this one has them fixed.  People did not like the UI so it is kept
out of 'next'

* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
 - archive.c: add support for --submodules[=(all|checkedout)]

Discussion stalled on the submodule selection criteria.
Probably I should discard it and wait for a reroll if needed.

* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
 - git-merge-file: allow converting the results for the work tree

This is a feature waiting for a user.

We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path".  Instead, merge-file simply wrote out the
data in the canonical repository representation.

rerere has the same issue, but it is a lot worse.  It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out.  It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree().  It also needs to write
in binary mode as well.

* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
 - Support fetching from foreign VCSes
 - Add specification of git-vcs helpers
 - Add "vcs" config option in remotes

* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
 - builtin-replace: use "usage_msg_opt" to give better error messages
 - parse-options: add new function "usage_msg_opt"
 - builtin-replace: teach "git replace" to actually replace
 - Add new "git replace" command
 - environment: add global variable to disable replacement
 - mktag: call "check_sha1_signature" with the replacement sha1
 - replace_object: add a test case
 - object: call "check_sha1_signature" with the replacement sha1
 - sha1_file: add a "read_sha1_file_repl" function
 - replace_object: add mechanism to replace objects found in
   "refs/replace/"
 - refs: add a "for_each_replace_ref" function

I know, I really have to drop everything else and re-read these, but I
haven't managed to.

* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
 - tests: fix "export var=val"
 - notes: refuse to edit notes outside refs/notes/
 - t3301: use test_must_fail instead of !
 - t3301: fix confusing quoting in test for valid notes ref
 - notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
 - notes: only clean up message file when editing
 - handle empty notes gracefully
 - git notes show: test empty notes
 - git-notes: fix printing of multi-line notes
 - notes: fix core.notesRef documentation
 - Add an expensive test for git-notes
 - Speed up git notes lookup
 - Add a script to edit/inspect notes
 - Introduce commit notes

* hv/cvsps-tests (Wed Mar 18 18:33:41 2009 +0100) 7 commits
 - cvsimport: extend testcase about patchset order to contain
   branches
 - cvsimport: add test illustrating a bug in cvsps
 - Add a test of "git cvsimport"'s handling of tags and branches
 - Add some tests of git-cvsimport's handling of vendor branches
 - Test contents of entire cvsimported "master" tree contents
 - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
 - Start a library for cvsimport-related tests

Two cvsimport test topics were rewound from 'next' and merged into this
one.  I'll keep this in 'pu' so that people can polish their cvsps skilz
to resolve issues these tests identify.

----------------------------------------------------------------
[Actively cooking]

* da/difftool (Tue Mar 24 23:29:59 2009 -0700) 5 commits
 - difftool: add a -y shortcut for --no-prompt
 - difftool: use perl built-ins when testing for msys
 - difftool: add various git-difftool tests
 - difftool: add git-difftool to the list of commands
 + difftool: move 'git-difftool' out of contrib

David has further refactoring which was a bit too early for me to pick
up.

----------------------------------------------------------------
[On Hold]

* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
 - receive-pack: default receive.denyDeleteCurrent to refuse

* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
 - Refuse updating the current branch in a non-bare repository via
   push

These are for 1.7.0, but the messages when they trigger together may need
to be rethought.

^ permalink raw reply

* What's in git.git (Mar 2009, #06; Mon, 30)
From: Junio C Hamano @ 2009-03-30 22:47 UTC (permalink / raw)
  To: git

Many small updates on the 'master' front.  I think we can declare feature
freeze for 1.6.3 in about a week, tag -rc0, and keep topics that are still
in 'pu' cooking for 1.6.4 (there are some good ones).

* The 'maint' branch has these fixes since the last announcement.

Allan Caffee (1):
  Documentation: update graph api example.

Carlo Marcelo Arenas Belon (1):
  documentation: update cvsimport description of "-r" for recent clone

Daniel Barkalow (1):
  Give error when no remote is configured

Daniel Cheng (aka SDiZ) (1):
  Fix bash completion in path with spaces

David Aguilar (1):
  everyday: use the dashless form of git-init

Emil Sit (1):
  test-lib: Clean up comments and Makefile.

Eric Wong (1):
  git-svn: fix ls-tree usage with dash-prefixed paths

Jeff King (2):
  doc: clarify how -S works
  ls-files: require worktree when --deleted is given

Johannes Schindelin (2):
  rsync transport: allow local paths, and fix tests
  import-zips: fix thinko

Johannes Sixt (1):
  diff --no-index: Do not generate patch output if other output is
    requested

Junio C Hamano (5):
  read-tree A B C: do not create a bogus index and do not segfault
  GIT 1.6.2.1
  Remove total confusion from git-fetch and git-push
  Update draft release notes to 1.6.2.2
  Update draft release notes to 1.6.2.2

Linus Torvalds (1):
  close_sha1_file(): make it easier to diagnose errors

Michael J Gruber (2):
  git submodule: Add test cases for git submodule add
  git submodule: Fix adding of submodules at paths with ./, .. and //

Nico -telmich- Schottelius (1):
  git-tag(1): add hint about commit messages

Nicolas Pitre (1):
  avoid possible overflow in delta size filtering computation

René Scharfe (3):
  diffcore-pickaxe: use memmem()
  optimize compat/ memmem()
  pickaxe: count regex matches only once

Shawn O. Pearce (1):
  Increase the size of the die/warning buffer to avoid truncation

Stephen Boyd (1):
  format-patch: --numbered-files and --stdout aren't mutually exclusive

Thomas Rast (3):
  send-email: respect in-reply-to regardless of threading
  send-email: test --no-thread --in-reply-to combination
  bash completion: only show 'log --merge' if merging


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (4):
  disable post-checkout test on Cygwin
  Produce a nicer output in case of sha1_object_info failures in ls-tree -l
  Microoptimize strbuf_cmp
  Improve error message about fetch into current branch

Amos King (2):
  Do not name "repo" struct "remote" in push_http.c
  http-push.c: use a faux remote to pass to http_init

Arto Jonsson (1):
  bash completion: add options for 'git fsck'

Ben Walton (7):
  configure: ensure settings from user are also usable in the script
  configure: reorganize flow of argument checks
  configure: add macros to stash FLAG variables
  configure: wrap some library tests with GIT_STASH_FLAGS
  configure: asciidoc version test cleanup
  configure: make iconv tests aware of user arguments
  configure: rework pthread handling to allow for user defined flags

Benjamin Kramer (1):
  Fix various dead stores found by the clang static analyzer

Brandon Casey (2):
  git-branch: display "was sha1" on branch deletion rather than just "sha1"
  builtin-send-pack.c: avoid empty structure initialization

Brian Gernhardt (2):
  Create USE_ST_TIMESPEC and turn it on for Darwin
  Makefile: Set compiler switch for USE_NSEC

Carlos Rica (1):
  config: test for --replace-all with one argument and fix documentation.

Chris Johnsen (2):
  git-push.txt: describe how to default to pushing only current branch
  Documentation: remove extra quoting/emphasis around literal texts

Daniel Barkalow (7):
  Make clone parse the default refspec with the normal code
  Use a single function to match names against patterns
  Use the matching function to generate the match results
  Keep '*' in pattern refspecs
  Support '*' in the middle of a refspec
  Use a common function to get the pretty name of refs
  Move push matching and reporting logic into transport.c

David J. Mellor (12):
  Documentation: minor grammatical fixes in git-archive.txt.
  Documentation: reword the "Description" section of git-bisect.txt.
  Documentation: minor grammatical fixes in git-blame.txt.
  Documentation: minor grammatical fixes in git-branch.txt.
  Documentation: reworded the "Description" section of git-bisect.txt.
  Documentation: reword example text in git-bisect.txt.
  Documentation: remove some uses of the passive voice in git-bisect.txt
  Documentation: minor grammatical fixes and rewording in git-bundle.txt
  Documentation: minor grammatical fixes in git-cat-file.txt
  Documentation: minor grammatical fixes in git-check-attr.txt
  Documentation: minor grammatical fix in git-check-ref-format.txt
  Documentation: Remove spurious uses of "you" in git-bisect.txt.

Elijah Newren (3):
  git-filter-branch: avoid collisions with variables in eval'ed commands
  Correct missing SP characters in grammar comment at top of fast-import.c
  fast-export: Avoid dropping files from commits

Emil Sit (1):
  config.txt: Describe special 'none' handling in core.gitProxy.

Eric Wong (1):
  git-svn: fix ls-tree usage with dash-prefixed paths

Felipe Contreras (8):
  git_config(): not having a per-repo config file is not an error
  git config: trivial rename in preparation for parseopt
  git config: reorganize get_color*
  git config: reorganize to use parseopt
  git config: don't allow multiple config file locations
  git config: don't allow multiple variable types
  git config: don't allow extra arguments for -e or -l.
  git config: don't allow --get-color* and variable type

Finn Arne Gangstad (2):
  New config push.default to decide default behavior for push
  Display warning for default git push with no push.default config

Giuseppe Bilotta (1):
  import-tars: separate author from committer

Heiko Voigt (1):
  Add warning about known issues to documentation of cvsimport

Janos Laube (1):
  MinGW: implement mmap

Jay Soffian (20):
  move duplicated get_local_heads() to remote.c
  move duplicated ref_newer() to remote.c
  move locate_head() to remote.c
  remote: simplify guess_remote_head()
  remote: make copy_ref() perform a deep copy
  remote: let guess_remote_head() optionally return all matches
  remote: make match_refs() copy src ref before assigning to peer_ref
  remote: make match_refs() not short-circuit
  string-list: new for_each_string_list() function
  builtin-remote: refactor duplicated cleanup code
  builtin-remote: remove unused code in get_ref_states
  builtin-remote: rename variables and eliminate redundant function call
  builtin-remote: make get_remote_ref_states() always populate
    states.tracked
  builtin-remote: fix two inconsistencies in the output of "show <remote>"
  builtin-remote: teach show to display remote HEAD
  builtin-remote: add set-head subcommand
  builtin-remote: new show output style
  builtin-remote: new show output style for push refspecs
  send-email: refactor and ensure prompting doesn't loop forever
  send-email: add tests for refactored prompting

Jeff King (12):
  test scripts: refactor start_httpd helper
  add basic http clone/fetch tests
  refactor find_ref_by_name() to accept const list
  remote: make guess_remote_head() use exact HEAD lookup if it is available
  config: set help text for --bool-or-int
  t3000: use test_cmp instead of diff
  ls-files: fix broken --no-empty-directory
  ls-files: require worktree when --deleted is given
  make oneline reflog dates more consistent with multiline format
  remote: improve sorting of "configure for git push" list
  Makefile: turn on USE_ST_TIMESPEC for FreeBSD
  t0060: fix whitespace in "wc -c" invocation

Jens Lehmann (1):
  githooks documentation: post-checkout hook is also called after clone

Johannes Schindelin (7):
  Turn the flags in struct dir_struct into a single variable
  rebase -i: avoid 'git reset' when possible
  winansi: support ESC [ K (erase in line)
  gc --aggressive: make it really aggressive
  t7300: fix clean up on Windows
  Smudge the files fed to external diff and textconv
  Guard a few Makefile variables against user environments

Johannes Sixt (30):
  recv_sideband: Bands #2 and #3 always go to stderr
  t9400, t9401: Do not force hard-linked clone
  test suite: Use 'say' to say something instead of 'test_expect_success'
  Call 'say' outside test_expect_success
  test-lib: Replace uses of $(expr ...) by POSIX shell features.
  test-lib: Simplify test counting.
  test-lib: Introduce test_chmod and use it instead of update-index --chmod
  t2200, t7004: Avoid glob pattern that also matches files
  t5300, t5302, t5303: Do not use /dev/zero
  t5602: Work around path mangling on MSYS
  test-lib: Work around incompatible sort and find on Windows
  test-lib: Work around missing sum on Windows
  Tests on Windows: $(pwd) must return Windows-style paths
  t0050: Check whether git init detected symbolic link support correctly
  test-lib: Infrastructure to test and check for prerequisites
  Propagate --exec-path setting to external commands via GIT_EXEC_PATH
  t3600: Use test prerequisite tags
  Skip tests that fail if the executable bit is not handled by the
    filesystem
  t5302: Use prerequisite tags to skip 64-bit offset tests
  t9100, t9129: Use prerequisite tags for UTF-8 tests
  Use prerequisite tags to skip tests that depend on symbolic links
  t0060: Fix tests on Windows
  Skip tests that require a filesystem that obeys POSIX permissions
  t3700: Skip a test with backslashes in pathspec
  Use prerequisites to skip tests that need unzip
  t7004: Use prerequisite tags to skip tests that need gpg
  t5503: GIT_DEBUG_SEND_PACK is not supported on MinGW
  MinGW: Quote arguments for subprocesses that contain a single-quote
  t7005-editor: Use $SHELL_PATH in the editor scripts
  t7502-commit: Skip SIGTERM test on Windows

Junio C Hamano (15):
  Make git-clone respect branch.autosetuprebase
  builtin-remote.c: no "commented out" code, please
  Not all systems use st_[cm]tim field for ns resolution file timestamp
  grep: cast printf %.*s "precision" argument explicitly to int
  http.c: style cleanups
  Improve "git branch --tracking" output
  http_init(): Fix config file parsing
  http authentication via prompts
  http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient versions of
    cURL
  Read attributes from the index that is being checked out
  Update draft release notes to 1.6.3
  blame: read custom grafts given by -S before calling setup_revisions()
  http tests: Darwin is not that special
  diff --cached: do not borrow from a work tree when a path is marked as
    assume-unchanged
  Update draft release notes to 1.6.3

Kevin Ballard (1):
  builtin-push.c: Fix typo: "anythig" -> "anything"

Kevin McConnell (1):
  Add --staged to bash completion for git diff

Kjetil Barvik (17):
  lstat_cache(): small cleanup and optimisation
  lstat_cache(): generalise longest_match_lstat_cache()
  lstat_cache(): swap func(length, string) into func(string, length)
  unlink_entry(): introduce schedule_dir_for_removal()
  create_directories(): remove some memcpy() and strchr() calls
  write_entry(): cleanup of some duplicated code
  write_entry(): use fstat() instead of lstat() when file is open
  show_patch_diff(): remove a call to fstat()
  lstat_cache(): print a warning if doing ping-pong between cache types
  check_updates(): effective removal of cache entries marked CE_REMOVE
  fix compile error when USE_NSEC is defined
  make USE_NSEC work as expected
  verify_uptodate(): add ce_uptodate(ce) test
  write_index(): update index_state->timestamp after flushing to disk
  Record ns-timestamps if possible, but do not use it without USE_NSEC
  checkout bugfix: use stat.mtime instead of stat.ctime in two places
  Revert "lstat_cache(): print a warning if doing ping-pong between cache
    types"

Kristian Amlie (1):
  Add a test for checking whether gitattributes is honored by checkout.

Michael J Gruber (3):
  test-lib.sh: Test for presence of git-init in the right path.
  test-lib.sh: Allow running the test suite against installed git
  git-branch.txt: document -f correctly

Michele Ballabio (6):
  apply: consistent spelling of "don't"
  apply: hide unused options from short help
  git log: avoid segfault with --all-match
  document --force-rebase
  rebase: add options passed to git-am
  rebase: fix typo (force_rebas -> force-rebas)

Miklos Vajna (11):
  parse-opt: migrate builtin-ls-files.
  Tests: use test_cmp instead of diff where possible
  http-push: using error() and warning() as appropriate
  builtin-apply: use warning() instead of fprintf(stderr, "warning: ")
  builtin-checkout: use warning() instead of fprintf(stderr, "warning: ")
  builtin-fetch-pack: use warning() instead of fprintf(stderr, "warning: ")
  builtin-init-db: use warning() instead of fprintf(stderr, "warning: ")
  builtin-rm: use warning() instead of fprintf(stderr, "warning: ")
  builtin-show-branch: use warning() instead of fprintf(stderr, "warning:
    ")
  builtin-show-ref: use warning() instead of fprintf(stderr, "warning: ")
  refs: use warning() instead of fprintf(stderr, "warning: ")

Nate Case (1):
  format-patch: Respect --quiet option

Nguyễn Thái Ngọc Duy (1):
  grep: prefer builtin over external one when coloring results

Petr Kodl (2):
  MinGW: a helper function that translates Win32 API error codes
  MinGW: a hardlink implementation

René Scharfe (6):
  grep: micro-optimize hit collection for AND nodes
  grep: remove grep_opt argument from match_expr_eval()
  grep: add pmatch and eflags arguments to match_one_pattern()
  grep: color patterns in output
  grep: add support for coloring with external greps
  pickaxe: count regex matches only once

Santi Béjar (2):
  Documentation: enhance branch.<name>.{remote,merge}
  Documentation: push.default applies to all remotes

Simon Arlott (1):
  git-svn: don't output git commits in quiet mode

Stephen Boyd (4):
  git-send-email.txt: describe --compose better
  completion: add --annotate option to send-email
  completion: add --cc and --no-attachment option to format-patch
  completion: add --thread=deep/shallow to format-patch

Wincent Colaiuta (2):
  Grammar fixes to "merge" and "patch-id" docs
  Grammar fix for "git merge" man page

^ permalink raw reply

* Re: [PATCH] Add warning about known issues to documentation of cvsimport
From: Heiko Voigt @ 2009-03-30 22:36 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090324031448.GA12829@coredump.intra.peff.net>

On Mon, Mar 23, 2009 at 11:14:48PM -0400, Jeff King was talking about:
> On Mon, Mar 23, 2009 at 08:53:05PM +0100, Heiko Voigt wrote:
> 
> > The described issues are compiled from the tests by Michael Haggerty and me.
> > Because it is not apparent that these can be fixed anytime soon at least warn
> > unwary users not to rely on the inbuilt cvsimport to much.
> 
> I think this change is good in concept.
> 
> > +[[issues]]
> > +ISSUES
> > +------
> > +Problems related to timestamps:
> > +
> > + * If timestamps of commits in the cvs repository are not stable enough
> > +   to be used for ordering commits
> > + * If any files were ever "cvs import"ed more than once (e.g., import of
> > +   more than one vendor release)
> > + * If the timestamp order of different files cross the revision order
> > +   within the commit matching time window
> 
> Reading this, I kept waiting for the "then" to your "if". I think the
> implication is "your import will be incorrect". But it would be nice to
> say _how_, even if it's something as simple as "changes may show up in
> the wrong commit, the wrong branch, be omitted" or whatever. Just give a
> general idea of what can happen.

You are right, I actually wanted to update my patch but as I've seen
today my patch already made it into master. So I guess I will prepare an
update patch to address these issues.

> 
> Also, this renders somewhat poorly in the manpage version. I get:
> 
> <quote>
> ISSUES
>        Problems related to timestamps:
> 
> 
>        ·   If timestamps of commits in the cvs repository are not stable
>            enough to be used for ordering commits
> 
>        ·   If any files were ever "cvs import"ed more than once (e.g., import
>            of more than one vendor release)
> 
>        ·   If the timestamp order of different files cross the revision order
>            within the commit matching time window
>        Problems related to branches:
> 
> 
>        ·   Branches on which no commits have been made are not imported
> </quote>
> 
> Note the extra blank line between each heading and its list, and the
> lack of a blank line between the end of the first list and the heading
> of the second. Your source is very readable, so it really is just
> asciidoc being silly, but I wonder if there is a way to work around
> that.

My xmlto is not working at the moment. I will check that.

^ permalink raw reply

* Re: [PATCH] Add warning about known issues to documentation of cvsimport
From: Heiko Voigt @ 2009-03-30 22:17 UTC (permalink / raw)
  To: Ferry Huberts (Pelagic); +Cc: Junio C Hamano, git
In-Reply-To: <49C7F233.9050205@pelagic.nl>

On Mon, Mar 23, 2009 at 09:33:55PM +0100, Ferry Huberts (Pelagic) wrote:
> maybe you can also add remarks about autocrlf and safecrlf?
> both need to be off

>From my experience thats not necessarily true. You can use
autocrlf=input to repair broken revisions were crlf's have been
mistakenly committed into the repository. And if I remember correctly
safecrlf helps if you want to make sure that no information gets lost.

So when importing from a nice correct cvs repository you would expect
safecrlf to not stop your import. And I suspect there are actually cvs
users that were very careful with their lineendings who would use it.

cheers Heiko

^ permalink raw reply

* Re: Implementing stat() with FindFirstFile()
From: Heiko Voigt @ 2009-03-30 22:07 UTC (permalink / raw)
  To: Björn Steinbrink
  Cc: Johannes Schindelin, Magnus Bäck, Johannes Sixt, git
In-Reply-To: <20090330051118.GA2681@atjola.homenet>

On Mon, Mar 30, 2009 at 07:11:18AM +0200, Björn Steinbrink wrote:
> On 2009.03.30 02:52:47 +0200, Johannes Schindelin wrote:
> > On Mon, 30 Mar 2009, Magnus Bäck wrote:
> > > On Friday, March 27, 2009 at 03:25 CET,
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > On Thu, 26 Mar 2009, Magnus Bäck wrote:
> > > > > I'd be very surprised if ZwQueryDirectoryFile() hasn't always been
> > > > > around (I just verified ntdll.dll from NT 4.0), so that's not a
> > > > > worry. Don't know why MSDN reports it as introduced in XP.
> > > >
> > > > As the current maintainer of msysGit, I refuse to have something in
> > > > the installer I ship that relies on not-at-all guaranteed interfaces.
> > > 
> > > Although I do appreciate the importance of guaranteed interfaces,
> > > I am also pragmatic. An incompatible change in ntdll.dll would break
> > > vast amounts of programs, including cygwin. There is a lot to be said
> > > about Microsoft and their APIs, but I don't think they have a habit of
> > > changing ABIs or function semantics for userland libraries that have
> > > been around for 15 years.
> > 
> > Had you pointed to some document that states that the function has been in 
> > all NT-based versions, that would have done the trick.
> 
> Not official documentation, but at least from some MS guy it seems:
> http://www.osronline.com/showThread.cfm?link=73086 (last message).
> 
> Apparently, it was in NT3.x, but they document only what's actually
> defined in the header.

How about runtime checking? You could do GetProcAddress(...) and if you
don't get it use the old behaviour. I mean if it really is faster why
not let Users of recent systems benefit from it.

cheers Heiko

^ permalink raw reply

* Re: [PATCHv2 3/4] Documentation: branch.*.merge can also afect  'git-push'
From: Santi Béjar @ 2009-03-30 22:06 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4bzdkkq.fsf@gitster.siamese.dyndns.org>

2009/3/30 Junio C Hamano <gitster@pobox.com>:
> I'll take [1/4] and [2/4] with minor rewording, and I think [4/4] is not
> necessary (push.default is clear enough---and defaultMode won't make it
> any clearer to the first time readers anyway as it is unspecified what
> kind of "mode" it is talking about).

At least to me, mode in the context of 'push' suggest behavior. But
maybe only for second time readers...

>
> I do not understand this [3/4].  I did look at push.default but it is
> unclear how this variable is involved.
>
> Perhaps it is because the word "tracking" in the description "push the
> current branch to the branch it is tracking" is used without explaination.

Maybe the push.default description needs some enhancements, but this
[3/4] is true.

> I think the author meant to say if your local branch frotz by default
> merges changes made to the branch nitfol of the remote repository, "frotz
> tracks nitfol", but the use of the word "track" for that meaning appears
> nowhere in Documentation/glossary-content.txt

So we can define:

push.default = "tracking" = "push the current branch to its upstream branch"

The "upstream branch" is defined in branch.name.merge and could also
be added to glossary-content.

Santi

^ permalink raw reply

* Re: [PATCH 1/8] mergetool: use tabs consistently
From: Charles Bailey @ 2009-03-30 21:35 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: David Aguilar, git
In-Reply-To: <7vzlf3flim.fsf@gitster.siamese.dyndns.org>

On Mon, Mar 30, 2009 at 01:44:01AM -0700, Junio C Hamano wrote:
> Thanks.
> 
> Even though this [1/8] is obviously regression free, and I think the
> overall direction in which the series is going is good, I'll wait until I
> hear Acks from Charles Bailey for the parts that involve mergetool.  I do
> not use either mergetool nor difftool myself, and going over every single
> line of this series to spot potential regression is beyond my bandwidth
> right now.
> 
> I do not think bits only common between mergetool and difftool should be
> called with a very generic name "sh-tools".  We didn't call the result of
> a similar refactoring for launching web browser from help and instaweb
> context with such a generic name (it is called git-web--browse).

OK, I've just had a very quick review of the patch series and, in
general, I like it.

I don't much like [1/8] though. I'm all in favour of consistency, but
this patch touches most of the lines in git-mergetool and tries to go
the opposite way to the consistency drive that we were trying to
introduce gradually (i.e. only through lines materially affected by
subsequent patches) in:

commit 0eea345111a9b9fea4dd2841b80bc7d62964e812
Author: Charles Bailey <charles@hashpling.org>
Date:   Thu Nov 13 12:41:13 2008 +0000

    Fix some tab/space inconsistencies in git-mergetool.sh

If you'd gone the other way the patch to consistency would only affect
23 lines rather than 347 lines and all bar 3 of these lines you
subsequently remove from git-mergetool.sh in later patches anyway.

[2/8] - looks good.

[3/8] - no mergetool impact.

[4/8] - Hmmm, OK. Even so at this point, I'm getting slightly iffy
feelings about the whole init_merge_tool_path sets a variable needed
by the calling script. I know it's only scripting and not programming,
but it seemed less bad to set (global) variables in sh functions when
they were all in the same sh script.

[5/8] - no mergtool impact.

[6/8] - ditto

[7/8] - OK, here's where my uneasiness about global script variables
vs. parameters really gets going. Why is merge_tool a parameter when
it's setup once and doesn't change in the invocation of a script, yet
base_present is a script global but can vary between sets of paths to
be merged?

I fully appreciate that this is just inheriting the way things are
and that they weren't beautiful before, but it somehow seems even
worse when the variables are set in one script and used from a
function in a separate sourced script. We're definitely setting up a
very strong coupling between the two scripts which will make it harder
to change either in the future.

[8/8] - no mergetool impact here.

On the plus side, I really like the introduction and function of the
run_mergetool function. It's exactly the split that will make
extending mergetool resolves of file vs. symlink vs. directory easier
in the future. I have a similar split in some slow brewing patches
myself.

I think that [1/8] is the only patch that I'd relucatant to ack, as it
seems like unnecessary churn and change of direction. Here's a sample
patch for consistency 'the other way'. As I mentioned before, the
first to hunks are made redundant by your subsequent changes anyway,
so I only counted 3 lines that are currently inconsistent in
git-mergetool as it stands at the moment.

Sample patch fixing consistent whitespace 'the other way'.
---
 git-mergetool.sh |   46 +++++++++++++++++++++++-----------------------
 1 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/git-mergetool.sh b/git-mergetool.sh
index 87fa88a..1588b5f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -344,29 +344,29 @@ valid_custom_tool()
 }
 
 valid_tool() {
-	case "$1" in
-		kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
-			;; # happy
-		*)
-			if ! valid_custom_tool "$1"; then
-				return 1
-			fi
-			;;
-	esac
+    case "$1" in
+	kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+	    ;; # happy
+	*)
+	    if ! valid_custom_tool "$1"; then
+		return 1
+	    fi
+	    ;;
+    esac
 }
 
 init_merge_tool_path() {
-	merge_tool_path=`git config mergetool.$1.path`
-	if test -z "$merge_tool_path" ; then
-		case "$1" in
-			emerge)
-				merge_tool_path=emacs
-				;;
-			*)
-				merge_tool_path=$1
-				;;
-		esac
-	fi
+    merge_tool_path=`git config mergetool.$1.path`
+    if test -z "$merge_tool_path" ; then
+	case "$1" in
+	    emerge)
+		merge_tool_path=emacs
+		;;
+	    *)
+		merge_tool_path=$1
+		;;
+	esac
+    fi
 }
 
 prompt_after_failed_merge() {
@@ -389,9 +389,9 @@ prompt_after_failed_merge() {
 if test -z "$merge_tool"; then
     merge_tool=`git config merge.tool`
     if test -n "$merge_tool" && ! valid_tool "$merge_tool"; then
-	    echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
-	    echo >&2 "Resetting to default..."
-	    unset merge_tool
+	echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
+	echo >&2 "Resetting to default..."
+	unset merge_tool
     fi
 fi
 
-- 
1.6.2.323.geaf6e

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/

^ permalink raw reply related

* Re: [PATCH] git-gui: make "Git GUI Here" Explorer extension more robust
From: Markus Heidelberg @ 2009-03-30 20:20 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: msysgit, git, Shawn O. Pearce
In-Reply-To: <alpine.DEB.1.00.0903301001090.7534@intel-tinevez-2-302>


Johannes Schindelin, 30.03.2009:
> Hi,
> 
> On Mon, 30 Mar 2009, Markus Heidelberg wrote:
> 
> > Johannes Schindelin, 30.03.2009:
> > 
> > > On Mon, 30 Mar 2009, Markus Heidelberg wrote:
> > > 
> > > > Starting git-gui via Windows Explorer shell extension caused 
> > > > problems when not started from the project directory, but from a 
> > > > directory within the project: starting the Explorer from the git-gui 
> > > > menu "Explore Working Copy" didn't work then.
> > > > 
> > > > Starting git-gui via Explorer shell extension from the .git 
> > > > directory didn't work at all.
> > > > 
> > > > To make these things possible, "cd .." until we see .git/
> > > 
> > > How does this interact with GIT_WORK_TREE?
> > 
> > Not sure. What's the use case for a globally set GIT_WORK_TREE, how is 
> > it used?
> 
> You can call git gui with a non-global GIT_WORK_TREE by something like 
> this, even on Windows (which your patch does not special case, anyway):
> 
> 	$ GIT_WORK_TREE=/bla/blub git gui

The patch only affected git-gui started via Explorer, i.e. invoked with
--working-dir. But it's right that core.worktree can be set in the
repository.
However, git-gui currently doesn't support the gitdir outside of the
working directory, but it may not be wise to build up on this!?

Hmm, more complicated than I initially thought.

Markus

^ permalink raw reply

* Re: [PATCH] git-gui: run post-checkout hook on checkout
From: Jens Lehmann @ 2009-03-30 20:00 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git, gitster, peff
In-Reply-To: <20090330143435.GA23521@spearce.org>

Shawn O. Pearce schrieb:
> Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> +	# -- Run the post-checkout hook.
>> +	#
>> +	set fd_ph [githook_read post-checkout $old_hash $new_hash 1]
>> +	if {$fd_ph ne {}} {
>> +		upvar #0 pch_error pc_err
> 
> I'd rather spell this "global pch_error".
> 
>> +		set pc_err {}

What i noticed when fixing this issue is that i copied this upvar
statement from the calling of the post-commit hook in commit.tcl
with only a minor change (ommitting the "$cmt_id" behind
"pch_error").

It does seem to be incorrect there too, as i couldn't find any use
of the variable "pc_err" or "pch_error$cmt_id" anywhere in git-gui.
So setting "pc_err" to empty seems pretty pointless, as everywhere
else in commit.tcl "pch_error" is used instead.

Or am i overlooking something? If not, the patch below should correct
that.

Jens

--------------------- 8>< ---------------------

>From 5ddd7e8c2d52fc99e496ed3bc96358cc07e538f1 Mon Sep 17 00:00:00 2001
From: Jens Lehmann <Jens.Lehmann@web.de>
Date: Mon, 30 Mar 2009 20:35:57 +0200
Subject: [PATCH] git-gui: When calling post-commit hook wrong variable was cleared.

Before calling the post-commit hook, the variable "pc_err" is cleared
while later only "pch_error" is used. "pch_error$cmt_id" only appeared in
"upvar"-Statements (which were changed to "global") and was removed.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
 git-gui/lib/commit.tcl |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/git-gui/lib/commit.tcl b/git-gui/lib/commit.tcl
index 9cc8410..7255efb 100644
--- a/git-gui/lib/commit.tcl
+++ b/git-gui/lib/commit.tcl
@@ -398,8 +398,8 @@ A rescan will be automatically started now.
 	#
 	set fd_ph [githook_read post-commit]
 	if {$fd_ph ne {}} {
-		upvar #0 pch_error$cmt_id pc_err
-		set pc_err {}
+		global pch_error
+		set pch_error {}
 		fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
 		fileevent $fd_ph readable \
 			[list commit_postcommit_wait $fd_ph $cmt_id]
@@ -461,7 +461,7 @@ A rescan will be automatically started now.
 }
 
 proc commit_postcommit_wait {fd_ph cmt_id} {
-	upvar #0 pch_error$cmt_id pch_error
+	global pch_error
 
 	append pch_error [read $fd_ph]
 	fconfigure $fd_ph -blocking 1
-- 
1.6.2.1.414.g2daa3

^ permalink raw reply related

* [PATCH v2] git-gui: run post-checkout hook on checkout
From: Jens Lehmann @ 2009-03-30 19:46 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git, gitster, peff

git-gui is using "git-read-tree -u" for checkout which doesn't
invoke the post-checkout hook as a plain git-checkout would.
So git-gui must call the hook itself.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---


Thanks to Shawn for the review of the first version, this one
tries to address all the issues raised.


 git-gui/lib/checkout_op.tcl |   43 +++++++++++++++++++++++++++++++++++++++----
 1 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/git-gui/lib/checkout_op.tcl b/git-gui/lib/checkout_op.tcl
index caca888..9e7412c 100644
--- a/git-gui/lib/checkout_op.tcl
+++ b/git-gui/lib/checkout_op.tcl
@@ -9,6 +9,7 @@ field w_cons   {}; # embedded console window object
 field new_expr   ; # expression the user saw/thinks this is
 field new_hash   ; # commit SHA-1 we are switching to
 field new_ref    ; # ref we are updating/creating
+field old_hash   ; # commit SHA-1 that was checked out when we started
 
 field parent_w      .; # window that started us
 field merge_type none; # type of merge to apply to existing branch
@@ -280,11 +281,11 @@ method _start_checkout {} {
 
 	# -- Our in memory state should match the repository.
 	#
-	repository_state curType curHEAD curMERGE_HEAD
+	repository_state curType old_hash curMERGE_HEAD
 	if {[string match amend* $commit_type]
 		&& $curType eq {normal}
-		&& $curHEAD eq $HEAD} {
-	} elseif {$commit_type ne $curType || $HEAD ne $curHEAD} {
+		&& $old_hash eq $HEAD} {
+	} elseif {$commit_type ne $curType || $HEAD ne $old_hash} {
 		info_popup [mc "Last scanned state does not match repository state.
 
 Another Git program has modified this repository since the last scan.  A rescan must be performed before the current branch can be changed.
@@ -297,7 +298,7 @@ The rescan will be automatically started now.
 		return
 	}
 
-	if {$curHEAD eq $new_hash} {
+	if {$old_hash eq $new_hash} {
 		_after_readtree $this
 	} elseif {[is_config_true gui.trustmtime]} {
 		_readtree $this
@@ -453,13 +454,47 @@ method _after_readtree {} {
 If you wanted to be on a branch, create one now starting from 'This Detached Checkout'."]
 	}
 
+	# -- Run the post-checkout hook.
+	#
+	set fd_ph [githook_read post-checkout $old_hash $new_hash 1]
+	if {$fd_ph ne {}} {
+		global pch_error
+		set pch_error {}
+		fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
+		fileevent $fd_ph readable [cb _postcheckout_wait $fd_ph]
+	} else {
+		_update_repo_state $this
+	}
+}
+
+method _postcheckout_wait {fd_ph} {
+	global pch_error
+
+	append pch_error [read $fd_ph]
+	fconfigure $fd_ph -blocking 1
+	if {[eof $fd_ph]} {
+		if {[catch {close $fd_ph}]} {
+			hook_failed_popup post-checkout $pch_error 0
+		}
+		unset pch_error
+		_update_repo_state $this
+		return
+	}
+	fconfigure $fd_ph -blocking 0
+}
+
+method _update_repo_state {} {
 	# -- Update our repository state.  If we were previously in
 	#    amend mode we need to toss the current buffer and do a
 	#    full rescan to update our file lists.  If we weren't in
 	#    amend mode our file lists are accurate and we can avoid
 	#    the rescan.
 	#
+	global selected_commit_type commit_type HEAD MERGE_HEAD PARENT
+	global ui_comm
+
 	unlock_index
+	set name [_name $this]
 	set selected_commit_type new
 	if {[string match amend* $commit_type]} {
 		$ui_comm delete 0.0 end
-- 
1.6.2.1.414.g2daa3

^ permalink raw reply related

* [PATCH] gitk: Map KP_Divide to focus the search box
From: Michele Ballabio @ 2009-03-30 12:55 UTC (permalink / raw)
  To: paulus; +Cc: git

Commit 97bed034 changed the behavior of the '/' key on the keyboard,
but the '/' on the keypad was left unused. They now both do the same
thing.

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
 gitk |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/gitk b/gitk
index a7294a1..3835a51 100755
--- a/gitk
+++ b/gitk
@@ -2313,6 +2313,7 @@ proc makewindow {} {
     bindkey d "$ctext yview scroll 18 units"
     bindkey u "$ctext yview scroll -18 units"
     bindkey / {focus $fstring}
+    bindkey <Key-KP_Divide> {focus $fstring}
     bindkey <Key-Return> {dofind 1 1}
     bindkey ? {dofind -1 1}
     bindkey f nextfile
-- 
1.6.2.22.gc2ac

^ permalink raw reply related

* [PATCH] gitk: Mark some strings for translation
From: Michele Ballabio @ 2009-03-30 19:17 UTC (permalink / raw)
  To: paulus; +Cc: git

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
 gitk |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gitk b/gitk
index 3835a51..8b61d0d 100755
--- a/gitk
+++ b/gitk
@@ -521,7 +521,7 @@ proc updatecommits {} {
     incr viewactive($view)
     set viewcomplete($view) 0
     reset_pending_select {}
-    nowbusy $view "Reading"
+    nowbusy $view [mc "Reading"]
     if {$showneartags} {
 	getallcommits
     }
@@ -3766,7 +3766,7 @@ proc editview {} {
     set newviewopts($curview,perm) $viewperm($curview)
     set newviewopts($curview,cmd)  $viewargscmd($curview)
     decode_view_opts $curview $viewargs($curview)
-    vieweditor $top $curview "Gitk: edit view $viewname($curview)"
+    vieweditor $top $curview "[mc "Gitk: edit view"] $viewname($curview)"
 }
 
 proc vieweditor {top n title} {
@@ -10227,7 +10227,7 @@ proc doprefs {} {
 proc choose_extdiff {} {
     global extdifftool
 
-    set prog [tk_getOpenFile -title "External diff tool" -multiple false]
+    set prog [tk_getOpenFile -title [mc "External diff tool"] -multiple false]
     if {$prog ne {}} {
 	set extdifftool $prog
     }
-- 
1.6.2.22.gc2ac

^ 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