On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
> Hi,
>
> On Thu, Sep 26, 2013 at 10:21 PM, John Keeping wrote:
> > On Thu, Sep 26, 2013 at 06:35:57PM +0200, Francis Moreau wrote:
> >> I'm trying to use "git log --cherry ..." in order to display new, kept
> >> and removed commits
I've just upgraded to Debian testing (jessie), and with that I got a
brand new (for me) git version:
$ git --version
git version 1.8.4.rc3
Some of my repos I use an ssh tunnel to reach, so when I want to reach a
repo forwarded to local port 2223, using the ssh protocol, the following
used
Signed-off-by: Matthieu Moy
---
Jakub Narebski writes:
> Perhaps "to use instead ..." would be easier to understand than
> proposed "to use ..., instead." (with "..." being one line long).
Actually, I had the version below staged, but forgot to "commit
--amend" before sending. Should be clear e
On Fri, Sep 27, 2013 at 10:11 AM, John Keeping wrote:
> On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
>> Hi,
>>
>> On Thu, Sep 26, 2013 at 10:21 PM, John Keeping wrote:
>> > On Thu, Sep 26, 2013 at 06:35:57PM +0200, Francis Moreau wrote:
>> >> I'm trying to use "git log --cherry
On Fri, Sep 27, 2013 at 3:07 PM, Morten Stenshorne wrote:
> I've just upgraded to Debian testing (jessie), and with that I got a
> brand new (for me) git version:
>
> $ git --version
> git version 1.8.4.rc3
>
> Some of my repos I use an ssh tunnel to reach, so when I want to reach a
> repo
On Thu, Sep 26, 2013 at 10:10 PM, Anders Kaseorg wrote:
> ‘eval "$@"’ created an extra layer of shell interpretation, which was
> probably not expected by a user who passed multiple arguments to git
> submodule foreach:
>
> $ git grep "'"
> [searches for single quotes]
> $ git submodule foreach gi
Am 27.09.2013 10:07, schrieb Morten Stenshorne:
> I've just upgraded to Debian testing (jessie), and with that I got a
> brand new (for me) git version:
>
> $ git --version
> git version 1.8.4.rc3
>
> Some of my repos I use an ssh tunnel to reach, so when I want to reach a
> repo forwarde
On Fri, Sep 27, 2013 at 10:28:05AM +0200, Francis Moreau wrote:
> On Fri, Sep 27, 2013 at 10:11 AM, John Keeping wrote:
> > On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
> >> Hi,
> >>
> >> On Thu, Sep 26, 2013 at 10:21 PM, John Keeping wrote:
> >> > On Thu, Sep 26, 2013 at 06:35
On Fri, Sep 27, 2013 at 11:14 AM, John Keeping wrote:
> On Fri, Sep 27, 2013 at 10:28:05AM +0200, Francis Moreau wrote:
>> On Fri, Sep 27, 2013 at 10:11 AM, John Keeping wrote:
>> > On Fri, Sep 27, 2013 at 07:09:03AM +0200, Francis Moreau wrote:
>> >> Hi,
>> >>
>> >> On Thu, Sep 26, 2013 at 10:21
‘eval "$@"’ created an extra layer of shell interpretation, which was
probably not expected by a user who passed multiple arguments to git
submodule foreach:
$ git grep "'"
[searches for single quotes]
$ git submodule foreach git grep "'"
Entering '[submodule]'
/usr/lib/git-core/git-submodule: 1:
On Fri, Sep 27, 2013 at 12:23 PM, Anders Kaseorg wrote:
> ‘eval "$@"’ created an extra layer of shell interpretation, which was
> probably not expected by a user who passed multiple arguments to git
> submodule foreach:
>
> $ git grep "'"
> [searches for single quotes]
> $ git submodule foreach gi
Hi,
I juggle between several hot branches, and an alphabetical listing
from 'git branch' doesn't cut it for me. I've chosen to enhance
for-each-ref so that I get output like (with color):
$ git hot
um-build>
perf-manifest=
* master=
sparse=
ia32-asm-cleanup>
menuconfig-jk<
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend its format with
%(HEAD) for the same effect.
Now you can use the following format in for-each-ref:
%C(red)%(HEAD)%C(reset) %(refname:short)
to display a red asterisk next t
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%C(green)%(refname:short)%C(reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4 +++-
builtin/for-each-ref.c | 23 +++
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%C(green)%(refname:short)%C(reset)%(upstream:trackshort)
On Fri, Sep 27, 2013 at 8:10 AM, Ramkumar Ramachandra
wrote:
> Enhance 'git for-each-ref' with color formatting options. You can now
> use the following format in for-each-ref:
>
> %C(green)%(refname:short)%C(reset)
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> Documentation/git-for-each-re
commit 6000334 (clone: allow cloning local paths with colons in them -
2013-05-04) is added to make it possible to specify a path that has
colons in it without file://, e.g. ../foo:bar/somewhere. But the check
is a bit loose.
Consider the url '[foo]:bar', the '[]' unwrapping code will turn the
str
On Fri, Sep 27, 2013 at 3:55 PM, Stefan Näwe
wrote:
>> [remote "exp"]
>> url = [localhost:2223]:blink.git
>> fetch = +refs/heads/*:refs/remotes/exp/*
>>
>> However, now I get this message:
>>
>> $ git fetch exp
>> fatal: ':blink.git' does not appear to be a git
On Fri, Sep 27, 2013 at 8:10 AM, Ramkumar Ramachandra
wrote:
> Introduce %(upstream:track) to display "[ahead M, behind N]" and
> %(upstream:trackshort) to display "=", ">", "<", or "<>"
> appropriately (inspired by contrib/completion/git-prompt.sh).
>
> Now you can use the following format in for
Am 9/27/2013 14:10, schrieb Ramkumar Ramachandra:
> + else if (!strcmp(formatp, "track") &&
> + !prefixcmp(name, "upstream")) {
> + char buf[40];
> +
> + if (!upstream_present)
> +
Phil Hord wrote:
>> --- a/builtin/for-each-ref.c
>> +++ b/builtin/for-each-ref.c
>> @@ -631,6 +631,7 @@ static void populate_value(struct refinfo *ref)
>> int eaten, i;
>> unsigned long size;
>> const unsigned char *tagged;
>> + int upstream_present = 0;
>
> This flag
On Fri, Sep 27, 2013 at 4:07 AM, Morten Stenshorne wrote:
> If I don't go via the ssh tunnel (I finally have some VPN stuff these
> days, so I don't really need the tunnel thing anymore, but that's going
> to be a lot of remotes to update, so I'd prefer it just worked like it
> used to):
>
> -
Johannes Sixt wrote:
>> + else if (!num_ours) {
>> + sprintf(buf, "[behind %d]",
>> num_theirs);
>> + v->s = xstrdup(buf);
>> + } else if (!num_theirs) {
>> +
Phil Hord writes:
> On Fri, Sep 27, 2013 at 4:07 AM, Morten Stenshorne wrote:
>> If I don't go via the ssh tunnel (I finally have some VPN stuff these
>> days, so I don't really need the tunnel thing anymore, but that's going
>> to be a lot of remotes to update, so I'd prefer it just worked like
- Original Message -
From: "Ramkumar Ramachandra"
Sent: Friday, September 27, 2013 1:10 PM
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).
Now you can
Philip Oakley wrote:
> "=" and "<>" I can easily understand (binary choice), but ">" and "<" will
> need to be clear which way they indicate in terms of matching
> the "[ahead N]" and "[behind M]" options.
The ">" corresponds to ahead, while "<" is behind. You'll get used to
it pretty quickly :)
From: "Ramkumar Ramachandra"
Philip Oakley wrote:
"=" and "<>" I can easily understand (binary choice), but ">" and "<"
will
need to be clear which way they indicate in terms of matching
the "[ahead N]" and "[behind M]" options.
The ">" corresponds to ahead, while "<" is behind. You'll get
From: "Jonathan Nieder"
What's cooking in git.git (Sep 2013, #08; Wed, 25)
* po/dot-url (2013-09-13) 2 commits
(merged to 'next' on 2013-09-20 at 6a12786)
+ config doc: update dot-repository notes
+ doc: command line interface (cli) dot-repository dwimmery
Explain how '.' can be used to re
Philip Oakley wrote:
> Jonathan,
> Did you spot my recent
> http://thread.gmane.org/gmane.comp.version-control.git/235127?
Will take a look. 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 htt
The latest maintenance release Git v1.8.4.1 is now available.
The release tarballs are found at:
http://alioth.debian.org/~jrnieder-guest/git/
and their SHA-1 checksums are:
49004a8dfcbb7c0848147737d9877fd7313a42ec git-1.8.4.1.tar.gz
1f0e5c5934ec333b5630a8c93a0fb0b1895dfcb8 git-htmldocs-1
On Fri, Sep 27, 2013 at 08:48:13PM +0700, Nguyen Thai Ngoc Duy wrote:
> ---
> I wanted to add a test then realized there were no ssh tests in the
> test suite. So laziness won :p
There is one in t5602, but it's not very reusable. How about squashing
in the patch below, which does a basic ssh-wo
On 13-09-27 02:52 PM, Jonathan Nieder wrote:
> The latest maintenance release Git v1.8.4.1 is now available.
>
> The release tarballs are found at:
>
> http://alioth.debian.org/~jrnieder-guest/git/
>
> and their SHA-1 checksums are:
>
> 49004a8dfcbb7c0848147737d9877fd7313a42ec git-1.8.4.1.
Marc Branchaud wrote:
> On 13-09-27 02:52 PM, Jonathan Nieder wrote:
>> The following public repositories all have a copy of the v1.8.4.1
>> tag and the maint branch that the tag points at:
>>
>> url = https://googlers.googlesource.com/jrn/git
>> url = git://repo.or.cz/git/jrn.git
>> url = g
Nguyễn Thái Ngọc Duy wrote:
> commit 6000334 (clone: allow cloning local paths with colons in them -
> 2013-05-04) is added to make it possible to specify a path that has
> colons in it without file://, e.g. ../foo:bar/somewhere. But the check
> is a bit loose.
[...]
> Make sure we only check so w
Johannes Sixt wrote:
> Am 9/27/2013 14:10, schrieb Ramkumar Ramachandra:
>> +v->s = xstrdup(buf);
>> +}
>
> These strdupped strings are leaked, right?
The convention seems to be that each refinfo owns its atom_value,
which owns its s
On Tue, Sep 24, 2013 at 10:56:48PM +0300, Paul Sokolovsky wrote:
> Hello,
>
> git rebase is confused about commits like
> https://github.com/pfalcon/civetweb/commit/ce8493837bf7676c6d824cdcb1d5e3a7ed476fe1
> - it stops, telling user to just run rebase --continue. I remember like
> few years ago re
Hello Brian,
On Fri, 27 Sep 2013 22:28:07 +
"brian m. carlson" wrote:
> On Tue, Sep 24, 2013 at 10:56:48PM +0300, Paul Sokolovsky wrote:
> > Hello,
> >
> > git rebase is confused about commits like
> > https://github.com/pfalcon/civetweb/commit/ce8493837bf7676c6d824cdcb1d5e3a7ed476fe1
> > -
Philip Oakley wrote:
> In Junio's recent patch series ([PATCH v3 0/7] Removing the guesswork
> of HEAD in "clone" $gmane/234950), his first patch updated t5505: 'fix
> "set-head --auto with ambiguous HEAD" test'.
>
> A quick look at the git remote man page showed that --auto was not
> documented,
Keshav Kini wrote:
> Jakub Narebski writes:
>> Matthieu Moy writes:
>>> * "git status" now omits the prefix to make its output a comment in a
>>> commit log editor, which is not necessary for human consumption.
>>> + Scripts that parse the output of "git status" are advised to use
>>> +
Matthieu Moy wrote:
> This file isn't really harmful, but isn't useful either, and can create
> minor annoyance for the user:
Would something like the following make sense, to ensure the gc.pid file is
always removed on normal exit?
Signed-off-by: Jonathan Nieder
diff --git c/builtin/gc.c i/bu
Hi,
This iteration incorporates the suggestions made by Phil Hord.
Thanks.
Ramkumar Ramachandra (3):
for-each-ref: introduce %C(...) for color
for-each-ref: introduce %(HEAD) asterisk marker
for-each-ref: introduce %(upstream:track[short])
Documentation/git-for-each-ref.txt | 14 ++-
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%C(green)%(refname:short)%C(reset)%(upstream:trackshort)
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend its format with
%(HEAD) for the same effect.
Now you can use the following format in for-each-ref:
%C(red)%(HEAD)%C(reset) %(refname:short)
to display a red asterisk next t
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%C(green)%(refname:short)%C(reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4 +++-
builtin/for-each-ref.c | 23 +++
On Sat, Sep 28, 2013 at 7:33 AM, Jonathan Nieder wrote:
> Matthieu Moy wrote:
>
>> This file isn't really harmful, but isn't useful either, and can create
>> minor annoyance for the user:
>
> Would something like the following make sense, to ensure the gc.pid file is
> always removed on normal exi
45 matches
Mail list logo
