Shawn O. Pearce | 1 Sep 06:29 2007

git-gui i18n status?

Now that git-gui 0.8.2 is out and git 1.5.3 is just around the corner
I am starting to think about bringing the git-gui i18n work into the
main git-gui tree, so we can start working from a common codebase.

Looking at the repository on repo.or.cz it looks like it needs to
be merged/rebased onto 0.8.2.  There is a trivial merge conflict,
but there are some more subtle ones caused by the movement of
the library directory initialization down lower in git-gui.sh.
For example translations won't be initialized if we have an issue
with the output of git-version and want to prompt the user.

What is the current plan?  Should I be looking at the master branch
of git://repo.or.cz/git-gui/git-gui-i18n.git for pulling?  Or are
folks expecting that this series will be cleaned up before I pull it?

--

-- 
Shawn.
Junio C Hamano | 1 Sep 06:57 2007
Picon
Picon

Re: [ANNOUNCE] git/gitweb.git repository

Luben Tuikov <ltuikov <at> yahoo.com> writes:

> --- Junio C Hamano <gitster <at> pobox.com> wrote:
> ...
>> I am a bit worried about the 'master' being a "StGIT stack",
>> though.  Playgrounds to be cherry-picked from (aka 'pu') would
>> make *perfect* sense to be managed that way (and the topics that
>> go only 'pu' of git.git itself are managed the same except that
>> I do not do so using StGIT), but I think we need a stable
>> history for the branch git.git will eventually pull from.
>
> That was my concern too, but seeing the immediate hostility
> I got about asking about the review process I decided not
> to mention it.

I do not think Johannes meant any hostility against you by
mentioning the obvious "person A sets up a repository, he gets
to decide rule for _his_ repository", implication of which is
that anobody else can do the same.

It is a completely different matter how the bits of the results
are decided to be good and bad and merged as part of git.git,
and that will be done with community input as always.

I asked Pasky to host series of patches for various reasons.

 (1) I know I am less qualified than Pasky, you nor Jakub (the
     three people I publicly said I consider more interested in
     and have experience with gitweb than I am).  If I were to
     sift through the patches, I am sure many patches will rot
(Continue reading)

Carlos Rica | 1 Sep 07:10 2007
Picon

[PATCH] git-tag: Fix -l option to use better shell style globs.

This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring.  The same
thing now could be achieved doing "git tag -l '*foo*'".

This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.

Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.

Tests for "git tag" were also changed to reflect this.

Signed-off-by: Carlos Rica <jasampler <at> gmail.com>
---
 builtin-tag.c  |   11 ++---------
 t/t7004-tag.sh |   20 +++++++++-----------
 2 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/builtin-tag.c b/builtin-tag.c
index d6d38ad..348919c 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
 <at>  <at>  -123,22 +123,15  <at>  <at>  static int show_reference(const char *refname, const unsigned char *sha1,
(Continue reading)

Shawn O. Pearce | 1 Sep 07:31 2007

Re: [PATCH] git-tag: Fix -l option to use better shell style globs.

Carlos Rica <jasampler <at> gmail.com> wrote:
> This patch removes certain behaviour of "git tag -l foo", currently
> listing every tag name having "foo" as a substring.  The same
> thing now could be achieved doing "git tag -l '*foo*'".

Even though this is a behavior change, I think its the right thing
to do.  The current behavior of searching "*$arg*" is downright
annoying and not what most users would expect I think, especially
when tools like for-each-ref don't do that.

Then again, I do "*$arg*" in git-gui's revision selection widget.
But there its immediately obvious what is happening and anyone I
have talked[*1*] to prefers it that way.

*1*: Disclaimer: people I talked to has thus far been limited to
     day-job coworkers.

--

-- 
Shawn.
Junio C Hamano | 1 Sep 07:39 2007
Picon
Picon

Re: [PATCH] git-tag: Fix -l option to use better shell style globs.

"Shawn O. Pearce" <spearce <at> spearce.org> writes:

> Carlos Rica <jasampler <at> gmail.com> wrote:
>> This patch removes certain behaviour of "git tag -l foo", currently
>> listing every tag name having "foo" as a substring.  The same
>> thing now could be achieved doing "git tag -l '*foo*'".
>
> Even though this is a behavior change, I think its the right thing
> to do.  The current behavior of searching "*$arg*" is downright
> annoying.

Yes, I concur.  It is very annoying that "git tag -l gui"
matches "gitgui-0.7.0".

Let's fix this.

Karl Hasselström | 1 Sep 07:43 2007

Re: [PATCH] git-svn: fix dcommit clobbering upstream when committing multiple changes

On 2007-08-31 18:16:12 -0700, Eric Wong wrote:

> Although dcommit could detect if the first commit in the series
> would conflict with the HEAD revision in SVN, it could not detect
> conflicts in further commits it made.
>
> Now we rebase each uncommitted change after each revision is
> committed to SVN to ensure that we are up-to-date. git-rebase will
> bail out on conflict errors if our next change cannot be applied and
> committed to SVN cleanly, preventing accidental clobbering of
> changes on the SVN-side.
>
> --no-rebase users will have trouble with this, and are thus warned
> if they are committing more than one commit. Fixing this for
> (hopefully uncommon) --no-rebase users would be more complex and
> will probably happen at a later date.

Shouldn't it be a simple matter of checking if the total diff over the
whole series would conflict with the SVN HEAD?

--

-- 
Karl Hasselström, kha <at> treskal.com
      www.treskal.com/kalle
David Symonds | 1 Sep 07:46 2007
Picon

Re: [ANNOUNCE] git/gitweb.git repository

On 31/08/07, David Symonds <dsymonds <at> gmail.com> wrote:
> On 31/08/2007, Petr Baudis <pasky <at> suse.cz> wrote:
> >   Please feel encouraged to make random forks for your development
> > efforts, or push your random patches (preferrably just bugfixes,
> > something possibly controversial should be kept in safe containment like
> > a fork or separate branch) to the mob branch.
>
> Sorry, I'm still relatively new to git, and couldn't work out how to
> push to the mob branch, so it's inline below. It's fairly minor, just
> adding <span title="foo">..</span> around author names when they get
> abbreviated.

Okay, I worked out how to push to the mob branch: it's commit 37c8546.
I can refactor this somewhat if that's an issue.

Dave.
Junio C Hamano | 1 Sep 08:16 2007
Picon
Picon

Re: [PATCH] git-tag: Fix -l option to use better shell style globs.

Carlos Rica <jasampler <at> gmail.com> writes:

>  	if (pattern == NULL)
> -		pattern = "";
> +		pattern = "*";
>
> -	/* prepend/append * to the shell pattern: */
> -	newpattern = xmalloc(strlen(pattern) + 3);
> -	sprintf(newpattern, "*%s*", pattern);
> -
> -	filter.pattern = newpattern;
> +	filter.pattern = pattern;
>  	filter.lines = lines;
>
>  	for_each_tag_ref(show_reference, (void *) &filter);

I think it is conceptually simpler on the show_reference side to
allow (filter.pattern == NULL) and say:

	if (!filter->pattern || !fnmatch(filter->pattern, refname, 0)) {
        	... show that ref ...
	}

It is not such a big deal now you do not do newpattern
allocation anymore, so I'll apply the patch as is.
Johannes Sixt | 1 Sep 09:25 2007
Picon

[PATCH] rebase -m: Fix incorrect short-logs of already applied commits.

When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:

    o--X--A--B--Y    <- master
     \
      A--B--Z        <- topic

then 'git rebase -m master' would report:

    Already applied: 0001 Y
    Already applied: 0002 Y

With this fix it reports the expected:

    Already applied: 0001 A
    Already applied: 0002 B

As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.

Signed-off-by: Johannes Sixt <johannes.sixt <at> telecom.at>
---
 git-rebase.sh |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index cbafa14..9cf0056 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
 <at>  <at>  -59,20 +59,23  <at>  <at>  continue_merge () {
(Continue reading)

Jari Aalto | 1 Sep 10:39 2007
Picon

Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples

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

> Jari Aalto <jari.aalto <at> cante.net> writes:
>
>> The manual mixed both caret(HEAD^) and tilde (HEAD~N) notation in
>> examples. This may be xconfusing to new users. The "counting" notation
>> HEAD~N likely to be grasped more easily because it allow successive
>> numbering 1, 2, 3 etc.
>
> I am mildly negative on this change.
>
> Referring to (rather, "having to refer to" to fix mistakes) the
> previous commit happens far more often than referring to an
> ancestor of an arbitrary generation away (i.e. HEAD~$n).  I
> think it is a better idea to expose users early on that HEAD^
> notation which is shorter to type.

If the page contains/combines many different ways of doing things,
this creates confusion, especially if the distictions are not explained.
And it would be unnecessary to explain the HEAD^ and HEAD~1 similarities
in every page where these two get mixed.

PRICPLES:

1. The novice user is best served by making things simple and uniform.

2. Utilize concepts that may already be familar. E.g. other VCS/SCM tools
   have concept of counting back revisions with negative numbers: -1,
   -2, -3; so following this same idea in git manual pages would 
   already rang associated bells.
(Continue reading)


Gmane