Re: Fsck configurations and cloning.

On Sat, Mar 5, 2016 at 5:44 PM, Ryne Everett wrote: > I'm assuming fsck configurations are supposed to apply to clones but > I'm having no luck: > > $ git --version > git version 2.7.2 > $ git config --get transfer.fsckobjects > true > $ git config --get

[PATCH 6/6] use setup_git_directory() in test-* programs

Some of the test-* programs rely on examining refs, but did not bother to make sure we are actually in a git repository. Let's have them call setup_git_directory() to do so. Signed-off-by: Jeff King --- As discussed elsewhere, test-match-trees isn't actually used in the test suite

[PATCH 0/6] avoid touching ref code in non-repositories

Here's the series I mentioned earlier, to avoid avoid accessing the ref code if we know we aren't in a repository. For those just joining us, the end goal is to be able to detect and complain when code tries to open a ref without having run check_repository_format() or similar. Once we have

Re: Resumable clone

Hi Junio & Duy, On Sat, 5 Mar 2016, Junio C Hamano wrote: > Duy Nguyen writes: > > > Resumable clone is happening. See [1] for the basic idea, [2] and [3] > > for some preparation work. I'm sure you can help. Once you've gone > > through at least [1], I think you can pick

Re: [PATCH 1/3] git reset --hard gives clean working tree

Torsten Bögershausen writes: >> When the user has CRLF data in the index and the user tell the >> attribute system so that the next "add" would result in "fixing" the >> indexed lines to be terminated with LF, "diff-files" _should_ show >> that correction as a change, I think. >

[PATCH 2/6] setup: set startup_info->have_repository more reliably

When setup_git_directory() is called, we set a flag in startup_info to indicate we have a repository. But there are a few other mechanisms by which we might set up a repo: 1. When creating a new repository via init_db(), we transition from no-repo to being in a repo. We should tweak

[PATCH 1/6] setup: make startup_info available everywhere

Commit a60645f (setup: remember whether repository was found, 2010-08-05) introduced the startup_info structure, which records some parts of the setup_git_directory() process (notably, whether we actually found a repository or not). One of the uses of this data is for functions to behave

[PATCH 3/6] remote: don't resolve HEAD in non-repository

The remote-config code wants to look at HEAD to mark the current branch specially. But if we are not in a repository (e.g., running "git archive --remote"), this makes no sense; there is no HEAD to look at, and we have no current branch. This doesn't really cause any bugs in practice (if you are

[PATCH v2 1/2] mergetool: honor tempfile configuration when resolving delete conflicts

Teach resolve_deleted_merge() to honor the mergetool.keepBackup and mergetool.keepTemporaries configuration knobs. This ensures that the worktree is kept pristine when resolving deletion conflicts with the variables both set to false. Signed-off-by: David Aguilar --- v2 uses

Fsck configurations and cloning.

I'm assuming fsck configurations are supposed to apply to clones but I'm having no luck: $ git --version git version 2.7.2 $ git config --get transfer.fsckobjects true $ git config --get fsck.badTimezone ignore $ cat $(git config --get fsck.skiplist)

[PATCH 5/6] grep: turn off gitlink detection for --no-index

If we are running "git grep --no-index" outside of a git repository, we behave roughly like "grep -r", examining all files in the current directory and its subdirectories. However, because we use fill_directory() to do the recursion, it will skip over any directories which look like

[PATCH 4/6] mailmap: do not resolve blobs in a non-repository

The mailmap code may be triggered outside of a repository by git-shortlog. There is no point in looking up a name like "HEAD:.mailmap" there; without a repository, we have no refs. This is unlikely to matter much in practice for the current code, as we would simply fail to find the ref. But as

Re: Making git apply always work relative to current directory

On Sat, Mar 05, 2016 at 11:31:53AM -0800, Junio C Hamano wrote: > "brian m. carlson" writes: > > > If I run git apply --no-index --verbose , it succeeds in both > > cases, but when I'm in the git repository, it *silently does nothing*. > > That originally sounded

Re: [PATCH v4] fetch-pack: fix object_id of exact sha1

On Fri, Mar 04, 2016 at 10:11:38PM -0300, Gabriel Souza Franco wrote: > Commit 58f2ed0 (remote-curl: pass ref SHA-1 to fetch-pack as well, > 2013-12-05) added support for specifying a SHA-1 as well as a ref name. > Add support for specifying just a SHA-1 and set the ref name to the same > value

Re: [PATCH v4] pull --rebase: add --[no-]autostash flag

Mehul Jain writes: > +--autostash:: > +--no-autostash:: > + Before starting rebase, stash local modifications away (see > + linkgit:git-stash.txt[1]) if needed, and apply the stash when > + done. > ++ > +This option is only valid when '--rebase' is used. >

Re: [PATCH] Allow "-" as a short-hand for "@{-1}" for branch deletion

Dinesh Polathula writes: > From: Dinesh > > *** > This patch allows the usage of "-" as a short-hand for "@{-1}" in "git branch > -d @{-1}". > > Note : This is a microproject that is part of the Google Summer of Code > application process. > I am

Re: [PATCH 1/3] git reset --hard gives clean working tree

Torsten Bögershausen writes: > On 11.02.16 19:49, Junio C Hamano wrote: > >> I did not continue the approach I illustrated because I realized and >> finally convinced myself that touching ce_compare_data() is a wrong >> solution--it breaks "diff-files". >> >> Imagine if you have

Re: [PATCH 1/3] git reset --hard gives clean working tree

> I do not think I can endorse this approach, as I cannot explain why > it could possibly make sense to treat as if CRLF conversion is > somehow special among all the convert_to_git()/convert_to_worktree() > conversions, which your patch does to the diff code. > > Comparisons between contents

Commit message not helpful after merge squash with conflicts

Hi, after a "git merge --squash" with a conflict the commit message is not helpful as it only includes the conflicted files information, however, I expect to see the content of SQUASH_MSG which contains the summary of the merged commits. SQUASH_MSG seems to be just ignored. I think git should

[PATCH] Allow "-" as a short-hand for "@{-1}" for branch deletion

From: Dinesh This patch allows the usage of "-" as a short-hand for "@{-1}" in "git branch -d @{-1}". Note : This is a microproject that is part of the Google Summer of Code application process.I am interested in working on the git Beginner mode implementation as part

[PATCH] branch.c: Allow "-" as a short-hand for "@{-1}" in "git branch -d @{-1}"

From: Dinesh The "-" shorthand can be used as a replacement for "@{-1}" to refer to the previous branch the user was on in the "git branch -d @{-1}" command. Replace "-" argument with "@{-1}" when the command line arguments are parsed. Signed-off-by: Dinesh

Re: Git clone sends first an empty authorization header

Guilherme writes: > When doing basic authentication using git clone by passing the > username and password in the url git clone will first send a GET > request without the authorization header set. > > Am i seeing this right? Yes, that is the correct way to implement HTTP

Re: Resumable clone

On Sat, Mar 5, 2016 at 4:23 PM, Kevin Wern wrote: > Hey, all, > > A while ago, I noticed that if a clone is interrupted, it has to be > restarted completely. When I looked up the issue, I saw that someone > suggested resumable clones as a feature as early as 2007. It

[PATCH v4] pull --rebase: add --[no-]autostash flag

If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the

Resumable clone

Hey, all, A while ago, I noticed that if a clone is interrupted, it has to be restarted completely. When I looked up the issue, I saw that someone suggested resumable clones as a feature as early as 2007. It doesn't seem like any progress has been made on this issue, so I began looking at

[PATCH] branch.c: Allow "-" as a short-hand for "@{-1}" in "git branch -d @{-1}"

From: Dinesh The "-" shorthand can be used as a replacement for "@{-1}" to refer to the previous branch the user was on in the "git branch -d @{-1}" command.Replace "-" argument with "@{-1}" when the command line arguments are parsed. Signed-off-by: Dinesh

Re: [PATCH v4] pull --rebase: add --[no-]autostash flag

On Sat, Mar 5, 2016 at 3:22 PM, Mehul Jain wrote: > Changes: > * --no-autostash is passed to git-rebase (suggested by Paul) > > * Error message changed when "git pull --[no-]autostash" is called. > > * If rebase.autoStash is unset and user don't

Re: Resumable clone

Duy Nguyen writes: > Resumable clone is happening. See [1] for the basic idea, [2] and [3] > for some preparation work. I'm sure you can help. Once you've gone > through at least [1], I think you can pick something (e.g. finalizing > the protocol, update the server side, or

Re: [PATCH v4] fetch-pack: fix object_id of exact sha1

Jeff King writes: > On Fri, Mar 04, 2016 at 10:11:38PM -0300, Gabriel Souza Franco wrote: > >> Commit 58f2ed0 (remote-curl: pass ref SHA-1 to fetch-pack as well, >> 2013-12-05) added support for specifying a SHA-1 as well as a ref name. >> Add support for specifying just a SHA-1

Re: [PATCH] fetch-pack: update the documentation for "..." arguments

Gabriel Souza Franco writes: > When we started allowing an exact object name to be fetched from the > command line, we forgot to update the documentation. > > Signed-off-by: Gabriel Souza Franco > --- Thanks for resending ;-) -- To

Making git apply always work relative to current directory

I have a piece of software which must run out of a given directory. In development, this is a git repository, and in production it is not. I also have an ignored subdirectory where I would like to use git apply to apply patches (in both environments). If I run git apply --no-index --verbose ,

Re: Resumable clone

Junio C Hamano writes: > So what remains? Here is a rough and still slushy outline: > > - A new method, prime_clone(), in "struct transport" for "git >clone" client to first call to learn the location of the >"alternate resource" from the server. > >... >-

[PATCH] strbuf_getwholeline: NUL-terminate getdelim buffer on error

Commit 0cc30e0 (strbuf_getwholeline: use getdelim if it is available, 2015-04-16) tries to clean up after getdelim() returns EOF, but gets one case wrong, which can lead in some obscure cases to us reading uninitialized memory. After getdelim() returns -1, we re-initialize the strbuf only if

Re: Making git apply always work relative to current directory

"brian m. carlson" writes: > If I run git apply --no-index --verbose , it succeeds in both > cases, but when I'm in the git repository, it *silently does nothing*. That originally sounded peculiar to me and I suspected it to be a bug, but it looks like a

Re: [PATCH] strbuf_getwholeline: NUL-terminate getdelim buffer on error

Jeff King writes: > Not a big rush for 2.8.0-rc, as the bug is in v2.5.0, and I doubt > there's an easy trigger besides fast-import. But it might be harmless > enough to squeeze in. Was it found by a real-world debugging session, or by a code inspection? I'd be really impressed

[PATCH] fetch-pack: update the documentation for "..." arguments

When we started allowing an exact object name to be fetched from the command line, we forgot to update the documentation. Signed-off-by: Gabriel Souza Franco --- Documentation/git-fetch-pack.txt | 4 1 file changed, 4 insertions(+) diff --git

Re: [PATCH] strbuf_getwholeline: NUL-terminate getdelim buffer on error

On Sat, Mar 05, 2016 at 11:33:08AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Not a big rush for 2.8.0-rc, as the bug is in v2.5.0, and I doubt > > there's an easy trigger besides fast-import. But it might be harmless > > enough to squeeze in. > > Was it found by a