On Tue, Apr 23, 2013 at 8:35 AM, Zoltan Klinger
zoltan.klin...@gmail.com wrote:
When a rebase is interrupted by a merge conflict it could be useful to
know how far a rebase has progressed and how many commits in total this
rebase will apply. Teach the __git_ps1() command to display the number
On Tue, Apr 23, 2013 at 10:08 AM, Junio C Hamano gits...@pobox.com wrote:
Zoltan Klinger zoltan.klin...@gmail.com writes:
When a rebase is interrupted by a merge conflict it could be useful to
know how far a rebase has progressed and how many commits in total this
rebase will apply. Teach the
Johan Herland jo...@herland.net writes:
This raises the same question I recently asked Antoine: For a given
prepackaged merge X,Y, do we assume that it only resolves conflicts
between the changes introduced in commit X vs. changes introduced in
commit Y, or do we assume that it resolves
On Tue, Apr 23, 2013 at 7:13 AM, Łukasz Stelmach l.stelm...@samsung.com wrote:
Enable sending patches to NNTP servers (Usenet, Gmane).
---
diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..0356635 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1174,6
It was 2013-04-24 śro 09:19, when Eric Sunshine wrote:
On Tue, Apr 23, 2013 at 7:13 AM, Łukasz Stelmach l.stelm...@samsung.com
wrote:
Enable sending patches to NNTP servers (Usenet, Gmane).
---
diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..0356635 100755
---
It was 2013-04-23 wto 17:02, when Junio C Hamano wrote:
Łukasz Stelmach l.stelm...@samsung.com writes:
Enable sending patches to NNTP servers (Usenet, Gmane).
---
The patch implements support for sending messages to groups on NNTP serviers.
Cute.
A Perl guru might want to encapsulate the
Łukasz Stelmach l.stelm...@samsung.com writes:
Enable sending patches to NNTP servers (Usenet, Gmane).
I'm surprised Junio didn't mention this: your patch lacks the
Signed-off-by.
+ if ($email_protocol eq 'nntp') {
+ $header = Newsgroups: $to\n . $header;
+ } else {
+
Am Dienstag, den 23.04.2013, 22:50 +0200 schrieb Johan Herland:
On Tue, Apr 23, 2013 at 4:59 PM, Junio C Hamano gits...@pobox.com wrote:
Jan Weitzel j.weit...@phytec.de writes:
Hello,
I have the following problem: I have 2 bare git repositories one has
several branches and tags.
If I
Am 4/23/2013 21:31, schrieb Junio C Hamano:
* fc/transport-helper-error-reporting (2013-04-17) 9 commits
(merged to 'next' on 2013-04-22 at 5ba6467)
+ transport-helper: update remote helper namespace
+ transport-helper: trivial code shuffle
+ transport-helper: warn when refspec is not
On Mon, Apr 22, 2013 at 11:03:44AM -0700, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
On Thu, Apr 11, 2013 at 03:11:32PM -0400, Jeff King wrote:
I always get a little nervous with sleeps in the test suite, as they are
indicative that we are trying to avoid some race
On Wed, Apr 24, 2013 at 2:57 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 4/23/2013 21:31, schrieb Junio C Hamano:
* fc/transport-helper-error-reporting (2013-04-17) 9 commits
(merged to 'next' on 2013-04-22 at 5ba6467)
+ transport-helper: update remote helper namespace
+
Commit caca2c1 (submodule: drop the top-level requirement) introduced a
relative_path helper but does not quote $curdir when it is stripped from
the front of a target path. In this particular case this should be safe
even with special characters because we only do this after checking that
$target
Phil Hord wrote:
Because I am in a git-rebase which has apparently failed, I would
expect 'git rebase --abort' would save me here. But it does not and
you have given me some unique instructions to try to recover. I
suppose rebase--abort cannot be made to recover in this case because
this is
Am 4/24/2013 10:04, schrieb Felipe Contreras:
On Wed, Apr 24, 2013 at 2:57 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 4/23/2013 21:31, schrieb Junio C Hamano:
* fc/transport-helper-error-reporting (2013-04-17) 9 commits
(merged to 'next' on 2013-04-22 at 5ba6467)
+ transport-helper:
It was 2013-04-24 śro 09:38, when Thomas Rast wrote:
Łukasz Stelmach l.stelm...@samsung.com writes:
Enable sending patches to NNTP servers (Usenet, Gmane).
I'm surprised Junio didn't mention this: your patch lacks the
Signed-off-by.
+if ($email_protocol eq 'nntp') {
+
On 04/23/2013 09:56 PM, Joel Jacobson wrote:
But stepping back a bit, I have a suspicion that your upstream
project _only_ cares about what you feed them (either by pushing
your work yourself to them, or telling them to pull from your
repository). There is no reason for you to be constantly
l.stelm...@samsung.com (Łukasz Stelmach) writes:
It was 2013-04-24 śro 09:38, when Thomas Rast wrote:
Łukasz Stelmach l.stelm...@samsung.com writes:
+ if ($email_protocol eq 'nntp') {
+ $header = Newsgroups: $to\n . $header;
+ } else {
+ $header = To: $to${ccline}\n
On OSX Tcl/Tk application windows are created behind all
the applications down the stack of windows. This is very
annoying, because once a gitk window appears, it's the
downmost window and switching to it is pain.
The patch is: if we are on OSX, use osascript to
bring the current Wish process
Sebastian Götte venit, vidit, dixit 24.04.2013 10:53:
On 04/23/2013 09:56 PM, Joel Jacobson wrote:
But stepping back a bit, I have a suspicion that your upstream
project _only_ cares about what you feed them (either by pushing
your work yourself to them, or telling them to pull from your
Junio C Hamano venit, vidit, dixit 23.04.2013 17:20:
Michael J Gruber g...@drmicha.warpmail.net writes:
Currently, git grep does not honor textconv settings by default.
Make it honor them by default just like git log --grep does.
git log --grep looks for strings in the log message which
Junio C Hamano venit, vidit, dixit 23.04.2013 17:16:
Michael J Gruber g...@drmicha.warpmail.net writes:
Currently, git grep does not honor any textconv filters. Demonstrate
this in the tests.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
t/t7008-grep-binary.sh | 23
Junio C Hamano venit, vidit, dixit 23.04.2013 17:14:
Michael J Gruber g...@drmicha.warpmail.net writes:
Subject: Re: [PATCHv2 2/7] show: obey --textconv for blobs
s/obey/honor/;
I missed that one, thanks.
Currently, diff and cat-file for blobs honor --textconv options
(with the former
Hi,
The 'git diff commit commit' form is perfectly fine: I can
understand that diff takes two commit^{tree}s to compare.
Unfortunately, it also shows off the examples 'git diff A..B' and 'git
diff A...B', where A..B and A...B do not correspond to the meaning
specified in gitrevisions.txt.
Today I botched a cutpaste and ran
git remote add git remote add origin url
only to notice, several commands later, that while it had succeeded,
it had in fact added a remote called 'git' with an url of 'remote'.
Some investigation yielded these fixes.
Thomas Rast (3):
remote: add a test
The 'git remote add' subcommand did not check for superfluous command
line arguments. Make it so.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
builtin/remote.c | 2 +-
t/t5505-remote.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/remote.c
This adds one test or comment for each subcommand of git-remote
according to its current documentation. All but 'set-branches' and
'update' are listed as taking only a fixed number of arguments; for
those we can write a test with one more (bogus) argument, and see if
the command notices that.
The 'git remote show' and 'prune' subcommands are documented as taking
only a single remote name argument, but that is not the case; they
will simply iterate the action over all remotes given. Update the
documentation and tests to match.
With the last user of the -f flag gone, we also remove the
Currently each submodule contains single .git file (instead of directory)
with only link to project's base repository, for example gitdir:
../../.git/modules/lib/neobundle.vim.
In git base repository we find .git/modules directory that contains bare
repositories of all submodules, for example
Hi
After some struggle I finally got apport work and got some
information. Please check whether it will be of any help. And you guys
are right, I have started to get the same crash again right now after
upgrading to latest git in Ubuntu.
Yes. Please do. The reason is a backtrace without symbols
On Wed, Apr 24, 2013 at 04:44:29PM +0200, Adam Stankiewicz wrote:
My proposal is to move default bare repository location from .git/modules
to .git directory inside submodule, like every normal git repo do.
That's the way it was in old versions of git. The git-file approach was
implemented so
On 04/23/2013 07:50 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Let me know if you would prefer that I re-roll.
Your fix-up cleanly applied to the result of applying the series up
to 16/33 and it was trivial to squash it in.
Please holler if what I push out
l.stelm...@samsung.com (Łukasz Stelmach) writes:
It was 2013-04-23 wto 17:02, when Junio C Hamano wrote:
Łukasz Stelmach l.stelm...@samsung.com writes:
Enable sending patches to NNTP servers (Usenet, Gmane).
---
The patch implements support for sending messages to groups on NNTP
John Keeping j...@keeping.me.uk writes:
Why not just replace the six-liner by this one-liner:
target=${target#$curdir/}
Simple enough ;-)
This seems to have arrived on next without this fix, so here's a patch
on top.
git-submodule.sh | 2 +-
1 file changed, 1
On Wed, Apr 24, 2013 at 09:21:38AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Why not just replace the six-liner by this one-liner:
target=${target#$curdir/}
Simple enough ;-)
This seems to have arrived on next without this fix, so here's a
Hi again,
So I decided that builtin/diff.c is hardcoded for the
commit..commit and commit...commit forms, and we can do
nothing about it unless we want to break compatibility (maybe a git
2.0 candidate?). The least we can do is document it properly in the
SYNOPSIS. I've done this in [4/5].
The
In DESCRIPTION, the 'commit..commit' form refers to the previous
form, namely the 'commit commit' form. However, bd52900
(Documentation: Describe git diff blob blob separately,
2012-12-18) broke this by inserting a form in between these two forms.
Fix this by reordering a form.
Signed-off-by:
It is imperative to specify options with the [options] template.
[--options] is inconsistent as well as misleading (as there are short
options which can be specified with a single -). Fix this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-diff.txt | 12
Clarify that -- is meant to disambiguate paths from the other
options.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-diff.txt | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-diff.txt
The DESCRIPTION refers to the 'commit..commit' and
'commit...commit' forms, but the SYNOPSIS does not list them at
all. Fix this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-diff.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
The SYNOPSIS lists the [--no-index] form as the last item, but the
DESCRIPTION lists it as a natural extension of the first form. Fix
this with a reordering. Also since the DESCRIPTION breaks up the
first form in the SYNOPSIS into two different forms (one without the
optional [commit], and the
Hi,
Ramkumar Ramachandra wrote:
A..B and A...B do not correspond to the meaning
specified in gitrevisions.txt. There's a note in the documentation
saying this, but I'm very unhappy.
What would it mean for A..B to be treated as a revision range?
Suppose I do a revision
Ramkumar Ramachandra wrote:
In DESCRIPTION, the 'commit..commit' form refers to the previous
form, namely the 'commit commit' form. However, bd52900
Good catch.
[...]
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -11,8 +11,8 @@ SYNOPSIS
[verse]
'git diff'
Ramkumar Ramachandra wrote:
It is imperative to specify options with the [options] template.
Why is it imperative?
Anyway, this looks like a good change. With that sentence removed
or some other clarification,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list:
Jonathan Nieder wrote:
Why is it imperative?
Sorry about the thinko; s/imperative/idiomatic/
--
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
Ramkumar Ramachandra artag...@gmail.com writes:
What should we do to improve the
situation?
The first thing to do is to eradicate diff A..B from the
documentation, and a dozen or more lines in your complaint will go
away with that single change.
As you know, diff is about two endpoints, and
Junio C Hamano wrote:
The first thing to do is to eradicate diff A..B from the
documentation, and a dozen or more lines in your complaint will go
away with that single change.
As you know, diff is about two endpoints, and A..B is not a way to
specify two endpoints, and not erroring it out
The 'commit..commit' and 'commit...commit' forms are confusing
as they are reminiscent of the corresponding forms in the SPECIFYING
RANGES section of revisions.txt. We can remove the
'commit..commit' form now (hence discouraging its use), since it
is exactly equivalent to the clearer 'commit
Barbu Paul - Gheorghe barbu.paul.gheor...@gmail.com writes:
Since SSL provides no protection if the certificates aren't verified it's
better not to include sslverify=false in the examples.
Also in the post 1.8.2.1 era git is able to properly verify the validity of a
certificate as well it's
Michael J Gruber g...@drmicha.warpmail.net writes:
+test_expect_failure 'grep does not honor textconv' '
+ echo a:binaryQfile expect
+ git grep Qfile actual
This should pass --textconv to git grep.
But git grep does not know that option yet, so the test would fail for
the wrong
On 04/24/2013 11:51 AM, Michael J Gruber wrote:
Sebastian Götte venit, vidit, dixit 24.04.2013 10:53:
What could be nice would be a
config option that makes git push warn/abort in case I try to push an
unsigned head commit to a repo where I want to
Michael J Gruber g...@drmicha.warpmail.net writes:
Junio C Hamano venit, vidit, dixit 23.04.2013 17:14:
Michael J Gruber g...@drmicha.warpmail.net writes:
Subject: Re: [PATCHv2 2/7] show: obey --textconv for blobs
s/obey/honor/;
I missed that one, thanks.
Currently, diff and cat-file
Michael J Gruber g...@drmicha.warpmail.net writes:
My point is that we apply textconv on log diff greps already, so why
should't we on content greps?
I think you are going in circles. If you start from textconv is
about mangling blob contents, then it would look natural to you
that show blob,
Here is a patch that creates a daemon that tracks file
state with inotify, writes it out to a file upon request,
and changes most of the calls to stat to use said cache.
It has bugs, but I figured it would be smarter to see
if the approach was acceptable at all before spending the
time to root
Jonathan Nieder jrnie...@gmail.com writes:
What would it mean for A..B to be treated as a revision range?
Nonsense is what it means ;-)
Suppose I do a revision walk and come up with the commits x, y,
and z. What is the resulting diff?
The common syntax is just a mnemonic: in the same
Phil Hord phil.h...@gmail.com writes:
Because I am in a git-rebase which has apparently failed, I would
expect 'git rebase --abort' would save me here.
More generally, if I git rebase --abort in the middle of a rebase (not
necessarily at the end), I'd expect the stash to be restored. Right
Ramkumar Ramachandra artag...@gmail.com writes:
What are your thoughts on inventing a new syntax A~B = $(git
merge-base A B) B which can be used by both range commands like log
and non-range commands like diff ? (In other words, why shouldn't log
be able to do this?).
The idea for a new
Junio C Hamano wrote:
And it does not match git log origin...HEAD
Exactly my problem. Inconsistency.
--
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
Ramkumar Ramachandra artag...@gmail.com writes:
Jonathan Nieder wrote:
Why is it imperative?
Sorry about the thinko; s/imperative/idiomatic/
Yeah, I think this step looks reasonable.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Ramkumar Ramachandra artag...@gmail.com writes:
-'git diff' [options] [--] [path...]::
+'git diff' [options] [[--] [path...]]::
You can say
git diff A B -- without any path
git diff A B pathspec without any double-dashes
git diff -- pathspec
and all three of them are expressed by
Junio C Hamano wrote:
While the update might be logically more correct, it looks to me
that the only end-user visibile effect of it is to make the end
result harder to read.
Hm, I thought it improves readability. I'm trying to say that -- is
used to separate [path...] from [everything else].
Ramkumar Ramachandra artag...@gmail.com writes:
The SYNOPSIS lists the [--no-index] form as the last item, but the
DESCRIPTION lists it as a natural extension of the first form.
Perhaps either the description or your reading is wrong.
The --no-index mode was a hack to allow git diff goodies
Ramkumar Ramachandra artag...@gmail.com writes:
The 'commit..commit' and 'commit...commit' forms are confusing
as they are reminiscent of the corresponding forms in the SPECIFYING
RANGES section of revisions.txt. We can remove the
'commit..commit' form now (hence discouraging its use), since
Junio C Hamano wrote:
The --no-index mode was a hack to allow git diff goodies to be
used outside the context of git, and a proper execution of it
should have been to send patches to GNU or BSD diff maintainers, not
to add the --no-index option that is unrelated to git to our
code.
Yeah, I
On Wed, Apr 24, 2013 at 11:59 PM, Junio C Hamano gits...@pobox.com wrote:
I agree with the end result not to list .. form in the SYNOPSIS, but
you shouldn't have added it in the first place in the earlier patch.
I'm expecting to re-roll anyway. I just wanted to show it to you now.
I do not
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
-'git diff' [options] [--] [path...]::
+'git diff' [options] [[--] [path...]]::
While the update might be logically more correct, it looks to me
that the only end-user visibile effect of it is to make the end
result
On Wed, Apr 24, 2013 at 11:41 PM, Junio C Hamano gits...@pobox.com wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
What are your thoughts on inventing a new syntax A~B = $(git
merge-base A B) B which can be used by both range commands like log
and non-range commands like diff ? (In
Junio C Hamano wrote:
The same logic would apply to this semi-nonsense rewrite, no?
git diff [[options] [--]] [path...]
Everything else comes before -- (if exists) that separates it from
the list of pathspecs.
Yeah, except it's sometimes
[[options] [revision range] [--]]
Matthieu Moy matthieu@grenoble-inp.fr writes:
Grepping through the binary, on the other hand, can very well make
sense, like:
$ git grep foo
file.txt: some instance of foo
binary file bar.bin matches
Yes,
I am moderately negative on making it the default, mostly because it
goes
Ramkumar Ramachandra wrote:
Hm, I thought it improves readability. I'm trying to say that -- is
used to separate [path...] from [everything else].
I agree with the goal, but I don't think this change achieves it.
Maybe adding gitcli(7) to the SEE ALSO section would work?
Jonathan
--
To
Ramkumar Ramachandra wrote:
I'm also considering making the first
argument optional (just git log ~rebase.autostash), and defaulting to
mean [nearest fork point].
Actually both can be optional. In A~B, A defaults to [nearest fork
point] and B defaults to HEAD.
git log ~
Isn't it
Ramkumar Ramachandra wrote:
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -13,6 +13,8 @@ SYNOPSIS
'git diff' [options] --cached [commit] [[--] [path...]]
'git diff' [options] blob blob
'git diff' [options] commit commit [[--] [path...]]
+'git diff' [options]
Ramkumar Ramachandra wrote:
The form is a special case of
the first form where the number of paths are limited to two. Besides,
isn't that how the DESCRIPTION section explains it now?
Sort of. It's a completely different form, but when --no-index is
Jonathan Nieder wrote:
Maybe it would make sense to move towards eliminating the implicit
--no-index for paths outside the repository trick. I use git diff
--no-index all the time, but I always spell it out to be careful.
Huh? Why do you want to endure the pain of spelling it out, when your
Am 24.04.2013 18:28, schrieb John Keeping:
On Wed, Apr 24, 2013 at 09:21:38AM -0700, Junio C Hamano wrote:
J6t meant a patch to remove the entire case...esac and replace it
with a single liner (target=${target#$curdir/}).
Ah, I missed the six-liner part. But that doesn't work because we
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
Maybe it would make sense to move towards eliminating the implicit
--no-index for paths outside the repository trick. I use git diff
--no-index all the time, but I always spell it out to be careful.
Huh? Why do you want to endure the pain
Jonathan Nieder wrote:
Oh please no.
If I understand this correctly, you are horrified by this?
https://github.com/artagnon/dotfiles/blob/master/.gitconfig#L30
By the way, my zsh aliases git to g.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
The same logic would apply to this semi-nonsense rewrite, no?
git diff [[options] [--]] [path...]
Everything else comes before -- (if exists) that separates it from
the list of pathspecs.
Yeah, except it's
Junio C Hamano wrote:
And it does not match git log origin...HEAD which gives both sides
of the symmetric difference of the history. To match it, you have
to say git log --right-only origin...HEAD or something.
I tend to use --left-right. All I meant is that with both diff and
log, ... is a
Ramkumar Ramachandra artag...@gmail.com writes:
Ramkumar Ramachandra wrote:
I'm also considering making the first
argument optional (just git log ~rebase.autostash), and defaulting to
mean [nearest fork point].
Actually both can be optional. In A~B, A defaults to [nearest fork
point] and
Junio C Hamano wrote:
You are missing the entire point.
Yeah, okay: I'll drop this patch. I was just saying; I don't feel
strongly about it at all.
--
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
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
Oh please no.
If I understand this correctly, you are horrified by this?
https://github.com/artagnon/dotfiles/blob/master/.gitconfig#L30
Nope, that looks like a useful way to save typing, and git help
helpfully expands any of your custom
Junio C Hamano wrote:
You will stay in my killlist for the coming few days ;-).
Now, now. What is your objection, objectively?
--
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
Jonathan Nieder wrote:
Because typing paths does not make my intent perfectly clear.
I'm not able to understand this. Doesn't your prompt tell you which
directory you're in, and if you're in a git repository? When you type
out paths, you know what is inside and what is outside your
repository.
Sebastian Götte ja...@physik.tu-berlin.de writes:
On 04/24/2013 11:51 AM, Michael J Gruber wrote:
Sebastian Götte venit, vidit, dixit 24.04.2013 10:53:
What could be nice would be a
config option that makes git push warn/abort in case I try to push an
Jonathan Nieder jrnie...@gmail.com writes:
And it does not match git log origin...HEAD which gives both sides
of the symmetric difference of the history. To match it, you have
to say git log --right-only origin...HEAD or something.
I tend to use --left-right. All I meant is that with both
Junio C Hamano wrote:
Yeah, I am not strongly opposed to have something like that, and
having a shorter (but not a single letter) option name might make it
more attractive than A...B at least to new users.
I'm not married to the single character or tilde. What I'm saying is
that we should
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
Because typing paths does not make my intent perfectly clear.
I'm not able to understand this. Doesn't your prompt tell you which
directory you're in, and if you're in a git repository? When you type
out paths, you know what is inside and
Ramkumar Ramachandra artag...@gmail.com writes:
Ramkumar Ramachandra wrote:
I'm also considering making the first
argument optional (just git log ~rebase.autostash), and defaulting to
mean [nearest fork point].
Actually both can be optional. In A~B, A defaults to [nearest fork
point] and
Jonathan Nieder wrote:
* hard to document
[...]
I completely disagree, but we don't have to agree: make it a
configuration variable. Even if it's turned to never by default, I
don't mind having one extra line in my .gitconfig. But you went all
Oh please no when I brought it up. I thought
Remove one of two consecutive, identical blocks for git commit -c.
Signed-off-by: Mårten Kongstad marten.kongs...@gmail.com
---
contrib/completion/git-completion.bash |7 ---
1 file changed, 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash
Ramkumar Ramachandra wrote:
I completely disagree, but we don't have to agree: make it a
configuration variable.
I thought we had discussed before how every configuration variable
costs quite a lot in terms of Git's teachability.
What would that configuration variable even mean? Set this to
Thomas Rast wrote:
* Looking for the nearest fork point is expensive and subject to change
by simply fetching. I hope you meant ... and exclude its upstream,
i.e., A defaults to @{u}, which might be at least somewhat useful.
I'm not proposing anything different from :/ in this aspect.
*
Ramkumar Ramachandra artag...@gmail.com writes:
Sorry I wasn't clear. A~B = $(git merge-base A B) B to diff and $(git
merge-base A B)..B to log.
Basically, I want to be able to do git log master~rebase.autostash
(without having to rebase).
How is it different from git log
On Wed, Apr 24, 2013 at 3:00 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Ramkumar Ramachandra wrote:
I'm also considering making the first
argument optional (just git log ~rebase.autostash), and defaulting to
mean [nearest fork point].
Actually both can be optional. In A~B, A
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
You will stay in my killlist for the coming few days ;-).
Now, now. What is your objection, objectively?
I do not think any further explanation is necessary.
My Git time is more useful to the Git development community
Paul Walmsley pjwh...@gmail.com wrote:
Hi,
Please forgive the direct approach, but I submitted a git-svn patch to the
git list which sank without any comment. As major contributors to git-svn I
would like to solicit your feedback on it. The patch is so that git svn
clone supports
On Thu, Apr 25, 2013 at 3:20 AM, Robert Zeh robert.allan@gmail.com wrote:
Here is a patch that creates a daemon that tracks file
state with inotify, writes it out to a file upon request,
and changes most of the calls to stat to use said cache.
It has bugs, but I figured it would be
Thomas Rast tr...@inf.ethz.ch writes:
+test_extra_arg () {
+ expect=success
+ if test z$1 = z-f; then
+ expect=failure
+ shift
+ fi
+ test_expect_$expect extra args: $*
+ test_must_fail git remote $* bogus_extra_arg 2actual
+
Junio C Hamano wrote:
My Git time is more useful to the Git development community than
educating somebody with demonstrated lack of design taste by calling
the log ~ that has an irregular default beautiful.
Why are you caught up in the character and the defaults (I just put
down the first
The SVN::Fetcher module is now able to filter for inclusion as well
as exclusion (as used by --ignore-path). Also added tests, documentation
changes and git completion script.
If you have an SVN repository with many top level directories and you
only want a git-svn clone of some of them then
1 - 100 of 115 matches
Mail list logo
