* [PATCH 4/8] revision: add leak_pending flag
From: René Scharfe @ 2011-10-01 15:56 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
The new flag leak_pending in struct rev_info can be used to prevent
prepare_revision_walk from freeing the list of pending objects. It
will still forget about them, so it really is leaked. This behaviour
may look weird at first, but it can be useful if the pointer to the
list is saved before calling prepare_revision_walk.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
The next three patches are going to use this flag.
revision.c | 3 ++-
revision.h | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 2e8aa33..6d329b4 100644
--- a/revision.c
+++ b/revision.c
@@ -1974,7 +1974,8 @@ int prepare_revision_walk(struct rev_info *revs)
}
e++;
}
- free(list);
+ if (!revs->leak_pending)
+ free(list);
if (revs->no_walk)
return 0;
diff --git a/revision.h b/revision.h
index 4541265..366a9b4 100644
--- a/revision.h
+++ b/revision.h
@@ -97,6 +97,7 @@ struct rev_info {
date_mode_explicit:1,
preserve_subject:1;
unsigned int disable_stdin:1;
+ unsigned int leak_pending:1;
enum date_mode date_mode;
--
1.7.7
^ permalink raw reply related
* [PATCH 3/8] checkout: use add_pending_{object,sha1} in orphan check
From: René Scharfe @ 2011-10-01 15:51 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
Instead of building a list of textual arguments for setup_revisions, use
add_pending_object and add_pending_sha1 to queue the objects directly.
This is both faster and simpler.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/checkout.c | 39 ++++++++++++---------------------------
1 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5e356a6..84e0cdc 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -588,24 +588,11 @@ static void update_refs_for_switch(struct checkout_opts *opts,
report_tracking(new);
}
-struct rev_list_args {
- int argc;
- int alloc;
- const char **argv;
-};
-
-static void add_one_rev_list_arg(struct rev_list_args *args, const char *s)
-{
- ALLOC_GROW(args->argv, args->argc + 1, args->alloc);
- args->argv[args->argc++] = s;
-}
-
-static int add_one_ref_to_rev_list_arg(const char *refname,
- const unsigned char *sha1,
- int flags,
- void *cb_data)
+static int add_pending_uninteresting_ref(const char *refname,
+ const unsigned char *sha1,
+ int flags, void *cb_data)
{
- add_one_rev_list_arg(cb_data, refname);
+ add_pending_sha1(cb_data, refname, sha1, flags | UNINTERESTING);
return 0;
}
@@ -685,19 +672,17 @@ static void suggest_reattach(struct commit *commit, struct rev_info *revs)
*/
static void orphaned_commit_warning(struct commit *commit)
{
- struct rev_list_args args = { 0, 0, NULL };
struct rev_info revs;
-
- add_one_rev_list_arg(&args, "(internal)");
- add_one_rev_list_arg(&args, sha1_to_hex(commit->object.sha1));
- add_one_rev_list_arg(&args, "--not");
- for_each_ref(add_one_ref_to_rev_list_arg, &args);
- add_one_rev_list_arg(&args, "--");
- add_one_rev_list_arg(&args, NULL);
+ struct object *object = &commit->object;
init_revisions(&revs, NULL);
- if (setup_revisions(args.argc - 1, args.argv, &revs, NULL) != 1)
- die(_("internal error: only -- alone should have been left"));
+ setup_revisions(0, NULL, &revs, NULL);
+
+ object->flags &= ~UNINTERESTING;
+ add_pending_object(&revs, object, sha1_to_hex(object->sha1));
+
+ for_each_ref(add_pending_uninteresting_ref, &revs);
+
if (prepare_revision_walk(&revs))
die(_("internal error in revision walk"));
if (!(commit->object.flags & UNINTERESTING))
--
1.7.7
^ permalink raw reply related
* [PATCH 2/8] revision: factor out add_pending_sha1
From: René Scharfe @ 2011-10-01 15:43 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
This function is a combination of the static get_reference and
add_pending_object. It can be used to easily queue objects by hash.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
The next patch is going to use it in checkout.
revision.c | 11 ++++++++---
revision.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index c46cfaa..2e8aa33 100644
--- a/revision.c
+++ b/revision.c
@@ -185,6 +185,13 @@ static struct object *get_reference(struct rev_info *revs, const char *name, con
return object;
}
+void add_pending_sha1(struct rev_info *revs, const char *name,
+ const unsigned char *sha1, unsigned int flags)
+{
+ struct object *object = get_reference(revs, name, sha1, flags);
+ add_pending_object(revs, object, name);
+}
+
static struct commit *handle_commit(struct rev_info *revs, struct object *object, const char *name)
{
unsigned long flags = object->flags;
@@ -832,9 +839,7 @@ struct all_refs_cb {
static int handle_one_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
struct all_refs_cb *cb = cb_data;
- struct object *object = get_reference(cb->all_revs, path, sha1,
- cb->all_flags);
- add_pending_object(cb->all_revs, object, path);
+ add_pending_sha1(cb->all_revs, path, sha1, cb->all_flags);
return 0;
}
diff --git a/revision.h b/revision.h
index 3d64ada..4541265 100644
--- a/revision.h
+++ b/revision.h
@@ -191,6 +191,7 @@ extern void add_object(struct object *obj,
const char *name);
extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name);
+extern void add_pending_sha1(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags);
extern void add_head_to_pending(struct rev_info *);
--
1.7.7
^ permalink raw reply related
* [PATCH 1/8] checkout: check for "Previous HEAD" notice in t2020
From: René Scharfe @ 2011-10-01 15:38 UTC (permalink / raw)
Cc: Junio C Hamano, Martin Fick, Julian Phillips, Christian Couder,
git, Christian Couder, Thomas Rast
In-Reply-To: <4E8731AF.2040305@lsrfire.ath.cx>
If we leave a detached head, exactly one of two things happens: either
checkout warns about it being an orphan or describes it as a courtesy.
Test t2020 already checked that the warning is shown as needed. This
patch also checks for the description.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t2020-checkout-detach.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
index 2366f0f..068fba4 100755
--- a/t/t2020-checkout-detach.sh
+++ b/t/t2020-checkout-detach.sh
@@ -12,11 +12,14 @@ check_not_detached () {
}
ORPHAN_WARNING='you are leaving .* commit.*behind'
+PREV_HEAD_DESC='Previous HEAD position was'
check_orphan_warning() {
- test_i18ngrep "$ORPHAN_WARNING" "$1"
+ test_i18ngrep "$ORPHAN_WARNING" "$1" &&
+ test_i18ngrep ! "$PREV_HEAD_DESC" "$1"
}
check_no_orphan_warning() {
- test_i18ngrep ! "$ORPHAN_WARNING" "$1"
+ test_i18ngrep ! "$ORPHAN_WARNING" "$1" &&
+ test_i18ngrep "$PREV_HEAD_DESC" "$1"
}
reset () {
--
1.7.7
^ permalink raw reply related
* Re: Git is not scalable with too many refs/*
From: René Scharfe @ 2011-10-01 15:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Fick, Julian Phillips, Christian Couder, git,
Christian Couder, Thomas Rast
In-Reply-To: <4E8607B6.2040800@lsrfire.ath.cx>
Am 30.09.2011 20:17, schrieb René Scharfe:
> Am 30.09.2011 18:52, schrieb Junio C Hamano:
>> It might be a better solution to not bother to clear the marks at
>> all; would it break anything in this codepath?
>
> Unfortunately, yes; the cleanup part was added by 5c08dc48 later,
> when it become apparent that it's really needed.
>
> However, since the patch only buys us a 5% speedup I'm not sure it's
> worth it in its current form.
I found something better: A trick used by bisect and bundle. They copy
the list of pending objects from rev_info before calling
prepare_revision_walk and then go through it to clean up the commit
marks without going through the refs again. And I think we can even
improve it a little.
The following patches tighten some orphan/detached head tests a little,
then comes a resend of my first patch on this topic, only split up into
two, then four patches that introduce the trick mentioned above (which
could be squashed together perhaps) and the last one is a bonus
refactoring patch.
bisect.c | 20 +++++++-------
builtin/checkout.c | 58 +++++++++++++------------------------------
bundle.c | 11 +++-----
commit.c | 14 ++++++++++
commit.h | 1 +
revision.c | 14 +++++++---
revision.h | 2 +
t/t2020-checkout-detach.sh | 7 ++++-
8 files changed, 64 insertions(+), 63 deletions(-)
René
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Andreas Ericsson @ 2011-10-01 14:24 UTC (permalink / raw)
To: Albert Zeyer, Git Mailing List
In-Reply-To: <CAO1Q+jeLEp2ReNc9eOFoJxdGq6oRE3b+O=JvMNU0Kqx_eAX=7w@mail.gmail.com>
Please don't cull the list when replying. Reply-to-all is the
standard on git@vger.
On 10/01/2011 08:57 AM, Albert Zeyer wrote:
> On Sat, Oct 1, 2011 at 3:39 PM, Andreas Ericsson<ae@op5.se> wrote:
>> On 10/01/2011 07:44 AM, Albert Zeyer wrote:
>>> Hi,
>>>
>>> There are problems on MacOSX with different UTF8 encodings of
>>> filenames. A unicode string has multiple ways to be represented as
>>> UTF8 and Git treats them as different filenames. This is the actual
>>> bug. It should treat them all as the same filename. In some cases (as
>>> on MacOSX), the underlying operating system may use a normalized UTF8
>>> representation in some sort, i.e. change the actual UTF8 filename
>>> representation.
>>>
>>> Similar problems also exists in SVN, for example. This was reported
>>> [here](http://subversion.tigris.org/issues/show_bug.cgi?id=2464).
>>> There you can find also lengthy discussions about the topic. And also
>>> [here](http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames).
>>>
>>> This was already reported for Git earlier and there is also a patch
>>> for Git [here](http://lists-archives.org/git/719832-git-mac-os-x-and-german-special-characters.html).
>>>
>>> I wonder about the state of this. This hasn't been applied yet. Why?
>>>
>>
>> Because the patch didn't address repositories carrying files with
>> more than one possible representation of the filename and that
>> could have lead to silent loss of data for unsuspecting users.
>>
>> The real solution to your problem is, unfortunately, to either use
>> a different and more competent filesystem, or to avoid triggering
>> the bugs in the one you're currently using.
>
> Well, I think it is a bug in Git itself that it treats different UTF8
> representations of the same filename as different filenames. It
> shouldn't have allowed such in the first place.
>
> But I see your point. I guess I will work myself on a patch here or
> extend that one.
The trouble is that they may represent two different files on a
different filesystem. The Linux kernel repo has plenty of files
that exist with both uppercase and lowercase characters, like so:
SOMEFILE_driver.c
somefile_driver.c
This is perfectly valid on all sensible and case-sensitive
filesystems, but breaks horribly on HFS. There are other, far more
"interesting" cases when you involve special chars such as the
german umlaut, or the swedish åäö characters.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-10-01 14:11 UTC (permalink / raw)
To: Peter Shenkin; +Cc: git
In-Reply-To: <loom.20111001T073652-884@post.gmane.org>
On Sat, Oct 1, 2011 at 05:40, Peter Shenkin <shenkin@gmail.com> wrote:
> Michael Witten <mfwitten <at> gmail.com> writes:
>> Well, you're missing the fact that it not only causes those to
>> be downloaded, but it also causes the defaults to be ignored,
>> which is why you don't get the other stuff. You can still tell
>> git to fetch anything else you want in addition.
>
> I was no longer missing it at the time I posted.
>
> But that is indeed what I was missing when I first encountered
> the behavior. The purpose of posting was to point out that
> with a very small change in the documentation, I would not
> have missed it.
However, my point was this:
You can still tell git to fetch anything else you want in addition.
That point doesn't seem clear with your proposed alteration.
^ permalink raw reply
* Re: Git, Mac OS X and German special characters
From: Andreas Ericsson @ 2011-10-01 13:39 UTC (permalink / raw)
To: Albert Zeyer; +Cc: git
In-Reply-To: <CAO1Q+jf=RO=sE90-mQdi+=fUWH1RLM+JTubSgSVGC5uDyhU+2A@mail.gmail.com>
On 10/01/2011 07:44 AM, Albert Zeyer wrote:
> Hi,
>
> There are problems on MacOSX with different UTF8 encodings of
> filenames. A unicode string has multiple ways to be represented as
> UTF8 and Git treats them as different filenames. This is the actual
> bug. It should treat them all as the same filename. In some cases (as
> on MacOSX), the underlying operating system may use a normalized UTF8
> representation in some sort, i.e. change the actual UTF8 filename
> representation.
>
> Similar problems also exists in SVN, for example. This was reported
> [here](http://subversion.tigris.org/issues/show_bug.cgi?id=2464).
> There you can find also lengthy discussions about the topic. And also
> [here](http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames).
>
> This was already reported for Git earlier and there is also a patch
> for Git [here](http://lists-archives.org/git/719832-git-mac-os-x-and-german-special-characters.html).
>
> I wonder about the state of this. This hasn't been applied yet. Why?
>
Because the patch didn't address repositories carrying files with
more than one possible representation of the filename and that
could have lead to silent loss of data for unsuspecting users.
The real solution to your problem is, unfortunately, to either use
a different and more competent filesystem, or to avoid triggering
the bugs in the one you're currently using.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Jakub Narebski @ 2011-10-01 13:06 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw0QXkNSF8+qGu+pCrv5dgy1OEvtq-53f23GRd4RrZ1GcQ@mail.gmail.com>
Grant <emailgrant@gmail.com> writes:
> Hello, I'm trying to decide between git and subversion. Subversion
> has "Path-Based Authorization" so I can give a developer access to
> only specific files instead of everything. Does git have something
> similar?
>
> http://svnbook.red-bean.com/en/1.5/svn.serverconfig.pathbasedauthz.html
In distributed version control systems each developers gets full copy
(a clone) of a repository (separate repository instance). This means that
if you want for developer to see only specified subset of repository
(specific subdirectories) you would have to split repository into
submodules, and control access on (sub)repository basis.
However if you want only to prevent developer from making changes outside
specific subdirectory or specified files, you can do that on publish time
via update / pre-receive hook (like contrib/hooks/update-paranoid), or git
repository management tool such as Gitolite. That would prevent a push if
any of commits being published touches files that it shouldn't.
P.S. Karl Fogel in "Producing Open Source Software" (http://producingoss.com)
writes that social solutions wrt. restricting contributors to given area
are better than technical solutions such as (overly-)strict access
control.
HTH
--
Jakub Narębski
^ permalink raw reply
* Git, Mac OS X and German special characters
From: Albert Zeyer @ 2011-10-01 12:44 UTC (permalink / raw)
To: git
Hi,
There are problems on MacOSX with different UTF8 encodings of
filenames. A unicode string has multiple ways to be represented as
UTF8 and Git treats them as different filenames. This is the actual
bug. It should treat them all as the same filename. In some cases (as
on MacOSX), the underlying operating system may use a normalized UTF8
representation in some sort, i.e. change the actual UTF8 filename
representation.
Similar problems also exists in SVN, for example. This was reported
[here](http://subversion.tigris.org/issues/show_bug.cgi?id=2464).
There you can find also lengthy discussions about the topic. And also
[here](http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames).
This was already reported for Git earlier and there is also a patch
for Git [here](http://lists-archives.org/git/719832-git-mac-os-x-and-german-special-characters.html).
I wonder about the state of this. This hasn't been applied yet. Why?
Regards,
Albert
^ permalink raw reply
* Re: Dealing with rewritten upstream
From: Philip Oakley @ 2011-10-01 11:34 UTC (permalink / raw)
To: Jay Soffian, Michael Witten; +Cc: git
In-Reply-To: <CAG+J_Dw9Oa=LH1CSE3Dr_B6de8X-SQfrWGbayPy3OD-UqB6siA@mail.gmail.com>
From: "Jay Soffian" <jaysoffian@gmail.com>
> On Fri, Sep 30, 2011 at 7:04 PM, Michael Witten <mfwitten@gmail.com>
> wrote:
>>> Pictorially:
>>>
>>> ---A---B---C---D---E... new-upstream/master
>>>
>>> ---a---b---c---d---e... old-upstream/master
>>> \ \ \
>>> 1---2---3---4---5 master
>>>
>>> The obvious way do deal with this situation is:
>>>
>>> $ git merge -s ours -m "Splice in new-upstream/master" E
>>>
>>> Are there any other/better options I'm missing?
>>>
>>> (Eventually upstream plans to migrate entirely to git, so I can't just
>>> run git-svn myself.)
>>
>> Surely, you'd rather have your master rewritten such that the relevant
>> commits of new-upstream/master are used IN PLACE of the corresponding
>> old-upstream/master. Have you considered ways to achieve that?
>
> My master has over two years of history with its commit-IDs referenced
> in our bug tracker, in old emails, in archived binaries, etc. So no, I
> do not want to rewrite my master.
>
> Now, if you mean, do I want to use something like replacement refs to
> try to more cleanly splice the new upstream into my existing master,
> no I haven't really explored that. git-replace isn't very well
> documented with examples of its intended use case.
>
> I've considered setting up a new repo at a different URL that is
> rewritten to be based on the new upstream, and migrating to that,
> making the old repo read-only.
>
> But I'm not sure that's worth the trouble. There doesn't seem to be
> too much downside to splicing in the new upstream via merge -s ours.
> It barely increases the repo size since the trees are the same. Maybe
> there's some other downsides I'm missing.
>
Surely; one method is to simply create a merge between the Old_master and
New_master (i.e. have two parallel branches of identical content) at the
point where the new approach starts. Git-filter-branch (if used) already
provides the ref to the original, so it's easy to create that special merge.
You have already noted that all the trees for the commits are identical, so
the storage overhead is minimal for just the new commit objects (though the
cognitive overhead can be large for some - plan for often/early
explanations!)
I'm presuming that you will have at some point in the past, a common commit
(it maybe the initial commit), so that there is still a single root.
The key question is to decide which 'branch' is Parent1, and which is
Parent2 (at the merge) for any history traversals that may be required in
the future. After the merge you can rename the branch back to Master if
required (more cognitive discussions..)
This slightly differs from your original diagram in that you do not have any
one-to-one links between the old and new commits. The date/time would be the
same for the old & new so it shouldn't be hard to find one from the other.
Philip
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Jeff King @ 2011-10-01 10:54 UTC (permalink / raw)
To: Philip Oakley
Cc: Carlos Martín Nieto, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <BED2B875AEDF4E52843F1C9211A8D2A1@PhilipOakley>
On Sat, Oct 01, 2011 at 11:38:08AM +0100, Philip Oakley wrote:
> Is there a write up of the the git testing method and how to use
> bin-wrappers etc. I didn't see anything in the Documentation, but I
> may not have looked carefully enough
Bin-wrappers (and the alternative, which is setting up the exec-path
yourself) are mentioned briefly in INSTALL. Running tests is described
in t/README.
Other than that, you're left on your own to read the code and the commit
messages. :)
-Peff
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Philip Oakley @ 2011-10-01 10:38 UTC (permalink / raw)
To: Jeff King, Carlos Martín Nieto; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20111001060353.GA25228@sigill.intra.peff.net>
From: "Jeff King" <peff@peff.net>
> On Sat, Oct 01, 2011 at 01:54:08AM +0200, Carlos Martín Nieto wrote:
>
>> > Have you tried
>> >
>> > $ ./git fetch git://repo.or.cz/git
>>
>> But this would execute /usr/local/libexec/git-fetch, wouldn't it? That
>> is precisely what I don't want to execute, because I changed some code
>> in builtin/fetch.c that I want to test.
>
> No, but only because fetch is a builtin. However, it still doesn't set
> up exec_path correctly, so your rev-list problem would not go away.
>
>> I guess I'll have to either properly install git from 'next' or base my
>> changed on 'maint'
>
> Just use bin-wrappers/git. That's exactly what it's there for (and it's
> what the test scripts use to make sure we are testing what is compiled).
>
> Your change isn't the problem; only your testing method.
>
> -Peff
Peff,
Is there a write up of the the git testing method and how to use
bin-wrappers etc. I didn't see anything in the Documentation, but I may not
have looked carefully enough
Philip
^ permalink raw reply
* Re: [PATCH] gitk: Show patch for initial commit
From: Zbigniew Jędrzejewski-Szmek @ 2011-10-01 9:54 UTC (permalink / raw)
To: Marcus Karlsson; +Cc: git, gitster
In-Reply-To: <20110930215021.GA3005@kennedy.acc.umu.se>
On 09/30/2011 11:50 PM, Marcus Karlsson wrote:
> Make gitk show the patch for the initial commit.
>
> Signed-off-by: Marcus Karlsson<mk@acc.umu.se>
> ---
> gitk-git/gitk | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index 4cde0c4..20aeae6 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
> @@ -7436,7 +7436,7 @@ proc diffcmd {ids flags} {
> lappend cmd HEAD
> }
> } else {
> - set cmd [concat | git diff-tree -r $flags $ids]
> + set cmd [concat | git diff-tree -r --root $flags $ids]
> }
> return $cmd
> }
Cool, this works for me! But I think I would be really nice if gitk
respected the configuration value of log.showroot. This would give nice
consistency amongst the various tools.
Zbyszek
^ permalink raw reply
* Re: Fwd: Release notes link problem
From: Junio C Hamano @ 2011-10-01 6:58 UTC (permalink / raw)
To: Jeff King; +Cc: Eugene Sajine, git
In-Reply-To: <20111001061004.GA25700@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Sep 30, 2011 at 05:06:50PM -0400, Eugene Sajine wrote:
>
>> The release notes link on http://git-scm.com/ is pointing to a page
>> which doesn't seem to exist. I'm getting error 404 when trying to
>> access it. Does anybody see the same issue?
>>
>> the link is
>> https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.6.4.txt
>
> This was due to some breakage on github this afternoon, but I believe it
> has since been fixed.
I guess the link should be
https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.7.txt
instead ;-).
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: John Szakmeister @ 2011-10-01 6:57 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <CAG+J_DyhcA7RmHwgGJBw4r9JRij0_ONp3ZMD6oMTJ_f4dvYW8w@mail.gmail.com>
On Fri, Sep 30, 2011 at 3:33 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Thu, Sep 29, 2011 at 6:03 AM, John Szakmeister <john@szakmeister.net> wrote:
>>
>> I've been working on a version of the keychain credential cache as
>> well. I did create a gui, although it's a bit painful.
>
> I still don't understand why a CLI app should have a GUI credential prompt.
For one, I saw it more as being useful to things other than the git
command line. And the Mac already presents a GUI for unlocking the
keychain if necessary. It's not like there isn't any precedent for
it.
[snip]
>> I think that makes sense. I think one thing we have to be careful
>> about partial matches. I wouldn't want the credential cache to send
>> off the wrong password to a service. This may be me being cautious,
>> but if I don't have all the necessary bits, I'd rather we fail that to
>> guess which entry is right.
>
> The credential helper I wrote doesn't work that way. To do so would
> mean using a rather more complicated form of the OS X Security API. It
> asks for an entry using whatever fields it has, and OS X returns the
> first match that satisfies. It's up to the user to yea/nay that match
> if the credential helper isn't on the entry's ACL.
True, the user would at least have to acknowledge it.
>>>> + /* "GitHub for Mac" compatibility */
>>>> + if (!strcmp(hostname, "github.com"))
>>>> + hostname = "github.com/mac";
>>>
>>> Nice touch. :)
>>
>> I honestly don't understand why this needs to be done.
>
> Because GitHub for Mac stores its entries using "github.com/mac" as
> the hostname.
>
>> I don't use GitHub for Mac... does that mean this is busted for me?
>
> No. It just means that the credential helper and GitHub for Mac store
> their entry in a compatible fashion. (So that each can locate the
> entry stored by the other.)
Ah, interesting. But it does mean that it won't pick up the password
I've cached via my browser, right?
>> [snip]
>>> My series will also produce "cert:/path/to/certificate" when unlocking a
>>> certificate. The other candidates for conversion are smtp-auth (for
>>> send-email) and imap (for imap-send). I guess for certs, you'd want to
>>> use the "generic" keychain type.
>>
>> There is a method for adding a certificate to the keychain:
>> <http://developer.apple.com/library/mac/#documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/doc/uid/TP30000157>
>>
>> I'm not sure what that does exactly, but I do have a cert, and it
>> shows up as "certificate" in the keychain.
>
> That's for storing a certificate itself. In this case, I think we're
> just talking about storing the passphrase which protects the
> certificate's private key.
I could've sworn the docs mentioned storing the private key, but I
don't see it. SecIdentityCreateWithCertificate() can get you the
private key from a cert, once added. It's not clear how to go from
cert to password in a manner that's compatible with other Mac apps.
[snip]
>> By the time you get Keychain involved, the decision has been made.
>> Most applications offer that ability... and you're right, this should
>> probably offer the same capability. That also means stashing that
>> data somewhere. :-( OTOH, it does make for a better user experience.
>
> What, no? If you don't want git to store usernames/passwords stored in
> the OS X Keychain, don't use the git-osx-keychain credential helper.
I want *some* cached, and others not. I don't want to be forced to
remember to take git-osx-keychain out of my credentials list, or
something silly like that. That doesn't help on the user-friendliness
front. Having a check box and storing the fact that we shouldn't
cache the password in the repo's config seems like a reasonable
approach. But I agree with Jeff in another part of this thread: I
think the prompting of the username and password should be a separate
mechanism. It could prompt about whether or not to store the
password, and git could take care of whether or not to call the
credential store.
-John
^ permalink raw reply
* Re: Fwd: Release notes link problem
From: Jeff King @ 2011-10-01 6:10 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <CAPZPVFY9O2VC7TS9ASReD5LYiqfDwLY5M2vxE97M+7BsYvAoqg@mail.gmail.com>
On Fri, Sep 30, 2011 at 05:06:50PM -0400, Eugene Sajine wrote:
> The release notes link on http://git-scm.com/ is pointing to a page
> which doesn't seem to exist. I'm getting error 404 when trying to
> access it. Does anybody see the same issue?
>
> the link is
> https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.7.6.4.txt
This was due to some breakage on github this afternoon, but I believe it
has since been fixed.
-Peff
^ permalink raw reply
* Re: 6d4bb3833c3d2114d (fetch: verify we have everything we need before updating our ref) breaks fetch
From: Jeff King @ 2011-10-01 6:03 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <1317426849.4331.29.camel@centaur.lab.cmartin.tk>
On Sat, Oct 01, 2011 at 01:54:08AM +0200, Carlos Martín Nieto wrote:
> > Have you tried
> >
> > $ ./git fetch git://repo.or.cz/git
>
> But this would execute /usr/local/libexec/git-fetch, wouldn't it? That
> is precisely what I don't want to execute, because I changed some code
> in builtin/fetch.c that I want to test.
No, but only because fetch is a builtin. However, it still doesn't set
up exec_path correctly, so your rev-list problem would not go away.
> I guess I'll have to either properly install git from 'next' or base my
> changed on 'maint'
Just use bin-wrappers/git. That's exactly what it's there for (and it's
what the test scripts use to make sure we are testing what is compiled).
Your change isn't the problem; only your testing method.
-Peff
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 5:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vwrcpoozk.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> I think in general our documentation aims to spell out _all_ that happens,
...
> I am wondering if there is a systemic failure...
> ,,,If so are there things that we could
> do better without going through individual description?
Yes, I would say that there is one obvious
systemic failure.
Nowhere is it documented (as far as I am aware) that
this is the way the git documentation should be read.
Since, in this regard, it differs from most software
documentation, it ought itself to be documented,
perhaps on the top-level git man page.
-P.
^ permalink raw reply
* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Peter Shenkin @ 2011-10-01 5:40 UTC (permalink / raw)
To: git
In-Reply-To: <CAMOZ1BsTKBPArRF-LxoNOJcQarMWx-2a2UBoVjWN-96xJ3Ad8A@mail.gmail.com>
Michael Witten <mfwitten <at> gmail.com> writes:
> Well, you're missing the fact that it not only causes those to
> be downloaded, but it also causes the defaults to be ignored,
> which is why you don't get the other stuff. You can still tell
> git to fetch anything else you want in addition.
I was no longer missing it at the time I posted.
But that is indeed what I was missing when I first encountered
the behavior. The purpose of posting was to point out that
with a very small change in the documentation, I would not
have missed it.
-P.
^ permalink raw reply
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Jonathan Nieder @ 2011-10-01 5:29 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Ilari Liusvaara, git
In-Reply-To: <20111001022544.GA31036@LK-Perkele-VI.localdomain>
Ilari Liusvaara wrote:
> What about sticking code to return an error to git daemon instead of this?
The code has even been written:
http://thread.gmane.org/gmane.comp.version-control.git/145456/focus=145573
Testing and other improvements would be very welcome.
^ permalink raw reply
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Nguyen Thai Ngoc Duy @ 2011-10-01 4:27 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20111001022544.GA31036@LK-Perkele-VI.localdomain>
2011/10/1 Ilari Liusvaara <ilari.liusvaara@elisanet.fi>:
> What about sticking code to return an error to git daemon instead of this?
>
> Here's what happens if I try to push to one of repos on this computer
> over git://:
>
> $ git push git://localhost/foobar
> fatal: remote error: W access for foobar DENIED to anonymous
>
> So send-pack can deal with ERR packet (and yes, that error message
> is really from Gitolite).
I'm dealing with git.gnome.org and not sure what's the server behind.
I had a look at git-daemon and it does allow push, but disabled by
default. So yes, maybe updating git-daemon is better.
> Aside: git archive seemingly can't deal with ERR packets. And worse
> yet, it doesn't even print what it received, resulting this:
>
> $ git archive --remote=git://localhost/foobar HEAD
> fatal: git archive: protocol error
Yes, builtin/archive.c seems only recognize either ACK or NACK.
pack-protocol.txt does not mention about ERR either, which seems to be
introduced in a807328 (connect.c: add a way for git-daemon to pass an
error back to client).
--
Duy
^ permalink raw reply
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Ilari Liusvaara @ 2011-10-01 2:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1317432415-9459-1-git-send-email-pclouds@gmail.com>
On Sat, Oct 01, 2011 at 11:26:55AM +1000, Nguyễn Thái Ngọc Duy wrote:
> This protocol has never been designed for pushing. Attempts to push
> over git:// usually result in
>
> fatal: The remote end hung up unexpectedly
>
> That message does not really point out the reason. With this patch, we get
>
> error: this protocol does not support pushing
> error: failed to push some refs to 'git://some-host.com/my/repo'
What about sticking code to return an error to git daemon instead of this?
Here's what happens if I try to push to one of repos on this computer
over git://:
$ git push git://localhost/foobar
fatal: remote error: W access for foobar DENIED to anonymous
So send-pack can deal with ERR packet (and yes, that error message
is really from Gitolite).
Aside: git archive seemingly can't deal with ERR packets. And worse
yet, it doesn't even print what it received, resulting this:
$ git archive --remote=git://localhost/foobar HEAD
fatal: git archive: protocol error
-Ilari
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: david @ 2011-10-01 2:09 UTC (permalink / raw)
To: Grant; +Cc: git
In-Reply-To: <CAN0CFw1-Edb5PdoTzJz38vJOjjXVAg6F24XgHpTi+3e5C7yxfQ@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1965 bytes --]
On Fri, 30 Sep 2011, Grant wrote:
>>> I have a series of files containing server-side code which make up a
>>> website. The entire layout contains only a few folders, but those
>>> folders contain many files. I want to be able to allow access to only
>>> certain files at a time, sometimes only a single file. Can that be
>>> done in the way you describe?
>>
>> If you can gather all sensitive files in a subdirectory, then you can
>> split that directory into its own repository (see git-submodule man
>> page) and grant limited access to that repo.
>> --
>> Duy
>
> I thought about separating files the dev has had access to into a
> separate folder from files the dev hasn't had access to, but it would
> mean constantly changing the code as files move around, plus it would
> be too complicated if I have multiple devs and want to give them
> access to different stuff. It's not that some files are more
> sensitive than others, it's just that I don't want to give anyone
> access to more than I have to.
the thing to think about is why would you want to give a dev access to a
file or restrict their access.
Remember that the Dev should be able to test their changes, so you really
need to give them access to enough stuff to be a complete, working set.
If you make each set of things it's own repository, then you should have
the granularity you are looking for.
If you think you will need more granularity, please explain what you are
thinking of?
Also remember that you don't want to have your development files on your
production site, so you probably don't want to deploy directly from your
repository to the production site. If you use a filter to make a new git
repository that only contains the pieces that you are wanting to publish,
and keep that repository clean, only submitting the files that you want
there, but treat it as a read-only repository (i.e. no development work
done there), you should be in good shape.
David Lang
^ permalink raw reply
* Re: Does git have "Path-Based Authorization"?
From: Grant @ 2011-10-01 1:43 UTC (permalink / raw)
To: git
In-Reply-To: <CACsJy8Dm-vSoki9Fr7s=DH7oRYL-a=kF7q9mBwo55ZxsLg5DTA@mail.gmail.com>
>> I have a series of files containing server-side code which make up a
>> website. The entire layout contains only a few folders, but those
>> folders contain many files. I want to be able to allow access to only
>> certain files at a time, sometimes only a single file. Can that be
>> done in the way you describe?
>
> If you can gather all sensitive files in a subdirectory, then you can
> split that directory into its own repository (see git-submodule man
> page) and grant limited access to that repo.
> --
> Duy
I thought about separating files the dev has had access to into a
separate folder from files the dev hasn't had access to, but it would
mean constantly changing the code as files move around, plus it would
be too complicated if I have multiple devs and want to give them
access to different stuff. It's not that some files are more
sensitive than others, it's just that I don't want to give anyone
access to more than I have to.
- Grant
^ 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