Our e-mail content detector has just been triggered by a message you sent:
To: japan11-boun...@scoutingingreenwich.org.uk
Subject: Mail System Error - Returned Mail
Date: Tue Sep 29 07:39:12 2015
One or more of the attachments (document.com) are on
the list of unacceptable attachments for
On Mon, Sep 28, 2015 at 2:19 PM, Junio C Hamano wrote:
> I agree with you if we limit the scope to "reset --hard" that does
> not mention any commit on the command line (or says "HEAD").
>
> However, for things like:
>
> $ git reset --hard HEAD^ Makefile
> $ git reset
Hi Karsten,
On 2015-09-29 12:23, Karsten Blees wrote:
> Am 28.09.2015 um 14:52 schrieb Johannes Schindelin:
>> Otherwise there would be that little loop-hole where (nsec % 1000) == 0 *by
>> chance* and we assume the timestamps to be identical even if they are not.
>
> Yeah, but in this case the
On Tue, 29 Sep 2015 15:40:55 +0200
Christophe COEVOET wrote:
> I'm installing git and gitk from the Ubuntu PPA maintained by the Git
> team. I received the Git 2.6 update today.
> Since this update, I'm unable to launch gitk with --all. I'm
> receiving the following error
Hi,
I noticed that the format of the comment lines in a rebase instruction
sheet has become stricter - it could no longer begin with spaces or
tabs. The comment char ("#" for example) has to appear on the first
column.
This break my little script (activated via some key binding in my
$EDITOR)
Le 29/09/2015 15:49, Konstantin Khomoutov a écrit :
On Tue, 29 Sep 2015 15:40:55 +0200
Christophe COEVOET wrote:
I'm installing git and gitk from the Ubuntu PPA maintained by the Git
team. I received the Git 2.6 update today.
Since this update, I'm unable to launch gitk with
Hi,
I'm installing git and gitk from the Ubuntu PPA maintained by the Git
team. I received the Git 2.6 update today.
Since this update, I'm unable to launch gitk with --all. I'm receiving
the following error message:
Error in startup script: bad menu entry index "Éditer la vue..."
while
On Tue, 29 Sep 2015 15:51:46 +0200
Christophe COEVOET wrote:
> >> I'm installing git and gitk from the Ubuntu PPA maintained by the
> >> Git team. I received the Git 2.6 update today.
> >> Since this update, I'm unable to launch gitk with --all. I'm
> >> receiving the following
Am 28.09.2015 um 19:38 schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Problem 1: Failure to detect racy files (without USE_NSEC)
>> ==
>>
>> Git may not detect racy changes when 'update-index' runs in parallel
Am 28.09.2015 um 14:52 schrieb Johannes Schindelin:
> Otherwise there would be that little loop-hole where (nsec % 1000) == 0 *by
> chance* and we assume the timestamps to be identical even if they are not.
Yeah, but in this case the file would be racy, as racy-checks use
the same comparison
From: Stefan Agner
See http://permalink.gmane.org/gmane.comp.version-control.git/274569
Reported-by: Juston Li
Tested-by: Markos Chandras
Signed-off-by: Lars Wendler
---
git-send-email.perl | 6 +-
1
Nazri Ramliy writes:
> I'd hit that key in my editor that filters the pick instructions add
> inserts the list of the modified files in each commit so that the
> instruction sheet becomes like this:
>
> pick deadbeef some commit message
> # M path/to/foo.txt | 15
Hi Lars,
On 2015-09-29 17:00, Lars Wendler wrote:
> From: Stefan Agner
>
> See http://permalink.gmane.org/gmane.comp.version-control.git/274569
Please summarize the linked discussion in the commit message, as it is the
convention here in the Git project to make commit
Matthieu Moy writes:
> Nazri Ramliy writes:
>
>> I'd hit that key in my editor that filters the pick instructions add
>> inserts the list of the modified files in each commit so that the
>> instruction sheet becomes like this:
>>
>> pick
> I agree with you if we limit the scope to "reset --hard" that does
> not mention any commit on the command line (or says "HEAD").
>
> However, for things like:
>
> $ git reset --hard HEAD^ Makefile
> $ git reset --hard HEAD@{4.hours.ago} Makefile
>
> I do not think "reset --hard" is a
On Thu, Sep 24, 2015 at 2:07 PM, Jeff King wrote:
> The init code predates strbufs, and uses PATH_MAX-sized
> buffers along with many manual checks on intermediate sizes
> (some of which make magic assumptions, such as that init
> will not create a path inside .git longer than 50
>
Dear Git users,
it is my pleasure to announce that Git for Windows 2.6.0 is available (see
https://git-for-windows.github.io/ for details and download links).
Thank you, contributors!
Changes since Git for Windows 2.5.3 (September 18th 2015)
New Features
• Comes with Git 2.6.0
• The
On Tue, Sep 29, 2015 at 04:50:39PM -0700, Michael Blume wrote:
> I see compile errors on my mac:
>
> First a whole bunch of
>
> ./compat/precompose_utf8.h:30:45: warning: declaration of 'struct
> strbuf' will not be visible outside of this function [-Wvisibility]
> void
Stefan Beller writes:
> + while (1) {
> + int i;
> + int output_timeout = 100;
> + int spawn_cap = 4;
> +
> + if (!no_more_task) {
> + for (i = 0; i < spawn_cap; i++) {
> + int
Stefan Beller writes:
> The new method removes all common signal handlers that were installed
> by sigchain_push.
>
> CC: Jeff King
> Signed-off-by: Stefan Beller
> ---
> sigchain.c | 9 +
> sigchain.h | 1 +
> 2 files changed, 10
Matthieu Moy writes:
>> Confirmed: Git 2.1.4 accepts this, 2.6 doesn't:
>>
>> Warning: the command isn't recognized in the following line:
>> - # pick dbafac11052a0075233bdcf0b71f54d1503aa82d test
>>
>> You can fix this with 'git rebase --edit-todo'.
>> Or you can
Git core has had automatic garbage collection for a long time.
Git-gui does not need a similar heuristic.
Signed-off-by: Beat Bolli
Cc: Pat Thoyts
---
git-gui.sh | 3 ---
lib/database.tcl | 26 --
2 files
Junio C Hamano writes:
> I know you alluded to preprocess what is fed to stripspace, but I
> wonder if we can remove the misguided call to stripspace in the
> first place and do something like the attached instead.
>
> git-rebase--interactive.sh | 3 +--
> 1 file changed, 1
2015-09-29 20:17 GMT+02:00 Junio C Hamano :
> Matthieu Moy writes:
>
>>> Confirmed: Git 2.1.4 accepts this, 2.6 doesn't:
>>>
>>> Warning: the command isn't recognized in the following line:
>>> - # pick dbafac11052a0075233bdcf0b71f54d1503aa82d
From: "Jacob Keller"
On Mon, Sep 28, 2015 at 1:42 PM, Junio C Hamano wrote:
"George Spelvin" writes:
I understand that "git reset --soft" makes no sense with a path, but
why not --hard?
I do not think there is anything
25 matches
Mail list logo