Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-24 Thread Junio C Hamano 
Max Horn m...@quendi.de writes:

 On 21.02.2014, at 19:04, Junio C Hamano gits...@pobox.com wrote:

  Isn't it possible for some helpers to _do_ want to
 tell us that it did not have to force after all by _not_ saying
 forced update and overwrite -forced_update with zero?

 Yes to the first part, no to the last bit: Yes, a transport helper
 can (and frequently does) tell us that no force happened -- by not
 saying forced update.
 ...
  How do we tell helpers that do want to do so apart from other
 helpers that say forced update only when they noticed they are
 indeed forcing?

 I am not completely sure I even understand that bit?

I think I phrased it too imprecisely.

If nobody even knew about the forced update before hg helper, then
they by definition do not wish to overwrite, of course.  But I was
worried if we are closing the door for this possible scenario:

 * the calling side sets ref-forced_update to true before invoking
   the helper, knowing that this update is not fast-forward; and

 * the helper does a magic (after all, we are talking with an
   external mechanism, which may be a different SCM like darcs) to
   rebase our change on top of the history that the other side
   already have, and makes it a fast-forward, non-forced push.

Such a helper would want a way to say You may have thought that
this does not fast-forward, but the push result ended up to be a
fast-forward update, and if we wanted to support that, one thing we
may need to allow it to do is to reset ref-forced_update to zero.

But I think I was worried too much into the future---I agree that
the code can stay as you proposed until such a remote-helper needs
more support, because overwrite with zero is necessary but is
probably not sufficient---it also may need to be able to tell us
what the final resulting commit of the push is, for example.

--
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  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-24 Thread Junio C Hamano 
Junio C Hamano gits...@pobox.com writes:

 But I think I was worried too much into the future---I agree that
 the code can stay as you proposed until such a remote-helper needs
 more support, because overwrite with zero is necessary but is
 probably not sufficient---it also may need to be able to tell us
 what the final resulting commit of the push is, for example.

So, here is what I'll queue (with forged s-o-b).

Thanks.

-- 8 --
From: Max Horn m...@quendi.de
Date: Fri, 21 Feb 2014 10:55:59 +0100
Subject: [PATCH] transport-helper.c: do not overwrite forced bit

If the the transport helper says it was a forced update, then it is
a forced update.  It is however possible that an update is forced
without the transport-helper knowing about it, namely because some
higher up code had objections to the update and needed forcing in
order to let it through to the transport helper.  In other words, it
does not necessarily mean the update was *not* forced, when the
helper did not say forced update.

Signed-off-by: Max Horn m...@quendi.de
Signed-off-by: Junio C Hamano gits...@pobox.com
---
 transport-helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/transport-helper.c b/transport-helper.c
index abe4c3c..705dce7 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -727,7 +727,7 @@ static int push_update_ref_status(struct strbuf *buf,
}
 
(*ref)-status = status;
-   (*ref)-forced_update = forced;
+   (*ref)-forced_update |= forced;
(*ref)-remote_status = msg;
return !(status == REF_STATUS_OK);
 }
-- 
1.9.0-291-g027825b

--
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  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-24 Thread Max Horn 


 Am 24.02.2014 um 18:06 schrieb Junio C Hamano gits...@pobox.com:
 
 Junio C Hamano gits...@pobox.com writes:
 
 But I think I was worried too much into the future---I agree that
 the code can stay as you proposed until such a remote-helper needs
 more support, because overwrite with zero is necessary but is
 probably not sufficient---it also may need to be able to tell us
 what the final resulting commit of the push is, for example.
 
 So, here is what I'll queue (with forged s-o-b).

Thank you, I hereby declare the forged s-o-b as legit ;-)

 
 Thanks.
 
 -- 8 --
 From: Max Horn m...@quendi.de
 Date: Fri, 21 Feb 2014 10:55:59 +0100
 Subject: [PATCH] transport-helper.c: do not overwrite forced bit
 
 If the the transport helper says it was a forced update, then it is
 a forced update.  It is however possible that an update is forced
 without the transport-helper knowing about it, namely because some
 higher up code had objections to the update and needed forcing in
 order to let it through to the transport helper.  In other words, it
 does not necessarily mean the update was *not* forced, when the
 helper did not say forced update.
 
 Signed-off-by: Max Horn m...@quendi.de
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
 transport-helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/transport-helper.c b/transport-helper.c
 index abe4c3c..705dce7 100644
 --- a/transport-helper.c
 +++ b/transport-helper.c
 @@ -727,7 +727,7 @@ static int push_update_ref_status(struct strbuf *buf,
}
 
(*ref)-status = status;
 -(*ref)-forced_update = forced;
 +(*ref)-forced_update |= forced;
(*ref)-remote_status = msg;
return !(status == REF_STATUS_OK);
 }
 -- 
 1.9.0-291-g027825b
 
 
--
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  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-21 Thread Max Horn 

On 20.02.2014, at 20:22, Junio C Hamano gits...@pobox.com wrote:

 Max Horn m...@quendi.de writes:
 
 On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:
 
 * fc/transport-helper-fixes (2013-12-09) 6 commits
 - remote-bzr: support the new 'force' option
 - test-hg.sh: tests are now expected to pass
 - transport-helper: check for 'forced update' message
 - transport-helper: add 'force' to 'export' helpers
 - transport-helper: don't update refs in dry-run
 - transport-helper: mismerge fix
 
 Reported to break t5541, and has been stalled for a while without
 fixes.
 ...
 Since I somewhat care about transport-helpers, I had a closer look
 at this failure.
 
 Thanks.  Let's keep it a bit longer and see how your new
 investigation (and possibly help from others) develops to a
 solution.

So I had a closer look, and I now believe to now understand what the right fix 
is. Simply dropping 
  transport-helper: check for 'forced update' message
would be wrong, because it would cause the contrib/remote-helpers test cases to 
fail -- when I tested last night, I forgot that I had to run those separately. 
Silly me!

Indeed, these tests include a test with a force push, and trigger the code path 
added in that commit. The remaining problem then is that the new code should be 
changed to only tell git when a remote-helper signals a forced update; but it 
should not incorrectly reset the forced_update flag to 0 if git already 
considers the update to be forced.

In other words, the following patch should be the correct solution, as far as I 
can tell. I verified that it fixes t5541 and causes no regressions in the 
contrib/remote-helpers test suite.

-- 8 --
diff --git a/transport-helper.c b/transport-helper.c
index fa7c608..86e1679 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -734,7 +734,7 @@ static int push_update_ref_status(struct strbuf *buf,
}

(*ref)-status = status;
-   (*ref)-forced_update = forced;
+   (*ref)-forced_update |= forced;
(*ref)-remote_status = msg;
return !(status == REF_STATUS_OK);
 }
-- 8 --




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-21 Thread Torsten Bögershausen 
On 2014-02-21 10.55, Max Horn wrote:
 
 On 20.02.2014, at 20:22, Junio C Hamano gits...@pobox.com wrote:
 
 Max Horn m...@quendi.de writes:

 On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:

 * fc/transport-helper-fixes (2013-12-09) 6 commits
 - remote-bzr: support the new 'force' option
 - test-hg.sh: tests are now expected to pass
 - transport-helper: check for 'forced update' message
 - transport-helper: add 'force' to 'export' helpers
 - transport-helper: don't update refs in dry-run
 - transport-helper: mismerge fix

 Reported to break t5541, and has been stalled for a while without
 fixes.
 ...
 Since I somewhat care about transport-helpers, I had a closer look
 at this failure.

 Thanks.  Let's keep it a bit longer and see how your new
 investigation (and possibly help from others) develops to a
 solution.
 
 So I had a closer look, and I now believe to now understand what the right 
 fix is. Simply dropping 
   transport-helper: check for 'forced update' message
 would be wrong, because it would cause the contrib/remote-helpers test cases 
 to fail -- when I tested last night, I forgot that I had to run those 
 separately. Silly me!
 
 Indeed, these tests include a test with a force push, and trigger the code 
 path added in that commit. The remaining problem then is that the new code 
 should be changed to only tell git when a remote-helper signals a forced 
 update; but it should not incorrectly reset the forced_update flag to 0 if 
 git already considers the update to be forced.
 
 In other words, the following patch should be the correct solution, as far as 
 I can tell. I verified that it fixes t5541 and causes no regressions in the 
 contrib/remote-helpers test suite.
 
 -- 8 --
 diff --git a/transport-helper.c b/transport-helper.c
 index fa7c608..86e1679 100644
 --- a/transport-helper.c
 +++ b/transport-helper.c
 @@ -734,7 +734,7 @@ static int push_update_ref_status(struct strbuf *buf,
 }
 
 (*ref)-status = status;
 -   (*ref)-forced_update = forced;
 +   (*ref)-forced_update |= forced;
 (*ref)-remote_status = msg;
 return !(status == REF_STATUS_OK);
  }
 -- 8 --
 
 
Ack from my side:

There are 2 fields:
ref-force and ref-forced_update.

forced_update is set in set_ref_status_for_push() in remote.c:

if (!force_ref_update)
ref-status = reject_reason;
else if (reject_reason)
ref-forced_update = 1;
}
And transport-helper.c sets it to 0 even if it had been 1, which is wrong.

--
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  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-21 Thread Ramkumar Ramachandra 
Junio C Hamano wrote:
 * jk/branch-at-publish-rebased (2014-01-17) 5 commits
  - t1507 (rev-parse-upstream): fix typo in test title
  - implement @{publish} shorthand
  - branch_get: provide per-branch pushremote pointers
  - branch_get: return early on error
  - sha1_name: refactor upstream_mark

  Give an easier access to the tracking branches from other side in
  a triangular workflow by introducing B@{publish} that works in a
  similar way to how B@{upstream} does.

  Meant to be used as a basis for whatever Ram wants to build on.

  Will hold.

Since I've decided that I don't have the time to work on this, we've
added this to the list of project ideas for GSoC 2014
(http://git.github.io/SoC-2014-Ideas.html). Hopefully, a student will
come along and volunteer to finish this.
--
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  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-21 Thread Junio C Hamano 
Max Horn m...@quendi.de writes:

 Thanks.  Let's keep it a bit longer and see how your new
 investigation (and possibly help from others) develops to a
 solution.

 So I had a closer look, and I now believe to now understand what
 the right fix is. Simply dropping transport-helper: check for
 'forced update' message would be wrong, because it would cause the
 contrib/remote-helpers test cases to fail -- when I tested last
 night, I forgot that I had to run those separately. Silly me!
 ...
 In other words, the following patch should be the correct
 solution, as far as I can tell. I verified that it fixes t5541 and
 causes no regressions in the contrib/remote-helpers test suite.

Here is a description I wrote for a tentative commit to queue on
'pu' after seeing your response:

transport-helper.c: do not overwrite forced bit

It does not necessarily mean the update was *not* forced, when the
helper did not say forced update.  When the helper does say so, we
know the update is forced.

A workaround to fix breakage introduced by the previous step,
proposed by Max Horn.

It troubled me that it does not necessarily mean sounded really
wishy-washy.  Isn't it possible for some helpers to _do_ want to
tell us that it did not have to force after all by _not_ saying
forced update and overwrite -forced_update with zero?  How do we
tell helpers that do want to do so apart from other helpers that say
forced update only when they noticed they are indeed forcing?

Perhaps the logic needs to be more like:

if (we know helper will tell us the push did not have to
force by *not* saying forced update) {
(*ref)-forced_update = forced;
}

i.e. for helpers that do not use the 'forced update' feature, simply
ignore this forced variable altogether, no?

 -- 8 --
 diff --git a/transport-helper.c b/transport-helper.c
 index fa7c608..86e1679 100644
 --- a/transport-helper.c
 +++ b/transport-helper.c
 @@ -734,7 +734,7 @@ static int push_update_ref_status(struct strbuf *buf,
 }

 (*ref)-status = status;
 -   (*ref)-forced_update = forced;
 +   (*ref)-forced_update |= forced;
 (*ref)-remote_status = msg;
 return !(status == REF_STATUS_OK);
  }
 -- 8 --
--
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  http://vger.kernel.org/majordomo-info.html

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-21 Thread Max Horn 

On 21.02.2014, at 19:04, Junio C Hamano gits...@pobox.com wrote:

 Here is a description I wrote for a tentative commit to queue on
 'pu' after seeing your response:
 
transport-helper.c: do not overwrite forced bit

I'd change forced bit to forced_update bit

 
It does not necessarily mean the update was *not* forced, when the
helper did not say forced update.  When the helper does say so, we
know the update is forced.
 
A workaround to fix breakage introduced by the previous step,
proposed by Max Horn.
 
 It troubled me that it does not necessarily mean sounded really
 wishy-washy.

But it's correct. But if you want to be more precise, how about this:

  If the the transport helper says it was a forced update, then it is
  a forced update. But it is possible that an update is forced without
  the transport-helper knowing about it, namely because some higher up
  code had objections to the update and needed forcing in order to let
  it through to the transport helper.



  Isn't it possible for some helpers to _do_ want to
 tell us that it did not have to force after all by _not_ saying
 forced update and overwrite -forced_update with zero?

Yes to the first part, no to the last bit:  Yes, a transport helper can (and 
frequently does) tell us that no force happened -- by not saying forced 
update.

But not, it should not get to reset the forced_update bit. Because it can't 
know what other reasons there might have been for requiring a --force. If you 
look at the code, right now the only place setting forced_update is 
set_ref_status_for_push() in remote.c. If it decides to set forced_update, it 
does so, without giving the transport helper any say in in the matter. So the 
update will fail. Unless the user forces it. Only then the transport helper 
gets involved, and indeed, it could happen that the transport helper happily 
pushes the changes without seeing any reason to signal a forced update.

But the update still should be marked as forced, because it *was* forced. The 
transport helper can't know about that, and consequently, it doesn't make sense 
to allow it to override the statement of its betters ;-).


  How do we tell helpers that do want to do so apart from other helpers that 
 say
 forced update only when they noticed they are indeed forcing?

I am not completely sure I even understand that bit? So far, no remote helper 
should have ever said forced update, as they weren't allowed to. Now, we 
allow transport helpers supporting the force feature to signal that, yes, 
indeed, I had to force this update. And the only thing we use that for is to 
report this fact to the user. So, that seems fine and all cases covered. No?


BTW, I guess we could perform an extra test and raise an error if a transport 
helper dares to request the forced update message even though it wasn't told 
that this update is supposed to be forced, i.e. even though !ref-force  
!(flags  TRANSPORT_PUSH_FORCE) holds -- but doing that would mostly be 
something to help transport helper developers to catch misbehavior in their 
remote helpers, and could just as well be verified by suitable test cases.



 Perhaps the logic needs to be more like:
 
   if (we know helper will tell us the push did not have to
force by *not* saying forced update) {
   (*ref)-forced_update = forced;
   }
 
 i.e. for helpers that do not use the 'forced update' feature, simply
 ignore this forced variable altogether, no?

Huh? For helpers not using the forced updated feature, the local forced 
variable stays zero, hence forced_update |= forced already does nothing.



Max


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-20 Thread Max Horn 

On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:

 * fc/transport-helper-fixes (2013-12-09) 6 commits
 - remote-bzr: support the new 'force' option
 - test-hg.sh: tests are now expected to pass
 - transport-helper: check for 'forced update' message
 - transport-helper: add 'force' to 'export' helpers
 - transport-helper: don't update refs in dry-run
 - transport-helper: mismerge fix
 
 Updates transport-helper, fast-import and fast-export to allow the
 ref mapping and ref deletion in a way similar to the natively
 supported transports.
 
 Reported to break t5541, and has been stalled for a while without
 fixes.
 
 Will discard.

Since I somewhat care about transport-helpers, I had a closer look at this 
failure. Torsten already narrowed it down to f9e3c6bebb89de12 
(transport-helper: check for 'forced update' message).

Looking at that commit, the problem is the new line

   (*ref)-forced_update = forced;

which is supposed to set forced_update to 1 in certain cases; but the code 
which sets forced = 1 ever triggered (at least in my limited tests). Worse, 
it seems forced_update can be set to 1 before we ever get there, and in these 
casss, we end up reseting forced_update from 1 back to 0. This triggers the 
test failure.

So a simple fix for the test failure is to drop that patch. Another would be to 
change the assignment to

   (*ref)-forced_update |= forced;

But I haven't spent enough time to look at the patch to determine if one of 
these two possible changes is correct. All I can say is that dropping that 
single commit fixes the test failure for me and seems to cause now new failures.


Cheers,
Max


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-20 Thread Junio C Hamano 
Max Horn m...@quendi.de writes:

 On 19.02.2014, at 22:41, Junio C Hamano gits...@pobox.com wrote:

 * fc/transport-helper-fixes (2013-12-09) 6 commits
 - remote-bzr: support the new 'force' option
 - test-hg.sh: tests are now expected to pass
 - transport-helper: check for 'forced update' message
 - transport-helper: add 'force' to 'export' helpers
 - transport-helper: don't update refs in dry-run
 - transport-helper: mismerge fix
 
 Reported to break t5541, and has been stalled for a while without
 fixes.
 ...
 Since I somewhat care about transport-helpers, I had a closer look
 at this failure.

Thanks.  Let's keep it a bit longer and see how your new
investigation (and possibly help from others) develops to a
solution.

 Torsten already narrowed it down to f9e3c6bebb89de12
 (transport-helper: check for 'forced update' message).

 Looking at that commit, the problem is the new line

(*ref)-forced_update = forced;

 which is supposed to set forced_update to 1 in certain cases; but
 the code which sets forced = 1 ever triggered (at least in my
 limited tests). Worse, it seems forced_update can be set to 1
 before we ever get there, and in these casss, we end up reseting
 forced_update from 1 back to 0. This triggers the test failure.

 So a simple fix for the test failure is to drop that
 patch. Another would be to change the assignment to

(*ref)-forced_update |= forced;

 But I haven't spent enough time to look at the patch to determine
 if one of these two possible changes is correct. All I can say is
 that dropping that single commit fixes the test failure for me and
 seems to cause now new failures.

--
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  http://vger.kernel.org/majordomo-info.html

What's cooking in git.git (Feb 2014, #06; Wed, 19)

2014-02-19 Thread Junio C Hamano 
Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

The tip of 'next' hasn't been rewound, and none of the topics that
have been cooking there has graduated, yet.  Hopefully that can
start happening to open the new development cycle later this week,
at which time I'll be also updating tinyurl.com/gitCal and also
annotate the topics listed in this file with the course of action
(i.e. if you run Meta/cook -w, many are listed as Undecided right
now, which I need to fix).

There are many stalled topics; I think some of them do deserve to be
discarded as marked, but others do solve (or at least attempt to)
real issues and it would be nice to see people help unblock them
(one reason for blockage would be that they introduce regressions).

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[New Topics]

* bc/blame-crlf-test (2014-02-18) 1 commit
 - blame: add a failing test for a CRLF issue.


* jk/http-no-curl-easy (2014-02-18) 1 commit
 - http: never use curl_easy_perform


* jk/janitorial-fixes (2014-02-18) 5 commits
 - open_istream(): do not dereference NULL in the error case
 - builtin/mv: don't use memory after free
 - utf8: use correct type for values in interval table
 - utf8: fix iconv error detection
 - notes-utils: handle boolean notes.rewritemode correctly


* ks/config-file-stdin (2014-02-18) 4 commits
 - config: teach git config --file - to read from the standard input
 - config: change git_config_with_options() interface
 - builtin/config.c: rename check_blob_write() - check_write()
 - config: disallow relative include paths from blobs


* lb/contrib-contacts-looser-diff-parsing (2014-02-18) 1 commit
 - git-contacts: do not fail parsing of good diffs


* mh/replace-refs-variable-rename (2014-02-18) 1 commit
 - Rename read_replace_refs to check_replace_refs


* nd/commit-editor-cleanup (2014-02-18) 3 commits
 - commit: add --cleanup=scissors
 - wt-status.c: move cut-line print code out to wt_status_add_cut_line
 - wt-status.c: make cut_line[] const to shrink .data section a bit


* nd/no-more-fnmatch (2014-02-18) 4 commits
 - Actually remove compat fnmatch source code
 - Stop using fnmatch (either native or compat)
 - Revert test-wildmatch: add perf command to compare wildmatch and fnmatch
 - Use wildmatch() directly without fnmatch() wrapper


* nd/reset-setup-worktree (2014-02-18) 1 commit
 - reset: optionally setup worktree and refresh index on --mixed


* po/git-help-user-manual (2014-02-18) 1 commit
 - Provide a 'git help user-manual' route to the docbook


* rt/links-for-asciidoctor (2014-02-18) 1 commit
 - Fix documentation AsciiDoc links for external urls


* tg/index-v4-format (2014-02-18) 5 commits
 - read-cache: add index.version config variable
 - FIXUP
 - test-lib: allow setting the index format version
 - FIXUP
 - introduce GIT_INDEX_VERSION environment variable


* tr/diff-submodule-no-reuse-worktree (2014-02-18) 2 commits
 - diff: refactor reuse_worktree_file()
 - diff: do not reuse_worktree_file for submodules


* nd/multiple-work-trees (2014-02-19) 26 commits
 - FIXUP???
 - gc: support prune --repos
 - prune: strategies for linked checkouts
 - checkout: detach if the branch is already checked out elsewhere
 - checkout: clean up half-prepared directories in --to mode
 - checkout: support checking out into a new working directory
 - use new wrapper write_file() for simple file writing
 - wrapper.c: wrapper to open a file, fprintf then close
 - setup.c: support multi-checkout repo setup
 - setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
 - setup.c: convert check_repository_format_gently to use strbuf
 - setup.c: detect $GIT_COMMON_DIR in is_git_directory()
 - setup.c: convert is_git_directory() to use strbuf
 - git-stash: avoid hardcoding $GIT_DIR/logs/
 - *.sh: avoid hardcoding $GIT_DIR/hooks/...
 - git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects
 - Add new environment variable $GIT_COMMON_DIR
 - commit: use SEQ_DIR instead of hardcoding sequencer
 - fast-import: use git_path() for accessing .git dir instead of get_git_dir()
 - reflog: avoid constructing .lock path with git_path
 - *.sh: respect $GIT_INDEX_FILE
 - Make git_path() aware of file relocation in $GIT_DIR
 - path.c: group git_path(), git_pathdup() and strbuf_git_path() together
 - path.c: rename vsnpath() to do_git_path()
 - Convert git_snpath() to strbuf_git_path()
 - path.c: make get_pathname() return strbuf instead of static buffer

--
[Stalled]

* po/everyday-doc (2014-01-27) 1 commit
 - Make 'git help everyday' work

 This may make the said command to emit something, but the source is
 not meant to be formatted into a manual pages to begin with, and
 also its contents