--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
/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.
Æ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
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
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,
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=132491485901482=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
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
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
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 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
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
Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 16, 2017 at 7:10 PM, Joey Hess <i...@joeyh.name> 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 f57f37e2e1bf11ab4cdf
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
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.
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).
>
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
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
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
Junio C Hamano wrote:
> On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess <i...@joeyh.name> 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, b
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
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
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 <jo...@joeyh.name>
---
entry.c
-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):
clarify %f
of git that does not support them.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 ++
convert.c | 111 +++-
con
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 <jo...@joeyh.n
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 <jo...@joeyh.name>
---
entry.c
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
Documentation/gitattributes.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
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 <jo...@joeyh.name>
---
merge-recursive.c | 53 ---
t
Includes test cases.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_
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
Includes test cases.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
sha1_file.c | 44 ++--
t/t0021-conversion.sh | 36
2 files changed, 74 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_
of git that does not support them.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 +
convert.c | 114 ++--
convert.h
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
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 <jo...@joeyh.n
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 <jo...@joeyh.name>
---
merge-recursive.c | 42 --
t
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 <jo...@joeyh.name>
---
entry.c
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
Documentation/gitattributes.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
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 <jo...@joeyh.name>
---
entry.c
Includes test cases.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_
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 <jo...@joeyh.name>
---
merge-recursive.c | 42 --
t
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 <jo...@joeyh.name>
---
entry.c
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 <jo...@joeyh.n
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
of git that does not support them.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 ++
convert.c | 108 ++--
con
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 <jo...@joeyh.name>
---
entry.c
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 <jo...@joeyh.name>
---
Documentation/gitattributes.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
It's natural to expect %f to be an actual file on disk; help avoid that
mistake.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
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.t
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
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 <jo...@joeyh.name>
---
entry.c
of git that does not support them.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
Documentation/config.txt| 18 ++-
Documentation/gitattributes.txt | 37 ++
convert.c | 108 ++--
con
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 <jo...@joeyh.name>
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_
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 smudgeToFile
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
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
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
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
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
>
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
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, ))
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 <jo...@joeyh.name>
---
entry.c
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 <jo...@joeyh.name>
---
Documentation/gitattributes.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documen
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 <jo...@joeyh.name>
---
Documentation/config.txt| 27 +++--
Includes test cases.
Signed-off-by: Joey Hess <jo...@joeyh.name>
---
sha1_file.c | 42 --
t/t0021-conversion.sh | 36
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_
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)
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
Junio C Hamano wrote:
> Joey Hess <i...@joeyh.name> 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
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):
Junio C Hamano wrote:
> Joey Hess <i...@joeyh.name> 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 speci
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
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
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
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
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
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
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
r 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 <j...@kitenet.net>
Date: Fri Sep 9 11:49:21 2011 -0400
an inn
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
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
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
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:
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
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 [options] [repository
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
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 find by looking
at BASH_SOURCE.
Signed-off-by: Joey Hess jo
joey@darkstar:~/tmpgit init --shared=world testrepo
Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
joey@darkstar:~/tmpgrep shared testrepo/.git/config
sharedrepository = 2
This magic value of 2 seems to be undocumented, as is the magic value of 1
that's
After being surprised that git-ls-files expands pathspecs, here's a patch
that would have saved me.
---
Documentation/git-ls-files.txt | 9 +
Documentation/git-ls-tree.txt | 8
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-ls-files.txt
I was very surprised to learn the other day that git ls-files 'foo*'
will expand wildcards (including character classes), in the absence of
expansion by the shell. (git version 2.1.4)
joey@darkstar:~/tmp/aaagit ls-files 'foo*bar'
foo*bar
foobazbar
joey@darkstar:~/tmp/aaagit ls-files '[abc]'
[abc]
Duy Nguyen wrote:
You can do git --literal-pathspecs ls-files ... or set
GIT_LITERAL_PATHSPECS.
Thanks! --literal-pathspecs does allow getting around this.
Now I'm wondering what other parts of plumbing might be doing globbing
that I did not anticipate. Maybe I should set the environment
I support this proposal, as someone who no longer releases tarballs
of my software, when I can possibly avoid it. I have worried about
signed tags / commits only being a SHA1 break away from useless.
As to the implementation, checksumming the collection of raw objects is
certainly superior to
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
@darkstar:~/r2git show
commit 63bd9608c96a91582b27c5853ff58053bab6c71c
Merge: 7ab8102 516a53c
Author: Joey Hess j...@kitenet.net
Date: Thu Jun 12 21:37:35 2014 -0400
oops
diff --cc bar
index 000,3594e94..3594e94
mode 00,12..100644
--- a/bar
+++ b/bar
joey@darkstar:~/r2git
Junio C Hamano wrote:
Hmph, perhaps you are right. Like this?
Works for me.
--
see shy jo
signature.asc
Description: Digital signature
Jeff King wrote:
I wish we understood why getrlimit was failing. Returning EFAULT seems
like an odd choice if it is not implemented for the system. On such a
system, do the other fallbacks actually work? Would it work to do:
That is, does sysconf actually work on such a system (or does it
Matthieu Moy wrote:
Not as far as I know. But git fsck has a --lost-found option that can
help recovering unreachable (dangling) commits.
You may have a look at http://hackage.haskell.org/package/git-repair but
I do not think it would solve your particular case.
Well, let's find out.. I
1 - 100 of 106 matches
Mail list logo
