Ramkumar Ramachandra artag...@gmail.com writes:
+finish_rebase () {
+ if test -f $state_dir/autostash
+ then
+ stash_sha1=$(cat $state_dir/autostash)
+ if git stash apply $stash_sha1 21 /dev/null
+ then
+ echo Applied
On Mon, May 13, 2013 at 6:56 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
The refname_expand() function no longer uses mkpath()/mksnpath() to
perform the pattern expansion. Instead, it uses strbuf_expand(), which
removes the need for using fixed-length
On Mon, May 13, 2013 at 6:54 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
Although we definitely support and encourage use of multi-level branch
names, we have never conciously tried to give support for multi-level
remote names. Currently, they are
On Mon, May 13, 2013 at 7:19 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, May 11, 2013 at 12:21 PM, Johan Herland jo...@herland.net wrote:
+* When displaying more then just remote-tracking branches, make the
s/then/than/
Thanks, will fix.
...Johan
--
Johan Herland,
Jiang Xin worldhello@gmail.com writes:
My initial intention for flags toggle is for git newbies, who are not clear
about how to use -x/-d/-X/-ff options. I feel it may have values for these
people.
It may have value for some of them, but throwing too many options in a
menu is usually
Jiang Xin worldhello@gmail.com writes:
2013/5/13 Matthieu Moy matthieu@grenoble-inp.fr:
Jiang Xin worldhello@gmail.com writes:
* color.interactive.slot: Use customized color for interactive
git-clean output (like git add --interactive). slot may be
prompt, header, help or
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using the Common Digest SHA-1
functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().
Add a COMMON_DIGEST_SHA1
Junio C Hamano wrote:
It is like asking why typeset a space after a sentence a tad wider
than a space after each word:
Not at all. The prompt has nothing to do with sentences.
grouping related things together, and
separating groups of different kind apart, to make it more readable.
You
On Sun, May 12, 2013 at 10:02:39PM -0700, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
On 12/05/2013 19:58, John Keeping wrote:
With the patch below, the --ancestry-path version drops to under 2
seconds.
I'm not sure if this is a good idea though. It helps me say I
On Mon, May 13, 2013 at 3:20 AM, David Aguilar dav...@gmail.com wrote:
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using the Common Digest SHA-1
functions
On Sun, May 12, 2013 at 03:19:49PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
But it is not a big problem. Either 3-way merge notices that there
is nothing new, or you get a conflict and have chance to inspect
what is going on.
It's not a problem here, but
Junio C Hamano wrote:
Especially I did not check if there are
still undesirable data loss behaviour in corner cases that people
were worried about in the discussion.
Check the tests. What am I missing?
In the longer term, it is unmaintainable to make such users (like
this new code)
Junio C Hamano wrote:
Writing it like this:
[...]
with a blank line before the next echo, it would be more readable.
This feels funny. Why not
[...]
without an extra command substitution with an echo?
I'll re-roll if there are more comments. Otherwise, can you fix these
up locally?
On Mon, May 13, 2013 at 12:55 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, May 13, 2013 at 3:20 AM, David Aguilar dav...@gmail.com wrote:
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at
Mac OS X Mountain Lion warns that HMAC_Init() and friends are
deprecated. Use CommonCrypto's HMAC to eliminate the warnings.
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: David Aguilar dav...@gmail.com
---
1/3 not included since it is unchanged.
These are replacement patches for
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using the CommonCrytpo SHA-1
functions for SHA1_Init(), SHA1_Update(), and SHA1_Final().
Add a COMMON_DIGEST_SHA1
Ramkumar Ramachandra artag...@gmail.com writes:
+finish_rebase () {
+ if test -f $state_dir/autostash
+ then
+ stash_sha1=$(cat $state_dir/autostash)
+ if git stash apply $stash_sha1 21 /dev/null
+ then
+ echo Applied
Matthieu Moy wrote:
Any reason why this is not using gettext and the other messages do.
You can run git stash apply or git stash drop at any time.
Fixed. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Especially I did not check if there are
still undesirable data loss behaviour in corner cases that people
were worried about in the discussion.
Check the tests. What am I missing?
I didn't do a thorough check, but my
Ramkumar Ramachandra artag...@gmail.com writes:
Matthieu Moy wrote:
Any reason why this is not using gettext and the other messages do.
You can run git stash apply or git stash drop at any time.
Fixed. Thanks.
After thinking a bit, I have another nit about the message: it's not
clear
On 05/12/2013 05:22 PM, Jason Timrod wrote:
Hi all,
This is a complicated question to try and ask, let alone answer, so I had
best give some background.
I have two repositories --- one of them, which I'll call repoA, is the main
repository, it's the one which most of the code we develop
On Mon, May 13, 2013 at 03:43:43PM +0530, Ramkumar Ramachandra wrote:
SZEDER Gábor wrote:
Don't forget that others might use a different prompt format and using
colors in the prompt is optional. With the default prompt format and
without colors I find that that space definitely helps
On Mon, May 13, 2013 at 01:05:51PM +0200, SZEDER Gábor wrote:
On Mon, May 13, 2013 at 03:43:43PM +0530, Ramkumar Ramachandra wrote:
If we can agree that it's just a matter of taste, we should both be
able to have what we want. Any suggestions on how to make this
configurable?
The same
On Sun, May 12, 2013 at 03:54:14PM -0700, Junio C Hamano wrote:
Thanks; is this the last one for this cycle and is your usual branch
ready to be pulled?
It is now; please pull from the usual place,
git://ozlabs.org/~paulus/gitk.git.
Thanks,
Paul.
--
To unsubscribe from this list: send the
On Mon, May 13, 2013 at 10:58:49AM +0200, Stefan Haller wrote:
Would you also consider Tair Sabirgaliev's v2 patch for not launching
gitk in the background on Mac? This fixes a very serious usability
problem.
http://permalink.gmane.org/gmane.comp.version-control.git/43
Yes, I put it
On Sun, May 12, 2013 at 10:01:38PM -0700, Junio C Hamano wrote:
Michael J Gruber g...@drmicha.warpmail.net writes:
Adding to that:
Somehow I still feel I should introduce a new attribute show (or a
better name) similar to diff so that you can specifiy a diff driver to
use for showing
On Thu, May 09, 2013 at 10:08:24AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Since the point of marking the detached HEAD is to turn off things like
@{-1}@{u}, we would want to be generous and err on the side of
assuming it is a branch if it _might_ be one.
I am not
Hi,
This topic is based on the rebase.autostash topic. It cleans up a few
things, introduces 'git stash store', and patches rebase to use it.
Should be simple enough.
Thanks.
Ramkumar Ramachandra (6):
Documentation/stash: correct synopsis for create
Documentation/stash: document short form
On Mon, May 13, 2013 at 4:23 AM, David Aguilar dav...@gmail.com wrote:
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using the CommonCrytpo SHA-1
functions for
Hi,
On Sun, May 12, 2013 at 02:19:34PM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
Since ages we do not care about our program enough. Lets not treat them
as slaves anymore and say please.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
Signed-off-by: Jonathan
Thanks to Felipe, SZEDER, and Junio for a review of v1. This is a v2
in response to those reviews.
Ramkumar Ramachandra (3):
prompt: introduce GIT_PS1_STATESEPARATOR
prompt: factor out gitstring coloring logic
prompt: colorize ZSH prompt
contrib/completion/git-prompt.sh | 128
A typical prompt looks like:
artagnon|master *=:~/src/git$
^
why do we have this space?
Nobody has branch names that end with +, *, =, or anyway, so it
doesn't serve the purpose of disambiguation.
Make this separator configurable via
So that we can extend it with ZSH-colors in a later patch.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 79 ++--
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
Add colors suitable for use in the ZSH prompt. Having learnt that the
ZSH equivalent of PROMPT_COMMAND is precmd (), you can now use
GIT_PS1_SHOWCOLORHINTS with ZSH.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 40
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Writing it like this:
[...]
with a blank line before the next echo, it would be more readable.
This feels funny. Why not
[...]
without an extra command substitution with an echo?
I'll re-roll if there are more
Junio C Hamano wrote:
No, thanks. I won't be even taking the patch right now, so you have
plenty of time ;-).
There were some additional comments from Matthieu, so I will re-roll
(just this part). I've even posted a stash series based on this one.
Do you have any additional comments?
--
To
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
more serious. If you cache patch IDs with a pathspec restriction ...
What? What business does patch-id have with pathspec-limited diff
generation? You do not rebase or cherry-pick
On Monday 2013-05-13 14:54, Thomas Rast wrote:
As I am sure you are all aware, there are two main religions as to how
one can translate technical material into German: leave the technical
terms mostly in English, or translate them to an appropriate
corresponding word. I'll denote them G+E and
SZEDER Gábor sze...@ira.uka.de writes:
On Mon, May 13, 2013 at 01:05:51PM +0200, SZEDER Gábor wrote:
On Mon, May 13, 2013 at 03:43:43PM +0530, Ramkumar Ramachandra wrote:
If we can agree that it's just a matter of taste, we should both be
able to have what we want. Any suggestions on how
On Mon, May 13, 2013 at 8:30 PM, Heiko Voigt hvo...@hvoigt.net wrote:
+ if (impolite_counter 10)
+ die(Error: Learn some manners, say please some time!);
+ if (polite_counter 10)
+ die(Error: Too many please! I don't believe you.);
NAK. If we
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Especially I did not check if there are
still undesirable data loss behaviour in corner cases that people
were worried about in the discussion.
Check the tests. What am I missing?
In the longer term, it is
Matthieu Moy matthieu@grenoble-inp.fr writes:
One benefit would be to avoid triggering rebuild (and editor reload) by
keeping the timestamps intact. But I agree it's probably not worth the
effort (and definitely isn't in the scope of this series).
It isn't in the scope, of course. If
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
more serious. If you cache patch IDs with a pathspec restriction ...
What? What business does patch-id have
On Sun, May 12, 2013 at 09:56:39PM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
/*
- * The fields f and name of top need to be initialized before calling
+ * All source specific fields in the union, name and the callbacks
+ * fgetc, ungetc, ftell of top need to be
Junio C Hamano wrote:
create is not advertised very widely, but store is too close to
what is already familiar to the people save and we really do not
want to confuse them. store -m message commit sounds as if you
are creating a stash to apply to the given $commit.
In the store series I
Junio C Hamano wrote:
If you restructure the code to formulate gitstring to call a shell
function to do so, people can override it and come up with whatever
format they want to use, no?
The user would essentially have to implement her own
__git_ps1_colorize_string; a function that takes a lot
On 13/05/2013 01:22, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
git log --ancestry-path --left-right E...F --not $(git merge-base
--all E F)
which looks like we're having to repeat ourselves because it's not
paying attention...
You are half wrong; --left-right is about do
Ramkumar Ramachandra artag...@gmail.com writes:
The option parser for create unnecessarily checks $1 inside a case
statement that matches $1 in the first place. Also, use $@, not
$*, as our caller is expecting $1 $2, not $1c$2 (where c is the
first character of IFS).
The first part of the
Ramkumar Ramachandra artag...@gmail.com writes:
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 05e462b..e58ab74 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -17,6 +17,7 @@ SYNOPSIS
[-u|--include-untracked] [-a|--all]
Ramkumar Ramachandra artag...@gmail.com writes:
When the update-ref invocation fails, store_stash currently prints:
Cannot save the current status
This is not very useful for diagnosing the problem. Instead, print:
Cannot store 688268c4254ca5dc6e2effa83bae4f0dbbe75e5b
so we can
Kevin Bracey venit, vidit, dixit 13.05.2013 16:26:
On 13/05/2013 01:22, Junio C Hamano wrote:
Kevin Bracey ke...@bracey.fi writes:
git log --ancestry-path --left-right E...F --not $(git merge-base
--all E F)
which looks like we're having to repeat ourselves because it's not
paying
2013/5/13 Matthieu Moy matthieu@grenoble-inp.fr:
+ /* Confirmation dialog */
+ printf(_(Remove ([y]es/[n]o/[e]dit) ? ));
To be more consistent with git add -p, this should use [] instead of
(), and have no space before ?.
Will be replaced with:
John Keeping j...@keeping.me.uk writes:
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
more serious. If you cache patch IDs with a pathspec restriction ...
Paul Mackerras pau...@samba.org writes:
On Sun, May 12, 2013 at 03:54:14PM -0700, Junio C Hamano wrote:
Thanks; is this the last one for this cycle and is your usual branch
ready to be pulled?
It is now; please pull from the usual place,
git://ozlabs.org/~paulus/gitk.git.
Thanks,
Heiko Voigt hvo...@hvoigt.net writes:
On Sun, May 12, 2013 at 09:56:39PM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
/*
- * The fields f and name of top need to be initialized before calling
+ * All source specific fields in the union, name and the callbacks
+
Ramkumar Ramachandra artag...@gmail.com writes:
Maybe we should add the
line Not for end user interactive use to both descriptions? We can
get that double-underscore if you really want, but it'd stick out like
a sore thumb since we can't change create.
Yeah, good point about the __name.
It
Jeff King venit, vidit, dixit 13.05.2013 13:55:
On Sun, May 12, 2013 at 10:01:38PM -0700, Junio C Hamano wrote:
Michael J Gruber g...@drmicha.warpmail.net writes:
Adding to that:
Somehow I still feel I should introduce a new attribute show (or a
better name) similar to diff so that you
Junio C Hamano wrote:
The semi-user facing git stash create never was meant to take
anything but a message sentence and $* is the proper way to say
everything is meant for a single message (just like echo).
Changing it to $@ will change the semantics in a big way.
Ah, I see. As an
On Mon, May 13, 2013 at 07:46:09AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Mon, May 13, 2013 at 06:53:29AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
The caching layer could also introduce false positives though, which is
This patch is a revised form of the one in my history traversal refinements
series. Pulled out to allow it to proceed faster, given that John Keeping has
found a use for the command.
I suggest this is placed onto pu ahead of the existing series, dropping the
equivalent final commit there. And
The documentation assures users that A...B is defined as A B --not
$(git merge-base --all A B). This wasn't in fact quite true, because
the calculated merge bases were not sent to add_rev_cmdline().
The main effect of this was that although
git rev-list --ancestry-path A B --not $(git
Junio C Hamano wrote:
- The error message store_stash() gives should not be hardcoded in
that function.
Save-stash may want to keep saying 'the current status' as it
said before, but a caller like your rebase-autostash will not be
saving the current status and would want to have
Ramkumar Ramachandra artag...@gmail.com writes:
A typical prompt looks like:
artagnon|master *=:~/src/git$
^
why do we have this space?
Nobody has branch names that end with +, *, =, or anyway, so it
doesn't serve the purpose of disambiguation.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
t/t6019-rev-list-ancestry-path.sh | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/t/t6019-rev-list-ancestry-path.sh
b/t/t6019-rev-list-ancestry-path.sh
index 39b4cb0..5287f6a 100755
---
On 2013-05-13 00.50, Junio C Hamano wrote:
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5551-http-fetch.sh | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Thanks, works like a charm, tested on Mac OS.
/torsten
--
To unsubscribe from this list: send the line
Michael J Gruber g...@drmicha.warpmail.net writes:
But you do have the possibility to use different drivers for diff and
show. For example, for showing a file some sort of automatic pagination
or line numbering can be helpful whereas it would hurt the diff case.
I do not find the example
John Keeping j...@keeping.me.uk writes:
This has the advantage that you get the benefit of the cache if you run
git log --cherry-mark with the same paths more than once. In my
testing the cache is beneficial as soon as you examine more than one
similar range (e.g. master...feature-A and then
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
- The error message store_stash() gives should not be hardcoded in
that function.
Save-stash may want to keep saying 'the current status' as it
said before, but a caller like your rebase-autostash will not be
On Mon, May 13, 2013 at 08:45:21AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
This has the advantage that you get the benefit of the cache if you run
git log --cherry-mark with the same paths more than once. In my
testing the cache is beneficial as soon as you
Looks good. Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
2013/5/13 Thomas Rast tr...@inf.ethz.ch:
Hi
I hope I got together a Cc list that pretty much represents everyone
involved in git core and pro-git book translation into German.
As I am sure you are all aware, there are two main religions as to how
one can translate technical material into
Torsten Bögershausen tbo...@web.de writes:
On 2013-05-13 00.50, Junio C Hamano wrote:
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5551-http-fetch.sh | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Thanks, works like a charm, tested on Mac OS.
/torsten
Thanks; I
Junio C Hamano wrote:
git stash store [-m message] [-e error message] $stash_sha1
1. The message is NOT optional. If the user says 'git stash store
b8bb3fe9', what default message can we possibly put in? There is
absolutely no context: no branch name, nothing. So, the best we can
do
Am 13.05.2013 15:57, schrieb Jan Engelhardt:
On Monday 2013-05-13 14:54, Thomas Rast wrote:
My vote is G+E.
Essentially, so is mine. ...
Same here. I frequently get asked to switch Git back to English when the
LANG=C gets lost, because my coworkers and myself - almost all of which
are native
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
git stash store [-m message] [-e error message] $stash_sha1
...
3. Why are we designing a command-line interface? git stash store
$stash_sha1 $message is sufficient for scripts, and there is
absolutely no point
Junio C Hamano wrote:
I however suspect that you would regret later when you need more
customization. It already happened once for git merge when it was
an internal API for git pull and it was painful to support saner
interface and the traditional one at the same time [*1*].
Oh god.
Junio C Hamano wrote:
*1* And no, don't even try to rewrite git merge call inside git
pull to use the modern style with -m message; you will likely
break it (I've tried once and decided it was not worth the hassle).
This falls in my basket of nice theoretical exercise: a lot of work
for no
On 2013-05-13 18.30, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
On 2013-05-13 00.50, Junio C Hamano wrote:
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5551-http-fetch.sh | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Thanks, works like a
Torsten Bögershausen tbo...@web.de writes:
On 2013-05-13 18.30, Junio C Hamano wrote:
Torsten Bögershausen tbo...@web.de writes:
On 2013-05-13 00.50, Junio C Hamano wrote:
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t5551-http-fetch.sh | 8 ++--
1 file changed, 6
Junio C Hamano wrote:
That is not a valid question.
I was just asking to see if you could think of something. I just did:
named stashes (each one has a different ref/ reflog) for internal use.
Sure, we'll go with the -m -e approach.
--
To unsubscribe from this list: send the line unsubscribe
A release candidate Git v1.8.3-rc2 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
b7569aa316d2e6c29249b15e8fc8e9c25fc7d6b1 git-1.8.3.rc2.tar.gz
Paul Mackerras wrote:
How about changing lines matching:?
Sorry for the slow response. Sounds perfect.
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi,
My vote is G+E, too.
lb1a, Florian Breisch and I are working on the german translation of the
pro-git book (hosted on git-scm.com). We use the repository [1] to share
our work. If someone wants to help us, JOIN US!
The current translation of pro-git is mixed, Ger and G+E. For example,
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
That is not a valid question.
I was just asking to see if you could think of something. I just did:
named stashes (each one has a different ref/ reflog) for internal use.
Sure, we'll go with the -m -e approach.
The
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
My experience is the opposite. I wonder What did the author of this
nonsense comment mean? or What is the purpose of this strange
condition in this if () statement?. Then git log -S finds the
culprit
Only if that if
On Monday 2013-05-13 20:57, Ralph Haußmann wrote:
There is a glossary for the pro-git book (see [2]) but it is not up-to-date
and it is also mixed. Therefor I would like to avoid using this glossary.
I like the idea of a shared wiki (git de.po and pro-git).
I suggest a single page as overview
Junio C Hamano wrote:
The whole point of my response is that it is not a valid approach to
decide to add (or not to add) a reasonable enhancement mechanism
built in from the beginning by asking what future enhancement do
you foresee today?. It is unclear if you got that point.
Right, got it.
Martin Langhoff wrote:
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
My experience is the opposite. I wonder What did the author of this
nonsense comment mean? or What is the purpose of this strange
condition in this if () statement?. Then git log -S finds the
Uses commit-date to sort displayed refs.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Just had this idea and wrote it down in five minutes. The
implementation is only meant to be indicative.
Isn't this awesome?
builtin/branch.c | 32 +---
1 file
This parameter is equivalent to the parameter --parents on svn cp commands
and is useful for non-standard repository layouts.
Signed-off-by: Tobias Schulte tobias.schu...@gliderpilot.de
---
Documentation/git-svn.txt|5
git-svn.perl | 22
Junio C Hamano gits...@pobox.com writes:
Johan Herland jo...@herland.net writes:
Obviously, I named it '%1' since it expands into the _first_ component
of the (slash-separated) shorthand.
OK, I can buy something like
%*
refs/%*
refs/heads/%*
...
Heiko Voigt hvo...@hvoigt.net writes:
On Sun, May 12, 2013 at 02:19:34PM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Jens Lehmann jens.lehm...@web.de
Thomas Rast tr...@inf.ethz.ch writes:
Heiko Voigt hvo...@hvoigt.net writes:
On Sun, May 12, 2013 at 02:19:34PM -0700, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net writes:
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
On Mon, May 13, 2013 at 3:33 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Well, no, it should find the final change that brought it into the
current form. Just like git blame.
Has it been finding zero results in some cases where the current code
matches the pattern? That sounds like a bug.
Jonathan Nieder wrote:
Martin Langhoff wrote:
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
My experience is the opposite. I wonder What did the author of this
nonsense comment mean? or What is the purpose of this strange
condition in this if () statement?.
Jens asked me at git-merge if coverage support was still available.
Turns out it is, but there were some weirdnesses. So this should fix
them. It is relly slow as you still have to run the tests one by
one; despite claims in the wild that it is multiprocess- safe but
thread-unsafe, I am in
Confusingly, the coverage-build target in fact builds with gcov
support _and runs tests_.
Split it into two targets that actually are named after what they do.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
Makefile | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
Change the 'coverage' target to build coverage-untested-functions by
default, so as to make it more discoverable.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 153d24d..6f9d1c7 100644
---
The coverage-compile target depends on coverage-clean, which is
supposed to remove the earlier build products that would get in the
way of the next coverage test run.
However, removing *.gcno is actively wrong. These are the files that
contain the compile-time coverage related data. They are
If the user sets DEFAULT_TEST_TARGET=prove in his config.mak, that
carries over into the coverage tests. Which is really bad if he also
sets GIT_PROVE_OPTS=-j.. as that completely breaks the coverage
runs.
Instead of attempting to mess with the GIT_PROVE_OPTS, just force the
test target to
1 - 100 of 171 matches
Mail list logo
