* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Junio C Hamano @ 2013-02-01 20:15 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: Sven Strickroth, git, David Aguilar, Jeff King
In-Reply-To: <CAHGBnuNpHtfnD6D+sji6e1yp2x6iLxjAbawwO6USF2iWW17nuQ@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> writes:
> The commit message still does not mention MSYS path mangling at all,
> which probably is why the reasoning of this patch was not yet fully
> understood.
Ahh, you are very right. I didn't realize that was what this funny
"with colon, with SP" business was about.
> I'd recommend something like the following:
>
> mergetools: Teach tortoisemerge about TortoiseGitMerge
>
> TortoiseGitMerge is an improved version of TortoiseMerge specifically
> for use with Git on Windows. Due to MSYS path mangling [1], the ":"
> after the "base" etc. arguments to TortoiseMerge caused to whole
> argument instead of just the file name to be quoted in case of file
> names with spaces. So TortoiseMerge was passed
>
> "-base:new file.txt"
>
> instead of
>
> -base:"new file.txt"
>
> (including the quotes). To work around this, TortoiseGitMerge does not
> require the ":" after the arguments anymore which fixes handling file
> names with spaces.
>
> [1] http://www.mingw.org/wiki/Posix_path_conversion
Sven?
^ permalink raw reply
* Re: [PATCH 2/6] fixup! fixup! fixup! Change 'git' to 'Git' whenever the whole system is referred to #1
From: Junio C Hamano @ 2013-02-01 20:16 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Thomas Ackermann, git, davvid, Fredrik Gustafsson, Jens Lehmann
In-Reply-To: <20130201194308.GC12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
>> index c743469..14386ed 100644
>> --- a/Documentation/git-rev-parse.txt
>> +++ b/Documentation/git-rev-parse.txt
>> @@ -187,9 +187,9 @@ print a message to stderr and exit with nonzero status.
>> Flags and parameters to be parsed.
>>
>> --resolve-git-dir <path>::
>> - Check if <path> is a valid git-dir or a git-file pointing to a valid
>> - git-dir. If <path> is a valid git-dir the resolved path to git-dir will
>> - be printed.
>> + Check if <path> is a valid `$GIT_DIR` or a gitfile pointing to a valid
>> + `$GIT_DIR`. If <path> is a valid `$GIT_DIR` the resolved path to `$GIT_DIR`
>> + will be printed.
>
> Hm, I don't find the old or the new version very easy to understand. Perhaps the
> idea is something like this?
>
> Check if <path> is a valid git repository (.git or <project>.git
> directory) or "gitdir:" file. If <path> is a "gitdir:" file
> then the resolved path to the corresponding real git repository
> will be printed.
Yeah, sounds much better.
^ permalink raw reply
* Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Junio C Hamano @ 2013-02-01 20:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Thomas Ackermann, git, davvid
In-Reply-To: <20130201195140.GE12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Thomas Ackermann wrote:
>
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -23,7 +23,7 @@ and full access to internals.
>>
>> See linkgit:gittutorial[7] to get started, then see
>> link:everyday.html[Everyday Git] for a useful minimum set of
>> -commands. The link:user-manual.html[Git User's Manual] has a more
>> +commands. The link:user-manual.html[The Git User's Manual] has a more
>> in-depth introduction.
>
> In the rendered version, this looks like:
>
> The The Git User's Manual[1] has a more in-depth introduction.
>
> Presumably the first "The" should be dropped from either the link or
> the surrounding text.
>...
Thanks for a review; I'll drop this from today's integration cycle.
^ permalink raw reply
* Aw: Re: [PATCH 6/6] Use consistent links for User Manual and Everyday Git; Fix a quoting error
From: Thomas Ackermann @ 2013-02-01 20:25 UTC (permalink / raw)
To: jrnieder, th.acker; +Cc: gitster, git, davvid
In-Reply-To: <20130201195140.GE12368@google.com>
>
> Presumably the first "The" should be dropped from either the link or
> the surrounding text.
>
> Doubled 'The'.
>
You are right. I missed that; sorry.
>
> Isn't the old title more informative?
>
Yes; but every other link just uses the shorter version "Everyday Git".
---
Thomas
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sven Strickroth @ 2013-02-01 20:10 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, Junio C Hamano, David Aguilar, Jeff King
In-Reply-To: <CAHGBnuNpHtfnD6D+sji6e1yp2x6iLxjAbawwO6USF2iWW17nuQ@mail.gmail.com>
Am 01.02.2013 21:07 schrieb Sebastian Schuberth:
> mergetools: Teach tortoisemerge about TortoiseGitMerge
This subject doesn't make any sense if we don't combine the two patches.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with
From: Sven Strickroth @ 2013-02-01 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Schuberth, git, David Aguilar, Jeff King
In-Reply-To: <7va9rnaiz4.fsf@alter.siamese.dyndns.org>
Am 01.02.2013 21:15 schrieb Junio C Hamano:
>> TortoiseGitMerge is an improved version of TortoiseMerge specifically
>> for use with Git on Windows. Due to MSYS path mangling [1], the ":"
>> after the "base" etc. arguments to TortoiseMerge caused to whole
>> argument instead of just the file name to be quoted in case of file
>> names with spaces. So TortoiseMerge was passed
>>
>> "-base:new file.txt"
>>
>> instead of
>>
>> -base:"new file.txt"
>>
>> (including the quotes). To work around this, TortoiseGitMerge does not
>> require the ":" after the arguments anymore which fixes handling file
>> names with spaces.
>>
>> [1] http://www.mingw.org/wiki/Posix_path_conversion
>
> Sven?
I just mailed a new patch. Thanks to Sebastian for pointing this out!
@Junio: Feel free to optimize the commit message.
--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server
^ permalink raw reply
* Re: [PATH/RFC] Revert "compat: add strtok_r()"
From: Jonathan Nieder @ 2013-02-01 20:49 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, David Michael Barr
In-Reply-To: <1359714786-1912-1-git-send-email-kusmabite@gmail.com>
Hi Erik,
Erik Faye-Lund wrote:
> This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
>
> commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
> the only call-site for strtok_r. So let's get rid of the compat
> implementation as well.
Yes, good idea. Sorry I didn't take care of this at the time.
> Conflicts:
> Makefile
> config.mak.in
> configure.ac
Since the conflicts were straightforward, I'd drop this or replace it
with a quick description of any surprising choices made in resolving
them.
Thanks. With the fixup from your reply squashed in,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
From: Sven Strickroth @ 2013-02-01 20:16 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, Junio C Hamano, David Aguilar, Jeff King
In-Reply-To: <CAHGBnuNpHtfnD6D+sji6e1yp2x6iLxjAbawwO6USF2iWW17nuQ@mail.gmail.com>
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax.
This change was necessary because of MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused to whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces [2] (as written above).
[1] http://www.mingw.org/wiki/Posix_path_conversion
[2] https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
---
mergetools/tortoisemerge | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
index 8476afa..3b89f1c 100644
--- a/mergetools/tortoisemerge
+++ b/mergetools/tortoisemerge
@@ -6,9 +6,17 @@ merge_cmd () {
if $base_present
then
touch "$BACKUP"
- "$merge_tool_path" \
- -base:"$BASE" -mine:"$LOCAL" \
- -theirs:"$REMOTE" -merged:"$MERGED"
+ basename="$(basename "$merge_tool_path" .exe)"
+ if test "$basename" = "tortoisegitmerge"
+ then
+ "$merge_tool_path" \
+ -base "$BASE" -mine "$LOCAL" \
+ -theirs "$REMOTE" -merged "$MERGED"
+ else
+ "$merge_tool_path" \
+ -base:"$BASE" -mine:"$LOCAL" \
+ -theirs:"$REMOTE" -merged:"$MERGED"
+ fi
check_unchanged
else
echo "$merge_tool_path cannot be used without a base" 1>&2
--
1.8.1.msysgit.1
^ permalink raw reply related
* Re: [PATCH] rebase --preserve-merges keeps empty merge commits
From: Phil Hord @ 2013-02-01 21:05 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, phil.hord, Neil Horman, Junio C Hamano
In-Reply-To: <CANiSa6gM1gpj0A6PC0qNVSaWvVrOBnSnjn2uKR9-cHSLAZ2OVA@mail.gmail.com>
Martin von Zweigbergk wrote:
> I'm working on a re-roll of
> http://thread.gmane.org/gmane.comp.version-control.git/205796
>
> and finally got around to including test cases for what you fixed in
> this patch. I want to make sure I'm testing what you fixed here. See
> questions below.
Thanks for that. I should have done this myself.
> On Sat, Jan 12, 2013 at 12:46 PM, Phil Hord <hordp@cisco.com> wrote:
>> Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20)
>> 'git rebase --preserve-merges' fails to preserve empty merge commits
>> unless --keep-empty is also specified. Merge commits should be
>> preserved in order to preserve the structure of the rebased graph,
>> even if the merge commit does not introduce changes to the parent.
>>
>> Teach rebase not to drop merge commits only because they are empty.
> Consider a history like
>
> # a---b---c
> # \ \
> # d---l
> # \
> # e
> # \
> # C
>
> where 'l' is tree-same with 'd' and 'C' introduces the same change as 'c'.
>
> My test case runs 'git rebase -p e l' and expects the result to look like
>
> # a---b---c
> # \ \
> # d \
> # \ \
> # e---l
>
This is probably right, but it is not exactly the case that caused my itch.
I think my branch looked like this:
# a---b---c
# \
# d---f
# \ \
# e---g
# \
# l
where g is tree-same with f. That is, e merged with f, but all of e's
changes were dropped in the merge.
So when I ran 'git rebase -p c l', I expected to end up with this:
# a---b---c
# \
# d---f
# \ \
# e---g
# \
# l
But instead, I got an error because git-rebase--interactive.sh decided
that g was empty, so it dropped it by commenting it out of the todo
list:
pick d
pick e
pick f
#pick g
pick l
At the end of this attempt, I got some odd error about a cherry-pick
have incorrect parameters or somesuch. I bisected the problem to a
commit that clued me in to one of my commits being silently dropped.
And that is specifically what I fixed.
This happened only because 'is_empty_commit' checks for tree-sameness
with the first parent; it does not consider whether there are multiple
parents. Perhaps it should.
>> A special case which is not handled by this change is for a merge commit
>> whose parents are now the same commit because all the previous different
>> parents have been dropped as a result of this rebase or some previous
>> operation.
> And for this case, the test case runs 'git rebase -p C l'. Is that
> what you meant here?
>
> Before your patch, git would just say "Nothing to do"
Huh. That is worse than I thought.
> and after your
> patch, we get
>
> # a---b---c
> # \ \
> # d \
> # \ \
> # e \
> # \ \
> # C---l
>
> As you say, your patch doesn't try to handle this case, but at least
> the new behavior seems better. I think we would ideally want the
> recreated 'l' to have only 'C' as parent in this case. Does that make
> sense?
This is not what I meant, but it is a very interesting corner case. I
am not sure I have a solid opinion on what the result should be here.
I feel like it should look the same as you show here, since neither
'c' nor 'C' is a candidate for collapsing during this rebase. But I may
be missing some subtlety here.
Here is the corner case I was thinking of. I did not test this to see
if this will happen, but I conceived that it might. Suppose you have
this tree where
# a---b---c
# \
# d---g---l
# \ /
# C
where 'C' introduced the same changes as 'c'.
When I execute 'git rebase -p l c', I expect that I will end up with
this:
# a---b---c---d---
# \ \
# ---g---l
That is, 'C' gets skipped because it introduces the same changes already
seen in 'c'. So 'g' now has two parents: 'd' and 'C^'. But 'C^' is 'd',
so 'g' now has two parents, both of whom are 'd'.
I think it should collapse to this instead:
# a---b---c---d---g---l
I don't think this occurs because of my patch, and I am not sure it
occurs at all. It is something that I considered when I was thinking of
failure scenarios for my patch.
I expect it also may happen if 'C' is an already-empty commit, or if
it is made empty after conflict resolution involving the user. I
mentioned it because I thought my patch _could_ address this if my
is_merge_commit test would also consider whether the parents are
distinct from each other or not.
I hope this is clear, but please let me know if I made it too confusing.
Phil
^ permalink raw reply
* What's cooking in git.git (Feb 2013, #01; Fri, 1)
From: Junio C Hamano @ 2013-02-01 22:09 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of this month.
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
--------------------------------------------------
[Graduated to "master"]
* as/test-cleanup (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at cc1147d)
+ t7102 (reset): don't hardcode SHA-1 in expected outputs
* bc/git-p4-for-python-2.4 (2013-01-30) 3 commits
(merged to 'next' on 2013-01-31 at 1096db1)
+ INSTALL: git-p4 does not support Python 3
(merged to 'next' on 2013-01-30 at 5d81ed2)
+ git-p4.py: support Python 2.4
+ git-p4.py: support Python 2.5
With small updates to remove dependency on newer features of
Python, keep git-p4 usable with older Python.
* jc/do-not-let-random-file-interfere-with-completion-tests (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at df27f53)
+ t9902: protect test from stray build artifacts
Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
* jc/no-git-config-in-clone (2013-01-11) 1 commit
(merged to 'next' on 2013-01-15 at feeffe1)
+ clone: do not export and unexport GIT_CONFIG
We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* jk/cvsimport-does-not-work-with-cvsps3 (2013-01-24) 1 commit
(merged to 'next' on 2013-01-28 at fef4eb2)
+ git-cvsimport.txt: cvsps-2 is deprecated
Warn people that other tools are more recommendable over
cvsimport+cvsps2 combo when doing a one-shot import, and cvsimport
will not work with cvsps3.
* jk/gc-auto-after-fetch (2013-01-26) 1 commit
(merged to 'next' on 2013-01-30 at 472d07b)
+ Merge branch 'jk/maint-gc-auto-after-fetch' into jk/gc-auto-after-fetch
(this branch uses jk/maint-gc-auto-after-fetch.)
This is to resolve merge conflicts early for the same topic to
recent codebase.
* jk/maint-gc-auto-after-fetch (2013-01-26) 2 commits
+ fetch-pack: avoid repeatedly re-scanning pack directory
+ fetch: run gc --auto after fetching
(this branch is used by jk/gc-auto-after-fetch.)
Help "fetch only" repositories that do not trigger "gc --auto"
often enough.
* jn/do-not-drop-username-when-reading-from-etc-mailname (2013-01-25) 1 commit
(merged to 'next' on 2013-01-28 at e0a8222)
+ ident: do not drop username when reading from /etc/mailname
We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part. This is to fix it.
* nd/edit-branch-desc-while-detached (2013-01-30) 1 commit
(merged to 'next' on 2013-01-30 at 69307d6)
+ branch: no detached HEAD check when editing another branch's description
(this branch is used by nd/branch-error-cases.)
Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.
* nd/fetch-depth-is-broken (2013-01-11) 3 commits
(merged to 'next' on 2013-01-15 at 70a5ca7)
+ fetch: elaborate --depth action
+ upload-pack: fix off-by-one depth calculation in shallow clone
+ fetch: add --unshallow for turning shallow repo into complete one
"git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
--------------------------------------------------
[New Topics]
* ft/transport-report-segv (2013-01-31) 1 commit
- push: fix segfault when HEAD points nowhere
A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer while showing an error message.
Will merge to 'next'.
* sb/gpg-i18n (2013-01-31) 1 commit
- gpg: allow translation of more error messages
Will merge to 'next'.
* sb/gpg-plug-fd-leak (2013-01-31) 1 commit
- gpg: close stderr once finished with it in verify_signed_buffer()
Will merge to 'next'.
* sb/run-command-fd-error-reporting (2013-01-31) 1 commit
- run-command: be more informative about what failed
Will merge to 'next' after spelling stdout, etc. out.
* jk/remote-helpers-doc (2013-01-31) 2 commits
- [SQUASH] simplify maintenance of redirection pages
- Rename {git- => git}remote-helpers.txt
"git help remote-helpers" did not work; 'remote-helpers' is not
a subcommand name but a concept, so its documentation should have
been in gitremote-helpers, not git-remote-helpers.
Will merge to 'next' after squashing the fix in.
* sp/smart-http-content-type-check (2013-01-31) 1 commit
- Verify Content-Type from smart HTTP servers
The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
Will merge to 'next'.
* jc/mention-tracking-for-pull-default (2013-01-31) 1 commit
- doc: mention tracking for pull.default
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.
This is my "don't list it to catch readers' eyes, but make sure it
can be found if the reader looks for it" version; I'm not married
to the layout and am willing to take a replacement patch.
* jc/fake-ancestor-with-non-blobs (2013-01-31) 3 commits
- apply: diagnose incomplete submodule object name better
- apply: simplify build_fake_ancestor()
- git-am: record full index line in the patch used while rebasing
Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
Will merge to 'next'.
* jk/doc-makefile-cleanup (2013-02-01) 1 commit
- Documentation/Makefile: clean up MAN*_TXT lists
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* dg/subtree-fixes (2013-01-08) 7 commits
- contrib/subtree: mkdir the manual directory if needed
- contrib/subtree: honor $(DESTDIR)
- contrib/subtree: fix synopsis and command help
- contrib/subtree: better error handling for "add"
- contrib/subtree: add --unannotate option
- contrib/subtree: use %B for split Subject/Body
- t7900: remove test number comments
contrib/subtree updates; there are a few more from T. Zheng that
were posted separately, with an overlap.
Expecting a reroll.
* mp/diff-algo-config (2013-01-16) 3 commits
- diff: Introduce --diff-algorithm command line option
- config: Introduce diff.algorithm variable
- git-completion.bash: Autocomplete --minimal and --histogram for git-diff
Add diff.algorithm configuration so that the user does not type
"diff --histogram".
Looking better; may want tests to protect it from future breakages,
but otherwise it looks ready for 'next'.
Expecting a follow-up to add tests.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* jl/submodule-deinit (2012-12-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/212884
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
- Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Stalled mostly due to lack of responses.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
* nd/parse-pathspec (2013-01-11) 20 commits
. Convert more init_pathspec() to parse_pathspec()
. Convert add_files_to_cache to take struct pathspec
. Convert {read,fill}_directory to take struct pathspec
. Convert refresh_index to take struct pathspec
. Convert report_path_error to take struct pathspec
. checkout: convert read_tree_some to take struct pathspec
. Convert unmerge_cache to take struct pathspec
. Convert read_cache_preload() to take struct pathspec
. add: convert to use parse_pathspec
. archive: convert to use parse_pathspec
. ls-files: convert to use parse_pathspec
. rm: convert to use parse_pathspec
. checkout: convert to use parse_pathspec
. rerere: convert to use parse_pathspec
. status: convert to use parse_pathspec
. commit: convert to use parse_pathspec
. clean: convert to use parse_pathspec
. Export parse_pathspec() and convert some get_pathspec() calls
. Add parse_pathspec() that converts cmdline args to struct pathspec
. pathspec: save the non-wildcard length part
Uses the parsed pathspec structure in more places where we used to
use the raw "array of strings" pathspec.
Ejected from 'pu' for now; will take a look at the rerolled one
later ($gmane/213340).
--------------------------------------------------
[Cooking]
* ab/gitweb-use-same-scheme (2013-01-28) 1 commit
- gitweb: refer to picon/gravatar images over the same scheme
Avoid mixed contents on a page coming via http and https when
gitweb is hosted on a https server.
Will merge to 'next'.
* jk/python-styles (2013-01-30) 1 commit
- CodingGuidelines: add Python coding guidelines
Will merge to 'next'.
* mn/send-email-authinfo (2013-01-29) 1 commit
- git-send-email: add ~/.authinfo parsing
Expecting a reroll.
$gmane/215004, $gmane/215024.
* mp/complete-paths (2013-01-11) 1 commit
(merged to 'next' on 2013-01-30 at 70e4f1a)
+ git-completion.bash: add support for path completion
The completion script used to let the default completer to suggest
pathnames, which gave too many irrelevant choices (e.g. "git add"
would not want to add an unmodified path). Teach it to use a more
git-aware logic to enumerate only relevant ones.
This is logically the right thing to do, and we would really love
to see people who have been involved in completion code to review
and comment on the implementation.
Will cook in 'next' to see if anybody screams.
* jk/read-commit-buffer-data-after-free (2013-01-26) 3 commits
(merged to 'next' on 2013-01-30 at c6d7e16)
+ logmsg_reencode: lazily load missing commit buffers
+ logmsg_reencode: never return NULL
+ commit: drop useless xstrdup of commit message
Clarify the ownership rule for commit->buffer field, which some
callers incorrectly accessed without making sure it is populated.
Will merge to 'master'.
* pw/git-p4-on-cygwin (2013-01-26) 21 commits
(merged to 'next' on 2013-01-30 at 958ae3a)
+ git p4: introduce gitConfigBool
+ git p4: avoid shell when calling git config
+ git p4: avoid shell when invoking git config --get-all
+ git p4: avoid shell when invoking git rev-list
+ git p4: avoid shell when mapping users
+ git p4: disable read-only attribute before deleting
+ git p4 test: use test_chmod for cygwin
+ git p4: cygwin p4 client does not mark read-only
+ git p4 test: avoid wildcard * in windows
+ git p4 test: use LineEnd unix in windows tests too
+ git p4 test: newline handling
+ git p4: scrub crlf for utf16 files on windows
+ git p4: remove unreachable windows \r\n conversion code
+ git p4 test: translate windows paths for cygwin
+ git p4 test: start p4d inside its db dir
+ git p4 test: use client_view in t9806
+ git p4 test: avoid loop in client_view
+ git p4 test: use client_view to build the initial client
+ git p4: generate better error message for bad depot path
+ git p4: remove unused imports
+ git p4: temp branch name should use / even on windows
Improve "git p4" on Cygwin.
Will merge to 'master'.
* ss/mergetools-tortoise (2013-02-01) 2 commits
- mergetools: teach tortoisemerge to handle filenames with SP correctly
- mergetools: support TortoiseGitMerge
Update mergetools to work better with newer merge helper tortoise ships.
Will merge to 'next'.
* da/mergetool-docs (2013-01-30) 7 commits
- doc: generate a list of valid merge tools
- mergetool--lib: list user configured tools in '--tool-help'
- fixup! doc: generate a list of valid merge tools
- fixup! mergetool--lib: add functions for finding available tools
- mergetool--lib: add functions for finding available tools
- mergetool--lib: improve the help text in guess_merge_tool()
- mergetool--lib: simplify command expressions
(this branch uses jk/mergetool.)
Build on top of the clean-up done by jk/mergetool and automatically
generate the list of mergetool and difftool backends the build
supports to be included in the documentation.
Will merge to 'next', after squashing the fixup! commits from John
Keeping.
* nd/branch-error-cases (2013-01-31) 6 commits
- branch: let branch filters imply --list
- docs: clarify git-branch --list behavior
- branch: mark more strings for translation
- Merge branch 'nd/edit-branch-desc-while-detached' into HEAD
- branch: give a more helpful message on redundant arguments
- branch: reject -D/-d without branch name
Fix various error messages and conditions in "git branch", e.g. we
advertised "branch -d/-D" to remove one or more branches but actually
implemented removal of zero or more branches---request to remove no
branches was not rejected.
Will merge to 'next'.
* jc/push-reject-reasons (2013-01-24) 4 commits
(merged to 'next' on 2013-01-28 at b60be93)
+ push: finishing touches to explain REJECT_ALREADY_EXISTS better
+ push: introduce REJECT_FETCH_FIRST and REJECT_NEEDS_FORCE
+ push: further simplify the logic to assign rejection reason
+ push: further clean up fields of "struct ref"
Improve error and advice messages given locally when "git push"
refuses when it cannot compute fast-forwardness by separating these
cases from the normal "not a fast-forward; merge first and push
again" case.
Will merge to 'master'.
* jk/mergetool (2013-01-28) 8 commits
- mergetools: simplify how we handle "vim" and "defaults"
- mergetool--lib: don't call "exit" in setup_tool
- mergetool--lib: improve show_tool_help() output
- mergetools/vim: remove redundant diff command
- git-difftool: use git-mergetool--lib for "--tool-help"
- git-mergetool: don't hardcode 'mergetool' in show_tool_help
- git-mergetool: remove redundant assignment
- git-mergetool: move show_tool_help to mergetool--lib
(this branch is used by da/mergetool-docs.)
Cleans up mergetool/difftool combo.
This is looking ready for 'next'.
* mm/add-u-A-sans-pathspec (2013-01-28) 1 commit
(merged to 'next' on 2013-01-28 at fe762a6)
+ add: warn when -u or -A is used without pathspec
Forbid "git add -u" and "git add -A" without pathspec run from a
subdirectory, to train people to type "." (or ":/") to make the
choice of default does not matter.
Will merge to 'master'.
* jc/hidden-refs (2013-01-30) 8 commits
- WIP: receive.allowupdatestohidden
- fetch: fetch objects by their exact SHA-1 object names
- upload-pack: optionally allow fetching from the tips of hidden refs
- fetch: use struct ref to represent refs to be fetched
- parse_fetch_refspec(): clarify the codeflow a bit
- upload/receive-pack: allow hiding ref hierarchies
- upload-pack: simplify request validation
- upload-pack: share more code
Allow the server side to unclutter the refs/ namespace it shows to
the client. Optionally allow requests for histories leading to the
tips of hidden refs by updated clients.
* ta/doc-no-small-caps (2013-02-01) 6 commits
- Documentation: StGit is the right spelling, not StGIT
- Documentation: describe the "repository" in repository-layout
- Documentation: add a description for 'gitfile' to glossary
- Documentation: do not use undefined terms git-dir and git-file
- Documentation: the name of the system is 'Git', not 'git'
- Documentation: avoid poor-man's small caps GIT
Update documentation to change "GIT" which was a poor-man's small
caps to "Git" which was the intended spelling. Also change "git"
spelled in all-lowercase to "Git" when it refers to the system as
the whole or the concept it embodies, as opposed to the command the
end users would type.
Will merge to 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will merge to 'next'.
* jk/remote-helpers-in-python-3 (2013-01-30) 10 commits
(merged to 'next' on 2013-01-31 at 5a948aa)
+ git_remote_helpers: remove GIT-PYTHON-VERSION upon "clean"
(merged to 'next' on 2013-01-28 at d898471)
+ git-remote-testpy: fix path hashing on Python 3
(merged to 'next' on 2013-01-25 at acf9419)
+ git-remote-testpy: call print as a function
+ git-remote-testpy: don't do unbuffered text I/O
+ git-remote-testpy: hash bytes explicitly
+ svn-fe: allow svnrdump_sim.py to run with Python 3
+ git_remote_helpers: use 2to3 if building with Python 3
+ git_remote_helpers: force rebuild if python version changes
+ git_remote_helpers: fix input when running under Python 3
+ git_remote_helpers: allow building with Python 3
Prepare remote-helper test written in Python to be run with Python3.
Will merge to 'master'.
* jk/config-parsing-cleanup (2013-01-23) 8 commits
(merged to 'next' on 2013-01-28 at 9bc9411)
+ reflog: use parse_config_key in config callback
+ help: use parse_config_key for man config
+ submodule: simplify memory handling in config parsing
+ submodule: use parse_config_key when parsing config
+ userdiff: drop parse_driver function
+ convert some config callbacks to parse_config_key
+ archive-tar: use parse_config_key when parsing config
+ config: add helper function for parsing key names
Configuration parsing for tar.* configuration variables were
broken. Introduce a new config-keyname parser API to make the
callers much less error prone.
Will merge to 'master'.
* jc/custom-comment-char (2013-01-16) 1 commit
(merged to 'next' on 2013-01-25 at 91d8a5d)
+ Allow custom "comment char"
An illustration to show codepaths that need to be touched to change
the hint lines in the edited text to begin with something other
than '#'.
This is half my work and half by Ralf Thielow. There may still be
leftover '#' lurking around, though. My "git grep" says C code
should be already fine, but git-rebase--interactive.sh could be
converted (it should not matter, as the file is not really a
free-form text).
Will merge to 'master'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0 ;-).
* bc/append-signed-off-by (2013-01-27) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
- sequencer.c: rework search for start of footer to improve clarity
Waiting for the final round of reroll before merging to 'next'.
After that we will go incremental.
--------------------------------------------------
[Discarded]
* jk/update-install-for-p4 (2013-01-20) 1 commit
. INSTALL: git-p4 doesn't support Python 3
Made obsolete by bc/git-p4-for-python-2.4 topic.
^ permalink raw reply
* Re: [PATCH] Rename {git- => git}remote-helpers.txt
From: Junio C Hamano @ 2013-02-01 22:15 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, John Keeping, git, Matthieu Moy, Max Horn
In-Reply-To: <20130201190007.GB22919@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 01, 2013 at 10:52:52AM -0800, Junio C Hamano wrote:
>
>> > 4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
>> > Users of "git help foo" would not ever see this, but people who
>> > have trained their fingers to type "man gitfoo" would, along with
>> > anybody following an outdated HTML link.
>> >
>> > 5. Update internal references to "linkgit:gitfoo" to point to
>> > "git-foo".
>> >
>> > Hmm. That really does not seem so bad. The biggest downside is the
>> > people who have to see the redirect made in step 4.
>>
>> Yeah, I see that a show-stopper in the whole sequence.
>>
>> This is one of the "if we had perfect knowledge we would have
>> designed it this way, and we could still migrate our current system
>> to that ideal, but it is dubious the difference between the current
>> system and the ideal will outweigh the cost of migration" moment,
>> isn't it?
>
> Yeah, perhaps. I did the patch series just to see what the effort would
> be like. But at this point I am fine if we drop it (it sounded like
> Jonathan was in favor of this direction, so maybe he wants to make a
> final argument).
OK.
^ permalink raw reply
* Re: Re: Re: Re: Segmentation fault with latest git (070c57df)
From: Jonathan Nieder @ 2013-02-01 22:38 UTC (permalink / raw)
To: Jongman Heo; +Cc: Jeff King, Junio C Hamano, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <27376267.797831359716377823.JavaMail.weblogic@epml01>
Jongman Heo wrote:
>> But it doesn't stimulate any prerequisites in make, which is weird.
>> What's in builtin/.depend/fetch.o.d?
[...]
> please see below~.
>
> $ cat builtin/.depend/fetch.o.d
> fetch.o: builtin/fetch.c cache.h git-compat-util.h compat/bswap.h \
That's the problem. See the following thread:
http://thread.gmane.org/gmane.comp.version-control.git/185625/focus=185680
Currently when COMPUTE_HEADER_DEPENDENCIES=auto git tests for
dependency generation support by checking the output and exit status
from the following command:
$(CC) $(ALL_CFLAGS) -c -MF /dev/null -MMD -MP \
-x c /dev/null -o /dev/null 2>&1
Perhaps this can be improved? Even something as simple as a ccache
version test could presumably help a lot.
Hope that helps,
Jonathan
^ permalink raw reply
* [PATCH resend] Makefile: explicitly set target name for autogenerated dependencies
From: Jonathan Nieder @ 2013-02-01 22:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jongman Heo, Jeff King, Thomas Rast, git, Antoine Pelisse,
Nguyễn Thái Ngọc Duy
In-Reply-To: <27376267.797831359716377823.JavaMail.weblogic@epml01>
Date: Fri, 18 Nov 2011 17:23:24 -0600
"gcc -MF depfile -MMD -MP -c -o path/to/file.o" produces a makefile
snippet named "depfile" describing what files are needed to build the
target given by "-o". When ccache versions before v3.0pre0~187 (Fix
handling of the -MD and -MDD options, 2009-11-01) run, they execute
gcc -MF depfile -MMD -MP -E
instead to get the final content for hashing. Notice that the "-c -o"
combination is replaced by "-E". The result is a target name without
a leading path.
Thus when building git with such versions of ccache with
COMPUTE_HEADER_DEPENDENCIES enabled, the generated makefile snippets
define dependencies for the wrong target:
$ make builtin/add.o
GIT_VERSION = 1.7.8.rc3
* new build flags or prefix
CC builtin/add.o
$ head -1 builtin/.depend/add.o.d
add.o: builtin/add.c cache.h git-compat-util.h compat/bswap.h strbuf.h \
After a change in a header file, object files in a subdirectory are
not automatically rebuilt by "make":
$ touch cache.h
$ make builtin/add.o
$
Luckily we can prevent trouble by explicitly supplying the name of the
target to ccache and gcc, using the -MQ option. Do so.
Reported-and-tested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Reported-by: : 허종만 <jongman.heo@samsung.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 731b6a8..5a2e02d 100644
--- a/Makefile
+++ b/Makefile
@@ -973,7 +973,8 @@ endif
ifeq ($(COMPUTE_HEADER_DEPENDENCIES),auto)
dep_check = $(shell $(CC) $(ALL_CFLAGS) \
- -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
+ -c -MF /dev/null -MQ /dev/null -MMD -MP \
+ -x c /dev/null -o /dev/null 2>&1; \
echo $$?)
ifeq ($(dep_check),0)
override COMPUTE_HEADER_DEPENDENCIES = yes
@@ -1843,7 +1844,7 @@ $(dep_dirs):
missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
dep_file = $(dir $@).depend/$(notdir $@).d
-dep_args = -MF $(dep_file) -MMD -MP
+dep_args = -MF $(dep_file) -MQ $@ -MMD -MP
ifdef CHECK_HEADER_DEPENDENCIES
$(error cannot compute header dependencies outside a normal build. \
Please unset CHECK_HEADER_DEPENDENCIES and try again)
--
1.8.1
^ permalink raw reply related
* Re: [PATCH] gitk-git/.gitignore: add rule for gitk-wish
From: Jonathan Nieder @ 2013-02-01 23:52 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Paul Mackerras, Christian Couder, Junio C Hamano
In-Reply-To: <1359456750-29342-1-git-send-email-artagnon@gmail.com>
Hi Ram,
Ramkumar Ramachandra wrote:
> 8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed
> "/gitk-git/gitk-wish" from the toplevel .gitignore, with the intent of
> moving it to gitk-git/.gitignore in a later patch. This was never
> realized.
>
> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
> ---
> Minor patch, so I didn't bother sending it through Paul.
All gitk patches go through Paul's repo. I keep forgetting the
address, so I look it up each time.
$ git log -1 --oneline gitk-git/
9a6c84e Merge git://ozlabs.org/~paulus/gitk
Looks like this was fixed in the week since last pull.
http://thread.gmane.org/gmane.comp.version-control.git/214312
Paul, would it be safe for Junio to pull again?
Thanks,
Jonathan
^ permalink raw reply
* Re: Files excluded but not ignored
From: Ben Aveling @ 2013-02-01 23:54 UTC (permalink / raw)
To: Jason Wenger; +Cc: Junio C Hamano, git
In-Reply-To: <7v38ximyr2.fsf@alter.siamese.dyndns.org>
On 31/01/2013 3:17 AM, Junio C Hamano wrote:
> Jason Wenger <jcwenger@gmail.com> writes:
>
>> Trying to start up discussion of whether there would be merit to a "half-
>> ignored" state -- Files which are excluded from tracking, but which still
>> show in git status, and which are removed by git clean.
> I see no merit for "ignored and never to be tracked, but are still
> shown loudly in the untracked list" myself. Use cases for "ignored
> and never to be tracked, but not expendable" class were mentioned
> often in the past, though.
A new state seems over the top.
Jason, would adding a parameter to "git status" telling it to ignore all
.gitignores give you what you need?
Regards, Ben
^ permalink raw reply
* Re: [PATCH resend] Makefile: explicitly set target name for autogenerated dependencies
From: Jeff King @ 2013-02-02 0:03 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Jongman Heo, Thomas Rast, git, Antoine Pelisse,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20130201224519.GI12368@google.com>
On Fri, Feb 01, 2013 at 02:45:19PM -0800, Jonathan Nieder wrote:
> After a change in a header file, object files in a subdirectory are
> not automatically rebuilt by "make":
>
> $ touch cache.h
> $ make builtin/add.o
> $
>
> Luckily we can prevent trouble by explicitly supplying the name of the
> target to ccache and gcc, using the -MQ option. Do so.
Thanks, I missed the original thread last year, but this does look like
the same problem. The fixed version of ccache is a few years old, but
the OP did mention RHEL5, so that makes sense.
> missing_dep_dirs := $(filter-out $(wildcard $(dep_dirs)),$(dep_dirs))
> dep_file = $(dir $@).depend/$(notdir $@).d
> -dep_args = -MF $(dep_file) -MMD -MP
> +dep_args = -MF $(dep_file) -MQ $@ -MMD -MP
This looks like a nice simple solution. The only downside would be if
-MQ is not supported by some gcc versions (in which case we would do
better to improve the "can we use computed dependencies" check, and
punish people on old ccache, not people on old gcc who otherwise could
work without -MQ).
As far as I can tell, though, -MQ came along with the other dependency
generation options in 2001:
http://gcc.gnu.org/news/dependencies.html
which means it's not a problem to rely on. So the patch looks good to
me.
-Peff
^ permalink raw reply
* Re: [PATCH] gitk-git/.gitignore: add rule for gitk-wish
From: Junio C Hamano @ 2013-02-02 0:33 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List, Paul Mackerras, Christian Couder
In-Reply-To: <20130201235209.GK12368@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Looks like this was fixed in the week since last pull.
>
> http://thread.gmane.org/gmane.comp.version-control.git/214312
>
> Paul, would it be safe for Junio to pull again?
Thanks. I think I pulled a few days ago, and the result should have
already been propagated out.
commit 9a6c84e6e9078b0ef4fd2c50b200e8552a28c6fa
Merge: 070c57d a8b38d9
Author: Junio C Hamano <gitster@pobox.com>
Date: Wed Jan 30 13:52:44 2013 -0800
Merge git://ozlabs.org/~paulus/gitk
* git://ozlabs.org/~paulus/gitk:
gitk: Ignore gitk-wish buildproduct
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
From: David Aguilar @ 2013-02-02 1:59 UTC (permalink / raw)
To: Sven Strickroth; +Cc: Sebastian Schuberth, git, Junio C Hamano, Jeff King
In-Reply-To: <510C229E.2050705@tu-clausthal.de>
On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth
<sven.strickroth@tu-clausthal.de> wrote:
> TortoiseMerge caused to whole
> argument instead of just the file name to be quoted
s/caused to whole/caused the whole/
I think this commit message is very nice. Is it too late to replace
the current patch with this one?
--
David
^ permalink raw reply
* Re: [PATCH] mergetools: Enable tortoisemerge to handle filenames with spaces with TortoiseGitMerge
From: Junio C Hamano @ 2013-02-02 2:08 UTC (permalink / raw)
To: David Aguilar; +Cc: Sven Strickroth, Sebastian Schuberth, git, Jeff King
In-Reply-To: <CAJDDKr4L3efzp6eBdTKQxXu8sfvyT91bK6MNh5OhXzWvms8TtQ@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On Fri, Feb 1, 2013 at 12:16 PM, Sven Strickroth
> <sven.strickroth@tu-clausthal.de> wrote:
>> TortoiseMerge caused to whole
>> argument instead of just the file name to be quoted
>
> s/caused to whole/caused the whole/
>
> I think this commit message is very nice. Is it too late to replace
> the current patch with this one?
Haven't merged it to 'next'; I will replace with this, with a bit of
retitling to make it shorter.
commit 81ed7b9581f7eafb334824264abb492d85a5ffb8
Author: Sven Strickroth <sven.strickroth@tu-clausthal.de>
Date: Fri Feb 1 21:16:30 2013 +0100
mergetools: teach tortoisemerge to handle filenames with SP correctly
TortoiseGitMerge, unlike TortoiseMerge, can be told to handle paths
with spaces in them by using -option "$FILE" (not -option:"$FILE",
which does not work for such paths) syntax.
This change was necessary because of MSYS path mangling [1], the ":"
after the "base" etc. arguments to TortoiseMerge caused the whole
argument instead of just the file name to be quoted in case of file
names with spaces. So TortoiseMerge was passed
"-base:new file.txt"
instead of
-base:"new file.txt"
(including the quotes). To work around this, TortoiseGitMerge does not
require the ":" after the arguments anymore which fixes handling file
names with spaces [2] (as written above).
[1] http://www.mingw.org/wiki/Posix_path_conversion
[2] https://github.com/msysgit/msysgit/issues/57
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Reported-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] rebase --preserve-merges keeps empty merge commits
From: Martin von Zweigbergk @ 2013-02-02 8:21 UTC (permalink / raw)
To: Phil Hord; +Cc: git, phil.hord, Neil Horman, Junio C Hamano
In-Reply-To: <510C2E10.1050403@cisco.com>
On Fri, Feb 1, 2013 at 1:05 PM, Phil Hord <hordp@cisco.com> wrote:
>
> This is probably right, but it is not exactly the case that caused my itch.
> I think my branch looked like [...]
That also makes sense. I'll add tests for both cases. Your patch makes
both of them pass.
>> # a---b---c
>> # \ \
>> # d \
>> # \ \
>> # e \
>> # \ \
>> # C---l
>>
>> As you say, your patch doesn't try to handle this case, but at least
>> the new behavior seems better. I think we would ideally want the
>> recreated 'l' to have only 'C' as parent in this case. Does that make
>> sense?
>
> This is not what I meant, but it is a very interesting corner case. I
> am not sure I have a solid opinion on what the result should be here.
Neither do I, so I'll just drop the test case. Thanks.
> Here is the corner case I was thinking of. I did not test this to see
> if this will happen, but I conceived that it might. Suppose you have
> this tree where
>
> # a---b---c
> # \
> # d---g---l
> # \ /
> # C
>
> where 'C' introduced the same changes as 'c'.
>
> When I execute 'git rebase -p l c', I expect that I will end up with
> this:
>
> # a---b---c---d---
> # \ \
> # ---g---l
>
> That is, 'C' gets skipped because it introduces the same changes already
> seen in 'c'. So 'g' now has two parents: 'd' and 'C^'. But 'C^' is 'd',
> so 'g' now has two parents, both of whom are 'd'.
>
> I think it should collapse to this instead:
>
> # a---b---c---d---g---l
I think this is actually what you will get. But I think it will only
be linearized if the branch that should be dropped is the second
parent. I have two tests for this, but I need to simplify them a
little to see that that (parent number) is the only difference.
> I hope this is clear, but please let me know if I made it too confusing.
Very clear. Thanks.
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Duy Nguyen @ 2013-02-02 9:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130201101503.GG30644@sigill.intra.peff.net>
On Fri, Feb 1, 2013 at 5:15 PM, Jeff King <peff@peff.net> wrote:
> The short-sha1 is a clever idea. Looks like it saves us on the order of
> 4MB for linux-2.6 (versus the full 20-byte sha1). Not as big as the
> savings we get from dropping the other 3 sha1's to uint32_t, but still
> not bad.
We could save another 4 bytes per commit by using 3 bytes for storing
.idx offsets. linux-2.6 only has 3M objects. It'll take many years for
big projects to reach 16M objects and need the fourth byte in
uint32_t.
> I guess the next steps in iterating on this would be:
>
> 1. splitting out the refactoring here into separate patches
>
> 2. squashing the cleaned-up bits into my patch 4/6
>
> 3. deciding whether this should go into a separate file or as part of
> index v3. Your offsets depend on the .idx file having a sorted sha1
> list. That is not likely to change, but it would still be nice to
> make sure they cannot get out of sync. I'm still curious what the
> performance impact is for mmap-ing N versus N+8MB.
4. Print some cache statistics in "count-objects -v"
>> The length of SHA-1 is chosen to be able to unambiguously identify any
>> cached commits. Full SHA-1 check is done after to catch false
>> positives.
>
> Just to be clear, these false positives come because the abbreviation is
> unambiguous within the packfile, but we might be looking for a commit
> that is not even in our pack, right?
It may even be ambiguous within the pack, say an octopus (i.e. not
cached) commit that shares the same sha-1 prefix with one of the
cached commits.
--
Duy
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Shawn Pearce @ 2013-02-02 10:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Duy Nguyen
In-Reply-To: <20130201091130.GB30644@sigill.intra.peff.net>
On Fri, Feb 1, 2013 at 1:11 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 31, 2013 at 09:14:26AM -0800, Shawn O. Pearce wrote:
>
>> On Tue, Jan 29, 2013 at 1:14 AM, Jeff King <peff@peff.net> wrote:
>> > Coupled with using compression level 0 for trees (which do not compress
>> > well at all, and yield only a 2% increase in size when left
>> > uncompressed), my "git rev-list --objects --all" time drops from ~40s to
>> > ~25s.
>>
>> This uhm.... is nice?
>>
>> But consider reachability bitmaps. ~40s to ~80ms. :-)
>
> Yeah, yeah. I'm working my way up to it. :)
:-)
> At this point I'm convinced that my 25s is about the best we will do for
> reachability analysis with a graph traversal. The repeated hashcmps to
> see that we've visited each node are starting to dominate. So the next
> obvious step is to try reachability bitmaps.
Yea, its hard to make a big N go fast when you still have a big N...
> I was hoping to iron out
> the "pack metadata goes here" issues with the commit cache stuff,
> though, as the actual cache implementation is quite simple (whereas the
> bitmap stuff is more on the complex side, but can build on the same
> metadata base).
Junio and I were talking about putting these in an index v3, below the
current tables where he thought there was a hole in v2. I am inclined
to agree with his comment elsewhere that we don't want 50 auxiliary
files next to a pack in 5 years.
But if we go that route I also suggested we append the index below the
pack file itself, so its a single file, and that we rename the file to
be SHA1(all-bits) not SHA1(sorted-object-list). Both steps make it
much safer to perform git gc on Windows while the repository is being
accessed.
>> Yup. I have also futzed with the one in JGit for quite a while now. I
>> pull some tricks there like making it a 2 level directory to reduce
>> the need to find a contiguous array of 8M entries when processing the
>> Linux kernel, and I try to preallocate the first level table based on
>> the number of objects in pack-*.idx files. But the bottleneck is
>> basically the cache lookups and hits, these happen like 100M times on
>> 2M objects, because its every link in nearly every tree.
>
> Right. I tried some multi-level tricks (and even a radix trie), but I
> couldn't get anything to beat the simple-and-stupid single hash table
> with linear probing.
O(1) lookup is hard for big N. Lets go shopping^Wcoding instead.
>> If we modified pack-objects' delta compressor for tree objects to only
>> generate delta instructions at tree record boundaries, a delta-encoded
>> tree can be processed without inflating the full content of that tree.
>> Because of the way deltas are created, "most" tree deltas should have
>> their delta base scanned by the object traversal before the delta is
>> considered. This means the tree delta just needs to consider the much
>> smaller records that are inserted into the base. We know these are
>> different SHA-1s than what was there before, so they are more likely
>> to be new to the lookup_object table.
>
> So sort of a magic shortcut tree diff you get while accessing the
> object. Neat idea.
Yes, exactly.
>> So the --objects traversal algorithm can change to get the delta base
>> SHA-1 and raw tree delta from the pack storage. Perform a
>> lookup_object on the base to see if it has been scanned. If it has,
>> just scan the delta insert instructions. If the base has not yet been
>> scanned, inflate the tree to its normal format and scan the entire
>> tree.
>
> This would not perform well if we hit the deltas before the bases. In
> general, though, our "use the larger as the base" heuristic should mean
> that our traversal hits the bases first.
It won't perform worse than the current code. And its actually the
time heuristic that should kick in here for trees. Most trees are
roughly the same size, or are only slightly bigger because a new
source file was added. More recent trees should appear earlier in the
delta window and be suitable candidates for older trees. So we should
get a large percentage of trees covered by this trick.
>> This is an approximation of what Nico and I were talking about doing
>> for pack v4. But doesn't require a file format change. :-)
>
> Yeah. It just needs to be very careful that the deltas it is looking at
> all fall on record boundaries, since we might get deltas generated by
> other versions of git. Can we necessarily identify that case for sure,
> though? I imagine a tree delta like that would look something like:
>
> delete bytes 100-120
> add 20 bytes at offset 100: \x12\x34\x56...
Of course we can't know without some flag. I assumed it was obvious we
would need to tag the pack somehow with extra metadata to say "every
tree delta in this pack is on a record boundary". That does make delta
reuse more complex as a tree delta can only be reused if it is coming
from a pack that has the same promise about record boundaries.
Otherwise the delta must be regenerated during packing.
> Without looking at the base object, and without knowing whether the
> delta was generated by our particular implementation, how can we be sure
> this is a sha1 replacement and not the renaming of part of a file? Or
> are you proposing some flag in the packfile to indicate "yes, this tree
> really was delta'd only at record boundaries"?
Yes, some sort of flag would be required on the pack. :-\
> It could be a big win, but it does seem quite complex and error-prone.
It is complex. But it seems so simple on the Internet...
> And it only helps with reachability, not regular traversals, so it's not
> very generic.
It should also help with path filter traversals. If we require the
deltas to be only at tree record boundaries then the mode and path
will be part of the delta, even if it is unmodified from the base
tree. A path filter can avoid scanning the base sections if its
already seen that base tree before. This could be a substantial
reduction in the number of tree records a path filter needs to examine
to get a `git log -- path` or `git blame path` completed.
> Which makes me think the bitmap route is a much better way
> to go.
Bitmaps discard a lot of useful data in favor of being really freaking
small. Colby was toying around with some other allocations of bitmaps
today. I think he managed to bitmap basically every commit in the
Linux kernel history since September... and its only 3M of data to
store on disk / cache in RAM. Very useful for serving fetch requests
to clients that are at varying points in history, but not so good for
doing things like new delta compression or path limited history
traversal.
<thought type="random" why="look at the Date header">
What if we built a bitmap for each path? Linux kernel history is
~41.5k paths. If the packer constructs a bitmap for each path that
sets a commit's bit if the path is impacted in that commit, you can do
some incredibly fast path traversal operations. Naive implementation
would cost around 1.7G of disk, but I wonder how well that set of maps
might compress.
</thought>
^ permalink raw reply
* Re: [PATCH 0/2] optimizing pack access on "read only" fetch repos
From: Shawn Pearce @ 2013-02-02 10:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130201091431.GC30644@sigill.intra.peff.net>
On Fri, Feb 1, 2013 at 1:14 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Jan 31, 2013 at 08:47:37AM -0800, Shawn O. Pearce wrote:
>
>> >> - System resource cost we incur by having to keep 50 file
>> >> descriptors open and maintaining 50 mmap windows will reduce by
>> >> 50 fold.
>> >
>> > I wonder how measurable that is (and if it matters on Linux versus less
>> > efficient platforms).
>>
>> It does matter. We know it has a negative impact on JGit even on Linux
>> for example. You don't want 300 packs in a repository. 50 might be
>> tolerable. 300 is not.
>
> I'd love to see numbers if you have them. It's not that I don't believe
> it is slower, but knowing _how much_ is important when thinking about
> what kind of performance increase we are looking to get (which in turn
> impacts how much effort to put into the repacking).
Never done a formal experiment. Just working from memory where 4 years
and 3 desks ago I got called because one of our Git servers was
struggling to keep up with user git fetch commands. Turns out the
repository had O(200) pack files. git gc that normally took only about
5 minutes took a hellva lot longer, like an hour or more.
The problem happened because the server was saving every push to a
pack and never exploding incoming packs to loose objects. This meant
the thin packs from the wire got delta bases appended to them.
pack-objects was looking at O(50) different alternatives for most
objects when trying to decide which one it should copy into the output
pack... for either a fetch/clone client, or the gc I was trying to run
to fix the repository.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-02-02 11:57 UTC (permalink / raw)
To: git
In-Reply-To: <20130131193844.GA14460@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]
On Thu, 31 Jan 2013 14:38:45 -0500 Jeff King <peff@peff.net> wrote:
JK> On Thu, Jan 31, 2013 at 10:23:51AM -0500, Ted Zlatanov wrote:
>> Jeff, is there a way for git-credential to currently support
>> authinfo/netrc parsing? I assume that's the right way, instead of using
>> Michal's proposal to parse internally?
>>
>> I'd like to add that, plus support for the 'string' and "string"
>> formats, and authinfo.gpg decoding through GPG. I'd write it in Perl,
>> if there's a choice.
JK> Yes, you could write a credential helper that understands netrc and
JK> friends; git talks to the helpers over a socket, so there is no problem
JK> with writing it in Perl. See Documentation/technical/api-credentials.txt
JK> for an overview, or the sample implementation in credential-store.c for a
JK> simple example.
I wrote a Perl credential helper for netrc parsing which is pretty
robust, has built-in docs with -h, and doesn't depend on external
modules. The netrc parser regex was stolen from Net::Netrc.
It will by default use ~/.authinfo.gpg, ~/.netrc.gpg, ~/.authinfo, and
~/.netrc (whichever is found first) and this can be overridden with -f.
If the file name ends with ".gpg", it will run "gpg --decrypt FILE" and
use the output. So non-interactively, that could hang if GPG was
waiting for input. Does Git handle that, or should I check for a TTY?
Take a look at the proposed patch and let me know if it's usable, if you
need a formal copyright assignment, etc.
Thanks
Ted
[-- Attachment #2: Add git-credential-netrc --]
[-- Type: text/x-patch, Size: 6016 bytes --]
commit 3d28bc2a610ebcc988eba5443d82d0ded92c24bc
Author: Ted Zlatanov <tzz@lifelogs.com>
Date: Sat Feb 2 06:42:13 2013 -0500
Add contrib/credentials/netrc with GPG support
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
new file mode 100755
index 0000000..92fc306
--- /dev/null
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -0,0 +1,242 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Data::Dumper;
+
+use Getopt::Long;
+use File::Basename;
+
+my $VERSION = "0.1";
+
+my %options = (
+ help => 0,
+ debug => 0,
+
+ # identical token maps, e.g. host -> host, will be inserted later
+ tmap => {
+ port => 'protocol',
+ machine => 'host',
+ path => 'path',
+ login => 'username',
+ user => 'username',
+ password => 'password',
+ }
+ );
+
+foreach my $v (values %{$options{tmap}})
+{
+ $options{tmap}->{$v} = $v;
+}
+
+foreach my $suffix ('.gpg', '')
+{
+ foreach my $base (qw/authinfo netrc/)
+ {
+ my $file = glob("~/.$base$suffix");
+ next unless (defined $file && -f $file);
+ $options{file} = $file ;
+ }
+}
+
+Getopt::Long::Configure("bundling");
+
+# TODO: maybe allow the token map $options{tmap} to be configurable.
+GetOptions(\%options,
+ "help|h",
+ "debug|d",
+ "file|f=s",
+ );
+
+if ($options{help})
+{
+ my $shortname = basename($0);
+ $shortname =~ s/git-credential-//;
+
+ print <<EOHIPPUS;
+
+$0 [-f AUTHFILE] [-d] get
+
+Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
+
+Options:
+ -f AUTHFILE: specify a netrc-style file
+ -d: turn on debugging
+
+To enable (note that Git will prepend "git-credential-" to the helper
+name and look for it in the path):
+
+ git config credential.helper '$shortname -f AUTHFILE'
+
+And if you want lots of debugging info:
+
+ git config credential.helper '$shortname -f AUTHFILE -d'
+
+Only "get" mode is supported by this credential helper. It opens
+AUTHFILE and looks for entries that match the requested search
+criteria:
+
+ 'port|protocol':
+ The protocol that will be used (e.g., https). (protocol=X)
+
+ 'machine|host':
+ The remote hostname for a network credential. (host=X)
+
+ 'path':
+ The path with which the credential will be used. (path=X)
+
+ 'login|user|username':
+ The credential’s username, if we already have one. (username=X)
+
+Thus, when we get "protocol=https\nusername=tzz", this credential
+helper will look for lines in AUTHFILE that match
+
+port https login tzz
+
+OR
+
+protocol https login tzz
+
+OR... etc. acceptable tokens as listed above. Any unknown tokens are
+simply ignored.
+
+Then, the helper will print out whatever tokens it got from the line,
+including "password" tokens, mapping e.g. "port" back to "protocol".
+
+The first matching line is used. Tokens can be quoted as 'STRING' or
+"STRING".
+
+No caching is performed by this credential helper.
+
+EOHIPPUS
+
+ exit;
+}
+
+my $mode = shift @ARGV;
+
+# credentials may get 'get', 'store', or 'erase' as parameters but
+# only acknowledge 'get'
+die "Syntax: $0 [-f AUTHFILE] [-d] get" unless defined $mode;
+
+# only support 'get' mode
+exit unless $mode eq 'get';
+
+my $debug = $options{debug};
+my $file = $options{file};
+
+die "Sorry, you need to specify an existing netrc file (with or without a .gpg extension) with -f AUTHFILE"
+ unless defined $file;
+
+die "Sorry, the specified netrc $file is not accessible"
+ unless -f $file;
+
+if ($file =~ m/\.gpg$/)
+{
+ $file = "gpg --decrypt $file|";
+}
+
+my @data = load($file);
+chomp @data;
+
+die "Sorry, we could not load data from [$file]"
+ unless (scalar @data);
+
+# the query
+my %q;
+
+foreach my $v (values %{$options{tmap}})
+{
+ undef $q{$v};
+}
+
+while (<STDIN>)
+{
+ next unless m/([a-z]+)=(.+)/;
+
+ my ($token, $value) = ($1, $2);
+ die "Unknown search token $1" unless exists $q{$token};
+ $q{$token} = $value;
+}
+
+# build reverse token map
+my %rmap;
+foreach my $k (keys %{$options{tmap}})
+{
+ push @{$rmap{$options{tmap}->{$k}}}, $k;
+}
+
+# there are CPAN modules to do this better, but we want to avoid
+# dependencies and generally, complex netrc-style files are rare
+
+if ($debug)
+{
+ foreach (sort keys %q)
+ {
+ printf STDERR "searching for %s = %s\n",
+ $_, $q{$_} || '(any value)';
+ }
+}
+
+LINE: foreach my $line (@data)
+{
+
+ print STDERR "line [$line]\n" if $debug;
+ my @tok;
+ # gratefully stolen from Net::Netrc
+ while (length $line &&
+ $line =~ s/^("((?:[^"]+|\\.)*)"|((?:[^\\\s]+|\\.)*))\s*//)
+ {
+ (my $tok = $+) =~ s/\\(.)/$1/g;
+ push(@tok, $tok);
+ }
+
+ my %tokens;
+ while (@tok)
+ {
+ my ($k, $v) = (shift @tok, shift @tok);
+ next unless defined $v;
+ next unless exists $options{tmap}->{$k};
+ $tokens{$options{tmap}->{$k}} = $v;
+ }
+
+ foreach my $check (sort keys %q)
+ {
+ if (exists $tokens{$check} && defined $q{$check})
+ {
+ print STDERR "comparing [$tokens{$check}] to [$q{$check}] in line [$line]\n" if $debug;
+ next LINE unless $tokens{$check} eq $q{$check};
+ }
+ else
+ {
+ print STDERR "we could not find [$check] but it's OK\n" if $debug;
+ }
+ }
+
+ print STDERR "line has passed all the search checks\n" if $debug;
+ foreach my $token (sort keys %rmap)
+ {
+ print STDERR "looking for useful token $token\n" if $debug;
+ next unless exists $tokens{$token}; # did we match?
+
+ foreach my $rctoken (@{$rmap{$token}})
+ {
+ next if defined $q{$rctoken}; # don't re-print given tokens
+ }
+
+ print STDERR "FOUND: $token=$tokens{$token}\n" if $debug;
+ printf "%s=%s\n", $token, $tokens{$token};
+ }
+
+ last;
+}
+
+sub load
+{
+ my $file = shift;
+ # this supports pipes too
+ my $io = new IO::File($file) or die "Could not open $file: $!\n";
+
+ return <$io>; # whole file
+}
^ permalink raw reply related
* Re: [PATCH 4/6] introduce a commit metapack
From: Junio C Hamano @ 2013-02-02 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, git, Duy Nguyen
In-Reply-To: <20130201094237.GE30644@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Jan 31, 2013 at 09:03:26AM -0800, Shawn O. Pearce wrote:
> ...
>> If we are going to change the index to support extension sections and
>> I have to modify JGit to grok this new format, it needs to be index v3
>> not index v2. If we are making index v3 we should just put index v3 on
>> the end of the pack file.
>
> I'm not sure what you mean by your last sentence here.
I am not Shawn, but here is a summary of what I think I discussed
with him in person, lest I forget.
You could imagine that a new pack system (from pack-objects,
index-pack down to read_packed_sha1() call) that works with a
packfile that
* is a single file, whose name is pack-$SHA1.$sfx (where $sfx
is something other than 'pack', perhaps);
* has the pack data stream, including the concluding checksum of
the stream contents at the end, at the beginning of the file; and
* has the index v3 data blob appended to the pack data stream.
The pack data is streamed over the wire exactly the same way,
interoperating with existing software. When receiving, the new
index-pack can read such a pack stream and add index at the end.
When re-indexing an existing pack (think: upgrading existing
packfiles from the current system), the index-pack can read from the
packfile and do what it does currently (notably, it knows where the
pack stream ends and can stop reading at that point, so even if you
feed the new pack to it, it will stop at the end of the pack data,
ignoring the index v3 already at the end of the input).
One potential advantage of using a single file, instead of the
primary .pack file with 3 (or 47) auxiliary files, is that it lets
you repack without having to deal with this sequence, which happens
currently when you repack:
* create a new .pack file and the corresponding auxiliary files
under temporary filename;
* move existing pack files that describe the same set of objects
away;
* rename these new files, one at a time, to their final name,
making sure that you rename .idx the last, because that happens
to be the key to the pack aware programs.
Instead you can rename only one thing (the new one) to the final
name (possibly atomically replacing the existing one). With the
current system, when you need to replace a pack with a new pack with
the same packname (e.g. you repack everything with a better pack
parameter in a repository that has everything packed into one),
there is a very small window other concurrent users will not find
the object data between the time when you rename the old ones away
and the time when you move the new ones in. The hairly logic
between "Ok we have prepared all new packfiles" and "End of pack
replacement" can be done with a single rename(2) of the new packfile
(which contains everything) to the final name, which atomically
replaces the old one.
This will become even safer if we picked $SHA1 (the name of the
packfile) to represent the hash of the whole thing, not the hash of
the sorted object names in the pack, as that will let us know there
is no need to even "replace" the files.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox