* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 10:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v63qqv7ex.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> This new action needs to be in a conditional to keep it from removing
>>> the ONLY git executable when bindir and execdir are the same dir.
>> Heh, I love bug reports that come immediately after I tag the tip of
>> 'master' as -rc1.
>
> This should do, but to be very honest, I really hate the output from the
> foreach that precedes this section.
>
> Makefile | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 798a2f2..92df61c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1362,7 +1362,10 @@ endif
> cp "$$bindir/git$X" "$$execdir/git$X"; \
> fi && \
> { $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
> - $(RM) "$$execdir/git$X" && \
> + if test "z$$bindir" != "z$$execdir"; \
> + then \
> + $(RM) "$$execdir/git$X"; \
> + fi && \
> ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
>
> install-doc:
>
I'll test this this evening.
^ permalink raw reply
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 10:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vabg2v83o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>> Johannes Sixt wrote:
>> [...]
>>> diff --git a/Makefile b/Makefile
>>> index 551bde9..cbab4f9 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1335,6 +1335,7 @@ endif
>>> '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
>>> fi
>>> $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
>>> + $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
>>> ifneq (,$X)
>>> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
>>> endif
>> This new action needs to be in a conditional to keep it from removing
>> the ONLY git executable when bindir and execdir are the same dir.
>
> Heh, I love bug reports that come immediately after I tag the tip of
> 'master' as -rc1.
>
Well, I'm currently about a week behind on all things git so this is as
timely as I could make it. ;-)
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-28 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <7vk5f6tqsj.fsf@gitster.siamese.dyndns.org>
On Mon, 2008-07-28 at 00:24 -0700, Junio C Hamano wrote:
> >> Commit reels can also, and generally do, include the objects required
> >> for a specific commit.
> >
> > Yes. The only times where they wouldn't contain all the objects
> > required for the commits within the reel, is when those objects happened
> > to be contained by a previous reel.
>
> What do you mean by "previous" reel? It is not quite defined in your
> message but perhaps defined elsewhere?
>
> How is this different from a bundle? Does a reel, unlike a bundle,
> contain the full tree for the bottom commits?
They are almost identical, both being defined by a set of starting and
ending refs. And now that you mention it, I feel slightly embarrassed
for not spotting the connection before. I only really compared reels to
packs, which is what the original specification tried to chop up bitwise
and distribute chunk by chunk.
The differences are:
- the reel has a defined object order (which as I hoped to demonstrate
in the test cases, is just a refinement of rev-list --date-order)
- deltas always point in one direction, to objects "earlier" on
the reel, so that slices of the reel sent on the network can be made
thin without resulting in unresolvable deltas (which should be
possible to do on commit boundaries using rev-list --objects-edge)
- the behaviour at the beginning of the reel is precisely defined
(although as I said, I think that the decision might be worth
revisiting - perhaps getting just the latest reel is a useful
'shallow clone')
> > This is one of the design decisions which I think may be a mistake; a
> > less expensive to calculate definition of a reel would be *all* objects
> > between the starting and ending Reference objects.
>
> Do you mean all such objects and nothing else? That would imply that a
> reel is quite similar to a bundle (but neither rev-list --objects-edge
> nor bundle guarantees that the result is minimal).
It's the lack of guarantees which is the issue, really. In order to
take the download work of the entire pack and distribute it over
multiple peers, you need a way to carve the bundle up. This has to
happen in such a way that the fragments that you get back will actually
fit together at the end, and also in such a way that you don't lose the
benefits of delta compression.
The way I thought would be best to do that would be to line up all the
objects in an exactly defined way - hence, the "reel" concept - and then
chop that up.
If a pack is already arranged to line up with the commit reel's
structure, then it's possible that the amount of work required to answer
a "play" request is as little as looking up in the reel index the local
on-disk location within the local pack, and copying that to the network.
I've certainly wondered how much baggage could be removed from this
whole thing, like replacing the "tracker" with a simple git-daemon
message that holds a register of mirrors/peers, possibly layering things
over git:// instead of the bittorrent-like protocol, dividing up blocks
by the commit graph and not all objects, etc. But I think that it would
be best to defer that kind of design change until the conclusion of this
prototype experiment.
That being said, anything which does shortcut the distance to the finish
line and can be agreed on wouldn't go amiss.
Sam
^ permalink raw reply
* Re: [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Johannes Schindelin @ 2008-07-28 9:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vljzmwvww.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 27 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > +struct cmdnames {
> >> > + int alloc;
> >> > + int cnt;
> >> > + struct cmdname {
> >> > + size_t len;
> >> > + char name[1];
> >> > + } **names;
> >> > +};
> >>
> >> I thought we do this kind of thing using FLEX_ARRAY macro. Is there any
> >> reason its use is not appropriate here?
> >
> > I think that came up in the previous review round: the "name" member _is_
> > NUL-terminated, but could have a ".exe" suffix. The "len" member has the
> > length excluding ".exe".
>
> Sorry, but I do understand what you are trying to explain.
>
> Marking the flexible member at the end as "last_member[FLEX_ARRAY]" is
> about a tiny bit of abstracting out how the exact decl syntax should look
> like depending on the compiler.
Ah, sorry, I misunderstood. I thought your complaint was about something
else.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Junio C Hamano @ 2008-07-28 9:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <7vvdyqx0i0.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>>> We may throw a dice or go with your version, I don't care *that* much
>>> about this change, I just wouldn't make it personally.
>>
>> What is the status of this patch? :-) Dropped altogether?
>
> Left behind on the far side of oblivion; I do not offhand recall what this
> was about, sorry.
Ok, I now recall this bit:
You are right, now that I understand the issue better, there's no good
fix for this except perhaps introducing --no-prefix, which is not my
itch to scratch. Here's my original wording improvement:
Note that if you are within a subdirectory of your working copy,
'git ls-tree' will automatically prepend the subdirectory prefix
to the specified paths, and assume the prefix specified in case
no paths were given - no matter what the tree object is! Thus,
within a subdirectory, 'git ls-tree' behaves as expected only
when run on a root tree object.
Eventually somebody may write a Porcelain that benefits from --no-prefix,
but it is safe to defer the implementation until the need becomes real.
I'll add some explanatory message to the documentation.
^ permalink raw reply
* Re* [PATCH] git-merge -s theirs
From: Junio C Hamano @ 2008-07-28 9:18 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Miklos Vajna
In-Reply-To: <7vhcak45ez.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
> ...
> That is certainly cute, but I do not like it for two reasons:
>
> - This advertizes "theirs" as available when you ask "git merge -s whoa",
> and then the user is told "don't use this stupid, go away". That is
> not exactly a good diplomacy to earn friends.
>
> - The message gives a rather long hexdecimal string in its suggestion to
> run "git reset --hard". This is not exactly your fault, though. The
> original refname the user gave to "git-merge" is not available to your
> strategy.
This does not address the first point at all, but attempts to solve the
second issue. Strategies now get the remote in the symbolic form
originally used on the command line.
All strategies know that they need to expect that the refs can be given
with arbitrary SHA-1 expressions, so this change should be safe.
builtin-merge.c | 20 +++++++++++++++-----
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..1a9850f 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "decorate.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -504,7 +505,7 @@ static void write_tree_trivial(unsigned char *sha1)
}
static int try_merge_strategy(const char *strategy, struct commit_list *common,
- const char *head_arg)
+ const char *head_arg, struct decoration *symbolic)
{
const char **args;
int i = 0, ret;
@@ -520,8 +521,12 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,
args[i++] = xstrdup(sha1_to_hex(j->item->object.sha1));
args[i++] = "--";
args[i++] = head_arg;
- for (j = remoteheads; j; j = j->next)
- args[i++] = xstrdup(sha1_to_hex(j->item->object.sha1));
+ for (j = remoteheads; j; j = j->next) {
+ char *name = lookup_decoration(symbolic, &j->item->object);
+ if (!name)
+ name = sha1_to_hex(j->item->object.sha1);
+ args[i++] = xstrdup(name);
+ }
args[i] = NULL;
ret = run_command_v_opt(args, RUN_GIT_CMD);
strbuf_release(&buf);
@@ -773,6 +778,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
struct commit_list *common = NULL;
const char *best_strategy = NULL, *wt_strategy = NULL;
struct commit_list **remotes = &remoteheads;
+ struct decoration symbolic_remote_head;
setup_work_tree();
if (unmerged_cache())
@@ -870,6 +876,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strbuf_addf(&buf, " %s", argv[i]);
setenv("GIT_REFLOG_ACTION", buf.buf, 0);
strbuf_reset(&buf);
+ memset(&symbolic_remote_head, 0, sizeof(symbolic_remote_head));
for (i = 0; i < argc; i++) {
struct object *o;
@@ -877,6 +884,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
o = peel_to_type(argv[i], 0, NULL, OBJ_COMMIT);
if (!o)
die("%s - not something we can merge", argv[i]);
+ add_decoration(&symbolic_remote_head, o, xstrdup(argv[i]));
remotes = &commit_list_insert(lookup_commit(o->sha1),
remotes)->next;
@@ -1041,7 +1049,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
wt_strategy = use_strategies[i]->name;
ret = try_merge_strategy(use_strategies[i]->name,
- common, head_arg);
+ common, head_arg,
+ &symbolic_remote_head);
if (!option_commit && !ret) {
merge_was_ok = 1;
/*
@@ -1105,7 +1114,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
restore_state();
printf("Using the %s to prepare resolving by hand.\n",
best_strategy);
- try_merge_strategy(best_strategy, common, head_arg);
+ try_merge_strategy(best_strategy, common, head_arg,
+ &symbolic_remote_head);
}
if (squash)
^ permalink raw reply related
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Junio C Hamano @ 2008-07-28 7:38 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <7vvdyqv9bf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> ... It is either used as
>> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
>> (2 directories).
>
> I thought Hannes already fixed that one; we shouldn't have the latter.
Oops, I misread your message. You are worried about the builtins. Sorry.
^ permalink raw reply
* Re: Git's config core.pager doesn't respect color.pager
From: Jeff King @ 2008-07-28 7:25 UTC (permalink / raw)
To: Benjamin Kudria; +Cc: Junio C Hamano, git
In-Reply-To: <d129c0140807221910j37f40e72se9f411d6424077de@mail.gmail.com>
On Tue, Jul 22, 2008 at 10:10:17PM -0400, Benjamin Kudria wrote:
> [core]
> pager = tig
>
> [color]
> diff = auto
> pager = false
[...]
> So, with the above config, when I do:
>
> git diff | tig
>
> Everything works correctly - git sends no color codes, because of
> color.pager = false.
Actually, it works because of color.diff = auto. Stdout is not a tty,
therefore color does not kick in. The point of color.pager is to say
"since git started a pager on behalf of the user, the tty test is
pointless. What we really want to know is whether the pager can handle
colors."
> However, if I do just:
>
> git diff
>
> git uses core.pager to display the output, but still sends color
> codes, which is OK for, say, less, bit not so good for tig, which does
> it's own colorizing, and displays the color codes git sends as-is.
And this is a bug, but one that only affects "diff". It's an ordering
problem in looking at the config and starting the pager (diff is unlike
most other commands in that we cannot decide immediately if we want the
pager, in the case that --exit-code is used). So we make the color
decision before we have started the pager.
Unfortunately, it is not quite as simple as just flipping the order.
Starting the pager depends on knowing that we are using --exit-code,
which depends on doing the diff options parsing and setup, which depends
on reading the config, which then depends on the pager setup.
The patch below should fix it, but it really leaves a bad taste in my
mouth. However, breaking the dependency chain would require some pretty
major surgery, I think. It is a little worrisome to me that
git_config_colorbool depends on the value of pager_use_color, another
config variable, at all; that means that ordering in the config file
could change the outcome. It happens to work because we read the config
several times, and we pick up pager.color on a previous read. I think
the "right" solution would be refactoring the color stuff to make the
decision closer to the point of use. But that is definitely not -rc
material, so perhaps this should go in, ugly as it is.
---
builtin-diff.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index 7ffea97..564984e 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -301,6 +301,21 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
setup_pager();
/*
+ * Special case: we have already examined the config for
+ * color, but we didn't know at that point whether we were
+ * going to start a pager. The only case that we care about is
+ * when we turned on color, but shouldn't have (we will never
+ * "should have but didn't" because of the pager, since
+ * a lack of a pager implies either the tty is stdout, in
+ * which case we do turn on color, or it is not, in which
+ * case we don't start a pager).
+ */
+ if (DIFF_OPT_TST(&rev.diffopt, COLOR_DIFF) &&
+ pager_in_use() &&
+ !pager_use_color)
+ DIFF_OPT_CLR(&rev.diffopt, COLOR_DIFF);
+
+ /*
* Do we have --cached and not have a pending object, then
* default to HEAD by hand. Eek.
*/
--
1.6.0.rc1.155.gd3310.dirty
^ permalink raw reply related
* Re: GTP/0.1 terminology 101: commit reels and references
From: Junio C Hamano @ 2008-07-28 7:24 UTC (permalink / raw)
To: Sam Vilain; +Cc: Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <1217228570.6750.24.camel@maia.lan>
Sam Vilain <sam@vilain.net> writes:
>> Commit reels can also, and generally do, include the objects required
>> for a specific commit.
>
> Yes. The only times where they wouldn't contain all the objects
> required for the commits within the reel, is when those objects happened
> to be contained by a previous reel.
What do you mean by "previous" reel? It is not quite defined in your
message but perhaps defined elsewhere?
How is this different from a bundle? Does a reel, unlike a bundle,
contain the full tree for the bottom commits?
> This is one of the design decisions which I think may be a mistake; a
> less expensive to calculate definition of a reel would be *all* objects
> between the starting and ending Reference objects.
Do you mean all such objects and nothing else? That would imply that a
reel is quite similar to a bundle (but neither rev-list --objects-edge
nor bundle guarantees that the result is minimal).
^ permalink raw reply
* [PATCH] Allow installing in the traditional way
From: Junio C Hamano @ 2008-07-28 7:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In an earlier commit c70a8d9 (Makefile: Do not install a copy of 'git' in
$(gitexecdir), 2008-07-21), we tried to avoid installing two git, one in
/usr/bin/git and the other in /usr/libexec/git-core/git. It mistakenly
removed the only copy of git when gitexecdir and bindir are set to the
same directory, i.e. the traditional layout.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 7e30b30..52c67c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1362,7 +1362,10 @@ endif
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
- $(RM) "$$execdir/git$X" && \
+ if test "z$$bindir" != "z$$execdir"; \
+ then \
+ $(RM) "$$execdir/git$X"; \
+ fi && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
--
1.6.0.rc1
^ permalink raw reply related
* [PATCH] Allow building without any git installed
From: Junio C Hamano @ 2008-07-28 7:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
This is a follow-up patch to 49fa65a (Allow the built-in exec path to be
relative to the command invocation path, 2008-07-23). Without specific
gitexecdir passed from the command line, git-gui's build procedure would
try to figure out the value for it by running an installed git.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 798a2f2..7e30b30 100644
--- a/Makefile
+++ b/Makefile
@@ -1067,7 +1067,7 @@ endif
all::
ifndef NO_TCLTK
- $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all
+ $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
--
1.6.0.rc1
^ permalink raw reply related
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-28 7:02 UTC (permalink / raw)
To: Joshua Roys; +Cc: gittorrent, git, Jonas Fonseca
In-Reply-To: <488D42B6.4030701@gmail.com>
Josh, I'm cc:'ing the main list with this one as well, as I think it
falls into the scope of discussions of wider interest than the rfc- and
implementation-specific discussions that (I envisaged would) happen on
the gittorrent list.
On Sun, 2008-07-27 at 23:53 -0400, Joshua Roys wrote:
> Here's some terms, as best as I understand them.
>
> The *Commit Reel* is a sequence of objects between two reference points,
> sorted in a deterministic fashion. The two reference points are
> *Reference* objects, or a signed tag containing a collection of git refs
> (similar to the output from `git show-ref`).
Yes, that's right. We have the two slightly ambiguous terms, "refs",
which mean the same thing as the rest of git, and "References", which
are more like .git/packed-refs. Perhaps this is a good time to pick a
better name. "Slice" would be an accurate term, though it's certainly
tempting to pick another term from the tape taxonomy, such as "Splice"¹
or "Mark"².
> Commit reels can also, and generally do, include the objects required
> for a specific commit.
Yes. The only times where they wouldn't contain all the objects
required for the commits within the reel, is when those objects happened
to be contained by a previous reel.
This is one of the design decisions which I think may be a mistake; a
less expensive to calculate definition of a reel would be *all* objects
between the starting and ending Reference objects. The current
definition requires a hash index of objects in each reel, which must be
consulted once for all objects when creating the reel index.
> As an example, a commit reel could be the set of objects between the
> v2.6.25 and v2.6.26 tags of the Linux kernel. The only thing we would
> need added to those tags is the list of heads (and tags) at the time of
> the tagging.
Correct. It represents all of the changes in a given repository over a
period of time.
> Those two structures form the basis for two *Peer Wire Protocol* (PWP)
> messages, Reels and References.
>
> Any questions, corrections, or rotten vegetables?
No, I think that's all good so far...
Cheers,
Sam.
¹ - see
http://en.wikipedia.org/wiki/Reel-to-reel_audio_tape_recording#Description
² - as used by the old unix "mt", see eg
http://docs.sun.com/app/docs/doc/816-0210/6m6nb7mf3?a=view
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-28 6:44 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080728063838.GB4234@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> t2103-update-index-ignore-missing.sh still broken on Windows because
> of stat.st_size being 0 for directories there.
I recall we did not reach a useful conclusion of that discussion.
^ permalink raw reply
* Re: [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-28 6:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Shawn O. Pearce
In-Reply-To: <7v3aly5zz3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
>> On Donnerstag, 24. Juli 2008, Junio C Hamano wrote:
>>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>>> > It also fixes 'make install' of git-gui as well (sigh!) by not exporting
>>> > gitexecdir - assuming that Shawn applies the git-gui patch.
>>>
>>> Yeah, this seems to break the install quite badly without git-gui patch.
>>
>> If you squash this in, we don't need the git-gui patch.
>
> Thanks.
>
> I think this patch makes _more_ sense than the git-gui patch, actually.
>
> Within the context of git.git project, we would want to force the
> installation directory of git-gui portion to be consistent with the main
> project.
What I wanted to say with the above is that the main Makefile is what has
its own special need from git-gui/Makefile's point of view, so passing
such customization from the main Makefile makes a lot of sense.
I think this is also needed; I noticed it while trying the "build on a
machine without any git installed" exercise.
diff --git a/Makefile b/Makefile
index 798a2f2..52c67c1 100644
--- a/Makefile
+++ b/Makefile
@@ -1067,7 +1067,7 @@ endif
all::
ifndef NO_TCLTK
- $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all
+ $(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) gitexecdir='$(gitexec_instdir_SQ)' all
$(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
^ permalink raw reply related
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: Junio C Hamano @ 2008-07-28 6:39 UTC (permalink / raw)
To: gitzilla; +Cc: Johannes Sixt, git
In-Reply-To: <7vabg2v83o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> This new action needs to be in a conditional to keep it from removing
>> the ONLY git executable when bindir and execdir are the same dir.
>
> Heh, I love bug reports that come immediately after I tag the tip of
> 'master' as -rc1.
This should do, but to be very honest, I really hate the output from the
foreach that precedes this section.
Makefile | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 798a2f2..92df61c 100644
--- a/Makefile
+++ b/Makefile
@@ -1362,7 +1362,10 @@ endif
cp "$$bindir/git$X" "$$execdir/git$X"; \
fi && \
{ $(foreach p,$(BUILT_INS), $(RM) "$$execdir/$p" && ln "$$execdir/git$X" "$$execdir/$p" ;) } && \
- $(RM) "$$execdir/git$X" && \
+ if test "z$$bindir" != "z$$execdir"; \
+ then \
+ $(RM) "$$execdir/git$X"; \
+ fi && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
^ permalink raw reply related
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-28 6:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy73myim5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Mon, Jul 28, 2008 02:09:38 +0200:
> Ok, so I tagged and pushed it out. There still is the "git mv" bugfix
> from Pasky that is parked in 'next' but other than that I think this is
> pretty much "it" for 1.6.0 feature-wise.
>
> Major parts of the changes since 1.6.0-rc0 consists of documentation and
> tests portability; there is nothing surprising nor scary.
t2103-update-index-ignore-missing.sh still broken on Windows because
of stat.st_size being 0 for directories there.
http://thread.gmane.org/gmane.comp.version-control.git/89370
^ permalink raw reply
* [PATCH] Make use of stat.ctime configurable
From: Alex Riesen @ 2008-07-28 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <7v1w1f155p.fsf@gitster.siamese.dyndns.org>
because there are situations where it produces too much false
positives. Like when file system crawlers keep changing it when
scanning and using the ctime for marking scanned files.
The default is to allow use of ctime.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Sun, Jul 27, 2008 21:46:42 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > because there are situations where it produces too much false
> > positives. Like when file system crawlers keep changing it when
> > scanning and using the ctime for marking scanned files.
>
> This justification is good and I am very inclined to advocate for its
> inclusion in 1.6.0, but any new configuration needs to be in the
> documentation.
Done.
> It appears there is "gui.trustmtime"; shouldn't this be called
> "core.trustctime" or something?
Getting old... I even called the global flag trust_file_ctime!
Corrected. Changed trust_file_ctime to trust_ctime.
Documentation/config.txt | 7 +++++++
Documentation/git-update-index.txt | 5 +++++
cache.h | 1 +
config.c | 4 ++++
environment.c | 1 +
read-cache.c | 2 +-
6 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1a13abc..552c134 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -149,6 +149,13 @@ core.safecrlf::
`core.autocrlf`, git will reject the file. The variable can
be set to "warn", in which case git will only warn about an
irreversible conversion but continue the operation.
+
+core.trustctime::
+ If false, the ctime differences between the index and the
+ working copy are ignored; useful when the inode change time
+ is regularly modified by something outside Git (file system
+ crawlers and some backup systems).
+ See linkgit:git-update-index[1]. True by default.
+
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 6b930bc..1d9d81a 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -323,6 +323,11 @@ from symbolic link to regular file.
The command looks at `core.ignorestat` configuration variable. See
'Using "assume unchanged" bit' section above.
+The command also looks at `core.trustctime` configuration variable.
+It can be useful when the inode change time is regularly modified by
+something outside Git (file system crawlers and backup systems use
+ctime for marking files processed) (see linkgit:git-config[1]).
+
SEE ALSO
--------
diff --git a/cache.h b/cache.h
index 4b6c0a6..2475de9 100644
--- a/cache.h
+++ b/cache.h
@@ -423,6 +423,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);
/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
+extern int trust_ctime;
extern int quote_path_fully;
extern int has_symlinks;
extern int ignore_case;
diff --git a/config.c b/config.c
index 1e066c7..53f04a0 100644
--- a/config.c
+++ b/config.c
@@ -341,6 +341,10 @@ static int git_default_core_config(const char *var, const char *value)
trust_executable_bit = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, "core.trustctime")) {
+ trust_ctime = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp(var, "core.quotepath")) {
quote_path_fully = git_config_bool(var, value);
diff --git a/environment.c b/environment.c
index 4a88a17..0c6d11f 100644
--- a/environment.c
+++ b/environment.c
@@ -13,6 +13,7 @@ char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
int user_ident_explicitly_given;
int trust_executable_bit = 1;
+int trust_ctime = 1;
int has_symlinks = 1;
int ignore_case;
int assume_unchanged;
diff --git a/read-cache.c b/read-cache.c
index 6c08803..1cae361 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -197,7 +197,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
}
if (ce->ce_mtime != (unsigned int) st->st_mtime)
changed |= MTIME_CHANGED;
- if (ce->ce_ctime != (unsigned int) st->st_ctime)
+ if (trust_ctime && ce->ce_ctime != (unsigned int) st->st_ctime)
changed |= CTIME_CHANGED;
if (ce->ce_uid != (unsigned int) st->st_uid ||
--
1.6.0.rc0.76.g581e
^ permalink raw reply related
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: Junio C Hamano @ 2008-07-28 6:24 UTC (permalink / raw)
To: gitzilla; +Cc: Johannes Sixt, git
In-Reply-To: <488D104F.8080005@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Johannes Sixt wrote:
> [...]
>>
>> diff --git a/Makefile b/Makefile
>> index 551bde9..cbab4f9 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1335,6 +1335,7 @@ endif
>> '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
>> fi
>> $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
>> + $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
>> ifneq (,$X)
>> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
>> endif
>
> This new action needs to be in a conditional to keep it from removing
> the ONLY git executable when bindir and execdir are the same dir.
Heh, I love bug reports that come immediately after I tag the tip of
'master' as -rc1.
^ permalink raw reply
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-28 6:18 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna
In-Reply-To: <200807280810.20922.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Yeah, but what is quite confusing I think is that a merge base seems to be
> defined as "an as good as possible _common_ ancestor" but in this case, the
> result of "git merge-base A B C" is not an ancestor of C (even with --all
> option). So perhaps we need a better definition.
See my other message. "git merge-base A B C" is not the best common
ancestors across A B and C. It is the best common ancestors between A and
a commit that is a merge between B and C.
By defining/explaining it that way, you can avoid the "Huh, are you
talking about OR or AND" question you would inevitably get when you say
"Common ancestor of A and B or A and C". Also in "git merge-base A B C",
A is fundamentally different from any other commit; a commit being (or not
being) common between A and B (or A and C) is what we care about a lot,
but a commit being (or not being) common between B and C does not matter
in this computation.
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Jeff King @ 2008-07-28 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vljzmv8mm.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 27, 2008 at 11:13:37PM -0700, Junio C Hamano wrote:
> Thanks, it seems that I keep forgetting to apply this patch after saying
> to myself "Heh, it obviously is the correct thing to do".
That is why you have other developers to nag you. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Junio C Hamano @ 2008-07-28 6:13 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20080728060204.GC7294@sigill.intra.peff.net>
Thanks, it seems that I keep forgetting to apply this patch after saying
to myself "Heh, it obviously is the correct thing to do".
^ permalink raw reply
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-28 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Miklos Vajna
In-Reply-To: <7vabg43pcp.fsf@gitster.siamese.dyndns.org>
Le dimanche 27 juillet 2008, Junio C Hamano a écrit :
>
> The point of merge_bases_many() is that it allows you to compute a merge
> base between a commit and another commit that does not yet exist which is
> a merge across all others.
>
> o---o---o---o---C
> / :
> / o---o---o---B..(M)
> / / :
> ---o---*---o---o---o---A..(X)
>
> Suppose you have commits A, B and C, and you would want to come up with
> an Octopus merge X across these three commits. Because our low-level
> merge machinery works always on two trees with one common ancestor tree,
> we would first create a tree that is a merge between B and C (which is
> marked as (M) in the picture), and then merge the tree of (M) and A using
> common ancestor between (M) and A.
>
> If we did not have merge_bases_many(), we would actually create (M) as a
> real commit, and compute merge base between A and (M), which is marked as
> "*" in the picture. The use of merge_bases_many() allows us to run the
> same merge base computation without actually creating commit (M).
> Instead of computing merge-base between A and (M), you can ask for the
> merge base between A ("the first commit") and B, C ("the other commits")
> to obtain the same answer "*".
Yeah, but what is quite confusing I think is that a merge base seems to be
defined as "an as good as possible _common_ ancestor" but in this case, the
result of "git merge-base A B C" is not an ancestor of C (even with --all
option). So perhaps we need a better definition.
> Base between A and B is that "*", and you are correct to say that it is
> an ancestor of the "*" that is output from the command; base between A
> and C is the parent of "*", and again you are correct to say it is
> ancestor of the "*" that is output from the command.
>
> But if we output any other commit between "*" and A from the command, it
> still satisifies your condition. "The merge base between A and each of
> B, C,... should be an ancestor of what is output". In order to satisify
> your condition, in the extreme case, we could even output A. Both the
> merge base between A and B, and the merge base between A and C, would be
> an ancestor of A.
>
> So your description may not be incorrect, but I think it completely
> misses the point of what is being computed.
>
> > Author
> > ------
> > diff --git a/builtin-merge-base.c b/builtin-merge-base.c
> > index 1cb2925..f2c9756 100644
> > --- a/builtin-merge-base.c
> > +++ b/builtin-merge-base.c
> > @@ -2,9 +2,11 @@
> > #include "cache.h"
> > #include "commit.h"
> >
> > -static int show_merge_base(struct commit *rev1, struct commit *rev2,
> > int show_all) +static int show_merge_base(struct commit *rev1, int
> > prev2_nr, + struct commit **prev2, int show_all)
> > {
> > - struct commit_list *result = get_merge_bases(rev1, rev2, 0);
> > + struct commit_list *result = get_merge_bases_many(rev1, prev2_nr,
> > + prev2, 0);
>
> This is just style, but if you must break lines somewhere, I'd prefer to
> have prev2_nr and prev2 on the same line, like this:
>
> struct commit_list *result = get_merge_bases_many(rev1,
> prev2_nr, prev2, 0);
>
> because they logically belong to each other. Further, I think this
> 84-column single-line statement is perfectly fine as well in this case:
>
> struct commit_list *result = get_merge_bases_many(rev1, prev2_nr, prev2,
> 0);
>
> I would probably do this myself in this case, though:
>
> struct commit_list *result;
>
> result = get_merge_bases_many(rev1, prev2_nr, prev2, 0);
I used that in v3.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Jeff King @ 2008-07-28 6:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807261511490.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 03:13:26PM +0200, Johannes Schindelin wrote:
> > Also, while I have your attention, Junio, here is another bug fix
> > that should go into 1.6.0. I posted the patch as a "how about this" deep
> > in a thread and got no response (which means no complaints, right?).
>
> Again it is in a thread...
Heh. Point taken.
My meaning was "you, Junio, did not see this because it was in another
thread, so I am pointing it out to you" but the irony of the rest of the
statement was lost on me during the original writing.
> I deem this patch obviously correct, and your reasoning as to what an
> empty parameter should mean makes sense.
Thank you for reviewing, anyway. ;)
Here is a re-post with a test for the new behavior added in (and an
extra test just to make sure --template works at all. It does get used
by test-lib, so we were implicitly checking it to some degree, but it's
entirely possible that it could fail and the tests wouldn't necessarily
notice (e.g., if it accidentally used an installed set of templates
instead)).
-- >8 --
init: handle empty "template" parameter
If a user passes "--template=", then our template parameter
is blank. Unfortunately, copy_templates() assumes it has at
least one character, and does all sorts of bad things like
reading from template[-1] and then proceeding to link all of
'/' into the .git directory.
This patch just checks for that condition in copy_templates
and aborts. As a side effect, this means that --template=
now has the meaning "don't copy any templates."
---
builtin-init-db.c | 2 ++
t/t0001-init.sh | 26 ++++++++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 38b4fcb..baf0d09 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -117,6 +117,8 @@ static void copy_templates(const char *template_dir)
template_dir = getenv(TEMPLATE_DIR_ENVIRONMENT);
if (!template_dir)
template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
+ if (!template_dir[0])
+ return;
strcpy(template_path, template_dir);
template_len = strlen(template_path);
if (template_path[template_len-1] != '/') {
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 2a38d98..620da5b 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -141,4 +141,30 @@ test_expect_success 'reinit' '
test_cmp again/empty again/err2
'
+test_expect_success 'init with --template' '
+ mkdir template-source &&
+ echo content >template-source/file &&
+ (
+ mkdir template-custom &&
+ cd template-custom &&
+ git init --template=../template-source
+ ) &&
+ test_cmp template-source/file template-custom/.git/file
+'
+
+test_expect_success 'init with --template (blank)' '
+ (
+ mkdir template-plain &&
+ cd template-plain &&
+ git init
+ ) &&
+ test -f template-plain/.git/info/exclude &&
+ (
+ mkdir template-blank &&
+ cd template-blank &&
+ git init --template=
+ ) &&
+ ! test -f template-blank/.git/info/exclude
+'
+
test_done
--
1.6.0.rc1.155.gd3310
^ permalink raw reply related
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Junio C Hamano @ 2008-07-28 5:58 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217224228-31303-2-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> ... It is either used as
> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
> (2 directories).
I thought Hannes already fixed that one; we shouldn't have the latter.
^ permalink raw reply
* [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Steffen Prohaska @ 2008-07-28 5:50 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Steffen Prohaska
In-Reply-To: <1217224228-31303-1-git-send-email-prohaska@zib.de>
This might solve a fundamental problem we have with the
computation of system directories based on relative paths
in combination with the new gitexecpath 'libexec/git-core'.
The problem is that the program 'git' is hardlinked to
directories with different depth. It is either used as
'bin/git' (1 directory) or as 'libexec/git-core/git-*'
(2 directories). Thus, using the same relative path
in system_path() yields different results when starting from the
two locations. I recognized the problem because /etc/gitconfig
is no longer be read.
The patch below might fix the problem by always calling 'bin/git'
for builtin commands. The computation in system_path() would
always start from 'bin' and thus yields predictable results. I
am not sure however if it fully solves the problem because other
code paths might run the dashed forms directly.
I think the only way to verify correctness would be to stop
installing the dashed forms for builtins. If they were not
installed they could not be called. The only entry point for all
builtins would be 'bin/git'. I don't think we want to stop
installing the dashed forms right away.
So what shall we do?
Steffen
-- 8< --
We prefer running the dashless form, so we should use it in
MinGW's start_command(), too.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
run-command.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/run-command.c b/run-command.c
index 6e29fdf..a3b28a6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -119,9 +119,8 @@ int start_command(struct child_process *cmd)
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
- const char *sargv0 = cmd->argv[0];
+ const char **sargv = cmd->argv;
char **env = environ;
- struct strbuf git_cmd;
if (cmd->no_stdin) {
s0 = dup(0);
@@ -165,9 +164,7 @@ int start_command(struct child_process *cmd)
}
if (cmd->git_cmd) {
- strbuf_init(&git_cmd, 0);
- strbuf_addf(&git_cmd, "git-%s", cmd->argv[0]);
- cmd->argv[0] = git_cmd.buf;
+ cmd->argv = prepare_git_cmd(cmd->argv);
}
cmd->pid = mingw_spawnvpe(cmd->argv[0], cmd->argv, env);
@@ -175,9 +172,9 @@ int start_command(struct child_process *cmd)
if (cmd->env)
free_environ(env);
if (cmd->git_cmd)
- strbuf_release(&git_cmd);
+ free(cmd->argv);
- cmd->argv[0] = sargv0;
+ cmd->argv = sargv;
if (s0 >= 0)
dup2(s0, 0), close(s0);
if (s1 >= 0)
--
1.6.0.rc0.79.gb0320
^ 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