In git 2.1.4, I can run: git pull --upload-pack 'echo --foo'
This also seems to work in 2.4.6, but in 2.5.0, the option parser
does something weird, apparently looking inside the quoted parameter
and parsing parameters in there:
error: unknown option `foo'
usage: git fetch [] [ [...]]
Needless t
I think this comes down to a lack of quoting where git-pull runs
git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
"$@" was passed through to git-fetch, but now there is a $upload_pack
which is passed without being quoted.
--
see shy jo
signature.asc
Description: Digital signature
joey@darkstar:~/tmp>git init --shared=world testrepo
Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
joey@darkstar:~/tmp>grep shared testrepo/.git/config
sharedrepository = 2
This magic value of 2 seems to be undocumented, as is the magic value of 1
that's equvila
tab complete. An
inconsistent UI..
So, if the git completion script is unable to find the wanted
_git_$command function, have it fall-back to looking for a git-$command
completion script, and loading it. The add-on script is looked for in the
same directory as the git completion script, which we can fi
Reroll of this patch set with changes:
* Added additional smudgeToFile calls in git am and recursive merge.
* Improved behavior when smudgeToFile filter fails.
* Some small improvements to the test cases.
I hope this will be the final version.
Joey Hess (8):
clarify %f documentation
add
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess
---
Documentation/gitattributes.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index e3b1de8..145dd10 1
If the smudgeToFile filter fails, it can leave the worktree file with the
wrong content, or even deleted. Recover from this by falling back to
running the smudge filter.
Signed-off-by: Joey Hess
---
entry.c | 55 ---
t/t0021
Let the user know when they have a smudgeToFile/cleanFromFile config
that cannot be used because the corresponding smudge/clean config
is missing.
The warning is only displayed a maximum of once per git invocation,
and only when doing an operation that would use the filter.
Signed-off-by: Joey
git that does not support them.
Signed-off-by: Joey Hess
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 ++
convert.c | 108 ++--
convert.h | 10
4 files
Includes test cases.
Signed-off-by: Joey Hess
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index d5e1121
Recursive merge updates the work tree and so should use the smudgeToFile
filter.
At this point, smudgeToFile is run by everything that updates work
tree files.
Signed-off-by: Joey Hess
---
merge-recursive.c | 42 --
t/t0021-conversion.sh | 16
This makes git checkout, git reset, etc use smudgeToFile.
Includes test cases.
(There's a call to convert_to_working_tree in merge-recursive.c
that could also be made to use smudgeToFile as well.)
Signed-off-by: Joey Hess
---
entry.c | 37 +--
git am updates the work tree and so should use the smudgeToFile filter.
This includes some refactoring into convert_to_working_tree_filter_to_file
to make it check the file after running the smudgeToFile command, and clean
up from a failing command.
Signed-off-by: Joey Hess
---
builtin/apply.c
This is the same as v3, except rebased on top of tb/convert-peek-in-index
to fix a build failure in pu.
Joey Hess (8):
clarify %f documentation
add smudgeToFile and cleanFromFile filter configs
use cleanFromFile in git add
use smudgeToFile in git checkout etc
warn on unusable
This makes git checkout, git reset, etc use smudgeToFile.
Includes test cases.
(There's a call to convert_to_working_tree in merge-recursive.c
that could also be made to use smudgeToFile as well.)
Signed-off-by: Joey Hess
---
entry.c | 37 +--
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess
---
Documentation/gitattributes.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index f2afdb6..197ece8 1
If the smudgeToFile filter fails, it can leave the worktree file with the
wrong content, or even deleted. Recover from this by falling back to
running the smudge filter.
Signed-off-by: Joey Hess
---
entry.c | 55 ---
t/t0021
Recursive merge updates the work tree and so should use the smudgeToFile
filter.
At this point, smudgeToFile is run by everything that updates work
tree files.
Signed-off-by: Joey Hess
---
merge-recursive.c | 42 --
t/t0021-conversion.sh | 16
Torsten Bögershausen wrote:
> There is a conflict in pu:
> "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
>
> (And currently pu didn't compile)
I'm sending a v4 of jh/clean-smudge-annex that is rebased on top of
tb/convert-peek-in-index to fix this.
> (I will hope
git am updates the work tree and so should use the smudgeToFile filter.
This includes some refactoring into convert_to_working_tree_filter_to_file
to make it check the file after running the smudgeToFile command, and clean
up from a failing command.
Signed-off-by: Joey Hess
---
builtin/apply.c
Let the user know when they have a smudgeToFile/cleanFromFile config
that cannot be used because the corresponding smudge/clean config
is missing.
The warning is only displayed a maximum of once per git invocation,
and only when doing an operation that would use the filter.
Signed-off-by: Joey
Includes test cases.
Signed-off-by: Joey Hess
---
sha1_file.c | 44 ++--
t/t0021-conversion.sh | 36
2 files changed, 74 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 55604b6
git that does not support them.
Signed-off-by: Joey Hess
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 +
convert.c | 114 ++--
convert.h | 11
4 files
larsxschnei...@gmail.com wrote:
> (2) Joey's topic, which is the base for my patch, looks stalled for more than
> 2 weeks:
> http://thread.gmane.org/gmane.comp.version-control.git/297994/focus=298006
> I would be happy to address Junio's comments and post a reroll. However,
> I don't want to interf
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess
---
Documentation/gitattributes.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index f2afdb6..197ece8 1
Let the user know when they have a smudgeToFile/cleanFromFile config
that cannot be used because the corresponding smudge/clean config
is missing.
The warning is only displayed a maximum of once per git invocation,
and only when doing an operation that would use the filter.
Signed-off-by: Joey
Recursive merge updates the work tree and so should use the smudgeToFile
filter.
At this point, smudgeToFile is run by everything that updates work
tree files.
Signed-off-by: Joey Hess
---
merge-recursive.c | 53 ---
t/t0021-conversion.sh
Includes test cases.
Signed-off-by: Joey Hess
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 2fc22b0
This makes git checkout, git reset, etc use smudgeToFile.
Includes test cases.
(There's a call to convert_to_working_tree in merge-recursive.c
that could also be made to use smudgeToFile as well.)
Signed-off-by: Joey Hess
---
entry.c
nvert-peek-in-index is at this point?
Improvements from Junio's review:
fix build with DEVELOPER=1
style fixes
use test_cmp in test cases
improve robustness of a test case
clean up some confusing code
small performance tweak
Joey Hess (8):
git that does not support them.
Signed-off-by: Joey Hess
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 ++
convert.c | 111 +++-
convert.h | 10
4 files
git am updates the work tree and so should use the smudgeToFile filter.
This includes some refactoring into convert_to_working_tree_filter_to_file
to make it check the file after running the smudgeToFile command, and clean
up from a failing command.
Signed-off-by: Joey Hess
---
apply.c
If the smudgeToFile filter fails, it can leave the worktree file with the
wrong content, or even deleted. Recover from this by falling back to
running the smudge filter.
Signed-off-by: Joey Hess
---
entry.c | 66 ++-
t/t0021
Torsten Bögershausen wrote re jh/clean-smudge-annex:
> The thing is that we need to check the file system to find .gitatttibutes,
> even if we just did it 1 nanosecond ago.
>
> So the .gitattributes is done 3 times:
> -1 would_convert_to_git_filter_fd(
> -2 assert(would_convert_to_git_filter_fd(pa
I'm using smudge/clean filters in git-annex now, and it's not been an
entirely smooth fit between the interface and what git-annex wants
to do.
The clean filter has to consume the whole file content on stdin;
not reading it all will make git think the clean filter failed.
But, git-annex often does
Junio C Hamano wrote:
> This side, I do not think we even need a new variant. We can just
> update the code to interact with "clean" so that it the writer to
> the pipe ignores SIGPIPE, detects EPIPE on write(2), says "ah, the
> other end does not need the full input to produce its output". The
>
Junio C Hamano wrote:
> The smudge happens to be the last to run, so it is quite true that
> it can say "Hey Git, I've written it out already".
>
> I didn't check all codepaths to ensure that we won't need the
> smudged result in core at all, but I am guessing you did so before
> making this propo
Junio C Hamano wrote:
> > Secondly, and harder to get around, the filename passed to the clean
> > filter is not necessarily a path to the actual existing file that is
> > being cleaned.
>
> Either one of us is confused. I was talking about updating the
> current "clean" implementation without ch
joey@darkstar:/tmp>git init test
Initialized empty Git repository in /tmp/test/.git/
joey@darkstar:/tmp>cd test
joey@darkstar:/tmp/test>mkdir sub
joey@darkstar:/tmp/test>cd sub
joey@darkstar:/tmp/test/sub>GIT_INDEX_FILE=../.git/otherindex git write-tree
fatal: Unable to create '/tmp/test/../.git/ot
Junio C Hamano wrote:
> Joey Hess writes:
>
> > Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is
> > relative to the top of the worktree and not to the CWD.
>
> I think that has always been the case. You can always specify it as
> relative
This is actually worse than I thought; when git is being run with a
detached work tree, GIT_INDEX_FILE is treated as a path relative to CWD,
instead of the normal behavior of relative the top of the work tree.
Normal and expected (according to this thread anyway):
joey@darkstar:~/src/other/git/Do
Junio C Hamano wrote:
> Joey Hess writes:
>
> > This seems to make it basically impossible for any program that wants to
> > use GIT_INDEX_FILE to use anything other than an absolute path;
> > there are too many configurations to keep straight that could change how
> &
Junio C Hamano wrote:
> I personally think that it would be OK as long as we do not change
> behaviours for those who do not use core.worktree, $GIT_DIR and/or
> $GIT_WORK_TREE and change behaviour for others to match that
> behaviour, simply because the plain vanilla no-configuration would
> be us
I have a case where git merge seems to include staged deletions into the
merge commit. This seems pretty surprising, dunno if it's a bug.
joey@darkstar:~/tmp/x/1>git rm 1 foo
joey@darkstar:~/tmp/x/1>git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
Includes test cases.
Signed-off-by: Joey Hess
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index d5e1121
not need to be streamed through the
filter. It even allows for things like clean-from-file commands that avoid
reading the whole content of the file, and for smudge-to-file commands that
populate a work tree file using an efficient Copy On Write operation.
Joey Hess (4):
clarify %f documentation
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess
---
Documentation/gitattributes.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
so ensures that a filter driver configuration that includes these
new commands will work, although less efficiently, when used with an older
version of git that does not support them.
Signed-off-by: Joey Hess
---
Documentation/config.txt| 27 +++---
Documentation/gitattributes
This makes git checkout, git reset, etc use smudge-to-file.
Includes test cases.
(There's a call to convert_to_working_tree in merge-recursive.c
that could also be made to use smudge-to-file as well.)
Signed-off-by: Joey Hess
---
entry.c
Joey Hess wrote:
> + int smudge_to_file = can_smudge_to_file(ce->name);
> if (ce_mode_s_ifmt == S_IFREG &&
> + ! smudge_to_file &&
> convert_to_working_tree(ce->name, new, size, &bu
Junio C Hamano wrote:
> I agree that "the name of the file" can be interpreted in many ways,
> and I agree that it would be a good idea to find a better phrase to
> name the path that is being worked on, but I do not think "the file
> in the git repository" is that phrase.
> I think using the word
Junio C Hamano wrote:
> "tracked by Git" is not all that interesting, compared to the fact
> that your filter needs to give contents relevant to that path
> because that is what the command line argument Git gives you with
> '%f' means. It is not a random filename "tracked by Git". Among 47
> oth
Michael J Gruber wrote:
> I'm not sure this will save all feet. I foresee "why is smudge-to-file
> not doing anything" reports...
It could display a warning message if smudge-to-file is set and smudge is
not.
> In addition, it opens the way to doing completely different things in
> smudge and smu
Junio C Hamano wrote:
> There is what we would want to fix, though. "worktree file" should
> be spelled "working tree file". This used not to matter before "git
> worktree" was invented (before that we used these two terms
> interchangeably), but these days the distinction matters.
The existing d
Junio C Hamano wrote:
> Would an interface that always appends the pathname at the end of
> the command line string work?
I'm ok with this, and like getting rid of %p as it's not distinguishable
from %f without reading the documentation.
The sh -c trick can of course be used if some other orderin
Junio C Hamano wrote:
> Would an interface that always appends the pathname at the end of
> the command line string work?
One problem with this is that "appends" is subtly unclear in this case.
With the example of smugeToFile = cmd --to-file
it seems that a space should be added by git before the
that the user knows it's refusing to use
their configuration.
There's been good and helpful documentation and interface review,
but some more code review would be good! Also, git-annex has a
improved-smudge-filters branch now that demonstrates this interface.
Joey Hess (4):
add smudge
Includes test cases.
Signed-off-by: Joey Hess
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index d5e1121
Let the user know when they have a smudgeToFile/cleanFromFile config
that cannot be used because the corresponding smudge/clean config
is missing.
The warning is only displayed a maximum of once per git invocation,
and only when doing an operation that would use the filter.
Signed-off-by: Joey
This makes git checkout, git reset, etc use smudgeToFile.
Includes test cases.
(There's a call to convert_to_working_tree in merge-recursive.c
that could also be made to use smudgeToFile as well.)
Signed-off-by: Joey Hess
---
entry.c | 37 +--
git that does not support them.
Signed-off-by: Joey Hess
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 ++
convert.c | 108 ++--
convert.h | 10
4 files
Doing a quick benchmark of this new interface and git-annex's use of it, git
checkout of a 1 gigabyte file with git-annex providing the smudge filter took:
19 seconds using the smudge interface
11 seconds using smudgeToFile
0.1 seconds with smudgeToFile and annex.thin set
(whi
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess
---
This patch series was meant to contain 5 patches; here's the missing
one. This patch will apply cleanly on top of v2.9.0.
Documentation/gitattributes.txt | 5 +
1 file
git init gitdir
mkdir worktree
cd worktree
ln -s ../gitdir/.git .git
git submodule add /any/git/repo sub
fatal: Could not chdir to '../../../sub': No such file or directory
Fairly sure this is a bug..
--
see shy jo
signature.asc
Description: PGP
Stefan Beller wrote:
> To elaborate on that: Starting in 2.7 parts of the submodule stuff
> has been rewritten in C, in 2.8 even more and there is more in flight for
> > 2.8.
>
> However your bug is also to be found in 2.6, which doesn't contain any
> recent rewrites, so it is a rather long stand
Junio C Hamano wrote:
> A more pertinent question may be which version of Git did the above
> ever work, I guess. We fairly liberally chdir around and I do not
> think we deliberately avoid assuming that "cd .git && cd .." might
> not come back to the original directory, for example, so I wouldn't
joey@darkstar:/tmp/empty>git init sub1
Initialized empty Git repository in /tmp/empty/sub1/.git/
joey@darkstar:/tmp/empty>git init sub2
Initialized empty Git repository in /tmp/empty/sub2/.git/
joey@darkstar:/tmp/empty>cd sub1
joey@darkstar:/tmp/empty/sub1>date > f1 ; git add f1; git commit -m add
ter a \0
in the commit message. git is very good at hiding such potentially
colliding data from the user, as https://github.com/joeyh/supercollider
demonstrates.
commit 24f30db5790b209fa412ce81c5ef2bf8af5fd4d7
Author: Joey Hess
Date: Fri Sep 9 11:49:21 2011 -0400
an innocent commit
Yaroslav Halchenko wrote:
> which is planned for the next release. I guess it is indeed a
> worthwhile accident-prevention measure BUT not sure if it is so
> important as to cause a change in behavior on which some projects using
> git through the cmdline interface might have been relying upon for
Yaroslav Halchenko wrote:
> - for git-annex (Joey was CCed from the beginning, not sure if annex
> would be affected though), it would be merging of git-annex
> branches while joining multiple annexes for the sync (e.g. by git
> annex assistant).
Not entirely accurate (git-annex merges its
Is there any available plumbing that can change the mtime etc metadata
that is recorded in the index for a file, to user-provided values? Or,
to force the current file stat metadata to be updated in the index?
I know, git update-index --refresh, but I have a case where that's too
expensive. I'm us
joey@darkstar:~/tmp/t> ls -l big-file
-rw-r--r-- 1 joey joey 11811160064 Jan 22 17:48 big-file
joey@darkstar:~/tmp/t> git status
fatal: Out of memory, realloc failed
This file is checked into git, but using a smudge/clean filter, so the actual
data checked into git is a hash. I did so using git-an
Jeff King wrote:
> I didn't experiment with the smudge side, but I think it uses the same
> apply_filter() code. Which means that yes, it would try to store the
> 11GB in memory before writing it out. And I agree writing it out to a
> file and moving it directly into place is the sanest option ther
Jeff King wrote:
> Looking at apply_single_file_filter(), it's not the _original_ file that
> it's trying to store, but rather the data coming back from the filter.
> It's just that we use the original file size as a hint!
Thanks much for working that out!
> In other words, I think this patch fix
a significant overhead for outputs up to a
few MB in size.
Signed-off-by: Joey Hess
---
convert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/convert.c b/convert.c
index 0d89ae7c23..85aebe2ed3 100644
--- a/convert.c
+++ b/convert.c
@@ -732,7 +732,7 @@ static int
Ævar Arnfjörð Bjarmason wrote:
> There's surely other aspects of that square peg of large file tracking
> not fitting the round hole of file locking, the point of my write-up was
> not that *that* solution is perfect, but there's prior art here that's
> very easily adopted to distributed locking if
/etc/.git/hooks/pre-commit is installed by etckeeper and runs
etckeeper pre-commit, which deals with /etc/.etckeeper, including
running "git add .etckeeper". Why that file would match a gitignore
seems much less important than why git would run that hook in an
entirely different git repository.
--with-tree=
When using --error-unmatch to expand the user supplied (i.e.
path pattern) arguments to paths, pretend that paths which were
removed in the index since the named are still present.
Using this option with -s or -u options does not mak
When git is running inside a subdirectory of the repository,
and needs to run the clean filter, it runs it chdired back to the top of
the repository. However, if git was run with a relative --work-tree,
it passes that relative path in GIT_WORK_TREE on to the clean filter.
If git was run with eg,
The clean filter can work around this problem by chdir GIT_PREFIX,
but needing to do this in unusual cases seems to be asking for bugs.
--
see shy jo
signature.asc
Description: PGP signature
Bisecting this test suite failure
https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/
I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git.
It seems that changed resolving refs paths when GIT_DIR and GIT_COMMON_DIR
are both set. While before refs were looked
Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 16, 2017 at 7:10 PM, Joey Hess wrote:
> > Bisecting this test suite failure
> > https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/
> > I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to g
Nice work.
Note that you can export BUILDER=stack and git-annex will build with a
known good dependency stack, which can be more reliable/cross platform
than using apt to install its build dependencies. That needs
https://docs.haskellstack.org/ installed. Also it currently needs
GIT_TEST_GIT_ANNEX
Joey Hess wrote:
> Bisecting this test suite failure
> https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/
> I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git.
>
> It seems that changed resolving refs paths when GIT_DIR and GIT_COMMON_DIR
Leo Gaspard wrote:
> That said, I just came upon [1] (esp. the description [2] and the patch
> [3]), and wondered: it looks like the patch was abandoned midway in
> favor of a hook refactoring. Would you happen to know whether the hook
> refactoring eventually took place, and/or whether this patch
Leo Gaspard wrote:
> I just wanted to check, you did not put the Signed-off-by line in
> patches in https://marc.info/?l=git&m=132491485901482&w=2
>
> Could you confirm that the patches you sent are “covered under an
> appropriate open source license and I have the right under that license
> to su
https://shattered.io/static/shattered.pdf
https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
IIRC someone has been working on parameterizing git's SHA1 assumptions
so a repository could eventually use a more secure hash. How far has
that gotten? There are still many "40" constants in git.git HEAD
Junio C Hamano wrote:
> On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote:
> >
> > Since we now have collisions in valid PDF files, collisions in valid git
> > commit and tree objects are probably able to be constructed.
>
> That may be true, but
> https:/
Linus Torvalds wrote:
> I haven't seen the attack yet, but git doesn't actually just hash the
> data, it does prepend a type/length field to it. That usually tends to
> make collision attacks much harder, because you either have to make
> the resulting size the same too, or you have to be able to a
Linus Torvalds wrote:
> What you describe pretty much already requires a pre-image attack,
> which the new attack is _not_.
>
> It's not clear that the "good" object can be anything sane.
Generate a regular commit object; use the entire commit object + NUL as the
chosen prefix, and use the identi
Joey Hess wrote:
> Linus Torvalds wrote:
> > What you describe pretty much already requires a pre-image attack,
> > which the new attack is _not_.
> >
> > It's not clear that the "good" object can be anything sane.
>
> Generate a regular commit o
Jeff King wrote:
> It's not an identical prefix, but I think collision attacks generally
> are along the lines of selecting two prefixes followed by garbage, and
> then mutating the garbage on both sides. That would "work" in this case
> (modulo the fact that git would complain about the NUL).
>
>
Linus Torvalds wrote:
> So you'd have to be able to attack both the full SHA1, _and_ whatever
> other different good hash to 128 bits.
There's a surprising result of combining iterated hash functions, that
the combination is no more difficult to attack than the strongest hash
function used.
https
In strbuf_add_absolute_path, git uses PWD if set when making relative
paths absolute, otherwise it falls back to getcwd(3). Using PWD may not
be a good idea. Here's one case where it confuses git badly:
joey@darkstar:/>sudo ln -s /media/hd/repo hd
joey@darkstar:/>cd /hd/repo
joey@darkstar:/hd/repo
Jeff King wrote:
> This should make Joey's immediate pain go away, though only by papering
> it over. I tend to agree that we shouldn't be looking at $PWD at all
> here.
I've confirmed that Jeff's patch fixes the case I was having trouble with.
--
see shy jo
signature.asc
Description: PGP sign
I have found many uses for the feature that lets a pre-commit hook stage
changes in the index that will be included in the commit. But now I seem
to have found a bug in the support for that, involving partial commits.
It seems that, after a partial commit in which the pre-commit hook
stages a modi
ewline at end of file
joey@darkstar:~/r2>git commit -m oops
[master 63bd960] oops
joey@darkstar:~/r2>git show
commit 63bd9608c96a91582b27c5853ff58053bab6c71c
Merge: 7ab8102 516a53c
Author: Joey Hess
Date: Thu Jun 12 21:37:35 2014 -0400
oops
diff --cc bar
index 000,3594e94..3594e
I've created git-repair as a small spinoff from git-annex.
http://git-repair.branchable.com/
git-repair is a complement to git fsck, which only finds problems, but
does not try to fix them.
At its simplest, git-repair deletes all corrupt objects and corrupt
packs, makes a fresh clone from a remo
I've got a git repository of < 2 mb, where git wants to
allocate a rather insane amount of memory:
>git fsck
Checking object directories: 100% (256/256), done.
fatal: Out of memory, malloc failed (tried to allocate 124865231165 bytes)
> git show 11644b5a075dc1425e01fbba51c045cea2d0c408
fatal: Out
Jeff King wrote:
> As for your specific corruption, I can't make heads or tails of it. It
> is not a single-bit error.
Oh, I should have mentioned that I am generating corrupt git
repositories mechanically for testing. I think in this case it prepended
some garbage to an object.
--
see shy jo
1 - 100 of 113 matches
Mail list logo
