* Re: More Beginning Git Questions
From: tactical @ 2011-09-24 20:22 UTC (permalink / raw)
To: git
In-Reply-To: <4E7CCCA0.50909@gmail.com>
Jon Forrest wrote:
>> Generally Alice shouldn't have uncommitted changes when doing
>> "git pull".
>
> That's what the tutorial said but I'm trying to understand
> what happens if she does have uncommitted changes. I'm
> trying to understand the total picture.
Mercurial allows this, and it's a very powerful feature. After reading
this thread, I could not believe Git didn't pulling with local changes, and
so I tried it, and also asked on IRC -- and it seems that Git really
doesn't.
If this is an important part of your workflow (as it is mine), I'd
recommend using Mercurial if possible.
^ permalink raw reply
* Re: sparse checkout bug?
From: Joshua Jensen @ 2011-09-24 20:19 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <CAG+J_DwRPq69TUMOeqU5O9pv=cHZWEP1VJ1_NRaJv5BSFhF00g@mail.gmail.com>
----- Original Message -----
From: Jay Soffian
Date: 9/24/2011 1:50 PM
> I wanted to exclude a single massive directory from a checkout (the
> LayoutTests directory from WebKit, which includes 130k files), so I
> tried:
>
> $ git config core.sparsecheckout true
> $ echo '*'> .git/info/sparse-checkout
> $ echo '!LayoutTests'>> .git/info/sparse-checkout
> $ git read-tree -m -u HEAD
>
> But LayoutTests is not being excluded. I also tried every variation of
> including leading/trailing slash and trailing '*'.
>
This bug has very recently been discussed on the mailing list.
As a workaround, use:
/*
instead of:
*
You said you have tried this already, but it works for me. The only
thing I do in addition is this:
/*
!LayoutTests/
-Josh
^ permalink raw reply
* sparse checkout bug?
From: Jay Soffian @ 2011-09-24 19:50 UTC (permalink / raw)
To: git
I wanted to exclude a single massive directory from a checkout (the
LayoutTests directory from WebKit, which includes 130k files), so I
tried:
$ git config core.sparsecheckout true
$ echo '*' > .git/info/sparse-checkout
$ echo '!LayoutTests' >> .git/info/sparse-checkout
$ git read-tree -m -u HEAD
But LayoutTests is not being excluded. I also tried every variation of
including leading/trailing slash and trailing '*'.
Simple repro:
git init sparse-test && cd sparse-test &&
touch foo && mkdir bar && touch bar/baz &&
git add foo bar/baz &&
git commit -m initial &&
git config core.sparsecheckout true &&
echo '*' > .git/info/sparse-checkout &&
echo '!bar' >> .git/info/sparse-checkout &&
git read-tree -m -u HEAD &&
ls -1R
foo
bar:
baz
j.
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Jonathan Nieder @ 2011-09-24 19:37 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Sverre Rabbelier, Dmitry Ivankov, David Barr
In-Reply-To: <1316878065-11782-2-git-send-email-vitor.hda@gmail.com>
Vitor Antunes wrote:
> The drop command deletes the given branch reference, allowing
> fast-import to actively ignore it in the final checks.
Thanks. I must have missed the earlier discussion. What are the
semantics of this command and its intended purpose? For example, what
happens if the branch already existed or if there is a checkpoint
(perhaps triggered by the impatient user sending SIGUSR1 to
fast-import) before the "drop" command is processed?
Jonathan
^ permalink raw reply
* bug with submodule and assume-unchanged
From: Orgad and Raizel Shaneh @ 2011-09-24 18:41 UTC (permalink / raw)
To: git
Hello,
Marking a submodule with update-index --assume-unchanged breaks diff.
Consider the script in http://pastebin.ca/2082543. The last 'diff'
output follows. Note that the diff for 'afile' is displayed, then sub
breaks the operation, and the diff for 'test' (or any other file that
comes after 'sub') is not displayed at all.
$:/tmp/git$ cd super/
$:/tmp/git/super$ git diff
fatal: unable to read c17499ae216dfba9538ed7f94ba109c2c5b87b2a
diff --git a/afile b/afile
index 14be0d4..7c2160f 100644
--- a/afile
+++ b/afile
@@ -1 +1 @@
-hello2
+goodbye2
diff --git a/sub b/sub
deleted file mode 160000
index c17499a..0000000
--- a/sub
+++ /dev/null
@@ -1 +0,0 @@
-Subproject commit c17499ae216dfba9538ed7f94ba109c2c5b87b2a
- Orgad
^ permalink raw reply related
* Fwd: git svn with non-standard svn layout
From: Chris Harris @ 2011-09-24 18:37 UTC (permalink / raw)
To: git
In-Reply-To: <CANPpUWyX+n7kMKZpCV=Oy=UmJb=9H=uZseYzU2-h1FLh2nzg8w@mail.gmail.com>
I am using git version 1.7.6.4 built from the latest stable source on
github. Running Ubuntu with kernel 2.6.38-11-generic
I can't seem to git git svn to see my branches correctly.
Unfortunately my svn repository is not open source, so I can not post
it here, but I will try to explain my issue.
We use a non standard svn layout like the following
branches
V4.1
V4.1.0
V4.1.1
dev
dev is our trunk, and our branches have 2 levels.
I first use git init, then setup my config as follows
[svn-remote "svn"]
url = file:///home/chris/svnrepo
fetch = dev:refs/remotes/trunk
branches = branches/V4.1/{V4.1.1}:refs/remotes/branches/*
For this example I am just trying to make a single branch work.
After a fetch all revisions are ok. master correctly points to
remotes/trunk,but gitk shows the following:
o remotes/branches/V4.1.1
|
o some commit
|
|
| o master - remotes/trunk
| |
| o another commit
| /
|
etc
( sorry for the bad ascii art. )
My issue is that trunk ( master ) appears to be a branch from V4.1.1
instead of V4.1.1 being a branch from trunk ( master )
git log --graph shows the same structure.
Any suggestions on how to configure this so git svn maps my
non-standard layout correctly?
Thank you
Chris
^ permalink raw reply
* Re: SSL certificate password storage?
From: Jakub Narebski @ 2011-09-24 17:51 UTC (permalink / raw)
To: James B; +Cc: git
In-Reply-To: <CAEsSSh2MDPgcFtrwYJ7uCDHBHPEfo35deE4dsWrb7Ukp7b310A@mail.gmail.com>
James B <coderer@gmail.com> writes:
> I'm accessing a Git repository over an HTTPS transport, where client
> certificates are required. My certificate requires a password to use,
> and Git prompts me for this every time I use it -- it's starting to
> get a little old. I've got Subversion set up to use Gnome-Keyring for
> credentials, so I only have to unlock that once per session. Is there
> something similar for Git? Is it planned? If not, is there a good
> place to make feature requests?
There is "credential helper" series:
* infrastructure and simple example implementations,
like in-memory cache by Jeff King
* credential helper for MacOS X keychain from Jay Soffian
* credential helper for KDE (KWallet) from Lukas Sandström
* simple credential helper for Windows by Erik Faye-Lund
In 'next' there is only sample implemetations (credentia-cache and
credential-store). Some of the rest you can find in 'pu', others only
on git mailing list.
Currently there are no credentials helper for GNOME. Perhaps you can
write one?
--
Jakub Narębski
^ permalink raw reply
* git svn clone issues with buddypress subversion repository
From: Anand Kumria @ 2011-09-24 16:50 UTC (permalink / raw)
To: git
In-Reply-To: <CAM1C4G=YbK5PF21UujxNRR0PX9xqQBSEvcB45Zxy1hwZuyuL8Q@mail.gmail.com>
Hi,
I'm trying:
% git svn clone -s http://svn.buddypress.org/trunk/ buddypress
Initialized empty Git repository in
/home/anand/Projects/wordpress/buddypress/.git/
Using higher level of URL: http://svn.buddypress.org/trunk =>
http://svn.buddypress.org
% git --version
git version 1.7.0.4
And at the end, git svn appears to successfull complete but nothing
has occurred. I'm successfully using 'git svn' against other
repositories with no problem, just wondering if anyone else has come
across this.
% find buddypress
buddypress
buddypress/.git
[omitted]
buddypress/.git/svn
buddypress/.git/svn/refs
buddypress/.git/svn/refs/remotes
buddypress/.git/svn/refs/remotes/git-svn
buddypress/.git/svn/refs/remotes/trunk
buddypress/.git/svn/refs/remotes/trunk/.rev_map.cdf35c40-ae34-48e0-9cc9-0c9da1808c22
buddypress/.git/svn/.metadata
% cat buddypress/.git/svn/.metadata
; This file is used internally by git-svn
; You should not have to edit it
[svn-remote "svn"]
reposRoot = http://svn.buddypress.org
uuid = cdf35c40-ae34-48e0-9cc9-0c9da1808c22
branches-maxRev = 5188
tags-maxRev = 5188
Thanks,
Anand
^ permalink raw reply
* Do we have a convenient way to refer to a specific commit in an already filtered rev-list?
From: Tzu-Jung Lee @ 2011-09-24 16:46 UTC (permalink / raw)
To: git
Hi Folks,
Do we have a convenient/symbolic way to refer to a specific commit of
an already filtered rev-list? For example, I'm interested in the
commits with some constraints:
git log somepath --author=someone
Without gui/tui tools, I have to frequently CUT & PASTE the commit-ID
for further manipulation (show, cherry-pick, ...), and possibly repeat
the parsing couple of times if I didn't save the output. I wonder if
we have a convenient way to refer to the discrete commits? like
HEAD~4, HEAD@{3} or something magic.
Thanks,
Roy
^ permalink raw reply
* [PATCH] send-email: auth plain/login fix
From: Zbigniew Jędrzejewski-Szmek @ 2011-09-24 15:49 UTC (permalink / raw)
To: gitster, joe, git; +Cc: Zbigniew Jędrzejewski-Szmek
In-Reply-To: <7vzkjn16n6.fsf@alter.siamese.dyndns.org>
git send-email was not authenticating properly when communicating over
TLS with a server supporting only AUTH PLAIN and AUTH LOGIN. This is
e.g. the standard server setup under debian with exim4 and probably
everywhere where system accounts are used.
The solution comes from this forum thread:
http://www.perlmonks.org/?node_id=904354
This patch is tested by sending it.
Before:
Net::SMTP>>> Net::SMTP(2.31)
Net::SMTP>>> Net::Cmd(2.29)
Net::SMTP>>> Exporter(5.64_01)
Net::SMTP>>> IO::Socket::INET(1.31)
Net::SMTP>>> IO::Socket(1.31)
Net::SMTP>>> IO::Handle(1.28)
...
Net::SMTP=GLOB(0x238f668)>>> STARTTLS
Net::SMTP=GLOB(0x238f668)<<< 220 2.0.0 Ready to start TLS
Net::SMTP::SSL=GLOB(0x238f668)>>> EHLO localhost.localdomain
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-yyy.yyy.yyy Hello xxx.xxx [xxx.xxx.xxx.xxx], pleased to meet you
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-PIPELINING
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-8BITMIME
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-SIZE 80000000
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-DSN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH=LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-AUTH LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x238f668)<<< 250-DELIVERBY
Net::SMTP::SSL=GLOB(0x238f668)<<< 250 HELP
Password:
Net::SMTP::SSL=GLOB(0x238f668)>>> AUTH
Net::SMTP::SSL=GLOB(0x238f668)<<< 501 5.5.2 AUTH mechanism must be specified
5.5.2 AUTH mechanism must be specified
After:
Net::SMTP=GLOB(0x1ac4a60)>>> STARTTLS
Net::SMTP=GLOB(0x1ac4a60)<<< 220 2.0.0 Ready to start TLS
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> EHLO localhost.localdomain
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-yyy.yyy.yyy Hello xxx.xxx [xxx.xxx.xxx.xxx], pleased to meet you
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-ENHANCEDSTATUSCODES
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-PIPELINING
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-8BITMIME
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-SIZE 80000000
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-DSN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-AUTH=LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-AUTH LOGIN PLAIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250-DELIVERBY
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 250 HELP
Password:
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> AUTH LOGIN
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 334 VXNlcm5hbWU6
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> emJ5c3plaw==
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 334 UGFzc3dvcmQ6
Net::SMTP::SSL=GLOB(0x1ac4a60)>>> dGVzdA==
Net::SMTP::SSL=GLOB(0x1ac4a60)<<< 535 5.7.0 authentication failed
5.7.0 authentication failed
The password is incorrect in this snippet, but the protocol works correctly.
---
git-send-email.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git git-send-email.perl git-send-email.perl
index 37dfbe7..100fbd9 100755
--- git-send-email.perl
+++ git-send-email.perl
@@ -27,6 +27,7 @@ use Term::ANSIColor;
use File::Temp qw/ tempdir tempfile /;
use File::Spec::Functions qw(catfile);
use Error qw(:try);
+use Authen::SASL qw(Perl);
use Git;
use MIME::Base64;
--
1.7.6
^ permalink raw reply
* [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-09-24 15:27 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, Vitor Antunes
In-Reply-To: <1316878065-11782-1-git-send-email-vitor.hda@gmail.com>
The drop command deletes the given branch reference, allowing
fast-import to actively ignore it in the final checks.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
fast-import.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 742e7da..906bbf4 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -743,6 +743,29 @@ static struct branch *new_branch(const char *name)
return b;
}
+static void release_tree_entry(struct tree_entry *e);
+static void drop_branch(const char *name)
+{
+ unsigned int hc = hc_str(name, strlen(name)) % branch_table_sz;
+ struct branch *b_prev = NULL, *b = NULL;
+ struct ref_lock *lock;
+ unsigned char old_sha1[20];
+
+ for (b = branch_table[hc]; b; b = b->table_next_branch) {
+ if (!strcmp(name, b->name)) {
+ release_tree_entry(&b->branch_tree);
+ if (b_prev)
+ b_prev->table_next_branch = b->table_next_branch;
+ branch_table[hc] = NULL;
+ branch_count--;
+ }
+ b_prev = b;
+ }
+
+ if (!read_ref(name, old_sha1))
+ delete_ref(name, old_sha1, 0)
+}
+
static unsigned int hc_entries(unsigned int cnt)
{
cnt = cnt & 7 ? (cnt / 8) + 1 : cnt / 8;
@@ -776,7 +799,6 @@ static struct tree_content *new_tree_content(unsigned int cnt)
return t;
}
-static void release_tree_entry(struct tree_entry *e);
static void release_tree_content(struct tree_content *t)
{
struct avail_tree_content *f = (struct avail_tree_content*)t;
@@ -2793,6 +2815,15 @@ static void parse_reset_branch(void)
unread_command_buf = 1;
}
+static void parse_drop_branch(void)
+{
+ char *sp;
+
+ /* Obtain the branch name from the rest of our command */
+ sp = strchr(command_buf.buf, ' ') + 1;
+ drop_branch(sp);
+}
+
static void cat_blob_write(const char *buf, unsigned long size)
{
if (write_in_full(cat_blob_fd, buf, size) != size)
@@ -3332,6 +3363,8 @@ int main(int argc, const char **argv)
parse_new_tag();
else if (!prefixcmp(command_buf.buf, "reset "))
parse_reset_branch();
+ else if (!prefixcmp(command_buf.buf, "drop "))
+ parse_drop_branch();
else if (!strcmp("checkpoint", command_buf.buf))
parse_checkpoint();
else if (!strcmp("done", command_buf.buf))
--
1.7.7.rc2.11.g4aecf.dirty
^ permalink raw reply related
* [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-09-24 15:27 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, Vitor Antunes
First try in implementing the drop command that was discussed in the
past. Please be gentle, as this is the first time I touch C in many
years. The git internals are also rather new to me.
No documentation and test cases were added at this point. It would be
great if someone could implement the test case for me.
Vitor Antunes (1):
fast-import: Add drop command
fast-import.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
--
1.7.7.rc2.11.g4aecf.dirty
^ permalink raw reply
* Re: Possible timestamp problems with diff-files?
From: Robin Rosenberg @ 2011-09-24 14:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Strapetz, Jeff King, git
In-Reply-To: <7vboud1sz5.fsf@alter.siamese.dyndns.org>
Junio C Hamano skrev 2011-09-21 23.33:
> Marc Strapetz<marc.strapetz@syntevo.com> writes:
>
>> On 20.09.2011 19:54, Jeff King wrote:
>>> On Tue, Sep 20, 2011 at 12:30:53PM +0200, Marc Strapetz wrote:
>>>
>>>> For our Git client, we are invoking
>>>>
>>>> git diff-files--quiet --ignore-submodules
>>>>
>>>> immediately after a commit of *all* changes. Hence, the expected exit
>>>> code would be 0 (because there are no changes). A user has now reported
>>>> that for commits with many changes, exit code is sometimes 1. For the
>>>> last incident, the commit was started at 15:24:11,820 and finished at
>>>> 15:24:12,329, diff-files was invoked at 15:24:12,455 and failed with
>>>> exit code 1 at 15:24:21,394. A subsequent diff-files succeeded, so I'm
>>>> wondering now, if that could be a timestamp problem (maybe related to
>>>> the Index)?
>
> What peff said already.
>
> If you do not refresh the cached stat information, diff-files may report
> "they differ" for a path that is otherwise unchanged without looking at
> the contents of such a path to notice that the only difference is the
> cached stat information (the whole and only point of having the cached
> stat information is to avoid looking at the contents). Also, it may look
> at the contents of such a path if it has a reason to suspect that the file
> might have changed if it cannot tell from the cached stat information
> (look for "racy-git" if you are really interested).
>
> Update the cached stat information before you use plumbing commands in
> your script.
Using git diff instead of git diff-files would do just that, unless I am
missing something.
-- robin
^ permalink raw reply
* Re: [PATCH 0/6] A handful of "branch description" patches
From: Michael J Gruber @ 2011-09-24 14:42 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20110923201824.GA27999@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 23.09.2011 22:18:
> On Fri, Sep 23, 2011 at 10:56:47AM +0200, Michael J Gruber wrote:
>
>> mjg/vob/refrev-pretend [mjg/vob/virtual-objects: ahead 1]
>> Pseudo revs for refnames
>>
>> An alternative implementation using pretend_sha1...
>> Currently unused.
>>
>> mjg/vob/virtual-objects [origin/next: ahead 2, behind 10]
>> Virtual refname objects
>>
>> For each existing refname, introduce virtual objects corresponding to a blob
>> with the refname as the content. "virtual" refers to the fact that these
>> objects are not written out but exist for all other purposes, such as
>> attaching notes and keeping them from being pruned.
>
> Eww. :)
>
> This seems like a clever solution to making git-notes store a ref as a
> key instead of an arbitrary sha1. But I wonder if the end result is
> really waht the user wants. The resulting notes tree is good for doing
> lookups, but the entries are completely obfuscated. So I can't easily do
> something like "list all of the refs which have descriptions". I can
> only list the _hashes_ of the refs which have descriptions. And if I am
> lucky, I can hash the refs I have and correlate them. But unknown ones
> will simply be a mystery.
[mjg@localhost git]$ git rev-parse ref:mjg/vob/virtual-objects
3f8aa9bb80fe241306aafd3d76af50739ba88268
[mjg@localhost git]$ git show 3f8aa9bb80fe241306aafd3d76af50739ba88268
refs/heads/mjg/vob/virtual-objects
:)
The only problem is with notes for non-existing refs. [You only have to
invoke the inverse mapping to sha1, of course... Uhm.]
> Wouldn't it be much more friendly to have a separate tree of refnames
> that stores:
>
> refs/heads/foo -> (some blob with the "foo" description)
> refs/heads/bar -> (some blob with the "bar" description)
Given the above, I don't think it's more friendly.
In fact, in my first attempt, I wrote out the blobs, and referenced them
just like above from a different subtree within the notes tree, in order
to keep them from being pruned. So the virtual approach is pretty
equivalent, though leaner.
> Yeah, you have to build another git-notes-like interface around it. But
> the data structure is pleasant and flexible. You could even "git
> checkout" the whole tree and edit the notes with your editor, without
> having to deal with some obfuscated name.
Well, "git branch --edit-description" and such should be the way to edit
them, shouldn't it?
I really think the only issue is remote refnames. As Junio points out,
they are local by nature. OTOH, you typically use a non-renaming refspec
which puts them under refs/remotes/foo/bar with "bar" being the same
name as the local one on the remote, foo something you have chosen. So,
teaching the code that the note for
refs/remotes/foo/bar
is in the notes tree
refs/remotes/foo/notes/commits (or .../refames, or whatever we do with
the namespaces)
as a note attached to sha1("refs/bar")
is really a non-issue. It's not done yet, in part because of the
possible namespace restructuring.
Michael
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-24 11:03 UTC (permalink / raw)
To: Jeff King
Cc: Jay Soffian, Junio C Hamano, git discussion list, Jakub Narebski
In-Reply-To: <20110924061555.GB13974@sigill.intra.peff.net>
On 09/24/2011 08:15 AM, Jeff King wrote:
> On Sat, Sep 24, 2011 at 08:05:29AM +0200, Michael Haggerty wrote:
>> This could be implemented by having a single local config option that
>> enables the use of an in-tree .gitconfig file:
>>
>> git config core.useTreeConfig true
>>
>> (or whatever the correct naming convention would be). This option would
>> default to false, so the in-tree config would only occur following an
>> affirmative decision by the cloner.
>
> But once you've verified that the config looks OK and turned this option
> on, how do you protect yourself from malicious config entering the repo
> through a fetch?
For most software projects, the user does
git pull
make
daily. There is nothing that a nasty .gitconfig can do that can't be
done more easily by a nasty Makefile (or anything else in the build
process). The moment I pull from Junio's repository and run a build
without having personally done a full code review first, I've given
Junio complete pownership of my account. For projects in which I invest
such trust, "core.useTreeConfig=true" would be a convenience that does
not appreciably increase my risk.
>> If finer granularity is required, config options could be classified
>> into "security-relevant" and "non-security-relevant" options, where the
>> former group basically includes anything that can cause arbitrary code
>> to be executed. Then there could be a "core.useTreeConfig = safeonly"
>> option to allow only the harmless options.
>
> This is the "can of worms" I referred to earlier. You have to start
> classifying each option.
It is not a "can of worms" in the sense of insoluble. It is only a lot
of work. We could start today by setting a default that all config
options are dangerous, incrementally opening up options as they are vetted.
>> I think the priority of config options (highest to lowest) should be
>>
>> $GIT_DIR/config
>> in-tree .gitconfig
>> ~/.gitconfig
>> $(prefix)/etc/gitconfig
>
> One catch with any precedence scheme is that there are certain config
> constructs that cannot be overridden.
Good point, and good suggestion to allow config constructs to be cleared.
>> Of course, just like for attributes, it would have to be decided which
>> version of the .gitconfig to use in which situations.
>
> I'm not sure it makes sense to have it in the tree at all. For
> attributes it makes sense, because you are annotating a path at a
> _specific_ revision. But config is often much more meta- than that.
> Take textconv for an example. The gitattributes say "foo.pdf should use
> the 'pdf' diff driver". That makes sense to go in a revision. But the
> config will say "pdf files can be converted to text using
> /usr/bin/pdftotext". That is not something that is tied to the revision
> at all, and should exist outside of any revision. I.e., whether I am
> doing a "git show" on the HEAD, or on some ancient commit, I would want
> to use the same value, not whatever tool I used to convert PDFs years
> ago.
There are obviously config options that should not be versioned. These
should not be stored in the tree. (Perhaps they should be stored in
another branch, as you suggested.) But there's no need to prevent
people from versioning *any* config options just because they shouldn't
version *all* of them.
I think that your "config-file includes" proposal would make all of this
possible or nearly possible, but I'll have to read your proposal more
carefully before I can comment.
While we are on the topic of config settings, I have often thought that
it would be nice for git's default settings to be set via a
well-commented config file, installed along with git, rather than via
values compiled into the code. This file and Documentation/config.txt
could be generated from a single source file as part of the build
process. Advantages:
1. It would give a single place for people to see exactly what defaults
are being applied, and a good starting point for seeing what can be
changed locally.
2. It would ensure that the defaults listed in the documentation always
match those being used, and prevent different default values from being
used in different places in the code.
3. It would make it easy to discover what default values have changed
between two git versions (i.e., what new knobs there are to turn).
4. It would make it easy for packagers to tweak the built-in defaults,
and would make it obvious what defaults packagers had changed. (Of
course packagers can already just include an /etc/gitconfig, but it
would be better to reserve that file for sitewide changes).
The priority would obviously be:
$GIT_DIR/config
in-tree .gitconfig
~/.gitconfig
$(prefix)/etc/gitconfig
git's installed defaults
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.6.4
From: Robin H. Johnson @ 2011-09-24 10:35 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <7vlitesucu.fsf@alter.siamese.dyndns.org>
On Fri, Sep 23, 2011 at 04:37:53PM -0700, Junio C Hamano wrote:
> The latest maintenance release Git 1.7.6.4 is available but not at the
> usual places.
>
> The release tarballs are found at:
>
> http://code.google.com/p/git-core/downloads/list
>
> and their SHA-1 checksums are:
>
> df91e2c32d6097ab1c9d0edc56dd8cecb4e9b686 git-1.7.6.4.tar.gz
> 6abd985e24b6585284cef7fae2e3046ba9201356 git-htmldocs-1.7.6.4.tar.gz
> c6f6d92f4005a7eccaf89e851c45768c18f7e65a git-manpages-1.7.6.4.tar.gz
Can you please upload the manpages and htmldocs tarballs to
code.google.com downloads? We use them in packaging on Gentoo for users
that want the docs without all of the documentation build chain.
(For 1.7.7.rc* too please).
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* Re: "git log --simplify-by-decoration" but including branch & merge points
From: Zbigniew Jędrzejewski-Szmek @ 2011-09-24 10:01 UTC (permalink / raw)
To: git; +Cc: David Röthlisberger
In-Reply-To: <EEB5CA46-D4FB-4B59-BDAF-36AE9BCC1D1E@rothlis.net>
See https://github.com/esc/git-big-picture. I think it's graphical only,
but might be a good starting point.
Best,
Zbyszek
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Ramkumar Ramachandra @ 2011-09-24 9:12 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Junio C Hamano, Francis Moreau, Michael J Gruber, git
In-Reply-To: <alpine.DEB.2.00.1109201254020.12564@debian>
Hi Martin,
Martin von Zweigbergk writes:
> I have started implementing the changes to git-am.sh now. I have made
> it not use mailinfo when in $rebasing mode, as you suggested. So now
> git-am works even if only a list of
>
> From $sha1 Mon Sep 17 00:00:00 2001
Ah, nice :)
> Now the question is how to generate such lines, without the overhead
> of a full format-patch call. We still want the --ignore-if-in-upstream
> functionality, so we can not use plain rev-list. We also want it to
> work with --root, so we can not use git-cherry. Finally, we can not
> use 'git rev-list --cherry-pick --right-only' since it seems to be
> inherently for symmetric ranges and therefore does not support
> git-cherry's <limit> parameter.
Using git-format-patch for anything except emailing patches to the
maintainer/ list is a mistake imo.
> I would go for teaching git-cherry --root, unless the "rev-list
> --cherry-pick for asymmetric ranges" option would be useful
> elsewhere. Either way, teaching git-cherry --root would not be a bad
> thing, I think.
Either this, or we have to write another wrapper around git-patch-id.
> [1] Long term, would it make sense to teach 'git cherry-pick' a '-2'
> option instead of using the '-3' option to 'git am'? (Where 'git
> cherry-pick -2' would try "apply && write-tree && commit-tree"
> before falling back to merging.)
Yeah, in the wake of scripts already doing "apply && write-tree &&
commit-tree" by hand, I think this proposal for git-cherry-pick makes
a lot of sense. I'm not sure if the option should be called '-2'
though.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH v2] Add command line option --chdir/-C to allow setting git process work directory.
From: kimi @ 2011-09-24 6:57 UTC (permalink / raw)
To: git
In-Reply-To: <4BBD811A-F750-43F5-A0F0-EBB186E54AEE@pasternacki.net>
I like http://www.monclershare.com/ <strong>Moncler</strong>
I like http://www.monclershare.com/ <strong>Buy Moncler</strong>
I like http://www.monclershare.com/ <strong>Moncler Online</strong>
I like http://www.monclershare.com/ <strong>Moncler Jackets</strong>
I like http://www.monclershare.com/ <strong>Discount Moncler
Jackets</strong>
--
View this message in context: http://git.661346.n2.nabble.com/PATCH-v2-Add-command-line-option-chdir-C-to-allow-setting-git-process-work-directory-tp1352126p6826652.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-24 6:15 UTC (permalink / raw)
To: Michael Haggerty
Cc: Jay Soffian, Junio C Hamano, git discussion list, Jakub Narebski
In-Reply-To: <4E7D7329.7070800@alum.mit.edu>
On Sat, Sep 24, 2011 at 08:05:29AM +0200, Michael Haggerty wrote:
> This could be implemented by having a single local config option that
> enables the use of an in-tree .gitconfig file:
>
> git config core.useTreeConfig true
>
> (or whatever the correct naming convention would be). This option would
> default to false, so the in-tree config would only occur following an
> affirmative decision by the cloner.
But once you've verified that the config looks OK and turned this option
on, how do you protect yourself from malicious config entering the repo
through a fetch?
> If finer granularity is required, config options could be classified
> into "security-relevant" and "non-security-relevant" options, where the
> former group basically includes anything that can cause arbitrary code
> to be executed. Then there could be a "core.useTreeConfig = safeonly"
> option to allow only the harmless options.
This is the "can of worms" I referred to earlier. You have to start
classifying each option.
> I think the priority of config options (highest to lowest) should be
>
> $GIT_DIR/config
> in-tree .gitconfig
> ~/.gitconfig
> $(prefix)/etc/gitconfig
One catch with any precedence scheme is that there are certain config
constructs that cannot be overridden. For example, some options are
respected multiple times to form a list (e.g., remote fetch and push
refspecs). There's no way in you $GIT_DIR/config to say "forget all of
the previous values you saw for this key" that may have come from the
in-tree .gitconfig.
I think you could introduce a special syntax for that, maybe just:
# make a list with two elements
[foo]
bar = one
bar = two
# now let's imagine this is our "reset" syntax
bar =
# and now we can put in our own new values
bar = three
where the final value of the config above would be (three).
It's actually not a new problem with in-tree config, and it doesn't tend
to come up all that much because most config values are treated as
simple scalars, and later values overwrite earlier ones.
> Of course, just like for attributes, it would have to be decided which
> version of the .gitconfig to use in which situations.
I'm not sure it makes sense to have it in the tree at all. For
attributes it makes sense, because you are annotating a path at a
_specific_ revision. But config is often much more meta- than that.
Take textconv for an example. The gitattributes say "foo.pdf should use
the 'pdf' diff driver". That makes sense to go in a revision. But the
config will say "pdf files can be converted to text using
/usr/bin/pdftotext". That is not something that is tied to the revision
at all, and should exist outside of any revision. I.e., whether I am
doing a "git show" on the HEAD, or on some ancient commit, I would want
to use the same value, not whatever tool I used to convert PDFs years
ago.
-Peff
^ permalink raw reply
* Re: Fwd: permission to re-license strbuf subsystem as LGPL
From: Jeff King @ 2011-09-24 6:05 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jakub Narebski, git
In-Reply-To: <CA+sFfMdt-95rfaZmiYAHx02Ukjt_WN-kLJr410AzZfGHYkSv5w@mail.gmail.com>
On Fri, Sep 23, 2011 at 05:50:27PM -0500, Brandon Casey wrote:
> Hmm, I forgot about bstring. I think strbuf is a little smaller in
> scope than bstring, perhaps less ambitious. Less abstraction, and
> less protection too. With strbuf, you never forget that you're
> dealing with C char arrays. The data structures are pretty similar,
> but I don't think strbuf will ever have a function like
>
> bconcat(bstring1, bstring2)
>
> instead, you'd just do
>
> strbuf_add(strbuf1, strbuf2.buf, strbuf2.len)
I think it's spelled:
strbuf_addbuf(strbuf1, strbuf2);
in the current code.
> The benefit, of course, of a bconcat function is that either bstring1
> or bstring2 can be NULL (like if a previous bstring2 = bfromcstr()
> initialization failed). This allows you to perform a sequence of
> bstring operations and only check errors at the end.
There is no error checking with strbufs at all. The only thing that can
fail is malloc, and in that case, we always die().
It wouldn't be too hard to make it return errors (or set a global error
flag), and have any failed mallocs just leave the strbuf unchanged.
Because strbufs are always in a consistent state, it would be safe to
do:
global_strbuf_error_flag = 0;
strbuf_addbuf(strbuf1, strbuf2);
strbuf_addbuf(strbuf3, strbuf1);
strbuf_addbuf(strbuf3, strbuf4);
if (global_strbuf_error_flag)
...
The contents of the strbufs would be indeterminant, but you would never
have violated any memory constraints.
-Peff
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-24 6:05 UTC (permalink / raw)
To: Jeff King
Cc: Jay Soffian, Junio C Hamano, git discussion list, Jakub Narebski
In-Reply-To: <20110923193341.GA26820@sigill.intra.peff.net>
On 09/23/2011 09:33 PM, Jeff King wrote:
> [1] I really wish we had an elegant way of versioning meta-information
> about a repository (like config, info/attributes, etc). I've hacked
> around this before by having a special meta-branch for each repo,
> checkout it out in an alternate directory, and then symlinking bits
> of it into .git. But that's kind of ugly, too.
>
> I'm not sure what a good solution would look like. There's a real
> can of worms with respect to picking and choosing local versus
> remote bits of meta-information, with some security implications.
This could be implemented by having a single local config option that
enables the use of an in-tree .gitconfig file:
git config core.useTreeConfig true
(or whatever the correct naming convention would be). This option would
default to false, so the in-tree config would only occur following an
affirmative decision by the cloner.
If finer granularity is required, config options could be classified
into "security-relevant" and "non-security-relevant" options, where the
former group basically includes anything that can cause arbitrary code
to be executed. Then there could be a "core.useTreeConfig = safeonly"
option to allow only the harmless options.
I think the priority of config options (highest to lowest) should be
$GIT_DIR/config
in-tree .gitconfig
~/.gitconfig
$(prefix)/etc/gitconfig
Of course, just like for attributes, it would have to be decided which
version of the .gitconfig to use in which situations.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.6.4
From: Junio C Hamano @ 2011-09-24 3:50 UTC (permalink / raw)
To: BJ Hargrave; +Cc: git, Michael Haggerty
In-Reply-To: <4850EB43-5CC7-4D33-90A8-1EDEE16ECAB7@bjhargrave.com>
BJ Hargrave <bj@bjhargrave.com> writes:
> The test
>
> invalid_ref "$(printf 'heads/foo\177')"
>
> was added to t1402-check-ref-format.sh. However sh on my RHEL 4 system
> does not handle the DEL (\177) character well in double quoted strings.
>
> sh-3.00$ echo $(printf 'hello\177') | hexdump -C
> 00000000 68 65 6c 6c 6f 7f 0a |hello..|
> 00000007
> sh-3.00$ echo "$(printf 'hello\177')" | hexdump -C
> 00000000 68 65 6c 6c 6f 0a |hello.|
> 00000006
>
> The double quotes cause the DEL (\177) character to be discarded.
>
> Can this test be rewritten to avoid this apparent bug in sh on RHEL 4?
For older distros, I would prefer a workaround patch first tested by
distro packaging people and then upstreamed.
Thanks.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.6.4
From: BJ Hargrave @ 2011-09-24 3:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael Haggerty
In-Reply-To: <7vlitesucu.fsf@alter.siamese.dyndns.org>
On Sep 23, 2011, at 19:37 , Junio C Hamano wrote:
> * "git check-ref-format --print" used to parrot a candidate string that
> began with a slash (e.g. /refs/heads/master) without stripping it, to make
> the result a suitably normalized string the caller can append to "$GIT_DIR/".
When building 1.7.6.4 on my RHEL 4 system, it failed t1402-check-ref-format.sh:
not ok - 19 ref name 'heads/foo' is not valid
I bisected and found that commit f3738c1ce9193a4bf45ba1a3ea67d0cf32da0257 introduced the issue.
The test
invalid_ref "$(printf 'heads/foo\177')"
was added to t1402-check-ref-format.sh. However sh on my RHEL 4 system does not handle the DEL (\177) character well in double quoted strings.
sh-3.00$ echo $(printf 'hello\177') | hexdump -C
00000000 68 65 6c 6c 6f 7f 0a |hello..|
00000007
sh-3.00$ echo "$(printf 'hello\177')" | hexdump -C
00000000 68 65 6c 6c 6f 0a |hello.|
00000006
The double quotes cause the DEL (\177) character to be discarded.
Can this test be rewritten to avoid this apparent bug in sh on RHEL 4?
--
BJ Hargrave
^ permalink raw reply
* Re: deleting non-existent ref via push
From: Sitaram Chamarty @ 2011-09-24 3:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vmxdvunto.fsf@alter.siamese.dyndns.org>
On Fri, Sep 23, 2011 at 11:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> Pushing to delete a non-existent ref (git push origin :refs/heads/foo)
>> works without error, except for a warning that the remote is "Allowing
>> deletion of corrupt ref". By "works" I mean all hooks are also
>> executed.
>>
>> Is this expected/supported behaviour? Can I rely on it continuing to
>> work, especially in terms of executing hooks.
>
> This most definitely is just "we didn't bother checking the error too
> carefully, especially because the result of deleting something that did
> not exist in the first place is a no-op; anybody who tries to delete a
> non-existing thing is a moron and deserves whatever random result he
I'd better hide behind the fact that I am only doing it for the
side-effect then ;-)
> gets".
>
> It would be a good idea to tighten it.
Thanks. I just needed to know if I could rely on it long-term or not.
I'll find some other way to "poke" a remote repo to run the hooks.
^ 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