* 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: 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
* 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: 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: 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: 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: 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: 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: [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: 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] 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: [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 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: 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: 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: 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
* [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: 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
* 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: [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 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: [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: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: [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] 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
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