* Re: [PATCH 1/8] Use %B for Split Subject/Body
From: Junio C Hamano @ 2013-01-07 16:53 UTC (permalink / raw)
To: 郑文辉(Techlive Zheng); +Cc: David A. Greene, git
In-Reply-To: <CAPYzjrT_8g26y-QrYvbQYoySWskGdn15jCX60rz04wQFQ2ikVw@mail.gmail.com>
"郑文辉(Techlive Zheng)" <techlivezheng@gmail.com> writes:
> Though, this patch defintely should be merged, becuase no one expects
> his commit message be altered durging the splitting process.
Are you saying that after double-checking what was posted? It said
something like this below, which does not look like 'definitely
should be' to me.
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..f2b6d4a 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -296,7 +296,12 @@ copy_commit()
# We're going to set some environment vars here, so
# do it in a subshell to get rid of them safely later
debug copy_commit "{$1}" "{$2}" "{$3}"
+ # Use %B rather than %s%n%n%b to handle the special case of a
+ # commit that only has a subject line. We don't want to
+ # introduce a newline after the subject, causing generation of
+ # a new hash.
git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' "$1" |
+# git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
(
read GIT_AUTHOR_NAME
read GIT_AUTHOR_EMAIL
^ permalink raw reply related
* Re: [PATCH 4/4] t5002: check if unzip supports symlinks
From: René Scharfe @ 2013-01-07 16:50 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <20130107085206.GI27909@elie.Belkin>
Am 07.01.2013 09:52, schrieb Jonathan Nieder:
> René Scharfe wrote:
>
>> Only add a symlink to the repository if both the filesystem and
>> unzip support symlinks. To check the latter, add a ZIP file
>> containing a symlink, created like this with InfoZIP zip 3.0:
>>
>> $ echo sample text >textfile
>> $ ln -s textfile symlink
>> $ zip -y infozip-symlinks.zip textfile symlink
>
> Hm. Do some implementations of "unzip" not support symlinks, or is
> the problem that some systems build Info-ZIP without the SYMLINKS
> option?
The unzip supplied with NetBSD 6.0.1, which is based on libarchive,
doesn't support symlinks. It creates a file with the link target path
as its only content for such entries.
I assume that Info-ZIP is compiled with the SYMLINKS option on all
platforms whose default filesystem supports symbolic links. Except on
Windows perhaps, where it's complicated.
For the test script there is no difference: If we don't have a tool to
verify symlinks in archives, we better skip that part.
René
^ permalink raw reply
* Re: [PATCH 2/4] t0024, t5000: use test_lazy_prereq for UNZIP
From: René Scharfe @ 2013-01-07 16:28 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <20130107084509.GH27909@elie.Belkin>
Am 07.01.2013 09:45, schrieb Jonathan Nieder:
> René Scharfe wrote:
>
>> --- a/t/t0024-crlf-archive.sh
>> +++ b/t/t0024-crlf-archive.sh
>> @@ -5,6 +5,11 @@ test_description='respect crlf in git archive'
>> . ./test-lib.sh
>> GIT_UNZIP=${GIT_UNZIP:-unzip}
>>
>> +test_lazy_prereq UNZIP '
>> + "$GIT_UNZIP" -v >/dev/null 2>&1
>> + test $? -ne 127
>
> Micronit: now that this is part of a test, there is no more need to
> silence its output. The "unzip -v" output could be useful to people
> debugging with "t0024-crlf-archive.sh -v -i".
Oh, yes, good point.
> With or without that change, this is a nice cleanup and obviously
> correct, so
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks,
René
^ permalink raw reply
* Re: [PATCH 1/4] t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
From: René Scharfe @ 2013-01-07 16:25 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <20130107051609.GB27909@elie.Belkin>
Am 07.01.2013 06:16, schrieb Jonathan Nieder:
> René Scharfe wrote:
>
>> InfoZIP's unzip takes default parameters from the environment variable
>> UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
>> alternate versions of the unzip command instead.
>>
>> t0024 wasn't even using variable for the actual extraction. t5000
>> was, but when setting it to InfoZIP's unzip it would try to extract
>> from itself (because it treats the contents of $UNZIP as parameters),
>> which failed of course.
>
> That would only happen if the UNZIP variable was already exported,
> right?
We don't want any parameters a user may have been specified influence
the test. I'm not sure if someone actually sets that variable for that
purpose, though.
My main use case is running individual test scripts with an alternative
unzip binary, and with the patch this works as expected:
$ cd t
$ GIT_UNZIP=/usr/pkg/bin/unzip ./t5000-tar-tree.sh
> The patch makes sense and takes care of all uses of ${UNZIP} I can
> find, and it even makes the quoting consistent so a person can put
> their copy of unzip under "/Program Files". For what it's worth,
>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks!
René
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: Junio C Hamano @ 2013-01-07 16:08 UTC (permalink / raw)
To: Jens Lehmann
Cc: Jonathan Nieder, W. Trevor King, Git, Peter Collingbourne,
mbranchaud, Michael J Gruber
In-Reply-To: <50EA84E9.9030702@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Right, and me thinks that would warrant a --force option for deinit
> to do that even if the submodule contains local changes (which would
> make deinit fail otherwise).
Probably.
> Additionally Michael and Marc spoke up
> that they would rather have a --all option to deinit all initialized
> submodules and "git submodule deinit" without any arguments should
> just produce a usage message. As I saw no voices against it that'll
> be part of the next iteration too.
Yeah, I forgot about that possible surprise of deiniting everything
under the sun by default.
I am not sure if "--all" is a good way forward, though.
Can you defeat it with "git submodule deinit ./--all" or something
to limit the target only to one submodule whose unfortunate location
is named as such? If you have such a support, I have this suspicion
that you already get a short and explicit way to say "everything
under the current directory" with "git submodule deinit ." for free.
^ permalink raw reply
* Re: [PATCH] Add getenv.so for catching invalid getenv() use via LD_PRELOAD
From: David Michael @ 2013-01-07 15:45 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git@vger.kernel.org, Junio C Hamano
In-Reply-To: <1357376146-7155-1-git-send-email-pclouds@gmail.com>
Hi,
On Sat, Jan 5, 2013 at 3:55 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> Perhaps this will help the getenv bug hunting (I assume we do the
> hunting on Linux platform only). So far it catches this and is stuck
> at getenv in git_pager().
For the record: I have been testing a macro pointing getenv at an
alternate implementation for the purpose of my port. This alternate
function will return a unique pointer for each variable, as opposed to
using the same static buffer. IBM considers this function a
proprietary z/OS extension (whereas the other is labelled as
conforming to half a dozen standards), but it seems to be more in-line
with the behavior git expects.
So I agree this patch is useful for reaching strict conformance to the
published specs, but I think we can go back to assuming no known
platforms are broken and unusable because of this.
Thanks.
David
^ permalink raw reply
* Re: [BUG/PATCH] setup: Copy an environment variable to avoid overwrites
From: Erik Faye-Lund @ 2013-01-07 15:28 UTC (permalink / raw)
To: David Michael; +Cc: git@vger.kernel.org, Junio C Hamano
In-Reply-To: <CAEvUa7niTJVfp8_kuWs50kvhfZ59F-yAuAmeOXEduHXOq-tRFA@mail.gmail.com>
On Sat, Jan 5, 2013 at 1:35 AM, David Michael <fedora.dm0@gmail.com> wrote:
> It is possible for this pointer of the GIT_DIR environment variable to
> survive unduplicated until further getenv calls are made. The standards
> allow for subsequent calls of getenv to overwrite the string located at
> its returned pointer, and this can result in broken git operations on
> certain platforms.
>
> Signed-off-by: David Michael <fedora.dm0@gmail.com>
> ---
>
> I have encountered an issue with consecutive calls to getenv
> overwriting earlier values. Most notably, it prevents a plain "git
> clone" from working.
>
> Long story short: This value of GIT_DIR gets passed around setup.c
> until it reaches check_repository_format_gently. This function calls
> git_config_early, which eventually runs getenv("HOME"). When it
> returns back to check_repository_format_gently, the gitdir variable
> contains my home directory path. The end result is that I wind up
> with ~/objects/ etc. and a failed repository clone. (Simply adding a
> bare getenv("GIT_DIR") afterwards to reset the pointer also corrects
> the problem.)
>
> Since other platforms are apparently working, yet this getenv behavior
> is supported by the standards, I am left wondering if this could be a
> symptom of something else being broken on my platform (z/OS). Can
> anyone more familiar with this part of git identify any condition that
> obviously should not be occurring?
>
> Thanks.
I have some patches of a similar nature here:
https://github.com/kusma/git/commits/work/getenv-safety
These were written for an earlier version of the UTF-8 patches for Git
for Windows, where we were looking into allowing getenv to use a
static buffer to convert the environment variables from UTF-16 (which
is what Windows maintains) to UTF-8. We ended converting the
environment on start-up instead, so these weren't needed for us. But
perhaps they can be of use to someone else?
^ permalink raw reply
* Re: [PATCH 1/8] Use %B for Split Subject/Body
From: 郑文辉(Techlive Zheng) @ 2013-01-07 15:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David A. Greene, git
In-Reply-To: <7vtxr1bg4g.fsf@alter.siamese.dyndns.org>
2013/1/1 Junio C Hamano <gitster@pobox.com>:
> "David A. Greene" <greened@obbligato.org> writes:
>
>> From: Techlive Zheng <techlivezheng@gmail.com>
>>
>> Use %B to format the commit message and body to avoid an extra newline
>> if a commit only has a subject line.
>
> Is this an unconditional improvement, or is it generally an
> improvement but for some users it may be a regression? I am
> guessing it is the former but am just making sure.
This patch will make sure the commits in the result branch by using
`git-subtree split` stays intact as they were in the original branch.
This patch will break the current existing branch that splitted before
this patch, becuase these branches were splitted with the wrongly
altered commit messages.
Maybe a fallback option should be added to make sure these branches
could still be updated.
Though, this patch defintely should be merged, becuase no one expects
his commit message be altered durging the splitting process.
^ permalink raw reply
* RE: [PATCH v4] git-completion.bash: add support for path completion
From: Marc Khouzam @ 2013-01-07 15:26 UTC (permalink / raw)
To: 'Manlio Perillo'
Cc: 'Junio C Hamano', 'git@vger.kernel.org',
'szeder@ira.uka.de', 'felipe.contreras@gmail.com'
In-Reply-To: <50EAD0FA.4050401@gmail.com>
> -----Original Message-----
> From: git-owner@vger.kernel.org
> [mailto:git-owner@vger.kernel.org] On Behalf Of Manlio Perillo
> Sent: Monday, January 07, 2013 8:43 AM
> To: Marc Khouzam
> Cc: Junio C Hamano; git@vger.kernel.org; szeder@ira.uka.de;
> felipe.contreras@gmail.com
> Subject: Re: [PATCH v4] git-completion.bash: add support for
> path completion
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Il 05/01/2013 21:23, Marc Khouzam ha scritto:
> > [...]
> > Below are two suggestions that are in line with this effort
> but that are not regressions.
> >
> > A) It would be nice if
> > git commit -a <TAB>
> > also completed with untracked files
> >
>
> $ git commit -a foo
> fatal: Paths with -a does not make sense.
>
> So
> git commit -a <TAB>
>
> should not suggest untracked files; instead it should suggest nothing.
You are right, I was confused.
git commit --all <TAB>
should also suggest nothing then.
Thanks
Marc
^ permalink raw reply
* Re: [PATCH 1/8] Use %B for Split Subject/Body
From: 郑文辉(Techlive Zheng) @ 2013-01-07 15:00 UTC (permalink / raw)
To: git; +Cc: greened
In-Reply-To: <CAPYzjrTqmzuWoDg+zvLxwB7g6J4J2wbBqpL+UbHKRHcbjA4HrA@mail.gmail.com>
2013/1/1 Junio C Hamano <gitster@pobox.com>:
> "David A. Greene" <greened@obbligato.org> writes:
>
>> From: Techlive Zheng <techlivezheng@gmail.com>
>>
>> Use %B to format the commit message and body to avoid an extra newline
>> if a commit only has a subject line.
>
> Is this an unconditional improvement, or is it generally an
> improvement but for some users it may be a regression? I am
> guessing it is the former but am just making sure.
>
>> Author: Techlive Zheng <techlivezheng@gmail.com>
>>
>> Signed-off-by: David A. Greene <greened@obbligato.org>
>
> Please don't do "Author: " which does not add anything new. That is
> what "From: " is for. Instead it needs to be a sign-off.
>
> Also, is that a real name, I have to wonder?
>
Hmm, sorry about the confusing.
I am a Chinese, I coined that first name a couple years ago when I
decided to have a unique name across the web. My real name is "郑文辉" in
Chinese，translate to English by its pronucation is "Wenhui
Zheng"，which means "Zheng" is acturally my real last name. The first
name "Wenhui" does not have any meaning in English, so I coined it by
"Tech" + "Live", which I interprate it as "Technological Living",
thus, "Techlive Zheng" is the name I am currently using online.
Here are some links:
* Let the code talks. https://github.com/techlivezheng
* I cross the great GFW to use twitter. https://twitter.com/techlivezheng
* Also search "Techlive Zheng" in Google, the result should be unique to me.
So, no doubt, I am a real person, just with kind of an uncommon name.
>> Thanks.
^ permalink raw reply
* Re: [BUG] two-way read-tree can write null sha1s into index
From: Jeff King @ 2013-01-07 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vzk0pvqvu.fsf@alter.siamese.dyndns.org>
On Thu, Jan 03, 2013 at 02:33:09PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Oh, I agree it's insane to try to carry through unmerged entries. I'm
> > just concerned that not all code paths are careful enough to check.
>
> I would actually be surprised if some code path do assume somebody
> might give them an index with conflicting entries in it and guard
> against it. We have been coding under the "index must exactly match
> the second tree when three-way unpack_trees() begin" requirement
> since day one. An conflicted entry will appear as "index and HEAD
> not matching" and will cause reject_merge() early in threeway_merge()
> anyway, no?
Hmm. There is code in threeway_merge to handle a few cases:
/*
* We start with cases where the index is allowed to match
* something other than the head: #14(ALT) and #2ALT, where it
* is permitted to match the result instead.
*/
/* #14, #14ALT, #2ALT */
if (remote && !df_conflict_head && head_match && !remote_match) {
if (index && !same(index, remote) && !same(index, head))
return o->gently ? -1 : reject_merge(index, o);
return merged_entry(remote, index, o);
}
but I do not think we have to worry, because we know that the index will
never match remote, either (and merged_entry has already been taught to
be wary of the conflicted bit, anyway). I'm not entirely clear on how
that would get triggered if all of the callers avoid operating on a
modified index.
-Peff
^ permalink raw reply
* Re: [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2013-01-07 13:43 UTC (permalink / raw)
To: Marc Khouzam
Cc: Junio C Hamano, git@vger.kernel.org, szeder@ira.uka.de,
felipe.contreras@gmail.com
In-Reply-To: <E59706EF8DB1D147B15BECA3322E4BDC0681FA@eusaamb103.ericsson.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 05/01/2013 21:23, Marc Khouzam ha scritto:
> [...]
> Below are two suggestions that are in line with this effort but that are not regressions.
>
> A) It would be nice if
> git commit -a <TAB>
> also completed with untracked files
>
$ git commit -a foo
fatal: Paths with -a does not make sense.
So
git commit -a <TAB>
should not suggest untracked files; instead it should suggest nothing.
> [...]
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDq0PoACgkQscQJ24LbaUSTNwCfWt7a1Tdg9u5sd6B3FXCEFj1/
sBwAoIv4B2y4MUQgLNafY2PTWx4giSfD
=tb3O
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-07 12:08 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <50EA7269.1080006@web.de>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Mon, Jan 07, 2013 at 07:59:53AM +0100, Jens Lehmann wrote:
> I´m currently working on teaching mv to move submodules and intend
> to send those patches to the list after finishing submodule deinit.
> Please see
> https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules
> for the current state of this series.
Ah, that will be much better :).
It looks like my script tries to do all the right things though, so if
anyone needs to move a submodule before Jens' branch lands, you might
want to give it a try.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v2] git-fast-import(1): remove duplicate '--done' option
From: John Keeping @ 2013-01-07 11:57 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, Eric S. Raymond, Sverre Rabbelier
In-Reply-To: <20130105160652.GE6440@serenity.lan>
On Sat, Jan 05, 2013 at 04:06:52PM +0000, John Keeping wrote:
The '--done' option to git-fast-import is documented twice in its manual
page. Combine the best bits of each description, keeping the location
of the instance that was added first.
Signed-off-by: John Keeping <john@keeping.me.uk>
---
Changed since v1:
'done' => `done`
I'll wait a bit longer for comments on [1] before I have another go at
the full re-organisation of this page.
[1] http://article.gmane.org/gmane.comp.version-control.git/212805
Documentation/git-fast-import.txt | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 68bca1a..4ef5721 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -39,10 +39,6 @@ OPTIONS
See ``Date Formats'' below for details about which formats
are supported, and their syntax.
--- done::
- Terminate with error if there is no 'done' command at the
- end of the stream.
-
--force::
Force updating modified existing branches, even if doing
so would cause commits to be lost (as the new commit does
@@ -108,7 +104,8 @@ OPTIONS
output.
--done::
- Require a `done` command at the end of the stream.
+ Terminate with error if there is no `done` command at the
+ end of the stream.
This option might be useful for detecting errors that
cause the frontend to terminate before it has started to
write a stream.
--
1.8.0.2
^ permalink raw reply related
* Re: What's cooking in git.git (Jan 2013, #03; Sun, 6)
From: John Keeping @ 2013-01-07 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vip79lnnb.fsf@alter.siamese.dyndns.org>
On Sun, Jan 06, 2013 at 06:42:16PM -0800, Junio C Hamano wrote:
> * jk/maint-fast-import-doc-dedup-done (2013-01-05) 1 commit
> - git-fast-import(1): remove duplicate "--done" option
>
> Will merge to 'next' and 'master' as a quick "oops" fix.
>
> The "logical order" reorganization can come after that is done and
> can cook longer in 'next'.
I was going to re-send this to change the quoting of 'done' to `done`,
which is what the original version had. Is there still time for that or
should I send a separate patch?
John
^ permalink raw reply
* Re: recovering a corrupted git repo
From: Christian Couder @ 2013-01-07 9:33 UTC (permalink / raw)
To: Phillip Susi; +Cc: git
In-Reply-To: <50EA44BA.2030107@ubuntu.com>
On Mon, Jan 7, 2013 at 4:44 AM, Phillip Susi <psusi@ubuntu.com> wrote:
>
> I have not had any issue until I ran a git fsck recently, which
> repored gzip and crc errors in some pack files. git fsck does not
> seem to repair the errors, only report them. I would like to try to
> rebuild my repository, without downloading any more from the origin
> than I have to. All of the commits I have added seem to still be
> intact, so I assume the corruption in somewhere in the upstream
> history packs.
>
> How can I correct the errors, and fetch the corrupted upstream
> history, while preserving my patches? So far I have exported my
> patches as bundles, and made a fresh clone from upstream, then pulled
> the bundles back in, but there must be a better way that only fetches
> the corrupted bits from upstream?
The documentation about fixing broken repo is this one:
https://git.wiki.kernel.org/index.php/GitFaq#fix-broken-repo
Hope this helps,
Christian.
^ permalink raw reply
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Pyeron, Jason J CTR (US) @ 2013-01-07 9:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Mark Levedahl, git@vger.kernel.org, Jonathan Nieder,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
In-Reply-To: <7v1udxladc.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]
> -----Original Message-----
> From: Junio C Hamano
> Sent: Monday, January 07, 2013 2:29 AM
>
> Jason Pyeron writes:
>
> [administrivia: please never cull CC list when you respond to a
> message on this list without a good reason]
Apologies, I just have 4 copies of every message and was trying to save other that pain.
>
> >> circumvent the Cygwin API (and by extension, Cygwin project goals).
> >>
> >> So, perhaps a better path forward is to disable / remove the
> >> above code by default. (Those wanting a native Win32 git
> >> should just use the native
> >> Win32 git).
> >
> > Or a make option...
>
> It already is a runtime option, isn't it?
>
> I do not have much stake in this personally, but IIRC, the (l)stat
> workaround was back then found to make Cygwin version from "unusably
> slow" to "slow but torelable", as our POSIX-y codebase assumes that
> lstat is fairly efficient, which Cygwin cannot satisify because it
Is there already a set of test cases I can run to validate that this is still true?
> has call many win32 calls to collect bits that we do not even look
> at, in order to give faithful emulation. It does place extra
> maintenance burden (e.g. conditional compilation depending on the
> header file the particular version of Cygwin installation the user
> has at hand) on us, but as long as it works, the ugly hack is fairly
There seems to be only 2 valid use cases here, with regards to cygwin.
1. Do it the normal posix way, and don’t hack it up.
2. For speed reasons, merge in native windows/non-posix functions.
I would not care about the user's cygwin version because the cygwin supporters won't either. In both cases assume the latest cygwin libraries. If there is a specific user with a use case for an older version of cygwin libraries then we can cross that bridge when (if) we arrive at it.
> isolated and I do not see a reason to unconditionally rip it out,
> especially if the reasoning behind such move is on "All programs
> that run in Cygwin environment has to be POSIX only and must not use
> Win32 API directly, even in a controlled way."
I presently do not care if it stays or goes. But if someone were to bring this to the cygwin mailing list it would be a headache to deal with the "hacked" way. They would likely be more receptive to increasing the efficiency of the lstat than other approaches.
>
> It is a completely different matter if the direct win32 calls we
> make, bypassing (l)stat emulation, somehow change the internal state
> of win32 resources Cygwin controls and violates the invariants
> Cygwin API implemenation expects, breaking later calls to it. I
> do not know that is the case here, but I doubt it.
I agree, it is not going to break anything here. Those libraries are just a way of presenting the Windows API without using Microsoft files and making it easier to wrap the POSIX apis to it.
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] t5002: check if unzip supports symlinks
From: Jonathan Nieder @ 2013-01-07 8:52 UTC (permalink / raw)
To: René Scharfe; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <50E9BB8B.9020101@lsrfire.ath.cx>
René Scharfe wrote:
> Only add a symlink to the repository if both the filesystem and
> unzip support symlinks. To check the latter, add a ZIP file
> containing a symlink, created like this with InfoZIP zip 3.0:
>
> $ echo sample text >textfile
> $ ln -s textfile symlink
> $ zip -y infozip-symlinks.zip textfile symlink
Hm. Do some implementations of "unzip" not support symlinks, or is
the problem that some systems build Info-ZIP without the SYMLINKS
option?
^ permalink raw reply
* Re: [PATCH 2/4] t0024, t5000: use test_lazy_prereq for UNZIP
From: Jonathan Nieder @ 2013-01-07 8:45 UTC (permalink / raw)
To: René Scharfe; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <50E9B90C.2060200@lsrfire.ath.cx>
René Scharfe wrote:
> --- a/t/t0024-crlf-archive.sh
> +++ b/t/t0024-crlf-archive.sh
> @@ -5,6 +5,11 @@ test_description='respect crlf in git archive'
> . ./test-lib.sh
> GIT_UNZIP=${GIT_UNZIP:-unzip}
>
> +test_lazy_prereq UNZIP '
> + "$GIT_UNZIP" -v >/dev/null 2>&1
> + test $? -ne 127
Micronit: now that this is part of a test, there is no more need to
silence its output. The "unzip -v" output could be useful to people
debugging with "t0024-crlf-archive.sh -v -i".
With or without that change, this is a nice cleanup and obviously
correct, so
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH] status: report ignored yet tracked directories
From: Jeff King @ 2013-01-07 8:33 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Torsten Bögershausen, git
In-Reply-To: <CALWbr2yRQai2Z08G2qFbA3AvsgivR-8kQ64SZ4pEktyrf+ZXiQ@mail.gmail.com>
On Sun, Jan 06, 2013 at 05:40:46PM +0100, Antoine Pelisse wrote:
> > Looking at your fix and remembering how the index hashing works, I think
> > the answer is that:
> >
> > 1. This bug only affects directories, because they are the only thing
> > that can be simultaneously "ignored and untracked" and "tracked"
> > (i.e., they have entries of both, and we are using
> > DIR_SHOW_OTHER_DIRECTORIES).
> >
> > 2. When core.ignorecase is false, the index name hash contains only
> > the file entries, and cache_name_exists returns an exact match. So
> > it doesn't matter if we make an extra check when adding the
> > directory via dir_add_name; we know that it will not be there, and
> > the final check is a no-op.
> >
> > 3. When core.ignorecase is true, we also store directory entries in
> > the index name hash, and this extra check is harmful; the entry
> > does not really exist in the index, and we still need to add it.
>
> Yes, because of this couple of lines I guess (name-hash.c, hash_index_entry()):
>
> if (ignore_case)
> hash_index_entry_directories(istate, ce);
Exactly. I couldn't remember at first why this was the case, but after
reading 5102c61 (Add case insensitivity support for directories when
using git status, 2010-10-03) again, I think it is because we cannot do
a partial-name lookup via the hash (i.e., the hash for "foo/" and
"foo/bar" have no relation to each other). Not related to your patch,
obviously, but it was the missing piece for me to understand why the
code was doing what it does.
> > I think in the normal file case, we'd expect treat_path to just tell us
> > that it is handled, and we would not ever call dir_add_name in the first
> > place. But what if we have an index entry for a file, but the working
> > tree now contains a directory?
>
> The directory is treated as any other untracked directory (it never
> matches indexed file because of the trailing /).
Ah, right. That makes sense.
> > I _think_ we still do not hit this code path in that instance, because
> > we will end up in treat_directory, and we will end up checking
> > directory_exists_in_index. And I cannot get it to misbehave in practice.
> > So I think your fix is correct, but the exact how and why is a bit
> > subtle.
>
> Thanks a lot for the help, I will try to come up with a better commit
> message now.
Thanks. I think the patch is right, but the reasoning is just a bit
subtle.
-Peff
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: Jens Lehmann @ 2013-01-07 8:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, W. Trevor King, Git, Peter Collingbourne,
mbranchaud, Michael J Gruber
In-Reply-To: <7vwqvpjv2n.fsf@alter.siamese.dyndns.org>
Am 07.01.2013 08:44, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Am 07.01.2013 02:39, schrieb Jonathan Nieder:
>>> (just cc-ing Jens and Peter, who might be interested)
>>
>> I´m currently working on teaching mv to move submodules and intend
>> to send those patches to the list after finishing submodule deinit.
>
> Thanks for a heads-up.
>
> As a couple of recent "What's cooking" message has stated, I'll
> shortly kick jl/submodule-deinit topic out of 'next' back to 'pu',
> so please make an update a replacement, not an incremental. If I
> recall the discussion correctly, I think we agreed that deinit
> should clear the slate, which means the submodule working tree
> should be removed and made into an empty directory without ".git" in
> it, and the last round we saw on the list didn't do that.
Right, and me thinks that would warrant a --force option for deinit
to do that even if the submodule contains local changes (which would
make deinit fail otherwise). Additionally Michael and Marc spoke up
that they would rather have a --all option to deinit all initialized
submodules and "git submodule deinit" without any arguments should
just produce a usage message. As I saw no voices against it that'll
be part of the next iteration too.
^ permalink raw reply
* Re: [PATCH] git-send-email: treat field names as case-independent
From: Junio C Hamano @ 2013-01-07 7:47 UTC (permalink / raw)
To: Nickolai Zeldovich; +Cc: git
In-Reply-To: <CADGQE7HTB+s2=PWhMZ=1BpU9nruhx5OBhKOY-ngdZJz=vC61uQ@mail.gmail.com>
Nickolai Zeldovich <nickolai@csail.mit.edu> writes:
> On Sun, Jan 6, 2013 at 10:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> While I think this patch is a sensible thing to do, I at the same
>> time wonder who is writing "cc:" in the lowercase in the first
>> place, and if that is one of our tools, we should fix that part as
>> well. Such a header would leak out to the payload given to the
>> underlying sendmail, doesn't it?
>
> In my case, I wrote the "cc:" headers by hand; it was not a result of
> any automated tool.
Ok, thanks for shrinking the list of things that worries me by one ;-)
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: Junio C Hamano @ 2013-01-07 7:44 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, W. Trevor King, Git, Peter Collingbourne
In-Reply-To: <50EA7269.1080006@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> Am 07.01.2013 02:39, schrieb Jonathan Nieder:
>> (just cc-ing Jens and Peter, who might be interested)
>
> I´m currently working on teaching mv to move submodules and intend
> to send those patches to the list after finishing submodule deinit.
Thanks for a heads-up.
As a couple of recent "What's cooking" message has stated, I'll
shortly kick jl/submodule-deinit topic out of 'next' back to 'pu',
so please make an update a replacement, not an incremental. If I
recall the discussion correctly, I think we agreed that deinit
should clear the slate, which means the submodule working tree
should be removed and made into an empty directory without ".git" in
it, and the last round we saw on the list didn't do that.
Thanks.
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Junio C Hamano @ 2013-01-07 7:29 UTC (permalink / raw)
To: Jason Pyeron
Cc: Mark Levedahl, git, Jonathan Nieder, Torsten Bögershausen,
Stephen & Linda Smith, Jason Pyeron, Eric Blake
In-Reply-To: <FBDECCA565D94DF9838DD81FE2E2543A@black>
"Jason Pyeron" <jpyeron@pdinc.us> writes:
[administrivia: please never cull CC list when you respond to a
message on this list without a good reason]
>> circumvent the Cygwin API (and by extension, Cygwin project goals).
>>
>> So, perhaps a better path forward is to disable / remove the
>> above code by default. (Those wanting a native Win32 git
>> should just use the native
>> Win32 git).
>
> Or a make option...
It already is a runtime option, isn't it?
I do not have much stake in this personally, but IIRC, the (l)stat
workaround was back then found to make Cygwin version from "unusably
slow" to "slow but torelable", as our POSIX-y codebase assumes that
lstat is fairly efficient, which Cygwin cannot satisify because it
has call many win32 calls to collect bits that we do not even look
at, in order to give faithful emulation. It does place extra
maintenance burden (e.g. conditional compilation depending on the
header file the particular version of Cygwin installation the user
has at hand) on us, but as long as it works, the ugly hack is fairly
isolated and I do not see a reason to unconditionally rip it out,
especially if the reasoning behind such move is on "All programs
that run in Cygwin environment has to be POSIX only and must not use
Win32 API directly, even in a controlled way."
It is a completely different matter if the direct win32 calls we
make, bypassing (l)stat emulation, somehow change the internal state
of win32 resources Cygwin controls and violates the invariants
Cygwin API implemenation expects, breaking later calls to it. I
do not know that is the case here, but I doubt it.
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: Jens Lehmann @ 2013-01-07 6:59 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: W. Trevor King, Git, Peter Collingbourne
In-Reply-To: <20130107013952.GE3823@elie.Belkin>
Am 07.01.2013 02:39, schrieb Jonathan Nieder:
> (just cc-ing Jens and Peter, who might be interested)
I´m currently working on teaching mv to move submodules and intend
to send those patches to the list after finishing submodule deinit.
Please see
https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules
for the current state of this series.
> W. Trevor King wrote:
>
>> Today I had to move my first submodule, and I discovered that Git's
>> support for this is pretty limited. There have been a few patch
>> series attempting to address this [1,2], but none of them seems to
>> have pushed through into master (although I can't put my finger on a
>> reason for why). There are also some SO postings discussing this
>> [3,4]. It would be nice if `git mv` worked out of the box on
>> submodules. Failing that, there could be a `git submodule mv` command
>> that casts the appropriate spell. Failing that, there could be a
>> recipe in Documentation/git-submodule.txt. Here's the best I could
>> come up with for a `git-submodule-mv.sh`:
>>
>> #!/bin/sh
>> # usage: git-submodule-mv.sh OLD NEW
>> OLD=$(realpath --relative-to . "$1")
>> NEW=$(realpath --relative-to . "$2")
>> SHA=$(git ls-files -s "$OLD" | sed 's|^[0-9]* \([0-9a-f]*\) .*|\1|')
>> NAME=$(git config -f .gitmodules --get-regexp 'submodule\..*\.path' "$OLD" |
>> sed -e 's|^submodule.||' -e "s|.path $OLD\$||")
>> GITDIR=$(realpath --relative-to "$NEW" .git/modules/"$NAME")
>> git config -f .gitmodules submodule."$NAME".path "$NEW"
>> git config -f .git/modules/"$NAME"/config core.worktree "../../../$NEW"
>> git rm --cached "$OLD"
>> mv "$OLD" "$NEW"
>> echo "gitdir: $GITDIR" > "$NEW/.git"
>> git update-index --add --cacheinfo 160000 "$SHA" "$NEW"
>>
>> This only works from the repository root directory, and I'm sure makes
>> a number of poor assumptions (e.g. old-style submodules that don't use
>> `gitdir` links are not supported). It does work for some simple test
>> cases. The tricky parts (e.g. path -> name conversion) are already
>> worked out more robustly git-submodule.sh, so adding a new cmd_mv
>> shouldn't be very difficult.
>>
>> Could something like this live somewhere in Git, or are we waiting for
>> a more integrated solution?
>>
>> Cheers,
>> Trevor
>>
>> [1]: http://thread.gmane.org/gmane.comp.version-control.git/88720
>> [2]: http://thread.gmane.org/gmane.comp.version-control.git/143250
>> [4]: http://stackoverflow.com/questions/4323558/moving-submodules-with-git
>> [3]: http://stackoverflow.com/questions/4604486/how-do-i-move-an-existing-git-submodule-within-a-git-repository
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ 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