Brandon Williams writes:
> Of course, I usually try to clear the parts of the mail I'm not
> responding to...though there are times where I forget or am a bit lazy.
> I'll definitely work on remembering to do that for the future!
This cuts both ways. Sometimes it is very
On 03/08, Johannes Schindelin wrote:
> I did take a quick glance, but did you have a look at the time of day I
> sent this patch? You do not want to trust my judgement after that.
Haha Yeah I did notice, and I trust your newer patch more than the one
you sent at 2am :)
>
> Another thing: may I
Johannes Schindelin writes:
> Rather than a heavy-handed reversal, I would really prefer to perform a
> diligent audit of all real_pathdup() callers and adjust them
> appropriately.
>
> Turns out that the canonicalize_ceiling_entry() caller is *the only one*
>
Hi Junio,
On Tue, 7 Mar 2017, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > OK, so it appears that we'd better audit all the callsites of
> > real_pathdup() and see if anybody _assumes_ that the return values are
> > not NULL. They all need fixing.
Indeed.
> I just
Hi valtron,
On Tue, 7 Mar 2017, valtron wrote:
> I only ran into this because of git-gui, where I eventually tracked it
> down to line 1330:
>
> set env(GIT_WORK_TREE) $_gitworktree
As git-gui is a Tcl script, which in turn runs as a pure Windows
application, the path should use
Hi Brandon,
On Tue, 7 Mar 2017, Brandon Williams wrote:
> On 03/08, Johannes Schindelin wrote:
> >
> > [...] On *Linux*, this happens:
> >
> > $ GIT_WORK_TREE=c:/invalid git rev-parse HEAD
> > Segmentation fault (core dumped)
> >
> > The reason is this: when set_git_work_tree() was
Johannes Schindelin writes:
> The problem is actually even worse: On *Linux*, this happens:
>
> $ GIT_WORK_TREE=c:/invalid git rev-parse HEAD
> Segmentation fault (core dumped)
>
> The reason is this: when set_git_work_tree() was converted from using
>
On 03/08, Johannes Schindelin wrote:
> Hi valtron,
>
> On Wed, 8 Mar 2017, Johannes Schindelin wrote:
>
> > On Tue, 7 Mar 2017, valtron wrote:
> >
> > > When GIT_WORK_TREE contains a drive-letter and forward-slashes, some git
> > > commands crash:
> > >
> > > C:\repo>set GIT_WORK_TREE=C:/repo
Hi valtron,
On Wed, 8 Mar 2017, Johannes Schindelin wrote:
> On Tue, 7 Mar 2017, valtron wrote:
>
> > When GIT_WORK_TREE contains a drive-letter and forward-slashes, some git
> > commands crash:
> >
> > C:\repo>set GIT_WORK_TREE=C:/repo
> > C:\repo>git rev-parse HEAD
> > 1 [main] git 2332
Hi valtron,
just to set the record straight on a few of my suggestions that turned out
to be incorrect:
On Wed, 8 Mar 2017, Johannes Schindelin wrote:
> On Tue, 7 Mar 2017, valtron wrote:
>
> > Stacktrace from GDB (on git-rev-parse) is:
> >
> > #0 0x00018019634d in strcmp (s1=0x600062080
Hi Johannes,
Thanks for looking at this! Yes, it's 2.12.0, sorry for the typo.
I only ran into this because of git-gui, where I eventually tracked it
down to line 1330:
set env(GIT_WORK_TREE) $_gitworktree
With that line commented out, it works. I'll look into why git-gui
sets it to a
Hi valtron,
On Tue, 7 Mar 2017, valtron wrote:
> Git 1.12.0.
I take it you meant 2.12.0. And you probably also meant to imply that you
are referring to MSYS2's git.exe in /usr/bin/.
> When GIT_WORK_TREE contains a drive-letter and forward-slashes, some git
> commands crash:
>
> C:\repo>set
Git 1.12.0. When GIT_WORK_TREE contains a drive-letter and
forward-slashes, some git commands crash:
C:\repo>set GIT_WORK_TREE=C:/repo
C:\repo>git rev-parse HEAD
1 [main] git 2332 cygwin_exception::open_stackdumpfile: Dumping
stack trace to git.exe.stackdump
C:\repo>set GIT_WORK_TREE=
13 matches
Mail list logo