* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: Junio C Hamano @ 2013-01-30 3:08 UTC (permalink / raw)
To: John Keeping; +Cc: David Aguilar, git
In-Reply-To: <20130129230607.GG1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Tue, Jan 29, 2013 at 02:55:26PM -0800, Junio C Hamano wrote:
> ...
>> I can work with John to get this part into a shape to support his
>> extended use sometime toward the end of this week, by which time
>> hopefully you have some time to comment on the result. John, how
>> does that sound?
>
> My email crossed with yours - that sounds good to me. If
> da/mergetool-docs is in a reasonable state by tomorrow evening (GMT) I
> should be able to have a look at it then - if not I'm happy to hold off
> longer.
Heh, I actually was hoping that you will send in a replacement for
David's patch ;-)
Here is what I will squash into the one we have been discussing. In
a few hours, I expect I'll be able to push this out in the 'pu'
branch.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 29 Jan 2013 18:57:55 -0800
Subject: [PATCH] [SQUASH] mergetools: tweak show_tool_names and its users
Use show_tool_names as a function to produce output, not as a
function to compute a string. Indicate if any output was given
with its return status, so that the caller can say "if it didn't
give any output, I'll say this instead" easily.
To be squashed into the previous; no need to keep this log message.
---
git-mergetool--lib.sh | 30 +++++++++++++++++-------------
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 135da96..79cbdc7 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -22,7 +22,7 @@ is_available () {
show_tool_names () {
condition=${1:-true} per_line_prefix=${2:-} preamble=${3:-}
- ( cd "$MERGE_TOOLS_DIR" && ls -1 * ) |
+ ( cd "$MERGE_TOOLS_DIR" && ls ) |
while read toolname
do
if setup_tool "$toolname" 2>/dev/null &&
@@ -36,6 +36,7 @@ show_tool_names () {
printf "%s%s\n" "$per_line_prefix" "$tool"
fi
done
+ test -n "$preamble"
}
diff_mode() {
@@ -236,27 +237,30 @@ list_merge_tool_candidates () {
show_tool_help () {
tool_opt="'git ${TOOL_MODE}tool --tool-<tool>'"
- available=$(show_tool_names 'mode_ok && is_available' '\t\t' \
- "$tool_opt may be set to one of the following:")
- unavailable=$(show_tool_names 'mode_ok && ! is_available' '\t\t' \
- "The following tools are valid, but not currently available:")
- if test -n "$available"
+
+ tab=' ' av_shown= unav_shown=
+
+ if show_tool_names 'mode_ok && is_available' "$tab$tab" \
+ "$tool_opt may be set to one of the following:"
then
- echo "$available"
+ av_shown=yes
else
echo "No suitable tool for 'git $cmd_name --tool=<tool>' found."
+ av_shown=no
fi
- if test -n "$unavailable"
+
+ if show_tool_names 'mode_ok && ! is_available' "$tab$tab" \
+ "The following tools are valid, but not currently available:"
then
- echo
- echo "$unavailable"
+ unav_shown=yes
fi
- if test -n "$unavailable$available"
- then
+
+ case ",$av_shown,$unav_shown," in
+ *,yes,*)
echo
echo "Some of the tools listed above only work in a windowed"
echo "environment. If run in a terminal-only session, they will fail."
- fi
+ esac
exit 0
}
--
1.8.1.2.555.gedafe79
^ permalink raw reply related
* Re: [PATCH/RFC 0/6] commit caching
From: Duy Nguyen @ 2013-01-30 3:31 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130129091434.GA6975@sigill.intra.peff.net>
On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@peff.net> wrote:
> The timings from this one are roughly similar to what I posted earlier.
> Unlike the earlier version, this one keeps the data for a single commit
> together for better cache locality (though I don't think it made a big
> difference in my tests, since my cold-cache timing test ends up touching
> every commit anyway). The short of it is that for an extra 31M of disk
> space (~4%), I get a warm-cache speedup for "git rev-list --all" of
> ~4.2s to ~0.66s.
Some data point on caching 1-parent vs 2-parent commits on webkit
repo, 26k commits. With your changes (caching 2-parent commits), the
.commits file takes 2241600 bytes. "rev-list --all --quiet":
0.06user 0.00system 0:00.08elapsed 95%CPU (0avgtext+0avgdata 26288maxresident)k
0inputs+0outputs (0major+2094minor)pagefaults 0swaps
With caching 1-parent commits only, the .commits file takes 1707900
bytes (30% less), the same rev-list command:
0.07user 0.00system 0:00.07elapsed 96%CPU (0avgtext+0avgdata 24144maxresident)k
0inputs+0outputs (0major+1960minor)pagefaults 0swaps
Compared to the timing without caching at all:
0.72user 0.02system 0:00.76elapsed 98%CPU (0avgtext+0avgdata 108976maxresident)k
0inputs+0outputs (0major+7272minor)pagefaults 0swaps
The performance loss in 1-parent case is not significant while disk
saving is (although it'll be less impressive after you do Shawn's
suggestion not storing SHA-1 directly)
--
Duy
^ permalink raw reply
* Re: [PATCH v2 3/4] mergetool--lib: Add functions for finding available tools
From: Junio C Hamano @ 2013-01-30 3:34 UTC (permalink / raw)
To: John Keeping; +Cc: David Aguilar, git
In-Reply-To: <7vwquvmkon.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Heh, I actually was hoping that you will send in a replacement for
> David's patch ;-)
>
> Here is what I will squash into the one we have been discussing. In
> a few hours, I expect I'll be able to push this out in the 'pu'
> branch.
I ended up doing this a bit differently; will push out the result
after merging the other topics to 'pu'.
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Duy Nguyen @ 2013-01-30 3:36 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130129091610.GD9999@sigill.intra.peff.net>
On Tue, Jan 29, 2013 at 4:16 PM, Jeff King <peff@peff.net> wrote:
> +int commit_metapack(unsigned char *sha1,
> + uint32_t *timestamp,
> + unsigned char **tree,
> + unsigned char **parent1,
> + unsigned char **parent2)
> +{
Nit picking. tree, parent1 and parent2 can/should be "const unsigned char **".
--
Duy
^ permalink raw reply
* Re: [PATCH 2/6] strbuf: add string-chomping functions
From: Michael Haggerty @ 2013-01-30 5:00 UTC (permalink / raw)
To: Jeff King; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <20130129111028.GA11055@sigill.intra.peff.net>
On 01/29/2013 12:10 PM, Jeff King wrote:
> On Tue, Jan 29, 2013 at 11:15:34AM +0100, Michael Haggerty wrote:
>> Please document the new functions in
>> Documentation/technical/api-strbuf.txt. Personally I would also
>> advocate a "docstring" in the header file, but obviously that preference
>> is the exception rather than the rule in the git project :-(
>
> Will do. I need to document the metapack functions, too, so I was thinking
> about experimenting with some inline documentation systems.
That would be great; it would make future API documentation much easier
and therefore (hopefully) more common.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH v3 1/4] mergetool--lib: simplify command expressions
From: David Aguilar @ 2013-01-30 6:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, John Keeping
In-Reply-To: <7vip6foc9m.fsf@alter.siamese.dyndns.org>
Update variable assignments to always use $(command "$arg")
in their RHS instead of "$(command "$arg")" as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding "echo" and $(command) substitutions completely.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This is a replacement patch for what's currently in pu to
fix the empty "test -z" expression.
git-mergetool--lib.sh | 42 ++++++++++++++++++------------------------
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 1d0fb12..1ff6d38 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -32,17 +32,10 @@ check_unchanged () {
fi
}
-valid_tool_config () {
- if test -n "$(get_merge_tool_cmd "$1")"
- then
- return 0
- else
- return 1
- fi
-}
-
valid_tool () {
- setup_tool "$1" || valid_tool_config "$1"
+ setup_tool "$1" && return 0
+ cmd=$(get_merge_tool_cmd "$1")
+ test -n "$cmd"
}
setup_tool () {
@@ -96,14 +89,13 @@ setup_tool () {
}
get_merge_tool_cmd () {
- # Prints the custom command for a merge tool
merge_tool="$1"
if diff_mode
then
- echo "$(git config difftool.$merge_tool.cmd ||
- git config mergetool.$merge_tool.cmd)"
+ git config "difftool.$merge_tool.cmd" ||
+ git config "mergetool.$merge_tool.cmd"
else
- echo "$(git config mergetool.$merge_tool.cmd)"
+ git config "mergetool.$merge_tool.cmd"
fi
}
@@ -114,7 +106,7 @@ run_merge_tool () {
GIT_PREFIX=${GIT_PREFIX:-.}
export GIT_PREFIX
- merge_tool_path="$(get_merge_tool_path "$1")" || exit
+ merge_tool_path=$(get_merge_tool_path "$1") || exit
base_present="$2"
status=0
@@ -145,7 +137,7 @@ run_merge_tool () {
# Run a either a configured or built-in diff tool
run_diff_cmd () {
- merge_tool_cmd="$(get_merge_tool_cmd "$1")"
+ merge_tool_cmd=$(get_merge_tool_cmd "$1")
if test -n "$merge_tool_cmd"
then
( eval $merge_tool_cmd )
@@ -158,11 +150,11 @@ run_diff_cmd () {
# Run a either a configured or built-in merge tool
run_merge_cmd () {
- merge_tool_cmd="$(get_merge_tool_cmd "$1")"
+ merge_tool_cmd=$(get_merge_tool_cmd "$1")
if test -n "$merge_tool_cmd"
then
- trust_exit_code="$(git config --bool \
- mergetool."$1".trustExitCode || echo false)"
+ trust_exit_code=$(git config --bool \
+ "mergetool.$1.trustExitCode" || echo false)
if test "$trust_exit_code" = "false"
then
touch "$BACKUP"
@@ -253,7 +245,7 @@ guess_merge_tool () {
# Loop over each candidate and stop when a valid merge tool is found.
for i in $tools
do
- merge_tool_path="$(translate_merge_tool_path "$i")"
+ merge_tool_path=$(translate_merge_tool_path "$i")
if type "$merge_tool_path" >/dev/null 2>&1
then
echo "$i"
@@ -300,9 +292,11 @@ get_merge_tool_path () {
fi
if test -z "$merge_tool_path"
then
- merge_tool_path="$(translate_merge_tool_path "$merge_tool")"
+ merge_tool_path=$(translate_merge_tool_path "$merge_tool")
fi
- if test -z "$(get_merge_tool_cmd "$merge_tool")" &&
+
+ merge_tool_cmd=$(get_merge_tool_cmd "$merge_tool")
+ if test -z "$merge_tool_cmd" &&
! type "$merge_tool_path" >/dev/null 2>&1
then
echo >&2 "The $TOOL_MODE tool $merge_tool is not available as"\
@@ -314,11 +308,11 @@ get_merge_tool_path () {
get_merge_tool () {
# Check if a merge tool has been configured
- merge_tool="$(get_configured_merge_tool)"
+ merge_tool=$(get_configured_merge_tool)
# Try to guess an appropriate merge tool if no tool has been set.
if test -z "$merge_tool"
then
- merge_tool="$(guess_merge_tool)" || exit
+ merge_tool=$(guess_merge_tool) || exit
fi
echo "$merge_tool"
}
--
1.8.0.9.g3370a50
^ permalink raw reply related
* Re: [PATCH 3/6] introduce pack metadata cache files
From: Jeff King @ 2013-01-30 6:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <7v622friy7.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 09:35:12AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > +static void write_meta_header(struct metapack_writer *mw, const char *id,
> > + uint32_t version)
> > +{
> > + version = htonl(version);
> > +
> > + sha1write(mw->out, "META", 4);
> > + sha1write(mw->out, "\0\0\0\1", 4);
> > + sha1write(mw->out, mw->pack->sha1, 20);
> > + sha1write(mw->out, id, 4);
> > + sha1write(mw->out, &version, 4);
> > +}
>
> It seems that you are very close to actually having a plumbing that
> could also do the pack .idx files. Until/unless that can be done, I
> am not sure how much benefit we would be getting from a file format
> that records a subtype "id" and a generic "META" type, instead of
> just a single "id" as the type ehader. But it is OK to use 8 extra
> bytes if we can potentially gain something later.
Yeah, I considered going that route. I had initially envisioned having a
generic META file type that provided some services (like fixed-size
records), and then having individual subtypes below that. But as I
simplified the design, the META format became pretty much pointless. I
left it in as the 8 bytes are not really a big problem, and it means we
can treat metapacks generically in some cases without necessarily
knowing what is in them. But I don't have a specific use case in mind,
so perhaps it is just useless and confusing. I don't mind simplifying.
> Shouldn't id be validated with at least something like
>
> if (strlen(id) < 3)
> die("Bad id: %s", id);
>
> to catch a call
>
> write_meta_header(&mw, "me", 47);
>
> that will stuff 'm', 'e', NUL and the garbage the compiler/linker
> combo has placed after that constant string in the 4-byte id field?
Yes, the id does need to be at least 4 bytes. Since the id is intended
to be a static string, I had planned to just document the requirement in
the API documentation. I don't mind putting in a run-time check. I had
originally had a separate "id" parameter that could be "char id[4]", but
found that it was just redundant with the "name" parameter: you ended up
passing ("commit", "CMIT") or similar.
> > + strbuf_addstr(&path, pack_idx);
> > + strbuf_chompstr(&path, ".idx");
> > + strbuf_addch(&path, '.');
> > + strbuf_addstr(&path, name);
>
> Your chompstr() does not even validate if the given name ends with
> ".idx",
Yeah, my intent was that it would be liberal in its input (i.e., take
just "pack-*"). E.g., you can run "git metapack pack/pack-XXXX".
> so this sounds like a glorified way to say
>
> strbuf_splice(&path, path->len - strlen("idx"), strlen("idx"),
> name, strlen(name));
>
> to me.
Yup, though my version handles edge cases by not chomping (e.g., what
does splice do when path->len is less than 3?).
> > +void metapack_writer_finish(struct metapack_writer *mw)
> > +{
> > + const char *tmp = mw->out->name;
> > +
> > + sha1close(mw->out, NULL, CSUM_FSYNC);
> > + if (rename(tmp, mw->path))
> > + die_errno("unable to rename temporary metapack file");
>
> Who is responsible for running adjust_shared_perm()? The caller, or
> this function?
I didn't think about it at all, but it seems pretty obvious to me that
this function should do so. Thanks for pointing it out.
-Peff
^ permalink raw reply
* Re: [PATCH 3/6] introduce pack metadata cache files
From: Jeff King @ 2013-01-30 6:50 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <CACsJy8Af9g9Tdqr0dXyucq-M2aP5U2HvX3ANSsabqtuX=w4Q0w@mail.gmail.com>
On Wed, Jan 30, 2013 at 08:30:57AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:15 PM, Jeff King <peff@peff.net> wrote:
> > +static void write_meta_header(struct metapack_writer *mw, const char *id,
> > + uint32_t version)
> > +{
> > + version = htonl(version);
> > +
> > + sha1write(mw->out, "META", 4);
> > + sha1write(mw->out, "\0\0\0\1", 4);
> > + sha1write(mw->out, mw->pack->sha1, 20);
> > + sha1write(mw->out, id, 4);
> > + sha1write(mw->out, &version, 4);
> > +}
>
> Because you go with all-commit-info-in-one-file, perhaps we should
> have an uint32_t bitmap to describe what info this cache contains? So
> far we need 4 bits for date, tree, 1st and 2nd parents (yes, I still
> want to check if storing 1-parent commits only gains us anything on
> some other repos). When commit count comes, it can take the fifth bit.
> Reachability bitmap offsets can take the sixth bit, if we just append
> the bitmaps at the end of the same file.
I thought about having some programmatic self-describing header like
that. But it makes the implementation much harder to verify, and it is
not like there is much point in picking and choosing those bits. My plan
was to do a combination of:
1. Put truly optional bits into a separate metapack (e.g.,
reachability bitmaps).
2. When something becomes obviously obsolete (e.g., we move to
generation numbers instead of timestamps in commits), bump the
version number.
-Peff
^ permalink raw reply
* Re: [PATCH v3 1/4] mergetool--lib: simplify command expressions
From: Junio C Hamano @ 2013-01-30 7:04 UTC (permalink / raw)
To: David Aguilar; +Cc: git, John Keeping
In-Reply-To: <1359526854-25132-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Update variable assignments to always use $(command "$arg")
> in their RHS instead of "$(command "$arg")" as the latter
> is harder to read. Make get_merge_tool_cmd() simpler by
> avoiding "echo" and $(command) substitutions completely.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
> This is a replacement patch for what's currently in pu to
> fix the empty "test -z" expression.
Thanks.
I think I already pushed out what I locally amended; will double
check.
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-01-30 7:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <7vy5fbq48t.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 09:38:10AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > +int commit_metapack(unsigned char *sha1,
> > + uint32_t *timestamp,
> > + unsigned char **tree,
> > + unsigned char **parent1,
> > + unsigned char **parent2)
> > +{
> > + struct commit_metapack *p;
> > +
> > + prepare_commit_metapacks();
> > + for (p = commit_metapacks; p; p = p->next) {
> > + unsigned char *data;
> > + int pos = sha1_entry_pos(p->index, 20, 0, 0, p->nr, p->nr, sha1);
>
> This is a tangent, but isn't it about time to rip out the check for
> GIT_USE_LOOKUP in find_pack_entry_one(), I wonder.
Rip it out and always use sha1_entry_pos, or rip it out and never use
it? I have never been able to measure any speedup from it; I just use it
here to avoid rewriting the binary search myself. I do not think there
is any disadvantage to using it, so I'd be in favor of just
standardizing on it for any sha1 binary searches.
> These cached properties of a single commit will not change no matter
> which pack it appears in, and it feels logically wrong, especially
> when you record these object names in the full SHA-1 form, to tie a
> "commit metapack" to a pack. Logically there needs only one commit
> metapack that describes all the commits known to the repository when
> the metapack was created.
True. I had originally envisioned it as tied to the packfile to help
manage the lifecycle. You know you need to generate a metapack for some
objects when they get packed, and you know you can throw it away when
the associated pack goes away. And it means you can verify the integrity
of the metapack by matching it to a particular packfile.
However, if you just have a commit cache, you can always blow the whole
thing away and regenerate it for all objects in the repo. It does not
have tied to a pack (you do end up doing some extra work at regeneration
when you are not doing a full repack, but it is really not enough to
worry about).
> In order to reduce the disk footprint and I/O cost, the future
> direction for this mechanism may want to point into an existing
> store of SHA-1 hashes with a shorter file offset, and the .idx file
> could be such a store, and in order to move in that direction, you
> cannot avoid tying a metapack to a pack.
Yes. That was not one of my original goals for the commit cache, but I
do think it's a useful direction to go in. And reachability bitmaps
(which would eventually be their own metapacks) would generally want to
be per-pack, too, for the same reason.
> > + *tail = &commit_list_insert(c, *tail)->next;
> > +}
>
> It feels somewhat wasteful to:
>
> - use commit_list for this, rather than an array of commit
> objects. If you have a rough estimate of the number of commits
> in the pack, you could just preallocate a single array and use
> ALLOC_GROW() on it, no?
We don't have a rough estimate, but yes, we could just use an array and
trust ALLOC_GROW to be reasonable. The use of commit_list did not have a
particular reason other than that it was simple (an array means stuffing
the array pointer and the nr and alloc counts into a struct to get to
the callback). The performance of writing the cache is dominated by
accessing the objects themselves, anyway. I don't mind changing it,
though, if you think it's clearer as an array.
> - iterate over the .idx file and run sha1_object_info() and
> parse_commit() on many objects in the SHA-1 order. Iterating in
> the way builtin/pack-objects.c::get_object_details() does avoids
> jumping around in existing packfiles, which may be more
> efficient, no?
Probably, though generating the complete commit cache for linux-2.6.git
takes only about 7 seconds on my machine. I wasn't too concerned with
optimizing generation, since it will typically be dwarfed by repacking
costs. It might make more of a difference for doing a metapack on all
objects (e.g., reachability bitmaps).
The reason I do it in .idx order is that it feeds the callback in sorted
order, so a writer could in theory just use that output as-is (and my
initial version did that, as it wrote separate metapacks for each
element). This version now puts all data elements together (for cache
locality), and builds the in-memory list so we do not have to re-do
sha1_object_info repeatedly. So it could very easily just generate the
list in pack order and sort it at the end.
I'll look into that for the next version.
-Peff
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-01-30 7:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <7vtxpzq2uv.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 10:08:08AM -0800, Junio C Hamano wrote:
> > In order to reduce the disk footprint and I/O cost, the future
> > direction for this mechanism may want to point into an existing
> > store of SHA-1 hashes with a shorter file offset, and the .idx file
> > could be such a store, and in order to move in that direction, you
> > cannot avoid tying a metapack to a pack.
>
> Have you considered if we can extend the .idx format version 2
> without actually having to bump the version number? My quick
> reading of check_packed_git_idx() tells me that we have a gap after
> the "large offset table" that we can place extensions, but I may be
> mistaken. If we indeed can, then perhaps adding a series of
>
> 4-byte "id" header
> 4-byte extension length (or 8-byte)
> ... N-byte worth of extension data ...
>
> followed by
>
> 20-byte SHA-1 checksum of all the extension sections
> 8-byte file offset to the first extension section
I considered it, but didn't look into it closely. My feeling was that it
added extra complexity, without adding any real advantage that a
separate file would not.
>From this:
> Then it will be very natural for the extension data that store the
> commit metainfo to name objects in the pack the .idx file describes
> by the offset in the SHA-1 table.
I guess your argument is that putting it all in the same file makes it
more natural for there to be a data dependency.
> As we always say, .idx is a local cache and bumping its version is
> not a huge headache compared to other longer term storage items.
True, but it is even less headache if the file is totally separate and
optional.
-Peff
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Jeff King @ 2013-01-30 7:12 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <CACsJy8COCpr_CvQPhBFtVnsKztA3xgo01=zKG4WPcFfCbNTmgw@mail.gmail.com>
On Wed, Jan 30, 2013 at 10:36:10AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:16 PM, Jeff King <peff@peff.net> wrote:
> > +int commit_metapack(unsigned char *sha1,
> > + uint32_t *timestamp,
> > + unsigned char **tree,
> > + unsigned char **parent1,
> > + unsigned char **parent2)
> > +{
>
> Nit picking. tree, parent1 and parent2 can/should be "const unsigned char **".
Thanks, I'll fix it in the next version.
^ permalink raw reply
* Re: [PATCH 4/6] introduce a commit metapack
From: Junio C Hamano @ 2013-01-30 7:17 UTC (permalink / raw)
To: Jeff King; +Cc: git, Duy Nguyen, Shawn O. Pearce
In-Reply-To: <20130130071209.GD11147@sigill.intra.peff.net>
> True, but it is even less headache if the file is totally separate and
> optional.
Once you start thinking about using an offset to some list of SHA-1,
perhaps? A section inside the same file can never go out of sync.
Also a longer-term advantage is that you can teach index-pack to do
this.
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Jeff King @ 2013-01-30 7:18 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, Shawn O. Pearce
In-Reply-To: <CACsJy8BE3LdxbZzdQXuvEJop23KnnLbCTgPos9CywKV7EY2q9g@mail.gmail.com>
On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@peff.net> wrote:
> > The timings from this one are roughly similar to what I posted earlier.
> > Unlike the earlier version, this one keeps the data for a single commit
> > together for better cache locality (though I don't think it made a big
> > difference in my tests, since my cold-cache timing test ends up touching
> > every commit anyway). The short of it is that for an extra 31M of disk
> > space (~4%), I get a warm-cache speedup for "git rev-list --all" of
> > ~4.2s to ~0.66s.
>
> Some data point on caching 1-parent vs 2-parent commits on webkit
> repo, 26k commits. With your changes (caching 2-parent commits), the
> .commits file takes 2241600 bytes. "rev-list --all --quiet":
Hmm. My webkit repo has zero merges in it (though it is the older
svn-based one). What percentage of the one you have are merges? How does
your 1-parent cache perform on something like git.git, where about 25%
of all commits are merges?
> The performance loss in 1-parent case is not significant while disk
> saving is (although it'll be less impressive after you do Shawn's
> suggestion not storing SHA-1 directly)
Yeah, I think moving to offsets instead of sha1s is going to be a big
enough win that it won't matter anymore.
-Peff
^ permalink raw reply
* Re: [PATCH v2 0/3] transfer.hiderefs
From: Junio C Hamano @ 2013-01-30 7:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vham0tvus.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Please take this as just a preview of early WIP. I think I may end
> up doing moderate amount of refactoring as a preparatory step before
> these patches, so nitpick-reviews are likely to become waste of
> reviewer's time at this point.
I've pushed out a mostly-done reroll on 'pu'; I'll send them out as
patches for review tomorrow. I think I am making a good progress.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Jeff King @ 2013-01-30 7:43 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: Junio C Hamano, git, Krzysztof Mazur, Michal Nazarewicz
In-Reply-To: <7vvcafojf4.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 11:53:19AM -0800, Junio C Hamano wrote:
> Either way it still encourages a plaintext password to be on disk,
> which may not be what we want, even though it may be slight if not
> really much of an improvement. Again the Help-for-users has this
> amusing bit:
I do not mind a .netrc or .authinfo parser, because while those formats
do have security problems, they are standard files that may already be
in use. So as long as we are not encouraging their use, I do not see a
problem in supporting them (and we already do the same with curl's netrc
support).
But it would probably make sense for send-email to support the existing
git-credential subsystem, so that it can take advantage of secure
system-specific storage. And that is where we should be pointing new
users. I think contrib/mw-to-git even has credential support written in
perl, so it would just need to be factored out to Git.pm.
-Peff
^ permalink raw reply
* Re: Updating shared ref from remote helper, or fetch hook
From: Jed Brown @ 2013-01-30 8:06 UTC (permalink / raw)
To: git; +Cc: Max Horn
In-Reply-To: <87ehh5lw9j.fsf@59A2.org>
Jed Brown <jed@59A2.org> writes:
> I'm working on an hg remote helper that uses git notes for the sha1
> revision, so that git users can more easily refer to specific commits
> when communicating with hg users. Since there may be multiple
> concurrent fast-import streams, I write the notes to a private ref
> (refs/notes/hg-REMOTE), to be merged eventually using
>
> git notes --ref hg merge hg-REMOTE*
A related issue is that when a remote helper replies to an 'import' with
_only_ a commit in refs/notes/, git (fetch or pull) produces an error
message like
error: refs/notes/hg-84b3865b750a567acb16929c21e14c4a45a5639b does not point to a valid object
but successfully updates the ref (which is indeed valid) and returns
0. I have not been able to determine what exactly git thinks is
invalid. As long as there is at least one non-notes commit in the
stream, no such error message is produced.
Is this behavior intended?
^ permalink raw reply
* Re: [PATCH/RFC 0/6] commit caching
From: Duy Nguyen @ 2013-01-30 8:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130130071839.GF11147@sigill.intra.peff.net>
On Wed, Jan 30, 2013 at 2:18 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> On Tue, Jan 29, 2013 at 4:14 PM, Jeff King <peff@peff.net> wrote:
>> > The timings from this one are roughly similar to what I posted earlier.
>> > Unlike the earlier version, this one keeps the data for a single commit
>> > together for better cache locality (though I don't think it made a big
>> > difference in my tests, since my cold-cache timing test ends up touching
>> > every commit anyway). The short of it is that for an extra 31M of disk
>> > space (~4%), I get a warm-cache speedup for "git rev-list --all" of
>> > ~4.2s to ~0.66s.
>>
>> Some data point on caching 1-parent vs 2-parent commits on webkit
>> repo, 26k commits. With your changes (caching 2-parent commits), the
>> .commits file takes 2241600 bytes. "rev-list --all --quiet":
>
> Hmm. My webkit repo has zero merges in it (though it is the older
> svn-based one). What percentage of the one you have are merges? How does
> your 1-parent cache perform on something like git.git, where about 25%
> of all commits are merges?
git.git performs worse with 1-parent cache. But the point is it should
be customizable.
>> The performance loss in 1-parent case is not significant while disk
>> saving is (although it'll be less impressive after you do Shawn's
>> suggestion not storing SHA-1 directly)
>
> Yeah, I think moving to offsets instead of sha1s is going to be a big
> enough win that it won't matter anymore.
Yeah, if we use uint32_t instead of sha-1, the cache is just about
400k 2 parents for webkit, 312k for 1 parent. The total size is so
small that reduction does not really matter anymore.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH v2] CodingGuidelines: add Python coding guidelines
From: Michael Haggerty @ 2013-01-30 10:05 UTC (permalink / raw)
To: John Keeping; +Cc: git
In-Reply-To: <20130129190844.GB1342@serenity.lan>
On 01/29/2013 08:08 PM, John Keeping wrote:
> These are kept short by simply deferring to PEP-8. Most of the Python
> code in Git is already very close to this style (some things in contrib/
> are not).
>
> Rationale for version suggestions:
>
> - Amongst the noise in [1], there isn't any disagreement about using
> 2.6 as a base (see also [2]), although Brandon Casey recently added
> support for 2.4 and 2.5 to git-p4 [3].
>
> - Restricting ourselves to 2.6+ makes aiming for Python 3 compatibility
> significantly easier [4].
>
> - Advocating Python 3 support in all scripts is currently unrealistic
> because:
>
> - 'p4 -G' provides output in a format that is very hard to use with
> Python 3 (and its documentation claims Python 3 is unsupported).
>
> - Mercurial does not support Python 3.
>
> - Bazaar does not support Python 3.
>
> - But we should try to make new scripts compatible with Python 3
> because all new Python development is happening on version 3 and the
> Python community will eventually stop supporting Python 2 [5].
>
> - Python 3.1 is required to support the 'surrogateescape' error handler
> for encoding/decodng filenames to/from Unicode strings and Python 3.0
> is not longer supported.
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/210329
> [2] http://article.gmane.org/gmane.comp.version-control.git/210429
> [3] http://thread.gmane.org/gmane.comp.version-control.git/214579
> [4] http://docs.python.org/3.3/howto/pyporting.html#try-to-support-python-2-6-and-newer-only
> [5] http://www.python.org/dev/peps/pep-0404/
>
> ---
> Changes since v1:
>
> - Set 3.1 as the minimum Python 3 version
>
> - Remove the section on Unicode literals - it just adds confusion and
> doesn't apply to the current code; we can deal with any issues if they
> ever arise.
>
> Documentation/CodingGuidelines | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> index 69f7e9b..db7a416 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -179,6 +179,19 @@ For C programs:
> - Use Git's gettext wrappers to make the user interface
> translatable. See "Marking strings for translation" in po/README.
>
> +For Python scripts:
> +
> + - We follow PEP-8 (http://www.python.org/dev/peps/pep-0008/).
> +
> + - As a minimum, we aim to be compatible with Python 2.6 and 2.7.
> +
> + - Where required libraries do not restrict us to Python 2, we try to
> + also be compatible with Python 3.1 and later.
> +
> + - We use the 'b' prefix for bytes literals. Note that even though
> + the Python documentation for version 2.6 does not mention this
> + prefix it is supported since version 2.6.0.
> +
> Writing Documentation:
>
> Every user-visible change should be reflected in the documentation.
>
Nit: s/it is supported/it has been supported/
I think this would be a good Python policy.
I would hate to junk up all Python code with things like
' '.encode('ascii')
though, so maybe we should establish a small Python library of
compatibility utilities (like a small "six"). It could contain b().
Another handy utility function could be
def check_python_version(minimum_v2=0x02060000,
minimum_v3=0x03010000)
which checks our default Python requirements by default, but is
overrideable by specific scripts if they know that they can deal with
older Python versions.
But I haven't had time to think of where to put such a library, how to
install it, etc.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [BUG] incorrect search result returned when using git log with a future date parameter
From: Caspar Zhang @ 2013-01-30 11:28 UTC (permalink / raw)
To: git; +Cc: Gris Ge, Junio C Hamano
Hi there,
when I'm using the commit limit option `--before/--until` when doing
`git log` search, I meet a bug when the upper-bound date is 10days later
in the future. Here is an example:
$ date +%F
2013-01-30
$ git log --oneline --since=2013-01-01 --until=2013-02-01
<several git log entry from 2013-01-01 to 2013-01-30 printed>
$ git log --oneline --since=2013-01-01 --until=2013-02-13
<null>
I debugged into the problem with ./test-date program in git source tree,
got:
$ ./test-date approxidate 2013-02-01
2013-02-01 -> 2013-02-01 10:47:13 +0000 // correctly parsed
$ ./test-date approxidate 2013-02-13
2013-02-13 -> 2013-01-02 10:47:20 +0000 // incorrectly parsed
When looking into the codes of date.c, in is_date() function, I found:
382 /* Be it commit time or author time, it does not make
383 * sense to specify timestamp way into the future. Make
384 * sure it is not later than ten days from now...
385 */
386 if (now + 10*24*3600 < specified)
387 return 0;
388 tm->tm_mon = r->tm_mon;
389 tm->tm_mday = r->tm_mday;
390 if (year != -1)
391 tm->tm_year = r->tm_year;
392 return 1;
If I comment Line 386 & 387 out, the parsing works correctly. So I guess
here is the cause of the problem.
Then I checked the git history, the change was introduced in commit
38035cf4 by Junio C Hamano (cc-ed):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
commit 38035cf4a51c48cccf6c5e3977130261bc0c03a7
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Apr 5 15:31:12 2006 -0700
date parsing: be friendlier to our European friends.
This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:
- Refuses to use the interpretation to put the date in the
future; recent kernel history has a commit made with
10/03/2006 which is recorded as October 3rd.
- Adds '.' as the possible year-month-date separator. We
learned from our European friends on the #git channel that
dd.mm.yyyy is the norm there.
- When the separator is '.', we prefer dd.mm.yyyy over
mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
dd/mm/yy[yy].
Signed-off-by: Junio C Hamano <junkio@cox.net>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It seems like the original commit was going to fix European date style,
but it fixed(?) the future date problem as well. However, this part of
fix is not perfect:
1) it makes date parsing not working correctly. (see my test examples
above).
IMO, it should be in another place (maybe in commit.c or somewhere
else?) we check if commit date is valid or not, instead of in the date
parsing function. A date parsing function should parse _all dates with
correctly format_, despite if it's an old date, or the date in the future.
2) from the test example I gave above, in fact the codes don't really
prevent git from accepting the changes with illegal date, e.g., if there
is a commit recorded as "2013-02-13", it will be parsed to "2013-01-02",
which is a legal (old) date, thus, this commit will be accepted, but
this is wrong.
My suggestion is we might need to revert the first part of commit
38035cf4 since this part of code doesn't work correctly and causes
problems; then we should create a new checking mechanism to prevent
those "future date commits" to be accepted in other functions. I'm not
able to do the second part since I'm not familiar with git codes yet.. :-(
Thoughts?
Caspar
^ permalink raw reply
* [BUG] incorrect search result returned when using git log with a future date parameter
From: Caspar Zhang @ 2013-01-30 11:30 UTC (permalink / raw)
To: git; +Cc: Gris Ge, Junio C Hamano
Hi there,
when I'm using the commit limit option `--before/--until` when doing
`git log` search, I meet a bug when the upper-bound date is 10days later
in the future. Here is an example:
$ date +%F
2013-01-30
$ git log --oneline --since=2013-01-01 --until=2013-02-01
<several git log entry from 2013-01-01 to 2013-01-30 printed>
$ git log --oneline --since=2013-01-01 --until=2013-02-13
<null>
I debugged into the problem with ./test-date program in git source tree,
got:
$ ./test-date approxidate 2013-02-01
2013-02-01 -> 2013-02-01 10:47:13 +0000 // correctly parsed
$ ./test-date approxidate 2013-02-13
2013-02-13 -> 2013-01-02 10:47:20 +0000 // incorrectly parsed
When looking into the codes of date.c, in is_date() function, I found:
382 /* Be it commit time or author time, it does not make
383 * sense to specify timestamp way into the future. Make
384 * sure it is not later than ten days from now...
385 */
386 if (now + 10*24*3600 < specified)
387 return 0;
388 tm->tm_mon = r->tm_mon;
389 tm->tm_mday = r->tm_mday;
390 if (year != -1)
391 tm->tm_year = r->tm_year;
392 return 1;
If I comment Line 386 & 387 out, the parsing works correctly. So I guess
here is the cause of the problem.
Then I checked the git history, the change was introduced in commit
38035cf4 by Junio C Hamano (cc-ed):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
commit 38035cf4a51c48cccf6c5e3977130261bc0c03a7
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Apr 5 15:31:12 2006 -0700
date parsing: be friendlier to our European friends.
This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:
- Refuses to use the interpretation to put the date in the
future; recent kernel history has a commit made with
10/03/2006 which is recorded as October 3rd.
- Adds '.' as the possible year-month-date separator. We
learned from our European friends on the #git channel that
dd.mm.yyyy is the norm there.
- When the separator is '.', we prefer dd.mm.yyyy over
mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
dd/mm/yy[yy].
Signed-off-by: Junio C Hamano <junkio@cox.net>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It seems like the original commit was going to fix European date style,
but it fixed(?) the future date problem as well. However, this part of
fix is not perfect:
1) it makes date parsing not working correctly. (see my test examples
above).
IMO, it should be in another place (maybe in commit.c or somewhere
else?) we check if commit date is valid or not, instead of in the date
parsing function. A date parsing function should parse _all dates with
correctly format_, despite if it's an old date, or the date in the future.
2) from the test example I gave above, in fact the codes don't really
prevent git from accepting the changes with illegal date, e.g., if there
is a commit recorded as "2013-02-13", it will be parsed to "2013-01-02",
which is a legal (old) date, thus, this commit will be accepted, but
this is wrong.
My suggestion is we might need to revert the first part of commit
38035cf4 since this part of code doesn't work correctly and causes
problems; then we should create a new checking mechanism to prevent
those "future date commits" to be accepted in other functions. I'm not
able to do the second part since I'm not familiar with git codes yet.. :-(
Thoughts?
Caspar
^ permalink raw reply
* Anybody know a website with up-to-date git documentation?
From: Max Horn @ 2013-01-30 11:46 UTC (permalink / raw)
To: git; +Cc: Scott Chacon
Hi,
does anybody know a website where one can view that latest git documentation? Here, "latest" means "latest release" (though being also able to access it for "next" would of course be a nice bonus, likewise for older versions). While I do have those docs on my local machine, I would like to access them online, too (e.g. easier to pointer people at this, I can access it from other machines, etc.).
My problem is that all sites I know of are outdated, and thus don't show recent improvements. Also, for many it is hard to determine for which version of git they carry documentation. Here are the contenders I know, and the problems they have:
* The closest I know is http://git-scm.com/ -- they fit the bill almost perfectly. Except that sadly, some pages that are crucial for me are permanently stuck at outdated versions, like http://git-scm.com/docs/git-remote-helpers which is stuck at 1.7.12.3. I tried contacting them about this for two months now, but to no avail (multiple bug reports, direct emails, etc. all went w/o reaction). Of course time and resources are limited, so I fully understand and respect that the people behind it (Scott Chacon in particular, who did an awesome job creating that site in the first place) have other priorities.
* http://www.kernel.org/pub/software/scm/git/docs/ was last updated in May 2012. No hints on who maintains this and how to contact them. Attempts to contact kernel.org webadmins to find out more were not answered either :-(. Anybody know more?
* http://schacon.github.com/git/git-remote-helpers.html was lasted updated in May 2011. I assume git-scm.com is supposed to replace it, though, as Scott Chacon made git-scm.com. (In that case, a redirect to git-scm.com might be nice *g* but of course is extra work)
* http://www.manpagez.com/man/1/git/ and http://man.he.net/man1/git at least document on each page from which git version it is taken. Unfortunately, both are stuck at the 1.7.x series.
* http://linux.die.net/man/1/git does not indicate the git version, but it seems to be a 1.7.x, too
Anybody know an up-to-date alternative? Or do I have to setup my own? :-(.
Cheers,
Max
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: John Keeping @ 2013-01-30 11:54 UTC (permalink / raw)
To: Max Horn; +Cc: git, Scott Chacon
In-Reply-To: <D6EAC791-63E2-4B0E-92AA-676112039BD9@quendi.de>
On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote:
> does anybody know a website where one can view that latest git
> documentation? Here, "latest" means "latest release" (though being
> also able to access it for "next" would of course be a nice bonus,
> likewise for older versions). While I do have those docs on my local
> machine, I would like to access them online, too (e.g. easier to
> pointer people at this, I can access it from other machines, etc.).
How about http://git-htmldocs.googlecode.com/git/ ?
It's just a directory listing of the git-htmldocs repository that Junio
maintains - the latest update was yesterday: Autogenerated HTML docs for
v1.8.1.2-422-g08c0e.
[I didn't know Google Code let you view the repository like that, but I
got there by clicking the "raw" link against one of the files so I
assume it's not likely to go away.]
John
^ permalink raw reply
* Re: Anybody know a website with up-to-date git documentation?
From: Sebastian Staudt @ 2013-01-30 11:56 UTC (permalink / raw)
To: Max Horn; +Cc: git
In-Reply-To: <20130130115439.GH1342@serenity.lan>
Hello Max,
git-scm.com is the best source and it's not outdated. It gets an
update after every single release of Git.
See e.g. http://git-scm.com/docs/git-config which was updated in the
current stable version.
It seems that git-remote-helper's documentation was just not updated
since version 1.7.12.3.
Best regards,
Sebastian
2013/1/30 John Keeping <john@keeping.me.uk>:
> On Wed, Jan 30, 2013 at 12:46:47PM +0100, Max Horn wrote:
>> does anybody know a website where one can view that latest git
>> documentation? Here, "latest" means "latest release" (though being
>> also able to access it for "next" would of course be a nice bonus,
>> likewise for older versions). While I do have those docs on my local
>> machine, I would like to access them online, too (e.g. easier to
>> pointer people at this, I can access it from other machines, etc.).
>
> How about http://git-htmldocs.googlecode.com/git/ ?
>
> It's just a directory listing of the git-htmldocs repository that Junio
> maintains - the latest update was yesterday: Autogenerated HTML docs for
> v1.8.1.2-422-g08c0e.
>
> [I didn't know Google Code let you view the repository like that, but I
> got there by clicking the "raw" link against one of the files so I
> assume it's not likely to go away.]
>
>
> John
> --
> 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: What's cooking in git.git (Jan 2013, #10; Sun, 27)
From: Pete Wyckoff @ 2013-01-30 12:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlibdyfdt.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Sun, 27 Jan 2013 22:45 -0800:
> * pw/git-p4-on-cygwin (2013-01-26) 21 commits
> - git p4: introduce gitConfigBool
> - git p4: avoid shell when calling git config
> - git p4: avoid shell when invoking git config --get-all
> - git p4: avoid shell when invoking git rev-list
> - git p4: avoid shell when mapping users
> - git p4: disable read-only attribute before deleting
> - git p4 test: use test_chmod for cygwin
> - git p4: cygwin p4 client does not mark read-only
> - git p4 test: avoid wildcard * in windows
> - git p4 test: use LineEnd unix in windows tests too
> - git p4 test: newline handling
> - git p4: scrub crlf for utf16 files on windows
> - git p4: remove unreachable windows \r\n conversion code
> - git p4 test: translate windows paths for cygwin
> - git p4 test: start p4d inside its db dir
> - git p4 test: use client_view in t9806
> - git p4 test: avoid loop in client_view
> - git p4 test: use client_view to build the initial client
> - git p4: generate better error message for bad depot path
> - git p4: remove unused imports
> - git p4: temp branch name should use / even on windows
>
> Improve "git p4" on Cygwin. The cover letter said it is not yet
> ready for full Windows support so I won't move this to 'next' until
> told by the author (the area maintainer) otherwise.
The series is ready as is to support Cygwin platforms, and
thus useful to people who would use git on windows via cygwin.
Future work will be to add support for Msysgit. That work
will need much of the changes in this Cygwin series as well.
It is more complicated since there's no native python for
Msysgit (yet).
I think the Cygwin changes should go in now.
-- Pete
^ 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