git-apply working on an index with smudged entries

I see that when I call "git apply --3way ..." on an index which was previously created by JGit and which contains smudged entries the command fails with message "error: foo.txt: does not match index". If I do a "git status" afterwards and then the same "git apply --3way ..." it succeeds. Looks like

Re: What exactly is a "initial checkout"

Ok, I know understand the problems which are solved by this special behaviour of a "initial checkout". And also important I understand when exactly I should do a "initial checkout" - when the index file does not exist. I'll share my new knowledge with JGit :-)

What exactly is a "initial checkout"

I am trying to teach JGit [1] to behave like native git regarding some corner cases during "git checkout". I am reading the "git read-tree" documentation and I am not sure about the case [2]. Git should behave differently during a normal checkout than when you are doing a "initial checkout". I can

Re: OAuth2 support in git?

What is not clear to me is how we can make use of the servers initial response in order control which credential helper to call and how to transport the credentials. Imagine we try to clone over http. The initial request sent to the server may not contain a "Authorization: ..." header and the serv

OAuth2 support in git?

Can I use native git as client to contact a git server which does authentication with OAuth2 Client Credentials Grant [1]? Background: We are running gerrit based git servers [2] in a cloud environment. That environment supports OAuth2 authorization for the apps running in the cloud. The idea is t

is ORIG_HEAD allowed to point to a non-existing object?

If I do a "git-rebase -i ..." followed by "git reflog expire ..." and "git gc ..." then I can end up with a repo which has a ref ORIG_HEAD which points to a non-existing object. - Is this intended? - What's the reason to keep a ref which points to a non-existing object? - Are there any other refs

Why does "git reset --hard" fail on file/folder conflicts?

Hi, git doesn't want to do a git reset hard when for a certain path the index contains a tree, worktree contains a file and the commit to reset to contains nothing. Is it a bug or is it intended? I would expect git to simply delete that path from index and worktree. > git init Initialized empty G

Re: git index containing tree extension for unknown path

id = 2b230fa0f3d19b497d3dd24e835691e3a921657f [checksum] checksum = True sha1 = 124680d4dec4758ee1ae28f546659d282952ebff Ciao Chris Ciao Chris On Wed, Jan 21, 2015 at 9:39 PM, Junio C Hamano wrote: > Christian Halstrick writes: > >> Is it allowed that the git index contains a tree extension mentioning

git index containing tree extension for unknown path

Is it allowed that the git index contains a tree extension mentioning patch 'x/y/z' while the only entry in the index is a '.gitattributes' files in the root? I have such a repo in a bug report against JGit [1]. Native git has no problems with this repo but JGit can't read such an index. I am wond

Re: What is the default refspec for fetch?

>>> On Fri, Nov 07, 2014 at 04:31:08PM +0100, Christian Halstrick wrote: >>> >>>> In a repo where no remote..fetch config parameter is set what >>>> should a "git fetch" do? My experiments let me think it's >>>> "HEAD:FETC

What is the default refspec for fetch?

Hi, In a repo where no remote..fetch config parameter is set what should a "git fetch" do? My experiments let me think it's "HEAD:FETCH_HEAD". Right? I came to this question after finding out that when I clone repos in bare mode then they don't have and explicit remote..fetch in their config. But

Re: Can I fetch an arbitrary commit by sha1?

I also like the feature of being able to fetch commits by SHA-1. My problem is that it is not clear to end users whether they can fetch SHA-1 from a specific server or not. For exactly the same server a "git fetch origin " first doesn't work and all of the sudden that command works and updates e.g.

Can I fetch an arbitrary commit by sha1?

I always though during fetch I have to specify a refspec and that a sha1 would not be accepted as a ref. Firing some like 'git fetch origin ' should be forbidden. But in fact I see that such a fetch command succeeds if you already have that object in your local repo. My question: is it allowed to

Re: How to populate index/worktree when recursive merge merges multiple common ancestors?

> They don't. The conflicts are preserved into the virtual ancestor. The > user only sees the final conflicts during merging of A and B with > virtual X3 as the common ancestor. Ah, now I understand. When I merge X1 and X2 into the virtual X3 I should not stop if this is not doable without conflic

How to populate index/worktree when recursive merge merges multiple common ancestors?

Imagine git does a recursive merge between A and B and finds multiple common ancestors X1,X2 for these commits. - Does git try to create an implicit/temporary common ancestor X3 by merging X1 and X2? - How should workingtree, index (stage1,2,3) look like if during that merge of common ancestors a c