Warning: E-mail viruses detected

[MailScanner]

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 this site and will not have
been delivered.

Consider renaming the files to avoid this constraint.

The virus detector said this about the message:
Report: Report: MailScanner: Executable DOS/Windows programs are dangerous in 
email (document.com)
Report: No programs allowed (document.com)


-- 
MailScanner
Email Virus Scanner
MailScanner

--
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.html

Re: Why not git reset --hard ?

[Jacob Keller]

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 --hard HEAD@{4.hours.ago} Makefile
>
> I do not think "reset --hard" is a good match.  Conceptually, you
> are grabbing what was stored in a given commit and checking that out
> to your current workspace (that is, the index and the working tree).
>

Agreed. I just get used to thinking about using it against HEAD. it's
just weird to me that something which sometimes switches branches is
also the thing to grab a version of a file.

reset hard really would be weird in this case, because you really
don't know if the user meant "rewind the history, but keep everything
*except* that listed file..

That makes sense now that I think about it. Thanks.

Regards,
Jake
--
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.html

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

[Johannes Schindelin]

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 file would be racy, as racy-checks use
> the same comparison now.

True.

> IMO change detection is so fundamental that it should Just Work,
> without having a plethora of config options that we need to explain
> to end users.
> 
> If that means that once in a million cases we need an extra content
> check to revalidate such falsely racy entries, that's fine with me.

You have a good point there. I retract my objections.

Thanks,
Dscho
--
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.html

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

[Konstantin Khomoutov]

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 message:
> 
> Error in startup script: bad menu entry index "Éditer la vue..."
>  while executing
> ".bar.view entryconf [mca "Edit view..."] -state normal"
>  invoked from within
> "if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne
> {}} {
>  # create a view for the files/dirs specified on the command line
>  se..."
>  (file "/usr/bin/gitk" line 12442)
> 
> Launching gitk without the --all option works fine.
> Launching gitk with the --branches option or the --tags option is
> also broken

Does it start if you run it via

$ LANG=C gitk --all

or

$ LANG=en_US.UTF-8 gitk --all

?
--
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.html

2.6.0: Comment in rebase instruction has become too rigid

[Nazri Ramliy]

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) for adding the list of modified files under each "pick"
command. The way I have it setup is something like this, given the
following rebase intruction:

  pick deadbeef some commit message
  pick cafebabe another commit message

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 --
  pick cafebabe another commit message
 # M bar.txt | 2 +-


IIRC before git 2.6.0 this worked fine. With git 2.6.0 the rebase
stops midway with warning about invalid instruction due to the now
no-longer recognized indented comments.

I could work around this by changing my script so that it removes the
indentation prefix so that the instruction would become like this:

  pick deadbeef some commit message
  # M path/to/foo.txt | 15 --
  pick cafebabe another commit message
  # M bar.txt | 2 +-

but this would make it harder to read because of the increased clutter
between the rebase instructions and the informative "what files were
changed in this commit" comment.

Looking at git-rebase--interactive.sh it seems that this is due to
"git stripspace --strip-comments".

Would it be okay if the behavior is reverted to the old one - which is
to recognize indented comments in the rebase instruction?

Nazri
--
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.html

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

[Christophe COEVOET]

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 --all. I'm
receiving the following error message:

Error in startup script: bad menu entry index "Éditer la vue..."
  while executing
".bar.view entryconf [mca "Edit view..."] -state normal"
  invoked from within
"if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne
{}} {
  # create a view for the files/dirs specified on the command line
  se..."
  (file "/usr/bin/gitk" line 12442)

Launching gitk without the --all option works fine.
Launching gitk with the --branches option or the --tags option is
also broken

Does it start if you run it via

$ LANG=C gitk --all

or

$ LANG=en_US.UTF-8 gitk --all

?

Yeah, both of these commands are working fine.

--
Christophe | Stof

--
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.html

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

[Christophe COEVOET]

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 executing
".bar.view entryconf [mca "Edit view..."] -state normal"
invoked from within
"if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
# create a view for the files/dirs specified on the command line
se..."
(file "/usr/bin/gitk" line 12442)

Launching gitk without the --all option works fine.
Launching gitk with the --branches option or the --tags option is also 
broken


--
Christophe Coevoet

--
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.html

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

[Konstantin Khomoutov]

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 error message:
> >>
> >> Error in startup script: bad menu entry index "Éditer la vue..."
> >>   while executing
> >> ".bar.view entryconf [mca "Edit view..."] -state normal"
> >>   invoked from within
> >> "if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd
> >> ne {}} {
> >>   # create a view for the files/dirs specified on the command
> >>   # line
> >>   se..."
> >>   (file "/usr/bin/gitk" line 12442)
[...]
> > Does it start if you run it via
> >
> > $ LANG=C gitk --all
> >
> > or
> >
> > $ LANG=en_US.UTF-8 gitk --all
> >
> > ?
> Yeah, both of these commands are working fine.

OK, so the problem is that some menu entry has the title "Edit view..."
which is for some reason not translated for your current locale,
and then some code tries to locate it using the original title
translated to French -- I fathom the command [mca] being called here
stands for "Message Catalog A-something" ;-)
--
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.html

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

[Karsten Blees]

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
>> to work tree updates.
>>
>> Consider this (where timestamps are t.):
>>
>>  t0.0$ echo "foo" > file1
>>  t0.1$ git update-index file1 &  # runs in background
> 
> I just wonder after looking at the ampersand here ...
> 
>> Please let me know what you think of this...maybe I've completely
>> screwed up and can no longer see the forest for all the trees.
> 
> ... if your task would become much simpler if you declare "once you
> give Git the control, do not muck with the repository until you get
> the control back".
> 

This is just to illustrate the problem. GUI-based applications will
often do things in the background that you cannot control. E.g. gitk,
git gui, Eclipse or TortoiseGit don't tell you when and how long you
shouldn't touch the working copy. At the same time, IntelliJ IDEA and
most office suits have the auto-save feature turned on by default,
and you cannot tell them when *not* to auto-save.

It may still be quite unlikely that this happens (you need two
changes within a second, without changing the file size), but *if*
it happens, the user may not even notice. And as git trusts the
false stat data blindly, the problem won't go away automatically.
You can mark all entries racy by setting index mtime to some value
far in the past, but this implies that you noticed that something
was wrong...

--
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.html

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

[Karsten Blees]

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 now.

IMO change detection is so fundamental that it should Just Work,
without having a plethora of config options that we need to explain
to end users.

If that means that once in a million cases we need an extra content
check to revalidate such falsely racy entries, that's fine with me.

Cheers,
Karsten
--
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.html

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

[Lars Wendler]

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 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index e3ff44b..e907e0ea 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1365,7 +1365,11 @@ Message-Id: $message_id
$smtp->mail( $raw_from ) or die $smtp->message;
$smtp->to( @recipients ) or die $smtp->message;
$smtp->data or die $smtp->message;
-   $smtp->datasend("$header\n$message") or die $smtp->message;
+   $smtp->datasend("$header\n") or die $smtp->message;
+   my @lines = split /^/, $message;
+   foreach my $line (@lines) {
+   $smtp->datasend("$line") or die $smtp->message;
+   }
$smtp->dataend() or die $smtp->message;
$smtp->code =~ /250|200/ or die "Failed to send 
$subject\n".$smtp->message;
}
-- 
2.6.0

--
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.html

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

[Matthieu Moy]

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 --
>   pick cafebabe another commit message
>  # M bar.txt | 2 +-
>
>
> IIRC before git 2.6.0 this worked fine.

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 abort the rebase with 'git rebase --abort'.

I didn't bisect, but I guess this was introduced in the series
introducing this check on the todolist before starting the bisection.

Actually, I think we accepted indented comments by mistake: the
semantics of comments in Git is usually that it must start at the first
column (try an indented # in a commit buffer, it's not a comment). But
since Git accepted it in the past, we should continue accepting it to
avoid breaking the user experience.

No time to send a patch right now, but I will hopefully be able to do
this within the next few days. It should be essentially a s/^ *// before
calling stripspaces.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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.html

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

[Johannes Schindelin]

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 messages self-sufficient, 
with links thrown in only to provide more context when desired.

Ciao,
Johannes

--
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.html

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

[Matthieu Moy]

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 deadbeef some commit message
>>  # M path/to/foo.txt | 15 --
>>   pick cafebabe another commit message
>>  # M bar.txt | 2 +-
>>
>>
>> IIRC before git 2.6.0 this worked fine.
>
> 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 abort the rebase with 'git rebase --abort'.
>
> I didn't bisect, but I guess this was introduced in the series
> introducing this check on the todolist before starting the bisection.

Indeed:

804098bb30a5339cccb0be981a3e876245aa0ae5 is the first bad commit
commit 804098bb30a5339cccb0be981a3e876245aa0ae5
Author: Galan Rémi 
Date:   Mon Jun 29 22:20:32 2015 +0200

git rebase -i: add static check for commands and SHA-1

Check before the start of the rebasing if the commands exists, and for
the commands expecting a SHA-1, check if the SHA-1 is present and
corresponds to a commit. In case of error, print the error, stop git
rebase and prompt the user to fix with 'git rebase --edit-todo' or to
abort.

This allows to avoid doing half of a rebase before finding an error
and giving back what's left of the todo list to the user and prompt
him to fix when it might be too late for him to do so (he might have
to abort and restart the rebase).

Signed-off-by: Galan Rémi 
Signed-off-by: Junio C Hamano 

:100644 100644 c26a200a6c0e7edd2b182b71af50df52179d295f 
dcc3401b5a8c45fd9c5ba474416eb4a6c3c9a29e M  git-rebase--interactive.sh
:04 04 3a2882c656f4a2ea3cfcba7e5afca79877c61295 
522781ff8b31d55b76064d27f3d4326026721091 M  t

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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.html

Re: Why not git reset --hard ?

[George Spelvin]

> 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 good match.  Conceptually, you
> are grabbing what was stored in a given commit and checking that out
> to your current workspace (that is, the index and the working tree).

I actually disagree, BUT that was based on an inaccurate mental model,
so I'm not sure if my judgement can be trusted.  Still, I'll blather on
just to give a different perspective.

To me, "git reset --hard" is "git reset" plus checking out from the index
to the working directory.  That's the difference and the only difference.

So any difference in behaviour between
git reset --hard  -- 
and
git reset --mixed  -- 
git checkout -- 
needs to be justified.  (There might be some if a file does not exist in
the revision.)

> All modes of "git reset" are primarily about updating where in the
> history DAG your HEAD points at, and then adjusting your current
> workspace to that update, taking into account the reason why you are
> repointing your HEAD in the history DAG (e.g. when doing --hard
> reset, you want the workspace to match what the commit your HEAD now
> points at; when doing --soft reset, you don't want any changes
> done).

Er... no.  Re-pointing HEAD can *only* be done as a global operation.
That's the single most fundamental difference between git and CVS.

Any time you specify a path, *obviously* that part can't be done, so
git-reset just skips that part and goes on to the index-updating part..


Git reset also skips that part in the single most common invocation
scenario: un-doing git-add.  That's for a different reason (pointing
HEAD to HEAD is a no-op), but it contributes to the mental model that
git-reset is fundamentally used for copying from history to the index.


That's my mental model, for what little it's worth (given the caveat above):
- git checkout is fundamentally about copying from the index to the
  working directory.  If can also move HEAD first (and create branches!)
  as a convenience feature.
- git reset is fundamentally about copying from HEAD to the index.
  Like git-checkout, it can also move HEAD first (and copy to the working
  directory) as a convenience feature.

To me, "git reset" is "throw the changes away and get me back to
some previous state".  That's why it's the tool I reached for in the
merge-conflict situation that started this thread.

I didn't think to try "git checkout" because I needed to overwrite the
merge conflict in the index, and I don't think of "git checkout" as
doing that.  (Globally, it fails if there are unresolved conflits.)
--
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.html

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

[Michael Blume]

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
> characters).
>
> We can simplify this greatly by using strbufs, which drops
> some hard-to-verify strcpy calls.  Note that we need to
> update probe_utf8_pathname_composition, too, as it assumes
> we are passing a buffer large enough to append its probe
> filenames (it now just takes a strbuf, which also gets rid
> of the confusing "len" parameter, which was not the length of
> "path" but rather the offset to start writing).
>
> Some of the conversion makes new calls to git_path_buf.
> While we're in the area, let's also convert existing calls
> to git_path to the safer git_path_buf (our existing calls
> were passed to pretty tame functions, and so were not a
> problem, but it's easy to be consistent and safe here).
>
> Note that we had an explicit test that "git init" rejects
> long template directories. This comes from 32d1776 (init: Do
> not segfault on big GIT_TEMPLATE_DIR environment variable,
> 2009-04-18). We can drop the test_must_fail here, as we now
> accept this and need only confirm that we don't segfault,
> which was the original point of the test.
>
> Signed-off-by: Jeff King 
> ---
>  builtin/init-db.c| 174 
> ---
>  compat/precompose_utf8.c |  12 ++--
>  compat/precompose_utf8.h |   2 +-
>  git-compat-util.h|   2 +-
>  t/t0001-init.sh  |   4 +-
>  5 files changed, 87 insertions(+), 107 deletions(-)
>
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index e7d0e31..cf6a3c8 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -36,10 +36,11 @@ static void safe_create_dir(const char *dir, int share)
> die(_("Could not make %s writable by group"), dir);
>  }
>
> -static void copy_templates_1(char *path, int baselen,
> -char *template, int template_baselen,
> +static void copy_templates_1(struct strbuf *path, struct strbuf *template,
>  DIR *dir)
>  {
> +   size_t path_baselen = path->len;
> +   size_t template_baselen = template->len;
> struct dirent *de;
>
> /* Note: if ".git/hooks" file exists in the repository being
> @@ -49,77 +50,64 @@ static void copy_templates_1(char *path, int baselen,
>  * with the way the namespace under .git/ is organized, should
>  * be really carefully chosen.
>  */
> -   safe_create_dir(path, 1);
> +   safe_create_dir(path->buf, 1);
> while ((de = readdir(dir)) != NULL) {
> struct stat st_git, st_template;
> -   int namelen;
> int exists = 0;
>
> +   strbuf_setlen(path, path_baselen);
> +   strbuf_setlen(template, template_baselen);
> +
> if (de->d_name[0] == '.')
> continue;
> -   namelen = strlen(de->d_name);
> -   if ((PATH_MAX <= baselen + namelen) ||
> -   (PATH_MAX <= template_baselen + namelen))
> -   die(_("insanely long template name %s"), de->d_name);
> -   memcpy(path + baselen, de->d_name, namelen+1);
> -   memcpy(template + template_baselen, de->d_name, namelen+1);
> -   if (lstat(path, _git)) {
> +   strbuf_addstr(path, de->d_name);
> +   strbuf_addstr(template, de->d_name);
> +   if (lstat(path->buf, _git)) {
> if (errno != ENOENT)
> -   die_errno(_("cannot stat '%s'"), path);
> +   die_errno(_("cannot stat '%s'"), path->buf);
> }
> else
> exists = 1;
>
> -   if (lstat(template, _template))
> -   die_errno(_("cannot stat template '%s'"), template);
> +   if (lstat(template->buf, _template))
> +   die_errno(_("cannot stat template '%s'"), 
> template->buf);
>
> if (S_ISDIR(st_template.st_mode)) {
> -   DIR *subdir = opendir(template);
> -   int baselen_sub = baselen + namelen;
> -   int template_baselen_sub = template_baselen + namelen;
> +   DIR *subdir = opendir(template->buf);
> if (!subdir)
> -   die_errno(_("cannot opendir '%s'"), template);
> -   path[baselen_sub++] =
> -   template[template_baselen_sub++] = '/';
> -   path[baselen_sub] =
> -   template[template_baselen_sub] = 0;
> -   copy_templates_1(path, baselen_sub,
> -   

Announcing Git for Windows 2.6.0

[Johannes Schindelin]

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 WhoUses.exe tool to determine which process holds a lock on a
given file (which was shipped with Git for Windows 1.x) gets
installed alongside Git for Windows again.
  • The values CurrentVersion, InstallPath and LibexecPath are added to
the HKEY_LOCAL_MACHINE\Software\GitForWindows registry key to help
third-party add-ons to find us.
  • When fetching or pushing with Git without a console, we now fall
back to Git GUI's askpass helper to ask for pass phrases.
  • When run through \cmd\git.exe, Git will find tools in
$HOME/bin now.

Bug Fixes

  • The portable version avoids DLL search path problems even when
installed into a FAT filesystem.
  • Configuring notepad as editor without configuring a width for
commit messages no longer triggers an error message.
  • When using Windows' default console for Git Bash, the .sh file
associations work again.
  • Portable Git's README is now clearer about the need to run
post-install.bat when unpacking manually.
  • We use the winpty trick now to run ipython interactively, too.
  • When the environment variable HOME is not set, we now fall back
correctly to use HOMEDRIVE and HOMEPATH.
  • The home directory is now set correctly when running as the SYSTEM
user.
  • The environment variable GIT_WORK_TREE may now differ in lower/
upper case with the Git's idea of the current working directory.
  • Running git clone --dissociate ... no longer locks the pack files
during the repacking phase.
  • Upstream cURL fixes for NTLM proxy issues ("Unknown SSL error")
were backported.

Ciao,
Johannes
--
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.html

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

[Jeff King]

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 probe_utf8_pathname_composition(struct strbuf *path);

Wow, my patch isn't even close to reasonable. I didn't realize because
we do not compile this code at all for non-Mac platforms. Sorry.

It probably needs something like this squashed in (completely untested):

diff --git a/builtin/init-db.c b/builtin/init-db.c
index cf6a3c8..c643054 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -283,7 +283,7 @@ static int create_default_files(const char *template_path)
path = git_path_buf(, "CoNfIg");
if (!access(path, F_OK))
git_config_set("core.ignorecase", "true");
-   probe_utf8_pathname_composition(path);
+   probe_utf8_pathname_composition();
}
 
strbuf_release();
diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c
index b4dd3c7..d2d2405 100644
--- a/compat/precompose_utf8.c
+++ b/compat/precompose_utf8.c
@@ -8,6 +8,7 @@
 #include "cache.h"
 #include "utf8.h"
 #include "precompose_utf8.h"
+#include "strbuf.h"
 
 typedef char *iconv_ibp;
 static const char *repo_encoding = "UTF-8";
@@ -45,17 +46,17 @@ void probe_utf8_pathname_composition(struct strbuf *path)
if (precomposed_unicode != -1)
return; /* We found it defined in the global config, respect it 
*/
strbuf_addstr(path, auml_nfc);
-   output_fd = open(path, O_CREAT|O_EXCL|O_RDWR, 0600);
+   output_fd = open(path->buf, O_CREAT|O_EXCL|O_RDWR, 0600);
if (output_fd >= 0) {
close(output_fd);
strbuf_setlen(path, baselen);
strbuf_addstr(path, auml_nfd);
-   precomposed_unicode = access(path, R_OK) ? 0 : 1;
+   precomposed_unicode = access(path->buf, R_OK) ? 0 : 1;
git_config_set("core.precomposeunicode", precomposed_unicode ? 
"true" : "false");
strbuf_setlen(path, baselen);
strbuf_addstr(path, auml_nfc);
-   if (unlink(path))
-   die_errno(_("failed to unlink '%s'"), path);
+   if (unlink(path->buf))
+   die_errno(_("failed to unlink '%s'"), path->buf);
}
strbuf_setlen(path, baselen);
 }
diff --git a/compat/precompose_utf8.h b/compat/precompose_utf8.h
index 7fc7be5..229e772 100644
--- a/compat/precompose_utf8.h
+++ b/compat/precompose_utf8.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+struct strbuf;
 
 typedef struct dirent_prec_psx {
ino_t d_ino;/* Posix */
--
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.html

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

[Junio C Hamano]

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 code;
> + if (pp->nr_processes == pp->max_processes)
> + break;
> +
> + code = pp_start_one(pp);
> + if (!code)
> + continue;
> + if (code < 0) {
> + pp->shutdown = 1;
> + kill_children(pp, SIGTERM);
> + }
> + no_more_task = 1;
> + break;
> + }
> + }
> + if (no_more_task && !pp->nr_processes)
> + break;

I may have comments on other parts of this patch, but I noticed this
a bit hard to read while reading the end result.

Losing the outer "if (!no_more_task)" and replacing the above with

for (no_more_task = 0, i = 0;
 !no_more_task && i < spawn_cap;
 i++) {
... do things that may or may not set
... no_more_task
}
if (no_more_task && ...)
break;

would make it clear that regardless of spawn_cap, no_more_task is
honored.

Also I think that having the outer "if (!no_more_task)" and not
having "no_more_task = 0" after each iteration is buggy.  Even when
next_task() told start_one() that it does not have more tasks for
now, as long as there are running processes, it is entirely plausible
that next call to next_task() can return "now we have some more task
to do".

Although I think it would make it unsightly, if you want to have the
large indentation that protects the spawn_cap loop from getting
entered, the condition would be 

if (!pp->shutdown) {
for (... spawn_cap loop ...) {
...
}
}

That structure could make sense.  But even then I would probably
write it more like

...
int spawn_cap = 4;

pp = pp_init(...);
while (1) {
int no_more_task = 0;

for (i = 0;
 !no_more_task && !pp->shutdown && i < spawn_cap;
 i++) {
...
code = start_one();
... set no_more_task to 1 as needed
... set pp->shutdown to 1 as needed
}
if (no_more_task && !pp->nr_processes)
break;
buffer_stderr(...);
output(...);
collect(...);
}

That is, you need to have two independent conditions that tell you
not to spawn any new task:

 (1) You called start_one() repeatedly and next_task() said "nothing
 more for now", so you know calling start_one() one more time
 without changing other conditions (like draining output from
 running processes and culling finished ones) will not help.

 Letting other parts of the application that uses this scheduler
 loop (i.e. drain output, cull finished process, etc.) may
 change the situation and you _do_ need to call start_one() when
 the next_task() merely said "nothing more for now".

 That is what no_more_task controls.

 (2) The application said "I want the system to be gracefully shut
 down".  next_task() may also have said "nothing more for now"
 and you may have set no_more_task in response to it, but unlike
 (1) above, draining and culling must be done only to shut the
 system down, the application does not want new processes to be
 added.  You do not want to enter the spawn_cap loop when it
 happens.

 That is what pp->shutdown controls.

--
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.html

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

[Junio C Hamano]

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 insertions(+)

Sounds like a good idea, as you need to clean them all up if you did
push_common() and ended up not receiving any signal.

This is merely pure aesthetics, but I somehow thought that ordering
them in the reverse as listed in push_common() might make more
sense, though.

Thanks.

>
> diff --git a/sigchain.c b/sigchain.c
> index faa375d..9262307 100644
> --- a/sigchain.c
> +++ b/sigchain.c
> @@ -50,3 +50,12 @@ void sigchain_push_common(sigchain_fun f)
>   sigchain_push(SIGQUIT, f);
>   sigchain_push(SIGPIPE, f);
>  }
> +
> +void sigchain_pop_common(void)
> +{
> + sigchain_pop(SIGINT);
> + sigchain_pop(SIGHUP);
> + sigchain_pop(SIGTERM);
> + sigchain_pop(SIGQUIT);
> + sigchain_pop(SIGPIPE);
> +}
> diff --git a/sigchain.h b/sigchain.h
> index 618083b..138b20f 100644
> --- a/sigchain.h
> +++ b/sigchain.h
> @@ -7,5 +7,6 @@ int sigchain_push(int sig, sigchain_fun f);
>  int sigchain_pop(int sig);
>  
>  void sigchain_push_common(sigchain_fun f);
> +void sigchain_pop_common(void);
>  
>  #endif /* SIGCHAIN_H */
--
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.html

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

[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 test
>>
>> You can fix this with 'git rebase --edit-todo'.
>> Or you can abort the rebase with 'git rebase --abort'.
>>
>> I didn't bisect, but I guess this was introduced in the series
>> introducing this check on the todolist before starting the bisection.
>
> Indeed:
>
> 804098bb30a5339cccb0be981a3e876245aa0ae5 is the first bad commit

Yup, before that series, expand_todo_ids -> transfom_todo_ids ended
up reading each line with "while read -r command rest" loop and the
we did not honor the usual "# at the beginning line is the comment"
convention, which I think was a bug.  With that commit, a separate
step in check_bad_cmd_and_sha1 uses a similar looking "while read"
loop but forgets to take '#' into account.

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 insertion(+), 2 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f01637b..a64f77a 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -886,7 +886,6 @@ check_commit_sha () {
 # from the todolist in stdin
 check_bad_cmd_and_sha () {
retval=0
-   git stripspace --strip-comments |
(
while read -r line
do
@@ -896,7 +895,7 @@ check_bad_cmd_and_sha () {
sha1=$2
 
case $command in
-   ''|noop|x|"exec")
+   '#'*|''|noop|x|"exec")
# Doesn't expect a SHA-1
;;
pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)
--
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.html

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

[Beat Bolli]

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 changed, 29 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index 11048c7..2866777 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -4004,9 +4004,6 @@ after 1 {
$ui_comm configure -state disabled -background gray
}
 }
-if {[is_enabled multicommit] && ![is_config_false gui.gcwarning]} {
-   after 1000 hint_gc
-}
 if {[is_enabled retcode]} {
bind .  {+terminate_me %W}
 }
diff --git a/lib/database.tcl b/lib/database.tcl
index 1f187ed..808bdf6 100644
--- a/lib/database.tcl
+++ b/lib/database.tcl
@@ -87,29 +87,3 @@ proc do_fsck_objects {} {
lappend cmd --strict
console::exec $w $cmd
 }
-
-proc hint_gc {} {
-   set ndirs 1
-   set limit 8
-   if {[is_Windows]} {
-   set ndirs 4
-   set limit 1
-   }
-
-   set count [llength [glob \
-   -nocomplain \
-   -- \
-   [gitdir objects 4\[0-[expr {$ndirs-1}]\]/*]]]
-
-   if {$count >= $limit * $ndirs} {
-   set objects_current [expr {$count * 256/$ndirs}]
-   if {[ask_popup \
-   [mc "This repository currently has approximately %i 
loose objects.
-
-To maintain optimal performance it is strongly recommended that you compress 
the database.
-
-Compress the database now?" $objects_current]] eq yes} {
-   do_gc
-   }
-   }
-}
-- 
2.5.0.492.g918e48c
--
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.html

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

[Junio C Hamano]

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 insertion(+), 2 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index f01637b..a64f77a 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -886,7 +886,6 @@ check_commit_sha () {
>  # from the todolist in stdin
>  check_bad_cmd_and_sha () {
>   retval=0
> - git stripspace --strip-comments |
>   (
>   while read -r line
>   do
> @@ -896,7 +895,7 @@ check_bad_cmd_and_sha () {
>   sha1=$2
>  
>   case $command in
> - ''|noop|x|"exec")
> + '#'*|''|noop|x|"exec")
>   # Doesn't expect a SHA-1
>   ;;
>   pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)

Nah, that would not work, as I misread the "split only at SP" manual
parsing of $line.

I shouldn't be responding to the git list traffic on my vacation
day, especially before my first caffeine X-<
--
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.html

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

[Ralf Thielow]

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 test
>>>
>>> You can fix this with 'git rebase --edit-todo'.
>>> Or you can abort the rebase with 'git rebase --abort'.
>>>
>>> I didn't bisect, but I guess this was introduced in the series
>>> introducing this check on the todolist before starting the bisection.
>>
>> Indeed:
>>
>> 804098bb30a5339cccb0be981a3e876245aa0ae5 is the first bad commit
>
> Yup, before that series, expand_todo_ids -> transfom_todo_ids ended
> up reading each line with "while read -r command rest" loop and the
> we did not honor the usual "# at the beginning line is the comment"
> convention, which I think was a bug.  With that commit, a separate
> step in check_bad_cmd_and_sha1 uses a similar looking "while read"
> loop but forgets to take '#' into account.
>
> 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 insertion(+), 2 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index f01637b..a64f77a 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -886,7 +886,6 @@ check_commit_sha () {
>  # from the todolist in stdin
>  check_bad_cmd_and_sha () {
> retval=0
> -   git stripspace --strip-comments |
> (
> while read -r line
> do
> @@ -896,7 +895,7 @@ check_bad_cmd_and_sha () {
> sha1=$2
>
> case $command in
> -   ''|noop|x|"exec")
> +   '#'*|''|noop|x|"exec")

If so, I think we should use "$comment_char"* here.

> # Doesn't expect a SHA-1
> ;;
> pick|p|drop|d|reword|r|edit|e|squash|s|fixup|f)
> --
> 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.html
--
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.html

Re: Why not git reset --hard ?

[Philip Oakley]

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 fundamentally wrong for wishing for
"reset --hard ".  It probably is just that nobody needed
it, because "git checkout HEAD " is a 99% acceptable
substitute for it (the only case where it makes a difference is when
you added a path to the index that did not exist in HEAD).



Personally, I would like to see this simply given the number of times
that I use git reset --hard  and then realize I should have used
git checkout instead. I conceptually think reset --hard should do
that, and that checkout is really not meant to do that as a concept.

I may have some time to try and give this a look in the next few days...

Regards,
Jake
--


I also recently had this problem of expecting to be able to use something 
like `git reset --hard -- ` to clear up some crud and having to cast 
around for the right approach.


Would it at least be worth flagging up the alternate ` git checkout  --  
path` a little better within the 'get reset' man pages? At the moment its 
hidden at the end of the git reset [-q] [] [--] …​ section, 
so is easily missed.


(i.e. should I flesh out a patch, or would the nuances bury it...?)

Philip

--
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.html