Moritz Neeb writes:
> On 02/28/2016 09:11 PM, Matthieu Moy wrote:
>
>> This patch was written after seen one more time a student panicked
>> because he had a "git commit" backgrounded.
>
> I think git commit is almost the only case where this would happen.
Right. It's not the only case when Git
I haven't digged further,
but trying to verify t9115 under Windows gave this:
compat/mingw.c: In function 'mingw_spawnve_fd':
compat/mingw.c:1072:10: warning: implicit declaration of function
'xmalloc_array' [-Wimplicit-function-declaration]
wargs = xmalloc_array(st_add(st_mult(2, args.len),
+ (
+ cd "$git" &&
+ git init . &&
+ git config --add git-p4.mapUser "mmax -> Max Mustermann
" &&
+ git config --add git-p4.mapUser "mo -> Moritz Untreu
" &&
Probably better to use more innocuous names. I'm not sure who these
peop
On 28 February 2016 at 10:25, wrote:
> From: Lars Schneider
>
> Map a P4 user to a specific name and email address in Git with the
> "git-p4.mapUser" config. The config value must be a string adhering
> to the format "p4user -> First Lastname ".
Seems generally fine. I agree with Eric's comment
Hi,
I have recently downloaded 64-bit Git for Windows (the file I downloaded
was "Git-2.7.2-64-bit.exe"). This reports a version string of "git
version 2.7.2.windows.1"
Using it from the command line, after cloning a repository, I attempted
to "git pull" a private repository from GitHub. From
On Sun, Feb 28, 2016 at 12:05 PM, Lars Schneider
wrote:
> On 28 Feb 2016, at 17:19, Eric Sunshine wrote:
>> On Sun, Feb 28, 2016 at 5:25 AM, wrote:
>>> +git-p4.mapUser::
>>> + Map a P4 user to a name and email address in Git. Use a string
>>> + with the following format to create a
On Mon, Feb 29, 2016 at 12:48 AM, Fred's Personal
wrote:
> Duy,
>
> Thanks for advice, here is the result of executing the lines you suggested:
>
> user1@Host1 MINGW64 ~/gitrepository (master)
> $ export GIT_TRACE=1
>
> user1@Host1 MINGW64 ~/gitrepository (master)
> $ git clone -v ssh://user1@Host
On Mon, Feb 29, 2016 at 3:11 AM, Matthieu Moy wrote:
> diff --git a/lockfile.c b/lockfile.c
> index 80d056d..a7d6175 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -150,9 +150,11 @@ void unable_to_lock_message(const char *path, int err,
> struct strbuf *buf)
> {
> if (err == EEXIST) {
On Mon, Feb 29, 2016 at 1:57 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> builtin/blame.c | 58
>> -
>> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> I think most of
On 02/28/2016 09:11 PM, Matthieu Moy wrote:
> A common mistake leading a user to see this message is to launch "git
> commit", let the editor open (and forget about it), and try again to
> commit.
>
> The previous message was going too quickly to "a git process crashed"
> and to the advice "remove
Commit 58f2ed0 (remote-curl: pass ref SHA-1 to fetch-pack as well,
2013-12-05) added support for specifying a SHA-1 as well as a ref name.
Add support for specifying just a SHA-1 and set the ref name to the same
value in this case.
Signed-off-by: Gabriel Souza Franco
---
Not the cleanest conditi
Luke Diamand writes:
> On 23 February 2016 at 20:56, Amadeusz Żołnowski wrote:
>>
>> To simplify things, why not just update ref during submit from bare
>> repository? As you have pointed out, if user invokes submit in this
>> context he/she actually wants to submit from bare repo and probably
>
A common mistake leading a user to see this message is to launch "git
commit", let the editor open (and forget about it), and try again to
commit.
The previous message was going too quickly to "a git process crashed"
and to the advice "remove the file manually".
This patch modifies the message in
From: Torsten Bögershausen
Commit
"tree-diff: catch integer overflow in combine_diff_path allocation"
make gcc under Mac OX 10.6 crash like this:
CC combine-diff.o
combine-diff.c: In function ‘diff_tree_combined’:
combine-diff.c:1391: internal compiler error: Segmentation fault
Xcode for Mac OS
John Keeping writes:
> Here's a series that changes the behaviour of "git config --get-urlmatch"
> when no appropriate key is found as well as a couple of improvements to
> the documentation while we're here.
Sounds sensible. It does change the behaviour, but it is inevitable
that a bugfix has
Paul Tan writes:
> Ultimately, git-pull needs to be aware of whether autostash is active
> or not (and this means rebase.autostash needs to be looked at as well)
> because if autostash is disabled, git-pull needs to perform the
> "worktree is clean" check. And this "worktree is clean" check needs
Gabriel Souza Franco writes:
>>> struct object_id oid;
>>>
>>> - if (!get_oid_hex(name, &oid) && name[GIT_SHA1_HEXSZ] == ' ')
>>> - name += GIT_SHA1_HEXSZ + 1;
>>> - else
>>> + if (get_oid_hex(name, &oid))
>>> oidclr(&oid);
>>> + else if (name[GIT_S
Jeff King writes:
> So the patch:
>
>> > diff --git a/fetch-pack.c b/fetch-pack.c
>>...
> is a wrong direction, I think. It removes the extra safety check that
> skips the ref above. But worse, in the example above, it overwrites the
> real object "1234..." with the name of the ref "abcd..." in t
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/clone.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
The command otherwise has been i18n'ed and it is clear that the
patches that added these strings should have done the i18n marking
show
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/checkout.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
The command otherwise has been i18n'ed and it is clear that the
patch that added this string should have done the i18n marking shown
here from
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/blame.c | 58
> -
> 1 file changed, 29 insertions(+), 29 deletions(-)
I think most of the strings we see here are not new ones introduced
in this cycle.
Stephan Beyer writes:
> However, it probably should be documented what "git bisect next" does
> after you've specified bad and good commits.
>
> For that, I'd like to have an extra informational paragraph.
> What about: "In general, the command computes the next commit for the
> bisection and che
Torsten Bögershausen writes:
> How about something like this as a workaround ?
> (I can send a proper patch, if this is the way forward)
> ...
> Make Git compile under Mac OS X 10.6 by using clang instead of gcc
Given that it is understandable that Apple is no longer interesting
in fixing co
On 28.02.16 05:59, Eric Wong wrote:
> tbo...@web.de wrote:
> Please keep lines wrapped at 80 cols or less.
> (I need big fonts)
OK
>
>> @@ -105,10 +105,10 @@ test_expect_success UTF8 'svn.pathnameencoding=cp932
>> new file on dcommit' '
>> '
> Why the extra 'o'?
That shouldn't be there, sorry.
W
Duy,
Thanks for advice, here is the result of executing the lines you suggested:
user1@Host1 MINGW64 ~/gitrepository (master)
$ export GIT_TRACE=1
user1@Host1 MINGW64 ~/gitrepository (master)
$ git clone -v ssh://user1@Host2/srv/centralrepo
12:33:47.928365 git.c:348 trace: built-in
On 28 Feb 2016, at 17:19, Eric Sunshine wrote:
> On Sun, Feb 28, 2016 at 5:25 AM, wrote:
>> Map a P4 user to a specific name and email address in Git with the
>> "git-p4.mapUser" config. The config value must be a string adhering
>> to the format "p4user -> First Lastname ".
>
> With the cave
On Sun, Feb 28, 2016 at 5:25 AM, wrote:
> Map a P4 user to a specific name and email address in Git with the
> "git-p4.mapUser" config. The config value must be a string adhering
> to the format "p4user -> First Lastname ".
With the caveat that I'm not a Perforce user, is this arrow "->"
thingy
On Sun, Feb 28, 2016 at 2:47 AM, Moritz Neeb wrote:
> On 02/28/2016 07:56 AM, Eric Sunshine wrote:
>> On Sun, Feb 28, 2016 at 12:13 AM, Moritz Neeb wrote:
>>> The strbuf is now rtrimmed before splitting. This is still required
>>> to remove potential CRs. In the next step this will then be done
>
Hi guys,
Git v2.8.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 48 updated messages need to be translated since last
update:
l10n: git.pot: v2.8.0 round 1 (48 new, 16 removed)
Generate po/git.pot from v2.8.0-rc0 for git v2.8.0 l10n round 1.
Hi Junio,
On Sun, Feb 28, 2016 at 3:26 AM, Junio C Hamano wrote:
> Mehul Jain writes:
>> @@ -835,13 +841,10 @@ int cmd_pull(int argc, const char **argv, const char
>> *prefix)
>> hashclr(orig_head);
>>
>> if (opt_rebase) {
>> - int autostash = 0;
>> -
>>
--get does not fail if a key is multi-valued, it returns the last value
as described in its documentation. Clarify the description of --get-all
to avoid implying that --get does fail in this case.
Signed-off-by: John Keeping
---
Documentation/git-config.txt | 3 +--
1 file changed, 1 insertion(
Using a numbered list is confusing because the exit codes are not listed
in order so the numbers at the start of each line do not match the exit
codes described by the following text. Switch to a bulleted list so
that the only number appearing on each line is the exit code described.
Signed-off-b
The --get, --get-all and --get-regexp options to git-config exit with
status 1 if the key is not found but --get-urlmatch succeeds in this
case.
Change --get-urlmatch to behave in the same way as the other --get*
options so that all four are consistent. --get-color is a special case
because it ac
On Sun, Feb 28, 2016 at 10:45:57AM +, John Keeping wrote:
> It looks to me like a simple bug that --get-urlmatch doesn't return 1 if
> the key isn't found, but git-config(1) isn't entirely clear. The
> overall documentation on exit codes at the end of DESCRIPTION says that
> exit code 1 means:
On Sun, Feb 28, 2016 at 10:45:57AM +, John Keeping wrote:
> On Sun, Feb 28, 2016 at 10:09:12AM +0530, Guilherme wrote:
> > My current woes are with multi-valued configuration values. More
> > specifically credential.helper
> >
> > The documentation of git config says that when a value is not m
On Sun, Feb 28, 2016 at 5:35 PM, Lars Schneider
wrote:
> On 26 Feb 2016, at 10:33, Duy Nguyen wrote:
>> Probably misunderstanding. I meant something like this
>>
>> CFLAGS += -Werror
>> CFLAGS += -Wdecl..
>> CFLAGS += -Wno-form..
>
> Oh. I just realized the patch made it already into master. Do y
On Sun, Feb 28, 2016 at 10:09:12AM +0530, Guilherme wrote:
> My current woes are with multi-valued configuration values. More
> specifically credential.helper
>
> The documentation of git config says that when a value is not matched
> it should return 1.
>
> To reproduce make sure that credential
On 26 Feb 2016, at 10:33, Duy Nguyen wrote:
> On Fri, Feb 26, 2016 at 4:30 PM, Lars Schneider
> wrote:
>>
>>> On 26 Feb 2016, at 10:26, Duy Nguyen wrote:
>>>
>>> On Thu, Feb 25, 2016 at 3:42 PM, wrote:
+ifdef DEVELOPER
+ CFLAGS += -Werror \
+
From: Lars Schneider
Map a P4 user to a specific name and email address in Git with the
"git-p4.mapUser" config. The config value must be a string adhering
to the format "p4user -> First Lastname ".
Signed-off-by: Lars Schneider
---
Documentation/git-p4.txt | 11 +
git-p4.py
Hi,
> I didn't see anything going on for this one, but you may want to
> double-check with the ml's archives.
>
I checked the archives and there doesn't seem to be any active work on this.
I made the required changes and ran the test suite. Though all the tests pass,
there still are two queries I
Mehul Jain writes:
> If user uses "git pull --[no-]autostash" then two possible things can be done:
>
>* Either "git pull" ignores "--[no-]autostash" and calls
> underlying "git merge",
> as merge stashes the untracked files by itself. Thus
> ign
On Sun, Feb 28, 2016 at 12:56 AM, Junio C Hamano wrote:
> Mehul Jain writes:
>
>> git pull --rebase understands --[no-]autostash flag.
>>
>> This flag overrides config variable "rebase.autoStash"
>> if set (default is false).
>
> Is that a statement of a fact? If so, is it true before this patch
On 02/28/2016 06:07 AM, Moritz Neeb wrote:
> Changes since v2:
>
> * Line splitting in notes_copy_from_stdin() is changed to string_list_split as
> suggested by Eric Sunshine.
> * The behavior change in interactive cleaning from patch v2 is undone.
> * Some of the previous patches were broken be
43 matches
Mail list logo