Warning: E-mail viruses detected

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

Re: Why not git reset --hard ?

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

Re: [PATCH/RFC] read-cache: fix file time comparisons with different precisions

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

Re: Gitk cannot start in the latest version when using --all

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

2.6.0: Comment in rebase instruction has become too rigid

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)

Re: Gitk cannot start in the latest version when using --all

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

Gitk cannot start in the latest version when using --all

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

Re: Gitk cannot start in the latest version when using --all

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

Re: broken racy detection and performance issues with nanosecond file times

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

Re: [PATCH/RFC] read-cache: fix file time comparisons with different precisions

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

[PATCH] git-send-email.perl: Fixed sending of many changes/patches

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

Re: 2.6.0: Comment in rebase instruction has become too rigid

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

Re: [PATCH] git-send-email.perl: Fixed sending of many changes/patches

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

Re: 2.6.0: Comment in rebase instruction has become too rigid

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

Re: Why not git reset --hard ?

> 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

Re: [PATCH 41/68] init: use strbufs to store paths

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 >

Announcing Git for Windows 2.6.0

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

Re: [PATCH 41/68] init: use strbufs to store paths

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

Re: [PATCH 6/8] run-command: add an asynchronous parallel child processor

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

Re: [PATCH 5/8] sigchain: add command to pop all common signals

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

Re: 2.6.0: Comment in rebase instruction has become too rigid

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

[PATCH] git-gui: remove the garbage collection hint

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

Re: 2.6.0: Comment in rebase instruction has become too rigid

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

Re: 2.6.0: Comment in rebase instruction has become too rigid

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

Re: Why not git reset --hard ?

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