Re: [PATCH] rerere: make rr-cache fanout directory honor umask

On Mon, Jul 09, 2012 at 04:28:21PM -0700, Junio C Hamano wrote: This is the last remaining call to mkdir(2) that restricts the permission bits by passing 0755. Just use the same mkdir_in_gitdir() used to create the leaf directories. Signed-off-by: Junio C Hamano gits...@pobox.com Looks

Re: Problems pushing???

Thanks for all your help. Running through this a few more times and reading the net I managed it ; ) I tested it cloning from the command line and all seems good. For developement I use eclipse with the eGit plugin. When I try cloning it putting all the relevant info in it fails. I am sure

[PATCH v4 00/19] git apply --3way

With finishing touches (mostly updates to in-code comments and log messages). Previous ones were: http://thread.gmane.org/gmane.comp.version-control.git/197538 http://thread.gmane.org/gmane.comp.version-control.git/197637 http://thread.gmane.org/gmane.comp.version-control.git/199936

[PATCH v4 01/19] apply: fix an incomplete comment in check_patch()

This check is not only about type-change (for which it would be sufficient to check only was_deleted()) but is also about a swap rename. Otherwise to_be_deleted() check is not justified. Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/apply.c | 24 +++- 1 file

[PATCH v4 02/19] apply: a bit more comments on PATH_TO_BE_DELETED

The code is littered with to_be_deleted() whose purpose is not so clear. Describe where it matters. Also remove an extra space before #define that snuck in by mistake at 7fac0ee (builtin-apply: keep information about files to be deleted, 2009-04-11). Signed-off-by: Junio C Hamano

[PATCH v4 03/19] apply: clear_image() clears things a bit more

The clear_image() function did not clear the line table in the image structure; this does not matter for the current callers, as the function is only called from the codepaths that deal with binary patches where the line table is never populated, and the codepaths that do populate the line table

[PATCH v4 04/19] apply: refactor read_file_or_gitlink()

Reading a blob out of the object store does not have to require that the caller has a cache entry for it. Create a read_blob_object() helper function that takes the object name and mode, and use it to reimplement the original function as a thin wrapper to it. Signed-off-by: Junio C Hamano

[PATCH v4 05/19] apply: factor out checkout_target() helper function

When a patch wants to touch a path, if the path exists in the index but is missing in the working tree, git apply --index checks out the file to the working tree from the index automatically and then applies the patch. Split this logic out to a separate helper function. Signed-off-by: Junio C

[PATCH v4 06/19] apply: split load_preimage() helper function out

Given a patch for a single path, the function apply_data() reads the preimage in core, and applies the change represented in the patch. Separate out the first part that reads the preimage into a separate helper function load_preimage(). Signed-off-by: Junio C Hamano gits...@pobox.com ---

[PATCH v4 07/19] apply: refactor previous patch logic

The code to grab the result of application of a previous patch in the input was mixed with error message generation for a case where a later patch tries to modify contents of a path that has been removed. The same code is duplicated elsewhere in the code. Introduce a helper to clarify what is

[PATCH v4 09/19] apply: move check_to_create_blob() closer to its sole caller

Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/apply.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index ee1a960..cd25e63 100644 --- a/builtin/apply.c +++ b/builtin/apply.c @@

[PATCH v4 08/19] apply: further split load_preimage()

load_preimage() is very specific to grab the current contents for the path given by patch-old_name. Split the logic that grabs the contents for a path out of it into a separate load_patch_target() function. Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/apply.c | 59

[PATCH v4 11/19] apply: accept -3/--3way command line option

Begin teaching the three-way merge fallback logic git am -3 uses to the underlying git apply. It only implements the command line parsing part, and does not do anything interesting yet, other than making sure that --reject and --3way are not given together, and making --3way imply --index.

[PATCH v4 12/19] apply: fall back on three-way merge

Grab the preimage blob the patch claims to be based on out of the object store, apply the patch, and then call three-way-merge function. This step still does not plug the actual three-way merge logic yet, but we are getting there. Signed-off-by: Junio C Hamano gits...@pobox.com ---

[PATCH v4 13/19] apply: plug the three-way merge logic in

When a patch does not apply to what we have, but we know the preimage the patch was made against, we apply the patch to the preimage to compute what the patch author wanted the result to look like, and attempt a three-way merge between the result and our version, using the intended preimage as the

[PATCH v4 14/19] apply: move verify_index_match() higher

We will be adding another caller of this function in a later patch. Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/apply.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index d84958b..682852c 100644 ---

[PATCH v4 15/19] apply: --3way with add/add conflict

When a patch wants to create a path, but we already have it in our current state, pretend as if the patch and we independently added the same path and cause add/add conflict, so that the user can resolve it just like git merge in the same situation. For that purpose, implement load_current() in

[PATCH v4 16/19] apply: register conflicted stages to the index

Now we have all the necessary logic to fall back on three-way merge when the patch does not cleanly apply, insert the conflicted entries to the index as appropriate. This obviously triggers only when the --index option is used. When we fall back to three-way merge and some of the merges fail,

[PATCH v4 18/19] apply: document --3way option

Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/git-apply.txt | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt index afd2c9a..634b84e 100644 --- a/Documentation/git-apply.txt +++

[PATCH v4 17/19] apply: allow rerere() to work on --3way results

Signed-off-by: Junio C Hamano gits...@pobox.com --- builtin/apply.c | 3 +++ t/t4108-apply-threeway.sh | 25 + 2 files changed, 28 insertions(+) diff --git a/builtin/apply.c b/builtin/apply.c index dc52c94..cd68862 100644 --- a/builtin/apply.c +++

[PATCH v4 19/19] apply: tests for the --3way option

Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t4108-apply-threeway.sh | 54 +++ 1 file changed, 54 insertions(+) diff --git a/t/t4108-apply-threeway.sh b/t/t4108-apply-threeway.sh index e6d4da6..fa5d4ef 100755 --- a/t/t4108-apply-threeway.sh

[PATCH v4 10/19] apply: move already exists logic to check_to_create()

The check_to_create_blob() function used to check only the case where we are applying to the working tree. Rename the function to check_to_create() and make it also responsible for checking the case where we apply to the index. Also make its caller responsible for issuing an error message.

git commit --amend --only -- nevertheless commits staged changes

When using git commit --amend --only --message message --, I'd expect to have just the commit message of my last commit changed, according to the man page: --only Make a commit only from the paths specified on the command line, disregarding any contents that have been staged so far. [...] If this

[PATCH 0/3] A better way of handling upstream information in git-branch

Hello all, This stems from comments made by Junio and Jonathan about my proposed changes to --set-upstream. This should probably have a few tests, but I'd like to hear comments about the code and documentation first. The third patch is the one I'm not so confident about. It would be simpler to

[PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

This interface is error prone, and a better one (--set-upstream-to) exists. Suggest how to fix a --set-upstream invocation in case the user only gives one argument, which makes it likely that he meant to do the opposite, like with git branch --set-upstream origin/master when they meant one

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Carlos Martín Nieto c...@elego.de writes: diff --git a/builtin/branch.c b/builtin/branch.c index 0e060f2..c886fc0 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -713,6 +713,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix) int verbose = 0, abbrev = -1,

Re: What's cooking in git.git (Jul 2012, #01; Tue, 3)

Junio C Hamano wrote: [...] * rj/platform-pread-may-be-thread-unsafe (2012-06-26) 1 commit (merged to 'next' on 2012-06-28 at ce5f79f) + index-pack: Disable threading on cygwin On Cygwin, the platform pread(3) is not thread safe, just like our own compat/ emulation, and cannot be used

Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

Carlos Martín Nieto c...@elego.de writes: This interface is error prone, and a better one (--set-upstream-to) exists. Suggest how to fix a --set-upstream invocation in case the user only gives one argument, which makes it likely that he meant to do the opposite, like with git branch

Re: [PATCH 3/3] branch: add --unset-upstream option

Carlos Martín Nieto c...@elego.de writes: We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets this information. --- create_branch() uses

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Hi, Carlos Martín Nieto wrote: The existing --set-uptream option can cause confusion, as it uses the usual branch convention of assuming a starting point of HEAD if none is specified, causing git branch --set-upstream origin/master to create a new local branch 'origin/master' that

Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

Hi, Quick nitpicks. Carlos Martín Nieto wrote: --- a/builtin/branch.c +++ b/builtin/branch.c @@ -864,10 +864,32 @@ int cmd_branch(int argc, const char **argv, const char *prefix) info and making sure new_upstream is correct */ create_branch(head,

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Junio C Hamano wrote: I am not super excited about it either, but at least it is a vast improvement compared to the older one, with which it was entirely unclear if we are setting the value of upstream *to* what is given as an option, or setting the upstream *for* what is given on the

Re: git commit --amend --only -- nevertheless commits staged changes

On Tue, Jul 10, 2012 at 12:41:13PM +0200, Marc Strapetz wrote: When using git commit --amend --only --message message --, I'd expect to have just the commit message of my last commit changed, according to the man page: --only Make a commit only from the paths specified on the command line,

Re: git commit --amend --only -- nevertheless commits staged changes

Marc Strapetz marc.strap...@syntevo.com writes: When using git commit --amend --only --message message --, I'd expect to have just the commit message of my last commit changed, according to the man page: --only Make a commit only from the paths specified on the command line, disregarding

Re: git commit --amend --only -- nevertheless commits staged changes

On Tue, Jul 10, 2012 at 04:30:52PM -0400, Jeff King wrote: On Tue, Jul 10, 2012 at 01:14:32PM -0700, Junio C Hamano wrote: I do not think the combination with --amend, --only and no paths ever worked. We rejected such a combination before 6a74642c5, which merely made us to accept the

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Jonathan Nieder jrnie...@gmail.com writes: The immediate problem that seems to trip people up is that it is very tempting to run git branch --set-upstream junio/master I think we have discussed this already a few days ago. See my comment in the earlier thread before this round. -- To

Re: git clone fails with error: RPC failed; result=22, HTTP code = 401

On Fri, Jul 06, 2012 at 02:04:10PM +0200, Ilya Ruprecht wrote: Location /git/repo1.git # read access Limit GET require ldap-group repo.writers require ldap-group repo.readers /Limit

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Junio C Hamano wrote: Jonathan Nieder jrnie...@gmail.com writes: The immediate problem that seems to trip people up is that it is very tempting to run git branch --set-upstream junio/master I think we have discussed this already a few days ago. See my comment in the earlier thread

Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

Jonathan Nieder jrnie...@gmail.com writes: Message should go on stderr and be guarded with an advice option (see advice.c). Like this: const char *arg; ... if (argc != 1 || !advice_old_fashioned_set_upstream) return 0; /* ok. */ arg = argv[0];

[PATCH v3 2/2] stash: invoke rerere in case of conflict

'stash apply' directly calls a backend merge function which does not automatically invoke rerere. This confuses mergetool when leftover rerere state is left behind from previous merges. Invoke rerere explicitly when we encounter a conflict during stash apply Change the test for this flaw to

Re: [PATCH 2/3] branch: suggest how to undo a --set-upstream when given one branch

Junio C Hamano wrote: I think it is better to leave them emitted unconditionally to the standard error stream, in order to train users away from using the old option that has its arguments wrong (the option does not take an argument

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Jonathan Nieder jrnie...@gmail.com writes: [someone should have] | suggested an alternative syntax that avoids the mistake you quoted | above, perhaps something like: | | git branch --set-upstream-to=origin/master [HEAD] with which I disagree. You can think of it this way. git branch

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Junio C Hamano wrote: You can think of it this way. git branch can not only _create_ a new branch (or list existing ones, but that is another entirely different mode), but also can be used to set attributes to an existing branch. Imagine a new option, say --set-description, to replace

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Jonathan Nieder jrnie...@gmail.com writes: The truth is that neither one of us is right. Both conventions could work, and which one is more intuitive will vary from person to person. It is not just person-to-person, I think. In short, you are saying that, assuming that missing start and

Re: [PATCH/RFC] git-svn: don't create master if another head exists

Junio C Hamano gits...@pobox.com wrote: Marcin Owsiany mar...@owsiany.pl writes: This makes my idea to do the same to my something else instead of master much less attractive. In fact I don't think such behaviour would be useful. I think with the suggested patch git-svn works as I

Re: [PATCH 1/3] branch: introduce --set-upstream-to

Junio C Hamano wrote: In short, you are saying that, assuming that missing start and branch are given a sane default values (namely HEAD), the syntax: git branch branch [start] git branch --set-upstream-jrn [branch] upstream is easier to understand I didn't propose allowing