* [PATCH] git submodule: fix add usage line
From: Julien Danjou @ 2009-04-02 8:47 UTC (permalink / raw)
To: gitster; +Cc: git, Julien Danjou
Actually, cmd_add() parse options first and stop as soon as an unknown
word is encoutered.
So we need to put the option like -b at the beginning, or the option
parsing loop will be escaped before we got the change to have our -b
option parsed.
Signed-off-by: Julien Danjou <julien@danjou.info>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 0a27232..7c2e060 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
--
1.6.2.1
^ permalink raw reply related
* Re: How to sync two svn repositories via git?
From: Michael J Gruber @ 2009-04-02 7:41 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090401223052.GA28619@raven.wolf.lan>
Josef Wolf venit, vidit, dixit 02.04.2009 00:30:
> Hello,
>
> I have two subversion repositories which I would like to synchronize via
> git-svn. For this, I have set up a git repository and configured two
> branches to track the subversion repositories via git-svn:
>
> mkdir test-sync
> cd test-sync
> git svn init --stdlayout file://$REPOSDIR/svn-first
>
> for repos in svn-first svn-second; do
> git config svn-remote.$repos.url file://$REPOSDIR/$repos
> git config svn-remote.$repos.fetch trunk:refs/remotes/$repos/trunk
> git config svn-remote.$repos.branches branches/*:refs/remotes/$repos/*
> git config svn-remote.$repos.tags tags/*:refs/remotes/$repos/tags/*
> git svn fetch -R $repos
> git checkout -b $repos $repos/trunk
> done
> git gc
>
> This gives me two remote and two local branches:
>
> master
> svn-first
> * svn-second
> svn-first/trunk
> svn-second/trunk
>
> The first step I'd like to do is to "mirror" the manual merges that were
> done between the subversion repositories in the past:
>
> git checkout svn-first
> git merge -s ours --log commit-of-the-first-merge-in-svn-second
>
> git checkout svn-second
> git merge -s ours --log commit-of-the-first-merge-in-svn-first
>
> This seems to work, but git-gui shows conflicts. How can I get conflicts
> when I use the "-s ours" merge strategy?
What do git status and git diff (--stat, --combined) say?
^ permalink raw reply
* Re: [PATCH] Allow curl to rewind the read buffers
From: Junio C Hamano @ 2009-04-02 7:03 UTC (permalink / raw)
To: Martin Storsjö; +Cc: git, Mike Ralphson
In-Reply-To: <Pine.LNX.4.64.0904011946510.5901@localhost.localdomain>
Martin Storsjö <martin@martin.st> writes:
> When using multi-pass authentication methods, the curl library may
> need to rewind the read buffers (depending on how much already has
> been fed to the server) used for providing data to HTTP PUT, POST or
> PROPFIND, and in order to allow the library to do so, we need to tell
> it how by providing either an ioctl callback or a seek callback.
>
> This patch adds an ioctl callback, which should be usable on older
> curl versions (since 7.12.3) than the seek callback (introduced in
> curl 7.18.0).
>
> Some HTTP servers (such as Apache) give an 401 error reply immediately
> after receiving the headers (so no data has been read from the read
> buffers, and thus no rewinding is needed), but other servers (such
> as Lighttpd) only replies after the whole request has been sent and
> all data has been read from the read buffers, making rewinding necessary.
>
> Signed-off-by: Martin Storsjo <martin@martin.st>
Looks good, thanks.
Mike, how does this interact with your effort for defining a simplified
dependency rules on libcurl versions?
> Updated comment to better describe the potential need for this.
>
> http-push.c | 24 ++++++++++++++++++++++++
> http.c | 19 +++++++++++++++++++
> http.h | 7 +++++++
> 3 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/http-push.c b/http-push.c
> index 6ce5a1d..7dc0dd4 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -567,6 +567,10 @@ static void start_put(struct transfer_request *request)
> curl_easy_setopt(slot->curl, CURLOPT_INFILE, &request->buffer);
> curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, request->buffer.buf.len);
> curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
> +#ifndef NO_CURL_IOCTL
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &request->buffer);
> +#endif
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
> curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
> curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
> @@ -1267,6 +1271,10 @@ static struct remote_lock *lock_remote(const char *path, long timeout)
> curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
> curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
> +#ifndef NO_CURL_IOCTL
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
> +#endif
> curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_URL, url);
> @@ -1508,6 +1516,10 @@ static void remote_ls(const char *path, int flags,
> curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
> curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
> +#ifndef NO_CURL_IOCTL
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
> +#endif
> curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_URL, url);
> @@ -1584,6 +1596,10 @@ static int locking_available(void)
> curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
> curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
> +#ifndef NO_CURL_IOCTL
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
> +#endif
> curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_URL, repo->url);
> @@ -1766,6 +1782,10 @@ static int update_remote(unsigned char *sha1, struct remote_lock *lock)
> curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
> curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.buf.len);
> curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
> +#ifndef NO_CURL_IOCTL
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &out_buffer);
> +#endif
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
> curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
> curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
> @@ -1910,6 +1930,10 @@ static void update_remote_info_refs(struct remote_lock *lock)
> curl_easy_setopt(slot->curl, CURLOPT_INFILE, &buffer);
> curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, buffer.buf.len);
> curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
> +#ifndef NO_CURL_IOCTL
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLFUNCTION, ioctl_buffer);
> + curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &buffer);
> +#endif
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
> curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
> curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
> diff --git a/http.c b/http.c
> index eae74aa..3e8d548 100644
> --- a/http.c
> +++ b/http.c
> @@ -44,6 +44,25 @@ size_t fread_buffer(void *ptr, size_t eltsize, size_t nmemb, void *buffer_)
> return size;
> }
>
> +#ifndef NO_CURL_IOCTL
> +curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp)
> +{
> + struct buffer *buffer = clientp;
> +
> + switch (cmd) {
> + case CURLIOCMD_NOP:
> + return CURLIOE_OK;
> +
> + case CURLIOCMD_RESTARTREAD:
> + buffer->posn = 0;
> + return CURLIOE_OK;
> +
> + default:
> + return CURLIOE_UNKNOWNCMD;
> + }
> +}
> +#endif
> +
> size_t fwrite_buffer(const void *ptr, size_t eltsize, size_t nmemb, void *buffer_)
> {
> size_t size = eltsize * nmemb;
> diff --git a/http.h b/http.h
> index 905b462..26abebe 100644
> --- a/http.h
> +++ b/http.h
> @@ -37,6 +37,10 @@
> #define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
> #endif
>
> +#if LIBCURL_VERSION_NUM < 0x070c03
> +#define NO_CURL_IOCTL
> +#endif
> +
> struct slot_results
> {
> CURLcode curl_result;
> @@ -67,6 +71,9 @@ struct buffer
> extern size_t fread_buffer(void *ptr, size_t eltsize, size_t nmemb, void *strbuf);
> extern size_t fwrite_buffer(const void *ptr, size_t eltsize, size_t nmemb, void *strbuf);
> extern size_t fwrite_null(const void *ptr, size_t eltsize, size_t nmemb, void *strbuf);
> +#ifndef NO_CURL_IOCTL
> +extern curlioerr ioctl_buffer(CURL *handle, int cmd, void *clientp);
> +#endif
>
> /* Slot lifecycle functions */
> extern struct active_request_slot *get_active_slot(void);
> --
> 1.6.0.2
^ permalink raw reply
* Re: [PATCH] Build RPMs locally unless overruled in ~/.rpmmacros
From: Junio C Hamano @ 2009-04-02 6:47 UTC (permalink / raw)
To: Niels Basjes; +Cc: git
In-Reply-To: <1238425839-6337-1-git-send-email-Niels@Basjes.nl>
Niels Basjes <Niels@basjes.nl> writes:
> From: Niels Basjes <niels@basjes.nl>
>
> Signed-off-by: Niels Basjes <niels@basjes.nl>
I am not opposed to have an option to build RPM binary packages in-tree,
and RPM_BUILDING might be an already accepted name for the directory (even
though it looks too loud to my eyes, you may have chosen it because it is
a common practice in the RPM land---I am not an RPM person so I wouldn't
know).
But I thought somebody already pointed out a possible regression scenario.
If one has been running 'make rpm' with RPMBUILD that invokes rpmbuild
command with a custom yet not $HOME/.rpmmacos file via --macros option, or
has been running it as a user that can write into system-wide rpm
workplaces, this patch would break such an established workflow.
Perhaps something along this line might work just as well, without
breaking things for people?
ifdef RPM_BUILD_HERE
RPMBUILDOPTS = --define="_topdir $(pwd)/RPM_BUILDING"
rpmprep:
mkdir RPM_BUILDING
mkdir RPM_BUILDING/BUILD
mkdir RPM_BUILDING/RPMS
mkdir RPM_BUILDING/SOURCES
mkdir RPM_BUILDING/SPECS
mkdir RPM_BUILDING/SRPMS
else
RPMBUILDOPTS =
rpmprep:
: nothing
endif
rpm: dist rpmprep
$(RPMBUILD) $(RPMBUILDOPTS) -ta $(GIT_TARNAME).tar.gz
By the way, as far as I can tell, you do not need to have SOURCES
directory in order to run "make rpm" in git.git.
> +RPMBUILDOPTS = $(shell if [ "`grep '^%_topdir' $(HOME)/.rpmmacros`" == "" ]; \
> + then \
> + mkdir -p RPM_BUILDING/{BUILD,RPMS,SOURCES,SPECS,SRPMS}; \
Not everybody runs bash.
> + echo '--define="_topdir `pwd`/RPM_BUILDING"' ; \
> + fi \
> + )
> +RPMBUILD = rpmbuild $(RPMBUILDOPTS)
> TCL_PATH = tclsh
> TCLTK_PATH = wish
> PTHREAD_LIBS = -lpthread
You need to have "make clean" remove RPM_BUILDING.
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Junio C Hamano @ 2009-04-02 6:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0903302250500.4093@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> That made no sense. It should have been:
>
> On Mon, 30 Mar 2009, Linus Torvalds wrote:
>>
>> but we care about the commits that are younger than 'expire_total' (older
>> than that, and they are pruned unconditionally), but older than
>> 'expire_unreachable' (younger than that and the date doesn't matter).
> ^^^^
> reachability
>
> but other than that the commentary stands.
Correct. But after thinking about this a bit more, I am starting to suspect
the "of course" in your earlier
If I do
mark_reachable(cb.ref_commit, 0);
instead (to traverse the _whole_ tree, with no regards to date), the time
shrinks to 1.7s. But of course, that's also wrong.
may not be such a clearly obvious thing.
Suppose you do not do "mark_reachable(cb.ref_commit, 0)" but use the
expire_total as the cut-off value (which is what I've queued). If you
have one unreachable entry that you end up running in_merge_bases() for,
you will traverse all the history down _anyway_, and at that point, you
would be better off if you actually marked everything upfront, and
discarded anything unmarked as unreachable without falling back to
in_merge_bases() at all.
The above reasoning of course assumes that "keep reflog entries if they
are reachable from the tip, otherwise drop them if they are more than 30
days old" is a good medium level semantics to cull what the other rule
"drop any reflog entry older than 90 days" may not.
A hacky alternative would be to use total_expire as the cut-off and do not
fall back on in_merge_bases(). We might incorrectly prune away an entry
that records that you pulled a commit that is still reachable from the tip
last week, if that commit happens to be 4 months old if we did so, so I am
not convinced myself it is a reasonable hack, though.
^ permalink raw reply
* Re: [PATCHv2 3/4] Documentation: branch.*.merge can also afect 'git-push'
From: Junio C Hamano @ 2009-04-02 6:08 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0903301506r65bd9b9bv6bf76c652a051400@mail.gmail.com>
Santi Béjar <santi@agolina.net> writes:
> 2009/3/30 Junio C Hamano <gitster@pobox.com>:
> ...
> Maybe the push.default description needs some enhancements, but this
> [3/4] is true.
>
>> I think the author meant to say if your local branch frotz by default
>> merges changes made to the branch nitfol of the remote repository, "frotz
>> tracks nitfol", but the use of the word "track" for that meaning appears
>> nowhere in Documentation/glossary-content.txt
>
> So we can define:
>
> push.default = "tracking" = "push the current branch to its upstream branch"
>
> The "upstream branch" is defined in branch.name.merge and could also
> be added to glossary-content.
Sounds like a good plan. Please make it so.
^ permalink raw reply
* Re: [PATCH 6/8 v2] sh-tools: add a run_merge_tool function
From: David Aguilar @ 2009-04-02 5:33 UTC (permalink / raw)
To: James Pickens; +Cc: gitster, git
In-Reply-To: <885649360903311115o6131988emdcba6ef215ec0ab0@mail.gmail.com>
On 0, James Pickens <jepicken@gmail.com> wrote:
> On Mon, Mar 30, 2009 at 1:11 AM, David Aguilar <davvid@gmail.com> wrote:
> > This function launches merge tools and will be used to refactor
> > git-(diff|merge)tool.
>
> Thanks for writing difftool; I find it quite useful. I tried it with
> tkdiff, and noticed that it shows the 'merge preview' window even though it
> isn't doing a merge. If a user with unstaged changes were to carelessly
> click the 'save and exit' button, his changes could be lost. So I think
> it's a good idea to stop the merge preview window from showing up under
> difftool. To do that I think you just have to remove the '-o "$MERGED"'
> option to tkdiff.
>
> James
Hi James
I included your suggestion in my latest patch series.
Once things settle down with the current series I'll
add diffuse to {diff,merge}tool and friends.
So, yup, this shouldn't be an issue in future versions of
difftool.
Thanks
--
David
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Junio C Hamano @ 2009-04-02 5:25 UTC (permalink / raw)
To: Christian Couder; +Cc: Nathaniel P Dawson, Johannes Sixt, git
In-Reply-To: <200904020557.25058.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Ok, so I suggest the following simple guiding principles:
>
> - git-compat-util.h or cache.h or builtin.h should always be the first
> #include in C files,
>
> - header files should include other incude files if and only if the other
> includes are needed to compile them,
This is unclear.
Long before I started touching git, I used to be religious about making
header files self contained. For a header file frotz.h in the project, I
used to insist that
$ cat >1.c <<\EOF
#include "frotz.h"
EOF
$ cc -Wall -c 1.c
did not fail.
Are you talking about that by "to compile them"?
I stopped doing that long time ago, partly because the rule was cumbersome
to enforce, but primarily because it was not helping much in the larger
picture.
Such a rule, together with strict rules such as the order of including
other header files in the header files themselves, may make life easier
for programmers who touch .c files but never .h files, because they can
include only the necessary .h files and in any order. But in practice,
people need to touch both .h and .c files and when they need to include
new system header files, they need to follow the inclusion order rule
somewhere anyway---at that point, it does not matter much if the rule
applies to only .h files or both .h and .c files.
So for example, you cannot compile
$ cat >1.c <<\EOF
#include "revision.h"
EOF
$ cc -Wll -c 1.c
in git.git project, but I do not think it is a problem.
> - a header file should be included in a C file only if it is needed to
> compile the C file (it is not ok to include it only because it includes
> many other headers that are needed)
If that is the rule, perhaps the problem lies not in a .c program that
includes such a .h header, but in the .h itself that includes many other
header files.
> - other than the above rules, it is ok to reduce the number of includes as
> much as possible
>
> What do you think?
What you did not write and I forgot to mention, which is a logical
conclusion of the first rule, is that C files should not directly include
common system header files such as unistd, sys/stat, etc.
There are exceptions to any rule. For example, inclusion of syslog.h in
daemon.c is OK because most of the rest of the system does not even use
syslog. If we later find a platform whose syslog.h has some funny
inter-header dependencies, however, we will need to include it in the
git-compat-util.h and resolve the dependencies there, like we do for other
system header files.
> Or perhaps Junio would prefer that you work on a C file by C file basis?
> Like for example:
>
> "delete useless includes in 'builtin-diff-files.c'"
> "delete useless includes in 'builtin-diff-index.c'"
If the series does not involve .h file clean-up, then a series that
consists of one patch per .c file would be easier to handle, I think.
^ permalink raw reply
* Re: [PATCH] Documentation: use "spurious .sp" XSLT if DOCBOOK_SUPPRESS_SP is set
From: Junio C Hamano @ 2009-04-02 5:25 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Johnsen, Heiko Voigt, git
In-Reply-To: <20090401101400.GA26181@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think the "feature knob" makes sense. I don't know that it is worth
> extensive testing with old releases. You have a pretty good guess about
> which versions are affected, and people who experience the problem can
> turn the knob. Your Makefile comments make it easy for them find the
> knob once they see the breakage.
>
> It is probably worth mentioning in the release notes to give a heads-up,
> though.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-svn: add a double quiet option to hide git commits
From: Junio C Hamano @ 2009-04-02 5:24 UTC (permalink / raw)
To: Eric Wong; +Cc: Simon Arlott, git, mdpoole
In-Reply-To: <20090331065231.GA32142@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Simon Arlott <simon@fire.lp0.eu> wrote:
>> People may expect/prefer -q to still show git commits,
>> so this change allows a second -q to hide them.
>>
>> Signed-off-by: Michael Poole <mdpoole@troilus.org>
>> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
>
> Thanks,
> Acked-by: Eric Wong <normalperson@yhbt.net>
> and pushed out to git://git.bogomips.org/git-svn
Thanks, and pulled.
^ permalink raw reply
* [PATCH] match_tree_entry(): a pathspec only matches at directory boundaries
From: Junio C Hamano @ 2009-04-02 4:41 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Eric Wong, Anton Gyllenberg, git, Linus Torvalds
In-Reply-To: <7vbprfn0ai.fsf@gitster.siamese.dyndns.org>
Previously the code did a simple prefix match, which means that a path in
a directory "frotz/" would have matched with pathspec "f".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* And this is a companion patch to fix ls-tree. The test case uses a
tree that has path3/1.txt and path3/2.txt in it.
The bug Eric diagnosed and worked around in git-svn makes the current
code show these two paths when pathspec "pa" and "path3/a" are given.
The presense of "path3/a" makes the tree walker traverse down to path3
subtree (in case something that matches "a" is in there---this is a
correct behaviour), but then in that subtree, "pa" incorrectly matches
"path3/1.txt".
This logic dates back to 0ca14a5 (Start adding interfaces to read in
partial trees, 2005-07-14). I think it is just a simple oversight and
we should fix it.
t/t3101-ls-tree-dirname.sh | 6 ++++++
tree.c | 8 ++++++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/t/t3101-ls-tree-dirname.sh b/t/t3101-ls-tree-dirname.sh
index 4dd7d12..51cb4a3 100755
--- a/t/t3101-ls-tree-dirname.sh
+++ b/t/t3101-ls-tree-dirname.sh
@@ -135,4 +135,10 @@ test_expect_success \
EOF
test_output'
+test_expect_success 'ls-tree filter is leading path match' '
+ git ls-tree $tree pa path3/a >current &&
+ >expected &&
+ test_output
+'
+
test_done
diff --git a/tree.c b/tree.c
index 03e782a..d82a047 100644
--- a/tree.c
+++ b/tree.c
@@ -60,8 +60,12 @@ static int match_tree_entry(const char *base, int baselen, const char *path, uns
/* If it doesn't match, move along... */
if (strncmp(base, match, matchlen))
continue;
- /* The base is a subdirectory of a path which was specified. */
- return 1;
+ /* pathspecs match only at the directory boundaries */
+ if (!matchlen ||
+ base[matchlen] == '/' ||
+ match[matchlen - 1] == '/')
+ return 1;
+ continue;
}
/* Does the base match? */
--
1.6.2.1.483.gcc994
^ permalink raw reply related
* Re: [PATCH] tree_entry_interesting: Only recurse when the pathspec is a leading path component
From: Junio C Hamano @ 2009-04-02 4:32 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Eric Wong, Anton Gyllenberg, git
In-Reply-To: <20090331150501.GA11446@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Previously the code did a simple prefix match, which means that it
> treated for example "foo/" as a subdirectory of "f".
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> ---
> I'm not exactly happy with the commit message, but that's the best I
> could come up with. Probably shows how little I know about that code :-/
> The test suite still passes and I'll try to provide a new testcase
> tonight or tommorow.
I'm planning to queue this.
From: Björn Steinbrink <B.Steinbrink@gmx.de>
Date: Tue, 31 Mar 2009 17:05:01 +0200
Subject: [PATCH] tree_entry_interesting: a pathspec only matches at directory boundary
Previously the code did a simple prefix match, which means that a
path in a directory "frotz/" would have matched with pathspec "f".
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4010-diff-pathspec.sh | 8 ++++++++
tree-diff.c | 12 +++++++++---
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh
index ad3d9e4..4c4c8b1 100755
--- a/t/t4010-diff-pathspec.sh
+++ b/t/t4010-diff-pathspec.sh
@@ -62,4 +62,12 @@ test_expect_success \
'git diff-index --cached $tree -- file0/ >current &&
compare_diff_raw current expected'
+test_expect_success 'diff-tree pathspec' '
+ tree2=$(git write-tree) &&
+ echo "$tree2" &&
+ git diff-tree -r --name-only $tree $tree2 -- pa path1/a >current &&
+ >expected &&
+ test_cmp expected current
+'
+
test_done
diff --git a/tree-diff.c b/tree-diff.c
index 9f67af6..b05d0f4 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -118,10 +118,16 @@ static int tree_entry_interesting(struct tree_desc *desc, const char *base, int
continue;
/*
- * The base is a subdirectory of a path which
- * was specified, so all of them are interesting.
+ * If the base is a subdirectory of a path which
+ * was specified, all of them are interesting.
*/
- return 2;
+ if (!matchlen ||
+ base[matchlen] == '/' ||
+ match[matchlen - 1] == '/')
+ return 2;
+
+ /* Just a random prefix match */
+ continue;
}
/* Does the base match? */
^ permalink raw reply related
* Re: [PATCH 07/10] rev-list: call new "filter_skip" function
From: Christian Couder @ 2009-04-02 4:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, John Tapsell
In-Reply-To: <alpine.DEB.1.00.0904011631300.13502@intel-tinevez-2-302>
Hi,
Le mercredi 1 avril 2009, Johannes Schindelin a écrit :
> Hi,
>
> On Wed, 1 Apr 2009, Christian Couder wrote:
> > Le mardi 31 mars 2009, Johannes Schindelin a écrit :
> > > Hi,
> > >
> > > On Tue, 31 Mar 2009, Christian Couder wrote:
> > > > Le lundi 30 mars 2009, Johannes Schindelin a écrit :
> > > No, you want to _look up_ sha1s. And struct decorate is not about
> > > storing objects, but to attach things to objects.
> >
> > The problem is that I don't have any object to attach things to when I
> > read the bisect skip refs. I just need to store the sha1 from the skip
> > refs in some sha1 container.
>
> I see, so you do not want to parse the commits just to register them as
> skipped.
>
> Fair enough.
>
> But I still think that a hashmap/set would be better suited.
>
> In any case, it should be refactored into something usable in all of
> libgit.a. You are basically duplicating the grafts code in commit.c,
> sharing that shortcoming that your code would be static again, not
> encouraging reusage.
I agree that binary search functions and related code should be refactored.
That's why I added the "Refactor binary search functions" task to the
Janitor wiki page (http://git.or.cz/gitwiki/Janitor) a few weeks ago.
I will have a look at that, and perhaps, after that, I will try to make
things less static, but I think these are some old problems in the code
base, so new developments should not be hostage of them.
Best reagrds,
Christian.
^ permalink raw reply
* [PATCH v2 10/10] mergetool: use run_mergetool from git-mergetool-lib
From: David Aguilar @ 2009-04-02 4:20 UTC (permalink / raw)
To: gitster; +Cc: git, markus.heidelberg, charles, David Aguilar
In-Reply-To: <1238646040-46008-2-git-send-email-davvid@gmail.com>
This refactors git-mergetool to use run_mergetool.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Includes fixups from Markus
git-mergetool.sh | 96 +++--------------------------------------------------
1 files changed, 6 insertions(+), 90 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 957993c..fd81ad7 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -190,96 +190,12 @@ merge_file () {
read ans
fi
- case "$merge_tool" in
- kdiff3)
- if base_present ; then
- ("$merge_tool_path" --auto --L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
- -o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
- else
- ("$merge_tool_path" --auto --L1 "$MERGED (Local)" --L2 "$MERGED (Remote)" \
- -o "$MERGED" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
- fi
- status=$?
- ;;
- tkdiff)
- if base_present ; then
- "$merge_tool_path" -a "$BASE" -o "$MERGED" "$LOCAL" "$REMOTE"
- else
- "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
- fi
- status=$?
- ;;
- meld)
- touch "$BACKUP"
- "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
- check_unchanged
- ;;
- vimdiff)
- touch "$BACKUP"
- "$merge_tool_path" -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
- check_unchanged
- ;;
- gvimdiff)
- touch "$BACKUP"
- "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
- check_unchanged
- ;;
- xxdiff)
- touch "$BACKUP"
- if base_present ; then
- "$merge_tool_path" -X --show-merged-pane \
- -R 'Accel.SaveAsMerged: "Ctrl-S"' \
- -R 'Accel.Search: "Ctrl+F"' \
- -R 'Accel.SearchForward: "Ctrl-G"' \
- --merged-file "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
- else
- "$merge_tool_path" -X --show-merged-pane \
- -R 'Accel.SaveAsMerged: "Ctrl-S"' \
- -R 'Accel.Search: "Ctrl+F"' \
- -R 'Accel.SearchForward: "Ctrl-G"' \
- --merged-file "$MERGED" "$LOCAL" "$REMOTE"
- fi
- check_unchanged
- ;;
- opendiff)
- touch "$BACKUP"
- if base_present; then
- "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED" | cat
- else
- "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$MERGED" | cat
- fi
- check_unchanged
- ;;
- ecmerge)
- touch "$BACKUP"
- if base_present; then
- "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" --default --mode=merge3 --to="$MERGED"
- else
- "$merge_tool_path" "$LOCAL" "$REMOTE" --default --mode=merge2 --to="$MERGED"
- fi
- check_unchanged
- ;;
- emerge)
- if base_present ; then
- "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$MERGED")"
- else
- "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
- fi
- status=$?
- ;;
- *)
- if test -n "$merge_tool_cmd"; then
- if test "$merge_tool_trust_exit_code" = "false"; then
- touch "$BACKUP"
- ( eval $merge_tool_cmd )
- check_unchanged
- else
- ( eval $merge_tool_cmd )
- status=$?
- fi
- fi
- ;;
- esac
+ present=false
+ base_present &&
+ present=true
+
+ run_mergetool "$merge_tool" "$present"
+
if test "$status" -ne 0; then
echo "merge of $MERGED failed" 1>&2
mv -- "$BACKUP" "$MERGED"
--
1.6.1.3
^ permalink raw reply related
* [PATCH v2 08/10] mergetool-lib: introduce run_mergetool
From: David Aguilar @ 2009-04-02 4:20 UTC (permalink / raw)
To: gitster; +Cc: git, markus.heidelberg, charles, David Aguilar
In-Reply-To: <1238646040-46008-1-git-send-email-davvid@gmail.com>
run_mergetool contains the common functionality for launching
mergetools. There's some context-specific behavior but overall
it's better to have all of this stuff in one place versus multiple
places.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Include fixups from Markus
Documentation/git-mergetool-lib.txt | 10 +++
git-mergetool-lib.sh | 141 +++++++++++++++++++++++++++++++++++
2 files changed, 151 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-mergetool-lib.txt b/Documentation/git-mergetool-lib.txt
index a8d62f5..7377774 100644
--- a/Documentation/git-mergetool-lib.txt
+++ b/Documentation/git-mergetool-lib.txt
@@ -29,6 +29,16 @@ FUNCTIONS
get_merge_tool_path::
returns the `merge_tool_path` for a `merge_tool`.
+run_mergetool::
+ launches a merge tool given the tool name and a true/false
+ flag to indicate whether a merge base is present
+
+valid_tool::
+ tests whether a merge tool is setup correctly.
+
+get_custom_cmd::
+ given a merge tool, returns the custom command for that tool.
+
Author
------
Written by David Aguilar <davvid@gmail.com>
diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
index 5f9ba97..d28be68 100644
--- a/git-mergetool-lib.sh
+++ b/git-mergetool-lib.sh
@@ -3,7 +3,12 @@ diff_mode() {
test $TOOL_MODE = "diff"
}
+merge_mode() {
+ test $TOOL_MODE = "merge"
+}
+
get_merge_tool_path () {
+ path="$1"
if test -z "$2"; then
case "$1" in
emerge)
@@ -17,6 +22,11 @@ get_merge_tool_path () {
echo "$path"
}
+# Overridden in git-mergetool
+check_unchanged () {
+ true
+}
+
valid_tool () {
case "$1" in
kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
@@ -40,3 +50,134 @@ get_custom_cmd () {
test -n "$custom_cmd" &&
echo "$custom_cmd"
}
+
+run_mergetool () {
+ base_present="$2"
+ if diff_mode; then
+ base_present="false"
+ fi
+ if test -z "$base_present"; then
+ base_present="true"
+ fi
+
+ case "$1" in
+ kdiff3)
+ if $base_present; then
+ ("$merge_tool_path" --auto \
+ --L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
+ -o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
+ else
+ ("$merge_tool_path" --auto \
+ --L1 "$MERGED (Local)" --L2 "$MERGED (Remote)" \
+ -o "$MERGED" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
+ fi
+ status=$?
+ ;;
+ kompare)
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ status=$?
+ ;;
+ tkdiff)
+ if $base_present; then
+ "$merge_tool_path" -a "$BASE" -o "$MERGED" "$LOCAL" "$REMOTE"
+ else
+ if merge_mode; then
+ "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ fi
+ fi
+ status=$?
+ ;;
+ meld)
+ if merge_mode; then
+ touch "$BACKUP"
+ "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
+ fi
+ check_unchanged
+ ;;
+ vimdiff)
+ if merge_mode; then
+ touch "$BACKUP"
+ "$merge_tool_path" -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
+ check_unchanged
+ else
+ "$merge_tool_path" -c "wincmd l" "$LOCAL" "$REMOTE"
+ fi
+ ;;
+ gvimdiff)
+ if merge_mode; then
+ touch "$BACKUP"
+ "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
+ check_unchanged
+ else
+ "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$REMOTE"
+ fi
+ ;;
+ xxdiff)
+ merge_mode && touch "$BACKUP"
+ if $base_present; then
+ "$merge_tool_path" -X --show-merged-pane \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
+ else
+ merge_mode && extra=--show-merged-pane
+ "$merge_tool_path" -X $extra \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" "$LOCAL" "$REMOTE"
+ fi
+ check_unchanged
+ ;;
+ opendiff)
+ merge_mode && touch "$BACKUP"
+ if $base_present; then
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -ancestor "$BASE" -merge "$MERGED" | cat
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ -merge "$MERGED" | cat
+ fi
+ check_unchanged
+ ;;
+ ecmerge)
+ merge_mode && touch "$BACKUP"
+ if $base_present; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" \
+ --default --mode=merge3 --to="$MERGED"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" \
+ --default --mode=merge2 --to="$MERGED"
+ fi
+ check_unchanged
+ ;;
+ emerge)
+ if $base_present; then
+ "$merge_tool_path" -f emerge-files-with-ancestor-command \
+ "$LOCAL" "$REMOTE" "$BASE" "$(basename "$MERGED")"
+ else
+ "$merge_tool_path" -f emerge-files-command \
+ "$LOCAL" "$REMOTE" "$(basename "$MERGED")"
+ fi
+ status=$?
+ ;;
+ *)
+ if test -n "$merge_tool_cmd"; then
+ if merge_mode &&
+ test "$merge_tool_trust_exit_code" = "false"; then
+ touch "$BACKUP"
+ ( eval $merge_tool_cmd )
+ check_unchanged
+ else
+ ( eval $merge_tool_cmd )
+ status=$?
+ fi
+ fi
+ ;;
+ esac
+}
--
1.6.1.3
^ permalink raw reply related
* [PATCH v2 03/10] Add a mergetool-lib scriptlet for holding common merge tool functions
From: David Aguilar @ 2009-04-02 4:20 UTC (permalink / raw)
To: gitster; +Cc: git, markus.heidelberg, charles, David Aguilar
git-mergetool-lib provides common merge tool functions.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Includes fixups from Markus
.gitignore | 1 +
Documentation/git-mergetool-lib.txt | 42 +++++++++++++++++++++++++++++++++++
Makefile | 1 +
command-list.txt | 1 +
git-mergetool-lib.sh | 42 +++++++++++++++++++++++++++++++++++
5 files changed, 87 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-mergetool-lib.txt
create mode 100644 git-mergetool-lib.sh
diff --git a/.gitignore b/.gitignore
index 966c886..75c154a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -80,6 +80,7 @@ git-merge-recursive
git-merge-resolve
git-merge-subtree
git-mergetool
+git-mergetool-lib
git-mktag
git-mktree
git-name-rev
diff --git a/Documentation/git-mergetool-lib.txt b/Documentation/git-mergetool-lib.txt
new file mode 100644
index 0000000..a8d62f5
--- /dev/null
+++ b/Documentation/git-mergetool-lib.txt
@@ -0,0 +1,42 @@
+git-mergetool-lib(1)
+====================
+
+NAME
+----
+git-mergetool-lib - Common git merge tool shell scriptlets
+
+SYNOPSIS
+--------
+'. "$(git --exec-path)/git-mergetool-lib"'
+
+DESCRIPTION
+-----------
+
+This is not a command the end user would want to run. Ever.
+This documentation is meant for people who are studying the
+Porcelain-ish scripts and/or are writing new ones.
+
+The 'git-mergetool-lib' scriptlet is designed to be sourced (using
+`.`) by other shell scripts to set up functions for working
+with git merge tools.
+
+Before sourcing it, your script should set up a few variables;
+`TOOL_MODE` is used to define the operation mode for various
+functions. 'diff' and 'merge' are valid values.
+
+FUNCTIONS
+---------
+get_merge_tool_path::
+ returns the `merge_tool_path` for a `merge_tool`.
+
+Author
+------
+Written by David Aguilar <davvid@gmail.com>
+
+Documentation
+--------------
+Documentation by David Aguilar and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/Makefile b/Makefile
index d77fd71..086f9e7 100644
--- a/Makefile
+++ b/Makefile
@@ -284,6 +284,7 @@ SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
SCRIPT_SH += git-mergetool.sh
+SCRIPT_SH += git-mergetool-lib.sh
SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
SCRIPT_SH += git-quiltimport.sh
diff --git a/command-list.txt b/command-list.txt
index fb03a2e..922c815 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -69,6 +69,7 @@ git-merge-file plumbingmanipulators
git-merge-index plumbingmanipulators
git-merge-one-file purehelpers
git-mergetool ancillarymanipulators
+git-mergetool-lib purehelpers
git-merge-tree ancillaryinterrogators
git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
new file mode 100644
index 0000000..5f9ba97
--- /dev/null
+++ b/git-mergetool-lib.sh
@@ -0,0 +1,42 @@
+# git-mergetool-lib is a library for common merge tool functions
+diff_mode() {
+ test $TOOL_MODE = "diff"
+}
+
+get_merge_tool_path () {
+ if test -z "$2"; then
+ case "$1" in
+ emerge)
+ path=emacs
+ ;;
+ *)
+ path="$1"
+ ;;
+ esac
+ fi
+ echo "$path"
+}
+
+valid_tool () {
+ case "$1" in
+ kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ if test "$1" = "kompare" && ! diff_mode; then
+ return 1
+ fi
+ ;; # happy
+ *)
+ if test -z "$(get_custom_cmd "$1")"; then
+ return 1
+ fi
+ ;;
+ esac
+}
+
+get_custom_cmd () {
+ diff_mode &&
+ custom_cmd="$(git config difftool.$1.cmd)"
+ test -z "$custom_cmd" &&
+ custom_cmd="$(git config mergetool.$1.cmd)"
+ test -n "$custom_cmd" &&
+ echo "$custom_cmd"
+}
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCH 03/10] Add a mergetool-lib scriptlet for holding common merge tool functions
From: David Aguilar @ 2009-04-02 3:58 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: gitster, charles, git
In-Reply-To: <200904020039.41894.markus.heidelberg@web.de>
On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> David Aguilar, 01.04.2009:
> >
> > diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
> > +valid_tool () {
> > + case "$1" in
> > + kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
> > + if test "$1" = "kompare" && ! diff_mode; then
> > + return 1
> > + fi
> > + ;; # happy
> > + *)
> > + if ! test -n "$(get_custom_cmd "$1")"; then
>
> Better this?
> if test -z "$(get_custom_cmd "$1")"; then
>
> > + return 1
> > + fi ;;
>
> For consistency:
> fi
> ;;
>
I'll reroll tonight and include you on the CC when I resent the
patches in question.
Thanks Markus.
--
David
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Christian Couder @ 2009-04-02 3:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nathaniel P Dawson, Johannes Sixt, git
In-Reply-To: <7vk56565m1.fsf@gitster.siamese.dyndns.org>
Le mardi 31 mars 2009, Junio C Hamano a écrit :
> Christian Couder <chriscool@tuxfamily.org> writes:
> > I think it's a good thing that you started working on it even if in the
> > end we decide that we want these cleanup to be done otherwise. At least
> > we will hopefully have clarified our include header policy.
>
> Before seeing a lot of patches to change #include all over the place, I'd
> like to see a simple guiding principle described, not just a subjective
> "I think this makes things better" but with "... because of X and Y and
> Z".
>
> The document Documentation/CodingGuidelines describes the only policy
> that exists currently: git-compat-util.h must be the first thing the
> compiler sees. The language should probably be stronger than what
> appears there:
>
> - The first #include in C files, except in platform specific
> compat/ implementations, should be git-compat-util.h or another
> well-known header file that includes it at the beginning, namely
> cache.h or builtin.h.
>
> Even though http.h may include "cache.h" at the very beginning, I'd
> rather not to see http-walker.c lose inclusion of "cache.h". It will
> force us to remember that http.h is Ok to include as the first file, and
> that won't scale.
>
> The reason git-compat-util.h must be the first is because inclusion of
> all the system header files is supposed to happen there, and there are
> some platforms that have broken system header dependencies we do not want
> application writers to care about, and the compat-util header knows about
> them.
Ok, so I suggest the following simple guiding principles:
- git-compat-util.h or cache.h or builtin.h should always be the first
#include in C files,
- header files should include other incude files if and only if the other
includes are needed to compile them,
- a header file should be included in a C file only if it is needed to
compile the C file (it is not ok to include it only because it includes
many other headers that are needed)
- other than the above rules, it is ok to reduce the number of includes as
much as possible
What do you think?
By the way, Nathaniel, you should try to give more meaningful titles to the
individual patches in your patch series and perhaps make them smaller so
that they are easier to review and have less conflicts with other patches.
For example your patch "[PATCH 1/5] Header includes cleanup" could be
splitted and the resulting patches could be renamed like this
"delete includes of 'git-compat-util.h' where 'builtin.h' is included"
"delete includes of 'cache.h' where 'builtin.h' is included"
"delete includes of 'strbuf.h' where 'builtin.h' is included"
"delete includes of 'commit.h' where 'builtin.h' is included"
Or perhaps Junio would prefer that you work on a C file by C file basis?
Like for example:
"delete useless includes in 'builtin-diff-files.c'"
"delete useless includes in 'builtin-diff-index.c'"
...
Thanks,
Christian.
^ permalink raw reply
* Re: "git clone --depth <depth>" producing history with <depth + 1> commits?
From: Junio C Hamano @ 2009-04-02 2:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sebastian Pipping, git
In-Reply-To: <alpine.DEB.1.00.0904020303320.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 1 Apr 2009, Sebastian Pipping wrote:
>
>> Sebastian Pipping wrote:
>> > Is "git clone --depth 1 <ropository>" expected to give a history
>> > with 2 commits? "--depth 2" gives 3 commits, "--depth 0" all.
>> >
>> > Is that by design or a bug?
>>
>> Anyone? Is "git clone --depth 1 <ropository>" really supposed to
>> produce a history holding _two_ commits? Why so?
>
> Because storing _no_ commit (according to you, that should happen with
> --depth=0) would make no sense?
But then you can error out upon such a request.
> After all, if you want to clone, you want to clone at least _something_.
I am a bit puzzled by your logic. If one is requested, shouldn't you give
only one and not two?
^ permalink raw reply
* Re: More help with "pull" please
From: Junio C Hamano @ 2009-04-02 2:24 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: John Dlugosz, git
In-Reply-To: <F364AB31-EC5B-4719-834E-58613BDBC433@dbservice.com>
Tomas Carnecky <tom@dbservice.com> writes:
>> OK, that works by adding something to the config file, right? The
>> docs
>> don't say, but does mention "having Pull: <refspec> lines for a
>> <repository>". Does tracking add Pull: lines, or is that another
>> feature?
>
> I think Pull: lines are not used anymore in newer
> repositories.
If your repository is using .git/remotes/origin to name the "origin"
remote, they are still honored. But you are correct to point out that
branch.<name>.remote and with the remote.<name>.* variables in .git/config
are used to control these more recent features. So in that sense the
documentation is still correct.
^ permalink raw reply
* Re: On git 1.6 (novice's opinion)
From: Jakub Narebski @ 2009-04-02 2:17 UTC (permalink / raw)
To: Ulrich Windl; +Cc: Michael J Gruber, git
In-Reply-To: <49D32CE5.21780.391D18@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de>
On Wed, 1 April 2009, Ulrich Windl wrote:
> On 27 Mar 2009 at 7:09, Jakub Narebski wrote:
>> "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> writes:
>>> On 27 Mar 2009 at 13:49, Michael J Gruber wrote:
>>>> Ulrich Windl venit, vidit, dixit 27.03.2009 08:21:
>>>
>>> [...]
>>>
>>>> Keyword substitution and cvs/svn style version numbers are independent
>>>> issues. The sha1 describes a commit uniquely, one could use that as a
>>>> keyword.
>>>
>>> However version numbers and time stamps have the property of being at least
>>> partially ordered in respect of "newer/older". That property does not hold for
>>> SHA-1 checksums. Just imagine suggesting users to upgrade from Microsoft
>>> Word/004765c2a1e9771e886f0dbe87d4f89643cd6f70 to Microsoft
>>> Word/00b7e6f51130f234a969c84ee9231a5ff7fc8a82 ;-)
>>
>> That is why people use output of git-describe and _tag_ their releases,
>> and make embedding version number in released version (tarball / binary)
>> the job of make: see GIT-VERSION-GEN script in git sources, and how it
>> is used in Makefile.
>
> OK, but imaginge someone sends you some file that originated from some git
> version, maybe with minor modifications. Is there a way to find out from what git
> version that file was derived? IMHO that's where "automatically replaced
> placeholders" (like $id$) make sense.
Is it theoretical exercise or some real problem?
First, if the file with modification was taken from _release_ (from
tarball of sources), they can have placeholders like @@VERSION@@ replaced
by actual version (taken from git-describe / GIT-VERSION-GEN) by make
during "make dist" step, or its equivalent. Usually it would be e.g.
v1.6.2.1, as you make distribution of tagged release.
Second, if the files was taken from _repository_ (from version control),
you can get modification send as git diff of changes (which includes
shortened sha-1 of original file contents, and tools such as git-am --3way
can make use of this information to apply patch), or at least in unified
patch format.
Last, you can use `ident` attribute to make git replace the only
"automatic replaced placeholder" (keyword) that makes sense for
distributed VCS, namely $Id$ keyword which get replaced by
$Id: <40-character hexadecimal blob object name>$; you can based
on this iformation find commit or commits that introduced this exact
version of a file.
See gitattributes(5).
>>>> Increasing version numbers are meaningless in a true DVCS world. What is
>>>> your 100th commit may not be someone else's, even if both your master's
>>>> heads are the same! This is why hg version numbers are a local thing.
>>>> They are merely a local shortcut for specifying a revision and serve the
>>>> same purpose as git's "backward" counts like HEAD~3 etc. Neither of them
>>>> work permanently, not even in a local repo, if you allow rebasing.
>>>
>>> Maybe I didn't fully understand, but having a version number that is larger than
>>> any parent's version numbers when doing a merge/commit doesn't look wrong to me.
>>
>> I'm sorry to dissapoint you, but without central server assigning
>> numbers to commits it wouldn't simply work in distributed version
>> control world. Take for example the following situation: somebody
>> clones your repository, and creates new commit on 'master' (trunk) and
>> it gets version number N. Meanwhile you also independently create new
>> commit on 'master'... and without central authority it would also get
>> version number N. Then you would merge (pull) his/her changes, and
>> you would have two commits with the same number; not something you want.
>
> Anyway the result would have number "N+1". Maybe you misunderstood: I'm not
> proposing to replace git's internal version numbering (SHA-1), but so introduce
> some more comprehensible, primitive user-level numbering.
Errr... what? You would want to renumber _all_ (possibly large amount
of) fetched commits from other repository? It is very costly, and you
are left with commit numbers which are local to repository...
Or perhaps you would want to number only commits in first line parentage
of a branch, i.e. created in repository or fast-forwarded? This is what
Mercurial and (from what I understand) Bazaar does, and it also results
in commit numbers which are local to repository.
Or you were talking about having merge ("result") to have number "N+1".
But then you would have _two_ commits with number "N", and "N" would not
identify commit uniquely, even local for repository. Which means that
it would be useless.
Numbers local to repository cannot be used to pass in communication
to others (e.g. bug was caused by commit 5436); additionally I don't
see how revision number 7654 is any easier to use than HEAD~3, or
f348eae (copy'n'pasted).
>> Not to mention that you can have multiple roots (multiple commits with
>> no parent) in git repository; besides independent branches (like
>> 'man', 'html' or 'todo') it is usually result of absorbing or
>> subtree-merging other projects. In 'master' branch there are 5 roots
>> or more: joined 'git-tools' (mailinfo / mailsplit), absorbed gitweb,
>> and subtree-merged gitk and git-gui. And here you would again have
>> multiple commits with the same number...
>
> Which would not harm, because it would be version N from committer X. Any if
> committer X merges from anything else, the next number would be> N. I did not
> claim that my method makes a total ordering of commits and merges possible.
>
> I truly believe in unique IDs, but they are just not handy in every situation.
You have <branch>~<n>, <branch>@<n>, shortened sha-1, result of git-describe
that can be used in place of full sha-1...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: "git clone --depth <depth>" producing history with <depth + 1> commits?
From: Sebastian Pipping @ 2009-04-02 1:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0904020303320.10279@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
>> Anyone? Is "git clone --depth 1 <ropository>" really supposed to
>> produce a history holding _two_ commits? Why so?
>
> Because storing _no_ commit (according to you, that should happen with
> --depth=0) would make no sense?
>
> After all, if you want to clone, you want to clone at least _something_.
I'm aware you need one commit at least.
I didn't think of several branches before.
I guess that's resolving the core of my question.
Sebastian
^ permalink raw reply
* Re: "git clone --depth <depth>" producing history with <depth + 1> commits?
From: Johannes Schindelin @ 2009-04-02 1:04 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git
In-Reply-To: <49D3C300.1040303@hartwork.org>
Hi,
On Wed, 1 Apr 2009, Sebastian Pipping wrote:
> Sebastian Pipping wrote:
> > Is "git clone --depth 1 <ropository>" expected to give a history
> > with 2 commits? "--depth 2" gives 3 commits, "--depth 0" all.
> >
> > Is that by design or a bug?
>
> Anyone? Is "git clone --depth 1 <ropository>" really supposed to
> produce a history holding _two_ commits? Why so?
Because storing _no_ commit (according to you, that should happen with
--depth=0) would make no sense?
After all, if you want to clone, you want to clone at least _something_.
Ciao,
Dscho
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Michael Johnson @ 2009-04-02 0:33 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Miklos Vajna, git
In-Reply-To: <20090401180627.GA14716@localhost>
On Wed, 01 Apr 2009 13:06:27 -0500, Clemens Buchacher <drizzd@aon.at>
wrote:
> On Tue, Mar 31, 2009 at 02:14:21AM -0500, Michael Johnson wrote:
>> It would appear that the patch has already been applied to 1.6.2.1.
>
> I don't think it has. But judging from the stack trace this bug is
> unrelated to the patch anyways.
When I tried to appy the patch I got a conflict (I applied it directly to
Debian's source package for git-core). When I compared the code to the
patch it appeared it had been applied. Of course, I'm far from an expert
at applying patches, so I might have misread the direction of the patch.
> If nobody else is dealing with this I'd like to have a look at it. Could
> you please send me a copy of the repo.
It doesn't sound like anyone else is. So I'll send you a copy shortly, off
list.
Thanks for all the help,
Michael
--
Michael D Johnson <redbeard@mdjohnson.us>
redbeardcreator.deviantart.com
"Marketing research...[has] shown that energy weapons that make sounds sell
better..." - Kevin Siembieda (Rifts Game Master Guide, pg 111)
^ permalink raw reply
* RE: More help with "pull" please
From: John Dlugosz @ 2009-04-01 23:26 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <F364AB31-EC5B-4719-834E-58613BDBC433@dbservice.com>
> I think Pull: lines are not used anymore in newer repositories.
...
> I'd say forget about Pull: because you won't see any of that in newer
> repositories. Instead, just use --track when checking out a branch you
> intend to follow. And, more as an implementation detail than anything
> else, remember that the tracking is done through the above mentioned
> config options (which you can set/change using git-config or directly
> by editing the .git/config file).
OK, the documentation is clear if I ignore that.
I expect it to be "well behaved" if I'm on a tracking branch and give it
no arguments, or if the single refspec argument is the correct remote
for the branch I'm on. Otherwise (not a tracking branch) the docs just
say "It's complicated, backward compatibility" and presumably involves
those non-existent Pull: lines and the state of the remote's HEAD.
> Maybe it's because I'm using a fairly recent version
> (1.6.2.1.307.g91408).
I'm running git version (1.6.2.msysgit.0.186.gf7512), and I assume my
coworker's was a bit older.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ 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