From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:06
Here is an update to the list I sent earlier. Topics that I
thought may deserve attention, discussion and eventual inclusion
but are not 1.5.4 material.
I think some of them actually have a slight chance of being
1.5.4 material, if interested parties present good enough
arguments that they are actually good and safe bugfixes.
* compress/decompress abstraction (Marco)
* crlf (Steffen Prohaska and Dmitry Potapov)
* whitespace error: "cr at eol is ok" (me)
* moving archive related helpers to libgit.a (Lars Hjemli)
* marking output from "diff --{no,src,dst}-prefix" as a non-git
diff (me)
* submodule subcommand parser fix for "git submodule add init
update" (Imran M Yousuf and me)
* submodule recursive wrapper (Imran M Yousuf)
* 'origin' is not so special after "clone -o frotz" (Mark Levedahl)
* "submodule summary" (Ping Yin)
* unconfigured ident safety (Stephen Sinclair)
* gitweb feed from commit to commitdiff (Florian La Rouche --
Jakub seems to be on top of this so I am not worried about it
too much).
* color.ui (Matthias Kestenholz)
* test scripts to use valgrind (Jeff King)
* various lstat(2) reduction changes (me).
* "rebase -i" UI -- should it be simplified to do commit --amend
itself? (Dscho)
* "cherry-pick/revert" error message fix (Björn Steinbrink and me)
* pathname safety on filesystems whose readdir(3) thinks it
knows better than users (Linus, Robin Rosenberg, me and
others).
Again, I am hoping that authors will resend the ones they really
care about after 1.5.4, as I do not want to take patches early.
From: Johannes Sixt <hidden> Date: 2016-06-15 22:44:06
Junio C Hamano schrieb:
Here is an update to the list I sent earlier. Topics that I
thought may deserve attention, discussion and eventual inclusion
but are not 1.5.4 material.
BTW, how would you like to have a 40+ patch series presented that
implements the port to MinGW? Should I send to the ML despite its volume?
(Of course not before 1.5.4 is released.)
The current state of the series is available here:
http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream
-- Hannes
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:06
Junio C Hamano [off-list ref] writes:
Here is an update to the list I sent earlier. Topics that I
thought may deserve attention, discussion and eventual inclusion
but are not 1.5.4 material.
I think some of them actually have a slight chance of being
1.5.4 material, if interested parties present good enough
arguments that they are actually good and safe bugfixes.
* submodule subcommand parser fix for "git submodule add init
update" (Imran M Yousuf and me)
Isn't it a bugfix, and shouldn't it for this reason be in 1.5.4?
* gitweb feed from commit to commitdiff (Florian La Rouche --
Jakub seems to be on top of this so I am not worried about it
too much).
What need IMHO to be changed is commit message: state stronger
that the only thing that changed is that feed entry refers now
to 'commitdiff' view rather than 'commit' view. I can agree that
it might be better... but I do not use gitweb feeds myself.
Reasonably post 1.5.4
Again, I am hoping that authors will resend the ones they really
care about after 1.5.4, as I do not want to take patches early.
From: Marco Costalba <hidden> Date: 2016-06-15 22:44:06
On Jan 18, 2008 11:40 AM, Junio C Hamano [off-list ref] wrote:
I think some of them actually have a slight chance of being
1.5.4 material, if interested parties present good enough
arguments that they are actually good and safe bugfixes.
* compress/decompress abstraction (Marco)
I have good enough arguments to NOT include it in 1.5.4: it's a
cleanup, so it's developer oriented, not user oriented, no
performance/feature benefit, no bug fix.
Please apply only after 1.5.4 is out.
Thanks
Marco
On Jan 18, 2008, at 11:40 AM, Junio C Hamano wrote:
Here is an update to the list I sent earlier. Topics that I
thought may deserve attention, discussion and eventual inclusion
but are not 1.5.4 material.
I think some of them actually have a slight chance of being
1.5.4 material, if interested parties present good enough
arguments that they are actually good and safe bugfixes.
[...]
* crlf (Steffen Prohaska and Dmitry Potapov)
I am working on an alternative to the patch I sent last week.
I hope I can present the two approaches soon.
The first approach is a lazy check in crlf_to_git() that warns
about an irreversible conversion; or dies if safecrlf=true. This
is relatively simple code but at least for git-add a workaround
is needed to suppress printing a warning twice. The runtime
overhead is negligible.
The second approach adds a new machinery is_worktree_crlfsafe()
that could be run independently of the crlf_to_git() conversion.
The code doing the conversion would stay unmodified. The
advantage is that the whole work tree could be verified before
any conversion actually happens and we could die() after printing
all the warnings instead of printing only the first one. The
drawback is that this approach most likely needs more code and
will introduce runtime overhead. A straight forward
implementation would add another pass over the work tree running
the stats in convert.c. So the stats would be run twice.
And for a simple "git add <file>" the situation is even worse:
the full work tree would be verified even is only a single file
is to be added.
I haven't found time during the week, so I'll continue to work
on this over the weekend. Maybe even more time is needed to
discuss the two alternatives.
I do not expect that this topic will be ready for 1.5.4.
Steffen
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:06
Hi,
On Fri, 18 Jan 2008, Steffen Prohaska wrote:
On Jan 18, 2008, at 11:40 AM, Junio C Hamano wrote:
quoted
* crlf (Steffen Prohaska and Dmitry Potapov)
I am working on an alternative to the patch I sent last week. I hope I
can present the two approaches soon.
The first approach is a lazy check in crlf_to_git() that warns about an
irreversible conversion; or dies if safecrlf=true. This is relatively
simple code but at least for git-add a workaround is needed to suppress
printing a warning twice. The runtime overhead is negligible.
The second approach adds a new machinery is_worktree_crlfsafe()
that could be run independently of the crlf_to_git() conversion.
From the sound of it, I like the first approach much better.
I do not expect that this topic will be ready for 1.5.4.
What with our ongoing discussion when to go out of preview phase for
msysGit, I think this makes sense.
Ciao,
Dscho
On Jan 18, 2008, at 2:09 PM, Johannes Schindelin wrote:
On Fri, 18 Jan 2008, Steffen Prohaska wrote:
quoted
On Jan 18, 2008, at 11:40 AM, Junio C Hamano wrote:
quoted
* crlf (Steffen Prohaska and Dmitry Potapov)
I am working on an alternative to the patch I sent last week. I
hope I
can present the two approaches soon.
The first approach is a lazy check in crlf_to_git() that warns
about an
irreversible conversion; or dies if safecrlf=true. This is
relatively
simple code but at least for git-add a workaround is needed to
suppress
printing a warning twice. The runtime overhead is negligible.
The second approach adds a new machinery is_worktree_crlfsafe()
that could be run independently of the crlf_to_git() conversion.
From the sound of it, I like the first approach much better.
Ok. I'll start with cleaning up the first approach tomorrow and
send resend the patch.
quoted
I do not expect that this topic will be ready for 1.5.4.
What with our ongoing discussion when to go out of preview phase for
msysGit, I think this makes sense.
I'll work on creating an improved installer that installs only a
subset of the commands. I'll exclude commands that are not yet
ready for Windows (e.g. git-svn, ...).
After we have the first version of this installer we can further
discuss if we leave the preview phase.
Steffen
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:06
Hi,
On Fri, 18 Jan 2008, Johannes Sixt wrote:
Junio C Hamano schrieb:
quoted
Here is an update to the list I sent earlier. Topics that I
thought may deserve attention, discussion and eventual inclusion
but are not 1.5.4 material.
BTW, how would you like to have a 40+ patch series presented that
implements the port to MinGW? Should I send to the ML despite its volume?
(Of course not before 1.5.4 is released.)
The current state of the series is available here:
http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream
Comments from reading the patches briefly (since there are 42 patches, it
needs quite some time to even do it briefly):
- Possibly some of these commits could be folded back into
f90524e(Add target architecture MinGW):
96a27f1(MinGW: Implement gettimeofday()),
2e05f891(Implement a rudimentary poll() emulation for Windows),
142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for
Windows),
e799caf(Implement setitimer() and sigaction()),
075fee7(Implement a wrapper of execve that can invoke shell scripts),
495f0af(Work around misbehaved rename() on Windows),
34cf7fd(Implement a pipe() replacement whose ends are not inherited to
children),
4504323(Implement start_command() for Windows),
b8e84a6(Implement a work-around for a misbehaved vsnprintf on Windows),
08bbcb4(Windows: always chmod(, 0666) before unlink()),
f6bbf12(Windows: Implement a wrapper of the open() function),
56cedf3(Windows: Fix PRIuMAX definition),
7458a97(Windows: Implement wrappers for gethostbyname(), socket(), and
connect()),
ef25947(Windows: Fix ntohl() related warnings about printf formatting),
b9db7ad(Windows: Implement a custom spawnve()), and
47dacb3(compat/pread.c: Add foward decl to fix warning)
- 142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for
Windows)
does not really implement getuid() and getpwnam(), and does not "fake"
the implementation of getpwuid() either, but has a minimal
implementation of it (affecting the other two functions, of course).
- d6596ed(gitk: Disable msgfmt on MinGW) and
004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a
.gitk)
are gitk patches.
Further, I think that d6596ed would be better done as an automatic
detection of msgfmt's presence; on my Eee PC, there is no msgfmt
either...
- 20fd16e(Windows: Use a customized struct stat that also has the
st_blocks member) should be folded into
6f97065(Add a new lstat and fstat implementation based on Win32 API)
(with a comment that you customized the struct stat, too)
But then, without 20fd16e, git does not compile, so again I would rather
fold that back into the MinGW commit.
- I would group the following path related commits:
f15879a(MSYS: local clone must use the drive letter in absolute paths),
788324d(Handle Windows style absolute paths in
safe_create_leading_directories( )),
851d28d(Treat Windows style path names),
8b9ce70(On Windows use the Windows style PATH separator in add_path()),
8811d9c(On Windows strip ".exe" from the program name),
af7a879(Windows: Disambiguate DOS style paths from SSH URLs),
71911a8(Windows: TMP and TEMP environment variables specify a temporary
directory),
ea035ed(Turn builtin_exec_path into a function.)
4e7e438(Compute the ultimate fallback for exec_path from the program
invocation),
abd87b3(Windows: Use a relative default template_dir and ETC_GITCONFIG),
7162bf5(When installing, be prepared that template_dir may be relative).
The latter two probably want to be merged, too.
- in git.git, the onelines are not terminated by "."
- in f6bbf12(Windows: Implement a wrapper of the open() function) there is
a typo: "on^".
- 47dacb3(compat/pread.c: Add foward decl to fix warning) has a typo:
"foward".
- The SOB line does not come last in 075fee7(Implement a wrapper of execve
that can invoke shell scripts.)
- I'd prefer f90524e(Add target architecture MinGW) to come last.
Alternatively, you could cut out the Makefile change so that the series
is still bisectable: MinGW will just not be supported until the very
end.
Implementation-wise I could not go into too much depth, naturally, but one
thing still struck me as odd:
$ git grep __MINGW j6t/upstream
comes up with 26 hits.
The first of them: cache.h:381, function is_absolute_path(). That just
cries out loud to be "#ifdef DOS_STYLE_PATHS" instead of "#ifdef
__MINGW32__".
I guess there should also be -DHAS_NO_FORK_BUT_THREADS -DHAS_TMP_AND_TEMP
-DHAS_WINSOCK2, but most of them look like -DDOS_STYLE_PATHS to me.
Uff. That were quite some things to wade through, and it's only to get
worse when I start for real ;-)
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:06
Hi,
On Fri, 18 Jan 2008, Johannes Schindelin wrote:
- d6596ed(gitk: Disable msgfmt on MinGW) and
004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a
.gitk)
are gitk patches.
Further, I think that d6596ed would be better done as an automatic
detection of msgfmt's presence; on my Eee PC, there is no msgfmt
either...
IOW I think something like this:
-- snipsnap --
[PATCH] Fall back to po2msg when msgfmt is unavailable
At least on my Eee PC I do not have msgfmt.
This should be split into two patches, one for git-gui and one for gitk.
---
git-gui/Makefile | 6 ++++--
gitk-git/Makefile | 7 +++++--
2 files changed, 9 insertions(+), 4 deletions(-)
From: Johannes Sixt <hidden> Date: 2016-06-15 22:44:06
[Don't have Cc: in KNode. oh well...]
Johannes Schindelin wrote:
On Fri, 18 Jan 2008, Johannes Sixt wrote:
quoted
BTW, how would you like to have a 40+ patch series presented that
implements the port to MinGW? Should I send to the ML despite its volume?
(Of course not before 1.5.4 is released.)
The current state of the series is available here:
http://repo.or.cz/w/git/mingw/j6t.git?a=shortlog;h=upstream
Comments from reading the patches briefly (since there are 42 patches, it
needs quite some time to even do it briefly):
Thanks a lot!
I agree with everything I didn't quote from your message.
- Possibly some of these commits could be folded back into
f90524e(Add target architecture MinGW):
96a27f1(MinGW: Implement gettimeofday()),
2e05f891(Implement a rudimentary poll() emulation for Windows),
142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for
Windows),
e799caf(Implement setitimer() and sigaction()),
075fee7(Implement a wrapper of execve that can invoke shell scripts),
495f0af(Work around misbehaved rename() on Windows),
34cf7fd(Implement a pipe() replacement whose ends are not inherited to
children),
4504323(Implement start_command() for Windows),
b8e84a6(Implement a work-around for a misbehaved vsnprintf on Windows),
08bbcb4(Windows: always chmod(, 0666) before unlink()),
f6bbf12(Windows: Implement a wrapper of the open() function),
56cedf3(Windows: Fix PRIuMAX definition),
7458a97(Windows: Implement wrappers for gethostbyname(), socket(), and
connect()),
ef25947(Windows: Fix ntohl() related warnings about printf formatting),
b9db7ad(Windows: Implement a custom spawnve()), and
47dacb3(compat/pread.c: Add foward decl to fix warning)
This would become a gigantic patch, which I really dislike. It's much easier
to follow (and bisect) if things appear in smaller pieces.
- d6596ed(gitk: Disable msgfmt on MinGW) and
004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a
.gitk)
are gitk patches.
Further, I think that d6596ed would be better done as an automatic
detection of msgfmt's presence; on my Eee PC, there is no msgfmt
either...
Let's do that later.
- 20fd16e(Windows: Use a customized struct stat that also has the
st_blocks member) should be folded into
6f97065(Add a new lstat and fstat implementation based on Win32 API)
(with a comment that you customized the struct stat, too)
But then, without 20fd16e, git does not compile, so again I would rather
fold that back into the MinGW commit.
The custom lstat() implementation cannot come after the custom struct stat
because we can't call Windows's stat() with a custom struct stat. But I
also don't want the custom lstat() in the code from the beginning because
it's merely an optimization.
- in git.git, the onelines are not terminated by "."
You mean commit messages?
- I'd prefer f90524e(Add target architecture MinGW) to come last.
Alternatively, you could cut out the Makefile change so that the series
is still bisectable: MinGW will just not be supported until the very
end.
I strongly disagree. The series is completely bisectable on *nix. But if the
Makefile change comes last, it becomes difficult to bisect on MinGW.
$ git grep __MINGW j6t/upstream
comes up with 26 hits.
The first of them: cache.h:381, function is_absolute_path(). That just
cries out loud to be "#ifdef DOS_STYLE_PATHS" instead of "#ifdef
__MINGW32__".
I guess there should also be -DHAS_NO_FORK_BUT_THREADS -DHAS_TMP_AND_TEMP
-DHAS_WINSOCK2, but most of them look like -DDOS_STYLE_PATHS to me.
Doesn't this go too far? How many systems are there where not all of them
would be set at the same time?
-- Hannes
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:06
Hi,
On Fri, 18 Jan 2008, Johannes Sixt wrote:
Johannes Schindelin wrote:
quoted
- Possibly some of these commits could be folded back into
f90524e(Add target architecture MinGW):
96a27f1(MinGW: Implement gettimeofday()),
2e05f891(Implement a rudimentary poll() emulation for Windows),
142bda0(Fake implementions of getpwuid(), getuid(), and getpwnam() for
Windows),
e799caf(Implement setitimer() and sigaction()),
075fee7(Implement a wrapper of execve that can invoke shell scripts),
495f0af(Work around misbehaved rename() on Windows),
34cf7fd(Implement a pipe() replacement whose ends are not inherited to
children),
4504323(Implement start_command() for Windows),
b8e84a6(Implement a work-around for a misbehaved vsnprintf on Windows),
08bbcb4(Windows: always chmod(, 0666) before unlink()),
f6bbf12(Windows: Implement a wrapper of the open() function),
56cedf3(Windows: Fix PRIuMAX definition),
7458a97(Windows: Implement wrappers for gethostbyname(), socket(), and
connect()),
ef25947(Windows: Fix ntohl() related warnings about printf formatting),
b9db7ad(Windows: Implement a custom spawnve()), and
47dacb3(compat/pread.c: Add foward decl to fix warning)
This would become a gigantic patch, which I really dislike. It's much
easier to follow (and bisect) if things appear in smaller pieces.
Yes, probably. (See below for the bisection.)
quoted
- d6596ed(gitk: Disable msgfmt on MinGW) and
004fb4b(Fix renaming .gitk-new to .gitk on Windows if there is already a
.gitk)
are gitk patches.
Further, I think that d6596ed would be better done as an automatic
detection of msgfmt's presence; on my Eee PC, there is no msgfmt
either...
Let's do that later.
I think these are more or less independent of the rest.
quoted
- 20fd16e(Windows: Use a customized struct stat that also has the
st_blocks member) should be folded into
6f97065(Add a new lstat and fstat implementation based on Win32 API)
(with a comment that you customized the struct stat, too)
But then, without 20fd16e, git does not compile, so again I would rather
fold that back into the MinGW commit.
The custom lstat() implementation cannot come after the custom struct
stat because we can't call Windows's stat() with a custom struct stat.
But I also don't want the custom lstat() in the code from the beginning
because it's merely an optimization.
Okay.
quoted
- in git.git, the onelines are not terminated by "."
You mean commit messages?
I meant the subjects of the commit messages. I.e. "Add target
architecture MinGW.". But that's such a minor issue.
quoted
- I'd prefer f90524e(Add target architecture MinGW) to come last.
Alternatively, you could cut out the Makefile change so that the series
is still bisectable: MinGW will just not be supported until the very
end.
I strongly disagree. The series is completely bisectable on *nix. But if
the Makefile change comes last, it becomes difficult to bisect on MinGW.
Hmm. You're right, of course, for *nix.
But for MinGW I am not really sure, as you do not really get a
fully functional system prior to all of the 42 patches...
I am really torn on this, because I can understand your point of view.
But when there would be an issue with MinGW, and I wanted to find out if
it worked _at all_, it would be nice to have an easily determined commit
where MinGW was supposed to be fully functional first, without a private
tag or something.
Reading again what I wrote it appears that my opinion on that was strong;
it is not. I am not quite sure what would be best. (In the end, I will
always have the option to not care and let it be Junio's problem ;-)
quoted
$ git grep __MINGW j6t/upstream
comes up with 26 hits.
The first of them: cache.h:381, function is_absolute_path(). That just
cries out loud to be "#ifdef DOS_STYLE_PATHS" instead of "#ifdef
__MINGW32__".
I guess there should also be -DHAS_NO_FORK_BUT_THREADS
-DHAS_TMP_AND_TEMP -DHAS_WINSOCK2, but most of them look like
-DDOS_STYLE_PATHS to me.
Doesn't this go too far? How many systems are there where not all of
them would be set at the same time?
I am not only thinking about other systems... it is also a pretty nice way
of documenting _why_ this change was made. With the possible exception of
HAS_TMP_AND_TEMP, I really would like to see that. So much so that I
hereby offer to do the transform myself.
Ciao,
Dscho
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:07
Here is an update to the list I sent earlier.
Topics that I thought may deserve attention, discussion and
eventual inclusion but are not 1.5.4 material.
I think these two could be part of 1.5.4, but I left them out of
1.5.4-rc4 (IOW, I do not think they should be on this list):
* marking output from "diff --{no,src,dst}-prefix" as a non-git
diff (me)
Linus had an objection but I think I made a reasonable
argument against that. Haven't heard back since then, so
this is in limbo.
* submodule subcommand parser fix for "git submodule add init
update" (Imran M Yousuf and me)
As Jakub noticed, this is meant to be a bugfix but as I do
not use submodule heavily myself, backing it with real-world
success stories would be needed.
Now these two out of our way, here is the list.
* various lstat(2) reduction changes (me, Linus and Dscho).
This will be queued in 'pu'; it appears this introduces a
timing related breakages in t75?? tests.
* compress/decompress abstraction (Marco)
* crlf (Steffen Prohaska and Dmitry Potapov)
* whitespace error: "cr at eol is ok" (me)
* submodule recursive wrapper (Imran M Yousuf)
* 'origin' is not so special after "clone -o frotz" (Mark Levedahl)
* "submodule summary" (Ping Yin)
* unconfigured ident safety (Stephen Sinclair)
* gitweb feed from commit to commitdiff (Florian La Rouche --
Jakub seems to be on top of this so I am not worried about it
too much).
* color.ui (Matthias Kestenholz)
* test scripts to use valgrind (Jeff King)
* "rebase -i" UI -- should it be simplified to do commit --amend
itself? (Dscho)
* "cherry-pick/revert" error message fix (Björn Steinbrink and me)
* pathname safety on filesystems whose readdir(3) thinks it
knows better than users (Linus, Robin Rosenberg, me and
others).
I tend to prefer a much simpler approach Linus suggested, to
wrap readdir(3) on systems that are known to mangle files,
but I have a slight suspicion it would not work well enough
for cross platform projects.
Again, I am hoping that authors will resend the ones they really
care about after 1.5.4, as I do not want to take patches early.
The previous version of this list did not include the some that
were discussed and landed in 'pu' (or 'offcuts'). The ones that
we may want to polish that are in 'pu' are:
* omit cc recipients from send-email (David Brown)
* sha1 lookup optimization (me)
* rewrite cherry-pick/revert in order to improve its D/F
conflict resolution (me)
* allow native protocol to tell exactly which branch HEAD
points at (me)
There is also 1.6.0 material queued already, way before the rc
cycle:
* Moving "git-foo" out of users' $PATH (Nguyễn Thái Ngọc Duy)
I suspect it might be a good idea to make an early declaration
that 1.5.5 is to resolve the above listed issues plus the ones
already in 'pu' (and nothing else), and have a fairly short
cycle after 1.5.4.
That will cause the QUIET_MSGFMT0 script to echo twice; once
when we try to run msgfmt and again when we fallback to po2msg.
That messes with the user's display and won't look very nice coming
out of a supposedly quiet make.
In other words this is probably better:
+ $(QUIET_MSGFMT0)($(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< || \
+ $(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< )$(QUIET_MSGFMT1)
But it is a lot uglier to read, and I tend to not like subshells.
--
Shawn.
* marking output from "diff --{no,src,dst}-prefix" as a non-git
diff (me)
Linus had an objection but I think I made a reasonable
argument against that. Haven't heard back since then, so
this is in limbo.
I just didn'̈́t really care enough. I still don't think the prefix has
anything to do with git'ness, but at the same time it's just not something
I'll ever use, so..
* various lstat(2) reduction changes (me, Linus and Dscho).
This will be queued in 'pu'; it appears this introduces a
timing related breakages in t75?? tests.
Can you send some more info on this? I obviously like that series, and
I've been running various versions of it for a while now, and have run
"make test" a lot. Haven't seen any failures (except the ones I've
introduced while developing), but would be happy to see reports.
Linus
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:44:07
On Sun, 20 Jan 2008, Junio C Hamano wrote:
Here is an update to the list I sent earlier.
Topics that I thought may deserve attention, discussion and
eventual inclusion but are not 1.5.4 material.
I think these two could be part of 1.5.4, but I left them out of
1.5.4-rc4 (IOW, I do not think they should be on this list):
* marking output from "diff --{no,src,dst}-prefix" as a non-git
diff (me)
Linus had an objection but I think I made a reasonable
argument against that. Haven't heard back since then, so
this is in limbo.
If Linus is still not happy with it, we could instead require that the
prefixes have at least one slash, not at the beginning, and figure that
'a/foo/' 'b/foo/' intends the effect it will have on git-apply. The effect
of --no-prefix on git-apply is kind of incoherent, so that's more sensible
to prohibit.
I suspect it might be a good idea to make an early declaration
that 1.5.5 is to resolve the above listed issues plus the ones
already in 'pu' (and nothing else), and have a fairly short
cycle after 1.5.4.
I've got 4 topics that I've been holding back until 1.5.4 is out:
* Use fewer connections to perform git-native fetches (this is actually
from before transport.c made it to master, and I forgot about it until
I was rebasing stuff and it didn't go away).
* Make checkout a builtin (includes a certain amount of infrastructure
improvement for programs that might wants to read multiple trees into
the same index in memory in sequence)
* Generate a cover letter from format-patch (originally Dscho's patch; I
reworked a bunch of it)
* Let the user provide aliases for URL patterns (should be useful for
groups whose members don't all have the same best access to a remote
repository)
If you want to have cycles that only handle stuff that's been submitted
beforehand, it doesn't make sense to have a feature freeze beforehand, and
therefore only take patches in that cycle from people who ignore your
wishes. I think in order to do that sort of thing, we'd need a tree run
like -mm, maintained by somebody whose attention won't be taken away from
the mainline release process by managing patches that are cooking.
-Daniel
*This .sig left intentionally blank*
From: Marco Costalba <hidden> Date: 2016-06-15 22:44:07
On Jan 21, 2008 3:37 AM, Junio C Hamano [off-list ref] wrote:
I suspect it might be a good idea to make an early declaration
that 1.5.5 is to resolve the above listed issues plus the ones
already in 'pu' (and nothing else), and have a fairly short
cycle after 1.5.4.
I have another patch, already sent to the list but lost somewhere
about pretty=format optimization that I'm planning to resend after a
cleanup when 1.5.4 is out.
Patch improves git log speed when --pretty=format is used.
Marco
That will cause the QUIET_MSGFMT0 script to echo twice; once when we try
to run msgfmt and again when we fallback to po2msg.
That messes with the user's display and won't look very nice coming out
of a supposedly quiet make.
In other words this is probably better:
+ $(QUIET_MSGFMT0)($(MSGFMT) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< || \
+ $(PO2MSG) --statistics --tcl -l $(basename $(notdir $<)) -d $(dir $@) $< )$(QUIET_MSGFMT1)
But it is a lot uglier to read, and I tend to not like subshells.
It was exactly this ugliness which made me not do it.
Note: There might be yet a better way. Instead of trying each and every
time, we could detect the presence of msgfmt with something like this:
+ifeq $(shell msgfmt2 2>/dev/null >/dev/null; echo $?) = 127
+ MSGFMT = $(TCL_PATH) po/po2msg.sh
+endif
This is not tested, yet, tough,
Ciao,
Dscho
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:44:07
Johannes Schindelin [off-list ref] wrote:
Note: There might be yet a better way. Instead of trying each and every
time, we could detect the presence of msgfmt with something like this:
+ifeq $(shell msgfmt2 2>/dev/null >/dev/null; echo $?) = 127
+ MSGFMT = $(TCL_PATH) po/po2msg.sh
+endif
I like it. I'm applying this diff (which I tested) to git-gui: