Re: [msysGit] [PATCH 12/14] Fix pointer -> integer casts on IL32P64 systems

On Mon, Sep 29, 2014 at 10:43:41PM +0200, Johannes Sixt wrote: > Am 28.09.2014 um 15:24 schrieb Marat Radchenko: > > This commit touches regcomp.c and poll.c from Gnulib, > > both were fixed upstream in 2012 the same way. > > > > Wrt ShellExecute, see [1]. > > > > [1]: http://blogs.msdn.com/b/old

Strange behavior of git rev-list --first-parent --ancesty-path

Hello! Imagine following tree: A--B--C \ / D--E B is parent #1 of C. git rev-list --first-parent --ancestry-path D..C returns zero commits. This is correct, since one cannot find any commits between D and C traversing tree by first parent. git rev-list --first-parent --ancestry-path E..C

What's cooking in git.git (Sep 2014, #08; Mon, 29)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-publi

Re: [PATCH v3 1/3] doc: modernise everyday.txt wording and format in man page style

Philip Oakley writes: > @@ -45,7 +58,7 @@ following commands. > >* linkgit:git-rebase[1] to maintain topic branches. > > - * linkgit:git-tag[1] to mark known point. > + * linkgit:git-tag[1] to mark a known point. I really appreciate your attention to details here. > +<10> review commi

Re: [BUG] (git commit --patch --message $MESSAGE) disallows hunk editing

Max Nanasy gmail.com> writes: > > Tested against v1.7.12.4 > > Steps to reproduce: > A. cd $DIRTY_WORKING_COPY > B. git commit --patch --message $MESSAGE > C. Stage this hunk? e > Expected behavior: > After step C, the hunk opens in the user's editor > Actual behavior: >

Git for Windows 1.9.4.msysgit.2

Hi, the Git for Windows team just released the third maintenance release of the Windows-specific installers for git 1.9.4. It can be downloaded from the usual place [1] and I also attached some unsigned SHA sums [2]. New Features - Comes with Git 1.9.4 plus Windows-specific patches. Bugfixes -

Re: `git log relative_path_to_object` does not respect the --work-tree path

Hi Roberto, Roberto Eduardo Decurnex Gorosito wrote: > When passing objects to the `git log`, by just naming them or using > the `--objects` option, relative paths are evaluated using the current > working directory instead of the current working tree path. Why should they be relative to the wor

Re: [msysGit] [PATCH 12/14] Fix pointer -> integer casts on IL32P64 systems

Am 28.09.2014 um 15:24 schrieb Marat Radchenko: > This commit touches regcomp.c and poll.c from Gnulib, > both were fixed upstream in 2012 the same way. > > Wrt ShellExecute, see [1]. > > [1]: http://blogs.msdn.com/b/oldnewthing/archive/2006/11/08/1035971.aspx Please do not force readers to visi

Re: [PATCH] Do not make trace.c/getnanotime an inlined function

Am 28.09.2014 um 22:42 schrieb Ben Walton: > On Sun, Sep 28, 2014 at 8:15 PM, Johannes Sixt > wrote: > Am 28.09.2014 um 09:50 schrieb Ben Walton: > > -inline uint64_t getnanotime(void) > > +uint64_t getnanotime(void) > > But then the function could stay stati

Re: [PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION.

Junio C Hamano writes: > Sergey Organov writes: > [...] >> As asked by Junio C Hamano , the newly introduced >> 'fork_point' term has been described. >> > > I suspect "will be used as a fallback" might be easier to understand > what is going on instead of "will be used instead", but other than

Will you come?? urgent, we must know

Dear Invited Authors After my previous email, we want to clarify some things: 1) Invited Authors represent only a 3-5% of our authors, see for example the papers with Italics here: http://www.wseas.org/main/conferences/2014/Salerno/Program.pdf ) 2) Invited Authors are selected very carefully

Re: `git log relative_path_to_object` does not respect the --work-tree path

Sorry, I left the --git-dir out of the example. I do set the --git-dir (and $GIT_DIR sometimes) too. It gives the same results. That's why I feels like it shouldn't be working as it is. In this specific case (log with object filter) the environment config is completely ignored. On Mon, Sep 29, 2

Re: `git log relative_path_to_object` does not respect the --work-tree path

Roberto Eduardo Decurnex Gorosito writes: > ~/path$ git --work-tree=~/path/to_repo log README.md This does not seem to specify GIT_DIR explicitly (either with the $GIT_DIR environment variable or the --git-dir option), so I would assume that you are sitting in a directory that has ".git/" subdir

Re: [PATCH] Ensure SHELL_PATH is the hash bang for test suite askpass helper script.

Ben Walton writes: > The askpass script that is created for use by the test suite should > use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024 > introduced the use of idioms not supported in some legacy /bin/sh > implementations. > > Use write_script to ensure this happens autom

Re: [PATCH] Do not make trace.c/getnanotime an inlined function

Duy Nguyen writes: > On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton wrote: >> Oracle Studio compilers don't allow for static variables in functions >> that are defined to be inline. GNU C does permit this. Let's reference >> the C99 standard though, which doesn't allow for inline functions to >> co

Re: [PATCH] Ensure SHELL_PATH is the hash bang for test suite askpass helper script.

On Mon, Sep 29, 2014 at 08:02:07AM +0100, Ben Walton wrote: > The askpass script that is created for use by the test suite should > use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024 > introduced the use of idioms not supported in some legacy /bin/sh > implementations. > > Use

[PATCH v3 3/3] Make 'git help everyday' work

The "Everyday GIT With 20 Commands Or So" is not accessible via the Git help system. Move everyday.txt to giteveryday.txt so that "git help everyday" works, and create a new placeholder file everyday.html to refer people who follow existing URLs to the updated location. giteveryday.txt now format

[PATCH v3 0/3] Make 'git help everyday' work

Here's version three of my patches to make 'git help everyday' work. It's taken awhile. Previous patches at [1] and [2]. Junio has provided guidance on modernisation of the text, which has been integrated into patch 1. Patch 2 regularises the OBSOLETE_HTML method in the make file, in line with t

[PATCH v3 2/3] doc: Makefile regularise OBSOLETE_HTML list building

Helped-by: Junio C Hamano Signed-off-by: Philip Oakley --- Documentation/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index cea0e7a..3b56714 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -5,6

[PATCH v3 1/3] doc: modernise everyday.txt wording and format in man page style

Refresh the contents of everyday.txt contents to a more modern command style. Also update the mark-up so that it can be formatted as a man page with AsciiDoc ready for transfer to the Git guides. The transfer is in subsequent commits. Guidance on modernising the command style provided by Junio at

`git log relative_path_to_object` does not respect the --work-tree path

When passing objects to the `git log`, by just naming them or using the `--objects` option, relative paths are evaluated using the current working directory instead of the current working tree path. Even the error message is clearly wrong. "unknown revision or path not in the working tree." E

Re: [PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION.

Sergey Organov writes: > Vanilla "git rebase" defaults to --fork-point that in some cases > makes behavior very different from "git rebase ", > where --no-fork-point is assumed. This fact was not mentioned in > the DESCRIPTION section of the manual page, even though the case of > omitted was oth

Re: [PATCH] Do not make trace.c/getnanotime an inlined function

On Sun, Sep 28, 2014 at 2:50 PM, Ben Walton wrote: > Oracle Studio compilers don't allow for static variables in functions > that are defined to be inline. GNU C does permit this. Let's reference > the C99 standard though, which doesn't allow for inline functions to > contain modifiable static var

Re: Code changes in merge commits

On Mon, Sep 29, 2014 at 5:59 PM, Matthieu Moy wrote: >> Ideally I'd like to see all the code changes to a code base just with >> "git log -p". > > What I'd love to see with "git log -p" is the diff between a trivial > merge (possibly including conflict markers) and the actual merge commit. > That

[PATCH v2] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION.

Vanilla "git rebase" defaults to --fork-point that in some cases makes behavior very different from "git rebase ", where --no-fork-point is assumed. This fact was not mentioned in the DESCRIPTION section of the manual page, even though the case of omitted was otherwise discussed. That in turn made

Re: Code changes in merge commits

> What I'd love to see with "git log -p" is the diff between a trivial > merge (possibly including conflict markers) and the actual merge commit. > That would imply that "git log" would redo the merge before computing > the diff (rather heavyweight :-( ), but an empty diff would mean "no > change o

Re: Code changes in merge commits

John Tapsell writes: > What if merge commits were forced into being always trivial? It would be relatively easy to "force" a client to always have trivial merges, but much harder to prevent an attacker to forge a non-trivial merge commit (e.g. modifying his local git command) and push it. > Ide

Re: [PATCH] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla "git rebase" in DESCRIPTION.

Junio C Hamano writes: > Sergey Organov writes: > >> I think you meant to say that we may find a better source to calculate >> the exact set of commits to rebase,... > > Yes. > >>> It is debatable if we should do the same when the user tells us to >>> rebase with respect to a specific _branch_ b

Re: Code changes in merge commits

Rereading what I wrote, I came across as unintentionally harsh and rude. Sorry about that - I was trying to be concise and terse, and it went a bit wrong :) What I was thinking to improve this is two short-term fixes: 1. Can we get git log -m -p . in the top level directory to show the sa

Code changes in merge commits

Hi, Our team just struggled with this problem, and I've created a simple, 3 commit large, example git repository to demonstrate the problem: https://github.com/johnflux/ExampleEvilness2 The code: Adds a file, adds a security fix commit, then removes the fix during a merge. This happened by

[PATCH] Ensure SHELL_PATH is the hash bang for test suite askpass helper script.

The askpass script that is created for use by the test suite should use SHELL_PATH for its hash bang instead of /bin/sh. Commit 5a4352024 introduced the use of idioms not supported in some legacy /bin/sh implementations. Use write_script to ensure this happens automatically. This lets us remove th