* Re: [RFC/PATCH]: reverse bisect v 2.0
From: Junio C Hamano @ 2011-10-04 23:27 UTC (permalink / raw)
To: Christian Couder
Cc: Jeff King, Michal Vyskocil, git, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <201110050034.46334.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> If we decide to go with yes/no, an option like:
>
> --yes-means=<it behaves like this>
>
> seems to me easier to understand. Though I recognize that it doesn't tell that
> the behavior changed.
What problem are you trying to solve?
As I already said while discussing --has-property vs --used-to, I think
that --yes-means shares the exact same downside as --has-property.
The --used-to proposal was to make sure that people who are bisecting to
find fixes would not by mistake say
git bisect start --used-to='work fine'
as it is very clear that bisecting in a history with something that used
to work fine is _not_ hunting for a fix.
When the users say
git bisect start --yes-means='frotz is broken'
is it clear to them that they are supposed to define what used to be the
case (in which case "yes" is always mapped to "good")? If you are trying
to allow them to say either old or new behaviour with --yes-means, how
does your "bisect" know if it needs to map "yes" to "good" (regression
hunting), or "yes" to "bad" (looking for a fix)?
^ permalink raw reply
* [PATCH] remote-curl: Fix warning after HTTP failure
From: Shawn O. Pearce @ 2011-10-04 23:20 UTC (permalink / raw)
To: gitster; +Cc: git, Shawn O. Pearce
From: "Shawn O. Pearce" <spearce@spearce.org>
If the HTTP connection is broken in the middle of a fetch or clone
body, the client presented a useless error message due to part of
the upload-pack->remote-curl pkt-line protocol leaking out of the
helper as the helper's "fetch result":
error: RPC failed; result=18, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: unpack-objects failed
warning: https unexpectedly said: '0000'
Instead when the HTTP RPC fails discard all remaining data from
upload-pack and report nothing to the transport helper. Errors
were already sent to stderr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
remote-curl.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 69831e9..d2bf832 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -573,7 +573,16 @@ static int rpc_service(struct rpc_state *rpc, struct discovery *heads)
close(client.in);
client.in = -1;
- strbuf_read(&rpc->result, client.out, 0);
+ if (!err) {
+ strbuf_read(&rpc->result, client.out, 0);
+ } else {
+ char buf[4096];
+ for (;;) {
+ int n = read(client.out, buf, sizeof(buf));
+ if (n <= 0)
+ break;
+ }
+ }
close(client.out);
client.out = -1;
--
1.7.6.4.dirty
^ permalink raw reply related
* Re: [PATCH 1/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 23:06 UTC (permalink / raw)
To: Phil Hord; +Cc: Junio C Hamano, git, Erik Faye-Lund
In-Reply-To: <CABURp0qEQdjLsUxQkf3jSAHU80NOZEqm9iEksZKST_JfK590Qw@mail.gmail.com>
From: Erik Faye-Lund <kusmabite@gmail.com>
entr_repo(..., 0) currently modifies the input to strip away
trailing slashes. This means that we some times need to copy the
input to keep the original.
Change it to unconditionally copy it into the used_path buffer so
we can safely use the input without having to copy it. Also store
a working copy in validated_path up-front before we start
resolving anything.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/cache.h b/cache.h
index 9994a3c..7eeb8cf 100644
--- a/cache.h
+++ b/cache.h
@@ -734,7 +734,7 @@ int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
int mkdir_in_gitdir(const char *path);
extern char *expand_user_path(const char *path);
-char *enter_repo(char *path, int strict);
+const char *enter_repo(const char *path, int strict);
static inline int is_absolute_path(const char *path)
{
return is_dir_sep(path[0]) || has_dos_drive_prefix(path);
diff --git a/daemon.c b/daemon.c
index 4c8346d..9253192 100644
--- a/daemon.c
+++ b/daemon.c
@@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err, va_list params)
exit(1);
}
-static char *path_ok(char *directory)
+static const char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- char *path;
+ const char *path;
char *dir;
dir = directory;
diff --git a/path.c b/path.c
index 6f3f5d5..f3d96aa 100644
--- a/path.c
+++ b/path.c
@@ -283,7 +283,7 @@ return_null:
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -297,14 +297,17 @@ char *enter_repo(char *path, int strict)
};
int len = strlen(path);
int i;
- while ((1 < len) && (path[len-1] == '/')) {
- path[len-1] = 0;
+ while ((1 < len) && (path[len-1] == '/'))
len--;
- }
+
if (PATH_MAX <= len)
return NULL;
- if (path[0] == '~') {
- char *newpath = expand_user_path(path);
+ strncpy(used_path, path, len);
+ used_path[len] = 0;
+ strcpy(validated_path, used_path);
+
+ if (used_path[0] == '~') {
+ char *newpath = expand_user_path(used_path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
return NULL;
@@ -316,24 +319,18 @@ char *enter_repo(char *path, int strict)
* anyway.
*/
strcpy(used_path, newpath); free(newpath);
- strcpy(validated_path, path);
- path = used_path;
}
else if (PATH_MAX - 10 < len)
return NULL;
- else {
- path = strcpy(used_path, path);
- strcpy(validated_path, path);
- }
- len = strlen(path);
+ len = strlen(used_path);
for (i = 0; suffix[i]; i++) {
- strcpy(path + len, suffix[i]);
- if (!access(path, F_OK)) {
+ strcpy(used_path + len, suffix[i]);
+ if (!access(used_path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i] || chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Sitaram Chamarty @ 2011-10-04 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phil Hord, Sitaram Chamarty, git
In-Reply-To: <7vty7oblpu.fsf@alter.siamese.dyndns.org>
On Wed, Oct 5, 2011 at 12:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Phil Hord <phil.hord@gmail.com> writes:
>
>> On Tue, Oct 4, 2011 at 11:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> I think I've seen this done as: "do this? [Y/n]" elsewhere.
>>>
>>> Not telling you what to do, but trying to feel what others may think.
>>
>> I think so, too. The [y]/n syntax is not clear enough for me to
>> confidently know what the default value will be.
>
> One downside of "do this [Y,n,m,o,p,q]? " is that it limits us to
> lowercase responses, which means we cannot assign 'q' for quitting from
> the innermost nested context and assign 'Q' for quitting from the whole
> interactive loop (e.g. "git add -p").
>
> "do this [y,n,m,o,p,q] (default=y)? "
Does this even make a difference in this case? I was going to send
out a new patch using [Y/n] instead of my original [y]/n. There's
only one loop in this thing, and till now people have been presumably
hitting Ctrl-C to get out of it. I see no real need to make that more
elegant; all I set out to do is add one teeny weeny bit of
functionality to a prompt that -- other than giving you a chance to
hit that Ctrl-C -- was not actually doing anything useful at all.
>
> may have been a better choice in hindsight.
>
> No matter what we end up doing, let's try to be consistent.
The only other part of git where I have ever used a prompt is 'git add
-p'. Consistency with *that* prompt, to me, would mean colors. And
help text. And I'm not sure what else, really, since I only used it
superficially.
Isn't that overkill for this case?
I'll wait a few hours for any further comments then send out a patch
that is the same as my original one except it uses [Y/n] instead of
[y]/n.
^ permalink raw reply
* Re: [PATCH 1/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 23:01 UTC (permalink / raw)
To: Phil Hord; +Cc: Junio C Hamano, git, Erik Faye-Lund
In-Reply-To: <4E8B8DEA.1000606@cisco.com>
On Tue, Oct 4, 2011 at 6:51 PM, Phil Hord <hordp@cisco.com> wrote:
> From: Erik Faye-Lund <kusmabite@gmail.com>
>
> +++ b/daemon.c
> @@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err,
> va_list params)
> exit(1);
Blast! Borked again.
I'll re-work on this and try again tomorrow.
P
^ permalink raw reply
* Re: [PATCH 1/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Erik Faye-Lund, phil.hord
From: Erik Faye-Lund <kusmabite@gmail.com>
entr_repo(..., 0) currently modifies the input to strip away
trailing slashes. This means that we some times need to copy the
input to keep the original.
Change it to unconditionally copy it into the used_path buffer so
we can safely use the input without having to copy it. Also store
a working copy in validated_path up-front before we start
resolving anything.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/cache.h b/cache.h
index 9994a3c..7eeb8cf 100644
--- a/cache.h
+++ b/cache.h
@@ -734,7 +734,7 @@ int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
int mkdir_in_gitdir(const char *path);
extern char *expand_user_path(const char *path);
-char *enter_repo(char *path, int strict);
+const char *enter_repo(const char *path, int strict);
static inline int is_absolute_path(const char *path)
{
return is_dir_sep(path[0]) || has_dos_drive_prefix(path);
diff --git a/daemon.c b/daemon.c
index 4c8346d..9253192 100644
--- a/daemon.c
+++ b/daemon.c
@@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err,
va_list params)
exit(1);
}
-static char *path_ok(char *directory)
+static const char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- char *path;
+ const char *path;
char *dir;
dir = directory;
diff --git a/path.c b/path.c
index 6f3f5d5..f3d96aa 100644
--- a/path.c
+++ b/path.c
@@ -283,7 +283,7 @@ return_null:
* links. User relative paths are also returned as they are given,
* except DWIM suffixing.
*/
-char *enter_repo(char *path, int strict)
+const char *enter_repo(const char *path, int strict)
{
static char used_path[PATH_MAX];
static char validated_path[PATH_MAX];
@@ -297,14 +297,17 @@ char *enter_repo(char *path, int strict)
};
int len = strlen(path);
int i;
- while ((1 < len) && (path[len-1] == '/')) {
- path[len-1] = 0;
+ while ((1 < len) && (path[len-1] == '/'))
len--;
- }
+
if (PATH_MAX <= len)
return NULL;
- if (path[0] == '~') {
- char *newpath = expand_user_path(path);
+ strncpy(used_path, path, len);
+ used_path[len] = 0;
+ strcpy(validated_path, used_path);
+
+ if (used_path[0] == '~') {
+ char *newpath = expand_user_path(used_path);
if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
free(newpath);
return NULL;
@@ -316,24 +319,18 @@ char *enter_repo(char *path, int strict)
* anyway.
*/
strcpy(used_path, newpath); free(newpath);
- strcpy(validated_path, path);
- path = used_path;
}
else if (PATH_MAX - 10 < len)
return NULL;
- else {
- path = strcpy(used_path, path);
- strcpy(validated_path, path);
- }
- len = strlen(path);
+ len = strlen(used_path);
for (i = 0; suffix[i]; i++) {
- strcpy(path + len, suffix[i]);
- if (!access(path, F_OK)) {
+ strcpy(used_path + len, suffix[i]);
+ if (!access(used_path, F_OK)) {
strcat(validated_path, suffix[i]);
break;
}
}
- if (!suffix[i] || chdir(path))
+ if (!suffix[i] || chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* Re: [RFC/PATCH]: reverse bisect v 2.0
From: Christian Couder @ 2011-10-04 22:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Michal Vyskocil, git, Sverre Rabbelier, Johannes Sixt
In-Reply-To: <7vfwj8dbn0.fsf@alter.siamese.dyndns.org>
Hi,
On Tuesday 04 October 2011 17:22:59 Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> > On Mon, Oct 03, 2011 at 10:00:25AM -0700, Junio C Hamano wrote:
> >
> > And the --started-to would literally be implemented as flipping the
> > meaning of "git bisect yes" and "git bisect no", and nothing more. IOW,
> > it's just another way of spelling "git bisect --reverse".
>
> Yes, if we wanted to also implement the flipping of the mapping between
> yes/no and good/bad, I do not have any problem with --used-to/--started-to
> pair of options.
If we decide to go with yes/no, an option like:
--yes-means=<it behaves like this>
seems to me easier to understand. Though I recognize that it doesn't tell that
the behavior changed.
And before responding to this thread I wanted to have another look at the
unfinished patch that Dscho sent a few years ago, but I did not have much time
these past few days, and I could not find it anymore.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 0/9] i18n: add PO files to po/
From: Junio C Hamano @ 2011-10-04 22:15 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Jonathan Nieder, git, Ramkumar Ramachandra, Peter Krefting,
Marcin Cieślak, Sam Reed, Jan Engelhardt, Jan Krüger,
Nguyễn Thái Ngọc
In-Reply-To: <CACBZZX5uz5cdoWebYOY-Omu0drnQasJB-12DMZyZ_NX17jzhmg@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> I think it's a bit too premature to try to plan this all ahead, why
> not just take patches to po/ and see what the friction points are,
> then address those as they arise?
> ...
>> 3. how can we avoid this making "git log -p" output unusable?
These two are somewhat mutually exclusive. I _suspect_ that Jonathan might
have been hinting me to eject everything under the current po/ directory,
and bind that part of the tree as a submodule from another repository,
which would give us "git log -p" cleanliness automatically. Taking more
patches to po/ would not help that process, even though it won't hinder
it.
^ permalink raw reply
* Re: [PATCH 0/9] i18n: add PO files to po/
From: Nguyen Thai Ngoc Duy @ 2011-10-04 22:09 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ævar Arnfjörð, git, Junio C Hamano,
Ramkumar Ramachandra, Peter Krefting, Marcin Cieślak,
Sam Reed, Jan Engelhardt, Jan Krüger
In-Reply-To: <20111003220659.GA19537@elie>
On Tue, Oct 4, 2011 at 9:06 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> 3. Maybe some hero will implement
>
> git log -p --exclude=po/
> # or
> git log -p -- :(not)po/
>
> to complement "git log -p -- po/". ;-)
Meanwhile, how about keeping po in its own repository? Translations
usually lag behind anyway. This keeps main repo "clean". Junio can
declare string freeze 1-2 weeks before a new release, so that
translations can be updated, then he can make a tarball containing
both git.git and git-translations.git.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/9] i18n: add PO files to po/
From: Ævar Arnfjörð Bjarmason @ 2011-10-04 21:58 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Junio C Hamano, Ramkumar Ramachandra, Peter Krefting,
Marcin Cieślak, Sam Reed, Jan Engelhardt, Jan Krüger,
Nguyễn Thái Ngọc
In-Reply-To: <20111003220659.GA19537@elie>
On Tue, Oct 4, 2011 at 00:06, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
>> It's been a long time coming, but here's an initial submission of PO
>> files to the po/ directory. This adds some initial and as of yet
>> unused translations.
>
> Neat. I think it's good to figure out what we will do with these
> anyway, and we don't have to wait for the infrastructure to do that.
I think it's a bit too premature to try to plan this all ahead, why
not just take patches to po/ and see what the friction points are,
then address those as they arise?
The reason I'm submitting this is because:
* Other parts of the i18n series depend on there being some PO files
for tests etc.
* I've had these sitting in my tree for way to long and there's no
reason not to stick them in git.git for further improvement.
> So, basic questions:
>
> 1. which branch will be translated?
Translations are an end user product, so I think it makes sense to
just translate the master when it's near or in the RC phase when you
know your work will make it into the end release and be useful to
users.
> 2. who keeps track of incoming translations?
While we could set up some "i18n maintainer" infrastructure why not
just have people submit patches to the list like we do for every other
file in git?
The people maintaining each translation would be the authority on that
file so their patches should be fast-tracked once they're seen not te
be complete buffoons.
> 3. how can we avoid this making "git log -p" output unusable?
Well it's already going to be making "git log -p" output unusable for
most software projects that use git and any sort of pseudo-generated
files, so it sounds like having this in the core and raising an itch
to scratch might improve the git user experience for everyone with
e.g. an --exclude option to git log.
^ permalink raw reply
* Re: [PATCH 3/4] Teach transport about the gitfile mechanism
From: Nguyen Thai Ngoc Duy @ 2011-10-04 21:46 UTC (permalink / raw)
To: Phil Hord; +Cc: git, Erik Faye-Lund
In-Reply-To: <CABURp0qkVcpNRyEg8gcNPjv2KbRbdHYk1XsqCjkp8Yrf7T_Lkw@mail.gmail.com>
On Wed, Oct 5, 2011 at 7:08 AM, Phil Hord <phil.hord@gmail.com> wrote:
> +static int is_gitfile(const char *url)
> +{
> + struct stat st;
> + char buf[9];
> + int fd, len;
> + if (stat(url, &st))
> + return 0;
> + if (!S_ISREG(st.st_mode))
> + return 0;
> + if (st.st_size < 10 || st.st_size > PATH_MAX)
> + return 1;
> +
> + fd = open(url, O_RDONLY);
> + if (fd < 0)
> + die_errno("Error opening '%s'", url);
> + len = read_in_full(fd, buf, sizeof(buf));
> + close(fd);
> + if (len != sizeof(buf))
> + die("Error reading %s", url);
> + return !prefixcmp(buf, "gitdir: ");
> +}
> +
There's similar code in get_repo_path(), builtin/clone.c, added in
commit 9b0ebc7 (clone: allow to clone from .git file). Perhaps you can
reuse this function there and remove duplicate code.
--
Duy
^ permalink raw reply
* Git Bug report
From: Federico Lucifredi @ 2011-10-04 21:24 UTC (permalink / raw)
To: git
Hello Git list,
Found a minor bug in git today - the error message reported is not
correct when trying to access a repo that is not accessible
permission-wise:
> federico@skyplex:/etc$ git log
> fatal: Not a git repository (or any of the parent directories): .git
with correct access permissions, everything works as expected.
> federico@skyplex:/etc$ sudo git log
> commit 10a1d0eefcc100a513a9dff46839cff2c4f9b5a0
> Author: root <root@skyplex>
> Date: Mon Oct 3 16:53:33 2011 -0400
>
> saving uncommitted changes in /etc prior to apt run
>
> commit 2abb2b397631c7f48757bbcb029ebc38e37659d6
> Author: federico <federico@skyplex>
> Date: Mon Oct 3 16:50:16 2011 -0400
>
> updating firefox packages next
>federico@skyplex:/etc$
> drwx------ 8 root root 4096 2011-10-03 16:53 .git
That's it... I am not subscribed to the list, CC me in reply as needed.
Best -Federico
--
_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - federico at canonical.com - GnuPG 0x4A73884C
^ permalink raw reply
* Re: [PATCH v3] refs: Use binary search to lookup refs faster
From: Junio C Hamano @ 2011-10-04 20:58 UTC (permalink / raw)
To: Michael Haggerty
Cc: Julian Phillips, Martin Fick, Christian Couder, git,
Christian Couder, Thomas Rast
In-Reply-To: <7vd3egj6aa.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> Um, well, my patch series includes the same changes that Julian's wants
>> to introduce, but following lots of other changes, cleanups,
>> documentation improvements, etc. Moreover, my patch series builds on
>> mh/iterate-refs, with which Julian's patch conflicts. In other words,
>> it would be a real mess to reroll my series on top of Julian's patch.
>
> Conflicts during re-rolling was not something I was worried too much
> about---that is just the fact of life. We cannot easily resolve two topics
> that want to go in totally different direction, but we should be able to
> converge two topics that want to take the same approach in the end,
> especially one is a subset of the other.
Ah, also I should have noted that I have a fix-up between mh/iterate-refs
and Julian's patch already queued on 'pu'.
I am planning to make mh/iterate-refs graduate to 'master' soonish, so
hopefully things will become simpler.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] log --children
From: Michael J Gruber @ 2011-10-04 20:51 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <1317761100-33922-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian venit, vidit, dixit 04.10.2011 22:45:
> Teach git-log to support --children, which was added by f35f5603f4
> to the revision machinery, and by 72276a3ecb to rev-list, but
> was never added to git-log.
>
> Also add tests for 'log --children' and 'log --parents'.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> On Tue, Oct 4, 2011 at 4:12 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> That means that "log --children --parents" will print out the parents'
>> sha1s, then the children's. Is that a good default format, or should we
>> somehow deal with the case when both are specified?
>
> They are mutually exclusive:
>
> $ git log --parents --children
> fatal: cannot combine --parents and --children
>
>> And I guess we would like to test this...
>
> Good idea. :-)
>
Thanks ;)
Looks good to me.
Michael
> j.
>
> log-tree.c | 12 ++++++++++++
> t/t4013-diff-various.sh | 2 ++
> t/t4013/diff.log_--children | 34 ++++++++++++++++++++++++++++++++++
> t/t4013/diff.log_--parents | 34 ++++++++++++++++++++++++++++++++++
> 4 files changed, 82 insertions(+), 0 deletions(-)
> create mode 100644 t/t4013/diff.log_--children
> create mode 100644 t/t4013/diff.log_--parents
>
> diff --git a/log-tree.c b/log-tree.c
> index 24c295ea1d..e7694a3a4c 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -165,6 +165,14 @@ static void show_parents(struct commit *commit, int abbrev)
> }
> }
>
> +static void show_children(struct rev_info *opt, struct commit *commit, int abbrev)
> +{
> + struct commit_list *p = lookup_decoration(&opt->children, &commit->object);
> + for ( ; p; p = p->next) {
> + printf(" %s", find_unique_abbrev(p->item->object.sha1, abbrev));
> + }
> +}
> +
> void show_decorations(struct rev_info *opt, struct commit *commit)
> {
> const char *prefix;
> @@ -414,6 +422,8 @@ void show_log(struct rev_info *opt)
> fputs(find_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
> if (opt->print_parents)
> show_parents(commit, abbrev_commit);
> + if (opt->children.name)
> + show_children(opt, commit, abbrev_commit);
> show_decorations(opt, commit);
> if (opt->graph && !graph_is_commit_finished(opt->graph)) {
> putchar('\n');
> @@ -473,6 +483,8 @@ void show_log(struct rev_info *opt)
> stdout);
> if (opt->print_parents)
> show_parents(commit, abbrev_commit);
> + if (opt->children.name)
> + show_children(opt, commit, abbrev_commit);
> if (parent)
> printf(" (from %s)",
> find_unique_abbrev(parent->object.sha1,
> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
> index 93a6f20871..a488325e2c 100755
> --- a/t/t4013-diff-various.sh
> +++ b/t/t4013-diff-various.sh
> @@ -231,6 +231,8 @@ log -GF -p master
> log -GF -p --pickaxe-all master
> log --decorate --all
> log --decorate=full --all
> +log --parents
> +log --children
>
> rev-list --parents HEAD
> rev-list --children HEAD
> diff --git a/t/t4013/diff.log_--children b/t/t4013/diff.log_--children
> new file mode 100644
> index 0000000000..bb8ed432cf
> --- /dev/null
> +++ b/t/t4013/diff.log_--children
> @@ -0,0 +1,34 @@
> +$ git log --children
> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64
> +Merge: 9a6d494 c7a2ab9
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:04:00 2006 +0000
> +
> + Merge branch 'side'
> +
> +commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a 59d314ad6f356dd08601a4cd5e530381da3e3c64
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:03:00 2006 +0000
> +
> + Side
> +
> +commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 59d314ad6f356dd08601a4cd5e530381da3e3c64
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:02:00 2006 +0000
> +
> + Third
> +
> +commit 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:01:00 2006 +0000
> +
> + Second
> +
> + This is the second commit.
> +
> +commit 444ac553ac7612cc88969031b02b3767fb8a353a 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:00:00 2006 +0000
> +
> + Initial
> +$
> diff --git a/t/t4013/diff.log_--parents b/t/t4013/diff.log_--parents
> new file mode 100644
> index 0000000000..bc4d44ff1f
> --- /dev/null
> +++ b/t/t4013/diff.log_--parents
> @@ -0,0 +1,34 @@
> +$ git log --parents
> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a
> +Merge: 9a6d494 c7a2ab9
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:04:00 2006 +0000
> +
> + Merge branch 'side'
> +
> +commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a 444ac553ac7612cc88969031b02b3767fb8a353a
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:03:00 2006 +0000
> +
> + Side
> +
> +commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:02:00 2006 +0000
> +
> + Third
> +
> +commit 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 444ac553ac7612cc88969031b02b3767fb8a353a
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:01:00 2006 +0000
> +
> + Second
> +
> + This is the second commit.
> +
> +commit 444ac553ac7612cc88969031b02b3767fb8a353a
> +Author: A U Thor <author@example.com>
> +Date: Mon Jun 26 00:00:00 2006 +0000
> +
> + Initial
> +$
^ permalink raw reply
* [PATCH v2] log --children
From: Jay Soffian @ 2011-10-04 20:45 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano, Michael J Gruber
In-Reply-To: <4E8B68AC.7020009@drmicha.warpmail.net>
Teach git-log to support --children, which was added by f35f5603f4
to the revision machinery, and by 72276a3ecb to rev-list, but
was never added to git-log.
Also add tests for 'log --children' and 'log --parents'.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
On Tue, Oct 4, 2011 at 4:12 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> That means that "log --children --parents" will print out the parents'
> sha1s, then the children's. Is that a good default format, or should we
> somehow deal with the case when both are specified?
They are mutually exclusive:
$ git log --parents --children
fatal: cannot combine --parents and --children
> And I guess we would like to test this...
Good idea. :-)
j.
log-tree.c | 12 ++++++++++++
t/t4013-diff-various.sh | 2 ++
t/t4013/diff.log_--children | 34 ++++++++++++++++++++++++++++++++++
t/t4013/diff.log_--parents | 34 ++++++++++++++++++++++++++++++++++
4 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 t/t4013/diff.log_--children
create mode 100644 t/t4013/diff.log_--parents
diff --git a/log-tree.c b/log-tree.c
index 24c295ea1d..e7694a3a4c 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -165,6 +165,14 @@ static void show_parents(struct commit *commit, int abbrev)
}
}
+static void show_children(struct rev_info *opt, struct commit *commit, int abbrev)
+{
+ struct commit_list *p = lookup_decoration(&opt->children, &commit->object);
+ for ( ; p; p = p->next) {
+ printf(" %s", find_unique_abbrev(p->item->object.sha1, abbrev));
+ }
+}
+
void show_decorations(struct rev_info *opt, struct commit *commit)
{
const char *prefix;
@@ -414,6 +422,8 @@ void show_log(struct rev_info *opt)
fputs(find_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
if (opt->print_parents)
show_parents(commit, abbrev_commit);
+ if (opt->children.name)
+ show_children(opt, commit, abbrev_commit);
show_decorations(opt, commit);
if (opt->graph && !graph_is_commit_finished(opt->graph)) {
putchar('\n');
@@ -473,6 +483,8 @@ void show_log(struct rev_info *opt)
stdout);
if (opt->print_parents)
show_parents(commit, abbrev_commit);
+ if (opt->children.name)
+ show_children(opt, commit, abbrev_commit);
if (parent)
printf(" (from %s)",
find_unique_abbrev(parent->object.sha1,
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 93a6f20871..a488325e2c 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -231,6 +231,8 @@ log -GF -p master
log -GF -p --pickaxe-all master
log --decorate --all
log --decorate=full --all
+log --parents
+log --children
rev-list --parents HEAD
rev-list --children HEAD
diff --git a/t/t4013/diff.log_--children b/t/t4013/diff.log_--children
new file mode 100644
index 0000000000..bb8ed432cf
--- /dev/null
+++ b/t/t4013/diff.log_--children
@@ -0,0 +1,34 @@
+$ git log --children
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64
+Merge: 9a6d494 c7a2ab9
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:04:00 2006 +0000
+
+ Merge branch 'side'
+
+commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a 59d314ad6f356dd08601a4cd5e530381da3e3c64
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:03:00 2006 +0000
+
+ Side
+
+commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 59d314ad6f356dd08601a4cd5e530381da3e3c64
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:02:00 2006 +0000
+
+ Third
+
+commit 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:01:00 2006 +0000
+
+ Second
+
+ This is the second commit.
+
+commit 444ac553ac7612cc88969031b02b3767fb8a353a 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:00:00 2006 +0000
+
+ Initial
+$
diff --git a/t/t4013/diff.log_--parents b/t/t4013/diff.log_--parents
new file mode 100644
index 0000000000..bc4d44ff1f
--- /dev/null
+++ b/t/t4013/diff.log_--parents
@@ -0,0 +1,34 @@
+$ git log --parents
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a
+Merge: 9a6d494 c7a2ab9
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:04:00 2006 +0000
+
+ Merge branch 'side'
+
+commit c7a2ab9e8eac7b117442a607d5a9b3950ae34d5a 444ac553ac7612cc88969031b02b3767fb8a353a
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:03:00 2006 +0000
+
+ Side
+
+commit 9a6d4949b6b76956d9d5e26f2791ec2ceff5fdc0 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:02:00 2006 +0000
+
+ Third
+
+commit 1bde4ae5f36c8d9abe3a0fce0c6aab3c4a12fe44 444ac553ac7612cc88969031b02b3767fb8a353a
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:01:00 2006 +0000
+
+ Second
+
+ This is the second commit.
+
+commit 444ac553ac7612cc88969031b02b3767fb8a353a
+Author: A U Thor <author@example.com>
+Date: Mon Jun 26 00:00:00 2006 +0000
+
+ Initial
+$
--
1.7.7.3.gaf8e
^ permalink raw reply related
* Re: [PATCH] log --children
From: Michael J Gruber @ 2011-10-04 20:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7vpqicbj8w.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 04.10.2011 22:21:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>>> @@ -414,6 +422,8 @@ void show_log(struct rev_info *opt)
>>> fputs(find_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
>>> if (opt->print_parents)
>>> show_parents(commit, abbrev_commit);
>>> + if (opt->children.name)
>>> + show_children(opt, commit, abbrev_commit);
>>
>> That means that "log --children --parents" will print out the parents'
>> sha1s, then the children's. Is that a good default format, or should we
>> somehow deal with the case when both are specified?
>
> I think these two options are muturally exclusive, not because of the
> "mixed output getting confusing" reasons but because of traversal reasons.
> IIRC, when parent rewriting is in effect, you cannot just say "a commit
> that has these commits on its parents list is a child of these commits",
> as you have to orphan and adopt it as a child of ancestor commits, which
> the code introduced in f35f5603 does not do.
>
I didn't think --parents would switch on rewriting, but I guess all is good:
git rev-list -5 --parents --children origin/next
fatal: cannot combine --parents and --children
Should be the same for log.
Michael
^ permalink raw reply
* Re: [PATCH 1/4] enter_repo: do not modify input
From: Junio C Hamano @ 2011-10-04 20:24 UTC (permalink / raw)
To: Phil Hord; +Cc: git, Erik Faye-Lund
In-Reply-To: <CABURp0rKRb+fZG5erKz08Dz+4d7mjoL842zbcA7uzZ8N5Qtn1Q@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
> diff --git a/daemon.c b/daemon.c
> index 4c8346d..9253192 100644
> --- a/daemon.c
> +++ b/daemon.c
> @@ -108,11 +108,11 @@ static void NORETURN daemon_die(const char *err,
> va_list params)
Corrupt and unappliable patch.
> - if (path[0] == '~') {
> - char *newpath = expand_user_path(path);
> + strncpy(used_path, path, len); used_path[len] = 0 ;
Do not write two statements on a single line; extra SP before ';'.
^ permalink raw reply
* Re: [PATCH] log --children
From: Junio C Hamano @ 2011-10-04 20:21 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jay Soffian, git
In-Reply-To: <4E8B68AC.7020009@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> @@ -414,6 +422,8 @@ void show_log(struct rev_info *opt)
>> fputs(find_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
>> if (opt->print_parents)
>> show_parents(commit, abbrev_commit);
>> + if (opt->children.name)
>> + show_children(opt, commit, abbrev_commit);
>
> That means that "log --children --parents" will print out the parents'
> sha1s, then the children's. Is that a good default format, or should we
> somehow deal with the case when both are specified?
I think these two options are muturally exclusive, not because of the
"mixed output getting confusing" reasons but because of traversal reasons.
IIRC, when parent rewriting is in effect, you cannot just say "a commit
that has these commits on its parents list is a child of these commits",
as you have to orphan and adopt it as a child of ancestor commits, which
the code introduced in f35f5603 does not do.
^ permalink raw reply
* Re: [PATCH 2/4] Learn to handle gitfiles in enter_repo
From: Phil Hord @ 2011-10-04 20:13 UTC (permalink / raw)
To: git, Erik Faye-Lund
In-Reply-To: <CABURp0r7o8Mq4RyjEac18syU3HwCXWm7FOe+Mu0PshVXddJwuA@mail.gmail.com>
On Tue, Oct 4, 2011 at 4:05 PM, Phil Hord <phil.hord@gmail.com> wrote:
> The enter_repo() function is used to navigate into a .git
> directory. It knows how to find standard alternatives (DWIM) but
> it doesn't handle gitfiles created by git init --separate-git-dir.
> This means that git-fetch and others do not work with repositories
> using the separate-git-dir mechanism.
>
> Teach enter_repo() to deal with the gitfile mechanism by resolving
> the path to the redirected path and continuing tests on that path
> instead of the found file.
>
> Signed-off-by: Phil Hord <hordp@cisco.com>
> ---
>
I meant to include this note on this patch. Maybe I should have added
an RFC, too.
I'm not sure how to resolve this change for the 'strict' case.
The actual path followed may be different than the version spelled
out on the input path because of resolved symlinks and whatnot.
This function normally returns the unmolested "original" path
that was validated. In case of a gitfile, I think that means
we should return the url resolved from the gitfile contents.
But should we?
The returned path is only used in git-daemon where it gets
further checks for path restrictions.
A. If we return the gitfile-resolved path, this may cause these
path restrictions to fail since the path gets canonicalized
when the gitfile is created by git.
B. If we do not return the gitfile-resolved path, this can create
a security-hole by allowing remote users to access files they
would otherwise have been restricted from. In effect it creates
an alternate symlink mechanism of which the administrator might
not be aware.
^ permalink raw reply
* Re: [PATCH] log --children
From: Michael J Gruber @ 2011-10-04 20:12 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <1317736923-20539-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian venit, vidit, dixit 04.10.2011 16:02:
> Teach git-log to support --children, which was added by f35f5603f4
> to the revision machinery, and by 72276a3ecb to rev-list, but
> was never added to git-log.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
> ---
> log-tree.c | 12 ++++++++++++
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/log-tree.c b/log-tree.c
> index 24c295ea1d..e7694a3a4c 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -165,6 +165,14 @@ static void show_parents(struct commit *commit, int abbrev)
> }
> }
>
> +static void show_children(struct rev_info *opt, struct commit *commit, int abbrev)
> +{
> + struct commit_list *p = lookup_decoration(&opt->children, &commit->object);
> + for ( ; p; p = p->next) {
> + printf(" %s", find_unique_abbrev(p->item->object.sha1, abbrev));
> + }
> +}
> +
> void show_decorations(struct rev_info *opt, struct commit *commit)
> {
> const char *prefix;
> @@ -414,6 +422,8 @@ void show_log(struct rev_info *opt)
> fputs(find_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
> if (opt->print_parents)
> show_parents(commit, abbrev_commit);
> + if (opt->children.name)
> + show_children(opt, commit, abbrev_commit);
That means that "log --children --parents" will print out the parents'
sha1s, then the children's. Is that a good default format, or should we
somehow deal with the case when both are specified?
> show_decorations(opt, commit);
> if (opt->graph && !graph_is_commit_finished(opt->graph)) {
> putchar('\n');
> @@ -473,6 +483,8 @@ void show_log(struct rev_info *opt)
> stdout);
> if (opt->print_parents)
> show_parents(commit, abbrev_commit);
> + if (opt->children.name)
> + show_children(opt, commit, abbrev_commit);
> if (parent)
> printf(" (from %s)",
> find_unique_abbrev(parent->object.sha1,
And I guess we would like to test this...
Michael
^ permalink raw reply
* [PATCH 4/4] Add test showing git-fetch groks gitfiles
From: Phil Hord @ 2011-10-04 20:09 UTC (permalink / raw)
To: git, Erik Faye-Lund
Add a test for two subtly different cases: 'git fetch path/.git'
and 'git fetch path' to confirm that transport recognizes both
paths as git repositories when using the gitfile mechanism.
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index e810314..87ee016 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -206,6 +206,20 @@ test_expect_success 'clone from .git file' '
git clone dst/.git dst2
'
+test_expect_success 'fetch from .git gitfile' '
+ (
+ cd dst2 &&
+ git fetch ../dst/.git
+ )
+'
+
+test_expect_success 'fetch from gitfile parent' '
+ (
+ cd dst2 &&
+ git fetch ../dst
+ )
+'
+
test_expect_success 'clone separate gitdir where target already exists' '
rm -rf dst &&
test_must_fail git clone --separate-git-dir realgitdir src dst
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jay Soffian @ 2011-10-04 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, John Szakmeister, Kyle Neath
In-Reply-To: <7vy5x0bmjk.fsf@alter.siamese.dyndns.org>
On Tue, Oct 4, 2011 at 3:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Hmm, don't we first want to enumerate contexts where we might want to get
> the access information from the user? E.g.
>
> * "transport" aka "git fetch/push"; I think you meant this by --type=network,
> but there probably are other kinds of accesses over "network".
> * "imap-send".
> * "send-email".
> * "tag -s" and perhaps upcoming "push --signed" or "commit --gpg-sign"?
>
> Anything else?
Perhaps it would be illustrative to look at the OS X keychain API call
for adding a password to the store:
OSStatus SecKeychainAddInternetPassword (
SecKeychainRef keychain,
UInt32 serverNameLength,
const char *serverName,
UInt32 securityDomainLength,
const char *securityDomain,
UInt32 accountNameLength,
const char *accountName,
UInt32 pathLength,
const char *path,
UInt16 port,
SecProtocolType protocol,
SecAuthenticationType authenticationType,
UInt32 passwordLength,
const void *passwordData,
SecKeychainItemRef *itemRef
);
SecProtocolType is an enum of 4-char values such as 'ftp ', 'http',
etc. Similarly for SecAuthenticationType which uses values such as
'form' (web form), 'http' (basic auth), etc.
http://developer.apple.com/library/mac/#documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecKeychainAddInternetPassword
http://developer.apple.com/library/mac/#documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecProtocolType
http://developer.apple.com/library/mac/#documentation/Security/Reference/keychainservices/Reference/reference.html#//apple_ref/doc/c_ref/SecAuthenticationType
j.
^ permalink raw reply
* [PATCH 3/4] Teach transport about the gitfile mechanism
From: Phil Hord @ 2011-10-04 20:08 UTC (permalink / raw)
To: git, Erik Faye-Lund
The transport_get() function assumes that a regular file is a
bundle rather than a local git directory. Look inside the file
for the telltale "gitlink: " header to see if it is actually a
gitfile. If so, do not try to process it as a bundle, but
treat it as a local repository instead.
Signed-off-by: Phil Hord <hordp@cisco.com>
diff --git a/transport.c b/transport.c
index cd49a25..f7017c1 100644
--- a/transport.c
+++ b/transport.c
@@ -867,6 +867,28 @@ static int is_local(const char *url)
has_dos_drive_prefix(url);
}
+static int is_gitfile(const char *url)
+{
+ struct stat st;
+ char buf[9];
+ int fd, len;
+ if (stat(url, &st))
+ return 0;
+ if (!S_ISREG(st.st_mode))
+ return 0;
+ if (st.st_size < 10 || st.st_size > PATH_MAX)
+ return 1;
+
+ fd = open(url, O_RDONLY);
+ if (fd < 0)
+ die_errno("Error opening '%s'", url);
+ len = read_in_full(fd, buf, sizeof(buf));
+ close(fd);
+ if (len != sizeof(buf))
+ die("Error reading %s", url);
+ return !prefixcmp(buf, "gitdir: ");
+}
+
static int is_file(const char *url)
{
struct stat buf;
@@ -915,7 +937,7 @@ struct transport *transport_get(struct remote
*remote, const char *url)
ret->fetch = fetch_objs_via_rsync;
ret->push = rsync_transport_push;
ret->smart_options = NULL;
- } else if (is_local(url) && is_file(url)) {
+ } else if (is_local(url) && is_file(url) && !is_gitfile(url)) {
struct bundle_transport_data *data = xcalloc(1, sizeof(*data));
ret->data = data;
ret->get_refs_list = get_refs_from_bundle;
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
* [PATCH v3] gitk: Teach gitk to respect log.showroot
From: Marcus Karlsson @ 2011-10-04 20:08 UTC (permalink / raw)
To: paulus; +Cc: zbyszek, gitster, git
In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development history in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.
"git log" learned to show the patch for the initial commit without requiring
--root command line option at 0f03ca9 (config option log.showroot to show
the diff of root commits, 2006-11-23).
Teach gitk to respect log.showroot.
Signed-off-by: Marcus Karlsson <mk@acc.umu.se>
---
Improved the commit message after suggestion from Zbigniew
Jedrzejewski-Szmek.
gitk-git/gitk | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 4cde0c4..40ea73f 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7402,7 +7402,7 @@ proc addtocflist {ids} {
}
proc diffcmd {ids flags} {
- global nullid nullid2
+ global log_showroot nullid nullid2
set i [lsearch -exact $ids $nullid]
set j [lsearch -exact $ids $nullid2]
@@ -7436,7 +7436,11 @@ proc diffcmd {ids flags} {
lappend cmd HEAD
}
} else {
- set cmd [concat | git diff-tree -r $flags $ids]
+ set cmd [concat | git diff-tree -r]
+ if {$log_showroot eq true} {
+ set cmd [concat $cmd --root]
+ }
+ set cmd [concat $cmd $flags $ids]
}
return $cmd
}
@@ -11403,6 +11407,11 @@ catch {
}
}
+set log_showroot true
+catch {
+ set log_showroot [exec git config --get log.showroot]
+}
+
if {[tk windowingsystem] eq "aqua"} {
set mainfont {{Lucida Grande} 9}
set textfont {Monaco 9}
--
1.7.7
^ permalink raw reply related
* [PATCH 2/4] Learn to handle gitfiles in enter_repo
From: Phil Hord @ 2011-10-04 20:05 UTC (permalink / raw)
To: git, Erik Faye-Lund
The enter_repo() function is used to navigate into a .git
directory. It knows how to find standard alternatives (DWIM) but
it doesn't handle gitfiles created by git init --separate-git-dir.
This means that git-fetch and others do not work with repositories
using the separate-git-dir mechanism.
Teach enter_repo() to deal with the gitfile mechanism by resolving
the path to the redirected path and continuing tests on that path
instead of the found file.
Signed-off-by: Phil Hord <hordp@cisco.com>
---
This change allows enter_repo to work with gitfiles, but another change
is required to teach transport.c to recognize gitfiles as git-dirs.
diff --git a/path.c b/path.c
index 01028f2..b6f71d1 100644
--- a/path.c
+++ b/path.c
@@ -295,6 +295,7 @@ const char *enter_repo(const char *path, int strict)
static const char *suffix[] = {
".git/.git", "/.git", ".git", "", NULL,
};
+ const char *gitfile;
int len = strlen(path);
int i;
while ((1 < len) && (path[len-1] == '/'))
@@ -329,7 +330,12 @@ const char *enter_repo(const char *path, int strict)
break;
}
}
- if (!suffix[i] || chdir(used_path))
+ if (!suffix[i])
+ return NULL;
+ gitfile = read_gitfile(used_path) ;
+ if (gitfile)
+ strcpy(used_path, gitfile);
+ if (chdir(used_path))
return NULL;
path = validated_path;
}
--
1.7.7.503.g26392.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox