* [PATCH 1/2] config: correct core.loosecompression documentation
From: Brian Downing @ 2007-11-19 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jonas Juselius, git, Brian Downing
In-Reply-To: <alpine.LFD.0.99999.0711191139240.19105@xanadu.home>
* core.loosecompression stated that the default was "0 (best speed)",
when in fact 0 is "no compression", and the default is Z_BEST_SPEED,
which is 1.
Signed-off-by: Brian Downing <bdowning@lavos.net>
---
Documentation/config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7ee97df..9565652 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -232,7 +232,7 @@ core.loosecompression::
are not in a pack file. -1 is the zlib default. 0 means no
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest. If not set, defaults to core.compression. If that is
- not set, defaults to 0 (best speed).
+ not set, defaults to 1 (best speed).
core.packedGitWindowSize::
Number of bytes of a pack file to map into memory in a
--
1.5.3.5.1824.g5f389
^ permalink raw reply related
* [PATCH 2/2] config: clarify compression defaults
From: Brian Downing @ 2007-11-19 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jonas Juselius, git, Brian Downing
In-Reply-To: <1195491531-2701-1-git-send-email-bdowning@lavos.net>
* Clarify that core.compression provides a system-wide default to
other compression parameters.
* Explain that the default for pack.compression, -1, is "a default
compromise between speed and compression (currently equivalent
to level 6)" according to zlib.h.
Signed-off-by: Brian Downing <bdowning@lavos.net>
---
Documentation/config.txt | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9565652..5d1eb5d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -226,6 +226,8 @@ core.compression::
An integer -1..9, indicating a default compression level.
-1 is the zlib default. 0 means no compression,
and 1..9 are various speed/size tradeoffs, 9 being slowest.
+ If set, this provides a default to other compression variables,
+ such as 'core.loosecompression' and 'pack.compression'.
core.loosecompression::
An integer -1..9, indicating the compression level for objects that
@@ -622,7 +624,9 @@ pack.compression::
in a pack file. -1 is the zlib default. 0 means no
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest. If not set, defaults to core.compression. If that is
- not set, defaults to -1.
+ not set, defaults to -1, the zlib default, which is "a default
+ compromise between speed and compression (currently equivalent
+ to level 6)."
pack.deltaCacheSize::
The maximum memory in bytes used for caching deltas in
--
1.5.3.5.1824.g5f389
^ permalink raw reply related
* Re: Git in a Nutshell guide
From: Matthieu Moy @ 2007-11-19 17:05 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Lars Hjemli, Jonas Juselius, git
In-Reply-To: <E983072E-E9FD-499E-A418-B630A275C4F3@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> git reset --hard HEAD~42 and then git reset --hard A.
And if you don't "remember" A, the reflog is here for you.
$ git reflog show HEAD
$ git reset --hard HEAD@{42} # not "the 42th ancestor"
# but "where HEAD was 42 moves ago".
By default, the reflog will expire after IIRC, 3 months, and git-prune
will not prune the objects while they are reachable.
So, it's even safer than you say ;-).
--
Matthieu
^ permalink raw reply
* Re: [PATCH 2/2] config: clarify compression defaults
From: Nicolas Pitre @ 2007-11-19 17:30 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, Jonas Juselius, git
In-Reply-To: <1195491531-2701-2-git-send-email-bdowning@lavos.net>
On Mon, 19 Nov 2007, Brian Downing wrote:
> * Clarify that core.compression provides a system-wide default to
> other compression parameters.
>
> * Explain that the default for pack.compression, -1, is "a default
> compromise between speed and compression (currently equivalent
> to level 6)" according to zlib.h.
>
> Signed-off-by: Brian Downing <bdowning@lavos.net>
Looks fine to me.
Nicolas
^ permalink raw reply
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Jakub Narebski @ 2007-11-19 17:43 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0711190515x3f58748bm224366ddb292755d@mail.gmail.com>
On Mon, 19 November 2007, Catalin Marinas wrote:
> On 19/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>> Catalin Marinas wrote:
>>>
>>> Have you tried the latest StGIT snapshot? We added support for this
>>> and it will be available in 0.14 (to be released pretty soon).
>>
>> Would it work with Python 2.4.3? Yes, I know I should upgrade my
>> Linux distribution (I use now Aurox 11.1, which is based on Fedora
>> Core 4)...
>
> Yes, it works with Python 2.4. We deprecated the Python 2.3 support.
I was worried that it would require Python 2.5 (IIRC some stgit RPM
had it in requires)
By the way, does StGIT write something meaningful by default in reflog
messages? Because now my reflog looks like this:
2162:[autoconf@git]# git reflog
407d6dc... HEAD@{0}:
5a46eb5... HEAD@{1}:
[...]
ea55960... HEAD@{15}:
8f5d6b4... HEAD@{16}:
15bb3f6... HEAD@{17}: checkout: moving from master to autoconf
8aff795... HEAD@{18}: pull origin: Merge made by recursive.
It would be really nice if StGIT wrote something meaningfull when
updating ref, like "stg refresh: <something>", or "stg rebase: <sth>"...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: ! [rejected] master -> master (non-fast forward)
From: Catalin Marinas @ 2007-11-19 17:47 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <9e4733910711181042x123e99efjad38486654db17e2@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> wrote:
> On 11/18/07, Junio C Hamano <gitster@pobox.com> wrote:
>> "Jon Smirl" <jonsmirl@gmail.com> writes:
>>
>> > What's causing this? I'm using stgit on the master branch.
[...]
>> pushed "A" to the remote's 'master', then built this history:
>>
>> o---o---A
>> /
>> ---o---o---o---o---A'
>>
>> by rewinding and rebuilding, and the tip of the branch now
>> points at A', which you tried to push to the remote.
>
> stgit must be doing this when I rebase. It pops all of it's patches,
> moves to head of linus/master and then rebases them.
[...]
> What is the right way to share repositories using stgit? I have a set
> of patches which I am working on for kernel inclusion. I have them
> applied as a stgit stack on top of linus/master. I need to share this
> patch stack with other developers. These developers may want to change
> one of my patches. Right now they are emailing me deltas and I apply
> them to the appropriate stgit patch. I have seventeen patches in my
> stack currently.
StGIT is meant for keeping a clean history but with the big
disadvantage that this history is volatile.
A solution is for the other developers to use StGIT or just git-rebase
so that they always have the same base (volatile) history and keep
their patches on top of yours.
A 2nd approach is to use topic branches rather than StGIT patches but
you might lose some flexibility.
Yet another approach (which I used) is to keep a public branch (can be
maintained by StGIT) where the history doesn't change and a devel
volatile branch. When I modify some patches and they are ready for
publishing, switch to the public branch and cherry-pick them (stg
pick) from the devel branch. Because this is done with a three-way
merge in StGIT, you will only get the new changes rather than the full
patch. You need to change the patch message (as it is that of the
original patch) to describe the specific changes and run 'stg refresh
&& stg commit' to store it into the immutable history (well, there is
an 'uncommit' command as well if something goes wrong).
--
Catalin
^ permalink raw reply
* [PATCH] Fix "identifier redeclared" compilation error with SUN cc
From: Guido Ostkamp @ 2007-11-19 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, raa.lkml, git, git
In-Reply-To: <7vd4ua3hww.fsf@gitster.siamese.dyndns.org>
Hello Junio,
On Thu, 15 Nov 2007, Junio C Hamano wrote:
> As I suspect there are other compilers that do not implement flexible
> array members (so you cannot use "member[]") nor older gcc extension of
> zero sized member (so you cannot use "member[0]" either), this checking
> specifically for Sun is too narrow.
>
> On the other hand, as you said, this is too broad, because not everybody
> may be using the SUN compiler on Sun, nor the version that does not
> understand flexible array members.
>
> But being broad should always be safer, albeit a bit wasteful.
>
> How about doing it this way?
it looks ok on Solaris. I assembled the following patch from your posting,
could you please include it?
Signed-off-by: Guido Ostkamp <git@ostkamp.fastmail.fm>
---
git-compat-util.h | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 276a437..97759fd 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -4,11 +4,20 @@
#define _FILE_OFFSET_BITS 64
#ifndef FLEX_ARRAY
-#if defined(__GNUC__) && (__GNUC__ < 3)
+#if defined(__GNUC__)
+#if (__GNUC__ < 3)
#define FLEX_ARRAY 0
#else
#define FLEX_ARRAY /* empty */
#endif
+#else
+/* more cases we know we can use 0 or empty can come here */
+#endif
+#endif
+
+/* if still undefined, default to the safe, old fashioned way */
+#ifndef FLEX_ARRAY
+#define FLEX_ARRAY 1
#endif
#define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
--
1.5.3.6.728.gea559
^ permalink raw reply related
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Catalin Marinas @ 2007-11-19 17:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711191843.43247.jnareb@gmail.com>
On 19/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
> By the way, does StGIT write something meaningful by default in reflog
> messages? Because now my reflog looks like this:
No, it leaves it up to GIT to write whatever it finds appropriate.
> It would be really nice if StGIT wrote something meaningfull when
> updating ref, like "stg refresh: <something>", or "stg rebase: <sth>"...
There is the 'stg log [<patch>]' command which shows the changes to a
specific patch. You can run it with -d (for the diff) or -g (to invoke
gitk).
--
Catalin
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Benoit Sigoure @ 2007-11-19 18:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jonas Juselius, git
In-Reply-To: <8c5c35580711190904v5975e81k3d515dc44fee9c21@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On Nov 19, 2007, at 6:04 PM, Lars Hjemli wrote:
> On Nov 19, 2007 5:57 PM, Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
>> Understanding this is very important because ``error humanum est'',
>> and people happen to screw up their hard work and they don't realize
>> that they can go back without even knowing what the hell the reflog
>> is or how to use it (I personally don't know -- but I'd like to, give
>> me pointers please :D).
>
> You can simply try 'git reflog', and then 'man git-reflog' ;-)
Did you only read the man? It doesn't explain how to use the reflog
or I must have a very hard time understanding it. I don't know where
the HEAD@{N} syntax is documented, but surely not in man git-reflog.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Git in a Nutshell guide
From: J. Bruce Fields @ 2007-11-19 18:13 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Lars Hjemli, Jonas Juselius, git
In-Reply-To: <25CF3422-A236-46CE-B243-3F01117B7743@lrde.epita.fr>
On Mon, Nov 19, 2007 at 07:10:07PM +0100, Benoit Sigoure wrote:
> On Nov 19, 2007, at 6:04 PM, Lars Hjemli wrote:
>
>> On Nov 19, 2007 5:57 PM, Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
>>> Understanding this is very important because ``error humanum est'',
>>> and people happen to screw up their hard work and they don't realize
>>> that they can go back without even knowing what the hell the reflog
>>> is or how to use it (I personally don't know -- but I'd like to, give
>>> me pointers please :D).
>>
>> You can simply try 'git reflog', and then 'man git-reflog' ;-)
>
> Did you only read the man? It doesn't explain how to use the reflog or I
> must have a very hard time understanding it. I don't know where the
> HEAD@{N} syntax is documented, but surely not in man git-reflog.
My copy at least has this paragraph:
The subcommand "show" (which is also the default, in the absence of any
subcommands) will take all the normal log options, and show the log of
HEAD, which will cover all recent actions, including branch switches.
It is basically an alias for git log -g --abbrev-commit
--pretty=oneline, see git-log(1).
But, yeah, HEAD@{N} isn't documented there or in git-log(1), it's in
git-rev-parse(1). I agree that the git-reflog manpage should at least
reference all of this, as it's the obvious first place people will go to learn
about reflogs....
--b.
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Matthieu Moy @ 2007-11-19 18:13 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Lars Hjemli, Jonas Juselius, git
In-Reply-To: <25CF3422-A236-46CE-B243-3F01117B7743@lrde.epita.fr>
Benoit Sigoure <tsuna@lrde.epita.fr> writes:
> Did you only read the man? It doesn't explain how to use the reflog
> or I must have a very hard time understanding it. I don't know where
> the HEAD@{N} syntax is documented, but surely not in man git-reflog.
http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html
I'll post a patch adding a link to that in the reflog man page.
--
Matthieu
^ permalink raw reply
* Re: StGIT 0.13 recognizes but not list packed StGIT controlled branches
From: Jakub Narebski @ 2007-11-19 18:26 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0711190951u412b2c1apf6d7d48abdd59c07@mail.gmail.com>
Catalin Marinas wrote:
> On 19/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> By the way, does StGIT write something meaningful by default in reflog
>> messages? Because now my reflog looks like this:
>
> No, it leaves it up to GIT to write whatever it finds appropriate.
But StGIT uses plumbing (or in the future perhaps PyGIT library).
And plumbing does not write by itself reflog messages. It is left
for porcelain (and StGIT being patch management interface is
porcelain) to provide reflog message in GIT_REFLOG_ACTION.
>> It would be really nice if StGIT wrote something meaningfull when
>> updating ref, like "stg refresh: <something>", or "stg rebase: <sth>"...
>
> There is the 'stg log [<patch>]' command which shows the changes to a
> specific patch. You can run it with -d (for the diff) or -g (to invoke
> gitk).
If I remember correctly StGIT is made to be more friendly to and with
core-git. Providing reflog messages for "git reflog" / "git log -g"
would be nice.
Besides 'stg log [<patch>]' is a bit orthogonal: it describes history
of a patch, and I want history of HEAD or of branch head (with things
like refresh, new (!), goto, float / sink, rebase (!)).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] builtin-commit: Fix git-commit honoring status.color
From: Ping Yin @ 2007-11-19 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejenuy4i.fsf@gitster.siamese.dyndns.org>
>
> Although I admit I do not care much about the "status color", I
> suspect this patch is not quite right.
>
> When prepare_log_message() returns "no committable changes" and
> we are not in merge, the calling cmd_commit() does another
> run_status() to show the status of the index and the work tree
> to the stdout, and at that point, we _do_ want to honor the
> configuration setting you are discarding with this assignment.
>
You're right. I forgot about untracked files when there are 'no
committable changes'
> ---
>
> builtin-commit.c | 5 ++++-
> wt-status.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 4e2f4aa..058cd32 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -300,7 +300,7 @@ static const char sign_off_header[] = "Signed-off-by: ";
> static int prepare_log_message(const char *index_file, const char *prefix)
> {
> struct stat statbuf;
> - int commitable;
> + int commitable, saved_color_setting;
> struct strbuf sb;
> char *buffer;
> FILE *fp;
> @@ -383,7 +383,10 @@ static int prepare_log_message(const char *index_file, const char *prefix)
> if (only_include_assumed)
> fprintf(fp, "# %s\n", only_include_assumed);
>
> + saved_color_setting = wt_status_use_color;
> + wt_status_use_color = 0;
> commitable = run_status(fp, index_file, prefix);
> + wt_status_use_color = saved_color_setting;
>
> fclose(fp);
>
> diff --git a/wt-status.h b/wt-status.h
> index f58ebcb..225fb4d 100644
> --- a/wt-status.h
> +++ b/wt-status.h
> @@ -27,6 +27,7 @@ struct wt_status {
> };
>
> int git_status_config(const char *var, const char *value);
> +int wt_status_use_color;
> void wt_status_prepare(struct wt_status *s);
> void wt_status_print(struct wt_status *s);
>
>
--
Ping Yin
^ permalink raw reply
* Re: git merge no longer handles add/add
From: Martin Langhoff @ 2007-11-19 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vtznipweu.fsf@gitster.siamese.dyndns.org>
On Nov 19, 2007 7:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> As far as the point of the merge is concerned, that's an add/add
> of _different_ contents, and we have always left the conflict to
> resolve for you since day one. The only case we handle without
> complaining is the accidental *clean* merge. Both branches adds
> the path *identically* compared to the common ancestor.
Even if the 2 paths did have matching content at one point? In fact,
the 2 files here get added with identicaly content and one of them is
later modified...
> The very initial implementation of merge may have used the total
> emptyness as the common ancestor for the merge, and later we
> made it a bit more pleasant to resolve by computing the common
> part of the file from the two branches to be used as a fake
> ancestor contents. But the fact we left the result as conflict
> for you to validate hasn't changed and will not change.
In this case, if you use the common part (100%) as the ancestor, then
you get a _clean_ merge. The file is added on both sides identically,
and then it changes on one side.
I'll see if I can repro with an older git install...
m
^ permalink raw reply
* [PATCH] Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
From: Matthieu Moy @ 2007-11-19 18:35 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <vpqtznirtlk.fsf@bauges.imag.fr>
The HEAD@{...} syntax was documented in git-rev-parse manpage, which
is hard to find by someone looking for the documentation of porcelain.
git-reflog is probably the place where one expects to find this.
While I'm there, "git revlog show whatever" was also undocumented.
---
Documentation/git-reflog.txt | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 5c7316c..aeac6f0 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -19,7 +19,7 @@ depending on the subcommand:
git reflog expire [--dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
-git reflog [show] [log-options]
+git reflog [show] [log-options] [<ref>]
Reflog is a mechanism to record when the tip of branches are
updated. This command is to manage the information recorded in it.
@@ -32,10 +32,17 @@ directly by the end users -- instead, see gitlink:git-gc[1].
The subcommand "show" (which is also the default, in the absence of any
subcommands) will take all the normal log options, and show the log of
-`HEAD`, which will cover all recent actions, including branch switches.
+`HEAD`, or of the reference provided in the command-line, which will
+cover all recent actions, including branch switches.
It is basically an alias for 'git log -g --abbrev-commit
--pretty=oneline', see gitlink:git-log[1].
+The reflog is useful in various git commands, to specify the old value
+of a reference. For example, `HEAD@\{2\}` means "where HEAD used to be
+two moves ago", `master@\{one.week.ago\}` means "where master used to
+point to one week ago", and so on. See gitlink:git-rev-parse[1] for
+more details.
+
OPTIONS
-------
--
1.5.3.5.724.g49d9d
^ permalink raw reply related
* Re: git merge no longer handles add/add
From: J. Bruce Fields @ 2007-11-19 18:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git list
In-Reply-To: <46a038f90711191033s4bc5ab50kd3e4f30d6b301e43@mail.gmail.com>
On Tue, Nov 20, 2007 at 07:33:27AM +1300, Martin Langhoff wrote:
> On Nov 19, 2007 7:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > As far as the point of the merge is concerned, that's an add/add
> > of _different_ contents, and we have always left the conflict to
> > resolve for you since day one. The only case we handle without
> > complaining is the accidental *clean* merge. Both branches adds
> > the path *identically* compared to the common ancestor.
>
> Even if the 2 paths did have matching content at one point? In fact,
> the 2 files here get added with identicaly content and one of them is
> later modified...
>
> > The very initial implementation of merge may have used the total
> > emptyness as the common ancestor for the merge, and later we
> > made it a bit more pleasant to resolve by computing the common
> > part of the file from the two branches to be used as a fake
> > ancestor contents. But the fact we left the result as conflict
> > for you to validate hasn't changed and will not change.
>
> In this case, if you use the common part (100%) as the ancestor, then
> you get a _clean_ merge. The file is added on both sides identically,
> and then it changes on one side.
That sounds like an inevitable consequence of git's design--it only uses
a global (not a per-file) common ancestor.
--b.
^ permalink raw reply
* [PATCH] autoconf: Add tests for memmem, strtoumax and mkdtemp functions
From: Jakub Narebski @ 2007-11-19 18:47 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Update configure.ac (and config.mak.in) to keep up with git
development by adding tests for memmem (NO_MEMMEM), strtoumax
(NO_STRTOUMAX) and mkdtemp (NO_MKDTEMP) functions.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is beginning of "bring configure up to date" thingy.
By the way, do you have idea how to test for the following
in configure.ac:
* Define NO_PREAD if you have a problem with pread() system call (e.g.
cygwin.dll before v1.5.22).
- what is the problem? how to detect it?
* Define NO_FAST_WORKING_DIRECTORY if accessing objects in pack files is
generally faster on your platform than accessing the working directory.
- if at all possible
* Define NO_TRUSTABLE_FILEMODE if your filesystem may claim to support
the executable mode bit, but doesn't really do so.
- I think there were some code here
* Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
that tells runtime paths to dynamic libraries;
"-Wl,-rpath=/path/lib" is used instead.
* Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
MakeMaker (e.g. using ActiveState under Cygwin).
* Define ASCIIDOC8 if you want to format documentation with AsciiDoc 8
* Define DOCBOOK_XSL_172 if you want to format man pages with DocBook XSL v1.72.
- it needs some portable way to check asciidoc and docbook-xsl version
* Define OLD_ICONV if your library has an old iconv(), where the second
(input buffer pointer) parameter is declared with type (const char **).
- perhaps compile with new iconv and check for compile errors?
config.mak.in | 3 +++
configure.ac | 18 ++++++++++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 776b805..11d256e 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -35,7 +35,10 @@ NO_SOCKADDR_STORAGE=@NO_SOCKADDR_STORAGE@
NO_IPV6=@NO_IPV6@
NO_C99_FORMAT=@NO_C99_FORMAT@
NO_STRCASESTR=@NO_STRCASESTR@
+NO_MEMMEM=@NO_MEMMEM@
NO_STRLCPY=@NO_STRLCPY@
+NO_STRTOUMAX=@NO_STRTOUMAX@
NO_SETENV=@NO_SETENV@
+NO_MKDTEMP=@NO_MKDTEMP@
NO_ICONV=@NO_ICONV@
NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
diff --git a/configure.ac b/configure.ac
index 53e9a17..7bcf1a4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -289,18 +289,36 @@ AC_CHECK_FUNC(strcasestr,
[NO_STRCASESTR=YesPlease])
AC_SUBST(NO_STRCASESTR)
#
+# Define NO_MEMMEM if you don't have memmem.
+AC_CHECK_FUNC(memmem,
+[NO_MEMMEM=],
+[NO_MEMMEM=YesPlease])
+AC_SUBST(NO_MEMMEM)
+#
# Define NO_STRLCPY if you don't have strlcpy.
AC_CHECK_FUNC(strlcpy,
[NO_STRLCPY=],
[NO_STRLCPY=YesPlease])
AC_SUBST(NO_STRLCPY)
#
+# Define NO_STRTOUMAX if you don't have strtoumax in the C library.
+AC_CHECK_FUNC(strtoumax,
+[NO_STRTOUMAX=],
+[NO_STRTOUMAX=YesPlease])
+AC_SUBST(NO_STRTOUMAX)
+#
# Define NO_SETENV if you don't have setenv in the C library.
AC_CHECK_FUNC(setenv,
[NO_SETENV=],
[NO_SETENV=YesPlease])
AC_SUBST(NO_SETENV)
#
+# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
+AC_CHECK_FUNC(mkdtemp,
+[NO_MKDTEMP=],
+[NO_MKDTEMP=YesPlease])
+AC_SUBST(NO_MKDTEMP)
+#
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_ICONV if your libc does not properly support iconv.
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH v2] git-send-email: show all headers when sending mail
From: David D. Kilzer @ 2007-11-19 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voddqodhs.fsf@gitster.siamese.dyndns.org>
I can't seem to reproduce this. Could you send me (off-list)
0001-branch-contains.txt and any relevant config bits?
Dave
Junio C Hamano <gitster@pobox.com> wrote:
> Thanks. Looks nice and obviously correct.
>
> One thing that has been bugging me for a long time now stands
> out like a sore thumb much more: empty Cc: is shown.
>
> $ git-send-email --dry-run --to=junio@my.isp.net 0001-branch-contains.txt
> Who should the emails appear to be from? [Junio C Hamano
> <gitster@pobox.com>]
> Emails will be sent from: Junio C Hamano <gitster@pobox.com>
> Message-ID to be used as In-Reply-To for the first email?
> 0001-branch-contains.txt
> Dry-OK. Log says:
> Date: Mon, 19 Nov 2007 00:10:04 -0800
> Server: my.isp.net
> MAIL FROM:<gitster@pobox.com>
> RCPT TO:<junio@my.isp.net>
> From: Junio C Hamano <gitster@pobox.com>
> Subject: [PATCH] branch --contains=<commit>
> Cc:
> To: junkio@cox.net
>
> Result: OK
^ permalink raw reply
* Re: [PATCH] Documentation: fix git-clone manpage not to refer to itself
From: Sergei Organov @ 2007-11-19 19:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0711191430460.16728@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Fri, 16 Nov 2007, Sergei Organov wrote:
>
>> +ifndef::git-clone[]
>
> It is laudable that you want to fix the _generated_ documentation, but
> there are two things to keep in mind:
>
> - it does _nothing_ to help readers of the sources, and asciidoc was
> chosen purposely because the source is human-readable, and
I wonder if C sources are human-readable? No #ifdefs whatsoever? ;)
And please notice that asciidoc is much worse than C preprocessor in
this regard :(
>
> - it makes writing the perl script to do a very tiny subset of asciidoc
> formatting much harder. We encounter enough problems with the different
> versions of asciidoc/docbook combinations that I think this perl script
> would be actually useful.
>
> I know that the user manual uses some advanced features, too, but it did
> not use ifdef in the main text, for example, let alone nested ifdefs,
> which your patch would encourage much more than the source before.
Unfortunately I don't see better solution than using ifdef in this
particular case, though I'm open for suggestions.
What I really do care about is the quality of the documentation that
user reads. For example, when the first option of git-format-*patch*
described in the manual is "-p Generate *patch*...", well..., what does
it generate without -p???
--
Sergei.
^ permalink raw reply
* Re: git merge no longer handles add/add
From: Junio C Hamano @ 2007-11-19 19:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git list
In-Reply-To: <46a038f90711191033s4bc5ab50kd3e4f30d6b301e43@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> On Nov 19, 2007 7:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> As far as the point of the merge is concerned, that's an add/add
>> of _different_ contents, and we have always left the conflict to
>> resolve for you since day one. The only case we handle without
>> complaining is the accidental *clean* merge. Both branches adds
>> the path *identically* compared to the common ancestor.
>
> Even if the 2 paths did have matching content at one point? In fact,
> the 2 files here get added with identicaly content and one of them is
> later modified...
A merge does not look at the history.
It _does_ look at the history to figure out what the common
ancestors are, but after finding them out, the "file history" is
not examined by following each step in the ancestry chain (that
would have been the "blame merge").
>> The very initial implementation of merge may have used the total
>> emptyness as the common ancestor for the merge, and later we
>> made it a bit more pleasant to resolve by computing the common
>> part of the file from the two branches to be used as a fake
>> ancestor contents. But the fact we left the result as conflict
>> for you to validate hasn't changed and will not change.
>
> In this case, if you use the common part (100%) as the ancestor, then
> you get a _clean_ merge. The file is added on both sides identically,
> and then it changes on one side.
Exactly. We may keep conflict markers in the file left in the
work tree to highlight which lines are unique to the side that
added more (iow, one group of lines delimited by <<< === >>> is
empty while the other is not) but this is currently treated as
"fishy, needs human validation" to catch mismerges.
^ permalink raw reply
* [RFH] Flush progress message buffer in display().
From: Johannes Sixt @ 2007-11-19 19:48 UTC (permalink / raw)
To: git, Nicolas Pitre
There are cases where the stderr of the program that reports progress
is not connected to a terminal (e.g. pack-objects when invoked by
upload-pack). In this case, the output is buffered by stdio. Consequently,
a considerable amount of progress report is accumulated before it is
written (in the upload-pack case to the remote end). A fflush() after
each progress display gives a nice continuous progress.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I need this patch on Windows because appearently progress output is buffered
by stdio. Why doesn't Linux/glibc's stdio buffer output that goes to a pipe?
If I inspect the data that upload-pack sends over the wire, then on Linux
it looks like this (the linebreaks don't appear on the wire):
0024^BCounting objects: 20946, done.
002c^BCompressing objects: 0% (1/15804) ^M
002e^BCompressing objects: 1% (159/15804) ^M
002e^BCompressing objects: 2% (317/15804) ^M
002e^BCompressing objects: 3% (475/15804) ^M
002e^BCompressing objects: 4% (633/15804) ^M
002e^BCompressing objects: 5% (791/15804) ^M
But on Windows it looks more like this:
0085^BCompressing objects: 0% (1/15804) ^MCompressing objects: 1% (159/15804) ^MCompressing objects: 2% (317/15804) ^MCompr
0085^Bessing objects: 3% (475/15804) ^MCompressing objects: 4% (633/15804) ^MCompressing objects: 5% (791/15804) ^MCompress
0085^Bing objects: 6% (990/16487) ...
The 0085 is obviously the length of progress[128] in create_pack_file()
plus 5 bytes overhead. This happens because pack-objects buffers the
progress output and upload-pack reads it out in pieces of 128 bytes.
Why doesn't the same happen on Linux? What is flushing the progress
output?
BTW, to reproduce, use this in your favorite git repo:
#!/bin/sh
git upload-pack . <<EOF | less
0040want $(git rev-parse HEAD) side-band-64k
00000009done
0000
EOF
-- Hannes
progress.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/progress.c b/progress.c
index 4bd650f..d19f80c 100644
--- a/progress.c
+++ b/progress.c
@@ -98,11 +98,13 @@ static int display(struct progress *progress, unsigned n, const char *done)
fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
progress->title, percent, n,
progress->total, tp, eol);
+ fflush(stderr);
progress_update = 0;
return 1;
}
} else if (progress_update) {
fprintf(stderr, "%s: %u%s%s", progress->title, n, tp, eol);
+ fflush(stderr);
progress_update = 0;
return 1;
}
@@ -207,6 +209,7 @@ struct progress *start_progress_delay(const char *title, unsigned total,
if (!progress) {
/* unlikely, but here's a good fallback */
fprintf(stderr, "%s...\n", title);
+ fflush(stderr);
return NULL;
}
progress->title = title;
--
1.5.3.5.739.gcac53
^ permalink raw reply related
* Re: git merge no longer handles add/add
From: Jakub Narebski @ 2007-11-19 19:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vabpanilk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Exactly. We may keep conflict markers in the file left in the
> work tree to highlight which lines are unique to the side that
> added more (iow, one group of lines delimited by <<< === >>> is
> empty while the other is not) but this is currently treated as
> "fishy, needs human validation" to catch mismerges.
BTW can xdifflib merge use original diff3 conflict markers, i.e.
<<< [main] |||| [ancestor] === [branch] >>>?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch
From: Junio C Hamano @ 2007-11-19 19:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Steffen Prohaska
In-Reply-To: <fhrrbt$lvk$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Brief recap, to check if I understand things correctly:
>
> 1. If you use "matching" more often, then it should be enough to provide
> remote.<remotename>.push with refspec or wildcard refspec.
Eh, excuse me, what refspec would you write there? "matching"
is defined to push the intersection of what we have and what
they have when "git-push" is run. I do not think there is any
way to write that in remote.$there.push and cast in stone.
With "matching", you can arrange a set of semi-permanent
branches to be shown to others and let others build on, in
either "publishing" or "shared repository" model, while keeping
experimental branches in your private repository, and:
$ git push $there
will only send what are in "the set of semi-permament branches",
like 'master' and 'maint. Adding a new branch to that set is
just the matter of a one-shot:
$ git push $there next
(older git may have choked and asked you to be more explicit by
"next:refs/heads/next"). After you do it once, "matching" will
push 'master', 'maint', 'next' without any additional
configuration. Removing a branch from the set is also just a
matter of one-shot:
$ git push $there :next
When you replace 'next' in the above with something that is a
lot short lived, the principle is the same. I can push a topic
branch (say, jn/gitweb), asking "I have queued your patches but
I am having trouble merging this back to 'master' due to heavy
conflicts; could you do the honors instead?". While waiting for
you to respond to that request, I may add more commits to that
branch and the "matching" push by me will update what is shown
$there. Hopefully you would eventually pick it up and merge,
and either push the result back to my 'master' directly or
publish the result elsewhere for me to pull to my 'master'.
After all the interaction is done, the topic branch does not
have to stay $there and can be deleted. Then 'matching' will
not touch the topic branch anymore, even if I still keep it
privately in my repository.
> ... If one wants to push only current branch, one
> would use "git push --current" or "git push <remotename> HEAD".
I think that is the proposal by Steffen (added back CC).
I am wondering if an alternative approach could be simpler. If
we teach "git-push" to notice when only the refspecs are given
without remotename, and default to branch.$current.remote in
such a case, IOW, make these:
$ git push HEAD
$ git push next
push the obvious thing to the default remote, I _think_ we can
achieve the same effect as --current and a bit more.
The latter could be run after I made the 'next' integration
branch into a good shape, switched to 'pu' to merge up other
bits but before finishing that merging yet (it would not help me
personally as I do not work that way --- I push things out only
after I am done with all the public branches --- but it may help
the others).
> Question: what to do if there is no remote.<remotename>.push? Assume
> 1-1 matching?
One-to-one is what 'matching' does, and the way to trigger it is
not to have a remote.$there.push.
^ permalink raw reply
* Re: [PATCH] Doc fix for git-reflog: mention @{...} syntax, and <ref> in synopsys.
From: Junio C Hamano @ 2007-11-19 20:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1195497342-26334-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The HEAD@{...} syntax was documented in git-rev-parse manpage, which
> is hard to find by someone looking for the documentation of porcelain.
> git-reflog is probably the place where one expects to find this.
>
> While I'm there, "git revlog show whatever" was also undocumented.
Thanks. The new HEAD@{N} description is concise and nice.
> The subcommand "show" (which is also the default, in the absence of any
> subcommands) will take all the normal log options, and show the log of
> -`HEAD`, which will cover all recent actions, including branch switches.
> +`HEAD`, or of the reference provided in the command-line, which will
> +cover all recent actions, including branch switches.
> It is basically an alias for 'git log -g --abbrev-commit
> --pretty=oneline', see gitlink:git-log[1].
But the wording added with "While I'm there" change seems wrong
to me. "..., which will cover all recent actions" is about the
reflog attached to HEAD but the new phrase inserted in the
middle makes it unclear.
^ permalink raw reply
* [PATCH] Fix start_command closing cmd->out/in regardless of cmd->close_out/in
From: Ping Yin @ 2007-11-19 20:12 UTC (permalink / raw)
To: git; +Cc: Ping Yin
When the file descriptor of 'FILE *fp' is assigned to child_process.out
and then start_command or run_command is run, the standard output of the
child process is expected to be outputed to fp.
start_command will always close fp in this case. However, sometimes fp is
not expected to be closed since further IO may be still performmed on fp.
This patch disables the auto closing behavious of start_command
and corrects all codes which depend on this kind of behaviour.
Following is a case that the auto closing behaviour is not expected.
When adding submodule summary feature to builtin-commit, in wt_status_print,
I want to output the submodule summary between changed and untracked files
as the following patch shows
wt_status_print_changed(s);
+ wt_status_print_submodule_summary(s);
wt_status_print_untracked(s);
All the three calls will output to s->fp (which points to a file instead of
standard output when doing committing). So I don't want s->fp to be closed after
wt_status_print_submodule_summary(s) which calls run_command.
+static void wt_status_print_submodule_summary(struct wt_status *s)
+{
+ struct child_process sm_summary;
+ memset(&sm_summary, 0, sizeof(sm_summary));
+ ...
+ sm_summary.out = fileno(s->fp);
+ ...
+ run_command(&sm_summary);
+}
Signed-off-by: Ping Yin <pkufranky@gmail.com>
---
bundle.c | 1 +
convert.c | 1 +
run-command.c | 4 ----
upload-pack.c | 3 ++-
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/bundle.c b/bundle.c
index e4d60cd..fc253fb 100644
--- a/bundle.c
+++ b/bundle.c
@@ -336,6 +336,7 @@ int unbundle(struct bundle_header *header, int bundle_fd)
memset(&ip, 0, sizeof(ip));
ip.argv = argv_index_pack;
ip.in = bundle_fd;
+ ip.close_in = 1;
ip.no_stdout = 1;
ip.git_cmd = 1;
if (run_command(&ip))
diff --git a/convert.c b/convert.c
index 4df7559..ce7bed0 100644
--- a/convert.c
+++ b/convert.c
@@ -212,6 +212,7 @@ static int filter_buffer(int fd, void *data)
child_process.argv = argv;
child_process.in = -1;
child_process.out = fd;
+ child_process.close_out = 1;
if (start_command(&child_process))
return error("cannot fork to run external filter %s", params->cmd);
diff --git a/run-command.c b/run-command.c
index 476d00c..4e5f58d 100644
--- a/run-command.c
+++ b/run-command.c
@@ -115,13 +115,9 @@ int start_command(struct child_process *cmd)
if (need_in)
close(fdin[0]);
- else if (cmd->in)
- close(cmd->in);
if (need_out)
close(fdout[1]);
- else if (cmd->out > 1)
- close(cmd->out);
if (need_err)
close(fderr[1]);
diff --git a/upload-pack.c b/upload-pack.c
index 7e04311..7aeda80 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -163,7 +163,8 @@ static void create_pack_file(void)
argv[arg++] = NULL;
memset(&pack_objects, 0, sizeof(pack_objects));
- pack_objects.in = rev_list.out; /* start_command closes it */
+ pack_objects.in = rev_list.out;
+ pack_objects.close_in = 1; /* finish_command closes rev_list.out */
pack_objects.out = -1;
pack_objects.err = -1;
pack_objects.git_cmd = 1;
--
1.5.3.5.1878.gb1da0-dirty
^ permalink raw reply related
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