Aw: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Thomas Ackermann
Hi Jiang, this happens with all of my repo clones (I am using V1.8.5.2 on Windows and on Linux). Steps to reproduce: mkdir repo_a cd repo_a git init . echo 1foo git add foo git commit -m 1 cd .. git clone repo_a repo_b cd repo_a echo 2foo git add foo git commit -m 2 cd ../repo_b git

Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Bryan Turner
On 6 January 2014 01:24, Thomas Ackermann th.ac...@arcor.de wrote: Hi Jiang, this happens with all of my repo clones (I am using V1.8.5.2 on Windows and on Linux). Steps to reproduce: mkdir repo_a cd repo_a git init . echo 1foo git add foo git commit -m 1 cd .. git clone repo_a

Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Jiang Xin
2014/1/6 Thomas Ackermann th.ac...@arcor.de: Hi Jiang, this happens with all of my repo clones (I am using V1.8.5.2 on Windows and on Linux). Steps to reproduce: mkdir repo_a cd repo_a git init . echo 1foo git add foo git commit -m 1 cd .. git clone repo_a repo_b cd repo_a echo

Aw: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Thomas Ackermann
Unfortunately that's not true. In repo_b your ref for origin/master has not moved. It has remotely (meaning refs/heads/master in repo_a has moved), but git status is not hitting the remote to find out; it only looks at the local state. To see what I mean, run git fetch in repo_b. Once you

[PATCH v2 00/17] Fix some mkdir/rmdir races

2014-01-06 Thread Michael Haggerty
This is v2 of changes [1] to remove some mkdir/rmdir races around safe_create_leading_directories() and a couple of its callers. Thanks to Jonathan Nieder for his thorough review of v1 and to Ramsay Jones for pointing out a typo. I think I have addressed all of their suggestions. This patch

[PATCH v2 01/17] safe_create_leading_directories(): fix format of if chaining

2014-01-06 Thread Michael Haggerty
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- sha1_file.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/sha1_file.c b/sha1_file.c index daacc0c..c9245a6 100644 --- a/sha1_file.c +++ b/sha1_file.c @@ -125,8 +125,7 @@ int safe_create_leading_directories(char

[PATCH v2 02/17] safe_create_leading_directories(): reduce scope of local variable

2014-01-06 Thread Michael Haggerty
This makes it more obvious that values of st don't persist across loop iterations. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- sha1_file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sha1_file.c b/sha1_file.c index c9245a6..cc9957e 100644 --- a/sha1_file.c

[PATCH v2 09/17] safe_create_leading_directories(): add new error value SCLD_VANISHED

2014-01-06 Thread Michael Haggerty
Add a new possible error result that can be returned by safe_create_leading_directories() and safe_create_leading_directories_const(): SCLD_VANISHED. This value indicates that a file or directory on the path existed at one point (either it already existed or the function created it), but then it

[PATCH v2 16/17] rename_tmp_log(): limit the number of remote_empty_directories() attempts

2014-01-06 Thread Michael Haggerty
This doesn't seem to be a likely error, but we've got the counter anyway, so we might as well use it for an added bit of safety. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- refs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/refs.c b/refs.c index

[PATCH v2 13/17] remove_dir_recurse(): handle disappearing files and directories

2014-01-06 Thread Michael Haggerty
If a file or directory that we are trying to remove disappears (e.g., because another process has pruned it), do not consider it an error. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- dir.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git

[PATCH v2 12/17] remove_dir_recurse(): tighten condition for removing unreadable dir

2014-01-06 Thread Michael Haggerty
If opendir() fails on the top-level directory, it makes sense to try to delete it anyway--but only if the failure was due to EACCES. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- dir.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/dir.c b/dir.c index

[PATCH v2 11/17] lock_ref_sha1_basic(): if locking fails with ENOENT, retry

2014-01-06 Thread Michael Haggerty
If hold_lock_file_for_update() fails with errno==ENOENT, it might be because somebody else (for example, a pack-refs process) has just deleted one of the lockfile's ancestor directories. So if this condition is detected, try again (up to 3 times). Signed-off-by: Michael Haggerty

[PATCH v2 17/17] rename_tmp_log(): on SCLD_VANISHED, retry

2014-01-06 Thread Michael Haggerty
If safe_create_leading_directories() fails because a file along the path unexpectedly vanished, try again from the beginning. Try at most 3 times. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- refs.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/refs.c

[PATCH v2 04/17] safe_create_leading_directories(): rename local variable

2014-01-06 Thread Michael Haggerty
Rename pos to next_component, because now it always points at the next component of the path name that has to be processed. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- sha1_file.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sha1_file.c

Re: [PATCH] remote-hg: do not fail on invalid bookmarks

2014-01-06 Thread Torsten Bögershausen
On 2013-12-29 12.30, Antoine Pelisse wrote: Mercurial can have bookmarks pointing to nullid (the empty root revision), while Git can not have references to it. When cloning or fetching from a Mercurial repository that has such a bookmark, the import will fail because git-remote-hg will not be

[PATCH v2 06/17] safe_create_leading_directories(): always restore slash at end of loop

2014-01-06 Thread Michael Haggerty
Always restore the slash that we scribbled over at the end of the loop, rather than also fixing it up at each premature exit from the loop. This makes it harder to forget to do the cleanup as new paths are added to the code. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- sha1_file.c |

Re: Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-06 Thread Heiko Voigt
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote: 2014/1/5 Heiko Voigt hvo...@hvoigt.net: The following questions directly pop into my mind: - What means the maintainer does not track the submodules sha1? Does that mean the superproject always refers to submodule

Re: Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-06 Thread Heiko Voigt
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote: 2014/1/5 Heiko Voigt hvo...@hvoigt.net: Could you please extend the description of your use-case so we can understand your goal better? Maybe I found better words to explain you my goal: the current git submodule use-case

Re: Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread Heiko Voigt
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote: 2014/1/5 W. Trevor King wk...@tremily.us: On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote: Also it could break some users that rely on the current behavior. The current code always has a detached HEAD after

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Sun, Dec 22, 2013 at 09:55:23PM +, Ben Maurer wrote: One issue with this approach is that it seems git-pack-index doesn't perform as well with thin packs. git-index-pack uses a multi-threaded approach to resolving the deltas. However, the multithreading only works on deltas that are

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Sun, Dec 22, 2013 at 11:47:34AM -0800, Ben Maurer wrote: Jeff King's bitmap branch appears to give a very substantial speedup. After applying this branch, the counting objects phase is basically free. However, I found that the compression phase still takes a non-trivial amount of time.

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Fri, Jan 03, 2014 at 04:12:51PM -0500, Matt Burke wrote: + git init -q + git fetch -q -fu ../../../other '+refs/*:refs/*' fatal: bad object 9b985fbe6a2b783c16756077a8be261c94b6c197 error: ../../../other did not send all necessary objects I was going to

Re: [PATCH v2] git-svn: workaround for a bug in svn serf backend

2014-01-06 Thread Andreas Stricker
Hi Roman git-svn: workaround for a bug in svn serf backend (2013-12-27 20:22:19 +) Thanks! Well thanks to you for finding and fixing this bug that really annoyed me just before Christmas again. Your bug analysis proved my observation that even a fresh checkout (as I suggested in my

Re: Re: Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread Heiko Voigt
On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote: On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote: On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote: If submodule.name.branch is set, it *always* creates a new local branch of that name pointing to the

Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Jonathan Nieder
Hi, Thomas Ackermann wrote: In repo_b your ref for origin/master has not moved. It has remotely (meaning refs/heads/master in repo_a has moved), but git status is not hitting the remote to find out; it only looks at the local state. [...] But for the simple

Re: [PATCH 2/2] Introduce git submodule attached update

2014-01-06 Thread W. Trevor King
On Mon, Jan 06, 2014 at 03:18:05PM +0100, Heiko Voigt wrote: If you simply want to always checkout the development tip of some project you could do something like this: git submodule foreach 'git fetch git checkout origin/master' Or (respecting submodule.name.branch): $ git

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Junio C Hamano
Jeff King p...@peff.net writes: We could probably teach index-pack an --assume-refs-are-thin option to optimize for this case, and have fetch-pack/receive-pack pass it whenever they know that delta-base-offset was negotiated. I thought the existing negotiation merely means I understand offset

Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread Junio C Hamano
Heiko Voigt hvo...@hvoigt.net writes: On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote: 2014/1/5 W. Trevor King wk...@tremily.us: On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote: Also it could break some users that rely on the current behavior. The

Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command

2014-01-06 Thread Junio C Hamano
W. Trevor King wk...@tremily.us writes: On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote: +case $update_module in +'') +;; # Unset update mode +checkout | rebase | merge | none) +

Aw: Re: Re: Re: [Bug report] 'git status' always says Your branch is up-to-date with 'origin/master'

2014-01-06 Thread Thomas Ackermann
But for the simple use case where you only have a master branch I consider it not really helpful and - at least for me - misleading. I see what you mean, and you're not the only one. Git follows a rule of never contact another machine unless explicitly asked to using a command such

Re: [GIT PULL] l10n update for maint branch

2014-01-06 Thread Junio C Hamano
Jiang Xin worldhello@gmail.com writes: Please pull l10n update for maint branch. It can be merged to master without conflict. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
A very common workflow for preparing patches involves working off a topic branch and generating patches against 'master' to send off to the maintainer. However, a plain $ git format-patch -o outgoing is a no-op on a topic branch, and the user has to remember to specify 'master' explicitly

Re: [PATCH] Improve user-manual html and pdf formatting

2014-01-06 Thread Junio C Hamano
Thomas Ackermann th.ac...@arcor.de writes: Use asciidoc style 'article' instead of 'book' and change asciidoc title level. This removes blank first page and superfluous Part I page (there is no Part II) in pdf output. Also pdf size is decreased by this from 77 to 67 pages. In html output

Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread W. Trevor King
On Mon, Jan 06, 2014 at 04:47:39PM +0100, Heiko Voigt wrote: On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote: On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote: On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote: Thinking through this more, perhaps

[PATCH 1/2] completion: complete format.coverLetter

2014-01-06 Thread Ramkumar Ramachandra
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 51c2dd4..39b81f7 100644 ---

Re: [PATCH 0/2] Minor convinience feature: format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Ramkumar Ramachandra wrote: Ramkumar Ramachandra (2): completion: complete format.coverLetter format-patch: introduce format.defaultTo Any thoughts on checkout.defaultTo? I have a com alias to checkout 'master'. -- To unsubscribe from this list: send the line unsubscribe git in the body of

Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread W. Trevor King
On Mon, Jan 06, 2014 at 08:56:22AM -0800, Junio C Hamano wrote: Heiko Voigt hvo...@hvoigt.net writes: Yes, why would you do a git pull in a submodule? Don't you want to do something like git checkout -t -b dev/my-topic origin/master to start your development? As long as

[BUG] rebase --onto doesn't abort properly

2014-01-06 Thread Ramkumar Ramachandra
Hi, On the latest git, I noticed that a rebase --onto doesn't abort properly. Steps to reproduce: # on some topic branch $ git rebase --onto master @~10 ^C # quickly! $ git rebase --abort # HEAD is still detached I tried going back a few revisions, and the bug seems to be very old;

Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command

2014-01-06 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: W. Trevor King wk...@tremily.us writes: On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote: + case $update_module in + '') + ;; # Unset update mode +

Re: [PATCH 1/2] git-submodule.sh: Support 'checkout' as a valid update command

2014-01-06 Thread Francesco Pretto
Ok, applying the suggested modifications and resending shortly. Thank you, Francesco 2014/1/6 Junio C Hamano gits...@pobox.com: Junio C Hamano gits...@pobox.com writes: W. Trevor King wk...@tremily.us writes: On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote: +

Re: [PATCH v2 10/17] lock_ref_sha1_basic(): on SCLD_VANISHED, retry

2014-01-06 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu writes: If safe_create_leading_directories() fails because a file along the path unexpectedly vanished, try again (up to 3 times). This can occur if another process is deleting directories at the same time as we are trying to make them. For example, git

Re: [PATCH v2 13/17] remove_dir_recurse(): handle disappearing files and directories

2014-01-06 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu writes: If a file or directory that we are trying to remove disappears (e.g., because another process has pruned it), do not consider it an error. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- dir.c | 22 -- 1 file

Re: [PATCH v2 17/17] rename_tmp_log(): on SCLD_VANISHED, retry

2014-01-06 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu writes: If safe_create_leading_directories() fails because a file along the path unexpectedly vanished, try again from the beginning. Try at most 3 times. As the previous step bumped it from 3 to 4 without explanation, the above no longer reflects

Re: [PATCH v2 03/17] safe_create_leading_directories(): add explicit slash pointer

2014-01-06 Thread Junio C Hamano
Michael Haggerty mhag...@alum.mit.edu writes: Keep track of the position of the slash character independently of pos, thereby making the purpose of each variable clearer and working towards other upcoming changes. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- This step has an

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jonathan Nieder
Hi, Ramkumar Ramachandra wrote: a plain $ git format-patch -o outgoing is a no-op on a topic branch, and the user has to remember to specify 'master' explicitly everytime. Save the user the extra keystrokes by introducing format.defaultTo Not excited. Two reasons:

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: A very common workflow for preparing patches involves working off a topic branch and generating patches against 'master' to send off to the maintainer. However, a plain $ git format-patch -o outgoing is a no-op on a topic branch,... Two

Re: [BUG] rebase --onto doesn't abort properly

2014-01-06 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Hi, On the latest git, I noticed that a rebase --onto doesn't abort properly. Steps to reproduce: # on some topic branch $ git rebase --onto master @~10 ^C # quickly! $ git rebase --abort # HEAD is still detached I do not think

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote: - why is a single branch name sufficient? It does accept a revision, so any form is allowed; but why would anyone want that in a format.defaultTo? I'm not sure we want to impose an artificial restriction on the configuration variable though. - is it a better option to

Re: [BUG] rebase --onto doesn't abort properly

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote: I do not think --abort was designed to abort an uncontrolled stop like ^C in the first place. Why not? All it requires is a reset --hard to .git/rebase-apply/head-name, as usual, no? To allow that kind of recovery, you need to teach rebase to first record the state you

[PATCH] git-submodule.sh: Support 'checkout' as a valid update command

2014-01-06 Thread Francesco Pretto
According to Documentation/gitmodules.txt, 'checkout' is a valid 'submodule.name.update' command. Also git-submodule.sh refers to it and processes it correctly. Reflecting commit 'ac1fbb' to support this syntax and also validate property values during 'update' command, issuing an error if the

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Jonathan Nieder wrote: 1. Most config settings are in noun form: e.g., [remote] pushDefault = foo. That makes their names easy to guess and makes them easy to talk about: I set the default remote for pushing by changing the remote.pushdefault setting. '[url foo] insteadOf'

[PATCH] mv: better document side effects when moving a submodule

2014-01-06 Thread Jens Lehmann
The Submodules section of the git mv documentation mentions what will happen when a submodule with a gitfile gets moved with newer git. But it doesn't talk about what happens when the user changes between commits before and after the move, which does not update the work tree like using the mv

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 08:16:31AM -0800, Junio C Hamano wrote: I was going to ask you to send your repository, but I can easily reproduce here. I guess people don't run into it because it's uncommon to fetch the whole refs/ namespace from a non-bare repo (and bare repos do not tend to

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 08:37:49AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: We could probably teach index-pack an --assume-refs-are-thin option to optimize for this case, and have fetch-pack/receive-pack pass it whenever they know that delta-base-offset was

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: - why is a single branch name sufficient? It does accept a revision, so any form is allowed; but why would anyone want that in a format.defaultTo? I'm not sure we want to impose an artificial restriction on the

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Mon, Jan 06, 2014 at 08:16:31AM -0800, Junio C Hamano wrote: I was going to ask you to send your repository, but I can easily reproduce here. I guess people don't run into it because it's uncommon to fetch the whole refs/ namespace from a non-bare repo

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote: Unless you set @{u} to this new configuration, in which case the choice becomes dynamic depending on the current branch, but - if that is the only sane choice based on the current branch, why not use that as the default

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread John Szakmeister
On Mon, Jan 6, 2014 at 3:18 PM, Jeff King p...@peff.net wrote: On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote: Unless you set @{u} to this new configuration, in which case the choice becomes dynamic depending on the current branch, but - if that is the only sane choice based

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Mon, Jan 06, 2014 at 12:06:51PM -0800, Junio C Hamano wrote: Unless you set @{u} to this new configuration, in which case the choice becomes dynamic depending on the current branch, but - if that is the only sane choice based on the current branch, why

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 09:57:23AM -0500, Jeff King wrote: diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index c733379..0cff874 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -1402,6 +1402,19 @@ static void check_object(struct object_entry *entry)

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jonathan Nieder
John Szakmeister wrote: I think in a typical, feature branch-based workflow @{u} would be nearly useless. I thought the idea of @{u} was that it represents which ref one typically wants to compare the current branch to. It is used by 'git

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 03:29:57PM -0500, John Szakmeister wrote: Yeah, I had similar thoughts. I personally use branch.*.merge as forkedFrom, and it seems like we are going that way anyway with things like git rebase and git merge defaulting to upstream. But then there is git push -u and

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote: I wonder if it is too late to try to clarify this dual usage. It kind of seems like the push config is this is the place I publish to. Which, in many workflows, just so happens to be the exact same as the place you forked

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread John Szakmeister
On Mon, Jan 6, 2014 at 3:42 PM, Jonathan Nieder jrnie...@gmail.com wrote: John Szakmeister wrote: I think in a typical, feature branch-based workflow @{u} would be nearly useless. I thought the idea of @{u} was that it represents which

RE: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Ben Maurer
Sorry for the slow reply; I've been on vacation. No worries. When you build your bitmaps, do you set the pack.writeBitmapHashCache option? We found that it makes a significant difference during the compression phase, as otherwise git attempts deltas between random files based on size. Here

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Junio C Hamano
Jeff King p...@peff.net writes: On Mon, Jan 06, 2014 at 12:38:30PM -0800, Junio C Hamano wrote: I wonder if it is too late to try to clarify this dual usage. It kind of seems like the push config is this is the place I publish to. Which, in many workflows, just so happens to be the exact

Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread Junio C Hamano
W. Trevor King wk...@tremily.us writes: And wouldn't it make it unnecessary to have a new re-attach option if such a mode that never have to detach is used? I think so, but we currently don't have a never detached route for folks that are cloning submodules via update (instead of via

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Junio C Hamano
John Szakmeister j...@szakmeister.net writes: Am I missing something? If there is something other than @{u} to represent this latter concept, I think `git push` should default to that instead. But, at least with my current knowledge, that doesn't exist--without explicitly saying so--or

Re: [PATCH] remote-hg: do not fail on invalid bookmarks

2014-01-06 Thread Antoine Pelisse
Thanks for noticing, I can reproduce at work, I will try to come-up with an improved version soon, Cheers, Antoine On Mon, Jan 6, 2014 at 2:52 PM, Torsten Bögershausen tbo...@web.de wrote: On 2013-12-29 12.30, Antoine Pelisse wrote: Mercurial can have bookmarks pointing to nullid (the empty

Re: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 09:15:04PM +, Ben Maurer wrote: Let me know how this patch does for you. My testing has been fairly limited so far. This patch looks like a much cleaner version :-). Works well for me, but my test setup may not be great since I didn't get any errors from

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote: I meant a single branch as opposed to depending on what branch you are sending out, you may have to use a different upstream starting point, and a single format.defaultTo that does not read what your HEAD currently points at may not be enough. Unless you set @{u} to

static initializers

2014-01-06 Thread Stefan Zager
Howdy, Is there any policy on making static initializers thread-safe? I'm working on an experimental patch to introduce threading, but I'm running into a few non-thread-safe bits like this, in convert.c: static const char *conv_attr_name[] = { crlf, ident, filter, eol, text, }; #define

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Jeff King wrote: Yeah, I had similar thoughts. I personally use branch.*.merge as forkedFrom, and it seems like we are going that way anyway with things like git rebase and git merge defaulting to upstream. My issue with that is that I no idea where my branch is with respect to my forked

RE: [PATCH] [RFC] Making use of bitmaps for thin objects

2014-01-06 Thread Ben Maurer
It looks like for my repo the size win wasn't as big (~10%). Is it possible that with the kernel test you got extremely lucky and there was some huge binary blob that thin packing turned into a tiny delta? The repo I'm testing with here isn't a typical codebase -- it is used to store

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Junio C Hamano
Ramkumar Ramachandra artag...@gmail.com writes: Junio C Hamano wrote: I meant a single branch as opposed to depending on what branch you are sending out, you may have to use a different upstream starting point, and a single format.defaultTo that does not read what your HEAD currently points

What's cooking in git.git (Jan 2014, #01; Mon, 6)

2014-01-06 Thread Junio C Hamano
Welcome to the first issue of What's cooking report for the new year. Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. You can find the changes described here in the integration branches of

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
Junio C Hamano wrote:. As I said in the different subthread, I am not convinced that you would need the complexity of branch.*.forkedFrom. If you set your upstream to the true upstream (not your publishing point), and have remote.pushdefaultset to 'publish', you can expect git push

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread Ramkumar Ramachandra
John Szakmeister wrote: Then where does it get pushed? Do you always specify where to save your work? FWIW, I think the idea of treating @{u} as the eventual recipient of your changes is good, but then it seems like Git is lacking the publish my changes to this other branch concept. Am I

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Jeff King
On Mon, Jan 06, 2014 at 12:17:21PM -0800, Junio C Hamano wrote: I am fine with rejecting it with a warning, but we should not then complain that the other side did not send us the object, since we should not be asking for it at all. I also do not see us complaining about the funny ref

Re: Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread Francesco Pretto
2014/1/6 Heiko Voigt hvo...@hvoigt.net: I agree. If we were to support this more easily we could add a configuration option so you can omit the --remote (i.e.: submodule.name.remote=true, as I also suggested in the other email). That way the developer checking out a branch in flight does not

Re: What's cooking in git.git (Jan 2014, #01; Mon, 6)

2014-01-06 Thread Francesco Pretto
2014/1/6 Junio C Hamano gits...@pobox.com: - git-submodule.sh: support 'checkout' as a valid update mode Need to pick up a rerolled one. I resent it, can you see it? Thank you, Francesco -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Junio C Hamano
Jeff King p...@peff.net writes: Then we ask fetch_refs_via_pack to get the actual objects for us. And it checks our refs again, with this call chain: do_fetch fetch_refs transport_fetch_refs fetch_refs_via_pack fetch_pack do_fetch_pack

Re: What's cooking in git.git (Jan 2014, #01; Mon, 6)

2014-01-06 Thread Junio C Hamano
Francesco Pretto ceztk...@gmail.com writes: 2014/1/6 Junio C Hamano gits...@pobox.com: - git-submodule.sh: support 'checkout' as a valid update mode Need to pick up a rerolled one. I resent it, can you see it? I know. I saw it and that is why I left the note to self. The thing is, it

Re: Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread Francesco Pretto
2014/1/7 Francesco Pretto cez...@gmail.com: To not break the existing behavior what it's really needed here, IMO, is a submodule.name.attached property that says two things: - at the first clone on git submodule update stay attached to submodule.name.branch; - implies --remote, as it's the

Re: [PATCH] mv: better document side effects when moving a submodule

2014-01-06 Thread Junio C Hamano
Jens Lehmann jens.lehm...@web.de writes: The Submodules section of the git mv documentation mentions what will happen when a submodule with a gitfile gets moved with newer git. But it doesn't talk about what happens when the user changes between commits before and after the move, which does

Re: What's cooking in git.git (Jan 2014, #01; Mon, 6)

2014-01-06 Thread Francesco Pretto
2014/1/7 Junio C Hamano gits...@pobox.com: The thing is, it takes a non trivial amount of time to run through a single day's integration cycle, and any reroll that comes later in a day once the cycle started may be too late for that day. Otherwise I have to discard the the result of earlier

Re: [PATCH] git-submodule.sh: Support 'checkout' as a valid update command

2014-01-06 Thread Junio C Hamano
Francesco Pretto cez...@gmail.com writes: According to Documentation/gitmodules.txt, 'checkout' is a valid 'submodule.name.update' command. As you can see in the surrounding text, we call the value of submodule.*.update a mode, not a command. Also git-submodule.sh refers to it and processes

Re: [PATCH] git-submodule.sh: Support 'checkout' as a valid update command

2014-01-06 Thread Francesco Pretto
2014/1/7 Junio C Hamano gits...@pobox.com: Francesco Pretto cez...@gmail.com writes: According to Documentation/gitmodules.txt, 'checkout' is a valid 'submodule.name.update' command. As you can see in the surrounding text, we call the value of submodule.*.update a mode, not a command. Ok.

Re: [msysGit] Fwd: static initializers

2014-01-06 Thread Erik Faye-Lund
On Mon, Jan 6, 2014 at 11:05 PM, Stefan Zager sza...@google.com wrote: Forwarding to msysgit for any guidance about win equivalents for PTHREAD_MUTEX_INITIALIZER or __attribute__((constructor)). As you've probably already guessed, PTHREAD_MUTEX_INITIALIZER isn't supported in our

Re: [PATCH 2/2] format-patch: introduce format.defaultTo

2014-01-06 Thread John Szakmeister
On Mon, Jan 6, 2014 at 5:54 PM, Ramkumar Ramachandra artag...@gmail.com wrote: John Szakmeister wrote: Then where does it get pushed? Do you always specify where to save your work? FWIW, I think the idea of treating @{u} as the eventual recipient of your changes is good, but then it seems

Re: [RFC v2] submodule: Respect requested branch on all clones

2014-01-06 Thread Francesco Pretto
2014/1/6 Junio C Hamano gits...@pobox.com: As long as origin/master contains the commit specified by the superproject, that would work, but it may be a good thing to use a mode of submodule.*.update that does not have to drop the user into a detached state in the first place. I somehow

Re: [PATCH] git-submodule.sh: Support 'checkout' as a valid update command

2014-01-06 Thread Francesco Pretto
2014/1/7 Junio C Hamano gits...@pobox.com: Sorry, but -ECANNOTPARSE. A bird told me what -ECANNOTPARSE means. Tell me if this comment sounds better: According to Documentation/gitmodules.txt, 'checkout' is a valid 'submodule.name.update' mode. Also git-submodule.sh already refers to it and

[PATCH] pager: set LV=-c alongside LESS=FRSX

2014-01-06 Thread Jonathan Nieder
On systems with lv configured as the preferred pager (i.e., DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the environment) git commands that use color show control codes instead of color in the pager: $ git diff ^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m

Re: Bug report: stash in upstream caused remote fetch to fail

2014-01-06 Thread Junio C Hamano
Junio C Hamano gits...@pobox.com writes: It's really not clear to me what the check in filter_refs was trying to do. It dates all the way back to 1baaae5 (Make maximal use of the remote refs, 2005-10-28), but there is not much explanation. I haven't dug into the list around that time to see

[PATCH] sha1_name: don't resolve refs when core.warnambiguousrefs is false

2014-01-06 Thread Brodie Rao
This change ensures get_sha1_basic() doesn't try to resolve full hashes as refs when ambiguous ref warnings are disabled. This provides a substantial performance improvement when passing many hashes to a command (like git rev-list --stdin) when core.warnambiguousrefs is false. The check incurs 6

Re: [PATCH] sha1_name: don't resolve refs when core.warnambiguousrefs is false

2014-01-06 Thread Brodie Rao
On Mon, Jan 6, 2014 at 7:32 PM, Brodie Rao bro...@sf.io wrote: This change ensures get_sha1_basic() doesn't try to resolve full hashes as refs when ambiguous ref warnings are disabled. This provides a substantial performance improvement when passing many hashes to a command (like git rev-list