It was <2013-04-24 śro 18:17>, when Junio C Hamano wrote:
> l.stelm...@samsung.com (Łukasz Stelmach) writes:
>
>> It was <2013-04-23 wto 17:02>, when Junio C Hamano wrote:
>>> Łukasz Stelmach writes:
>>>
Enable sending patches to NNTP servers (Usenet, Gmane).
---
The patch impl
Ramkumar Ramachandra writes:
> Ramkumar Ramachandra wrote:
>> Ofcourse, I now see that this is probably useless, and .. fits my bill.
>
> Would you find it potentially useful?
I dunno. The description you gave was insufficient for me to answer
that question.
The part of your message that outli
From: Johannes Sixt
Bash on Windows does not implement process substitution.
Signed-off-by: Johannes Sixt
---
Am 4/24/2013 10:30, schrieb Johannes Sixt:
> Am 4/24/2013 10:04, schrieb Felipe Contreras:
>> On Wed, Apr 24, 2013 at 2:57 AM, Johannes Sixt wrote:
>>> Am 4/23/2013 21:31, schrieb Juni
Ramkumar Ramachandra wrote:
> 3. Even though I lashed out strongly against 'git diff A..B' because
> of inconsistency, I can't say that it's not useful (omit specifying
> HEAD on one side). If we were to start over today, I would argue that
> 'git diff A ^B' and 'git diff B ^A' be handled as speci
Junio C Hamano wrote:
> It should be more like this [*1*]:
>
> 'git log' [] [] [--] [...]
Agreed. The backslash is unnecessary (I suspect it's something
carried over from earlier versions of asciidoc requiring this
escaping).
> It may be better to split the item into two, keep the curren
Hi,
So, I have three serious itches that would be nice to address:
1. git reset --hard HEAD~1/ git show HEAD~1 is a very common idiom
that's unnecessarily cumbersome to type out. We can make the
part of ~ optional without being ambiguous: you might argue
that ~ normally refers to a /home/, but
Ramkumar Ramachandra wrote:
> We might still want it. I mean what are we losing?
Actually, let's just look at extending the rev specs we currently
have. I'll gather up a list of real itches and post it to the list.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
From: Torstein Hegge
Subject: Re: [PATCH] bisect: Store first bad commit as comment in log file
Date: Tue, 23 Apr 2013 00:20:58 +0200
> On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:
>> Torstein Hegge writes:
>>
>> > I took another look at this. I wasn't able to come up with anyt
9 ปี กรือเซะ 28 เมษายน 2556
ย้อนกลับไปดูเหตุการณ์ เมื่อวันที่ 28 เมษายน 2547 เกิดความ
รุนแรงขึ้นที่จังหวัดชายแดนภาคใต้ถึง 11 จุด ในวันเดียวกัน แต่เหตุการณ์ที่
ต้องจดจำกันไปอีกนานก็คือ กรณีเหตุการณ์ที่มัสยิดกรือเซะ จังหวัดปัตตานี
กลุ่มผู้ก่อความไม่สงบจำนวนหนึ่งได้บุกเข้าโจมตีจุดตรวจของตำร
Junio C Hamano writes:
>> So, given all that, revised patch below:
I tried to squeeze the minimum test I sent $gmane/220919 to the test
suite. I think the "do not use --parents option for this test"
switch needs to be cleaned up a bit more, but it fails without your
patch and does pass with you
Ramkumar Ramachandra writes:
> In its current form, the note talks about separating options from
> "branch names" and "refnames" in the same sentence. This is entirely
> inaccurate, as need not be a set of branch names or
> ref names. Rewrite it to use the word "revision range", to be
> consis
Ramkumar Ramachandra wrote:
> Ofcourse, I now see that this is probably useless, and .. fits my bill.
Would you find it potentially useful? You do a lot of merging
back-and-fourth juggling feature branches, pu, next, master.
> When packaged with a good default for LHS (which .. currently doesn't
This was caused by a mechanical mismerge at d931e2fb252e (Merge
branch 'mp/complete-paths', 2013-02-08), it seems. The side branch
fea16b47 wanted to add this block, of course, but the same fix was
done independently in 685397585 already.
Thanks for catching it.
--
To unsubscribe from this list:
Junio C Hamano wrote:
> How is it different from "git log master..rebase.autostash"?
>
> git log A..B
>
> is already a perfectly fine way to spell your "A~B", which is
>
> git log B --not $(git merge-base --all A B)
>
> when written in longhand [*1*], no?
>
> So I do not think your A~B help
Thomas Rast writes:
> Łukasz Stelmach writes:
>
>> Enable sending patches to NNTP servers (Usenet, Gmane).
>
> I'm surprised Junio didn't mention this: your patch lacks the
> Signed-off-by.
Heh, that was because I took the patch as an early preview and not a
final submission. It came without d
Kevin Bracey writes:
> If simplify_history is set, and we do want ancestry, then it doesn't
> matter about the TREESAME definition because it shows all merges,
> regardless of the TREESAME flag. Thus adding "--parents" to the above
> command means it can find it, but only because it drags _every_
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 using
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 firs
Thomas Rast 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 2>actual &&
> +
On Thu, Apr 25, 2013 at 3:20 AM, Robert Zeh 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 smarter to see
> if the appr
Paul Walmsley 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 '--include-path' as a com
Ramkumar Ramachandra 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 than
educating s
On Wed, Apr 24, 2013 at 3:00 PM, Ramkumar Ramachandra
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 defaults to [near
Ramkumar Ramachandra 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 master..rebase.autostash"?
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> Isn't it obviously incredibly useful? I'm working on a topic branch I
>> need to send out to git.git, and I want see how my WIP looks: should I
>> have to rebase on master just to see this?
>
> Nope. I just do "git log master..topic".
Why
Ramkumar Ramachandra wrote:
> Isn't it obviously incredibly useful? I'm working on a topic branch I
> need to send out to git.git, and I want see how my WIP looks: should I
> have to rebase on master just to see this?
Nope. I just do "git log master..topic".
--
To unsubscribe from this list: se
Jonathan Nieder wrote:
> What would that configuration variable even mean? "Set this to make
> other people's scripts work when they assume --no-index won't be
> triggered automatically"?
No. "Set this for interactive use".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
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 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 t
Remove one of two consecutive, identical blocks for "git commit -c".
Signed-off-by: Mårten Kongstad
---
contrib/completion/git-completion.bash |7 ---
1 file changed, 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 93eba
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 thoug
Ramkumar Ramachandra 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 B default
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 insi
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 m
Jonathan Nieder 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 diff an
Sebastian Götte 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
>>> unsigned he
Hi Otto
> I don't have skills to review the patch, but I just wanted to thank
> you for working on the JavaScript parser
Thank you :-)
> I've been hoping that somebody would fix it!
With fixing you mean getting it into the next release? Or do you
know of any other problems with it? I'm currentl
Ramkumar Ramachandra wrote:
> [...]
Any updates on this?
--
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
Hey all!
When I'm using git-svn, I'm always a bit dismayed that the dates in the git-svn
commits are not copied from the original commits. They instead just contain the
date of the dcommit. Note that I'm talking about the commits in my git repo
here, not the ones in subversion - I know that tho
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.
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 http://vger.kernel.org/m
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 cu
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 htt
Ramkumar Ramachandra 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 B default
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, ..
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> The same logic would apply to this semi-nonsense rewrite, no?
>>
>> git diff [[options] [--]] [...]
>>
>> Everything else comes before "--" (if exists) that separates it from
>> the list of pathspecs.
>
> Yeah, except it's sometimes
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 majo
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 end
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 beca
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
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 i
Ramkumar Ramachandra wrote:
> --- a/Documentation/git-diff.txt
> +++ b/Documentation/git-diff.txt
> @@ -13,6 +13,8 @@ SYNOPSIS
> 'git diff' [options] --cached [] [[--] [...]]
> 'git diff' [options]
> 'git diff' [options] [[--] [...]]
> +'git diff' [options] .. [[--] [...]]
> +'git diff' [op
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 beaut
Ramkumar Ramachandra wrote:
> Hm, I thought it improves readability. I'm trying to say that -- is
> used to separate [...] 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 unsubscr
Matthieu Moy 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 against established expectat
Junio C Hamano wrote:
> The same logic would apply to this semi-nonsense rewrite, no?
>
> git diff [[options] [--]] [...]
>
> Everything else comes before "--" (if exists) that separates it from
> the list of pathspecs.
Yeah, except it's sometimes
[[options] [revision range] [--]] [..
On Wed, Apr 24, 2013 at 11:41 PM, Junio C Hamano wrote:
> Ramkumar Ramachandra 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
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> -'git diff' [options] [--] [...]::
>>> +'git diff' [options] [[--] [...]]::
>>
>> 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.
On Wed, Apr 24, 2013 at 11:59 PM, Junio C Hamano 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 think it is a ba
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
> co
Ramkumar Ramachandra writes:
> The '..' and '...' forms are confusing
> as they are reminiscent of the corresponding forms in the "SPECIFYING
> RANGES" section of revisions.txt. We can remove the
> '..' form now (hence discouraging its use), since it
> is exactly equivalent to the clearer ' ' fo
Ramkumar Ramachandra 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 to be
used out
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 [...] from [everything else].
--
Ramkumar Ramachandra writes:
> -'git diff' [options] [--] [...]::
> +'git diff' [options] [[--] [...]]::
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 versions before or
Ramkumar Ramachandra 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 majord...@vger.kernel.org
Mor
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 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 syntax to denote a
Junio C Hamano writes:
> But diff..textconv is to mangle blob contents in preparation
> for comparing with another.
and also in preparation for "blame".
In both cases (diff and blame), we're preparing to show the file content
to the user, and showing the binary makes no sense.
Grepping through
Phil Hord 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 now,
if I read co
Jonathan Nieder 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 situations as I
>
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 th
Michael J Gruber 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 ", "diff A B", and "grep
Michael J Gruber writes:
> Junio C Hamano venit, vidit, dixit 23.04.2013 17:14:
>> Michael J Gruber 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"
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 wan
Michael J Gruber 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 r
Barbu Paul - Gheorghe 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 origin.
>
> Signed-off-by:
The '..' and '...' forms are confusing
as they are reminiscent of the corresponding forms in the "SPECIFYING
RANGES" section of revisions.txt. We can remove the
'..' form now (hence discouraging its use), since it
is exactly equivalent to the clearer ' ' form.
However, we must keep the '...' form
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
Ramkumar Ramachandra 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 A..B is not a wa
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 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
--
To unsubscribe from this list: send the line "uns
Ramkumar Ramachandra wrote:
> In DESCRIPTION, the '..' form refers to "the previous
> form", namely the ' ' form. However, bd52900
Good catch.
[...]
> --- a/Documentation/git-diff.txt
> +++ b/Documentation/git-diff.txt
> @@ -11,8 +11,8 @@ SYNOPSIS
> [verse]
> 'git diff' [options] [] [--] [...
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
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 [], and the other wi
Clarify that "--" is meant to disambiguate paths from the other
options.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-diff.txt | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 47a
The DESCRIPTION refers to the '..' and
'...' forms, but the SYNOPSIS does not list them at
all. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-diff.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index a0fdfc
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
---
Documentation/git-diff.txt | 12 ++--
1 file change
In DESCRIPTION, the '..' form refers to "the previous
form", namely the ' ' form. However, bd52900
(Documentation: Describe "git diff " separately,
2012-12-18) broke this by inserting a form in between these two forms.
Fix this by reordering a form.
Signed-off-by: Ramkumar Ramachandra
---
Docu
Hi again,
So I decided that builtin/diff.c is hardcoded for the
.. and ... 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 other patches are just g
On Wed, Apr 24, 2013 at 09:21:38AM -0700, Junio C Hamano wrote:
> John Keeping 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 her
John Keeping 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 insertio
l.stelm...@samsung.com (Łukasz Stelmach) writes:
> It was <2013-04-23 wto 17:02>, when Junio C Hamano wrote:
>> Łukasz Stelmach writes:
>>
>>> Enable sending patches to NNTP servers (Usenet, Gmane).
>>> ---
>>>
>>> The patch implements support for sending messages to groups on NNTP
>>> serviers.
On 04/23/2013 07:50 PM, Junio C Hamano wrote:
> Michael Haggerty 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 on 'pu' in 8
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
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
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 .
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
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
The 'git remote add' subcommand did not check for superfluous command
line arguments. Make it so.
Signed-off-by: Thomas Rast
---
builtin/remote.c | 2 +-
t/t5505-remote.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 937484d..
Today I botched a cut&paste and ran
git remote add git remote add origin
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 for
1 - 100 of 123 matches
Mail list logo
