Re: Questions about the hash function transition

On Tue, Aug 28, 2018 at 2:50 PM, Ævar Arnfjörð Bjarmason wrote: > If we instead had something like clean/smudge filters: > > [extensions] > objectFilter = sha256-to-sha1 > compatObjectFormat = sha1 > [objectFilter "sha256-to-sha1"] > clean = ... > smudge =

Re: [RFC PATCH 1/1] recover: restoration of deleted worktree files

On Sat, Aug 04, 2018 at 08:54:49AM -0700, Junio C Hamano wrote: > > My first reaction was to say that I am not going to take a new > command written only for bash with full bashism, even if it came > with docs, tests nor Makefile integration, for Git itself. Then I > reconsidered, as not

[RFC PATCH 1/1] recover: restoration of deleted worktree files

in your repository that were deleted +# from the working tree. +# +# Copyright (c) 2017-2018 Edward Thomson. + +set -e + +IFS=$'\n' + +PROGNAME=$(echo "$0" | sed -e 's/.*\///') +GIT_DIR=$(git rev-parse --git-dir) + +DO_RECOVER=0 +DO_FULL=0 +DO_INTERACTIVE=0 +BLOBS=() +FILENAMES=() +

[RFC PATCH 0/1] Introduce git-recover

ectory and named using its 40 character object ID, unless the `-f` option is specified. -f , --filename When specified after an object ID, the file written will use this filename. In addition, any filters (for example: CRLF conversion or Git-LFS) will be run according to the `gitattributes` confi

Re: Hash algorithm analysis

On Fri, Jul 20, 2018 at 09:52:20PM +, brian m. carlson wrote: > > To summarize the discussion that's been had in addition to the above, > Ævar has also stated a preference for SHA-256 and I would prefer BLAKE2b > over SHA-256 over SHA3-256, although any of them would be fine. > > Are there

Re: [PATCH] checkout files in-place

On Tue, Jun 12, 2018 at 09:13:54AM +0300, Orgad Shaneh wrote: > Some of my colleagues use an ancient version of Source Insight, which also > locks files for write. If that application is locking files for writing (that is to say, it did not specify the `FILE_SHARE_WRITE` bit in the sharing modes

Re: [PATCH] checkout files in-place

On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote: > > It is safe to do this on Linux file systems, even if open file handles > still exist, because unlink only removes the directory reference to the > file. On Windows, however, a file cannot be deleted until all handles to > it

Re: [RFC 0/1] Tolerate broken headers in `packed-refs` files

On Mon, Mar 26, 2018 at 2:08 PM, Derrick Stolee wrote: > Since most heavily-used tools that didn't spawn Git processes use > LibGit2 to interact with Git repos, I added Ed Thomson to CC to see > if libgit2 could ever write these bad header comments. We added the `sorted`

Contributor Summit Dinner

Hello- Microsoft would like to invite the contributors summit to dinner tonight; it will take place at 8pm: La Tagliatella (Placa Catalunya) Ronda de la Universitat, 31 It's conveniently right around the corner from the Beers with Bitbucket event, in case you're going to that. Hope to see

[ANNOUNCE] libgit2 summit: 9 March 2018, Barcelona

The libgit2 community is hosting the libgit2 Summit 2018 on March 9th 2018 in Barcelona. As peff previously announced, Git Merge 2018 is happening in Barcelona on March 8th (and the Git Contributor's Summit is planned for March 7.) We will follow the Git Merge event and have our summit on March

Re: git merge-tree: bug report and some feature requests

On Tue, Jan 23, 2018 at 7:08 AM, Josh Bleecher Snyder wrote: > Looking over your list above, at a minimum, libgit2 might not have a > particularly good way to represent submodule/file or > submodule/directory conflicts, because is-a-submodule is defined > external to a

[ANNOUNCE] Git London User Group: 16 January 2018

. This talk looks at the basic principles that support best practice for scripting Git and how to avoid some common pitfalls. Building Git Tools with libgit2: Edward Thomson Edward introduces the libgit2 framework (http://libgit2.org), which is a portable, implementation of Git as a library. If you're

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

On Wed, Jun 01, 2016 at 09:00:34AM -0700, Junio C Hamano wrote: > > Unlike the "something like this" we saw earlier, this draws the > boundary of responsibility between the caller and the API at a much > more sensible place. This makes sense to me - Junio, are you taking (or have you already

[PATCH] add: add --chmod=+x / --chmod=-x options

already familiar with. Signed-off-by: Edward Thomson <ethom...@edwardthomson.com> --- builtin/add.c | 12 +++- cache.h| 2 ++ read-cache.c | 11 +-- t/t3700-add.sh | 30 ++ 4 files changed, 52 insertions(+), 3 deletions(-) diff --git a/b

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

On Fri, May 27, 2016 at 11:30:40AM -0700, Junio C Hamano wrote: > > Oh, having said all of that, the comments on the implementation > still stand. Certainly; sorry for the delay. I've squashed in your tests and applied your recommendations. Resending the patch momentarily. Thanks- -ed -- To

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

On Wed, May 25, 2016 at 12:36:55AM -0700, Junio C Hamano wrote: > > At the design level, I have a few comments. Thanks, I will submit a new patch that incorporates your (and dscho's) comments. > * This is about a repository with core.filemode=0; I wonder if >something for a repository with

Re: [PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

On Wed, May 25, 2016 at 05:39:04PM -0500, Jeff King wrote: > Looks like we didn't have any tests at all for %C(auto). And the tests > for %C(auto,...) were labeled as %C(auto), making it all the more > confusing. Perhaps it is worth squashing this in: Thanks, peff. Indeed I did squash that into

[PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

d as being applicable to `%C(auto)`. Signed-off-by: Edward Thomson <ethom...@edwardthomson.com> Tests from Jeff King. Signed-off-by: Jeff King <p...@peff.net> --- pretty.c | 2 +- t/t6006-rev-list-format.sh | 26 +++--- 2 files changed, 20 inse

[PATCH] add: add --chmod=+x / --chmod=-x options

command allows users to set a file executable in a single command that they're already familiar with. Signed-off-by: Edward Thomson <ethom...@edwardthomson.com> --- builtin/add.c | 18 +- cache.h| 2 ++ read-cache.c | 6 ++ t/t3700-add.sh | 19 ++

[PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

the ability to specify that color should be displayed only when the output is a tty, and to use the default color for the given context (instead of a hardcoded color value). Signed-off-by: Edward Thomson <ethom...@edwardthomson.com> --- pretty.c | 2 +- 1 file changed, 1 insertion(+), 1 de

Re: [PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

On Tue, May 24, 2016 at 05:55:02PM -0700, Junio C Hamano wrote: > Looks obviously the right thing to do from a cursory read. > Missing sign-off? Yes, apologies for the oversight; will re-send. Thanks- -ed -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message

[PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

Check that we are configured to display colors in the given context when the user specifies a format string of `%C(auto)`, instead of always displaying the default color for the given context. This makes `%C(auto)` obey the `color=auto` setting and brings its behavior in line with the behavior of

Re: [RFC/PATCH] fsck: do not canonicalize modes in trees we are checking

On Tue, Sep 23, 2014 at 11:47:51AM -0400, Jeff King wrote: As far as I can tell, fsck's mode-checking has been totally broken basically forever. Which makes me a little nervous to fix it. :) linux.git does have some bogus modes, but they are 100664, which is specifically ignored here unless

[PATCH] upload-pack: keep poll(2)'s timeout to -1

Keep poll's timeout at -1 when uploadpack.keepalive = 0, instead of setting it to -1000, since some pedantic old systems (eg HP-UX) and the gnulib compat/poll will treat only -1 as the valid value for an infinite timeout. Signed-off-by: Edward Thomson ethom...@microsoft.com --- upload-pack.c

Re: [PATCH] upload-pack: keep poll(2)'s timeout to -1

On Fri, Aug 22, 2014 at 12:03:34PM -0400, Jeff King wrote: Yeah, I wasn't thinking we would get negative values from the user (we don't document them at all), but we should probably do something sensible. Let's just leave it at Ed's patch. Thanks, both. Apologies for the dumb question: is

RE: Rename conflicts in the index

Edward Thomson [ethom...@microsoft.com] wrote: Junio C Hamano [mailto:gis...@pobox.com] wrote: * Path A may have only stage #1, while path B and C has only stage #2 and stage #3 (the user would have to notice these three correspond to each other, and resolve manually). You

RE: Rename conflicts in the index

Junio C Hamano [mailto:gits...@pobox.com] wrote: Edward Thomson ethom...@microsoft.com writes: Junio, did you have additional thoughts on this? Not at this moment. I think we have covered the principles (do not unnecessarily duplicate information, do not break existing implementations

RE: Rename conflicts in the index

Junio C Hamano [mailto:gis...@pobox.com] wrote: As long as the format will be backward compatible to allow existing users use existing tools to deal with cases the existing tools can handle, then that is OK. I didn't get that impression which is where my non starter came from. I see now.

RE: Rename conflicts in the index

Junio C Hamano [mailto:gits...@pobox.com] wrote: Edward Thomson ethom...@microsoft.com writes: I would propose that this not simply track rename conflicts, but all conflicts. That is a no starter. So. Can you explain to me why this would be a non starter? Can you suggest some alternate

RE: Rename conflicts in the index

Junio C Hamano [mailto:gits...@pobox.com] wrote: We do not gratuitously break existing implementations. If no conflict is stored as higher-stage index entries in an index that has your index extension, no existing implementation can read a conflicted index written by your implementation and

RE: Rename conflicts in the index

Junio C Hamano [mailto:gits...@pobox.com] wrote: Edward Thomson ethom...@microsoft.com writes: I would propose that we store the data about the file in conflict as it occurred through the renames. For example, in a rename 1-2 conflict where A was renamed to both B and C, you would have

RE: Rename conflicts in the index

Junio C Hamano [mailto:gits...@pobox.com] wrote: Edward Thomson ethom...@microsoft.com writes: I would propose a new extension, 'CONF', to handle conflict data, differing from the stage 0 entries in the index in that this extension tracks the conflicting file across names if the underlying

Rename conflicts in the index

When a rename conflict occurs, the information about the conflict is written to stdout and the index is updated as if the conflict were a simpler conflict that did not involve renames. This doesn't give a lot of information to users after the fact - a status of added in ours does not provide a

RE: Rename conflicts in the index

Junio C Hamano [mailto:gits...@pobox.com] wrote: I do not offhand see anything particularly stupid; a new optional index extension section CACHE_EXT_RENAME_CONFLICT might be a good addition. Is one side moves A to B while the other side moves it to C the only case, or is it just an

Merge with staged and unstaged changes

Hi- I've been investigating the cases where merge is allowed to proceed when there are staged changes in the index or unstaged files in the working directory. There are cases where I find the behavior surprising and I hope I can get clarification. There are also two cases that I will report as

Re: Merge with staged and unstaged changes

On 2/20/13 2:21 PM, Junio C Hamano gits...@pobox.com wrote: Both are very much on purpose. The integrator may have seen the patch on the list, ran git apply [--index] on it to contemplate on it, and before commiting the result, saw a pull request for a branch that contains the change. The above