* Re: "git archve --format=tar" output changed from 1.8.1 to 1.8.2.1
From: René Scharfe @ 2013-01-31 18:33 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git, Konstantin Ryabitsev
In-Reply-To: <20130131172805.GC16593@kroah.com>
Am 31.01.2013 18:28, schrieb Greg KH:
> I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
> (archive-tar: split long paths more carefully). The diff of a hex dump
> of the tar archives shows the following difference:
>
> --- old_git_archive 2013-01-31 17:31:24.466343388 +0100
> +++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
> @@ -19239998,8 +19239998,8 @@
> 125943d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125943e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125943f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> -12594400:0000 0000 0000 0000 0000 0000 0000 0000 ................
> -12594410:0000 0000 0000 0000 0000 0000 0000 0000 ................
> +12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3
> +12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000 -pnand-hal/.....
> 12594420:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 12594430:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 12594440:0000 0000 0000 0000 0000 0000 0000 0000 ................
> @@ -19240025,8 +19240025,8 @@
> 12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172 /astoria/arch/ar
> 12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c m/plat-omap/incl
> 125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269 ude/mach/westbri
> -125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f dge/westbridge-o
> -125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000 map3-pnand-hal..
> +125945b0:6467 6500 0000 0000 0000 0000 0000 0000 dge.............
> +125945c0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125945d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125945e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
> 125945f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
This is the only directory in the repository whose path is long enough to
make a difference with the patch, 105 characters in total:
drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/
Five characters less and you wouldn't notice a thing. It contains
"westbridge" thrice, so I think it's cheating just to reach that
length, though. ;-)
> Interestingly, the output of uncompressing the tar archives is
> identical, so the data is correct, but the binary isn't.
The path is split differently between two header fields, that's all.
> Now keeping binary compatibility of tar archive files isn't really a big
> deal, but, the commit to git that causes this seems a bit odd, is it
> really needed? Or can we just fix the version of tar with NetBSD
> instead? :)
Apart from Junio's suggestion, I can't think of a practical solution.
You could downgrade your git to a version before the fix. A downside is
that you won't be able to extract the archive on NetBSD without getting
an error message (but the contents would be intact, except perhaps for
permission bits of the directory above).
You could upgrade the kernel.org version of git, but that might cause the
same problem for other maintainers with long directory paths who in their
repositories who still use git without the fix.
You could make the path shorter. Won't help at all with the release you
just did, of course.
I don't know if other tar implementations freak out when they see an
empty name field. NetBSD's tar might seem a bit too strict here, but
overall I think it's right in complaining.
What makes the commit odd, by the way?
Thanks,
René
^ permalink raw reply
* [PATCH 0/5] Fix msvc build
From: Ramsay Jones @ 2013-01-31 18:26 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
As I mentioned recently, while discussing a cygwin specific patch
(see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
MSVC build is broken for me.
The first 4 patches fix the MSVC build for me. The final patch is
not really related to fixing the build, but it removed some make
warnings which were quite irritating ...
Note that I used the Makefile, with the Visual C++ 2008 command
line compiler on Windows XP (SP3), to build a vanilla git on MinGW.
I'm not subscribed to the msysgit mailing list, nor do I follow the
msysgit fork of git, so these patches may conflict with commits in
their repository.
HTH
ATB,
Ramsay Jones
Ramsay Jones (5):
msvc: Fix compilation errors caused by poll.h emulation
msvc: git-daemon: Fix linker "unresolved external" errors
msvc: Fix build by adding missing symbol defines
msvc: test-svn-fe: Fix linker "unresolved external" error
msvc: avoid collisions between "tags" and "TAGS"
compat/msvc.h | 2 ++
compat/vcbuild/include/sys/poll.h | 1 -
compat/vcbuild/include/unistd.h | 3 +++
config.mak.uname | 4 +++-
git-compat-util.h | 3 +++
test-svn-fe.c | 2 +-
6 files changed, 12 insertions(+), 3 deletions(-)
delete mode 100644 compat/vcbuild/include/sys/poll.h
--
1.8.1
^ permalink raw reply
* [PATCH 1/5] msvc: Fix compilation errors caused by poll.h emulation
From: Ramsay Jones @ 2013-01-31 18:28 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
Commit 0f77dea9 ("mingw: move poll out of sys-folder", 24-10-2011), along
with other commits in the 'ef/mingw-upload-archive' branch (see commit
7406aa20), effectively reintroduced the same problem addressed by commit
56fb3ddc ("msvc: Fix compilation errors in compat/win32/sys/poll.c",
04-12-2010).
In order to fix the compilation errors, we use the same solution adopted
in that earlier commit. In particular, we set _WIN32_WINNT to 0x0502
(which would target Windows Server 2003) prior to including the winsock2.h
header file.
Also, we delete the compat/vcbuild/include/sys/poll.h header file, since
it is now redundant and it's presence may cause some confusion.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/vcbuild/include/sys/poll.h | 1 -
git-compat-util.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
delete mode 100644 compat/vcbuild/include/sys/poll.h
diff --git a/compat/vcbuild/include/sys/poll.h b/compat/vcbuild/include/sys/poll.h
deleted file mode 100644
index 0d8552a..0000000
--- a/compat/vcbuild/include/sys/poll.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Intentionally empty file to support building git with MSVC */
diff --git a/git-compat-util.h b/git-compat-util.h
index cc2abee..204cb1e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -86,6 +86,9 @@
#define _SGI_SOURCE 1
#ifdef WIN32 /* Both MinGW and MSVC */
+# if defined (_MSC_VER)
+# define _WIN32_WINNT 0x0502
+# endif
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
--
1.8.1
^ permalink raw reply related
* [PATCH 2/5] msvc: git-daemon: Fix linker "unresolved external" errors
From: Ramsay Jones @ 2013-01-31 18:30 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
In particular, while linking git-daemon.exe, the linker complains
that the external symbols _inet_pton and _inet_ntop are unresolved.
Commit a666b472 ("daemon: opt-out on features that require posix",
04-11-2010) addressed this problem for MinGW by configuring the
use of the internal 'compat' versions of these function.
Although the MSVC header <WS2tcpip.h> contains the prototypes for
the inet_pton and inet_ntop functions, they are only visible for
Windows API versions from 0x0600 (Windows Vista) or later. (In
addition, on Windows XP, ws2_32.dll does not export these symbols).
In order to fix the linker errors, we also configure the MSVC build
to use the internal compat versions of these functions by setting
the NO_INET_{PTON,NTOP} build variables.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
config.mak.uname | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.mak.uname b/config.mak.uname
index bea34f0..7e52f3c 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -344,6 +344,8 @@ ifeq ($(uname_S),Windows)
NO_CURL = YesPlease
NO_PYTHON = YesPlease
BLK_SHA1 = YesPlease
+ NO_INET_PTON = YesPlease
+ NO_INET_NTOP = YesPlease
NO_POSIX_GOODIES = UnfortunatelyYes
NATIVE_CRLF = YesPlease
DEFAULT_HELP_FORMAT = html
--
1.8.1
^ permalink raw reply related
* [PATCH 3/5] msvc: Fix build by adding missing symbol defines
From: Ramsay Jones @ 2013-01-31 18:31 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
In particular, remote-testsvn.c fails to compile with two
undeclared identifier errors relating to the 'UINT32_MAX'
and 'STDIN_FILENO' symbols.
In order to fix the compilation errors, we add appropriate
definitions for the UINT32_MAX and STDIN_FILENO constants
to an msvc compat header file.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/vcbuild/include/unistd.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/compat/vcbuild/include/unistd.h b/compat/vcbuild/include/unistd.h
index b14fcf9..c65c2cd 100644
--- a/compat/vcbuild/include/unistd.h
+++ b/compat/vcbuild/include/unistd.h
@@ -49,6 +49,9 @@ typedef int64_t off64_t;
#define INTMAX_MAX _I64_MAX
#define UINTMAX_MAX _UI64_MAX
+#define UINT32_MAX 0xffffffff /* 4294967295U */
+
+#define STDIN_FILENO 0
#define STDOUT_FILENO 1
#define STDERR_FILENO 2
--
1.8.1
^ permalink raw reply related
* [PATCH 5/5] msvc: avoid collisions between "tags" and "TAGS"
From: Ramsay Jones @ 2013-01-31 18:33 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
Commit 2f769195 ("MinGW: avoid collisions between "tags" and "TAGS",
28-09-2010) enabled MinGW to use an ETAGS file in order to avoid
filename collisions on (Windows) case insensitive filesystems. In
addition, this prevents 'make' from issuing several warning messages.
When using the Makefile to perform an MSVC build, which is usually
executed using MinGW tools, we can also benefit from this capability.
In order to reap the above benefits, we set the ETAGS_TARGET build
variable to ETAGS in the MSVC config block.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
config.mak.uname | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.mak.uname b/config.mak.uname
index bfb8a39..6f60c3f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -343,6 +343,7 @@ ifeq ($(uname_S),Windows)
NO_CURL = YesPlease
NO_PYTHON = YesPlease
BLK_SHA1 = YesPlease
+ ETAGS_TARGET = ETAGS
NO_INET_PTON = YesPlease
NO_INET_NTOP = YesPlease
NO_POSIX_GOODIES = UnfortunatelyYes
--
1.8.1
^ permalink raw reply related
* [PATCH 4/5] msvc: test-svn-fe: Fix linker "unresolved external" error
From: Ramsay Jones @ 2013-01-31 18:32 UTC (permalink / raw)
To: GIT Mailing-list
Cc: Junio C Hamano, Erik Faye-Lund, Jonathan Nieder, Johannes Sixt,
Johannes Schindelin
In particular, while linking test-svn-fe.exe, the linker complains
that the external symbol _strtoull is unresolved. A call to this
function was added in commit ddcc8c5b ("vcs-svn: skeleton of an svn
delta parser", 25-12-2010).
The NO_STRTOULL build variable attempts to provide support to old
systems which can't even declare 'unsigned long long' variables,
let alone provide the strtoll() or strtoull() functions. Setting
this build variable does not provide an implementation of these
functions. Rather, it simply allows the compat implementations
of strto{i,u}max() to use strtol() and strtoul() instead.
In order to fix the linker error on systems with NO_STRTOULL set,
currently MSVC and OSF1, we can substitute a call to strtoumax().
However, we can easily provide support for the strtoull() and
strtoll() functions on MSVC, since they are essentially already
available as _strtoui64() and _strtoi64(). This allows us to
remove NO_STRTOULL for MSVC.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/msvc.h | 2 ++
config.mak.uname | 1 -
test-svn-fe.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/compat/msvc.h b/compat/msvc.h
index aa4b563..96b6d60 100644
--- a/compat/msvc.h
+++ b/compat/msvc.h
@@ -12,6 +12,8 @@
#define __attribute__(x)
#define strncasecmp _strnicmp
#define ftruncate _chsize
+#define strtoull _strtoui64
+#define strtoll _strtoi64
static __inline int strcasecmp (const char *s1, const char *s2)
{
diff --git a/config.mak.uname b/config.mak.uname
index 7e52f3c..bfb8a39 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -327,7 +327,6 @@ ifeq ($(uname_S),Windows)
# NEEDS_LIBICONV = YesPlease
NO_ICONV = YesPlease
NO_STRTOUMAX = YesPlease
- NO_STRTOULL = YesPlease
NO_MKDTEMP = YesPlease
NO_MKSTEMPS = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
diff --git a/test-svn-fe.c b/test-svn-fe.c
index 0f2d9a4..120ec96 100644
--- a/test-svn-fe.c
+++ b/test-svn-fe.c
@@ -24,7 +24,7 @@ static int apply_delta(int argc, char *argv[])
die_errno("cannot open preimage");
if (buffer_init(&delta, argv[3]))
die_errno("cannot open delta");
- if (svndiff0_apply(&delta, (off_t) strtoull(argv[4], NULL, 0),
+ if (svndiff0_apply(&delta, (off_t) strtoumax(argv[4], NULL, 0),
&preimage_view, stdout))
return 1;
if (buffer_deinit(&preimage))
--
1.8.1
^ permalink raw reply related
* Re: [PATCH v3 00/11] unify appending of sob
From: Brandon Casey @ 2013-01-31 18:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, pclouds
In-Reply-To: <7vhalylggd.fsf@alter.siamese.dyndns.org>
On Wed, Jan 30, 2013 at 9:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>> Brandon Casey wrote:
>>>
>>>> Round 3.
>>>
>>> Thanks for a pleasant read. My only remaining observations are
>>> cosmetic, except for a portability question in Duy's test script, a
>>> small behavior change when the commit message ends with an
>>> RFC2822-style header with no trailing newline and the possibility of
>>> tightening the pattern in sequencer.c to match the strictness of
>>> format-patch (which could easily wait for a later patch).
>>
>> Thanks for a quick review. I agree that this series is getting very
>> close with your help.
>
> Unless Brandon and/or Jonathan wants to have another chance to
> excise warts from the recorded history by rerolling the entire
> series one more time, I think what we have queued is in a good
> enough shape to merge to 'next' and any further improvement and fix
> can be done incrementally.
>
> OK? Or "stop, I want to reroll"?
>
> I'll wait for a day or two.
Let's hold off so I can do another round. I worked on this last night
and was able to simplify some things nicely. I'll try to finish up
tonight and resubmit.
-Brandon
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Johannes Schindelin @ 2013-01-31 18:57 UTC (permalink / raw)
To: Ramsay Jones
Cc: GIT Mailing-list, Junio C Hamano, Erik Faye-Lund, Jonathan Nieder,
Johannes Sixt
In-Reply-To: <510AB766.4030806@ramsay1.demon.co.uk>
Hi Ramsay,
On Thu, 31 Jan 2013, Ramsay Jones wrote:
> As I mentioned recently, while discussing a cygwin specific patch
> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
> MSVC build is broken for me.
>
> The first 4 patches fix the MSVC build for me. The final patch is
> not really related to fixing the build, but it removed some make
> warnings which were quite irritating ...
Thanks!
> Note that I used the Makefile, with the Visual C++ 2008 command line
> compiler on Windows XP (SP3), to build a vanilla git on MinGW. I'm not
> subscribed to the msysgit mailing list, nor do I follow the msysgit fork
> of git, so these patches may conflict with commits in their repository.
Maybe you can Cc: the patch series to msysgit@googlegroups.com
nevertheless?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 19:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vvcadgss0.fsf@alter.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> Wow, that's a blast from the past.
>
> I tend to agree that deprecating and removing are quite different,
> but a simple "revert" of the change would not be good, either. We
> still would want to _discourage_ its use.
Hm, I was about to try adding a line in that vein, like
* `tracking` - deprecated synonym for `upstream`.
Imagine my surprise when I saw that that is what you just said
would be no good:
[...]
>>> `git pull`.
>>> -* `tracking` - deprecated synonym for `upstream`.
>>> * `current` - push the current branch to a branch of the same name.
I really do think that including `tracking` in the same list would be
valuable. When I look over a friend's .gitconfig file to help track
down a problem she is running into, it is helpful if I can find the
meaning of each item in a straightforward way.
Is the problem that "deprecated" is not precise enough? For example,
would it make sense to say "deprecated synonym for `upstream`. Will
be dropped in git 2.1" or something like that?
My two cents,
Jonathan
^ permalink raw reply
* Why git-whatchanged shows a commit touching every file, but git-log doesn't?
From: Constantine A. Murenin @ 2013-01-31 19:09 UTC (permalink / raw)
To: git
Hi,
DragonFly BSD uses git as its SCM, with one single repository and
branch for both the kernel and the whole userland.
On 2011-11-26 (1322296064), someone did a commit that somehow touched
every single file in the repository, even though most of the files
were not modified one bit.
That's the offending commit from 2011-11-26:
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/86d7f5d305c6adaa56ff4582ece9859d73106103
https://github.com/DragonFlyBSD/DragonFlyBSD/commit/86d7f5d305c6adaa56ff4582ece9859d73106103
Since then, with some tools, if you look at file history for any file
anywhere in the repo, you can see that all files were changed on
2011-11-26 with that commit, but it's only shown in some tools, and
not shown in others.
For example, the bogus 2011-11-26 commit is not shown with the following:
* git log sys/sys/sensors.h
* https://github.com/DragonFlyBSD/DragonFlyBSD/commits/master/sys/sys/sensors.h
However, the bogus commit is [erroneously] shown with the following:
% git whatchanged --pretty=%at sys/sys/sensors.h | cat
1322296064
:000000 100644 0000000... 554cfc2... A sys/sys/sensors.h
1191329821
:000000 100644 0000000... 554cfc2... A sys/sys/sensors.h
%
Notice how the file was ]A]dded once again at 1322296064 without ever
being deleted, and that the dst sha1 is the same for both the latest
and the immediately prior revision of the file.
Gitweb, unlike github, would also show the erroneous commit from 2011-11:
http://gitweb.dragonflybsd.org/dragonfly.git/history/HEAD:/sys/sys/sensors.h
Another, more representative example, which shows that src sha1 (field
names are documented in git-diff-tree(1)) is always "0000000..." in
such bogus touch-all commits (even though it makes little sense when
you consider that the files were never deleted and still have the same
dst sha1):
% git whatchanged --pretty=%at sys/sys/sysctl.h | head -9
1322296064
:000000 100644 0000000... 6659977... A sys/sys/sysctl.h
1296826445
:100644 100644 94b8d96... 6659977... M sys/sys/sysctl.h
1292413105
:100644 100644 8c9deaa... 94b8d96... M sys/sys/sysctl.h
%
So, my questions are as follows:
* How was it possible for all these files to be added without first
being deleted in the first place? Was / is it a bug in git (during a
commit) to allow something like that?
* Why do some tools compact such bogus commits out (and hide them from
the user), but some don't?
* Is there a way to make git-whatchanged and gitweb ignore such bogus
commits on files that weren't actually modified, just as git-log and
github already do?
P.S. I've asked this question on
http://stackoverflow.com/q/14632828/1122270, if anyone wants a cookie.
Best regards,
Constantine.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 19:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131190747.GE27340@google.com>
Jonathan Nieder wrote:
> Is the problem that "deprecated" is not precise enough? For example,
> would it make sense to say "deprecated synonym for `upstream`. Will
> be dropped in git 2.1" or something like that?
Also, if we plan to remove support soon, we should start warning when
this setting is encountered so people know to update their
configuration.
Jonathan
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Junio C Hamano @ 2013-01-31 19:28 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ramsay Jones, GIT Mailing-list, Erik Faye-Lund, Jonathan Nieder,
Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.1301311956470.32206@s15462909.onlinehome-server.info>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Ramsay,
>
> On Thu, 31 Jan 2013, Ramsay Jones wrote:
>
>> As I mentioned recently, while discussing a cygwin specific patch
>> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
>> MSVC build is broken for me.
>>
>> The first 4 patches fix the MSVC build for me. The final patch is
>> not really related to fixing the build, but it removed some make
>> warnings which were quite irritating ...
>
> Thanks!
>
>> Note that I used the Makefile, with the Visual C++ 2008 command line
>> compiler on Windows XP (SP3), to build a vanilla git on MinGW. I'm not
>> subscribed to the msysgit mailing list, nor do I follow the msysgit fork
>> of git, so these patches may conflict with commits in their repository.
>
> Maybe you can Cc: the patch series to msysgit@googlegroups.com
> nevertheless?
OK. The only thing I can say about these patches is that none of
them would affect my boxes would exercise, so I'll wait until I get
a final-for-application re-send from mysgit folks, preferrably with
their Acked-by: lines.
Thanks.
^ permalink raw reply
* Re: Why git-whatchanged shows a commit touching every file, but git-log doesn't?
From: Jonathan Nieder @ 2013-01-31 19:34 UTC (permalink / raw)
To: Constantine A. Murenin; +Cc: git
In-Reply-To: <CAPKkNb49FUgLxZxHmQJoqccQ1XVcFYbYF8kYDp0+Y27cmi56fg@mail.gmail.com>
Hi Constantine,
Constantine A. Murenin wrote:
> DragonFly BSD uses git as its SCM, with one single repository and
> branch for both the kernel and the whole userland.
>
> On 2011-11-26 (1322296064), someone did a commit that somehow touched
> every single file in the repository, even though most of the files
> were not modified one bit.
"gitk --simplify-by-decoration" might provide some insight.
In the dragonfly history, it seems that imports of a packages typically
proceed in two steps:
1. First, the upstream code is imported as a new "initial commit"
with no history:
cd ~/src
git init gcc-4.7.2-import
cd gcc-4.7.2-import
tar -xf /path/to/gcc-4.7.2
mkdir contrib
mv gcc-4.7.2 contrib/gcc-4.7
git add .
git commit -m 'Import gcc-4.7.2 to new vendor branch'
2. Next, that code is incorporated into dragonfly.
cd ~/src/dragonfly
git fetch ../gcc-4.7.2-import master:refs/heads/vendor/GCC47
git merge vendor/GCC47
rm -fr ../gcc-4.7.2-import
Unfortunately in the commit you mentioned, someone made a mistake.
Instead of importing a single new upstream package, the author
imported the entire dragonfly tree as a new vendor branch. Oops.
The effects might be counterintuitive:
* tools like "git blame" and path-limited "git log" get a choice:
when looking at the merge that pulled in a copy of dragonfly into
the existing dragonfly codebase, either parent is an equally
sensible from blame's point of view as an explanation of the origin
of this code. I think both prefer the first parent here, making them
happen to produce the "right" result.
* tools like "git show" that describe what change a commit made
get a choice: when looking at a parentless commit, the diff that
brings a project into existence may or may not be interesting,
depending on the situation.
See
http://thread.gmane.org/gmane.comp.version-control.git/182571/focus=182577
for more about that.
But at its heart, this is just an instance of "lie when creating your
history and history-mining tools will lie back to you." :)
Hoping that clarifies a little,
Jonathan
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Jeff King @ 2013-01-31 19:38 UTC (permalink / raw)
To: Ted Zlatanov
Cc: Junio C Hamano, Michal Nazarewicz, git, Krzysztof Mazur,
Michal Nazarewicz
In-Reply-To: <87pq0l5qbc.fsf@lifelogs.com>
On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
> Jeff, is there a way for git-credential to currently support
> authinfo/netrc parsing? I assume that's the right way, instead of using
> Michal's proposal to parse internally?
>
> I'd like to add that, plus support for the 'string' and "string"
> formats, and authinfo.gpg decoding through GPG. I'd write it in Perl,
> if there's a choice.
Yes, you could write a credential helper that understands netrc and
friends; git talks to the helpers over a socket, so there is no problem
with writing it in Perl. See Documentation/technical/api-credentials.txt
for an overview, or the sample implementation in credential-store.c for a
simple example.
-Peff
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 19:41 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131190747.GE27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Wow, that's a blast from the past.
>>
>> I tend to agree that deprecating and removing are quite different,
>> but a simple "revert" of the change would not be good, either. We
>> still would want to _discourage_ its use.
>
> Hm, I was about to try adding a line in that vein, like
>
> * `tracking` - deprecated synonym for `upstream`.
>
> Imagine my surprise when I saw that that is what you just said
> would be no good:
>
> [...]
>>>> `git pull`.
>>>> -* `tracking` - deprecated synonym for `upstream`.
>>>> * `current` - push the current branch to a branch of the same name.
>
> I really do think that including `tracking` in the same list would be
> valuable. When I look over a friend's .gitconfig file to help track
> down a problem she is running into, it is helpful if I can find the
> meaning of each item in a straightforward way.
While I agree we would need a way for you to easily find `tracking`
mentioned near that point, listing it as if it is a proper part of
the same list of possibilities is not the only way to do so.
The enumeration is used by two different audiences. For those who
want to _learn_ what possibilities are available to them (i.e. they
are not going from `tracking` to what it means, but going in the
opposite direction), it should be unmistakingly clear that
`tracking` is not a part of the choices they should make. I do not
think the following list created by a simple "revert" makes it clear.
* `nothing` - do not push anything.
* `matching` - push all branches having the same name in both ends.
* `upstream` - push the current branch to ...
* `simple` - like `upstream`, but refuses to ...
* `tracking` - deprecated synonym for `upstream`.
* `current` - push the current branch to a branch of the same name.
When scanning, most people will scan lines to see there are 6
choices without reading anything after '-' first, and then start
reading the item that sounds plausible for them without necessarily
reading the others. That will imprint the word `tracking` in the
context of choosing how to push, especially when that is not what
they end up using.
That is why I tend to prefer how check-ref-format documentation
describes --print:
--normalize::
Normalize 'refname' by removing any leading slash (`/`)
characters and collapsing runs of adjacent slashes between
name components into a single slash. Iff the normalized
refname is valid then print it to standard output and exit
with a status of 0. (`--print` is a deprecated way to spell
`--normalize`.)
When you are going from `tracking` to what it means, you have \C-s
(if you are viewing in Emacs) or '/' (if you are using less)
available.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 19:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vip6dgmx2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> That is why I tend to prefer how check-ref-format documentation
> describes --print:
>
> --normalize::
> Normalize 'refname' by removing any leading slash (`/`)
> characters and collapsing runs of adjacent slashes between
> name components into a single slash. Iff the normalized
> refname is valid then print it to standard output and exit
> with a status of 0. (`--print` is a deprecated way to spell
> `--normalize`.)
That works because, as you mention, the usual way to look up an option
in manpages is to search for "--print", including the two minus signs.
Unfortunately an analagous approach in gitconfig(5) would be seriously
broken, because searching for "tracking" (no minus signs) is going to
hit many false positives. I do not think such a change would be an
improvement.
Meanwhile I believe the prominent words "deprecated synonym" already
make it completely obvious that when I write a new config file, I should
use the modern option, unless I am trying to write a config file that
also works with older versions of git. In the latter case (which
unfortunately is not too uncommon), hiding the option is not going to
make my life easier. What would allow me to make an informed choice
is mentioning what version of git *introduced* the new name of the
option:
- `tracking` - deprecated old name for `upstream`, used by git
versions before 1.7.4.2. Don't use this.
Also I do not think anyone claimed we are removing "tracking" from the
documentation in order to stop people from using it. The rationale
when the patch was proposed is that it makes the documentation easier
to read. I agree with that rationale, with the caveat Avar mentioned.
There is a simple fix: just simplify the behavior being explained as
well, by biting the bullet and dropping the "tracking" synonym after a
suitable period in which it produces a warning.
In the meantime, the documentation is valuable, and pretending that
"tracking" does not exist for everyone who does not confusedly reread
the docs a few times is just a way to lie to ourselves and make users'
lives more difficult. Is that really the intent?
Jonathan
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 19:58 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131191105.GF27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Jonathan Nieder wrote:
>
>> Is the problem that "deprecated" is not precise enough? For example,
>> would it make sense to say "deprecated synonym for `upstream`. Will
>> be dropped in git 2.1" or something like that?
>
> Also, if we plan to remove support soon, we should start warning when
> this setting is encountered so people know to update their
> configuration.
I do not think this even needs to be removed.
We deprecate something for one of two reasons. One is when it was a
bad idea to support it, and we would want to remove the support
eventually. This needs a migration plan.
The other is when there are better ways available but we do not want
to break the old way. We still do not want to encourage the old way
to new users.
The change from 'upstream' from 'tracking' is the latter. The
wording will confuse new users when they want to learn what
'tracking' as a concept is, and it is better spelt 'upstream'. But
the breakage is not serious enough to warrant forcing an old timer
who can explain these two concepts to newbies when needed to update
his configuration files he is not planning to show to newbies.
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 20:01 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131195712.GH27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> That is why I tend to prefer how check-ref-format documentation
>> describes --print:
>>
>> --normalize::
>> Normalize 'refname' by removing any leading slash (`/`)
>> characters and collapsing runs of adjacent slashes between
>> name components into a single slash. Iff the normalized
>> refname is valid then print it to standard output and exit
>> with a status of 0. (`--print` is a deprecated way to spell
>> `--normalize`.)
>
> That works because, as you mention, the usual way to look up an option
> in manpages is to search for "--print", including the two minus signs.
>
> Unfortunately an analagous approach in gitconfig(5) would be seriously
> broken, because searching for "tracking" (no minus signs) is going to
> hit many false positives. I do not think such a change would be an
> improvement.
I thought your example was that you saw "pull.default = tracking"
and wondering what it is. Why do you need global search for
"tracking", not just near pull.default is described, in the first
place?
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 20:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7vip6dgmx2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> For those who
> want to _learn_ what possibilities are available to them (i.e. they
> are not going from `tracking` to what it means, but going in the
> opposite direction), it should be unmistakingly clear that
> `tracking` is not a part of the choices they should make.
Until pre-1.7.4 versions of git fall out of use, I don't agree that
the above is true. :(
> I do not
> think the following list created by a simple "revert" makes it clear.
>
> * `nothing` - do not push anything.
> * `matching` - push all branches having the same name in both ends.
> * `upstream` - push the current branch to ...
> * `simple` - like `upstream`, but refuses to ...
> * `tracking` - deprecated synonym for `upstream`.
> * `current` - push the current branch to a branch of the same name.
How about the following?
* `nothing` - ...
* `matching` - ...
* `upstream` - ...
* `simple` - ...
* `current` - ...
For compatibility with ancient config files, the following synonym
is also supported. Don't use it.
* `tracking` - old name for `upstream`
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Matthieu Moy @ 2013-01-31 20:08 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Ævar Arnfjörð Bjarmason, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131200434.GI27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> How about the following?
>
> * `nothing` - ...
> * `matching` - ...
> * `upstream` - ...
> * `simple` - ...
> * `current` - ...
>
> For compatibility with ancient config files, the following synonym
> is also supported. Don't use it.
>
> * `tracking` - old name for `upstream`
Sounds good to me.
I'm the author of the removal patch, but the patch was just part of a
larger serie explaining push.default, the idea of cleaning up the
obsolete alias came in the discussion and I did it, but I'm fine with
reintroducing it in the doc (as long as it does not disturb new users
too much).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Jonathan Nieder @ 2013-01-31 20:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <7va9rpgm06.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> That works because, as you mention, the usual way to look up an option
>> in manpages is to search for "--print", including the two minus signs.
>>
>> Unfortunately an analagous approach in gitconfig(5) would be seriously
>> broken, because searching for "tracking" (no minus signs) is going to
>> hit many false positives. I do not think such a change would be an
>> improvement.
>
> I thought your example was that you saw "pull.default = tracking"
> and wondering what it is. Why do you need global search for
> "tracking", not just near pull.default is described, in the first
> place?
Because the UI for local searches in web browsers and man pagers is
seriously lacking. Or, because people have bad habits and do not
take apppropriate advantage of search in small subsections of a
document. All I know is that I have seen myself and others doing
searches analagous to "--print" and not seen searches analagous to
"tracking".
Am I really the only one that doesn't see the "--print" change as
hiding an option and sees burying "tracking" in the text as
qualitatively different?
Jonathan
^ permalink raw reply
* [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
From: John Keeping @ 2013-01-31 20:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Max Horn, Matthieu Moy
In-Reply-To: <7vfw1ijtz2.fsf@alter.siamese.dyndns.org>
When looking up a topic via "git help <topic>", git-help prepends "git-"
to topics that are the names of commands (either builtin or found on the
path) and "git" (no hyphen) to any other topic name.
"git-remote-helpers" is not the name of a command, so "git help
remote-helpers" looks for "gitremote-helpers" and does not find it.
Fix this by renaming "git-remote-helpers.txt" to
"gitremote-helpers.txt".
Signed-off-by: John Keeping <john@keeping.me.uk>
---
On Wed, Jan 30, 2013 at 12:28:49PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
> >
> > Does this mean that "git-remote-helpers.txt" should lose the first
> > hyphen or is help.c not being clever enough in some way?
>
> I think it is the former. "git help tutorial" works exactly the
> same way.
This is the patch to rename it to "gitremote-helpers.txt".
Would we want to do something to avoid breaking links to the existing
document as well?
Documentation/git-remote-testgit.txt | 2 +-
Documentation/{git-remote-helpers.txt => gitremote-helpers.txt} | 6 +++---
Documentation/urls.txt | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
rename Documentation/{git-remote-helpers.txt => gitremote-helpers.txt} (99%)
diff --git a/Documentation/git-remote-testgit.txt b/Documentation/git-remote-testgit.txt
index 612a625..f791d73 100644
--- a/Documentation/git-remote-testgit.txt
+++ b/Documentation/git-remote-testgit.txt
@@ -23,7 +23,7 @@ The best way to learn more is to read the comments and source code in
SEE ALSO
--------
-linkgit:git-remote-helpers[1]
+linkgit:gitremote-helpers[1]
GIT
---
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/gitremote-helpers.txt
similarity index 99%
rename from Documentation/git-remote-helpers.txt
rename to Documentation/gitremote-helpers.txt
index e36fdcb..0c91aba 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -1,9 +1,9 @@
-git-remote-helpers(1)
-=====================
+gitremote-helpers(1)
+====================
NAME
----
-git-remote-helpers - Helper programs to interact with remote repositories
+gitremote-helpers - Helper programs to interact with remote repositories
SYNOPSIS
--------
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index 539c0a0..3ca122f 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -55,7 +55,7 @@ may be used:
where <address> may be a path, a server and path, or an arbitrary
URL-like string recognized by the specific remote helper being
-invoked. See linkgit:git-remote-helpers[1] for details.
+invoked. See linkgit:gitremote-helpers[1] for details.
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt
From: Matthieu Moy @ 2013-01-31 20:18 UTC (permalink / raw)
To: John Keeping; +Cc: git, Junio C Hamano, Max Horn
In-Reply-To: <fc96ae61bb64ce19e856d7a1624e2130c99afd47.1359662569.git.john@keeping.me.uk>
John Keeping <john@keeping.me.uk> writes:
> Would we want to do something to avoid breaking links to the existing
> document as well?
That would be nice to add a new git-remote-helpers.txt saying "document
has moved, see linkgit:gitremote-helpers.txt[1], so that HTML links to
http://git-scm.com/docs/git-remote-helpers and friends do not get
broken, yes.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 2/7] Undocument deprecated alias 'push.default=tracking'
From: Junio C Hamano @ 2013-01-31 20:21 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð Bjarmason, Matthieu Moy, git,
Jeff King, Michael Haggerty
In-Reply-To: <20130131200434.GI27340@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>
>> For those who
>> want to _learn_ what possibilities are available to them (i.e. they
>> are not going from `tracking` to what it means, but going in the
>> opposite direction), it should be unmistakingly clear that
>> `tracking` is not a part of the choices they should make.
>
> Until pre-1.7.4 versions of git fall out of use, I don't agree that
> the above is true. :(
The documentation ships with the version that the above is true. We
are not making an update to documentation that comes with ancient
versions.
>> I do not
>> think the following list created by a simple "revert" makes it clear.
>>
>> * `nothing` - do not push anything.
>> * `matching` - push all branches having the same name in both ends.
>> * `upstream` - push the current branch to ...
>> * `simple` - like `upstream`, but refuses to ...
>> * `tracking` - deprecated synonym for `upstream`.
>> * `current` - push the current branch to a branch of the same name.
>
> How about the following?
>
> * `nothing` - ...
> * `matching` - ...
> * `upstream` - ...
> * `simple` - ...
> * `current` - ...
>
> For compatibility with ancient config files, the following synonym
> is also supported. Don't use it.
>
> * `tracking` - old name for `upstream`
Didn't I say I am fine to mention it "as a side note" in the
original message you started responding to?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox