* [BUG ?] completion of stash name with git stash
From: Mathieu CLAVEL @ 2012-01-19 13:21 UTC (permalink / raw)
To: git
Hello,
I first posted that message on the group for msysgit [1].
====
I'm using mysgit 1.7.8 on XP.
I think the stash name completion has a problem.
I don't know if it's a problem from my system, mysgit or git.
Here are the steps to reproduce (you need to have at least 2 stashed commits).
'+ tab =>' means using the tab to autocomplete the current command. Left part is
before completion, right tab is after completion.
$ git stash list
stash@{0}: WIP on feature/preservation_offres: 7f2c9a8 import.cmd : import par
lot de 10.000 contrats
stash@{1}: WIP on feature/echeancier: ddb7bb0 Mockito : 1.8.5 -> 1.9.0
$ git stash drop '+ tab =>' $ git stash drop stash@{
$ git stash drop stash@{0 '+ tab =>' $ git stash drop stashstash@{0}
I don't know if it's relevant, but I also have 'git flow' and 'git flow
completion' installed, and as said in a previous thread, 'git flow completion'
isn't working with alias [2].
====
Regards,
Mathieu CLAVEL
[1] https://groups.google.com/d/topic/msysgit/AgGY7wl8IJQ/discussion
[2] https://groups.google.com/d/msg/msysgit/UnBHlY9eAK0/JfdH7q2hcsAJ
^ permalink raw reply
* diff --minimal as default?
From: Victor Engmark @ 2012-01-19 13:41 UTC (permalink / raw)
To: git
Git v1.7.8 supports `diff --minimal`. I've got cycles to spare and
usually small files - Is there (or will there be) a configuration
option to set this as the default? If not I'll just use an alias, but
there should still be an inverse option to be able to override it in
special cases.
Cheers,
V
^ permalink raw reply
* More support on branch description?
From: Nguyen Thai Ngoc Duy @ 2012-01-19 14:14 UTC (permalink / raw)
To: Git Mailing List
Hi,
The coming v1.7.9 will introduce branch description, mainly used in
integration process. I think we could make it useful for users who
don't extensively use request-pull/format-patch. Showing a short
summary along with branch name in "git branch" would be nice. "branch
-v" is already used for something else, maybe we can come up with
another option, or "-v -v"? Another place we could show branch
description is "git status". What do you think?
--
Duy
^ permalink raw reply
* Re: diff --minimal as default?
From: Thomas Rast @ 2012-01-19 14:22 UTC (permalink / raw)
To: Victor Engmark; +Cc: git
In-Reply-To: <CAA5Ydx_ZqnaWRK3cEvMkULcrGx8B1MUyi2-Ca8eSBmbDg==fDQ@mail.gmail.com>
Victor Engmark <victor.engmark@gmail.com> writes:
> Git v1.7.8 supports `diff --minimal`. I've got cycles to spare and
> usually small files - Is there (or will there be) a configuration
> option to set this as the default? If not I'll just use an alias, but
> there should still be an inverse option to be able to override it in
> special cases.
AFAIK no config option is planned; you could make a patch :-)
But there's --no-minimal, following the usual pattern for boolean
options.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: More support on branch description?
From: Michael Schubert @ 2012-01-19 15:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <CACsJy8D0_EB6jN7KxpzLtnPnj0HjdU6sNHJRyqXJf-2-ZNatFA@mail.gmail.com>
On 01/19/2012 03:14 PM, Nguyen Thai Ngoc Duy wrote:
> The coming v1.7.9 will introduce branch description, mainly used in
> integration process. I think we could make it useful for users who
> don't extensively use request-pull/format-patch. Showing a short
> summary along with branch name in "git branch" would be nice. "branch
> -v" is already used for something else, maybe we can come up with
> another option, or "-v -v"? Another place we could show branch
> description is "git status". What do you think?
Junio suggested a new option "--verbose-format" for branch some weeks
ago:
http://thread.gmane.org/gmane.comp.version-control.git/186727
I planned on working on it, but haven't found the time yet nor do I
really know which way to go.? (pretty.c seems to be the right
place for format code, but it's very commit format specific atm.)
^ permalink raw reply
* Re: [PATCHv4 0/5] git-p4: small fixes to branches and labels
From: Pete Wyckoff @ 2012-01-19 15:19 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, Vitor Antunes
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Thu, 19 Jan 2012 09:52 +0000:
> This is the fourth version of some small fixes to git-p4 branch and
> label handling, incorporating a fix from Pete Wyckoff and an
> additional failing test.
>
> This change does not fix the other problems with git-p4 labels:
>
> - two p4 labels on the same changelist will fall over
> - labels must match exactly the list of files imported
> - you can't import a label without a p4 commit
This all looks great to me. Thanks for adding that failing test,
and fixing the pre-existing bug in invoking p4 labels.
-- Pete
^ permalink raw reply
* Re: More support on branch description?
From: Nguyen Thai Ngoc Duy @ 2012-01-19 15:24 UTC (permalink / raw)
To: Michael Schubert; +Cc: Git Mailing List
In-Reply-To: <4F183365.5010607@elegosoft.com>
On Thu, Jan 19, 2012 at 10:14 PM, Michael Schubert <mschub@elegosoft.com> wrote:
> Junio suggested a new option "--verbose-format" for branch some weeks
> ago:
>
> http://thread.gmane.org/gmane.comp.version-control.git/186727
>
> I planned on working on it, but haven't found the time yet nor do I
> really know which way to go.? (pretty.c seems to be the right
> place for format code, but it's very commit format specific atm.)
Thanks. I must have missed that. There's another piece of formatting
code in "for-each-ref --format" command (I happened to have a look at
it a few days ago). It's ref-specific, probably closer than pretty.c
for this kind of stuff.
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] diff --word-diff: use non-whitespace regex by default
From: Thomas Rast @ 2012-01-19 15:53 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CALUzUxqXTXZv4RE=4rBa79T3_1y7UdqZ6okjC1y-Ve+=NDbQ2g@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Thu, Jan 12, 2012 at 5:22 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> [snip]
>> Case in point, consider my patch sent out yesterday
>>
>> http://article.gmane.org/gmane.comp.version-control.git/188391
>>
>> It consists of a one-hunk doc update. word-diff is not brilliant:
>>
>> -k::
>> Usually the program [-'cleans up'-]{+removes email cruft from+} the Subject:
>> header line to extract the title line for the commit log
>> [-message,-]
>> [- among which (1) remove 'Re:' or 're:', (2) leading-]
>> [- whitespaces, (3) '[' up to ']', typically '[PATCH]', and-]
>> [- then prepends "[PATCH] ".-]{+message.+} This [-flag forbids-]{+option prevents+} this munging, and is most
>> useful when used to read back 'git format-patch -k' output.
>> [snip the rest as it's only {+}]
>>
>> But character-diff tries too hard to find common subsequences:
>>
>> $ g show HEAD^^ --word-diff-regex='[^[:space:]]' | xsel
>>[snip]
>> w-]{+. T+}hi[-te-]s[-paces, (3) '[' up t-] o[-']', ty-]p[
>>
>> is just line noise? The colors don't even help as most of it is removed
>> (red).
>
> You missed the '+' quantifier, as in
>
> [^[:space:]]+
Did I? I was working from the example you provided earlier
} matrix[a,b,c]
} matrix[d,b,c]
} gives
} matrix[[-a-]{+d+},b,c]
}
} and when we have
}
} ImagineALanguageLikeFoo
} ImagineALanguageLikeBar
} we get
} ImagineALanguageLike[-Foo-]{+Bar+}
Under [^[:space:]]+ neither of the examples would work. Actually,
[^[:space:]]+ is the same as today's default, the [^[:space:]]* I
mentioned later is (strictly speaking) broken as it allows for a
0-length match. (It doesn't really matter because IIRC the engine
ignores 0-length words.)
>> That being said, I can see some arguments for changing the default to
>> split punctuation into a separate word. That is, whereas the current
>> default is semantically equivalent to a wordRegex of
>>
>> [^[:space:]]*
>>
>> (but has a faster code path)
>
> Oh right, there *is* a sensible default implemented in. Somehow I was
> under the impression that there wasn't.
>
> I wonder which is faster, using the non-whitespace regex, or the
> isspace() calls...
I tried measuring it across a few commits, but it mostly gets drowned
out by the diff effort. For a commit with stat
exercises/cgal/cover/cover.cpp | 5 +-
exercises/cgal/cover/cover.in1 |27014 +++++++++++++++-----
exercises/cgal/cover/cover.in2 |48996 +++++++++++++++++++++++------------
exercises/cgal/cover/cover.in3 |55041 +++++++++++++++++++++++++--------------
exercises/cgal/cover/cover.in4 |47600 ++++++++++++++++++++--------------
exercises/cgal/cover/cover.int |43491 ++++++++++++++++++++++---------
exercises/cgal/cover/cover.out1 | 53 +-
exercises/cgal/cover/cover.out2 | 24 +-
exercises/cgal/cover/cover.out3 | 11 +-
exercises/cgal/cover/cover.out4 | 2 +-
exercises/cgal/cover/cover.outt | 23 +-
exercises/cgal/cover/gen | 39 +-
exercises/cgal/cover/gen-1.cpp | 4 +-
exercises/cgal/cover/gen-2.cpp | 6 +-
exercises/cgal/cover/gen-3.cpp | 6 +-
(sorry, can't share as those testcases are secret) I get best-of-5
timings
--word-diff-regex='[^[:space:]]+' 0:07.50real 7.40user 0.07system
--word-diff 0:07.47real 7.41user 0.03system
In conclusion, "meh". I think ripping out the isspace() part would make
for a nice code reduction.
>> and your proposal is equivalent to
>>
>> [^[:space:]]|UTF_8_GUARD
>>
>> I think there is a case to be made for a default of
>>
>> [^[:space:]]|([[:alnum:]]|UTF_8_GUARD)+
>>
>> or some such. There's a lot of bikeshedding lurking in the (non)extent
>> of the [[:alnum:]] here, however.
>
> Care to explain further? Not to sure what you mean here.
For natural language, it may or may not make sense to match numbers as
part of a word.
For typical use in e.g. emails, a lot of punctuation has a double role;
breaking words in
http://article.gmane.org/gmane.comp.version-control.git/188391
may or may not make sense.
For some uses, especially source code, it would be better to match an
underscore _ as part of a complete word, too.
For some programming languages, say lisp, a dash - would also belong in
the same category.
There's no real reason other than ease of implementation why the pattern
handles ASCII non-alphanumerics separately, but non-ASCII UTF-8
non-alnums (like, say, unicode NO-BREAK SPACE which would show as \xc2
\xa0) always goes into a word. But if you were to make UTF-8 sequences
a single word, text in (say) many European languages would become
chunked at accented letters.
I'm sure you can find more items for this list. It's a grey area.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [BUG ?] completion of stash name with git stash
From: Thomas Rast @ 2012-01-19 16:18 UTC (permalink / raw)
To: Mathieu CLAVEL; +Cc: git
In-Reply-To: <loom.20120119T141601-606@post.gmane.org>
Mathieu CLAVEL <math.clavel@gmail.com> writes:
> I'm using mysgit 1.7.8 on XP.
>
> I think the stash name completion has a problem.
> I don't know if it's a problem from my system, mysgit or git.
>
> Here are the steps to reproduce (you need to have at least 2 stashed commits).
> '+ tab =>' means using the tab to autocomplete the current command. Left part is
> before completion, right tab is after completion.
>
> $ git stash list
> stash@{0}: WIP on feature/preservation_offres: 7f2c9a8 import.cmd : import par
> lot de 10.000 contrats
> stash@{1}: WIP on feature/echeancier: ddb7bb0 Mockito : 1.8.5 -> 1.9.0
>
> $ git stash drop '+ tab =>' $ git stash drop stash@{
>
> $ git stash drop stash@{0 '+ tab =>' $ git stash drop stashstash@{0}
>
> I don't know if it's relevant, but I also have 'git flow' and 'git flow
> completion' installed, and as said in a previous thread, 'git flow completion'
> isn't working with alias [2].
This works for me using git completion as shipped with v1.7.9-rc2 and
bash 4.2.10. Double-tabbing at 'git stash drop ' prints a list of
stashes as expected. Which bash version are you using?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [BUG ?] completion of stash name with git stash
From: Mathieu CLAVEL @ 2012-01-19 16:34 UTC (permalink / raw)
To: git
In-Reply-To: <87lip3mzsz.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast <at> student.ethz.ch> writes:
> This works for me using git completion as shipped with v1.7.9-rc2 and
> bash 4.2.10. Double-tabbing at 'git stash drop ' prints a list of
> stashes as expected. Which bash version are you using?
$ bash --version
GNU bash, version 3.1.0(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.
It's the version ship with the last version of msysGit.
I'm not sure I can update bash on Windows without any risk to break something.
So, do you think it's coming from the bash version ?
^ permalink raw reply
* Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 17:20 UTC (permalink / raw)
To: git
In-Reply-To: <CADo4Y9jGYJasDL9m7_50aOTrOyoezdyg=vcsZhQ87Qk-1XfTUQ@mail.gmail.com>
I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
The problem I'm running into is that whenever I change a file in a
directory, I have to bump up the version number in the configuration
file. The larger version value in the config file causes my changes
to be loaded over the old ones.
Most of my commits are edits to a file like "foo.js" and an increment
to the version number in "config". Ideally, each of my features
should live in a single commit and I should be able to make a sequence
of them, each time incrementing the version number in config.
The problem I'm running into starts with me editing version=100. I
create new commits where I set the version to 101, 102, 103, 104.
When I go to push ("git svn dcommit"), my coworkers have incremented
the version to 103. So, I rebase my changes, and get conflicts every
time because of the version number!
Is there a good way to avoid these conflicts? Is there a hook I can
write? Is there a change to this process that would work smoother
with Git and its distributed development? It's okay if the version
number skips numbers (e.g., jumps from 100 to 104), as long as it
increases.
Thanks,
Mike
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: demerphq @ 2012-01-19 18:12 UTC (permalink / raw)
To: mike; +Cc: git
In-Reply-To: <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
On 19 January 2012 18:20, Michael Nahas <mike.nahas@gmail.com> wrote:
> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>
> The problem I'm running into is that whenever I change a file in a
> directory, I have to bump up the version number in the configuration
> file. The larger version value in the config file causes my changes
> to be loaded over the old ones.
>
> Most of my commits are edits to a file like "foo.js" and an increment
> to the version number in "config". Ideally, each of my features
> should live in a single commit and I should be able to make a sequence
> of them, each time incrementing the version number in config.
>
> The problem I'm running into starts with me editing version=100. I
> create new commits where I set the version to 101, 102, 103, 104.
> When I go to push ("git svn dcommit"), my coworkers have incremented
> the version to 103. So, I rebase my changes, and get conflicts every
> time because of the version number!
>
> Is there a good way to avoid these conflicts? Is there a hook I can
> write? Is there a change to this process that would work smoother
> with Git and its distributed development? It's okay if the version
> number skips numbers (e.g., jumps from 100 to 104), as long as it
> increases.
Stop using version numbers and start using the git sha1 of the code
you are using.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [BUG ?] completion of stash name with git stash
From: Thomas Rast @ 2012-01-19 18:14 UTC (permalink / raw)
To: Mathieu CLAVEL; +Cc: git
In-Reply-To: <loom.20120119T172954-563@post.gmane.org>
Mathieu CLAVEL <math.clavel@gmail.com> writes:
> Thomas Rast <trast <at> student.ethz.ch> writes:
>
>> This works for me using git completion as shipped with v1.7.9-rc2 and
>> bash 4.2.10. Double-tabbing at 'git stash drop ' prints a list of
>> stashes as expected. Which bash version are you using?
>
>
> $ bash --version
> GNU bash, version 3.1.0(1)-release (i686-pc-msys)
> Copyright (C) 2005 Free Software Foundation, Inc.
>
> It's the version ship with the last version of msysGit.
> I'm not sure I can update bash on Windows without any risk to break something.
> So, do you think it's coming from the bash version ?
Indeed, I compiled bash 3.1 and with that (and otherwise the same bashrc
etc.) I can reproduce. Ditto for 4.0-rc1, which was the newest version
in the repository where I found the bash source[1], so I couldn't
bisect. Perhaps if you can hunt down something newer you could try to
find the version where it starts working.
[1] git://gitorious.org/bash/bash.git
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Junio C Hamano @ 2012-01-19 18:30 UTC (permalink / raw)
To: Johannes Sixt
Cc: Ævar Arnfjörð Bjarmason, Alex Riesen,
Git Mailing List
In-Reply-To: <4F17C294.6010004@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> ... We have, e.g., NO_MMAP, and I can set it to request
> that some alternative is used, even if I have a working mmap(). The option
> name "NO_GETTEXT" is in exactly the same spirit.
>
>> In the current approach we take for shell scripts, we cannot have "No i18n
>> whatsoever and messages are emit with printf and echo". We always have to
>> go through gettext/eval_gettext even though they may be an implementation
>> that does not do i18n at all.
>
> Just like we go through _() in C code, even though there may be an
> implementation that does not do i18n at all, right?
Yes, just like that. The small detail that _() can be #define'd out to
empty while gettext/eval_gettext cannot be made to be no-impact like that
does not really matter.
> In C, it is easy, in shell code it may be more involved.
Correct.
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Junio C Hamano @ 2012-01-19 18:46 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <8762g87y4q.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> [dropped Dieter as this really goes off on an internal tangent]
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> If somebody is writing a script using "git add" (which is not recommended
>> to begin with)
>
> Can we still stick to that stance? Our tests are increasingly using
> 'git add' instead of 'git update-index --add':
>
> $ git grep 'git[ -]add' t/ | wc -l
> 1540
> $ git grep 'git[ -]update-index --add' t/ | wc -l
> 269
> $ git grep 'git[ -]update-index --add' v1.6.0 t/ | wc -l
> 251
> $ git grep 'git[ -]add' v1.6.0 t/ | wc -l
> 705
Stop being silly.
Have you actually looked at these usage? Some of them are genuinely
testing if "git add" works correctly, so it is out of the scope of this
discussion, but others that could be "git update-index" are feeding the
paths known to the script to exist (and we want 'git add' to error out
if that is not the case).
More generally, scripts in t/ directories are "scripts", but it is totally
different from the kind of "user facing script that behaves as if it is a
complete command, taking its own command line arguments, passing them
through to the underlying plumbing commands".
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 18:48 UTC (permalink / raw)
To: demerphq; +Cc: git
In-Reply-To: <CANgJU+WWq=+BP1ZDbGY3weB5Xey2TtbryDJvz5=eMLFzNet3xQ@mail.gmail.com>
On Thu, Jan 19, 2012 at 1:12 PM, demerphq <demerphq@gmail.com> wrote:
> Stop using version numbers and start using the git sha1 of the code
> you are using.
>
> Yves
1. Others in the group use SVN.
2. The version number needs to be increasing, to work with the current
process. SHA1's are random.
3. The "git sha1" for the commit/snapshot cannot be put into the
config file, which is part of the snapshot.
Mike
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Carlos Martín Nieto @ 2012-01-19 19:20 UTC (permalink / raw)
To: mike; +Cc: git
In-Reply-To: <CADo4Y9iKvoXhKg5pEAB+cbA7Rkfa=nF4TLu0xgcS3dnkNi_n4g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2118 bytes --]
On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:
> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>
> The problem I'm running into is that whenever I change a file in a
> directory, I have to bump up the version number in the configuration
> file. The larger version value in the config file causes my changes
> to be loaded over the old ones.
Is this a deployment script that does this? Why can't it look at whether
files have changed? If a feature isn't ready for production, why is it
in a branch that gets deployed?
>
> Most of my commits are edits to a file like "foo.js" and an increment
> to the version number in "config". Ideally, each of my features
> should live in a single commit and I should be able to make a sequence
> of them, each time incrementing the version number in config.
>
So if you've changed the file but don't increase the config file's
version, it means that the change isn't ready for production? If that's
the case, you've just implemented branches, poorly.
Contrary to what apparently many people think, subversion does support
branches. Get your team to use them.
> The problem I'm running into starts with me editing version=100. I
> create new commits where I set the version to 101, 102, 103, 104.
> When I go to push ("git svn dcommit"), my coworkers have incremented
> the version to 103. So, I rebase my changes, and get conflicts every
> time because of the version number!
This sounds like a race condition that the svn users might be avoiding
by committing everything immediately. Sounds like a buggy development
process.
>
> Is there a good way to avoid these conflicts? Is there a hook I can
> write? Is there a change to this process that would work smoother
> with Git and its distributed development? It's okay if the version
> number skips numbers (e.g., jumps from 100 to 104), as long as it
> increases.
You could write a merge driver that detects this situation and writes in
a higher number, but it's all working around the fact that it's a race
condition.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] add a Makefile switch to avoid gettext translation in shell scripts
From: Alex Riesen @ 2012-01-19 19:52 UTC (permalink / raw)
To: Git Mailing List
Cc: Ævar Arnfjörð Bjarmason, Junio C Hamano,
Jonathan Nieder
In-Reply-To: <CALxABCbaBmP6k5TYrYLCYm8oiv=9cF=N7_opSTKUnbkz5b-cwg@mail.gmail.com>
Some systems have gettext.sh (GNU gettext) installed, but it is either broken
or misconfigured in such a way so its output is not usable.
For instance, on this particular system, a Cygwin installations gettext
produces no output whatsoever.
In case the users of these systems are unable or not interested in fixing
them, setting the new Makefile switch should help:
USE_FALLTHROUGH_GETTEXT_SCHEME=yes
This will replace the translation routines with fallthrough versions, which
currently used only for regression testing.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Alex Riesen, Thu, Jan 19, 2012 10:13:20 +0100:
> On Thu, Jan 19, 2012 at 00:18, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > It makes sense to prefer the system functions by default in both
> > cases, but when the OS one can be broken or lacking we can just add
> > probes or Makefile options like we do for fnmatch() with the
> > NO_FNMATCH_CASEFOLD switch.
>
> Yes, and I personally shall welcome a chance to insult the local IT
> by suggesting BROKEN_SH_GETTEXT. Not that they get the point...
I believe this patch does just that. It is certainly enough for my purposes.
The copy-paste error noticed by Jonathan is also fixed, thanks!
I didn't add the tracking of the switch in GIT-BUILD-OPTIONS: didn't found
how to do it quickly enough in this time of evening, and gave up, thinking
that no one sane would need to set the option anyway. So at the moment a
"make clean" needed when changing it.
Makefile | 4 ++
git-sh-i18n.sh | 102 +++++++++++++++++++++++++++-----------------------------
2 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/Makefile b/Makefile
index a782409..806d126 100644
--- a/Makefile
+++ b/Makefile
@@ -47,6 +47,9 @@ all::
# A translated Git requires GNU libintl or another gettext implementation,
# plus libintl-perl at runtime.
#
+# Define USE_FALLTHROUGH_GETTEXT_SCHEME, if you don't want to trust the
+# installed gettext translation of the shell scripts output.
+#
# Define HAVE_LIBCHARSET_H if you haven't set NO_GETTEXT and you can't
# trust the langinfo.h's nl_langinfo(CODESET) function to return the
# current character set. GNU and Solaris have a nl_langinfo(CODESET),
@@ -1887,6 +1890,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's|@@LOCALEDIR@@|$(localedir_SQ)|g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@USE_FALLTHROUGH_GETTEXT_SCHEME@@/$(USE_FALLTHROUGH_GETTEXT_SCHEME)/g' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+
endef
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index b4575fb..da8b214 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -16,61 +16,44 @@ else
fi
export TEXTDOMAINDIR
-if test -z "$GIT_GETTEXT_POISON"
+GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
+if test -n "@@USE_FALLTHROUGH_GETTEXT_SCHEME@@$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
+then
+ : no probing necessary
+elif test -n "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
- then
- # This is GNU libintl's gettext.sh, we don't need to do anything
- # else than setting up the environment and loading gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Try to use libintl's gettext.sh, or fall back to English if we
- # can't.
- . gettext.sh
-
- elif test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" = "-h"
- then
- # We don't have gettext.sh, but there's a gettext binary in our
- # path. This is probably Solaris or something like it which has a
- # gettext implementation that isn't GNU libintl.
- GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Solaris has a gettext(1) but no eval_gettext(1)
- eval_gettext () {
- gettext "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
-
- else
- # Since gettext.sh isn't available we'll have to define our own
- # dummy pass-through functions.
-
- # Tell our tests that we don't have the real gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- gettext () {
- printf "%s" "$1"
- }
-
- eval_gettext () {
- printf "%s" "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
- fi
-else
- # Emit garbage under GETTEXT_POISON=YesPlease. Unlike the C tests
- # this relies on an environment variable
-
GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
+elif type gettext.sh >/dev/null 2>&1
+then
+ # This is GNU libintl's gettext.sh, we don't need to do anything
+ # else than setting up the environment and loading gettext.sh
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
+elif test "$(gettext -h 2>&1)" = "-h"
+then
+ # We don't have gettext.sh, but there's a gettext binary in our
+ # path. This is probably Solaris or something like it which has a
+ # gettext implementation that isn't GNU libintl.
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
+fi
+export GIT_INTERNAL_GETTEXT_SH_SCHEME
+case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
+gnu)
+ # Try to use libintl's gettext.sh, or fall back to English if we
+ # can't.
+ . gettext.sh
+ ;;
+solaris)
+ # Solaris has a gettext(1) but no eval_gettext(1)
+ eval_gettext () {
+ gettext "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+poison)
+ # Used in tests
gettext () {
printf "%s" "# GETTEXT POISON #"
}
@@ -78,7 +61,20 @@ else
eval_gettext () {
printf "%s" "# GETTEXT POISON #"
}
-fi
+ ;;
+*)
+ gettext () {
+ printf "%s" "$1"
+ }
+
+ eval_gettext () {
+ printf "%s" "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+esac
# Git-specific wrapper functions
gettextln () {
--
1.7.9.rc1.92.ga90a1
^ permalink raw reply related
* [RFC] Making pathspec limited log play nicer with --first-parent
From: Junio C Hamano @ 2012-01-19 19:58 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
I often find myself frustrated when I receive an update to a part of the
project and want to find the latest commit that merges the topic branch
that touched the same area.
For example, I wanted to find the latest merge of any git-p4 related topic
so that I can fork a new topic branch to keep Luke's updates posted today.
Without pathspec, "git log --first-parent" traverses the first-parent
chain just fine, and "-m --stat" shows the list of paths touched by the
merge, so we _could_ ask the question this way:
$ git log --first-parent --oneline -m --stat master |
sed -e '/^ contrib\/fast-import\/git-p4 /q' | tail
The above finds that 8cbfc11 (Merge branch 'pw/p4-view-updates',
2012-01-06) was such a commit.
But a more natural way to spell it does not work as expected:
$ git log --first-parent --oneline -m --stat -1 master -- \
contrib/fast-import/git-p4
This finds ecb7cf9 (git-p4: rewrite view handling, 2012-01-02), which is a
part of the merged topic branch and is _not_ on the first-parent path from
the 'master':
$ git show-branch 8cbfc11 ecb7cf9
! [8cbfc11] Merge branch 'pw/p4-view-updates'
! [ecb7cf9] git-p4: rewrite view handling
--
- [8cbfc11] Merge branch 'pw/p4-view-updates'
+ [8cbfc11^2] git-p4: view spec documentation
++ [ecb7cf9] git-p4: rewrite view handling
The problem happens when the merge simplification logic kicks in when the
traversal inspects the merge 8cbfc11. In this case, the history leading to
the tip of 'master' did not touch git-p4 since 'pw/p4-view-updates' topic
forked from it, and the result of the merge is simply a copy from the tip
of the topic branch in the view limited by the given pathspec. The merge
simplification logic discards the first-parent of the merge and pretends
as if the sole parent of the merge is its second parent, i.e. the tip of
the topic. The history traversal veers off to the side branch, possibly
skipping a large swath of the mainline history if the topic forked from it
long in the past, but that only happens when the mainline did not touch
the paths in the limited view since the side topic forked, so it is not
losing information---but it still is wrong to show the commits on the side
topic when we are explicitly asked to show the first-parent chain.
Here is an attempt to fix this issue, by not allowing us to compare the
merge result with anything but the first parent when --first-parent is in
effect, to avoid the history traversal veering off to the side branch.
As this touches deep innards of a scary hairball that is the revision
traversal machinery, I am obviously not considering it as a 1.7.9
material, but I think we would want to fix it at some point, hopefully
soon.
With this patch, the "more natural way" finds the merge commit I am
looking for.
Comments?
---
revision.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 064e351..9e4596d 100644
--- a/revision.c
+++ b/revision.c
@@ -416,7 +416,7 @@ static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit)
static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp, *parent;
- int tree_changed = 0, tree_same = 0;
+ int tree_changed = 0, tree_same = 0, nth_parent = 0;
/*
* If we don't do pruning, everything is interesting
@@ -444,6 +444,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
while ((parent = *pp) != NULL) {
struct commit *p = parent->item;
+ if (revs->first_parent_only && nth_parent++)
+ break;
if (parse_commit(p) < 0)
die("cannot simplify commit %s (because of %s)",
sha1_to_hex(commit->object.sha1),
^ permalink raw reply related
* Re: Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 20:02 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1327000803.5947.59.camel@centaur.lab.cmartin.tk>
I'm guessing here, but I believe the "version number" is used to make
a directory on the production machine. Thus, older versions of the
javascript are available on the production machines under their older
version number. If there's an issue in production with the new
version, code can be redirected to use the older version that is still
in its directory.
So it probably looks like:
/100/js/<files>
/101/js/<files>
/103/js/<files>
/104/js/<files>
If something goes wrong with version 104, the admin can just tell the
machine to use version 103 instead of 104.
You're right that incrementing this version number is probably not an
issue for SVN users because they put N features in a single commit and
they update the version number once. With git, a user can put N
features in N commits and changing the version number really belongs
in each commit. This makes rebasing suck.
On Thu, Jan 19, 2012 at 2:20 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Thu, 2012-01-19 at 12:20 -0500, Michael Nahas wrote:
>> I'm at a new job and using Git-SVN at a place that is accustomed to SVN.
>>
>> The problem I'm running into is that whenever I change a file in a
>> directory, I have to bump up the version number in the configuration
>> file. The larger version value in the config file causes my changes
>> to be loaded over the old ones.
>
> Is this a deployment script that does this? Why can't it look at whether
> files have changed? If a feature isn't ready for production, why is it
> in a branch that gets deployed?
>
>>
>> Most of my commits are edits to a file like "foo.js" and an increment
>> to the version number in "config". Ideally, each of my features
>> should live in a single commit and I should be able to make a sequence
>> of them, each time incrementing the version number in config.
>>
>
> So if you've changed the file but don't increase the config file's
> version, it means that the change isn't ready for production? If that's
> the case, you've just implemented branches, poorly.
>
> Contrary to what apparently many people think, subversion does support
> branches. Get your team to use them.
>
>> The problem I'm running into starts with me editing version=100. I
>> create new commits where I set the version to 101, 102, 103, 104.
>> When I go to push ("git svn dcommit"), my coworkers have incremented
>> the version to 103. So, I rebase my changes, and get conflicts every
>> time because of the version number!
>
> This sounds like a race condition that the svn users might be avoiding
> by committing everything immediately. Sounds like a buggy development
> process.
>
>>
>> Is there a good way to avoid these conflicts? Is there a hook I can
>> write? Is there a change to this process that would work smoother
>> with Git and its distributed development? It's okay if the version
>> number skips numbers (e.g., jumps from 100 to 104), as long as it
>> increases.
>
> You could write a merge driver that detects this situation and writes in
> a higher number, but it's all working around the fact that it's a race
> condition.
>
> cmn
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: PJ Weisberg @ 2012-01-19 19:58 UTC (permalink / raw)
To: mike; +Cc: demerphq, git
In-Reply-To: <CADo4Y9is9mBOJaU+YRTMedTz7FfDrMFoDiqiUvQpVxQpyariPQ@mail.gmail.com>
On Thu, Jan 19, 2012 at 10:48 AM, Michael Nahas <mike.nahas@gmail.com> wrote:
> On Thu, Jan 19, 2012 at 1:12 PM, demerphq <demerphq@gmail.com> wrote:
>> Stop using version numbers and start using the git sha1 of the code
>> you are using.
>>
>> Yves
>
> 1. Others in the group use SVN.
> 2. The version number needs to be increasing, to work with the current
> process. SHA1's are random.
> 3. The "git sha1" for the commit/snapshot cannot be put into the
> config file, which is part of the snapshot.
Suggestion #1: Just put $Rev$ into the file and be done with it until
the team moves over to Git (at which point you can figure something
else out).
Suggestion #2: In your release process, put something like `sed -e
"s/@@id@@/$(date +%s)/" source-dir/config > release-dir/config`
-PJ
^ permalink raw reply
* Re: Rebase and incrementing version numbers
From: Michael Nahas @ 2012-01-19 20:06 UTC (permalink / raw)
To: PJ Weisberg; +Cc: demerphq, git
In-Reply-To: <CAJsNXTkDdHTMqmXCynT2nEYyuTmSF53RVtG2V+v7b+qcsYYufg@mail.gmail.com>
> Suggestion #1: Just put $Rev$ into the file and be done with it until
> the team moves over to Git (at which point you can figure something
> else out).
>
> Suggestion #2: In your release process, put something like `sed -e
> "s/@@id@@/$(date +%s)/" source-dir/config > release-dir/config`
>
> -PJ
Ideally, this value only increments with a change in a certain directory.
I think using either $Rev$ or a data+time value conditioned on a file
changing in a directory might work. Thanks!
Mike
^ permalink raw reply
* Re: [RFC] Making pathspec limited log play nicer with --first-parent
From: Linus Torvalds @ 2012-01-19 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uqvjwga.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Thu, Jan 19, 2012 at 11:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Comments?
Looks conceptually right, but I do have to admit to hating that new variable.
I don't see a better way to do it, though. Sure, you could do it with just
if (revs->first_parent_only && pp != &commit->parents)
break;
and avoid the new variable that way, but that replaces the annoying
variable with a pretty subtle thing.
Or we could re-write that while() loop and move the 'parent' variable
into it. Like the appended untested thing.
But maybe your patch is better, and my dislike for that parent counter
is just irrational.
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 1606 bytes --]
revision.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/revision.c b/revision.c
index 064e35108478..5e8eb379c369 100644
--- a/revision.c
+++ b/revision.c
@@ -415,7 +415,7 @@ static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit)
static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
{
- struct commit_list **pp, *parent;
+ struct commit_list **pp;
int tree_changed = 0, tree_same = 0;
/*
@@ -441,8 +441,14 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
return;
pp = &commit->parents;
- while ((parent = *pp) != NULL) {
- struct commit *p = parent->item;
+ do {
+ struct commit_list *parent = *pp;
+ struct commit *p;
+
+ if (!parent)
+ break;
+ pp = &parent->next;
+ p = parent->item;
if (parse_commit(p) < 0)
die("cannot simplify commit %s (because of %s)",
@@ -458,7 +464,6 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
* to lose the other branches of this
* merge, so we just keep going.
*/
- pp = &parent->next;
continue;
}
parent->next = NULL;
@@ -487,11 +492,10 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
case REV_TREE_OLD:
case REV_TREE_DIFFERENT:
tree_changed = 1;
- pp = &parent->next;
continue;
}
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
- }
+ } while (!revs->first_parent_only);
if (tree_changed && !tree_same)
return;
commit->object.flags |= TREESAME;
^ permalink raw reply related
* [PATCH] t/Makefile: Use $(sort ...) explicitly where needed
From: Kirill Smelkov @ 2012-01-19 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kirill Smelkov
Starting from GNU Make 3.82 $(wildcard ...) no longer sorts the result
(from NEWS):
* WARNING: Backward-incompatibility!
Wildcards were not documented as returning sorted values, but the results
have been sorted up until this release.. If your makefiles require sorted
results from wildcard expansions, use the $(sort ...) function to request
it explicitly.
http://repo.or.cz/w/make.git/commitdiff/2a59dc32aaf0681dec569f32a9d7ab88a379d34f
so we have to sort tests list or else they are executed in seemingly
random order even for -j1.
Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
t/Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/Makefile b/t/Makefile
index 9046ec9..66ceefe 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -17,9 +17,9 @@ DEFAULT_TEST_TARGET ?= test
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
-T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
-TSVN = $(wildcard t91[0-9][0-9]-*.sh)
-TGITWEB = $(wildcard t95[0-9][0-9]-*.sh)
+T = $(sort $(wildcard t[0-9][0-9][0-9][0-9]-*.sh))
+TSVN = $(sort $(wildcard t91[0-9][0-9]-*.sh))
+TGITWEB = $(sort $(wildcard t95[0-9][0-9]-*.sh))
all: $(DEFAULT_TEST_TARGET)
--
1.7.9.rc2.124.ge3180
^ permalink raw reply related
* Re: [RFC] Making pathspec limited log play nicer with --first-parent
From: Junio C Hamano @ 2012-01-19 20:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <CA+55aFxucaeX7it_Kj7WV3ZbwCukN+wvbuxqJzh3V5Rxz4ib1g@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Jan 19, 2012 at 11:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Comments?
>
> Looks conceptually right, but I do have to admit to hating that new variable.
>
> I don't see a better way to do it, though. Sure, you could do it with just
>
> if (revs->first_parent_only && pp != &commit->parents)
> break;
>
> and avoid the new variable that way, but that replaces the annoying
> variable with a pretty subtle thing.
>
> Or we could re-write that while() loop and move the 'parent' variable
> into it. Like the appended untested thing.
>
> But maybe your patch is better, and my dislike for that parent counter
> is just irrational.
I didn't like that parent counter that _only_ increments when we are
running under first-parent-only mode at the conceptual level. At the
implementation level, of course it is the right thing to do because
outside first-parent-only mode nobody cares about the parent counter,
so it is a valid but subtle optimization.
But I personally find your loop
do {
...
} while (!revs->first_parent_only);
is even more disgusting. It is misleading to have something that is not
supposed to change inside the loop as the terminating condition as if we
are saying "loop until somebody flips that bit" which is clearly not the
case.
So obviously I am saying that I do not think either patch is pretty
without offering a better alternative implementation, which is my usual
badness. As this is not an ultra urgent fix, I'll wait and see if somebody
else comes up with a more readable version.
Thanks for eyeballing the logic side of it, anyway. That was what I was
worried about the change the most.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox