* Re: [PATCH] Replace git-cvsimport with a rewrite that fixes major bugs.
From: Michael Haggerty @ 2013-01-03 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, Chris Rorvick, Eric Raymond, git
In-Reply-To: <7vip7expd8.fsf@alter.siamese.dyndns.org>
On 01/03/2013 04:22 PM, Junio C Hamano wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>>> Doesn't Python come with a standard subprocess module that lets you
>>> spawn external programs safely, similar to the way Perl's list form
>>> open(), e.g. "open($fh, "-|", 'git', @args)", works?
>
> ... and of course a more boring "system('git', $subcmd, @args)", as well.
Python's os.system() takes exactly one argument, which must be a string,
and executes it in a subshell. subprocess is indeed the way to go.
>> You mean something like this:
>>
>> p1 = subprocess.Popen([backend.command()], stdout=subprocess.PIPE)
>> subprocess.Popen(["git", "fast-import", "--quiet"] + gitopts,
>> cwd=outdir, stdin=p1.stdout)
>>
>> Assuming gitopts is a list rather than a string. (care must be taken
>> with backend.command() also)
>
> Yes.
>
> I vaguely recall that the subprocess module once used to be one
> portability issue but that was between Python 2.3 and 2.4 or some
> ancient history, and it should no longer be relevant.
subprocess was added in Python 2.4, and the above example should work
fine in any version >= 2.4. But please note that other functions have
been added to the module since then, like check_call() (v2.5),
check_output (v2.7), and some methods were added to the Popen object in
v2.6.
Such things are documented pretty reliably in the Python library
documentation [1]; when in doubt, one can view older versions of the
library documentation, which are all available online [2].
Michael
[1] http://docs.python.org/2/library/
[2] http://www.python.org/doc/versions/
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Pretty pictures of git merge conflicts
From: Michael Haggerty @ 2013-01-03 16:37 UTC (permalink / raw)
To: git discussion list
Hi,
I've been thinking lately about how to attack difficult git merge
conflicts. The first step is to visualize them. I have written some
articles [1,2,3] describing a way to atomize a complicated merge and
efficiently compute diagrams that show which pairwise commits cause the
merge to go awry. I hope you find them interesting; feedback would be
very welcome.
I am working on some more articles (including software) that I plan to
grow into tools to help users perform git merges that would otherwise
seem hopeless.
Michael
[1]
http://softwareswirl.blogspot.de/2012/12/the-conflict-frontier-of-nightmare-merge.html
[2]
http://softwareswirl.blogspot.de/2012/12/mapping-merge-conflict-frontier.html
[3]
http://softwareswirl.blogspot.de/2012/12/real-world-conflict-diagrams.html
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] merge: Honor prepare-commit-msg return code
From: Antoine Pelisse @ 2013-01-03 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jay Soffian
In-Reply-To: <7vwqvv1dta.fsf@alter.siamese.dyndns.org>
> Oh, that wasn't meant as a complaint. I am tempted to rewrite the
> log message like so, though:
>
> 65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to
> make "git commit" and "git merge" consistent, because a merge that
> required user assistance has to be concluded with "git commit", but
> only "git commit" triggered prepare-commit-msg hook. When it added
> a call to run the prepare-commit-msg hook, however, it forgot to
> check the exit code from the hook like "git commit" does, and ended
> up replacing one inconsistency with another.
That's fine with me
>>> diff --git a/t/t7505-prepare-commit-msg-hook.sh b/t/t7505-prepare-commit-msg-hook.sh
>>> index bc497bc..3573751 100755
>>> --- a/t/t7505-prepare-commit-msg-hook.sh
>>> +++ b/t/t7505-prepare-commit-msg-hook.sh
>>> @@ -172,11 +172,12 @@ test_expect_success 'with failing hook (merge)' '
>>> git checkout -B other HEAD@{1} &&
>>> echo "more" >> file &&
>>> git add file &&
>>> - chmod -x $HOOK &&
>>> + rm -f "$HOOK" &&
>>> git commit -m other &&
>>> - chmod +x $HOOK &&
>>> + write_script "$HOOK" <<-EOF
>>> + exit 1
>>> + EOF
>>> git checkout - &&
>>> - head=`git rev-parse HEAD` &&
>>> test_must_fail git merge other
>>>
>>> '
>>
>> What about moving the hook file then ? Not very important to me, just
>> a suggestion as it would keep the shebang.
>
> Strictly speaking, the way $HOOK is prepared in the original is
> wrong. The script is always run under "#!/bin/sh" instead of the
> shell the user told us to use with $SHELL_PATH. For a simple one
> liner that only exits with 1, it does not matter, though.
>
> Many test scripts got this wrong and that was the reason we later
> added write_script helper function to the test suite.
So let's keep your suggestion and squash the commit.
Thanks,
^ permalink raw reply
* Re: [RFH] NetBSD 6?
From: Greg Troxel @ 2013-01-03 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvcbew895.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
Junio C Hamano <gitster@pobox.com> writes:
> I forgot to mention that we also ship configure (and keep track of
> configure.ac) so that optionally people can let autoconf machinery
> to create config.mak.autogen to be included at the same place as
> handcrafted config.mak in their build process. I do not offhand
> know if we do "for p in python python2.6 python2.7; do ..." kind of
> thing, though.
pkgsrc uses the configure method, but it seems not to output a
PYTHON_PATH. It looks like automake's python.m4 is not used by git's
configure.ac. But pkgsrc passes PYTHON_PATH in the environment to make,
so it works out currently.
> It refers to the type of the second parameter to iconv(); OLD_ICONV
> makes it take "const char *", as opposed to "char *", the latter of
> which matches
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
Thanks - I now see our extra const and am looking into it.
[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply
* [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Junio C Hamano @ 2013-01-03 19:05 UTC (permalink / raw)
To: git; +Cc: Jeff King
This allows things like:
$ DEFAULT_DOC_TARGET=html make doc
$ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
on a platform that does not have manpage viewer. Which is not very
useful, given that you can already say
$ make install-html
on such a platform, and these install-$format targets will not go
away.
The real motivation behind this was to let me say:
$ git checkout $some_old_fork_point
$ DEFAULT_DOC_TARGET=git-push.1 make doc
while updating the sources to the documentation for the maintainance
track, without having to format everything else that is different
between the old fork point and the primary branch I usually work on.
The first one was discussed some time ago on the list and all the
fixes mentioned on the thread already squashed in. The second one
is merely for completeness.
For previous round, see:
http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201
Junio C Hamano (2):
Allow generating a non-default set of documentation
Allow installing a non-default set of documentation
Documentation/Makefile | 10 ++++++++--
Makefile | 13 ++++++++++++-
2 files changed, 20 insertions(+), 3 deletions(-)
--
1.8.1.293.g4a210a9
^ permalink raw reply
* [PATCH v2 1/2] Allow generating a non-default set of documentation
From: Junio C Hamano @ 2013-01-03 19:05 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <1357239920-2201-1-git-send-email-gitster@pobox.com>
By default, "make doc" generates the manpages and htmldocs in the
Documentation directory, but you may want to change this depending
on the target environment, e.g. to include 'pdf'. Introduce a new
Makefile variable DEFAULT_DOC_TARGET to allow customizing this.
The primary motivation is to let us check documentation patches with
$ DEFAULT_DOC_TARGET=git-push.1 make doc
but it is not so far-fetched to imagine that Windows users may want to
omit manpages with
$ DEFAULT_DOC_TARGET=html make doc
or somesuch. It won't be useful without additional support to tweak
the format installed by default via DEFAULT_DOC_INSTALL_TARGET, though.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/Makefile | 7 ++++++-
Makefile | 10 +++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 063fa69..0f8fdf8 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,3 +1,6 @@
+# The default target of this Makefile is...
+all::
+
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
$(wildcard git-*.txt)) \
@@ -65,6 +68,8 @@ endif
-include ../config.mak.autogen
-include ../config.mak
+DEFAULT_DOC_TARGET ?= html man
+
#
# For docbook-xsl ...
# -1.68.1, no extra settings are needed?
@@ -151,7 +156,7 @@ ifndef V
endif
endif
-all: html man
+all:: $(DEFAULT_DOC_TARGET)
html: $(DOC_HTML)
diff --git a/Makefile b/Makefile
index 6b0c961..71655a7 100644
--- a/Makefile
+++ b/Makefile
@@ -281,6 +281,12 @@ all::
# DEFAULT_EDITOR='$GIT_FALLBACK_EDITOR',
# DEFAULT_EDITOR='"C:\Program Files\Vim\gvim.exe" --nofork'
#
+# You can define DEFAULT_DOC_TARGET to change it from the built-in
+# default of generating manpages and htmldocs. e.g.
+#
+# DEFAULT_DOC_TARGET='man html info pdf'
+# DEFAULT_DOC_TARGET='html'
+#
# Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on
# header files to be automatically computed, to avoid rebuilding objects when
# an unrelated header file changes. Define it to "no" to use the hard-coded
@@ -1421,6 +1427,8 @@ ifneq (,$(SOCKLEN_T))
BASIC_CFLAGS += -Dsocklen_t=$(SOCKLEN_T)
endif
+DEFAULT_DOC_TARGET ?= html man
+
ifeq ($(uname_S),Darwin)
ifndef NO_FINK
ifeq ($(shell test -d /sw/lib && echo y),y)
@@ -2371,7 +2379,7 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
$(VCSSVN_LIB): $(VCSSVN_OBJS)
$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS)
-export DEFAULT_EDITOR DEFAULT_PAGER
+export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET
doc:
$(MAKE) -C Documentation all
--
1.8.1.293.g4a210a9
^ permalink raw reply related
* [PATCH v2 2/2] Allow installing a non-default set of documentation
From: Junio C Hamano @ 2013-01-03 19:05 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <1357239920-2201-1-git-send-email-gitster@pobox.com>
In a fashion similar to the previous DEFAULT_DOC_TARGET patch, teach
the build procedure to allow installing the documentation sets
specified via DEFAULT_DOC_INSTALL_TARGET.
These two symbols must be separate, as we should allow formatting
more than what will be installed. The default has been to format
both html and manpages, and to install only the latter.
$ make DEFAULT_DOC_INSTALL_TARGET='html man' install-doc
will format and install both html and manpages.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/Makefile | 3 ++-
Makefile | 5 ++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 0f8fdf8..bd7800d 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -69,6 +69,7 @@ endif
-include ../config.mak
DEFAULT_DOC_TARGET ?= html man
+DEFAULT_DOC_INSTALL_TARGET ?= $(DEFAULT_DOC_TARGET)
#
# For docbook-xsl ...
@@ -171,7 +172,7 @@ info: git.info gitman.info
pdf: user-manual.pdf
-install: install-man
+install: $(patsubst %,install-%,$(DEFAULT_DOC_INSTALL_TARGET))
install-man: man
$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
diff --git a/Makefile b/Makefile
index 71655a7..422a15f 100644
--- a/Makefile
+++ b/Makefile
@@ -287,6 +287,8 @@ all::
# DEFAULT_DOC_TARGET='man html info pdf'
# DEFAULT_DOC_TARGET='html'
#
+# DEFAULT_DOC_INSTALL_TARGET can be used in a similar way.
+#
# Define COMPUTE_HEADER_DEPENDENCIES to "yes" if you want dependencies on
# header files to be automatically computed, to avoid rebuilding objects when
# an unrelated header file changes. Define it to "no" to use the hard-coded
@@ -1428,6 +1430,7 @@ ifneq (,$(SOCKLEN_T))
endif
DEFAULT_DOC_TARGET ?= html man
+DEFAULT_DOC_INSTALL_TARGET ?= man
ifeq ($(uname_S),Darwin)
ifndef NO_FINK
@@ -2379,7 +2382,7 @@ $(XDIFF_LIB): $(XDIFF_OBJS)
$(VCSSVN_LIB): $(VCSSVN_OBJS)
$(QUIET_AR)$(RM) $@ && $(AR) rcs $@ $(VCSSVN_OBJS)
-export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET
+export DEFAULT_EDITOR DEFAULT_PAGER DEFAULT_DOC_TARGET DEFAULT_DOC_INSTALL_TARGET
doc:
$(MAKE) -C Documentation all
--
1.8.1.293.g4a210a9
^ permalink raw reply related
* What's cooking in git.git (Jan 2013, #02; Thu, 3)
From: Junio C Hamano @ 2013-01-03 19:17 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'.
The post 1.8.1 cycle has started, and about a dozen topics (mostly
fixes) have graduated to the 'master' branch. The second batch will
follow shortly.
As usual, this cycle is expected to last for 8 to 10 weeks. To
ensure the quality of the end result, let's merge topics in flight
earlier than previous cycles to 'next' and fix issues in-tree.
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]
* jn/less-reconfigure (2013-01-02) 1 commit
(merged to 'next' on 2013-01-02 at e5cd6cf)
+ build: do not automatically reconfigure unless configure.ac changed
When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
* ap/merge-stop-at-prepare-commit-msg-failure (2013-01-03) 1 commit
- merge: Honor prepare-commit-msg return code
"git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook. t7505 may want a general clean-up but that is
a different topic.
Will merge to 'next'.
* tb/test-shell-lint (2013-01-02) 1 commit
- test: Add check-non-portable-shell.pl
Check for common mistakes in the test scripts, based on simple
pattern-matching.
Will merge to 'next'.
* jk/enable-test-lint-by-default (2013-01-03) 1 commit
- tests: turn on test-lint by default
We had two simple and quick tests to catch common mistakes when
writing test scripts, but they weren't run by default when running
tests.
Will merge to 'next'.
--------------------------------------------------
[Graduated to "master"]
* as/test-tweaks (2012-12-20) 7 commits
(merged to 'next' on 2012-12-22 at 7312c6c)
+ tests: paint unexpectedly fixed known breakages in bold red
+ tests: test the test framework more thoroughly
+ tests: refactor mechanics of testing in a sub test-lib
+ tests: change info messages from yellow/brown to cyan
+ tests: paint skipped tests in blue
+ tests: paint known breakages in yellow
+ tests: test number comes first in 'not ok $count - $message'
Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* da/p4merge-mktemp (2012-12-26) 1 commit
(merged to 'next' on 2012-12-26 at 036938a)
+ mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
Create an empty file in $TMPDIR instead of using an empty file in
the local directory.
* dm/port (2012-12-19) 4 commits
(merged to 'next' on 2012-12-22 at 8adc198)
+ git-compat-util.h: do not #include <sys/param.h> by default
+ Generalize the inclusion of strings.h
+ Detect when the passwd struct is missing pw_gecos
+ Support builds when sys/param.h is missing
(this branch is used by mk/qnx.)
Add a few more knobs for new platform ports can tweak.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
(merged to 'next' on 2012-12-11 at 6659fdc)
+ sh-setup: work around "unset IFS" bug in some shells
Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.
* jc/maint-fnmatch-old-style-definition (2012-12-19) 1 commit
(merged to 'next' on 2012-12-22 at 540df2c)
+ compat/fnmatch: update old-style definition to ANSI
Update old-style function definition "int foo(bar) int bar; {}"
to "int foo(int bar) {}".
* jc/maint-test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at daeed53)
+ t4014: fix arguments to grep
+ t9502: do not assume GNU tar
+ t0200: "locale" may not exist
(this branch is used by jc/test-portability.)
Minor test fixes noticed while running our tests on OpenBSD 5.2,
applicable to 'maint'.
* jc/mkstemp-more-careful-error-reporting (2012-12-18) 1 commit
(merged to 'next' on 2012-12-22 at 18cdaf0)
+ xmkstemp(): avoid showing truncated template more carefully
After failing to create a temporary file using mkstemp(), failing
pathname was not reported correctly on some platforms.
* jc/same-encoding (2012-12-10) 1 commit
(merged to 'next' on 2012-12-17 at 86b41c7)
+ format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
* jc/test-cvs-no-init-in-existing-dir (2012-12-24) 1 commit
(merged to 'next' on 2012-12-26 at 3b93f37)
+ t9200: let "cvs init" create the test repository
t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you
need to be in the cvsadmin group on NetBSD 6.0).
* jc/test-portability (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 123041b)
+ t9020: use configured Python to run the test helper
+ t3600: Avoid "cp -a", which is a GNUism
+ Merge branch 'jc/maint-test-portability' into 'jc/test-portability'
(this branch uses jc/maint-test-portability.)
The remainder of jc/maint-test-portability, applicable to 'master'.
* jk/repack-ref-racefix (2012-12-21) 1 commit
(merged to 'next' on 2012-12-22 at 03e1ca9)
+ refs: do not use cached refs in repack_without_ref
"git pack-refs" that ran in parallel to another process that
created new refs had a nasty race.
* md/gitweb-sort-by-age (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at 9f39410)
+ gitweb: Sort projects with undefined ages last
Gitweb showed repositories without any commit at the top in its
age-sorted view, in which the users are interested in looking at
active projects; sorting them at the bottom makes it more useful.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
(merged to 'next' on 2012-12-26 at 2ff59ab)
+ graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
* mk/qnx (2012-12-19) 2 commits
(merged to 'next' on 2012-12-22 at 0473197)
+ Port to QNX
+ Make lock local to fetch_pack
(this branch uses dm/port.)
Port to QNX.
* ms/subtree-fixlets (2012-12-22) 2 commits
(merged to 'next' on 2012-12-26 at 1cb26eb)
+ git-subtree: fix typo in manpage
+ git-subtree: ignore git-subtree executable
* nd/invalidate-i-t-a-cache-tree (2012-12-15) 4 commits
(merged to 'next' on 2012-12-18 at 33e4488)
+ cache-tree: invalidate i-t-a paths after generating trees
+ cache-tree: fix writing cache-tree when CE_REMOVE is present
+ cache-tree: replace "for" loops in update_one with "while" loops
+ cache-tree: remove dead i-t-a code in verify_cache()
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
* pf/editor-ignore-sigint (2012-12-02) 5 commits
(merged to 'next' on 2012-12-07 at 6b04419)
+ launch_editor: propagate signals from editor to git
+ run-command: do not warn about child death from terminal
+ launch_editor: ignore terminal signals while editor has control
+ launch_editor: refactor to use start/finish_command
+ run-command: drop silent_exec_failure arg from wait_or_whine
The behaviour visible to the end users was confusing, when they
attempt to kill a process spawned in the editor that was in turn
launched by Git with SIGINT (or SIGQUIT), as Git would catch that
signal and die. We ignore these signals now.
* rb/http-cert-cred-no-username-prompt (2012-12-21) 1 commit
(merged to 'next' on 2012-12-22 at 9fc28ed)
+ http.c: Avoid username prompt for certifcate credentials
It is wrong to ask for username if the authentication is done by
certificate identity.
* sp/shortlog-missing-lf (2012-12-11) 2 commits
(merged to 'next' on 2012-12-11 at 64b8429)
+ strbuf_add_wrapped*(): Remove unused return value
+ shortlog: fix wrapping lines of wraplen
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
* ss/nedmalloc-compilation (2012-12-11) 1 commit
(merged to 'next' on 2012-12-13 at c1f0d7f)
+ nedmalloc: Fix a compile warning (exposed as error) with GCC 4.7.2
* ss/svn-prompt (2012-12-17) 3 commits
(merged to 'next' on 2012-12-26 at 1012ae2)
+ git-svn, perl/Git.pm: extend and use Git->prompt method for querying users
+ perl/Git.pm: Honor SSH_ASKPASS as fallback if GIT_ASKPASS is not set
+ git-svn, perl/Git.pm: add central method for prompting passwords
Tweak the way "git svn" asks for password to be in line with the
rest of the system, so that the same SSH/GIT_ASKPASS can be used.
--------------------------------------------------
[Stalled]
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ 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.
But this does not yet do so (does not remove the checkout of the
submodule). The design discussion petered out.
http://thread.gmane.org/gmane.comp.version-control.git/210867/focus=211456
Will kick back to 'pu'.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* 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
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed ($gmane/206172).
Will kick back to 'pu'.
* 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/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
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.
Waiting for comments.
* 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.
--------------------------------------------------
[Cooking]
* jc/doc-default-format (2013-01-03) 2 commits
- Allow installing a non-default set of documentation
- Allow generating a non-default set of documentation
Instead of the default of generating html/man and installing man,
you can control what "make doc" and "make install-doc" do via two
make variables.
Will merge to 'next'.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
In the longer term, tightening rules is a good thing to do, and
because nobody who has worked in the remote helper area seems to be
interested in reviewing this, I would assume they do not think
such a retroactive tightening will affect their remote helpers. So
let's advance this topic to see what happens.
* fc/remote-bzr (2013-01-02) 9 commits
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree upon pushing
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr, with minimum fix squashed in.
Will merge to 'next'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
As nobody seems to be stepping up to review this, I am tempted to
merge this to 'next and see who screams.
* jc/submittingpatches (2013-01-02) 4 commits
- SubmittingPatches: give list and maintainer addresses
- SubmittingPatches: remove overlong checklist
- SubmittingPatches: mention subsystems with dedicated repositories
- SubmittingPatches: who am I and who cares?
Will merge to 'next'.
* kb/maint-bundle-doc (2013-01-01) 2 commits
- Documentation: full-ness of a bundle is significant for cloning
- Documentation: correct example restore from bundle
Will merge to 'next'.
* nd/maint-branch-desc-doc (2013-01-03) 5 commits
- format-patch: pick up branch description when no ref is specified
- format-patch: pick up correct branch name from symbolic ref
- t4014: a few more tests on cover letter using branch description
- branch: delete branch description if it's empty
- config.txt: a few lines about branch.<name>.description
Will merge to 'next'.
* tb/test-t9020-no-which (2013-01-01) 1 commit
- t9020: which is not portable
Will merge to 'next'.
* tb/test-t9810-no-sed-i (2013-01-01) 1 commit
- t9810: Do not use sed -i
Will merge to 'next'.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
(merged to 'next' on 2013-01-02 at b9db3a2)
+ rebase: Handle cases where format-patch fails
Save output from format-patch command in a temporary file, just in
case it aborts, to give a better failure-case behaviour.
* ap/status-ignored-in-ignored-directory (2013-01-01) 2 commits
- git-status: Test --ignored behavior
- dir.c: Make git-status --ignored more consistent
Will merge to 'next'.
* ta/remove-stale-translated-tut (2012-12-27) 1 commit
(merged to 'next' on 2013-01-02 at e70df8e)
+ Remove Documentation/pt_BR/gittutorial.txt
Remove a translation of a document that was left stale.
* er/stop-recommending-parsecvs (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at fd816dd)
+ Remove the suggestion to use parsecvs, which is currently broken.
Stop recommending a defunct third-party software.
* as/test-name-alias-uniquely (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at e297810)
+ Use longer alias names in subdirectory tests
A few short-and-bland aliases used in the tests were interfering
with git-custom command in user's $PATH.
* jc/maint-fmt-merge-msg-no-edit-lose-credit (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at 8795e87)
+ merge --no-edit: do not credit people involved in the side branch
Stop spending cycles to compute information to be placed on
commented lines in "merge --no-edit".
* as/check-ignore (2012-12-28) 19 commits
- Add git-check-ignore sub-command
- setup.c: document get_pathspec()
- pathspec.c: extract new validate_path() for reuse
- pathspec.c: move reusable code from builtin/add.c
- add.c: remove unused argument from validate_pathspec()
- add.c: refactor treat_gitlinks()
- dir.c: provide clear_directory() for reclaiming dir_struct memory
- dir.c: keep track of where patterns came from
- dir.c: use a single struct exclude_list per source of excludes
- dir.c: rename free_excludes() to clear_exclude_list()
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
- Improve documentation and comments regarding directory traversal API
- api-directory-listing.txt: update to match code
Rerolled. The early parts looked mostly fine; we may want to split
this into two topics and have the early half graduate sooner.
* jc/format-patch-reroll (2013-01-02) 9 commits
- format-patch: give --reroll-count a short synonym -v
- format-patch: document and test --reroll-count
- format-patch: add --reroll-count=$N option
- get_patch_filename(): split into two functions
- get_patch_filename(): drop "just-numbers" hack
- get_patch_filename(): simplify function signature
- builtin/log.c: stop using global patch_suffix
- builtin/log.c: drop redundant "numbered_files" parameter from make_cover_letter()
- builtin/log.c: drop unused "numbered" parameter from make_cover_letter()
Teach "format-patch" to prefix v4- to its output files for the
fourth iteration of a patch series, to make it easier for the
submitter to keep separate copies for iterations.
Will merge to 'next'.
* mz/pick-unborn (2012-12-23) 2 commits
(merged to 'next' on 2013-01-02 at 22b9951)
+ learn to pick/revert into unborn branch
+ tests: move test_cmp_rev to test-lib-functions
Allows "git cherry-pick $commit" when you do not have any history
behind HEAD yet.
* nd/retire-fnmatch (2013-01-01) 7 commits
- Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
- wildmatch: advance faster in <asterisk> + <literal> patterns
- wildmatch: make a special case for "*/" with FNM_PATHNAME
- test-wildmatch: add "perf" command to compare wildmatch and fnmatch
- wildmatch: support "no FNM_PATHNAME" mode
- wildmatch: make dowild() take arbitrary flags
- wildmatch: rename constants and update prototype
(this branch uses nd/wildmatch.)
Replace our use of fnmatch(3) with a more feature-rich wildmatch.
A handful patches at the bottom have been moved to nd/wildmatch to
graduate as part of that branch, before this series solidifies.
Will merge to 'next'.
* os/gitweb-highlight-uncaptured (2013-01-01) 1 commit
- gitweb: fix error in sanitize when highlight is enabled
Will merge to 'next'.
* jc/merge-blobs (2012-12-26) 5 commits
- merge-tree: fix d/f conflicts
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
A beginning of a new merge strategy based on the disused merge-tree
proof-of-concept code.
* jk/pathspec-literal (2012-12-19) 1 commit
(merged to 'next' on 2012-12-22 at c794bd6)
+ add global --literal-pathspecs option
Allow scripts to feed literal paths to commands that take
pathspecs, by disabling wildcard globbing.
Will merge to 'master'.
* er/python-version-requirements (2012-12-28) 1 commit
(merged to 'next' on 2013-01-02 at 1023a3f)
+ Add checks to Python scripts for version dependencies.
Some python scripts we ship cannot be run with old versions of the
interpreter.
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* mz/oneway-merge-wo-u-no-lstat (2012-12-20) 1 commit
(merged to 'next' on 2012-12-22 at 87bd30e)
+ oneway_merge(): only lstat() when told to update worktree
Optimize "read-tree -m <tree-ish>" without "-u".
* wk/submodule-update-remote (2012-12-19) 3 commits
(merged to 'next' on 2012-12-22 at 7ddf897)
+ submodule add: If --branch is given, record it in .gitmodules
+ submodule update: add --remote for submodule's upstream changes
+ submodule: add get_submodule_config helper funtion
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
Will merge to 'master'.
* cc/no-gitk-build-dependency (2012-12-18) 3 commits
(merged to 'next' on 2012-12-22 at da7b2cf)
+ Makefile: replace "echo 1>..." with "echo >..."
+ Makefile: detect when PYTHON_PATH changes
+ Makefile: remove tracking of TCLTK_PATH
Remove leftover bits from an earlier change to move gitk in its own
subdirectory. Reimplementing the dependency tracking rules needs
to be done in gitk history separately.
Will merge to 'master'.
* jc/format-color-auto (2012-12-17) 2 commits
(merged to 'next' on 2012-12-18 at 5aaac94)
+ log --format: teach %C(auto,black) to respect color config
+ t6006: clean up whitespace
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
Will merge to 'master'.
* zk/clean-report-failure (2013-01-02) 2 commits
- (SQUASH???) fix-up only the trivial bits
- git-clean: Display more accurate delete messages
"git clean" states what it is going to remove and then goes on to
remove it, but sometimes it only discovers things that cannot be
removed after recursing into a directory, which makes the output
confusing and even wrong.
Rerolled, and comments sent.
* mp/complete-paths (2012-12-21) 1 commit
- 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.
Waiting for area-experts' review.
* ja/directory-attrs (2012-12-17) 1 commit
(merged to 'next' on 2012-12-17 at ced8e73)
+ Add directory pattern matching to attributes
The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.
Will merge to 'master'.
* jk/mailmap-from-blob (2012-12-13) 5 commits
(merged to 'next' on 2012-12-17 at 14b7cdc)
+ mailmap: default mailmap.blob in bare repositories
+ mailmap: fix some documentation loose-ends for mailmap.blob
+ mailmap: clean up read_mailmap error handling
+ mailmap: support reading mailmap from blobs
+ mailmap: refactor mailmap parsing for non-file sources
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
Will merge to 'master'.
* jk/complete-commit-c (2012-12-15) 1 commit
(merged to 'next' on 2012-12-18 at 75b5f21)
+ completion: complete refs for "git commit -c"
Complete "git commmit -c foo<TAB>" into a refname that begins with
"foo".
Will merge to 'master'.
* jk/error-const-return (2012-12-15) 2 commits
(merged to 'next' on 2012-12-22 at bf2b1cd)
+ silence some -Wuninitialized false positives
+ make error()'s constant return value more visible
Help compilers' flow analysis by making it more explicit that
error() always returns -1, to reduce false "variable used
uninitialized" warnings. Looks somewhat ugly but not too much.
Will merge to 'master'.
* ap/log-mailmap (2012-12-27) 10 commits
- log --use-mailmap: optimize for cases without --author/--committer search
- log: add log.mailmap configuration option
- log: grep author/committer using mailmap
- test: Add test for --use-mailmap option
- log: Add --use-mailmap option
- pretty: Use mailmap to display username and email
- mailmap: Add mailmap structure to rev_info and pp
- mailmap: Simplify map_user() interface
- mailmap: Remove buffer length limit in map_user
- Use split_ident_line to parse author and committer
(this branch is used by jc/mailmap.)
Clean up various codepaths around mailmap and teach the "log"
machinery to use it.
Expecting a reroll.
$gmane/212426
* jc/fetch-ignore-symref (2012-12-11) 1 commit
(merged to 'next' on 2012-12-17 at 370e2c8)
+ fetch: ignore wildcarded refspecs that update local symbolic refs
Avoid false error from an attempt to update local symbolic ref via
fetch.
Will merge to 'master'.
* bc/append-signed-off-by (2013-01-01) 12 commits
- t4014: do not use echo -n
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- 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
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a reroll.
$gmane/212507
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
Will merge to 'master'.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will merge to 'master'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
Deal with a situation where .config/git is a file and we notice
.config/git/config is not readable due to ENOTDIR, not ENOENT.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Will merge to 'master'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Will merge to 'master'.
* nd/wildmatch (2013-01-01) 18 commits
(merged to 'next' on 2013-01-01 at 8c633a5)
+ wildmatch: replace variable 'special' with better named ones
+ compat/fnmatch: respect NO_FNMATCH* even on glibc
+ wildmatch: fix "**" special case
(merged to 'next' on 2012-12-15 at c734714)
+ t3070: Disable some failing fnmatch tests
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
(this branch is used by nd/retire-fnmatch.)
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
Will merge to 'master'.
^ permalink raw reply
* Re: [RFH] NetBSD 6?
From: Stefano Lattarini @ 2013-01-03 19:28 UTC (permalink / raw)
To: Greg Troxel; +Cc: Junio C Hamano, git
In-Reply-To: <rmiobh6rujt.fsf@fnord.ir.bbn.com>
On 01/03/2013 07:27 PM, Greg Troxel wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I forgot to mention that we also ship configure (and keep track of
>> configure.ac) so that optionally people can let autoconf machinery
>> to create config.mak.autogen to be included at the same place as
>> handcrafted config.mak in their build process. I do not offhand
>> know if we do "for p in python python2.6 python2.7; do ..." kind of
>> thing, though.
>
> pkgsrc uses the configure method, but it seems not to output a
> PYTHON_PATH. It looks like automake's python.m4 is not used by git's
> configure.ac.
>
That is not surprising, since Git build system doesn't use Automake :-)
In addition, it's worth nothing that Automake's python support (both
in its m4 and make components) is intended as an help to install python
*modules* from Autotools-based packages; using it for mere stand-alone
scripts would be overkill.
In the case of Git, an adapted version of something like this might
be enough:
AC_CHECK_PROGS([PYTHON], [python python2.7 python2.6 python2.5])
if test -z "$PYTHON"; then
AC_MSG_WARNING([python not found])
fi
$PYTHON -c 'check-not-py3k' || AC_MSG_WARNING([Python 3 is not supported])
$PYTHON -c 'check-its-version' || AC_MSG_WARNING([python is too old])
(Automake itself uses, in its own build system, a similar idiom to
look for a Perl interpreter at configure runtime).
Not my itch so far, but I will happily review a patch if anyone is
willing to write it.
> But pkgsrc passes PYTHON_PATH in the environment to make,
> so it works out currently.
>
>> It refers to the type of the second parameter to iconv(); OLD_ICONV
>> makes it take "const char *", as opposed to "char *", the latter of
>> which matches
>>
>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/iconv.html
>
> Thanks - I now see our extra const and am looking into it.
Regards,
Stefano
^ permalink raw reply
* Re: [BUG] two-way read-tree can write null sha1s into index
From: Jeff King @ 2013-01-03 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vehi2xote.fsf@alter.siamese.dyndns.org>
On Thu, Jan 03, 2013 at 07:34:53AM -0800, Junio C Hamano wrote:
> > Good point; I was just thinking about the --reset case.
> >
> > With "-m", though, we could in theory carry over the unmerged entries
> > (again, assuming that "old" and "new" are the same; otherwise it is an
> > obvious reject). But those entries would be confused with any new
> > unmerged entries we create. It seems we already protect against this,
> > though: "read-tree -m" will not run at all if you have unmerged entries.
> >
> > Likewise, "checkout" seems to have similar protections.
> >
> > So I think it may be a non-issue.
>
> Yeah. Also earlier in the thread you mentioned three-way case, but
> I do not think we ever would want --reset with three trees, so I
> think that too is a non-issue for the same reason.
Yeah, agreed; we should always reject in the three-way case. I would
worry more that it has a bug where something is _not_ rejected, and we
end up putting a bogus null sha1 entry into the index (which is the
actual problem with twoway_merge). IOW, if we have the bogus sha1 in the
index (because we marked it with CE_CONFLICTED), and the two sides and
the common ancestor are all the same, would we blindly carry through the
bogus conflicted entry (which we would prefer, because it has the
up-to-date stat information)?
Or are you suggesting that the three-way case should always be protected
by checking that there are no unmerged entries before we start it? That
seems sane to me, but I haven't confirmed that that is the case.
> I would still feel safer if we expressed the expectation of
> the callee in the code, perhaps like this in the two-way case:
>
> if (current->ce_flags & CE_CONFLICTED) {
> if (!o->reset) {
> ... either die or fail ...
> } else {
> ... your fix ...
> }
> }
Agreed. I looked at that, but it seemed like it was going to involve
repeating a lot of the "are the two trees the same" logic. Let me see if
I can refactor it to avoid that.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Jeff King @ 2013-01-03 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1357239920-2201-1-git-send-email-gitster@pobox.com>
On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote:
> This allows things like:
>
> $ DEFAULT_DOC_TARGET=html make doc
> $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
>
> on a platform that does not have manpage viewer. Which is not very
> useful, given that you can already say
>
> $ make install-html
>
> on such a platform, and these install-$format targets will not go
> away.
I think the usefulness is that it can be set by default for a particular
uname, so people on Windows can just type "make install-doc" without
having to care about setting anything (though to be honest, I do not
even know what they build by default; maybe they do build manpages).
Except that in the original thread:
> http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201
it became clear that to do that we would also want to hoist the uname
automagic defaults into their own file that could be read from
Documentation/Makefile.
> The real motivation behind this was to let me say:
>
> $ git checkout $some_old_fork_point
> $ DEFAULT_DOC_TARGET=git-push.1 make doc
>
> while updating the sources to the documentation for the maintainance
> track, without having to format everything else that is different
> between the old fork point and the primary branch I usually work on.
I still don't see how this is any advantage over:
make -C Documentation git-push.1
> The first one was discussed some time ago on the list and all the
> fixes mentioned on the thread already squashed in. The second one
> is merely for completeness.
I wonder...do we really need DEFAULT_DOC_INSTALL_TARGET? Why isn't it
the same as DEFAULT_DOC_TARGET? I realize that right now we build html
and manpages by default, but only install man. But then why do we bother
building html then?
-Peff
^ permalink raw reply
* Re: [BUG] two-way read-tree can write null sha1s into index
From: Junio C Hamano @ 2013-01-03 20:34 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git
In-Reply-To: <20130103202343.GA4632@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Or are you suggesting that the three-way case should always be protected
> by checking that there are no unmerged entries before we start it? That
> seems sane to me, but I haven't confirmed that that is the case.
I think the normal (and hopefully only) "-m -u O A B" use case of
threeway is the bog-standard "git merge", which requires even more:
your index must exactly match HEAD, even though you are allowed to
have local changes in the working tree.
That requirement is not likely to change, as cleanly merged paths
are automatically added to the index, so "diff --cached" should show
only the changes from cleanly merged part, while "diff" should show
paths that still needs user's help.
If we allowed local modification to the index (let alone conflicted
entries in it) before the merge begins, the users would not be able
to tell which paths are in what state after a half-merge stops and
asks for help. Updated paths may not have anything to do with the
merge (i.e. earlier "git add" before the merge started), conflicting
paths may not have anything to do with the merge (i.e. leftover
conflicts before the merge started).
^ permalink raw reply
* Re: [BUG] two-way read-tree can write null sha1s into index
From: Jeff King @ 2013-01-03 20:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7vip7evwdo.fsf@alter.siamese.dyndns.org>
On Thu, Jan 03, 2013 at 12:34:27PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Or are you suggesting that the three-way case should always be protected
> > by checking that there are no unmerged entries before we start it? That
> > seems sane to me, but I haven't confirmed that that is the case.
>
> I think the normal (and hopefully only) "-m -u O A B" use case of
> threeway is the bog-standard "git merge", which requires even more:
> your index must exactly match HEAD, even though you are allowed to
> have local changes in the working tree.
>
> That requirement is not likely to change, as cleanly merged paths
> are automatically added to the index, so "diff --cached" should show
> only the changes from cleanly merged part, while "diff" should show
> paths that still needs user's help.
>
> If we allowed local modification to the index (let alone conflicted
> entries in it) before the merge begins, the users would not be able
> to tell which paths are in what state after a half-merge stops and
> asks for help. Updated paths may not have anything to do with the
> merge (i.e. earlier "git add" before the merge started), conflicting
> paths may not have anything to do with the merge (i.e. leftover
> conflicts before the merge started).
Oh, I agree it's insane to try to carry through unmerged entries. I'm
just concerned that not all code paths are careful enough to check. They
probably are, though, as a null sha1 in your index would be the least of
your worries, and somebody would have noticed in the last 7 years.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Jeff King @ 2013-01-03 20:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20130103203222.GB4632@sigill.intra.peff.net>
On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote:
> On Thu, Jan 03, 2013 at 11:05:18AM -0800, Junio C Hamano wrote:
>
> > This allows things like:
> >
> > $ DEFAULT_DOC_TARGET=html make doc
> > $ DEFAULT_DOC_INSTALL_TARGET=html make install-doc
> >
> > on a platform that does not have manpage viewer. Which is not very
> > useful, given that you can already say
> >
> > $ make install-html
> >
> > on such a platform, and these install-$format targets will not go
> > away.
>
> I think the usefulness is that it can be set by default for a particular
> uname, so people on Windows can just type "make install-doc" without
> having to care about setting anything (though to be honest, I do not
> even know what they build by default; maybe they do build manpages).
I also notice that we have DEFAULT_HELP_FORMAT (which is "html" on
Windows). Wouldn't that be a sane default for DEFAULT_DOC_TARGET if it
is set? I guess we can set all three independently for maximum
flexibility, though, but it seems like a sane fallback.
-Peff
^ permalink raw reply
* [PATCH v2] Documentation: update "howto maintain git"
From: Junio C Hamano @ 2013-01-03 20:40 UTC (permalink / raw)
To: git
The flow described in the document is still correct, but over time I
have automated various parts of the workflow with tools and their
use was not explained at all.
Update it and outline the use of two key scripts from the 'todo'
branch, "Reintegrate" and "cook".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I sent an incomplete preview some time ago; this is an update.
The old one is at:
http://thread.gmane.org/gmane.comp.version-control.git/210632
Antoine Cc'ed because this is a more detailed answer to his
question in:
http://thread.gmane.org/gmane.comp.version-control.git/212127/focus=212333
Documentation/howto/maintain-git.txt | 314 +++++++++++++++++++++++++----------
1 file changed, 225 insertions(+), 89 deletions(-)
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
index 8823a37..a4ec3cb 100644
--- a/Documentation/howto/maintain-git.txt
+++ b/Documentation/howto/maintain-git.txt
@@ -8,20 +8,20 @@ Abstract: Imagine that git development is racing along as usual, when our friend
The maintainer's git time is spent on three activities.
- - Communication (60%)
+ - Communication (45%)
Mailing list discussions on general design, fielding user
questions, diagnosing bug reports; reviewing, commenting on,
suggesting alternatives to, and rejecting patches.
- - Integration (30%)
+ - Integration (50%)
Applying new patches from the contributors while spotting and
correcting minor mistakes, shuffling the integration and
testing branches, pushing the results out, cutting the
releases, and making announcements.
- - Own development (10%)
+ - Own development (5%)
Scratching my own itch and sending proposed patch series out.
@@ -35,6 +35,9 @@ The policy.
contain bugfixes and enhancements in any area, including
functionality, performance and usability, without regression.
+ - One release cycle for a feature release is expected to last for
+ eight to ten weeks.
+
- Maintenance releases are numbered as vX.Y.Z.W and are meant
to contain only bugfixes for the corresponding vX.Y.Z feature
release and earlier maintenance releases vX.Y.Z.V (V < W).
@@ -58,12 +61,15 @@ The policy.
- 'pu' branch is used to publish other proposed changes that do
not yet pass the criteria set for 'next'.
- - The tips of 'master', 'maint' and 'next' branches will always
- fast-forward, to allow people to build their own
- customization on top of them.
+ - The tips of 'master' and 'maint' branches will not be rewound to
+ allow people to build their own customization on top of them.
+ Early in a new development cycle, 'next' is rewound to the tip of
+ 'master' once, but otherwise it will not be rewound until the end
+ of the cycle.
- - Usually 'master' contains all of 'maint', 'next' contains all
- of 'master' and 'pu' contains all of 'next'.
+ - Usually 'master' contains all of 'maint' and 'next' contains all
+ of 'master'. 'pu' contains all the topics merged to 'next', but
+ is rebuilt directly on 'master'.
- The tip of 'master' is meant to be more stable than any
tagged releases, and the users are encouraged to follow it.
@@ -76,11 +82,16 @@ The policy.
A typical git day for the maintainer implements the above policy
by doing the following:
- - Scan mailing list and #git channel log. Respond with review
- comments, suggestions etc. Kibitz. Collect potentially
- usable patches from the mailing list. Patches about a single
- topic go to one mailbox (I read my mail in Gnus, and type
- \C-o to save/append messages in files in mbox format).
+ - Scan mailing list. Respond with review comments, suggestions
+ etc. Kibitz. Collect potentially usable patches from the
+ mailing list. Patches about a single topic go to one mailbox (I
+ read my mail in Gnus, and type \C-o to save/append messages in
+ files in mbox format).
+
+ - Write his own patches to address issues raised on the list but
+ nobody has stepped up solving. Send it out just like other
+ contributors do, and pick them up just like patches from other
+ contributors (see above).
- Review the patches in the saved mailboxes. Edit proposed log
message for typofixes and clarifications, and add Acks
@@ -96,40 +107,32 @@ by doing the following:
- Obviously correct fixes that pertain to the tip of 'master'
are directly applied to 'master'.
+ - Other topics are not handled in this step.
+
This step is done with "git am".
$ git checkout master ;# or "git checkout maint"
- $ git am -3 -s mailbox
+ $ git am -sc3 mailbox
$ make test
- - Merge downwards (maint->master):
-
- $ git checkout master
- $ git merge maint
- $ make test
+ In practice, almost no patch directly goes to 'master' or
+ 'maint'.
- Review the last issue of "What's cooking" message, review the
- topics scheduled for merging upwards (topic->master and
- topic->maint), and merge.
+ topics ready for merging (topic->master and topic->maint). Use
+ "Meta/cook -w" script (where Meta/ contains a checkout of the
+ 'todo' branch) to aid this step.
+
+ And perform the merge. Use "Meta/Reintegrate -e" script (see
+ later) to aid this step.
+
+ $ Meta/cook -w last-issue-of-whats-cooking.mbox
$ git checkout master ;# or "git checkout maint"
- $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ echo ai/topic | Meta/Reintegrate -e ;# "git merge ai/topic"
$ git log -p ORIG_HEAD.. ;# final review
$ git diff ORIG_HEAD.. ;# final review
$ make test ;# final review
- $ git branch -d ai/topic ;# or "git branch -d ai/maint-topic"
-
- - Merge downwards (maint->master) if needed:
-
- $ git checkout master
- $ git merge maint
- $ make test
-
- - Merge downwards (master->next) if needed:
-
- $ git checkout next
- $ git merge master
- $ make test
- Handle the remaining patches:
@@ -138,9 +141,9 @@ by doing the following:
and not in 'master') is applied to a new topic branch that
is forked from the tip of 'master'. This includes both
enhancements and unobvious fixes to 'master'. A topic
- branch is named as ai/topic where "ai" is typically
- author's initial and "topic" is a descriptive name of the
- topic (in other words, "what's the series is about").
+ branch is named as ai/topic where "ai" is two-letter string
+ named after author's initial and "topic" is a descriptive name
+ of the topic (in other words, "what's the series is about").
- An unobvious fix meant for 'maint' is applied to a new
topic branch that is forked from the tip of 'maint'. The
@@ -158,7 +161,8 @@ by doing the following:
The above except the "replacement" are all done with:
- $ git am -3 -s mailbox
+ $ git checkout ai/topic ;# or "git checkout -b ai/topic master"
+ $ git am -sc3 mailbox
while patch replacement is often done by:
@@ -166,93 +170,166 @@ by doing the following:
then replace some parts with the new patch, and reapplying:
+ $ git checkout ai/topic
$ git reset --hard ai/topic~$n
- $ git am -3 -s 000*.txt
+ $ git am -sc3 -s 000*.txt
The full test suite is always run for 'maint' and 'master'
after patch application; for topic branches the tests are run
as time permits.
- - Update "What's cooking" message to review the updates to
- existing topics, newly added topics and graduated topics.
-
- This step is helped with Meta/cook script (where Meta/ contains
- a checkout of the 'todo' branch).
+ - Merge maint to master as needed:
- - Merge topics to 'next'. For each branch whose tip is not
- merged to 'next', one of three things can happen:
+ $ git checkout master
+ $ git merge maint
+ $ make test
- - The commits are all next-worthy; merge the topic to next:
+ - Merge master to next as needed:
$ git checkout next
- $ git merge ai/topic ;# or "git merge ai/maint-topic"
+ $ git merge master
$ make test
+ - Review the last issue of "What's cooking" again and see if topics
+ that are ready to be merged to 'next' are still in good shape
+ (e.g. has there any new issue identified on the list with the
+ series?)
+
+ - Prepare 'jch' branch, which is used to represent somewhere
+ between 'master' and 'pu' and often is slightly ahead of 'next'.
+
+ $ Meta/Reintegrate master..pu >Meta/redo-jch.sh
+
+ The result is a script that lists topics to be merged in order to
+ rebuild 'pu' as the input to Meta/Reintegrate script. Remove
+ later topics that should not be in 'jch' yet. Add a line that
+ consists of '###' before the name of the first topic in the output
+ that should be in 'jch' but not in 'next' yet.
+
+ - Now we are ready to start merging topics to 'next'. For each
+ branch whose tip is not merged to 'next', one of three things can
+ happen:
+
+ - The commits are all next-worthy; merge the topic to next;
- The new parts are of mixed quality, but earlier ones are
- next-worthy; merge the early parts to next:
+ next-worthy; merge the early parts to next;
+ - Nothing is next-worthy; do not do anything.
+
+ This step is aided with Meta/redo-jch.sh script created earlier.
+ If a topic that was already in 'next' gained a patch, the script
+ would list it as "ai/topic~1". To include the new patch to the
+ updated 'next', drop the "~1" part; to keep it excluded, do not
+ touch the line. If a topic that was not in 'next' should be
+ merged to 'next', add it at the end of the list. Then:
+
+ $ git checkout -B jch master
+ $ Meta/redo-jch.sh -c1
+
+ to rebuild the 'jch' branch from scratch. "-c1" tells the script
+ to stop merging at the '###' line you added earlier.
+
+ At this point, build-test the result. It may reveal semantic
+ conflicts (e.g. a topic renamed a variable, another added a new
+ reference to the variable under its old name), in which case
+ prepare an appropriate merge-fix first (see appendix), and
+ rebuild the 'jch' branch from scratch, starting at the tip of
+ 'master'.
+
+ Then do the same to 'next'
$ git checkout next
- $ git merge ai/topic~2 ;# the tip two are dubious
- $ make test
+ $ sh Meta/redo-jch.sh -c1 -e
- - Nothing is next-worthy; do not do anything.
+ The "-e" option allows the merge message that comes from the
+ history of the topic and the comments in the "What's cooking" to
+ be edited. The resulting tree should match 'jch' as the same set
+ of topics are merged on 'master'; otherwise there is a mismerge.
+ Investigate why and do not proceed until the mismerge is found
+ and rectified.
- - [** OBSOLETE **] Optionally rebase topics that do not have any commit
- in next yet, when they can take advantage of low-level framework
- change that is merged to 'master' already.
+ $ git diff jch next
- $ git rebase master ai/topic
+ When all is well, clean up the redo-jch.sh script with
- This step is helped with Meta/git-topic.perl script to
- identify which topic is rebaseable. There also is a
- pre-rebase hook to make sure that topics that are already in
- 'next' are not rebased beyond the merged commit.
+ $ sh Meta/redo-jch.sh -u
- - [** OBSOLETE **] Rebuild "pu" to merge the tips of topics not in 'next'.
+ This removes topics listed in the script that have already been
+ merged to 'master'. This unfortunately loses the "###" marker,
+ so add it again to the appropriate place.
- $ git checkout pu
- $ git reset --hard next
- $ git merge ai/topic ;# repeat for all remaining topics
- $ make test
+ - Rebuild 'pu'.
+
+ $ Meta/Reintegrate master..pu >Meta/redo-pu.sh
+
+ Edit the result by adding new topics that are not still in 'pu'
+ in the script. Then
+
+ $ git checkout -B pu jch
+ $ sh Meta/redo-pu.sh
+
+ When all is well, clean up the redo-pu.sh script with
+
+ $ sh Meta/redo-pu.sh -u
+
+ Double check by running
+
+ $ git branch --no-merged pu
+
+ to see there is no unexpected leftover topics.
+
+ At this point, build-test the result for semantic conflicts, and
+ if there are, prepare an appropriate merge-fix first (see
+ appendix), and rebuild the 'pu' branch from scratch, starting at
+ the tip of 'jch'.
+
+ - Update "What's cooking" message to review the updates to
+ existing topics, newly added topics and graduated topics.
- This step is helped with Meta/PU script
+ This step is helped with Meta/cook script.
- - Push four integration branches to a private repository at
- k.org and run "make test" on all of them.
+ $ Meta/cook
- - Push four integration branches to /pub/scm/git/git.git at
- k.org. This triggers its post-update hook which:
+ This script inspects the history between master..pu, finds tips
+ of topic branches, compares what it found with the current
+ contents in Meta/whats-cooking.txt, and updates that file.
+ Topics not listed in the file but are found in master..pu are
+ added to the "New topics" section, topics listed in the file that
+ are no longer found in master..pu are moved to the "Graduated to
+ master" section, and topics whose commits changed their states
+ (e.g. used to be only in 'pu', now merged to 'next') are updated
+ with change markers "<<" and ">>".
- (1) runs "git pull" in $HOME/git-doc/ repository to pull
- 'master' just pushed out;
+ Look for lines enclosed in "<<" and ">>"; they hold contents from
+ old file that are replaced by this integration round. After
+ verifying them, remove the old part. Review the description for
+ each topic and update its doneness and plan as needed. To review
+ the updated plan, run
- (2) runs "make doc" in $HOME/git-doc/, install the generated
- documentation in staging areas, which are separate
- repositories that have html and man branches checked
- out.
+ $ Meta/cook -w
- (3) runs "git commit" in the staging areas, and run "git
- push" back to /pub/scm/git/git.git/ to update the html
- and man branches.
+ which will pick up comments given to the topics, such as "Will
+ merge to 'next'", etc. (see Meta/cook script to learn what kind
+ of phrases are supported).
- (4) installs generated documentation to /pub/software/scm/git/docs/
- to be viewed from http://www.kernel.org/
+ - Compile, test and install all four (five) integration branches;
+ Meta/Dothem script may aid this step.
- - Fetch html and man branches back from k.org, and push four
- integration branches and the two documentation branches to
- repo.or.cz and other mirrors.
+ - Format documentation if the 'master' branch was updated;
+ Meta/dodoc.sh script may aid this step.
+ - Push the integration branches out to public places; Meta/pushall
+ script may aid this step.
Some observations to be made.
- * Each topic is tested individually, and also together with
- other topics cooking in 'next'. Until it matures, none part
- of it is merged to 'master'.
+ * Each topic is tested individually, and also together with other
+ topics cooking first in 'pu', then in 'jch' and then in 'next'.
+ Until it matures, no part of it is merged to 'master'.
* A topic already in 'next' can get fixes while still in
'next'. Such a topic will have many merges to 'next' (in
other words, "git log --first-parent next" will show many
- "Merge ai/topic to next" for the same topic.
+ "Merge branch 'ai/topic' to next" for the same topic.
* An unobvious fix for 'maint' is cooked in 'next' and then
merged to 'master' to make extra sure it is Ok and then
@@ -274,3 +351,62 @@ Some observations to be made.
* Being in the 'next' branch is not a guarantee for a topic to
be included in the next feature release. Being in the
'master' branch typically is.
+
+
+[Appendix]
+
+Preparing a "merge-fix"
+
+A merge of two topics may not textually conflict but still have
+conflict at the semantic level. A classic example is for one topic
+to rename an variable and all its uses, while another topic adds a
+new use of the variable under its old name. When these two topics
+are merged together, the reference to the variable newly added by
+the latter topic will still use the old name in the result.
+
+The Meta/Reintegrate script that is used by redo-jch and redo-pu
+scripts implements a crude but usable way to work this issue around.
+When the script merges branch $X, it checks if "refs/merge-fix/$X"
+exists, and if so, the effect of it is squashed into the result of
+the mechanical merge. In other words,
+
+ $ echo $X | Meta/Reintegrate
+
+is roughly equivalent to this sequence:
+
+ $ git merge --rerere-autoupdate $X
+ $ git commit
+ $ git cherry-pick -n refs/merge-fix/$X
+ $ git commit --amend
+
+The goal of this "prepare a merge-fix" step is to come up with a
+commit that can be squashed into a result of mechanical merge to
+correct semantic conflicts.
+
+After finding that the result of merging branch "ai/topic" to an
+integration branch had such a semantic conflict, say pu~4, check the
+problematic merge out on a detached HEAD, edit the working tree to
+fix the semantic conflict, and make a separate commit to record the
+fix-up:
+
+ $ git checkout pu~4
+ $ git show -s --pretty=%s ;# double check
+ Merge branch 'ai/topic' to pu
+ $ edit
+ $ git commit -m 'merge-fix/ai/topic' -a
+
+Then make a reference "refs/merge-fix/ai/topic" to point at this
+result:
+
+ $ git update-ref refs/merge-fix/ai/topic HEAD
+
+Then double check the result by asking Meta/Reintegrate to redo the
+merge:
+
+ $ git checkout pu~5 ;# the parent of the problem merge
+ $ echo ai/topic | Meta/Reintegrate
+ $ git diff pu~4
+
+This time, because you prepared refs/merge-fix/ai/topic, the
+resulting merge should have been tweaked to include the fix for the
+semantic conflict.
--
1.8.1.293.g4a210a9
^ permalink raw reply related
* Re: git filter-branch doesn't dereference annotated tags
From: Brandon Casey @ 2013-01-03 20:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Grégory Pakosz, Junio C Hamano, git
In-Reply-To: <50E55E94.2090401@kdbg.org>
On Thu, Jan 3, 2013 at 2:33 AM, Johannes Sixt <j6t@kdbg.org> wrote:
> Am 03.01.2013 10:50, schrieb Grégory Pakosz:
>>>
>>> IOW, if the command was something like
>>>
>>> git filter-branch ...filter options... -- v1.0 master ...
>>>
>>> and v1.0 is an annotated tag, then it is reasonable to expect v1.0 to be
>>> deleted if the commit it points to goes away. But if the commit did not
>>> go away, but was rewritten, then it is equally reasonable to expect that
>>> the tag is also rewritten. But I don't think that we currently do the
>>> latter.
>>>
>> When the commit doesn't go away, the tag is currently being rewritten properly.
>
> Indeed, but only if a --tag-name-filter was specified.
>
>>> Therefore, IMO, a change that implements the former behavior should also
>>> implement the latter behavior.
>>>
>> The patch in my latest email does both. (yet lacks unit tests for now)
>
> If it deletes a tag only when --tag-name-filter was specified, than that
> should be fine.
Hmm, if a tag name filter _other_ than 'cat' is supplied, I think a
user will expect that the original tags will _not_ be touched, and
especially not deleted.
Rather than blindly deleting the original tag ref, maybe we should
still call the user's tag name filter, and then attempt to delete the
"new" name provided by the filter, if it exists. If the filter was
'cat', then the new and old names will be the same.
-Brandon
^ permalink raw reply
* Re: cvsps, parsecvs, svn2git and the CVS exporter mess
From: Eric S. Raymond @ 2013-01-03 20:53 UTC (permalink / raw)
To: Michael Haggerty
Cc: Yann Dirson, Heiko Voigt, Antoine Pelisse, Bart Massey,
Keith Packard, David Mansfield, git
In-Reply-To: <50E5A5CF.2070009@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> There are two good reasons that the output is written to two separate files:
Those are good reasons to write to a pair of tempfiles, and I was able
to deduce in advance most of what your explanation would be from the
bare fact that you did it that way.
They are *not* good reasons for having an interface that exposes this
implementation detail to the caller - that choice I consider a failure
of interface-design judgment. But I know how to fix this in a simple and
backward-compatible way, and will do so when I have time to write you
a patch. Next week or the week after, most likely.
Also, the cvs2git manual page is still rather half-baked and careless,
with several fossil references to cvs2svn that shouldn't be there and
obviously incomplete feature coverage. Fixing these bugs is also on my
to-do list for sometime this month.
I'd be willing to put in this work anyway, but it still in the back of
my mind that if cvs2git wins the test-suite competition I might
officially end-of-life both cvsps and parsecvs. One of the features
of the new git-cvsimport is direct support for using cvs2git as a
conversion engine.
> A potentially bigger problem is that if you want to handle such
> blob/dump output, you have to deal with git-fast-import format's "blob"
> command as opposed to only handling inline blobs.
Not a problem. All of the main potential consumers for this output,
including reposurgeon, handle the blob command just fine.
> cvs2git does not currently support incremental conversions; therefore, a
> cvsps-based option (if it would actually work, that is) would have at
> least one advantage over cvs2git.
Yes. The reason I didn't ship the replacement patch Junio was
expecting yesterday is that I don't have test coverage for the
incremental case. I'm working on that now.
> cvs2svn has an extensive test suite which includes tests derived from
> bug reports that we have received over the years. I adapted a few of
> its test repositories to create the git test suite additions that I made
> in Feb 2009, but there are many more in our project.
I've merged those into my tree.
> I think it would be great to have a way to test across tools, though
> please realize that the inference of the most plausible "true" CVS
> history is partly objective but also often a matter of heuristics and
> taste. Moreover, the choice of how to represent the inferred history in
> git, which has rather a different model than CVS/Subversion, is also
> non-obvious and somewhat controversial. I expect that there will be a
> number of simple CVS repositories for which we can all agree about the
> correct git output, but not far away will be a vast number for which the
> "correct" answer is unclear. Many of the interesting tests would fall
> into the latter category.
I'm aware of the problem. One of the interesting questions is how much
further into the weird cases everybody can agree on what correct
translation looks like. We won't know until we push it.
> It's not clear what you want me to sign off on.
If you're not willing to use the new suite, my spending the effort
required to genericize it gets much less interesting. I needed
Junio's agreement because I wanted to move the old git-cvsimport
tests from the git tree to the new test suite; they're not really
tests of the wrapper script at all but of the conversion engines.
> I guess you want to
> replace (or augment?) the cvs2svn test suite with one based on your
> framework?
Augment, not replace - and just as importantly, commit to writing
new tests into the new generic framework when they don't involve a
tool-specific option. It would be silly and duplicative for us *not*
to be sharing as many tests as we can.
> * We definitely want to continue testing the Subversion output of
> cvs2svn. A test suite that only tests the git output could at best be
> an addition to the current test suite, not a replacement for it. (That
> being said, the addition of good tests of the 2git output would be great.)
Agreed.
> * A test suite that tests only the easy cases wouldn't really be
> interesting, because the difficult cases are where the potential
> problems lie.
Yes, I know. I'm arguing that we should be doing that exploration
jointly rather than separately.
> * It would be unfortunate if the cvs2svn test suite would grow another
> run-time dependency or if we would have to invest a lot of time
> synchronizing with another project, though if the gain were big enough
> we could consider it.
I know how to keep the friction cost low. You'll see more about this when
I split off the test suite and announce it.
> * The licenses obviously have to be compatible to the extent required by
> the level of coupling.
I don't think this will be a problem. You own the copyright on your tests and
I own it on mine, so we can relicense under whatever common license we choose.
I'm not fussy about what we use; ASL 2.0 would be fine by me.
> * I don't have a lot of time to work on the integration. cvs2svn has
> long been at a level of maturity where it doesn't need much care and
> feeding, and I would like to keep it that way :-) Nowadays I am far
> more interested in working on the git project with my little available
> open-sourcin' time.
I don't want to spend the rest of my life on the CVS-lifting problem either.
My present plans envision intense work on it for another three weeks or
so, after which I expect we'll be at a relatively stable and low-maintainance
state.
FYI, here are my agenda items in roughly the order I expect to finish them:
1. Write test coverage for incremental imports.
2. Ship version 2 of the git-cvsimport replacement patch (with the fallback
option Junio requested) to the git list.
3. Get parsecvs to a non-broken state and ship a release
4. Ship a patch for git-cvsimport that adds the option to use parsecvs
as a conversion engine.
5. Break the test suite out of cvsps, give it its own public repo, document
it, and hand you the keys.
6. Fix the interface-design bug(s) in cvs2git, and its documentation.
7. Torture-test all three tools (cvsps, parsecvs, cvs2git) against the
new suite.
8. Make a judgement about whether I should EOL cvsps or parsecvs or both.
I have other commitments, so this will take a bit longer than it might
have. I expect to be at step 8 in roughly a month (early February).
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Suggested improvements to the git-p4 documentation (branch-related)
From: Olivier Delalleau @ 2013-01-03 20:58 UTC (permalink / raw)
To: git
Hi,
While struggling to get git-p4 to work properly with branches, I
thought the documentation on http://git-scm.com/docs/git-p4 could use
some improvements:
1. At the end of the "Branch detection" section, the following
commands are provided (for when you want to explicitly provide branch
mappings to git-p4):
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all
The second command should end with a dot (".") because the first
command only works if you are already in a git-initialized folder.
Thus I would also suggest to add "git init" as first command to type.
2. Even though having a "main" branch is standard in Perforce, it
would be worth mentioning what happens when you don't: there is a
message "Could not detect main branch. No checkout/master branch
created" output by the "git p4 clone" command. However, it will still
work if you manually set the master branch ("git checkout -b master
remotes/p4/my_custom_main_branch").
3. I don't know what I missed for that one, but I haven't been able to
get the example for the --branch option to work. It says that after
"git init", we can import a p4 branch with:
git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
However, after doing this, followed by "git checkout -b proj2
remotes/p4/proj2", I am unable to properly use "git p4 sync" or "git
p4 submit" from this branch, as git complains about a missing
refs/remotes/p4/master.
Maybe it only works if "git clone" has been used before? But then why
have "git init" first?
NB: it's quite possible some of my problems were caused by me not
properly understanding the doc / how git/p4 works. My apologies if
that's the case.
-=- Olivier
^ permalink raw reply
* Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Jeff King @ 2013-01-03 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20130103203222.GB4632@sigill.intra.peff.net>
On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote:
> I think the usefulness is that it can be set by default for a particular
> uname, so people on Windows can just type "make install-doc" without
> having to care about setting anything (though to be honest, I do not
> even know what they build by default; maybe they do build manpages).
> Except that in the original thread:
>
> > http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201
>
> it became clear that to do that we would also want to hoist the uname
> automagic defaults into their own file that could be read from
> Documentation/Makefile.
IOW, this (on the current master), which I think is a nice cleanup
regardless of this series:
-- >8 --
Subject: [PATCH] Makefile: hoist uname autodetection to config.mak.uname
Our Makefile first sets up some sane per-platform defaults
by looking at "uname", then modifies that according to the
results of autoconf (if any), then modifies that according
to the user's wishes in config.mak.
For sub-Makefiles like Documentation/Makefile, the latter
two are available, but the uname defaults are available only
to the main Makefile. This hasn't been a problem so far,
because the sub-Makefiles do not rely on any of those
automatic settings to do their work.
This patch puts the uname magic into its own file so it can
be reused in other Makefiles, opening up the possibility of
new knobs.
Note that we leave one reference to uname in the top-level
Makefile: if we are on Darwin, we must check the NO_FINK and
NO_DARWIN_PORTS settings. But because we are combining uname
settings with user-options, we must do so after all of the
config is loaded. This is acceptable, as the resulting
conditionals are about setting variables specific to the
top-level Makefile (and if that ever changes, we can hoist
them into a separate post-config include, too).
Signed-off-by: Jeff King <peff@peff.net>
---
I'm happy to call it "config.mak.autodetect" if you prefer. My rationale
was that we might eventually have several levels of autodetection, and
we would want to be able to order them individually (in fact, we already
do; config.mak.autogen is another form that should take precedence over
uname detection, and it is already split out).
Makefile | 526 +------------------------------------------------------
config.mak.uname | 522 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 523 insertions(+), 525 deletions(-)
create mode 100644 config.mak.uname
diff --git a/Makefile b/Makefile
index 736ecd4..5e4ee47 100644
--- a/Makefile
+++ b/Makefile
@@ -326,19 +326,6 @@ GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
-uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
-uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
-uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
-uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
-uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
-uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
-
-ifdef MSVC
- # avoid the MingW and Cygwin configuration sections
- uname_S := Windows
- uname_O := Windows
-endif
-
# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2 -Wall
@@ -937,518 +924,7 @@ GIT_USER_AGENT = git/$(GIT_VERSION)
GIT_USER_AGENT = git/$(GIT_VERSION)
-#
-# Platform specific tweaks
-#
-
-# We choose to avoid "if .. else if .. else .. endif endif"
-# because maintaining the nesting to match is a pain. If
-# we had "elif" things would have been much nicer...
-
-ifeq ($(uname_M),x86_64)
- XDL_FAST_HASH = YesPlease
-endif
-ifeq ($(uname_S),OSF1)
- # Need this for u_short definitions et al
- BASIC_CFLAGS += -D_OSF_SOURCE
- SOCKLEN_T = int
- NO_STRTOULL = YesPlease
- NO_NSEC = YesPlease
-endif
-ifeq ($(uname_S),Linux)
- NO_STRLCPY = YesPlease
- NO_MKSTEMPS = YesPlease
- HAVE_PATHS_H = YesPlease
- LIBC_CONTAINS_LIBINTL = YesPlease
- HAVE_DEV_TTY = YesPlease
-endif
-ifeq ($(uname_S),GNU/kFreeBSD)
- NO_STRLCPY = YesPlease
- NO_MKSTEMPS = YesPlease
- HAVE_PATHS_H = YesPlease
- DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
- LIBC_CONTAINS_LIBINTL = YesPlease
-endif
-ifeq ($(uname_S),UnixWare)
- CC = cc
- NEEDS_SOCKET = YesPlease
- NEEDS_NSL = YesPlease
- NEEDS_SSL_WITH_CRYPTO = YesPlease
- NEEDS_LIBICONV = YesPlease
- SHELL_PATH = /usr/local/bin/bash
- NO_IPV6 = YesPlease
- NO_HSTRERROR = YesPlease
- NO_MKSTEMPS = YesPlease
- BASIC_CFLAGS += -Kthread
- BASIC_CFLAGS += -I/usr/local/include
- BASIC_LDFLAGS += -L/usr/local/lib
- INSTALL = ginstall
- TAR = gtar
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
-endif
-ifeq ($(uname_S),SCO_SV)
- ifeq ($(uname_R),3.2)
- CFLAGS = -O2
- endif
- ifeq ($(uname_R),5)
- CC = cc
- BASIC_CFLAGS += -Kthread
- endif
- NEEDS_SOCKET = YesPlease
- NEEDS_NSL = YesPlease
- NEEDS_SSL_WITH_CRYPTO = YesPlease
- NEEDS_LIBICONV = YesPlease
- SHELL_PATH = /usr/bin/bash
- NO_IPV6 = YesPlease
- NO_HSTRERROR = YesPlease
- NO_MKSTEMPS = YesPlease
- BASIC_CFLAGS += -I/usr/local/include
- BASIC_LDFLAGS += -L/usr/local/lib
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- INSTALL = ginstall
- TAR = gtar
-endif
-ifeq ($(uname_S),Darwin)
- NEEDS_CRYPTO_WITH_SSL = YesPlease
- NEEDS_SSL_WITH_CRYPTO = YesPlease
- NEEDS_LIBICONV = YesPlease
- ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
- OLD_ICONV = UnfortunatelyYes
- endif
- ifeq ($(shell expr "$(uname_R)" : '[15]\.'),2)
- NO_STRLCPY = YesPlease
- endif
- NO_MEMMEM = YesPlease
- USE_ST_TIMESPEC = YesPlease
- HAVE_DEV_TTY = YesPlease
- COMPAT_OBJS += compat/precompose_utf8.o
- BASIC_CFLAGS += -DPRECOMPOSE_UNICODE
-endif
-ifeq ($(uname_S),SunOS)
- NEEDS_SOCKET = YesPlease
- NEEDS_NSL = YesPlease
- SHELL_PATH = /bin/bash
- SANE_TOOL_PATH = /usr/xpg6/bin:/usr/xpg4/bin
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- NO_MKDTEMP = YesPlease
- NO_MKSTEMPS = YesPlease
- NO_REGEX = YesPlease
- NO_FNMATCH_CASEFOLD = YesPlease
- NO_MSGFMT_EXTENDED_OPTIONS = YesPlease
- HAVE_DEV_TTY = YesPlease
- ifeq ($(uname_R),5.6)
- SOCKLEN_T = int
- NO_HSTRERROR = YesPlease
- NO_IPV6 = YesPlease
- NO_SOCKADDR_STORAGE = YesPlease
- NO_UNSETENV = YesPlease
- NO_SETENV = YesPlease
- NO_STRLCPY = YesPlease
- NO_STRTOUMAX = YesPlease
- GIT_TEST_CMP = cmp
- endif
- ifeq ($(uname_R),5.7)
- NEEDS_RESOLV = YesPlease
- NO_IPV6 = YesPlease
- NO_SOCKADDR_STORAGE = YesPlease
- NO_UNSETENV = YesPlease
- NO_SETENV = YesPlease
- NO_STRLCPY = YesPlease
- NO_STRTOUMAX = YesPlease
- GIT_TEST_CMP = cmp
- endif
- ifeq ($(uname_R),5.8)
- NO_UNSETENV = YesPlease
- NO_SETENV = YesPlease
- NO_STRTOUMAX = YesPlease
- GIT_TEST_CMP = cmp
- endif
- ifeq ($(uname_R),5.9)
- NO_UNSETENV = YesPlease
- NO_SETENV = YesPlease
- NO_STRTOUMAX = YesPlease
- GIT_TEST_CMP = cmp
- endif
- INSTALL = /usr/ucb/install
- TAR = gtar
- BASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__ -DHAVE_ALLOCA_H
-endif
-ifeq ($(uname_O),Cygwin)
- ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4)
- NO_D_TYPE_IN_DIRENT = YesPlease
- NO_D_INO_IN_DIRENT = YesPlease
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- NO_MKSTEMPS = YesPlease
- NO_SYMLINK_HEAD = YesPlease
- NO_IPV6 = YesPlease
- OLD_ICONV = UnfortunatelyYes
- CYGWIN_V15_WIN32API = YesPlease
- endif
- NO_THREAD_SAFE_PREAD = YesPlease
- NEEDS_LIBICONV = YesPlease
- NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
- NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
- NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
- # There are conflicting reports about this.
- # On some boxes NO_MMAP is needed, and not so elsewhere.
- # Try commenting this out if you suspect MMAP is more efficient
- NO_MMAP = YesPlease
- X = .exe
- COMPAT_OBJS += compat/cygwin.o
- UNRELIABLE_FSTAT = UnfortunatelyYes
- SPARSE_FLAGS = -isystem /usr/include/w32api -Wno-one-bit-signed-bitfield
-endif
-ifeq ($(uname_S),FreeBSD)
- NEEDS_LIBICONV = YesPlease
- OLD_ICONV = YesPlease
- NO_MEMMEM = YesPlease
- BASIC_CFLAGS += -I/usr/local/include
- BASIC_LDFLAGS += -L/usr/local/lib
- DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
- USE_ST_TIMESPEC = YesPlease
- ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
- PTHREAD_LIBS = -pthread
- NO_UINTMAX_T = YesPlease
- NO_STRTOUMAX = YesPlease
- endif
- PYTHON_PATH = /usr/local/bin/python
- HAVE_PATHS_H = YesPlease
-endif
-ifeq ($(uname_S),OpenBSD)
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- USE_ST_TIMESPEC = YesPlease
- NEEDS_LIBICONV = YesPlease
- BASIC_CFLAGS += -I/usr/local/include
- BASIC_LDFLAGS += -L/usr/local/lib
- HAVE_PATHS_H = YesPlease
-endif
-ifeq ($(uname_S),NetBSD)
- ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
- NEEDS_LIBICONV = YesPlease
- endif
- BASIC_CFLAGS += -I/usr/pkg/include
- BASIC_LDFLAGS += -L/usr/pkg/lib $(CC_LD_DYNPATH)/usr/pkg/lib
- USE_ST_TIMESPEC = YesPlease
- NO_MKSTEMPS = YesPlease
- HAVE_PATHS_H = YesPlease
-endif
-ifeq ($(uname_S),AIX)
- DEFAULT_PAGER = more
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- NO_MKDTEMP = YesPlease
- NO_MKSTEMPS = YesPlease
- NO_STRLCPY = YesPlease
- NO_NSEC = YesPlease
- FREAD_READS_DIRECTORIES = UnfortunatelyYes
- INTERNAL_QSORT = UnfortunatelyYes
- NEEDS_LIBICONV = YesPlease
- BASIC_CFLAGS += -D_LARGE_FILES
- ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
- NO_PTHREADS = YesPlease
- else
- PTHREAD_LIBS = -lpthread
- endif
- ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
- INLINE = ''
- endif
- GIT_TEST_CMP = cmp
-endif
-ifeq ($(uname_S),GNU)
- # GNU/Hurd
- NO_STRLCPY = YesPlease
- NO_MKSTEMPS = YesPlease
- HAVE_PATHS_H = YesPlease
- LIBC_CONTAINS_LIBINTL = YesPlease
-endif
-ifeq ($(uname_S),IRIX)
- NO_SETENV = YesPlease
- NO_UNSETENV = YesPlease
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- NO_MKSTEMPS = YesPlease
- NO_MKDTEMP = YesPlease
- # When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
- # (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
- # git dies with a segmentation fault when trying to access the first
- # entry of a reflog. The conservative choice is made to always set
- # NO_MMAP. If you suspect that your compiler is not affected by this
- # issue, comment out the NO_MMAP statement.
- NO_MMAP = YesPlease
- NO_REGEX = YesPlease
- NO_FNMATCH_CASEFOLD = YesPlease
- SNPRINTF_RETURNS_BOGUS = YesPlease
- SHELL_PATH = /usr/gnu/bin/bash
- NEEDS_LIBGEN = YesPlease
-endif
-ifeq ($(uname_S),IRIX64)
- NO_SETENV = YesPlease
- NO_UNSETENV = YesPlease
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- NO_MKSTEMPS = YesPlease
- NO_MKDTEMP = YesPlease
- # When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
- # (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
- # git dies with a segmentation fault when trying to access the first
- # entry of a reflog. The conservative choice is made to always set
- # NO_MMAP. If you suspect that your compiler is not affected by this
- # issue, comment out the NO_MMAP statement.
- NO_MMAP = YesPlease
- NO_REGEX = YesPlease
- NO_FNMATCH_CASEFOLD = YesPlease
- SNPRINTF_RETURNS_BOGUS = YesPlease
- SHELL_PATH = /usr/gnu/bin/bash
- NEEDS_LIBGEN = YesPlease
-endif
-ifeq ($(uname_S),HP-UX)
- INLINE = __inline
- NO_IPV6 = YesPlease
- NO_SETENV = YesPlease
- NO_STRCASESTR = YesPlease
- NO_MEMMEM = YesPlease
- NO_MKSTEMPS = YesPlease
- NO_STRLCPY = YesPlease
- NO_MKDTEMP = YesPlease
- NO_UNSETENV = YesPlease
- NO_HSTRERROR = YesPlease
- NO_SYS_SELECT_H = YesPlease
- NO_FNMATCH_CASEFOLD = YesPlease
- SNPRINTF_RETURNS_BOGUS = YesPlease
- NO_NSEC = YesPlease
- ifeq ($(uname_R),B.11.00)
- NO_INET_NTOP = YesPlease
- NO_INET_PTON = YesPlease
- endif
- ifeq ($(uname_R),B.10.20)
- # Override HP-UX 11.x setting:
- INLINE =
- SOCKLEN_T = size_t
- NO_PREAD = YesPlease
- NO_INET_NTOP = YesPlease
- NO_INET_PTON = YesPlease
- endif
- GIT_TEST_CMP = cmp
-endif
-ifeq ($(uname_S),Windows)
- GIT_VERSION := $(GIT_VERSION).MSVC
- pathsep = ;
- NO_PREAD = YesPlease
- NEEDS_CRYPTO_WITH_SSL = YesPlease
- NO_LIBGEN_H = YesPlease
- NO_POLL = YesPlease
- NO_SYMLINK_HEAD = YesPlease
- NO_IPV6 = YesPlease
- NO_UNIX_SOCKETS = YesPlease
- NO_SETENV = YesPlease
- NO_UNSETENV = YesPlease
- NO_STRCASESTR = YesPlease
- NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
- NO_FNMATCH = YesPlease
- NO_MEMMEM = YesPlease
- # NEEDS_LIBICONV = YesPlease
- NO_ICONV = YesPlease
- NO_STRTOUMAX = YesPlease
- NO_STRTOULL = YesPlease
- NO_MKDTEMP = YesPlease
- NO_MKSTEMPS = YesPlease
- SNPRINTF_RETURNS_BOGUS = YesPlease
- NO_SVN_TESTS = YesPlease
- NO_PERL_MAKEMAKER = YesPlease
- RUNTIME_PREFIX = YesPlease
- NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
- NO_NSEC = YesPlease
- USE_WIN32_MMAP = YesPlease
- # USE_NED_ALLOCATOR = YesPlease
- UNRELIABLE_FSTAT = UnfortunatelyYes
- OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
- NO_REGEX = YesPlease
- NO_CURL = YesPlease
- NO_PYTHON = YesPlease
- BLK_SHA1 = YesPlease
- NO_POSIX_GOODIES = UnfortunatelyYes
- NATIVE_CRLF = YesPlease
- DEFAULT_HELP_FORMAT = html
-
- CC = compat/vcbuild/scripts/clink.pl
- AR = compat/vcbuild/scripts/lib.pl
- CFLAGS =
- BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
- COMPAT_OBJS = compat/msvc.o compat/winansi.o \
- compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/dirent.o
- COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
- BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
- EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
- PTHREAD_LIBS =
- lib =
-ifndef DEBUG
- BASIC_CFLAGS += -GL -Os -MT
- BASIC_LDFLAGS += -LTCG
- AR += -LTCG
-else
- BASIC_CFLAGS += -Zi -MTd
-endif
- X = .exe
-endif
-ifeq ($(uname_S),Interix)
- NO_INITGROUPS = YesPlease
- NO_IPV6 = YesPlease
- NO_MEMMEM = YesPlease
- NO_MKDTEMP = YesPlease
- NO_STRTOUMAX = YesPlease
- NO_NSEC = YesPlease
- NO_MKSTEMPS = YesPlease
- ifeq ($(uname_R),3.5)
- NO_INET_NTOP = YesPlease
- NO_INET_PTON = YesPlease
- NO_SOCKADDR_STORAGE = YesPlease
- NO_FNMATCH_CASEFOLD = YesPlease
- endif
- ifeq ($(uname_R),5.2)
- NO_INET_NTOP = YesPlease
- NO_INET_PTON = YesPlease
- NO_SOCKADDR_STORAGE = YesPlease
- NO_FNMATCH_CASEFOLD = YesPlease
- endif
-endif
-ifeq ($(uname_S),Minix)
- NO_IPV6 = YesPlease
- NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
- NO_NSEC = YesPlease
- NEEDS_LIBGEN =
- NEEDS_CRYPTO_WITH_SSL = YesPlease
- NEEDS_IDN_WITH_CURL = YesPlease
- NEEDS_SSL_WITH_CURL = YesPlease
- NEEDS_RESOLV =
- NO_HSTRERROR = YesPlease
- NO_MMAP = YesPlease
- NO_CURL =
- NO_EXPAT =
-endif
-ifeq ($(uname_S),NONSTOP_KERNEL)
- # Needs some C99 features, "inline" is just one of them.
- # INLINE='' would just replace one set of warnings with another and
- # still not compile in c89 mode, due to non-const array initializations.
- CC = cc -c99
- # Disable all optimization, seems to result in bad code, with -O or -O2
- # or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
- # abends on "git push". Needs more investigation.
- CFLAGS = -g -O0
- # We'd want it to be here.
- prefix = /usr/local
- # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
- PERL_PATH = ${prefix}/bin/perl
- PYTHON_PATH = ${prefix}/bin/python
-
- # As detected by './configure'.
- # Missdetected, hence commented out, see below.
- #NO_CURL = YesPlease
- # Added manually, see above.
- NEEDS_SSL_WITH_CURL = YesPlease
- HAVE_LIBCHARSET_H = YesPlease
- NEEDS_LIBICONV = YesPlease
- NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
- NO_SYS_SELECT_H = UnfortunatelyYes
- NO_D_TYPE_IN_DIRENT = YesPlease
- NO_HSTRERROR = YesPlease
- NO_STRCASESTR = YesPlease
- NO_FNMATCH_CASEFOLD = YesPlease
- NO_MEMMEM = YesPlease
- NO_STRLCPY = YesPlease
- NO_SETENV = YesPlease
- NO_UNSETENV = YesPlease
- NO_MKDTEMP = YesPlease
- NO_MKSTEMPS = YesPlease
- # Currently libiconv-1.9.1.
- OLD_ICONV = UnfortunatelyYes
- NO_REGEX = YesPlease
- NO_PTHREADS = UnfortunatelyYes
-
- # Not detected (nor checked for) by './configure'.
- # We don't have SA_RESTART on NonStop, unfortunalety.
- COMPAT_CFLAGS += -DSA_RESTART=0
- # Apparently needed in compat/fnmatch/fnmatch.c.
- COMPAT_CFLAGS += -DHAVE_STRING_H=1
- NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
- NO_NSEC = YesPlease
- NO_PREAD = YesPlease
- NO_MMAP = YesPlease
- NO_POLL = YesPlease
- NO_INTPTR_T = UnfortunatelyYes
- # Bug report 10-120822-4477 submitted to HP NonStop development.
- MKDIR_WO_TRAILING_SLASH = YesPlease
- # RFE 10-120912-4693 submitted to HP NonStop development.
- NO_SETITIMER = UnfortunatelyYes
- SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
- SHELL_PATH = /usr/local/bin/bash
- # as of H06.25/J06.14, we might better use this
- #SHELL_PATH = /usr/coreutils/bin/bash
-endif
-ifneq (,$(findstring MINGW,$(uname_S)))
- pathsep = ;
- NO_PREAD = YesPlease
- NEEDS_CRYPTO_WITH_SSL = YesPlease
- NO_LIBGEN_H = YesPlease
- NO_POLL = YesPlease
- NO_SYMLINK_HEAD = YesPlease
- NO_UNIX_SOCKETS = YesPlease
- NO_SETENV = YesPlease
- NO_UNSETENV = YesPlease
- NO_STRCASESTR = YesPlease
- NO_STRLCPY = YesPlease
- NO_STRTOK_R = YesPlease
- NO_FNMATCH = YesPlease
- NO_MEMMEM = YesPlease
- NEEDS_LIBICONV = YesPlease
- OLD_ICONV = YesPlease
- NO_STRTOUMAX = YesPlease
- NO_MKDTEMP = YesPlease
- NO_MKSTEMPS = YesPlease
- NO_SVN_TESTS = YesPlease
- NO_PERL_MAKEMAKER = YesPlease
- RUNTIME_PREFIX = YesPlease
- NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
- NO_NSEC = YesPlease
- USE_WIN32_MMAP = YesPlease
- USE_NED_ALLOCATOR = YesPlease
- UNRELIABLE_FSTAT = UnfortunatelyYes
- OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
- NO_REGEX = YesPlease
- NO_PYTHON = YesPlease
- BLK_SHA1 = YesPlease
- ETAGS_TARGET = ETAGS
- NO_INET_PTON = YesPlease
- NO_INET_NTOP = YesPlease
- NO_POSIX_GOODIES = UnfortunatelyYes
- COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/win32
- COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
- COMPAT_OBJS += compat/mingw.o compat/winansi.o \
- compat/win32/pthread.o compat/win32/syslog.o \
- compat/win32/dirent.o
- EXTLIBS += -lws2_32
- PTHREAD_LIBS =
- X = .exe
- SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
-ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
- htmldir = doc/git/html/
- prefix =
- INSTALL = /bin/install
- EXTLIBS += /mingw/lib/libz.a
- NO_R_TO_GCC_LINKER = YesPlease
- INTERNAL_QSORT = YesPlease
- HAVE_LIBCHARSET_H = YesPlease
-else
- NO_CURL = YesPlease
-endif
-endif
-
+include config.mak.uname
-include config.mak.autogen
-include config.mak
diff --git a/config.mak.uname b/config.mak.uname
new file mode 100644
index 0000000..3ccbb8e
--- /dev/null
+++ b/config.mak.uname
@@ -0,0 +1,522 @@
+# Platform specific Makefile tweaks based on uname detection
+
+uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
+uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
+uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
+uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
+uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
+uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
+
+ifdef MSVC
+ # avoid the MingW and Cygwin configuration sections
+ uname_S := Windows
+ uname_O := Windows
+endif
+
+# We choose to avoid "if .. else if .. else .. endif endif"
+# because maintaining the nesting to match is a pain. If
+# we had "elif" things would have been much nicer...
+
+ifeq ($(uname_M),x86_64)
+ XDL_FAST_HASH = YesPlease
+endif
+ifeq ($(uname_S),OSF1)
+ # Need this for u_short definitions et al
+ BASIC_CFLAGS += -D_OSF_SOURCE
+ SOCKLEN_T = int
+ NO_STRTOULL = YesPlease
+ NO_NSEC = YesPlease
+endif
+ifeq ($(uname_S),Linux)
+ NO_STRLCPY = YesPlease
+ NO_MKSTEMPS = YesPlease
+ HAVE_PATHS_H = YesPlease
+ LIBC_CONTAINS_LIBINTL = YesPlease
+ HAVE_DEV_TTY = YesPlease
+endif
+ifeq ($(uname_S),GNU/kFreeBSD)
+ NO_STRLCPY = YesPlease
+ NO_MKSTEMPS = YesPlease
+ HAVE_PATHS_H = YesPlease
+ DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
+ LIBC_CONTAINS_LIBINTL = YesPlease
+endif
+ifeq ($(uname_S),UnixWare)
+ CC = cc
+ NEEDS_SOCKET = YesPlease
+ NEEDS_NSL = YesPlease
+ NEEDS_SSL_WITH_CRYPTO = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ SHELL_PATH = /usr/local/bin/bash
+ NO_IPV6 = YesPlease
+ NO_HSTRERROR = YesPlease
+ NO_MKSTEMPS = YesPlease
+ BASIC_CFLAGS += -Kthread
+ BASIC_CFLAGS += -I/usr/local/include
+ BASIC_LDFLAGS += -L/usr/local/lib
+ INSTALL = ginstall
+ TAR = gtar
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+endif
+ifeq ($(uname_S),SCO_SV)
+ ifeq ($(uname_R),3.2)
+ CFLAGS = -O2
+ endif
+ ifeq ($(uname_R),5)
+ CC = cc
+ BASIC_CFLAGS += -Kthread
+ endif
+ NEEDS_SOCKET = YesPlease
+ NEEDS_NSL = YesPlease
+ NEEDS_SSL_WITH_CRYPTO = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ SHELL_PATH = /usr/bin/bash
+ NO_IPV6 = YesPlease
+ NO_HSTRERROR = YesPlease
+ NO_MKSTEMPS = YesPlease
+ BASIC_CFLAGS += -I/usr/local/include
+ BASIC_LDFLAGS += -L/usr/local/lib
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ INSTALL = ginstall
+ TAR = gtar
+endif
+ifeq ($(uname_S),Darwin)
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ NEEDS_SSL_WITH_CRYPTO = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ ifeq ($(shell expr "$(uname_R)" : '[15678]\.'),2)
+ OLD_ICONV = UnfortunatelyYes
+ endif
+ ifeq ($(shell expr "$(uname_R)" : '[15]\.'),2)
+ NO_STRLCPY = YesPlease
+ endif
+ NO_MEMMEM = YesPlease
+ USE_ST_TIMESPEC = YesPlease
+ HAVE_DEV_TTY = YesPlease
+ COMPAT_OBJS += compat/precompose_utf8.o
+ BASIC_CFLAGS += -DPRECOMPOSE_UNICODE
+endif
+ifeq ($(uname_S),SunOS)
+ NEEDS_SOCKET = YesPlease
+ NEEDS_NSL = YesPlease
+ SHELL_PATH = /bin/bash
+ SANE_TOOL_PATH = /usr/xpg6/bin:/usr/xpg4/bin
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_REGEX = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_MSGFMT_EXTENDED_OPTIONS = YesPlease
+ HAVE_DEV_TTY = YesPlease
+ ifeq ($(uname_R),5.6)
+ SOCKLEN_T = int
+ NO_HSTRERROR = YesPlease
+ NO_IPV6 = YesPlease
+ NO_SOCKADDR_STORAGE = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_SETENV = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_STRTOUMAX = YesPlease
+ GIT_TEST_CMP = cmp
+ endif
+ ifeq ($(uname_R),5.7)
+ NEEDS_RESOLV = YesPlease
+ NO_IPV6 = YesPlease
+ NO_SOCKADDR_STORAGE = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_SETENV = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_STRTOUMAX = YesPlease
+ GIT_TEST_CMP = cmp
+ endif
+ ifeq ($(uname_R),5.8)
+ NO_UNSETENV = YesPlease
+ NO_SETENV = YesPlease
+ NO_STRTOUMAX = YesPlease
+ GIT_TEST_CMP = cmp
+ endif
+ ifeq ($(uname_R),5.9)
+ NO_UNSETENV = YesPlease
+ NO_SETENV = YesPlease
+ NO_STRTOUMAX = YesPlease
+ GIT_TEST_CMP = cmp
+ endif
+ INSTALL = /usr/ucb/install
+ TAR = gtar
+ BASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__ -DHAVE_ALLOCA_H
+endif
+ifeq ($(uname_O),Cygwin)
+ ifeq ($(shell expr "$(uname_R)" : '1\.[1-6]\.'),4)
+ NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_D_INO_IN_DIRENT = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_SYMLINK_HEAD = YesPlease
+ NO_IPV6 = YesPlease
+ OLD_ICONV = UnfortunatelyYes
+ CYGWIN_V15_WIN32API = YesPlease
+ endif
+ NO_THREAD_SAFE_PREAD = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
+ NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ # There are conflicting reports about this.
+ # On some boxes NO_MMAP is needed, and not so elsewhere.
+ # Try commenting this out if you suspect MMAP is more efficient
+ NO_MMAP = YesPlease
+ X = .exe
+ COMPAT_OBJS += compat/cygwin.o
+ UNRELIABLE_FSTAT = UnfortunatelyYes
+ SPARSE_FLAGS = -isystem /usr/include/w32api -Wno-one-bit-signed-bitfield
+endif
+ifeq ($(uname_S),FreeBSD)
+ NEEDS_LIBICONV = YesPlease
+ OLD_ICONV = YesPlease
+ NO_MEMMEM = YesPlease
+ BASIC_CFLAGS += -I/usr/local/include
+ BASIC_LDFLAGS += -L/usr/local/lib
+ DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
+ USE_ST_TIMESPEC = YesPlease
+ ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
+ PTHREAD_LIBS = -pthread
+ NO_UINTMAX_T = YesPlease
+ NO_STRTOUMAX = YesPlease
+ endif
+ PYTHON_PATH = /usr/local/bin/python
+ HAVE_PATHS_H = YesPlease
+endif
+ifeq ($(uname_S),OpenBSD)
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ USE_ST_TIMESPEC = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ BASIC_CFLAGS += -I/usr/local/include
+ BASIC_LDFLAGS += -L/usr/local/lib
+ HAVE_PATHS_H = YesPlease
+endif
+ifeq ($(uname_S),NetBSD)
+ ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
+ NEEDS_LIBICONV = YesPlease
+ endif
+ BASIC_CFLAGS += -I/usr/pkg/include
+ BASIC_LDFLAGS += -L/usr/pkg/lib $(CC_LD_DYNPATH)/usr/pkg/lib
+ USE_ST_TIMESPEC = YesPlease
+ NO_MKSTEMPS = YesPlease
+ HAVE_PATHS_H = YesPlease
+endif
+ifeq ($(uname_S),AIX)
+ DEFAULT_PAGER = more
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_NSEC = YesPlease
+ FREAD_READS_DIRECTORIES = UnfortunatelyYes
+ INTERNAL_QSORT = UnfortunatelyYes
+ NEEDS_LIBICONV = YesPlease
+ BASIC_CFLAGS += -D_LARGE_FILES
+ ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
+ NO_PTHREADS = YesPlease
+ else
+ PTHREAD_LIBS = -lpthread
+ endif
+ ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
+ INLINE = ''
+ endif
+ GIT_TEST_CMP = cmp
+endif
+ifeq ($(uname_S),GNU)
+ # GNU/Hurd
+ NO_STRLCPY = YesPlease
+ NO_MKSTEMPS = YesPlease
+ HAVE_PATHS_H = YesPlease
+ LIBC_CONTAINS_LIBINTL = YesPlease
+endif
+ifeq ($(uname_S),IRIX)
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_MKDTEMP = YesPlease
+ # When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
+ # (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
+ # git dies with a segmentation fault when trying to access the first
+ # entry of a reflog. The conservative choice is made to always set
+ # NO_MMAP. If you suspect that your compiler is not affected by this
+ # issue, comment out the NO_MMAP statement.
+ NO_MMAP = YesPlease
+ NO_REGEX = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ SNPRINTF_RETURNS_BOGUS = YesPlease
+ SHELL_PATH = /usr/gnu/bin/bash
+ NEEDS_LIBGEN = YesPlease
+endif
+ifeq ($(uname_S),IRIX64)
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_MKDTEMP = YesPlease
+ # When compiled with the MIPSpro 7.4.4m compiler, and without pthreads
+ # (i.e. NO_PTHREADS is set), and _with_ MMAP (i.e. NO_MMAP is not set),
+ # git dies with a segmentation fault when trying to access the first
+ # entry of a reflog. The conservative choice is made to always set
+ # NO_MMAP. If you suspect that your compiler is not affected by this
+ # issue, comment out the NO_MMAP statement.
+ NO_MMAP = YesPlease
+ NO_REGEX = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ SNPRINTF_RETURNS_BOGUS = YesPlease
+ SHELL_PATH = /usr/gnu/bin/bash
+ NEEDS_LIBGEN = YesPlease
+endif
+ifeq ($(uname_S),HP-UX)
+ INLINE = __inline
+ NO_IPV6 = YesPlease
+ NO_SETENV = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_HSTRERROR = YesPlease
+ NO_SYS_SELECT_H = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ SNPRINTF_RETURNS_BOGUS = YesPlease
+ NO_NSEC = YesPlease
+ ifeq ($(uname_R),B.11.00)
+ NO_INET_NTOP = YesPlease
+ NO_INET_PTON = YesPlease
+ endif
+ ifeq ($(uname_R),B.10.20)
+ # Override HP-UX 11.x setting:
+ INLINE =
+ SOCKLEN_T = size_t
+ NO_PREAD = YesPlease
+ NO_INET_NTOP = YesPlease
+ NO_INET_PTON = YesPlease
+ endif
+ GIT_TEST_CMP = cmp
+endif
+ifeq ($(uname_S),Windows)
+ GIT_VERSION := $(GIT_VERSION).MSVC
+ pathsep = ;
+ NO_PREAD = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ NO_LIBGEN_H = YesPlease
+ NO_POLL = YesPlease
+ NO_SYMLINK_HEAD = YesPlease
+ NO_IPV6 = YesPlease
+ NO_UNIX_SOCKETS = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_STRTOK_R = YesPlease
+ NO_FNMATCH = YesPlease
+ NO_MEMMEM = YesPlease
+ # NEEDS_LIBICONV = YesPlease
+ NO_ICONV = YesPlease
+ NO_STRTOUMAX = YesPlease
+ NO_STRTOULL = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ SNPRINTF_RETURNS_BOGUS = YesPlease
+ NO_SVN_TESTS = YesPlease
+ NO_PERL_MAKEMAKER = YesPlease
+ RUNTIME_PREFIX = YesPlease
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ USE_WIN32_MMAP = YesPlease
+ # USE_NED_ALLOCATOR = YesPlease
+ UNRELIABLE_FSTAT = UnfortunatelyYes
+ OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
+ NO_REGEX = YesPlease
+ NO_CURL = YesPlease
+ NO_PYTHON = YesPlease
+ BLK_SHA1 = YesPlease
+ NO_POSIX_GOODIES = UnfortunatelyYes
+ NATIVE_CRLF = YesPlease
+ DEFAULT_HELP_FORMAT = html
+
+ CC = compat/vcbuild/scripts/clink.pl
+ AR = compat/vcbuild/scripts/lib.pl
+ CFLAGS =
+ BASIC_CFLAGS = -nologo -I. -I../zlib -Icompat/vcbuild -Icompat/vcbuild/include -DWIN32 -D_CONSOLE -DHAVE_STRING_H -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE
+ COMPAT_OBJS = compat/msvc.o compat/winansi.o \
+ compat/win32/pthread.o compat/win32/syslog.o \
+ compat/win32/dirent.o
+ COMPAT_CFLAGS = -D__USE_MINGW_ACCESS -DNOGDI -DHAVE_STRING_H -DHAVE_ALLOCA_H -Icompat -Icompat/regex -Icompat/win32 -DSTRIP_EXTENSION=\".exe\"
+ BASIC_LDFLAGS = -IGNORE:4217 -IGNORE:4049 -NOLOGO -SUBSYSTEM:CONSOLE -NODEFAULTLIB:MSVCRT.lib
+ EXTLIBS = user32.lib advapi32.lib shell32.lib wininet.lib ws2_32.lib
+ PTHREAD_LIBS =
+ lib =
+ifndef DEBUG
+ BASIC_CFLAGS += -GL -Os -MT
+ BASIC_LDFLAGS += -LTCG
+ AR += -LTCG
+else
+ BASIC_CFLAGS += -Zi -MTd
+endif
+ X = .exe
+endif
+ifeq ($(uname_S),Interix)
+ NO_INITGROUPS = YesPlease
+ NO_IPV6 = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_STRTOUMAX = YesPlease
+ NO_NSEC = YesPlease
+ NO_MKSTEMPS = YesPlease
+ ifeq ($(uname_R),3.5)
+ NO_INET_NTOP = YesPlease
+ NO_INET_PTON = YesPlease
+ NO_SOCKADDR_STORAGE = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ endif
+ ifeq ($(uname_R),5.2)
+ NO_INET_NTOP = YesPlease
+ NO_INET_PTON = YesPlease
+ NO_SOCKADDR_STORAGE = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ endif
+endif
+ifeq ($(uname_S),Minix)
+ NO_IPV6 = YesPlease
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ NEEDS_LIBGEN =
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ NEEDS_IDN_WITH_CURL = YesPlease
+ NEEDS_SSL_WITH_CURL = YesPlease
+ NEEDS_RESOLV =
+ NO_HSTRERROR = YesPlease
+ NO_MMAP = YesPlease
+ NO_CURL =
+ NO_EXPAT =
+endif
+ifeq ($(uname_S),NONSTOP_KERNEL)
+ # Needs some C99 features, "inline" is just one of them.
+ # INLINE='' would just replace one set of warnings with another and
+ # still not compile in c89 mode, due to non-const array initializations.
+ CC = cc -c99
+ # Disable all optimization, seems to result in bad code, with -O or -O2
+ # or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
+ # abends on "git push". Needs more investigation.
+ CFLAGS = -g -O0
+ # We'd want it to be here.
+ prefix = /usr/local
+ # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
+ PERL_PATH = ${prefix}/bin/perl
+ PYTHON_PATH = ${prefix}/bin/python
+
+ # As detected by './configure'.
+ # Missdetected, hence commented out, see below.
+ #NO_CURL = YesPlease
+ # Added manually, see above.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ HAVE_LIBCHARSET_H = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
+ NO_SYS_SELECT_H = UnfortunatelyYes
+ NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_HSTRERROR = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ # Currently libiconv-1.9.1.
+ OLD_ICONV = UnfortunatelyYes
+ NO_REGEX = YesPlease
+ NO_PTHREADS = UnfortunatelyYes
+
+ # Not detected (nor checked for) by './configure'.
+ # We don't have SA_RESTART on NonStop, unfortunalety.
+ COMPAT_CFLAGS += -DSA_RESTART=0
+ # Apparently needed in compat/fnmatch/fnmatch.c.
+ COMPAT_CFLAGS += -DHAVE_STRING_H=1
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ NO_PREAD = YesPlease
+ NO_MMAP = YesPlease
+ NO_POLL = YesPlease
+ NO_INTPTR_T = UnfortunatelyYes
+ # Bug report 10-120822-4477 submitted to HP NonStop development.
+ MKDIR_WO_TRAILING_SLASH = YesPlease
+ # RFE 10-120912-4693 submitted to HP NonStop development.
+ NO_SETITIMER = UnfortunatelyYes
+ SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
+ SHELL_PATH = /usr/local/bin/bash
+ # as of H06.25/J06.14, we might better use this
+ #SHELL_PATH = /usr/coreutils/bin/bash
+endif
+ifneq (,$(findstring MINGW,$(uname_S)))
+ pathsep = ;
+ NO_PREAD = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ NO_LIBGEN_H = YesPlease
+ NO_POLL = YesPlease
+ NO_SYMLINK_HEAD = YesPlease
+ NO_UNIX_SOCKETS = YesPlease
+ NO_SETENV = YesPlease
+ NO_UNSETENV = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_STRTOK_R = YesPlease
+ NO_FNMATCH = YesPlease
+ NO_MEMMEM = YesPlease
+ NEEDS_LIBICONV = YesPlease
+ OLD_ICONV = YesPlease
+ NO_STRTOUMAX = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_SVN_TESTS = YesPlease
+ NO_PERL_MAKEMAKER = YesPlease
+ RUNTIME_PREFIX = YesPlease
+ NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
+ USE_WIN32_MMAP = YesPlease
+ USE_NED_ALLOCATOR = YesPlease
+ UNRELIABLE_FSTAT = UnfortunatelyYes
+ OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
+ NO_REGEX = YesPlease
+ NO_PYTHON = YesPlease
+ BLK_SHA1 = YesPlease
+ ETAGS_TARGET = ETAGS
+ NO_INET_PTON = YesPlease
+ NO_INET_NTOP = YesPlease
+ NO_POSIX_GOODIES = UnfortunatelyYes
+ COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/win32
+ COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
+ COMPAT_OBJS += compat/mingw.o compat/winansi.o \
+ compat/win32/pthread.o compat/win32/syslog.o \
+ compat/win32/dirent.o
+ EXTLIBS += -lws2_32
+ PTHREAD_LIBS =
+ X = .exe
+ SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
+ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
+ htmldir = doc/git/html/
+ prefix =
+ INSTALL = /bin/install
+ EXTLIBS += /mingw/lib/libz.a
+ NO_R_TO_GCC_LINKER = YesPlease
+ INTERNAL_QSORT = YesPlease
+ HAVE_LIBCHARSET_H = YesPlease
+else
+ NO_CURL = YesPlease
+endif
+endif
--
1.8.1.rc3.4.gf3a2f57
^ permalink raw reply related
* Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Jeff King @ 2013-01-03 21:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20130103210541.GA11783@sigill.intra.peff.net>
On Thu, Jan 03, 2013 at 04:05:41PM -0500, Jeff King wrote:
> On Thu, Jan 03, 2013 at 03:32:22PM -0500, Jeff King wrote:
>
> > I think the usefulness is that it can be set by default for a particular
> > uname, so people on Windows can just type "make install-doc" without
> > having to care about setting anything (though to be honest, I do not
> > even know what they build by default; maybe they do build manpages).
> > Except that in the original thread:
> >
> > > http://thread.gmane.org/gmane.comp.version-control.git/207193/focus=207201
> >
> > it became clear that to do that we would also want to hoist the uname
> > automagic defaults into their own file that could be read from
> > Documentation/Makefile.
>
> IOW, this (on the current master), which I think is a nice cleanup
> regardless of this series:
>
> -- >8 --
> Subject: [PATCH] Makefile: hoist uname autodetection to config.mak.uname
Not surprising for such a large refactoring, but this has conflicts with
what's in next. Here's the patch to apply on top of the conflicted tree
you get from merging this with "next":
diff --cc Makefile
index 5e4ee47,f37fb24..0000000
--- a/Makefile
+++ b/Makefile
diff --git a/config.mak.uname b/config.mak.uname
index f9de18e..bea34f0 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -425,6 +425,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# Added manually, see above.
NEEDS_SSL_WITH_CURL = YesPlease
HAVE_LIBCHARSET_H = YesPlease
+ HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
@@ -520,3 +521,19 @@ endif
NO_CURL = YesPlease
endif
endif
+ifeq ($(uname_S),QNX)
+ COMPAT_CFLAGS += -DSA_RESTART=0
+ HAVE_STRINGS_H = YesPlease
+ NEEDS_SOCKET = YesPlease
+ NO_FNMATCH_CASEFOLD = YesPlease
+ NO_GETPAGESIZE = YesPlease
+ NO_ICONV = YesPlease
+ NO_MEMMEM = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_NSEC = YesPlease
+ NO_PTHREADS = YesPlease
+ NO_R_TO_GCC_LINKER = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_STRLCPY = YesPlease
+endif
^ permalink raw reply related
* Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Junio C Hamano @ 2013-01-03 22:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130103210731.GB11783@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Not surprising for such a large refactoring, but this has conflicts with
> what's in next. Here's the patch to apply on top of the conflicted tree
> you get from merging this with "next":
Yeah, verifying the manual fixup is a bit tricky indeed. The output from
$ git blame -C HEAD^.. -- config.mak.uname | grep '^[^^]'
shows only the first line of the resulting file, and the output from
$ git blame --reverse -C HEAD^.. -- Makefile | grep '^^'
shows only the three-line "Platform specific tweaks" comment, which
was replaced by your version in config.mak.uname, so nothing extra
was added and nothing important was lost between the two, it seems.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/2] DEFAULT_DOC_TARGET
From: Jeff King @ 2013-01-03 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nixx61c.fsf@alter.siamese.dyndns.org>
On Thu, Jan 03, 2013 at 02:20:31PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Not surprising for such a large refactoring, but this has conflicts with
> > what's in next. Here's the patch to apply on top of the conflicted tree
> > you get from merging this with "next":
>
> Yeah, verifying the manual fixup is a bit tricky indeed. The output from
>
> $ git blame -C HEAD^.. -- config.mak.uname | grep '^[^^]'
>
> shows only the first line of the resulting file, and the output from
>
> $ git blame --reverse -C HEAD^.. -- Makefile | grep '^^'
>
> shows only the three-line "Platform specific tweaks" comment, which
> was replaced by your version in config.mak.uname, so nothing extra
> was added and nothing important was lost between the two, it seems.
Yeah, it's probably easier to do than verify. I knew that my patch was a
straight copy/paste move of the big if/else block, replacing it with the
include. So the obvious resolution is to mechanically move the "theirs"
block from next in the same way. And then the resulting diff shows the
fixup (which you can verify does not do anything fancy).
It's really the same logic that merge-recursive uses for full-file
renames, except that git is not smart enough to figure out that it was a
500-line block that moved, not the whole file. It comes up rarely enough
that it is probably not worth trying to teach the merge machinery about
code block movement. But it would be cool. :)
-Peff
^ permalink raw reply
* Re: [BUG] two-way read-tree can write null sha1s into index
From: Junio C Hamano @ 2013-01-03 22:33 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git
In-Reply-To: <20130103203606.GA8188@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Oh, I agree it's insane to try to carry through unmerged entries. I'm
> just concerned that not all code paths are careful enough to check.
I would actually be surprised if some code path do assume somebody
might give them an index with conflicting entries in it and guard
against it. We have been coding under the "index must exactly match
the second tree when three-way unpack_trees() begin" requirement
since day one. An conflicted entry will appear as "index and HEAD
not matching" and will cause reject_merge() early in threeway_merge()
anyway, no?
^ permalink raw reply
* Re: [PATCH v3] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2013-01-03 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfw2j2vlp.fsf@alter.siamese.dyndns.org>
> The updated code structure is much nicer than the previous round,
> but I am somewhat puzzled how return value of remove_dirs() and
> &gone relate to each other. Surely when gone is set to zero,
> remove_dirs() is reporting that the directory it was asked to remove
> recursively did not go away, so it must report failure, no? Having
> the &gone flag looks redundant and checking for gone in some places
> while checking for the return value for others feels like an
> invitation for future bugs.
The return value of remove_dirs() has an overall effect on the exit
code of git-clean, and &gone indicates whether the directory we asked
remove_dirs() to delete was actually removed. If all goes well in
remove_dirs() the return code is 0 and gone flag is 1. If file or
subdirectory delete fails return code is 1 and the gone flag is set to
0. The special case is when remove_dirs() is asked to remove an
untracked git repo that should be ignored. In this case remove_dirs()
is not going to remove the directory so the gone flag is set to zero
but it is not an error so the return value will be set to zero too.
> Also the remove_dirs() function seems to replace the use of
> remove_dir_recurse() from dir.c by copying large part of it, with
> error message sprinkled. Does remove_dir_recurse() still get used
> by other codepaths? If so, do the remaining callsites benefit from
> using this updated version?
In dir.c the remove_dir_recurse() is a private function that is called
by the public remove_dir_recursively() wrapper function. The
remove_dir_recursively() function is called from the following places:
builtin/clone.c:387:
builtin/clone.c:392:
builtin/rm.c:349:
notes-merge.c:771:
refs.c:1527:
sequencer.c:27:
transport.c:247:
transport.c:393:
The messages that remove_dirs() prints out are very specific to
git-clean and they are not really relevant in the above places where
remove_dir_recursively() is called from. Also, the remove logic for
files is slightly different in remove_dirs() when it comes to handling
a failed file delete. While remove_dirs() continues removing other
files in the same directory upon failure, remove_dir_recurse() will
stop at the first error. So perhaps having the remove_dirs() in
builtin/clean.c is OK.
^ permalink raw reply
* Re: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
From: Martin Fick @ 2013-01-03 23:52 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Shawn Pearce, Jeff King, git, Junio C Hamano
In-Reply-To: <201212310330.53835.mfick@codeaurora.org>
Any thoughts on this idea? Is it flawed? I am trying to
write it up in a more formal generalized manner and was
hoping to get at least one "it seems sane" before I do.
Thanks,
-Martin
On Monday, December 31, 2012 03:30:53 am Martin Fick wrote:
> On Thursday, December 27, 2012 04:11:51 pm Martin Fick
wrote:
> > It concerns me that git uses any locking at all, even
> > for refs since it has the potential to leave around
> > stale locks.
> > ...
> > [a previous not so great attempt to fix this]
> > ...
>
> I may have finally figured out a working loose ref update
> mechanism which I think can avoid stale locks.
> Unfortunately it requires atomic directory renames and
> universally unique identifiers (uuids). These may be
> no-go criteria? But I figure it is worth at least
> exploring this idea because of the potential benefits?
>
> The general approach is to setup a transaction and either
> commit or abort it. A transaction can be setup by
> renaming an appropriately setup directory to the
> "ref.lock" name. If the rename succeeds, the transaction
> is begun. Any actor can abort the transaction (up until
> it is committed) by simply deleting the "ref.lock"
> directory, so it is not at risk of going stale. However,
> once the actor who sets up the transaction commits it,
> deleting the "ref.lock" directory simply aids in cleaning
> it up for the next transaction (instead of aborting it).
>
> One important piece of the transaction is the use of
> uuids. The uuids provide a mechanism to tie the atomic
> commit pieces to the transactions and thus to prevent
> long sleeping process from inadvertently performing
> actions which could be out of date when they wake finally
> up. In each case, the atomic commit piece is the
> renaming of a file. For the create and update pieces, a
> file is renamed from the "ref.lock" dir to the "ref" file
> resulting in an update to the sha for the ref. However,
> in the delete case, the "ref" file is instead renamed to
> end up in the "ref.lock" directory resulting in a delete
> of the ref. This scheme does not affect the way refs are
> read today,
>
> To prepare for a transaction, an actor first generates a
> uuid (an exercise I will delay for now). Next, a tmp
> directory named after the uuid is generated in the parent
> directory for the ref to be updated, perhaps something
> like: ".lock_uuid". In this directory is places either a
> file or a directory named after the uuid, something like:
> ".lock_uuid/,uuid". In the case of a create or an
> update, the new sha is written to this file. In the case
> of a delete, it is a directory.
>
> Once the tmp directory is setup, the initiating actor
> attempts to start the transaction by renaming the tmp
> directory to "ref.lock". If the rename fails, the update
> fails. If the rename succeeds, the actor can then attempt
> to commit the transaction (before another actor aborts
> it).
>
> In the case of a create, the actor verifies that "ref"
> does not currently exist, and then renames the now named
> "ref.lock/uuid" file to "ref". On success, the ref was
> created.
>
> In the case of an update, the actor verifies that "ref"
> currently contains the old sha, and then also renames the
> now named "ref.lock/uuid" file to "ref". On success, the
> ref was updated.
>
> In the case of a delete, the actor may verify that "ref"
> currently contains the sha to "prune" if it needs to, and
> then renames the "ref" file to "ref.lock/uuid/delete". On
> success, the ref was deleted.
>
> Whether successful or not, the actor may now simply delete
> the "ref.lock" directory, clearing the way for a new
> transaction. Any other actor may delete this directory at
> any time also, likely either on conflict (if they are
> attempting to initiate a transaction), or after a grace
> period just to cleanup the FS. Any actor may also safely
> cleanup the tmp directories, preferably also after a grace
> period.
>
> One neat part about this scheme is that I believe it would
> be backwards compatible with the current locking
> mechanism since the transaction directory will simply
> appear to be a lock to older clients. And the old lock
> file should continue to lock out these newer
> transactions.
>
> Due to this backwards compatibility, I believe that this
> could be incrementally employed today without affecting
> very much. It could be deployed in place of any updates
> which only hold ref.locks to update the loose ref. So
> for example I think it could replace step 4a below from
> Michael Haggerty's description of today's loose ref
> pruning during
>
> ref packing:
> > * Pack references:
> ...
>
> > 4. prune_refs(): for each ref in the ref_to_prune list,
> >
> > call prune_ref():
> > a. Lock the reference using lock_ref_sha1(),
> > verifying that the recorded SHA1 is still valid. If
> > it is, unlink the loose reference file then free
> > the lock; otherwise leave the loose reference file
> > untouched.
>
> I think it would also therefore be able to replace the
> loose ref locking in Michael's new ref-packing scheme as
> well as the locking in Michael's new ref deletion scheme
> (again steps
>
> 4):
> > * Delete reference foo:
> ...
>
> > 4. Delete loose ref for "foo":
> > a. Acquire the lock $GIT_DIR/refs/heads/foo.lock
> >
> > b. Unlink $GIT_DIR/refs/heads/foo if it is
> > unchanged.
> >
> > If it is changed, leave it untouched. If it is
> > deleted,
> >
> > that is OK too.
> >
> > c. Release lock $GIT_DIR/refs/heads/foo.lock
>
> ...
>
> > * Pack references:
> ...
>
> > 4. prune_refs(): for each ref in the ref_to_prune
> > list,
> >
> > call prune_ref():
> > a. Lock the loose reference using lock_ref_sha1(),
> >
> > verifying that the recorded SHA1 is still valid
> >
> > b. If it is, unlink the loose reference file
> >
> > (otherwise, leave it untouched)
> >
> > c. Release the lock on the loose reference
>
> To be honest, I suspect I missed something obvious because
> this seems almost too simple to work. I am ashamed that
> it took me so long to come up with (of course, I will be
> even more ashamed :( when it is shown to be flawed!)
> This scheme also feels extensible. if there are no
> obvious flaws in it, I will try to post solutions for ref
> packing and for multiple repository/ref transactions also
> soon.
>
> I welcome any comments/criticisms,
>
> -Martin
> --
> To unsubscribe from this list: send the line "unsubscribe
> git" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ 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