* Re: [PATCH v3 3/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 17:55 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, peff, j6t, gitster, rene.scharfe
In-Reply-To: <1317329963-6656-4-git-send-email-kusmabite@gmail.com>
On Thu, Sep 29, 2011 at 4:59 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> 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.
I'm also modifying enter_repo() so I'm looking a bit closer at this patch now.
> Change it to unconditionally copy it into the used_path buffer so
> we can safely use the input without having to copy it.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
[...]
> */
> -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,15 @@ 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);
When len < strlen(path), this will will leave used_path unterminated.
> +
> + if (used_path[0] == '~') {
> + char *newpath = expand_user_path(used_path);
> if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
> free(newpath);
> return NULL;
> @@ -316,24 +317,21 @@ char *enter_repo(char *path, int strict)
> * anyway.
> */
> strcpy(used_path, newpath); free(newpath);
> - strcpy(validated_path, path);
> - path = used_path;
> + strcpy(validated_path, used_path);
The point of 'validated_path' is to keep the original unmolested,
unexpanded path string (plus DWIM suffix), but here you've just
replaced validated_path with a copy of the expanded_user_path. On the
other hand, we seem always to strcpy(validated_path , path), so we
might as well get that done up-front.
I'll re-roll these changes in in a minute. Stand by.
Phil
^ permalink raw reply
* Re: [PATCH v3 3/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 18:00 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, peff, j6t, gitster, rene.scharfe
In-Reply-To: <CABURp0qDsxHwsuyvB6-KvKPrKuUT0-Fpr730TD_TxxFY7fotpA@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>
---
cache.h | 2 +-
daemon.c | 4 ++--
path.c | 28 ++++++++++++----------------
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/cache.h b/cache.h
index 607c2ea..a7e4de1 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..01028f2 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,16 @@ 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 +318,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: Phil Hord @ 2011-10-04 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sitaram Chamarty, git
In-Reply-To: <7vbotwdbjg.fsf@alter.siamese.dyndns.org>
On Tue, Oct 4, 2011 at 11:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaram@atc.tcs.com> writes:
>
>> Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com>
>> ---
>>
>> I'm using what is pretty much a universal convention to
>> signify that the default choice is "y"; I hope documentation
>> for something so small is not needed but if it is, let me
>> know and I'll do that also.
>>
>> - printf "Hit return to launch '%s': " \
>> + printf "Launch '%s' [y]/n: " \
>
> 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.
Phil
^ permalink raw reply
* Re: pack-object poor performance (with large number of objects?)
From: Jeff King @ 2011-10-04 18:08 UTC (permalink / raw)
To: Piotr Krukowiecki
Cc: Junio C Hamano, Shawn Pearce, Git Mailing List, Ingo Molnar
In-Reply-To: <CAA01Csp2rouKk4jvCH0Wu+0gc3+cvyH__d-yw8EHEkeZhRpX1Q@mail.gmail.com>
On Tue, Oct 04, 2011 at 03:21:24PM +0200, Piotr Krukowiecki wrote:
> I have 4GB ram + 4GB swap. Is it possible the RAM is the problem if I
> always have free RAM left and my swap is almost not used?
> For example at the moment repack finished counting objects ("Counting
> objects: 1742200, done."):
>
> $ free -m
> total used free shared buffers cached
> Mem: 3960 3814 146 0 441 215
> -/+ buffers/cache: 3157 803
> Swap: 6143 694 5449
I am not the best person to comment on Linux's disk caching strategies,
but in general, it should prefer dropping disk cache over pushing
program memory into swap. So no, you're not swapping, but you are
working with only 800M or so to do your disk caching.
So depending how big pack-object's working set of objects is, we might
be overflowing that, and constantly evicting and re-reading objects. I
don't recall offhand what kind of locality there is to pack-object's
accesses.
One thing you could try to reduce the working set is to incrementally
pack some smaller chunks, and then combine them all at the end. That
ends up being more work overall, but at any given time, your working set
of objects will be smaller.
You'd have to do something like this (this is very untested):
# find out how many revisions we have. Let's pretend it's about
# 25,000.
git rev-list HEAD | wc -l
# now split them into chunks of whatever size you feel like trying.
# 1000, maybe, or a few thousand. Bearing in mind that this is a gross
# approximation, since the history is not linear.
#
# Start with HEAD~24K (25K total, minus 1K we want to pack)
echo HEAD~24000 | git pack-objects --revs .git/objects/pack/pack
# And then prune the loose objects that we just packed.
git prune-packed
# And repeat for the next chunk
echo HEAD~24000..HEAD~23000 | git pack-objects --revs .git/objects/pack/pack
git prune-packed
# And so forth...
And then at the end, probably do a "git repack -ad" to put it all in
one big pack. Which should hopefully be less disk-intensive, because now
you'll have a much smaller disk footprint, since most of your objects
are at least delta'd against the others in their own pack.
I have no idea if this will actually go faster for you. But it might be
worth trying, instead of just redoing the svn import with auto-gc turned
on.
-Peff
^ permalink raw reply
* Re: Git ksshaskpass to play nice with https and kwallet
From: Michael J Gruber @ 2011-10-04 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20111004124344.GA30162@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 04.10.2011 14:43:
> On Tue, Oct 04, 2011 at 02:12:02PM +0200, Michael J Gruber wrote:
>
>>> The latter is especially useful if you have put a username in your
>>> ~/.gitconfig, in which case you get:
>>
>> I'm actually wondering why git can't infer the user from
>>
>> https://user@host.com
>>
>> with last week's next, at least.
>
> It can, and it has for some time. Part of the configurable-username
> thing was that it would be way nicer to just use a user-agnostic URL,
> because it means it's easier to share with other people.
>
We seem to mean something different:
git config --get remote.bitbucket.pushurl
https://grubix@bitbucket.org/grubix/git.git
SSH_ASKPASS= git push -n bitbucket
Username for 'bitbucket.org':
I mean that git should not need to ask for the username here.
Michael
^ permalink raw reply
* Git attributes ignored for root directory
From: Gioele Barabucci @ 2011-10-04 18:52 UTC (permalink / raw)
To: git
Hello,
I just updated to git v1.7.7 using the Ubuntu Lucid PPA and I found that
`git check-attr` is broken now.
I have this attribute in my `$HOME/.gitattributes` file:
/. show_in_prompt=no
Now, if I go to `$HOME` and run
git check-attr show_in_prompt -- .
With git v1.7.6 this is the answer I got:
.: show_in_prompt: no
With the newer v1.7.7 I get this, instead:
.: show_in_prompt: unspecified
Also, if I use the `--all` option, `check-attr` does not show any
attribute at all.
I see in the release notes of 1.7.7-rc1 that `check-attr` has been
changed to allow relative paths to be specified. Maybe this error is
related to that change.
Best,
--
Gioele Barabucci <gioele@svario.it>
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Junio C Hamano @ 2011-10-04 19:10 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, John Szakmeister, Kyle Neath
In-Reply-To: <20111004174840.GA31558@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> No, sadly I don't think we're there yet.
It is much better to proceed with caution than unleashing something whose
semantics will later have to change so drastically that we end up hurting
end users, so nobody has to say "sadly". By spelling out what more needs
to be there for us to get there, we are making progress.
> The two big open questions are:
>
> 1. Should we be giving more context details to the helpers, and/or
> should we be breaking down the information into pieces?
>
> I think the answer is probably yes. Certainly OS X would benefit
> from the broken-down pieces. My feeling is that we could hand
> helpers both broken-down pieces as well as an inclusive URL. So
> something like:
>
> git credential-foo \
> --type=network --protocol=https --host=example.com \
> --username=user1 --path=repo.git \
> --url=https://user1@example.com/repo.git
>
> and then the helper can pick what it likes from there.
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?
I am not sure where the unlocking passphrase for ssl cert fits in this
picture, though.
> One thing I haven't figured out is how the user would tell git "no,
> the repo path is not relevant for determining the auth domain".
> That feature can come later, but I want to make sure that helpers
> know they might or might not get the "--path" option. I guess that
> is just a matter of documentation; I'm just a little nervous
> committing to it without having figured out the details.
Well, shouldn't the caller of credential-foo be passing --authdomain as a
separate piece anyway? In the above example, if example.com operates as a
single auth domain no matter what repository, --authdomain may just say
"". If it uses per repository auth domain, --authdomain may say "repo.git"
(I am assuming <authdomain> is not globally unique but unique within the
context of <type, host> or perhaps <type, proto, host>).
> 2. There has been some talk that the helper interface should perhaps
> be vastly simplified from "get the credentials and give them to
> git" to merely being a store/retrieve system, where the invocations
> would be something like (pretend git is the shell):
>
> # git asks if we have a stored credential
> git credential-foo --get --url=...,etc | read password
>
> # we had a successful authentication; ask the helper to store it;
> echo password | git credential-foo --put --url=...,etc
>
> That makes the helpers much simpler, and makes interacting with the
> user more uniform across helpers.
>
> It disallows helpers doing specialized interactions or dialogs.
Very true.
I have this suspicion that running dialog on various desktop environments
may be orthogonal to what credential store to be used. Once we know the
repertoire of the broken-down pieces, we may want to add "dialog-foo"
family of helpers whose sole purpose is to interact with the user to get
missing information. E.g. we may notice that we need to ask both the
username and password, and invoke
$ dialog-foo --msg=$msg --ask=username --ask-secret=password
where $msg tells the user why we are asking these pieces (e.g. trying to
push into https://example.com/repo.git), and then read from the helper
what the user gave it.
If the URL had user1@ in it, then the $msg would say that we are trying to
push into https://example.com/repo.git as user1, and we invoke the helper
with only --ask-secret=password (without --ask=username).
The same "helper" executable _could_ implement both interfaces, but I
think they are logically separate.
^ permalink raw reply
* Re: [PATCH] git-difftool: allow skipping file by typing 'n' at prompt
From: Junio C Hamano @ 2011-10-04 19:28 UTC (permalink / raw)
To: Phil Hord; +Cc: Sitaram Chamarty, git
In-Reply-To: <CABURp0qmYWRJzHZZwZreKnj0ymFyM_AYXWXqwy=vTZspoPvvvg@mail.gmail.com>
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)? "
may have been a better choice in hindsight.
No matter what we end up doing, let's try to be consistent.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-completion: offer references for 'git reflog'
From: Michael Schubert @ 2011-10-04 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h4kd6vg.fsf@alter.siamese.dyndns.org>
On 10/04/2011 07:05 PM, Junio C Hamano wrote:
> Michael Schubert <mschub@elegosoft.com> writes:
>
>> On 09/25/2011 12:42 PM, Michael Schubert wrote:
>>> 'git reflog <ref>' is a valid command, therefore offer reference
>>> completion.
>>>
>>> Signed-off-by: Michael Schubert <mschub@elegosoft.com>
>>> ---
>>> contrib/completion/git-completion.bash | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>>> index 8648a36..63d0f08 100755
>>> --- a/contrib/completion/git-completion.bash
>>> +++ b/contrib/completion/git-completion.bash
>>> @@ -1774,7 +1774,7 @@ _git_reflog ()
>>> local subcommand="$(__git_find_on_cmdline "$subcommands")"
>>>
>>> if [ -z "$subcommand" ]; then
>>> - __gitcomp "$subcommands"
>>> + __gitcomp "$subcommands $(__git_refs)"
>>> else
>>> __gitcomp "$(__git_refs)"
>>> fi
>>
>> Ping.?
>
> Personally I think this change will give much less pleasant user
> experience. This is what I currently get:
>
> $ git reflog <TAB>
> delete expire show
> $ git reflog
>
> and after learning the "show" subcommand exists, this is what I would get:
>
> $ git reflog show <TAB>
> Display all 626 possibilities? (y or n)
>
> With your change, I would get:
>
> $ git reflog <TAB>
> Display all 629 possibilities? (y or n)
Yeah, that would be a tradeoff. IMHO the current behaviour is pleasant
for newcomers, but (I guess) most users would rather enjoy "the short form".
> and do not even have a chance to remind myself if the subcommand to drop
> a reflog was "delete" or "remove".
>
> At least when I know that I want to be reminded of refs to $verb (use one
> of the three subcommands I currently get in place of the "$verb"), I can
> say
>
> $ git reflog $verb <TAB>
>
> and at that point, I am willing to wade thru list of 600+ refs.
^ permalink raw reply
* [PATCH 1/4] enter_repo: do not modify input
From: Phil Hord @ 2011-10-04 20:02 UTC (permalink / raw)
To: git, Erik Faye-Lund
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>
---
This is Erik Faye-Lund's patch with some minor cleanup by me. I sent
this to the list earlier today for Erik, but I'm including it here
again as part of this series. Not sure what the etiquette is on this,
but this way seemed safest.
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..01028f2 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,16 @@ 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 +318,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
* [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
* [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 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
* 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 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] 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
* 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: 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 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: 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
* [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 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
* 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
* 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 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
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