On Tue, Dec 22, 2015 at 10:53 PM, Stephen P. Smith wrote:
> Rather than merely pointing readers at the 1.5 release notes to
> learn about shallow clones, document them formally.
Thanks, this version looks better. A few comment below...
> Signed-off-by: Stephen P. Smith
> ---
Right here, below
On Wed, 2015-12-23 at 06:33 +0100, Michael Haggerty wrote:
> On 12/03/2015 01:35 AM, David Turner wrote:
> > Alternate refs backends might not need the refs/heads directory and
> > so
> > on, so we make ref db initialization part of the backend. We also
> > might need to initialize ref backends th
On 12/03/2015 01:35 AM, David Turner wrote:
> The check for duplicate refnames in a transaction is needed for
> all backends, so move it to the common code.
>
> ref_transaction_commit_fn gains a new argument, the sorted
> string_list of affected refnames.
>
> Signed-off-by: David Turner
> ---
>
On 12/03/2015 01:35 AM, David Turner wrote:
> Alternate refs backends might not need the refs/heads directory and so
> on, so we make ref db initialization part of the backend. We also
> might need to initialize ref backends themselves, so we'll add a
> method for that as well.
>
> Signed-off-by:
On 12/22/2015 08:34 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote:
>>> Shawn Pearce writes:
>>>
> But really, aside from slightly helping
> disambiguate references from paths in the command line, what is it good
> for?
>
Rather than merely pointing readers at the 1.5 release notes to
learn about shallow clones, document them formally.
Signed-off-by: Stephen P. Smith
---
Documentation/user-manual.txt | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manu
There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.
Signed-off-by: Stephen P. Smith
---
Documentation/glossary-content.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/glo
I just realized that the two patches I sent earlier were missing the Signed by
lines. I will be resending them.
sps
--
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-in
On Wed, 2015-12-02 at 19:35 -0500, David Turner wrote:
> I'm starting the patchset numbering over from 1 here, because this
> version of the patchset is a subset of the last version.
I'm going out of town on 12/24 and will return 1/5. I won't be reading
this email address. When I get back, I'll
A release candidate Git v2.7.0-rc2 is now available for testing
at the usual places. It is comprised of 511 non-merge commits
since v2.6.0, contributed by 75 people, 24 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following publ
Torsten Bögershausen writes:
> When working in a cross-platform environment, a user wants to
> check if text files are stored normalized in the repository and if
> .gitattributes are set appropriately.
>
> Make it possible to let Git show the line endings in the index and
> in the working tree an
Lars Schneider writes:
> Junio just made me aware of the inappropriate phrasing here.
> This is what I wanted to express:
>
> This patch is based on master as it depends on "git-p4: add option to keep
> empty commits" (4ae048e)"
Thanks.
It wasn't "inappropriate", but was merely prone to be mis
Duy Nguyen writes:
> (I'm joining the newer thread [1] back to this one, thanks for
> reminding me about this)
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/282771
>
> On Tue, Sep 22, 2015 at 2:40 AM, Junio C Hamano wrote:
>> Josef Kufner writes:
>>
>>> Pass graph width to pret
Ralf Thielow writes:
> Signed-off-by: Ralf Thielow
> ---
> builtin/push.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/push.c b/builtin/push.c
> index cc29277..8963dbd 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -547,7 +547,7 @@ int cmd_push(int
Sorry, I didn't do a group-reply in my last mail.
On Mon, Dec 21, 2015 at 03:46:54PM -0800, Junio C Hamano wrote:
> Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes:
>
> > On Thu, Dec 17, 2015 at 10:22:20AM -0800, Junio C Hamano wrote:
> >> I suspect that you are missing the bigger workflow iss
Duy Nguyen writes:
> On Tue, Dec 22, 2015 at 1:31 AM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> Nguyễn Thái Ngọc Duy writes:
>>>
This commit has caused three regression reports so far. All of them are
about spawning git subprocesses, where the new presence of GIT_WORK_T
Elia Pinto wrote:
> This is the second series, the other will be sent separately.
Reviewed-by: Jonathan Nieder
--
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.htm
Martin Fick writes:
> ... What if we added
> a leading slash for absolute references? Then I could do
> something like:
>
> /HEAD
> /refs/heads/master
> /refs/tags/v1.0.0
> /refs/remotes/origin/master
Yeah, that is one way to allow a tool to be absolutely certain there
is no funny DWIMmery goin
Hi,
On Tue, Dec 22, 2015 at 6:53 PM, Pierre-Luc Loyer
wrote:
> Hi,
>
> I've encountered a situation using rebase for which I don't understand the
> results, even after reading the documentation.
> I'm currently working in my feature branch and then I want to squash commits,
> thus I use interac
On Tuesday, December 22, 2015 06:17:28 PM you wrote:
> On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty
wrote:
>
> At a deeper level, the "refs/" part of reference names is
> actually pretty useless in general. I suppose it
> originated in the practice of storing loose references
> under "refs/"
Elia Pinto wrote:
> This is the first series, the other will be sent separately.
FWIW,
Reviewed-by: Jonathan Nieder
--
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-inf
Am 22.12.2015 um 19:35 schrieb Johannes Sixt:
Am 22.12.2015 um 16:27 schrieb Elia Pinto:
-for mail in `echo 00*`
+for mail in $(echo 00*)
-for mail in `echo rfc2047/00*`
+for mail in $(echo rfc2047/00*)
True, these are equvalence transformations. But a better way to get rid
of the back-quot
Am 22. Dezember 2015 um 18:39 schrieb Ralf Thielow :
> #: builtin/tag.c:25
> -#, fuzzy
> msgid ""
> "git tag -l [-n[]] [--contains ] [--points-at ]\n"
> "\t\t[--format=] [--[no-]merged []] [...]"
> msgstr ""
> "git tag -l [-n[]] [--contains ] [--points-at ]\n"
> -"\t\t[...]"
> +"\t\t[--format
Shawn Pearce writes:
> On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote:
>> Shawn Pearce writes:
>>
But really, aside from slightly helping
disambiguate references from paths in the command line, what is it good
for?
>>>
>>> Nothing really; today refs/ prefix is used to enc
Pierre-Luc Loyer writes:
> From the documentation it says that (which is HEAD) will be checked
> out before doing anything and that upon completion, will be the
> current branch. However, this doesn't seem to happen. In fact, it seems more
> like the following is happening during the rebase:
On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>>> But really, aside from slightly helping
>>> disambiguate references from paths in the command line, what is it good
>>> for?
>>
>> Nothing really; today refs/ prefix is used to encourage to the tools
>> that you
Shawn Pearce writes:
>> But really, aside from slightly helping
>> disambiguate references from paths in the command line, what is it good
>> for?
>
> Nothing really; today refs/ prefix is used to encourage to the tools
> that you really meant refs/heads/master and not
> refs/heads/heads/master o
David Turner writes:
> On Mon, 2015-12-21 at 15:34 -0800, Junio C Hamano wrote:
>> Great. Thanks, will queue w/o 1/2 (though I do not think it would
>> hurt).
>>
>> On Mon, Dec 21, 2015 at 3:33 PM, David Turner <
>> dtur...@twopensource.com> wrote:
>> > On Mon, 2015-12-21 at 15:27 -0800, Junio C
On Tue, Dec 22, 2015 at 9:17 AM, Michael Haggerty wrote:
>
> etc. But we store branches into the main "refs/remotes/origin/"
> namespace, leaving no reserved space for the remote "HEAD" (not to
> mention other namespaces that might appear on the remote, such as
> "refs/changes/*", "refs/pull/*", a
Rather than merely pointing readers at the 1.5 release notes to
learn about shallow clones, document them formally.
---
Documentation/user-manual.txt | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual
There are several places in the documentation that
the term shallow clone is used. Defining the term
enables its use elsewhere with a known definition.
---
Documentation/glossary-content.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation
Am 22.12.2015 um 16:27 schrieb Elia Pinto:
-for mail in `echo 00*`
+for mail in $(echo 00*)
-for mail in `echo rfc2047/00*`
+for mail in $(echo rfc2047/00*)
True, these are equvalence transformations. But a better way to get rid
of the back-quotes is to write these lines as
for mail in ec
Duy Nguyen writes:
> On Tue, Dec 22, 2015 at 5:57 PM, Duy Nguyen wrote:
>> On Tue, Dec 22, 2015 at 4:18 AM, Junio C Hamano wrote:
>>> Thanks. I wiggled these three on top of the "Revert the earlier
>>> one"; while I think the result is correct, I'd appreciate if you can
>>> double check the re
Hi,
I've encountered a situation using rebase for which I don't understand the
results, even after reading the documentation.
I'm currently working in my feature branch and then I want to squash commits,
thus I use interactive rebase. After successfully completing the rebase, I end
up in a deta
Signed-off-by: Ralf Thielow
---
builtin/push.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/push.c b/builtin/push.c
index cc29277..8963dbd 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -547,7 +547,7 @@ int cmd_push(int argc, const char **argv, const char
*pre
Translate 68 new messages came from git.pot update in
f4f2c8f (l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)) and
2c0ca05 (l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)).
Signed-off-by: Ralf Thielow
---
po/de.po | 190 ---
1 fil
On Tue, 2015-12-22 at 09:08 -0800, Dave Borowitz wrote:
> Well, IIUC one of the reasons for Git's fork-everything strategy is to
> avoid having to dynamically link the core git binary against large
> libraries like libcurl, so the dependency size has been taken into
> account at least in that sense
On 12/22/2015 05:11 PM, Shawn Pearce wrote:
> On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty
> wrote:
>> On 12/17/2015 10:02 PM, Shawn Pearce wrote:
>>> I started playing around with the idea of storing references directly
>>> in Git. Exploiting the GITLINK tree entry, we can associate a name
On Tue, Dec 22, 2015 at 7:39 AM, Paul Smith wrote:
> I'm trying to build Git (2.6.4) on GNU/Linux, but without any
> requirements (other than basic libc etc.) on the local system. This
> works fine except for one thing: git-remote-https.
>
> In order to build this I need to have libcurl, but libc
On Tue, Dec 22, 2015 at 8:11 AM, Shawn Pearce wrote:
> Yup, and Gerrit Code Review servers often have 100k+ refs per
> repository. We can't rewrite the entire store every time either. So
> its not a flat list. Its a directory structure using the / separators
> in the ref namespace.
I wonder if th
(I'm joining the newer thread [1] back to this one, thanks for
reminding me about this)
[1] http://thread.gmane.org/gmane.comp.version-control.git/282771
On Tue, Sep 22, 2015 at 2:40 AM, Junio C Hamano wrote:
> Josef Kufner writes:
>
>> Pass graph width to pretty formatting, so N in '%>|(N)' in
Duy Nguyen writes:
> In that case we can just check config once in read_index_from and
> destroy UNTR extension. Or the middle ground, we check config once in
> that place, make a note in struct index_state, and make invalidate_*
> check that note instead of config file. The middle ground has an
On Monday, December 21, 2015 10:47:16 PM Eric Sunshine wrote:
> On Mon, Dec 21, 2015 at 9:09 PM, Stephen P. Smith wrote:
> > [[repositories-and-branches]]
> > Repositories and Branches
> > =
> > @@ -72,6 +71,25 @@ called the <>, together
> > with a special
> > top-leve
On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty wrote:
> On 12/17/2015 10:02 PM, Shawn Pearce wrote:
>> I started playing around with the idea of storing references directly
>> in Git. Exploiting the GITLINK tree entry, we can associate a name to
>> any SHA-1.
>>
>> By storing all references in
Duy Nguyen writes:
> On Sun, Dec 20, 2015 at 10:41:44AM -0600, Elliott Cable wrote:
>> I'm not sure what version the `%>` / `<|` / etc padding showed up in,
>> but they're truly excellent for building beautiful one-line `git log`
>> output.
>
> Somebody found my code useful!! :-D
Is this related
[Jeff King, Shawn Pearce and myself represent the Git project to the
Conservancy, and here is a request for help from us.]
We apologize that we're interrupting the usual content on this
mailing list with a fundraising message, but the non-profit home of
the Git project, Software Freedom Conservanc
On 12/17/2015 10:02 PM, Shawn Pearce wrote:
> I started playing around with the idea of storing references directly
> in Git. Exploiting the GITLINK tree entry, we can associate a name to
> any SHA-1.
>
> By storing all references in a single tree, atomic transactions are
> possible. Its a simple
I'm trying to build Git (2.6.4) on GNU/Linux, but without any
requirements (other than basic libc etc.) on the local system. This
works fine except for one thing: git-remote-https.
In order to build this I need to have libcurl, but libcurl is a MONSTER
library with an enormous number of prerequis
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
This patch series continues the changes introduced with the merge
6753d8a85d543253d95184ec2faad6dc197f248:
Merge branch 'ep/shell-command-substitution'
Adjust shell scripts to use $(cmd) instead of `cmd`.
This is the third serie, the other will be sent separately.
Elia Pinto (10):
t
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
Hi guys,
Another two new messages need to be translated, so let's start Git l10n
for Git v2.7.0 round 2.
l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)
Generate po/git.pot from v2.7.0-rc1-44-g1d88dab for git v2.7.0 l10n round 2.
Signed-off-by: Jiang Xin
You can get it from the u
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
This patch series continues the changes introduced with the merge
6753d8a85d543253d95184ec2faad6dc197f248:
Merge branch 'ep/shell-command-substitution'
Adjust shell scripts to use $(cmd) instead of `cmd`.
This is the second series, the other will be sent separately.
Elia Pinto (10):
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
The backquoted form is the traditional method for command
substitution, and is supported by POSIX. However, all but the
simplest uses become complicated quickly. In particular, em
This patch series continues the changes introduced with the merge
6753d8a85d543253d95184ec2faad6dc197f248:
Merge branch 'ep/shell-command-substitution'
Adjust shell scripts to use $(cmd) instead of `cmd`.
This is the first series, the other will be sent separately.
Elia Pinto (10):
On Tue, Dec 22, 2015 at 5:57 PM, Duy Nguyen wrote:
> On Tue, Dec 22, 2015 at 4:18 AM, Junio C Hamano wrote:
>> Thanks. I wiggled these three on top of the "Revert the earlier
>> one"; while I think the result is correct, I'd appreciate if you can
>> double check the result when I push the topic
When working in a cross-platform environment, a user wants to
check if text files are stored normalized in the repository and if
.gitattributes are set appropriately.
Make it possible to let Git show the line endings in the index and
in the working tree and the effective text/eol attributes.
The
On Sun, Dec 20, 2015 at 10:41:44AM -0600, Elliott Cable wrote:
> I'm not sure what version the `%>` / `<|` / etc padding showed up in,
> but they're truly excellent for building beautiful one-line `git log`
> output.
Somebody found my code useful!! :-D
> This may be a long-shot, but, unfortunatel
On Tue, Dec 22, 2015 at 4:18 AM, Junio C Hamano wrote:
> Thanks. I wiggled these three on top of the "Revert the earlier
> one"; while I think the result is correct, I'd appreciate if you can
> double check the result when I push the topic out later today.
Looks good. "prove" passed too by the w
On Tue, Dec 22, 2015 at 09:17:38AM +0100, Dennis Kaarsemaker wrote:
> On ma, 2015-12-21 at 14:29 +, Alan Mackenzie wrote:
> > Hello, git project.
> >
> > Last night, whilst clearing out a stale "stash stack", I did "git stash
> > pop". There were conflicts in two files.
> >
> > However, all
On 20 Dec 2015, at 15:59, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> Hi,
>
> this patch improves "git-p4: add option to keep empty commits" (4ae048e)
> and therefore should be applied on master.
>
> Thanks,
> Lars
Junio just made me aware of the inappropriate phrasing here.
T
On 21 Dec 2015, at 21:31, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> Hi,
>>
>> these patches extend "git-p4: add trap to kill p4d on test exit" (dfe90e8)
>> and therefore should be applied on master.
>
> Wait, wait. Please be a bit more careful
On 21 Dec 2015, at 21:38, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> From: Lars Schneider
>>
>> If tests are executed in verbose mode then the retry logic clutters the
>> test output. Suppress that clutter.
>>
>> Signed-off-by: Lars Schneider
>> ---
>> t/lib-git-p4.sh | 2
On Tue, Dec 22, 2015 at 1:30 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Thu, Dec 17, 2015 at 2:44 PM, Jeff King wrote:
>>> I think we may actually be thinking of the same thing. Naively, I would
>>> expect:
>>>
>>> ..
>>> - if there is cache data in the index but that config flag i
On ma, 2015-12-21 at 14:29 +, Alan Mackenzie wrote:
> Hello, git project.
>
> Last night, whilst clearing out a stale "stash stack", I did "git stash
> pop". There were conflicts in two files.
>
> However, all the popped files became staged. This doesn't normally happen.
> It was intensely
92 matches
Mail list logo
