* RE: Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
From: Pyeron, Jason J CTR (US) @ 2013-01-04 17:52 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <201301031652.44982.mfick@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 7382 bytes --]
> From: Martin Fick
> Sent: Thursday, January 03, 2013 6:53 PM
>
> 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.
If you are assuming that atomic renames, etc. are available, then you should identify a test case and a degrade operation path when it is not available.
>
> 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
> --
> 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
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2013, #02; Thu, 3)
From: Adam Spiers @ 2013-01-04 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmwwqvzy4.fsf@alter.siamese.dyndns.org>
On Thu, Jan 3, 2013 at 7:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * 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.
Sounds good to me. As already mentioned, I have the v4 series ready
and it addresses all issues already voiced in v3, but I have postponed
submitting it as per your request. Please let me know when and how to
proceed, thanks!
^ permalink raw reply
* Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases
From: Johannes Sixt @ 2013-01-04 16:55 UTC (permalink / raw)
To: Jeff King; +Cc: git, Bart Trojanowski
In-Reply-To: <20130104124756.GA402@sigill.intra.peff.net>
Am 04.01.2013 13:47, schrieb Jeff King:
> I have two reservations with this patch:
>
> 1. We are ignoring SIGPIPE all the time. For an alias that is calling
> "log", that is fine. But if pack-objects dies on the server side,
> seeing that it died from SIGPIPE is useful data, and we are
> squelching that. Maybe callers of run-command should have to pass
> an "ignore SIGPIPE" flag?
I am of two minds. On the one hand, losing useful debugging information
is not something we should do lightly. On the other hand, the message is
really noise most of the time, even on servers: when pack-objects dies
on the server side, it is most likely due to a connection that breaks
(voluntarily or involuntarily) half-way during a transfer, and is
presumably a frequent event, and as such not worth noting most of the time.
> 2. The die_errno in handle_alias is definitely wrong. Even if we want
> to print a message for signal death, showing errno is bogus unless
> the return value was -1. But is it the right thing to just pass the
> negative value straight to exit()? It works, but it is depending on
> the fact that (unsigned char)(ret & 0xff) behaves in a certain way
> (i.e., that we are on a twos-complement platform, and -13 becomes
> 141). That is not strictly portable, but it is probably fine in
> practice. I'd worry more about exit() doing something weird on
> Windows.
It did something weird on Windows until we added this line to
compat/mingw.h:
#define exit(code) exit((code) & 0xff)
-- Hannes
^ permalink raw reply
* [PATCH] attr: allow pattern escape using backslashes
From: Nguyễn Thái Ngọc Duy @ 2013-01-04 14:46 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Patterns in .gitattributes are separated by whitespaces, which makes
it impossible to specify exact spaces in the pattern. '?' can be used
as a workaround, but it matches other characters too. This patch makes
a space following a backslash part of the pattern, not a pattern
separator.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
A similar patch was posted twice (during freeze time iirc). I think
this is a good change, so I will keep reposting until someone turns
it down.
We could use wildmatch for parsing here, which would support patterns
like "Hello[ ]world". But that's not going to happen until wildmatch
graduates and somebody brings it up again.
Documentation/gitattributes.txt | 6 +++---
attr.c | 8 +++++++-
t/t0003-attributes.sh | 5 +++++
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 2698f63..113b1f8 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -20,9 +20,9 @@ Each line in `gitattributes` file is of form:
pattern attr1 attr2 ...
-That is, a pattern followed by an attributes list,
-separated by whitespaces. When the pattern matches the
-path in question, the attributes listed on the line are given to
+That is, a pattern followed by an attributes list, separated by
+whitespaces that are not quoted by a backslash. When the pattern matches
+the path in question, the attributes listed on the line are given to
the path.
Each attribute can be in one of these states for a given path:
diff --git a/attr.c b/attr.c
index 097ae87..776f34e 100644
--- a/attr.c
+++ b/attr.c
@@ -209,7 +209,13 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
if (!*cp || *cp == '#')
return NULL;
name = cp;
- namelen = strcspn(name, blank);
+ namelen = 0;
+ while (name[namelen] != '\0' && !strchr(blank, name[namelen])) {
+ if (name[namelen] == '\\' && name[namelen + 1] != '\0')
+ namelen += 2;
+ else
+ namelen++;
+ }
if (strlen(ATTRIBUTE_MACRO_PREFIX) < namelen &&
!prefixcmp(name, ATTRIBUTE_MACRO_PREFIX)) {
if (!macro_ok) {
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 807b8b8..6a5d8ab 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -24,6 +24,7 @@ test_expect_success 'setup' '
echo "offon -test test"
echo "no notest"
echo "A/e/F test=A/e/F"
+ echo "A\\ b test=space"
) >.gitattributes &&
(
echo "g test=a/g" &&
@@ -196,6 +197,10 @@ test_expect_success 'root subdir attribute test' '
attr_check subdir/a/i unspecified
'
+test_expect_success 'quoting in pattern' '
+ attr_check "A b" space
+'
+
test_expect_success 'negative patterns' '
echo "!f test=bar" >.gitattributes &&
test_must_fail git check-attr test -- f
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* [RFC/PATCH] avoid SIGPIPE warnings for aliases
From: Jeff King @ 2013-01-04 12:47 UTC (permalink / raw)
To: git; +Cc: Bart Trojanowski
When git executes an alias that specifies an external
command, it will complain if the alias dies due to a signal.
This is usually a good thing, as signal deaths are
unexpected. However, SIGPIPE is not unexpected for many
commands which produce a lot of output; it is intended that
the user closing the pager would kill them them via SIGPIPE.
As a result, the user might see annoying messages in a
scenario like this:
$ cat ~/.gitconfig
[alias]
lgbase = log --some-options
lg = !git lgbase --more-options
lg2 = !git lgbase --other-options
$ git lg -p
[user hits 'q' to exit pager]
error: git lgbase --more-options died of signal 13
fatal: While expanding alias 'lg': 'git lgbase --more-options': Success
Many users won't see this, because we execute the external
command with the shell, and a POSIX shell will silently
rewrite the signal-death exit code into 128+signal, and we
will treat it like a normal exit code. However, this does
not always happen:
1. If the sub-command does not have shell metacharacters,
we will skip the shell and exec it directly, getting
the signal code.
2. Some shells do not do this rewriting; for example,
setting SHELL_PATH set to zsh will reveal this problem.
This patch squelches the message, and let's git exit
silently (with the same exit code that a shell would use in
case of a signal).
The first line of the message comes from run-command's
wait_or_whine. To silence that message, we remain quiet
anytime we see SIGPIPE.
The second line comes from handle_alias itself. It calls
die_errno whenever run_command returns a negative value.
However, only -1 indicates a syscall error where errno has
something useful (note that it says the useless "success"
above). Instead, we treat negative returns from run_command
(except for -1) as a normal code to be passed to exit.
Signed-off-by: Jeff King <peff@peff.net>
---
I have two reservations with this patch:
1. We are ignoring SIGPIPE all the time. For an alias that is calling
"log", that is fine. But if pack-objects dies on the server side,
seeing that it died from SIGPIPE is useful data, and we are
squelching that. Maybe callers of run-command should have to pass
an "ignore SIGPIPE" flag?
2. The die_errno in handle_alias is definitely wrong. Even if we want
to print a message for signal death, showing errno is bogus unless
the return value was -1. But is it the right thing to just pass the
negative value straight to exit()? It works, but it is depending on
the fact that (unsigned char)(ret & 0xff) behaves in a certain way
(i.e., that we are on a twos-complement platform, and -13 becomes
141). That is not strictly portable, but it is probably fine in
practice. I'd worry more about exit() doing something weird on
Windows.
git.c | 2 +-
run-command.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index d33f9b3..07edb8a 100644
--- a/git.c
+++ b/git.c
@@ -175,7 +175,7 @@ static int handle_alias(int *argcp, const char ***argv)
alias_argv[argc] = NULL;
ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
- if (ret >= 0) /* normal exit */
+ if (ret != -1) /* normal exit */
exit(ret);
die_errno("While expanding alias '%s': '%s'",
diff --git a/run-command.c b/run-command.c
index 757f263..01a4c9b 100644
--- a/run-command.c
+++ b/run-command.c
@@ -242,7 +242,7 @@ static int wait_or_whine(pid_t pid, const char *argv0)
error("waitpid is confused (%s)", argv0);
} else if (WIFSIGNALED(status)) {
code = WTERMSIG(status);
- if (code != SIGINT && code != SIGQUIT)
+ if (code != SIGINT && code != SIGQUIT && code != SIGPIPE)
error("%s died of signal %d", argv0, code);
/*
* This return value is chosen so that code & 0xff
--
1.8.1.rc1.16.g6d46841
^ permalink raw reply related
* Re: [PATCH 2/2] format-patch: give --reroll-count a short synonym -v
From: Junio C Hamano @ 2013-01-04 1:28 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
In-Reply-To: <7vpq1lvmtz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>>> +test_expect_success 'reroll count (-v)' '
>>> + rm -fr patches &&
>>> + git format-patch -o patches --cover-letter -v 4 master..side >list
>>> &&
>>
>> Shouldn't this be using the sticked form -v4 as described in the
>> commit message and gitcli?
>
> I personally do not care too deeply either way.
Actually, I do care. And in this case both should work.
Separating argument from the option
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can write the mandatory option parameter to an option as a separate
word on the command line. That means that all the following uses work:
----------------------------
$ git foo --long-opt=Arg
$ git foo --long-opt Arg
$ git foo -oArg
$ git foo -o Arg
----------------------------
As "reroll-count" must always be followed by nth (in other words, it
is not optional), the following does not apply.
However, this is *NOT* allowed for switches with an optional value, where the
'sticked' form must be used:
^ permalink raw reply
* Re: [PATCH 2/2] format-patch: give --reroll-count a short synonym -v
From: Philip Oakley @ 2013-01-03 23:21 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <1357166525-12188-2-git-send-email-gitster@pobox.com>
From: "Junio C Hamano" <gitster@pobox.com> Sent: Wednesday, January 02,
2013 10:42 PM
> Accept "-v" as a synonym to "--reroll-count", so that users can say
> "git format-patch -v4 master", instead of having to fully spell it
> out as "git format-patch --reroll-count=4 master".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * As I do not think of a reason why users would want to tell the
> command to be "verbose", I think it may be OK to squat on the
> short and sweet single letter option, but I do not mind dropping
> it.
>
> Documentation/git-format-patch.txt | 3 ++-
> builtin/log.c | 2 +-
> t/t4014-format-patch.sh | 8 ++++++++
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-format-patch.txt
> b/Documentation/git-format-patch.txt
> index 736d8bf..ae3212e 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -18,7 +18,7 @@ SYNOPSIS
> [--start-number <n>] [--numbered-files]
> [--in-reply-to=Message-Id] [--suffix=.<sfx>]
> [--ignore-if-in-upstream]
> - [--subject-prefix=Subject-Prefix] [--reroll-count <n>]
> + [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>]
> [--to=<email>] [--cc=<email>]
> [--cover-letter] [--quiet]
> [<common diff options>]
> @@ -166,6 +166,7 @@ will want to ensure that threading is disabled for
> `git send-email`.
> allows for useful naming of a patch series, and can be
> combined with the `--numbered` option.
>
> +-v <n>::
> --reroll-count=<n>::
> Mark the series as the <n>-th iteration of the topic. The
> output filenames have `v<n>` pretended to them, and the
> diff --git a/builtin/log.c b/builtin/log.c
> index e101498..08e8a9d 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -1081,7 +1081,7 @@ int cmd_format_patch(int argc, const char
> **argv, const char *prefix)
> N_("use <sfx> instead of '.patch'")),
> OPT_INTEGER(0, "start-number", &start_number,
> N_("start numbering patches at <n> instead of 1")),
> - OPT_INTEGER(0, "reroll-count", &reroll_count,
> + OPT_INTEGER('v', "reroll-count", &reroll_count,
> N_("mark the series as Nth re-roll")),
> { OPTION_CALLBACK, 0, "subject-prefix", &rev, N_("prefix"),
> N_("Use [<prefix>] instead of [PATCH]"),
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> index 0ff9958..03b8e51 100755
> --- a/t/t4014-format-patch.sh
> +++ b/t/t4014-format-patch.sh
> @@ -245,6 +245,14 @@ test_expect_success 'reroll count' '
> ! grep -v "^Subject: \[PATCH v4 [0-3]/3\] " subjects
> '
>
> +test_expect_success 'reroll count (-v)' '
> + rm -fr patches &&
> + git format-patch -o patches --cover-letter -v 4 master..side >list
> &&
Shouldn't this be using the sticked form -v4 as described in the commit
message and gitcli?
Or is this being too picky?
> + ! grep -v "^patches/v4-000[0-3]-" list &&
> + sed -n -e "/^Subject: /p" $(cat list) >subjects &&
> + ! grep -v "^Subject: \[PATCH v4 [0-3]/3\] " subjects
> +'
> +
> check_threading () {
> expect="$1" &&
> shift &&
> --
> 1.8.0.9.g5e84801
>
^ permalink raw reply
* Fwd: Git hangs after resolving deltas when using NTLM proxy on Windows
From: Adam Baxter @ 2013-01-04 0:28 UTC (permalink / raw)
To: git
In-Reply-To: <CAChFQ9QYt6ncpD2zwQu+ziD98J+aOd4TWAJR9dLdDs69bskZ2g@mail.gmail.com>
Hi,
Git is authenticating to my corporate proxy correctly, but is hanging
after "resolving deltas".
This is when cloning via HTTPS.
Apologies for linking to a Gist, but I'm having difficulty getting
this list to accept a log file attachment.
See https://gist.github.com/4448684 for the curl log.
Regards,
Adam
^ permalink raw reply
* Re: [PATCH 2/2] format-patch: give --reroll-count a short synonym -v
From: Junio C Hamano @ 2013-01-04 0:00 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
In-Reply-To: <A6A2DEC8F88743B88AA03DC5BD8547B7@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
>> +test_expect_success 'reroll count (-v)' '
>> + rm -fr patches &&
>> + git format-patch -o patches --cover-letter -v 4 master..side >list
>> &&
>
> Shouldn't this be using the sticked form -v4 as described in the
> commit message and gitcli?
I personally do not care too deeply either way.
Both styles seem to work, and if/when we break parse-options API
implementation, this test will break and we will notice, which might
be an added plus ;-)
^ permalink raw reply
* Re: Pretty pictures of git merge conflicts
From: John Szakmeister @ 2013-01-03 23:53 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git discussion list
In-Reply-To: <50E5B3BE.7080500@alum.mit.edu>
On Thu, Jan 3, 2013 at 11:37 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> 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.
Interesting work Michael! Interestingly, I've taken such an approach
in a few real life situations. It was a real help it trying to get
the conflicts resolved, so I'm eager to see the tools you come up
with!
-John
^ 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
* 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: [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 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: [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 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: 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
* 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: 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
* 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
* [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: [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
* 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: [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: [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
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