* 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
* RE: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Jason Pyeron @ 2013-01-07 5:37 UTC (permalink / raw)
To: git
In-Reply-To: <50E9F7C2.1000603@gmail.com>
> -----Original Message-----
> From: Mark Levedahl
> Sent: Sunday, January 06, 2013 17:17
>
> On 01/06/2013 02:54 PM, Junio C Hamano wrote:
> > Jonathan Nieder <jrnieder@gmail.com> writes:
> >
> >> Mark Levedahl wrote:
> >>
> >>>
> However,
> >>> the newer win32api is provided only for the current
> cygwin release
> >>> series, which can be reliably identified by having dll version
> >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from
> >>> redhat, 1.5.x open source) still have the older api as no
> updates are being made for the legacy version(s).
> >> Ah. That makes sense, thanks.
> >>
> >> (For the future, if we wanted to diagnose an out-of-date
> win32api and
> >> print a helpful message, I guess cygcheck would be the command to
> >> use.)
> > Hmph, so we might see somebody who cares about Cygwin to
> come up with
> > a solution based on cygcheck (not on uname) to update this part,
> > perhaps on top of Peff's "split default settings based on
> uname into
> > separate file" patch?
> >
> > If I understood what Mark and Torsten wrote correctly, you
> will have
> > the new win32api if you install 1.7.17 (or newer) from
> scratch, but if
> > you are on older 1.7.x then you can update the win32api part as a
> > package update (as opposed to the whole-system upgrade). A
> test based
> > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14)
> > installation has a newer win32api because the user updated
> it from the
> > package (hence the user should not define CYGWIN_V15_WIN32API).
> >
> > Am I on the same page as you guys, or am I still behind?
> >
> > In the meantime, perhaps we would need something like this?
>
> It's perhaps worth noting how we got into this mess. The
> problems have their root in
>
> adbc0b6b6e57c11ca49779d01f549260a920a97d
>
> Cygwin's entire goal is a completely POSIX compliant
> environment running under Windows. The above commit
> circumvents some of Cygwin's API regarding stat/fstat to make
> things perhaps a bit faster, and definitely not POSIX
Ug!
> compliant (The commit message is wrong, the commit definitely
> breaks POSIX compliance). That code is also what will not
> compile on different w32api versions. It is curious: the
> Cygwin mailing list has been absolutely silent since the
> w32api change was introduced last summer, this is the only
> piece of code I am aware of that was broken by the new
> headers, and of course the purpose of this code is to
Um, going out on a limb here, but those headers are used internally as "cygwin"
apps are most likely to now know about those headers.
> 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...
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply
* RE: Nike Air Max Shop
From: Jason Pyeron @ 2013-01-07 5:27 UTC (permalink / raw)
To: git
In-Reply-To: <1357529831380-7574402.post@n2.nabble.com>
Is there a practical way to eliminate the spam here? Could vger.kernel.org use a
postini (list maintainers contact me offline about this) account?
-Jason
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100 -
- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
^ permalink raw reply
* Re: [PATCH 1/4] t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
From: Jonathan Nieder @ 2013-01-07 5:16 UTC (permalink / raw)
To: René Scharfe; +Cc: git discussion list, Junio C Hamano
In-Reply-To: <50E9B8CD.2010209@lsrfire.ath.cx>
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?
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>
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #03; Sun, 6)
From: Junio C Hamano @ 2013-01-07 5:13 UTC (permalink / raw)
To: Adam Spiers; +Cc: git
In-Reply-To: <7vehhxllvz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I forgot to say that tonight's 'pu' seems to break t0008 and does
> not pass the self-test. I didn't try figuring out if this is the
> result of some mismerge, or one (or more) of the topics are broken.
An addendum. This comes from the check-ignore patch and seems to
manifest itself when the test is run under /bin/dash (not bash).
Due to the mini-harness the test introduces, the output from running
the script with "-v -i" was not very helpful, and I stopped digging
at that point.
$ dash t0008-ignores.sh -i -v
...
expecting success:
expect "$expect" &&
eval "$code"
not ok - 64 existing tracked file at top-level not ignored
#
# expect "$expect" &&
# eval "$code"
#
^ permalink raw reply
* recovering a corrupted git repo
From: Phillip Susi @ 2013-01-07 3:44 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQEcBAEBAgAGBQJQ6kS6AAoJEJrBOlT6nu75tFgIAJCI+DEWDVxddEQM5qhmz1y8
3JuqjTHp7gIXmQv6WGbEIehJrRfTBudQn+Ip2jLMwavvL16oZe+cf/uuLo393Z+T
pxEcWHOtjdU/XZeQOV//R/Cfo7PY5n8wfasgFYZuFesJchInwFocTI6S5x2B9kIB
dvLonoiDQwe9JqQaoAxM0OLTWe9aj0gc3c36+WUlRgRZijUhEogYQwU8aEoa+TMq
s2p+tbaNYKocRAafQ4824DMnuQTWb+HJVU4uI1pH2yB964Urq9ELSX2jxeSRdlaH
d+AoJ8oMdymmUwPeuyivcmQQHEGGsxxgCOuLSSHh1hcxMaytZNcEkVQ6OzuGyZk=
=yUr4
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git push --force to update tag
From: Chris Rorvick @ 2013-01-07 3:42 UTC (permalink / raw)
To: 乙酸鋰; +Cc: git
In-Reply-To: <CAHtLG6Ss=KE8j_VZWf77A9FXantnwJvdDi1uoN9M-XO0c9GgEQ@mail.gmail.com>
On Sun, Jan 6, 2013 at 8:23 PM, 乙酸鋰 <ch3cooli@gmail.com> wrote:
> about git 1.8.2
>
> * "git push" now requires "-f" to update a tag, even if it is a
> fast-forward, as tags are meant to be fixed points.
>
> Does the server side validate this? Do we need to upgrade git on
> server side to support this?
This check is made by the side doing the push. There is no additional
validation done on the remote side so it does not need an updated
version of Git for this feature to work correctly.
Chris
^ permalink raw reply
* Re: [PATCH] git-send-email: treat field names as case-independent
From: Nickolai Zeldovich @ 2013-01-07 3:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7va9sllljh.fsf@alter.siamese.dyndns.org>
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. (Yes, the header makes it into the message
payload. This makes the bug all the more annoying: other people's
replies get cc:ed to the right address, but the original message never
gets sent there.)
Nickolai.
^ permalink raw reply
* Re: [PATCH] git-send-email: treat field names as case-independent
From: Junio C Hamano @ 2013-01-07 3:27 UTC (permalink / raw)
To: Nickolai Zeldovich; +Cc: git
In-Reply-To: <1357522498-8086-1-git-send-email-nickolai@csail.mit.edu>
Nickolai Zeldovich <nickolai@csail.mit.edu> writes:
> Field names like To:, Cc:, etc should be treated as case-independent;
> use a case-insensitive regexp to match them as such. Previously,
> git-send-email would send email messages with a lowercase "cc:" line in
> the body without actually sending a copy of the message to that address.
>
> Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
> ---
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?
Leaking such lowercased headers of course is not a crime (the
headers are case insensitive), but they look ugly.
> git-send-email.perl | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 94c7f76..be809e5 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1285,10 +1285,10 @@ foreach my $t (@files) {
> }
>
> if (defined $input_format && $input_format eq 'mbox') {
> - if (/^Subject:\s+(.*)$/) {
> + if (/^Subject:\s+(.*)$/i) {
> $subject = $1;
> }
> - elsif (/^From:\s+(.*)$/) {
> + elsif (/^From:\s+(.*)$/i) {
> ($author, $author_encoding) = unquote_rfc2047($1);
> next if $suppress_cc{'author'};
> next if $suppress_cc{'self'} and $author eq $sender;
> @@ -1296,14 +1296,14 @@ foreach my $t (@files) {
> $1, $_) unless $quiet;
> push @cc, $1;
> }
> - elsif (/^To:\s+(.*)$/) {
> + elsif (/^To:\s+(.*)$/i) {
> foreach my $addr (parse_address_line($1)) {
> printf("(mbox) Adding to: %s from line '%s'\n",
> $addr, $_) unless $quiet;
> push @to, $addr;
> }
> }
> - elsif (/^Cc:\s+(.*)$/) {
> + elsif (/^Cc:\s+(.*)$/i) {
> foreach my $addr (parse_address_line($1)) {
> if (unquote_rfc2047($addr) eq $sender) {
> next if ($suppress_cc{'self'});
> @@ -1325,7 +1325,7 @@ foreach my $t (@files) {
> elsif (/^Message-Id: (.*)/i) {
> $message_id = $1;
> }
> - elsif (!/^Date:\s/ && /^[-A-Za-z]+:\s+\S/) {
> + elsif (!/^Date:\s/i && /^[-A-Za-z]+:\s+\S/) {
> push @xh, $_;
> }
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #03; Sun, 6)
From: Junio C Hamano @ 2013-01-07 3:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vip79lnnb.fsf@alter.siamese.dyndns.org>
I forgot to say that tonight's 'pu' seems to break t0008 and does
not pass the self-test. I didn't try figuring out if this is the
result of some mismerge, or one (or more) of the topics are broken.
^ permalink raw reply
* What's cooking in git.git (Jan 2013, #03; Sun, 6)
From: Junio C Hamano @ 2013-01-07 2:42 UTC (permalink / raw)
To: git
What's cooking in git.git (Jan 2013, #03; Sun, 6)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'next' will be rewound and rebuilt shortly, kicking a
couple of topics back to 'pu' and reordering the remainder as
needed.
As usual, this cycle is expected to last for 8 to 10 weeks. To
ensure the quality of the end result, let's merge topics in flight
earlier than previous cycles to 'next' and fix issues in-tree.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Various updates to fast-export used in the context of the remote
helper interface.
* ja/directory-attrs (2012-12-17) 1 commit
(merged to 'next' on 2012-12-17 at ced8e73)
+ Add directory pattern matching to attributes
The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.
* jc/fetch-ignore-symref (2012-12-11) 1 commit
(merged to 'next' on 2012-12-17 at 370e2c8)
+ fetch: ignore wildcarded refspecs that update local symbolic refs
Avoid false error from an attempt to update local symbolic ref via
fetch.
* jc/format-color-auto (2012-12-17) 2 commits
(merged to 'next' on 2012-12-18 at 5aaac94)
+ log --format: teach %C(auto,black) to respect color config
+ t6006: clean up whitespace
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
* jk/complete-commit-c (2012-12-15) 1 commit
(merged to 'next' on 2012-12-18 at 75b5f21)
+ completion: complete refs for "git commit -c"
Complete "git commmit -c foo<TAB>" into a refname that begins with
"foo".
* jk/error-const-return (2012-12-15) 2 commits
(merged to 'next' on 2012-12-22 at bf2b1cd)
+ silence some -Wuninitialized false positives
+ make error()'s constant return value more visible
Help compilers' flow analysis by making it more explicit that
error() always returns -1, to reduce false "variable used
uninitialized" warnings. Looks somewhat ugly but not too much.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
* jk/mailmap-from-blob (2012-12-13) 5 commits
(merged to 'next' on 2012-12-17 at 14b7cdc)
+ mailmap: default mailmap.blob in bare repositories
+ mailmap: fix some documentation loose-ends for mailmap.blob
+ mailmap: clean up read_mailmap error handling
+ mailmap: support reading mailmap from blobs
+ mailmap: refactor mailmap parsing for non-file sources
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Optimize matching paths with common forms of pathspecs that contain
wildcard characters.
* wk/submodule-update-remote (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 7ddf897)
+ submodule add: If --branch is given, record it in .gitmodules
+ submodule update: add --remote for submodule's upstream changes
+ submodule: add get_submodule_config helper funtion
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
--------------------------------------------------
[New Topics]
* jk/pathspec-literal (2013-01-06) 1 commit
- t6130-pathspec-noglob: Windows does not allow a file named "f*"
Will merge to 'next' and 'master' as a quick "oops" fix.
* as/dir-c-cleanup (2012-12-28) 10 commits
- dir.c: rename free_excludes() to clear_exclude_list()
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
- Improve documentation and comments regarding directory traversal API
- api-directory-listing.txt: update to match code
(this branch is used by as/check-ignore.)
Separated an earlier and more solidly done bits from the other
topic.
Will merge to 'next'.
* jk/config-uname (2013-01-03) 1 commit
- Makefile: hoist uname autodetection to config.mak.uname
Move the bits to set fallback default based on the platform from
the main Makefile to a separate file, so that it can be included in
Makefiles in subdirectories.
Will merge to 'next'.
* jc/push-2.0-default-to-simple (2013-01-04) 10 commits
- push: switch default from "matching" to "simple"
- t9401: do not assume the "matching" push is the default
- t9400: do not assume the "matching" push is the default
- t7406: do not assume the "matching" push is the default
- t5531: do not assume the "matching" push is the default
- t5519: do not assume the "matching" push is the default
- t5517: do not assume the "matching" push is the default
- t5516: do not assume the "matching" push is the default
- t5505: do not assume the "matching" push is the default
- t5404: do not assume the "matching" push is the default
Will merge to 'next' and cook there until Git 2.0.
* 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'.
* jk/unify-exit-code-by-receiving-signal (2013-01-06) 1 commit
- run-command: encode signal death as a positive integer
The internal logic had to deal with two representations of a death
of a child process by a signal.
Will merge to 'next'.
* jl/interrupt-clone-remove-separate-git-dir (2013-01-05) 1 commit
- clone: support atomic operation with --separate-git-dir
When "git clone --separate-git-dir" is interrupted, we failed to
remove the real location we created the repository.
Will merge to 'next'.
* rs/leave-base-name-in-name-field-of-tar (2013-01-05) 1 commit
- archive-tar: split long paths more carefully
Improve compatibility with implementations of "tar" that do not
like empty name field in header (with the additional prefix field
holding everything).
Will merge to 'next'.
* as/api-allocation-doc (2013-01-06) 1 commit
- api-allocation-growing.txt: encourage better variable naming
Will merge to 'next'.
* jc/comment-cygwin-win32api-in-makefile (2013-01-06) 1 commit
- Makefile: add comment on CYGWIN_V15_WIN32API
Will merge to 'next'.
* jn/xml-depends-on-asciidoc-conf (2013-01-06) 1 commit
- docs: manpage XML depends on asciidoc.conf
Will merge to 'next'.
* nd/clone-no-separate-git-dir-with-bare (2013-01-06) 1 commit
- clone: forbid --bare --separate-git-dir <dir>
Expecting a reroll.
$gmane/212863
* nd/parse-pathspec (2013-01-06) 21 commits
- Convert more init_pathspec() to parse_pathspec()
- Convert add_files_to_cache to take struct pathspec
- Convert {read,fill}_directory to take struct pathspec
- Convert refresh_index to take struct pathspec
- Convert report_path_error to take struct pathspec
- checkout: convert read_tree_some to take struct pathspec
- Convert unmerge_cache to take struct pathspec
- Convert read_cache_preload() to take struct pathspec
- add: convert to use parse_pathspec
- archive: convert to use parse_pathspec
- ls-files: convert to use parse_pathspec
- rm: convert to use parse_pathspec
- checkout: convert to use parse_pathspec
- rerere: convert to use parse_pathspec
- status: convert to use parse_pathspec
- commit: convert to use parse_pathspec
- clean: convert to use parse_pathspec
- Export parse_pathspec() and convert some get_pathspec() calls
- pathspec: make sure the prefix part is wildcard-clean
- Add parse_pathspec() that converts cmdline args to struct pathspec
- pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Unfortunately, this conflicts a couple of topics in flight. I tried
to be careful while resolving conflicts, though.
* rs/zip-tests (2013-01-06) 4 commits
- t5003: check if unzip supports symlinks
- t5000, t5003: move ZIP tests into their own script
- t0024, t5000: use test_lazy_prereq for UNZIP
- t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
Updates zip tests to skip some that cannot be handled on platform
unzip.
I've renamed the t5002 in the original to t5003 to avoid name
clashes with another topic in flight.
Will merge to 'next'.
* rs/zip-with-uncompressed-size-in-the-header (2013-01-06) 1 commit
- archive-zip: write uncompressed size into header even with streaming
Improve compatibility of our zip output to fill uncompressed size
in the header, which we can do without seeking back (even though it
should not be necessary).
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
But this does not yet do so (does not remove the checkout of the
submodule). The design discussion petered out.
http://thread.gmane.org/gmane.comp.version-control.git/210867/focus=211456
Will kick back to 'pu'.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
Will kick back to 'pu'.
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* jn/less-reconfigure (2013-01-02) 1 commit
(merged to 'next' on 2013-01-02 at e5cd6cf)
+ build: do not automatically reconfigure unless configure.ac changed
When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
Will merge to 'master'.
* ap/merge-stop-at-prepare-commit-msg-failure (2013-01-03) 1 commit
(merged to 'next' on 2013-01-04 at 251e88b)
+ merge: Honor prepare-commit-msg return code
"git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook. t7505 may want a general clean-up but that is
a different topic.
Will merge to 'master'.
* tb/test-shell-lint (2013-01-02) 1 commit
(merged to 'next' on 2013-01-04 at 0289566)
+ test: Add check-non-portable-shell.pl
Check for common mistakes in the test scripts, based on simple
pattern-matching.
* jk/enable-test-lint-by-default (2013-01-03) 1 commit
(merged to 'next' on 2013-01-04 at 65b21ad)
+ tests: turn on test-lint by default
We had two simple and quick tests to catch common mistakes when
writing test scripts, but they weren't run by default when running
tests.
Will merge to 'master'.
* jc/doc-maintainer (2013-01-03) 2 commits
- howto/maintain: mark titles for asciidoc
- Documentation: update "howto maintain git"
Describe tools for automation that were invented since this
document was originally written.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
In the longer term, tightening rules is a good thing to do, and
because nobody who has worked in the remote helper area seems to be
interested in reviewing this, I would assume they do not think
such a retroactive tightening will affect their remote helpers. So
let's advance this topic to see what happens.
* fc/remote-bzr (2013-01-02) 9 commits
(merged to 'next' on 2013-01-04 at 7791dcb)
+ remote-bzr: detect local repositories
+ remote-bzr: add support for older versions of bzr
+ remote-bzr: add support to push special modes
+ remote-bzr: add support for fecthing special modes
+ remote-bzr: add simple tests
+ remote-bzr: update working tree upon pushing
+ remote-bzr: add support for remote repositories
+ remote-bzr: add support for pushing
+ Add new remote-bzr transport helper
New remote helper for bzr, with minimum fix squashed in.
Will merge to 'master'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
As nobody seems to be stepping up to review this, I am tempted to
merge this to 'next and see who screams.
Will merge to 'next'.
* jc/submittingpatches (2013-01-02) 4 commits
(merged to 'next' on 2013-01-04 at 060ffb0)
+ SubmittingPatches: give list and maintainer addresses
+ SubmittingPatches: remove overlong checklist
+ SubmittingPatches: mention subsystems with dedicated repositories
+ SubmittingPatches: who am I and who cares?
Streamline the document and update with a few e-mail addresses the
patches should be sent to.
Will merge to 'master'.
* kb/maint-bundle-doc (2013-01-01) 2 commits
(merged to 'next' on 2013-01-04 at 73486d9)
+ Documentation: full-ness of a bundle is significant for cloning
+ Documentation: correct example restore from bundle
Will merge to 'master'.
* nd/maint-branch-desc-doc (2013-01-03) 5 commits
(merged to 'next' on 2013-01-04 at d05a47f)
+ format-patch: pick up branch description when no ref is specified
+ format-patch: pick up correct branch name from symbolic ref
+ t4014: a few more tests on cover letter using branch description
+ branch: delete branch description if it's empty
+ config.txt: a few lines about branch.<name>.description
Teach various forms of "format-patch" command line to identify what
branch the patches are taken from, so that the branch description
is picked up in more cases.
Will merge to 'master'.
* tb/test-t9020-no-which (2013-01-01) 1 commit
(merged to 'next' on 2013-01-04 at 0bcf646)
+ t9020: which is not portable
Will merge to 'master'.
* tb/test-t9810-no-sed-i (2013-01-01) 1 commit
(merged to 'next' on 2013-01-04 at 0da03e6)
+ t9810: Do not use sed -i
Will merge to 'master'.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
(merged to 'next' on 2013-01-02 at b9db3a2)
+ rebase: Handle cases where format-patch fails
Save output from format-patch command in a temporary file, just in
case it aborts, to give a better failure-case behaviour.
* ap/status-ignored-in-ignored-directory (2013-01-06) 3 commits
- status: always report ignored tracked directories
(merged to 'next' on 2013-01-04 at 114fb2f)
+ git-status: Test --ignored behavior
+ dir.c: Make git-status --ignored more consistent
Output from "git status --ignored" showed an unexpected interaction
with "--untracked".
* ta/remove-stale-translated-tut (2012-12-27) 1 commit
(merged to 'next' on 2013-01-02 at e70df8e)
+ Remove Documentation/pt_BR/gittutorial.txt
Remove a translation of a document that was left stale.
Will merge to 'master'.
* er/stop-recommending-parsecvs (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at fd816dd)
+ Remove the suggestion to use parsecvs, which is currently broken.
Stop recommending a defunct third-party software.
Will merge to 'master'.
* as/test-name-alias-uniquely (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at e297810)
+ Use longer alias names in subdirectory tests
A few short-and-bland aliases used in the tests were interfering
with git-custom command in user's $PATH.
Will merge to 'master'.
* jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at 8795e87)
+ merge --no-edit: do not credit people involved in the side branch
Stop spending cycles to compute information to be placed on
commented lines in "merge --no-edit".
Will merge to 'master'.
* as/check-ignore (2013-01-06) 11 commits
- add git-check-ignore sub-command
- setup.c: document get_pathspec()
- add.c: extract new die_if_path_beyond_symlink() for reuse
- add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
- pathspec.c: rename newly public functions for clarity
- add.c: move pathspec matchers into new pathspec.c for reuse
- add.c: remove unused argument from validate_pathspec()
- dir.c: improve docs for match_pathspec() and match_pathspec_depth()
- dir.c: provide clear_directory() for reclaiming dir_struct memory
- dir.c: keep track of where patterns came from
- dir.c: use a single struct exclude_list per source of excludes
(this branch uses as/dir-c-cleanup.)
Rerolled.
* jc/format-patch-reroll (2013-01-03) 9 commits
(merged to 'next' on 2013-01-04 at 6840dbd)
+ format-patch: give --reroll-count a short synonym -v
+ format-patch: document and test --reroll-count
+ format-patch: add --reroll-count=$N option
+ get_patch_filename(): split into two functions
+ get_patch_filename(): drop "just-numbers" hack
+ get_patch_filename(): simplify function signature
+ builtin/log.c: stop using global patch_suffix
+ builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
+ builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
Will merge to 'master'.
* mz/pick-unborn (2012-12-23) 2 commits
(merged to 'next' on 2013-01-02 at 22b9951)
+ learn to pick/revert into unborn branch
+ tests: move test_cmp_rev to test-lib-functions
Allows "git cherry-pick $commit" when you do not have any history
behind HEAD yet.
* nd/retire-fnmatch (2013-01-01) 7 commits
(merged to 'next' on 2013-01-04 at 4dc3ff1)
+ Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
+ wildmatch: advance faster in <asterisk> + <literal> patterns
+ wildmatch: make a special case for "*/" with FNM_PATHNAME
+ test-wildmatch: add "perf" command to compare wildmatch and fnmatch
+ wildmatch: support "no FNM_PATHNAME" mode
+ wildmatch: make dowild() take arbitrary flags
+ wildmatch: rename constants and update prototype
(this branch uses nd/wildmatch.)
Replace our use of fnmatch(3) with a more feature-rich wildmatch.
A handful patches at the bottom have been moved to nd/wildmatch to
graduate as part of that branch, before this series solidifies.
* os/gitweb-highlight-uncaptured (2013-01-01) 1 commit
(merged to 'next' on 2013-01-04 at d565cdd)
+ gitweb: fix error in sanitize when highlight is enabled
The code to sanitize control characters before passing it to
"highlight" filter lost known-to-be-safe control characters by
mistake.
Will merge to 'master'.
* jc/merge-blobs (2012-12-26) 5 commits
- merge-tree: fix d/f conflicts
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
Update the disused merge-tree proof-of-concept code.
Will merge to 'next'.
* er/python-version-requirements (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at 1023a3f)
+ Add checks to Python scripts for version dependencies.
Some python scripts we ship cannot be run with old versions of the
interpreter.
Will merge to 'master'.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* mz/oneway-merge-wo-u-no-lstat (2012-12-20) 1 commit
(merged to 'next' on 2012-12-22 at 87bd30e)
+ oneway_merge(): only lstat() when told to update worktree
Optimize "read-tree -m <tree-ish>" without "-u".
Will merge to 'master'.
* cc/no-gitk-build-dependency (2012-12-18) 3 commits
(merged to 'next' on 2012-12-22 at da7b2cf)
+ Makefile: replace "echo 1>..." with "echo >..."
+ Makefile: detect when PYTHON_PATH changes
+ Makefile: remove tracking of TCLTK_PATH
Remove leftover bits from an earlier change to move gitk in its own
subdirectory. Reimplementing the dependency tracking rules needs
to be done in gitk history separately.
Will merge to 'master'.
* zk/clean-report-failure (2013-01-06) 1 commit
- git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
Rerolled.
* mp/complete-paths (2012-12-21) 1 commit
- git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
It has been reported (no surprise) that this does not work inside
subdirectory. $gmane/212642
Waiting for area-experts' review.
* ap/log-mailmap (2013-01-06) 10 commits
- log: add log.mailmap configuration option
- log: grep author/committer using mailmap
- test: add test for --use-mailmap option
- log: add --use-mailmap option
- pretty: use mailmap to display username and email
- mailmap: add mailmap structure to rev_info and pp
- mailmap: simplify map_user() interface
- mailmap: remove email copy and length limitation
- Use split_ident_line to parse author and committer
- list_lookup: create case and length search
Clean up various codepaths around mailmap and teach the "log"
machinery to use it.
Rerolled.
* bc/append-signed-off-by (2013-01-01) 12 commits
- t4014: do not use echo -n
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a reroll.
$gmane/212507
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
Deal with a situation where .config/git is a file and we notice
.config/git/config is not readable due to ENOTDIR, not ENOENT.
Will merge to 'master'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will merge to 'master'.
* nd/wildmatch (2013-01-01) 18 commits
(merged to 'next' on 2013-01-01 at 8c633a5)
+ wildmatch: replace variable 'special' with better named ones
+ compat/fnmatch: respect NO_FNMATCH* even on glibc
+ wildmatch: fix "**" special case
(merged to 'next' on 2012-12-15 at c734714)
+ t3070: Disable some failing fnmatch tests
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch is used by nd/retire-fnmatch.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
--------------------------------------------------
[Discarded]
* jc/doc-default-format (2013-01-03) 2 commits
. Allow installing a non-default set of documentation
. Allow generating a non-default set of documentation
Instead of the default of generating html/man and installing man,
you can control what "make doc" and "make install-doc" do via two
make variables.
^ 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