* Re: Bug: git log --numstat counts wrong
From: Junio C Hamano @ 2011-09-23 19:23 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Alexander Pepper, git
In-Reply-To: <CALUzUxoujys1eWL6i6YJmFZZakcQx8oa8ZbRjixUzANB1Hpb3Q@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On further thought, I think the patch merely side-steps the problem -
> ie. that -U0 generates "incorrect" diffs.
I do not know if there anything "incorrect" about it.
When the file have common blocks lines in different places that are not
modified, the comparison between preimage and postimage is free to choose
how these common blocks are matched, and for that reason it is incorrect
to expect that "diff -U0", "diff -U3" and "diff -U20" would produce the
identical results.
> I think this function is incorrect. xdl_cleanup_records() and
> xdl_clean_mmatch() may potentially look into common tail lines, so it
> may not be "safe" to drop all common tail lines.
I would prefer to keep that common trimming optimization, and also to see
the same common trimming logic extended to trim (and adjust offsets) at
the beginning as well in the longer term. If xdl_cleanup_records() and
xdl_clean_mmatch() need to become aware of the change in the total number
of lines made by trim_common_tail(), please make it so.
>
> -- >8 --
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 0e2c169..da4fab6 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -131,7 +131,7 @@
> mmfile_t a = *mf1;
> mmfile_t b = *mf2;
>
> - trim_common_tail(&a, &b, xecfg->ctxlen);
> +/* trim_common_tail(&a, &b, xecfg->ctxlen); */
>
> return xdl_diff(&a, &b, xpp, xecfg, xecb);
> }
> -- >8 --
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #06; Wed, 21)
From: Junio C Hamano @ 2011-09-23 19:29 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <7vvcsjuojp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Scott Chacon <schacon@gmail.com> writes:
>
>> It appears that you're no longer pushing the 'html' branch to the
>> GitHub repo,...
>
> It is not even "no longer".
It just occurred to me that https://github.com/git/git repository might be
the one you are talking about, but that repository is not even mine. The
page at https://github.com/git says git@logicalawesome.com is its contact
person.
I _suspect_ it is set up to mirror from my k.org repository and obviously
nothing is updated from that route for the past few weeks. It is correct
to say "html branch in that repository is no longer updated", but I cannot
do anything about that repository ;-).
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-23 19:33 UTC (permalink / raw)
To: Michael Haggerty
Cc: Jay Soffian, Junio C Hamano, git discussion list, Jakub Narebski
In-Reply-To: <4E7C5A3B.10703@alum.mit.edu>
On Fri, Sep 23, 2011 at 12:06:51PM +0200, Michael Haggerty wrote:
> This is a very dangerous line of thought. When content is read out of a
> historical commit, the content must be identical to what was checked
> into that commit. For example, the EOL characters that I see in an old
> file revision must not depend on my current HEAD or index. This rule
> should apply regardless of whether the content is being read to be
> checked out, put into an archive, or diffed against some other revision.
> So for these purposes, I think there is no choice but to honor the
> gitattributes files in the tree/index/directory from which the content
> was read.
>
> If the user really wants to say "this is what this file is like
> throughout history" (thereby altering history), then this should be a
> local decision that should be stored locally in $GIT_DIR/info/attributes.
I think we're in agreement here that this is the right way to do things.
My points are that:
1. The current behavior is often convenient, even though it is wrong
in some cases. Using $GIT_DIR/info/attributes is manual and
annoying[1]. Turning on .gitattributes in the working tree and
having it impact "git log -p" on older commits is a huge
convenience. When it's right.
2. This isn't how we're doing it now, and I don't see a lot of bug
reports. That doesn't mean there isn't room for improvement, but
it may mean the current strategy is good enough, especially if the
alternative ends up being very complex or hard to understand.
My biggest fear is not that we are wrong in some minority of the cases,
but that there is no good way to tell git it's wrong and to do something
else.
[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.
> There are other attributes that affect "two-argument" operations like
> diff. Here the policy has to depend on the situation. In the case of
> diff, I suggest that the relevant attributes be read from *both*
> versions of the file. If they are the same, then obviously use them.
> If they differ, then fall back to a "safe" default (for example, the
> diff that would be used if *no* attributes had been specified).
> However, as a special case, if an attribute is specified in one version
> and unspecified in another, it would *usually* be OK to use the
> specified version of the attributes and that might be considered a
> reasonable alternative.
Those are sane ground rules. But specific contexts would want to be
smarter in some cases. For example, if you have two conflicting diff
attributes that both define a textconv, you would not want to fallback
to not doing any textconv (which is what your above text prescribes).
Instead, you want to textconv each side individually according to its
attributes, and then compare the result.
One could argue that textconv is therefore not a "two-argument"
operation, since it works on each side individually. But it is part of
the "diff" attribute, and so it ends up being processed in a
two-argument context (this is possibly a mistake in the original design
of textconv).
> By the way, it is possible that the two ends of a diff operation have
> different filenames (e.g., with -M or -C). In this case the attributes
> should be looked up using the filename corresponding to the commit.
We do some of this already. For example, textconv will look up each side
based on its individual filename. But the funcname code, for example
does this ("one" is the "from" side of the diff, "two" is the "to"
side):
pe = diff_funcname_pattern(one);
if (!pe)
pe = diff_funcname_pattern(two);
whereas I think your proposed code would do:
pe1 = diff_funcname_pattern(one);
pe2 = diff_funcname_pattern(two);
if (!pe1)
pe = pe2; /* only one side, or both empty */
else if (!pe2)
pe = pe1; /* only one side */
else if (!pattern_cmp(pe1, pe2))
pe = pe1; /* identical, pick one */
else
pe = NULL; /* conflict, default to nothing */
> > So if the status quo with working trees (i.e., retroactively applying
> > the current gitattributes to past commits) is good enough, perhaps the
> > bare-repository solution should be modeled the same way? In other words,
> > should "git log -p" in a bare repo be looking for attributes not in the
> > commits being diffed, but rather in HEAD[2]?
>
> This would be a very poor policy, modeled on a status quo that is
> *not* good enough. For example, HEAD might not even be a descendant
> of the commit whose content is being interrogated; the commit might
> have new files and new gitattributes that would be ignored.
Notice the "if" in my statement. :)
Yes, that is a corner case that is utterly broken. It's also utterly
broken in the current code with a non-bare repository, where we respect
the checked-out .gitattributes (which generally come from HEAD). This
would just be a very simple way of harmonizing bare repositories with
the current non-bare behavior (broken or not).
> I suppose your suggestion is better than the status quo, so it would
> be fine as a starting point, *provided* it is clear that people should
> not rely on this behavior not being improved later.
Sure. If we go down this road, we will be breaking the non-bare case,
too, so we will have to deal with deprecations and all that, anyway.
-Peff
^ permalink raw reply
* [BUG] git-p4 can't cope with dollars in filenames
From: Luke Diamand @ 2011-09-23 19:38 UTC (permalink / raw)
To: Git List; +Cc: Pete Wyckoff
Hi!
If you have a dollar in a filename and attempt to submit it to Perforce
via git-p4 it fails.
e.g. this sequence:
% touch foo\$bar.c
% git commit -m 'whatever' foo\$bar.c
% git-p4 submit
....
....
Submit aborted -- fix problems then use 'p4 submit -c 3'.
The problem is all the places that use the git-p4 read_pipe() function,
which is a wrapper around os.popen(). popen() does shell expansion which
does hilarious things to files with dollars in their name.
You can have hours of fun and entertainment with this. Adding a file
called foo\`fortune\`.h is especially amusing.
I'm going to try to come up with a fix for this.
Luke
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Junio C Hamano @ 2011-09-23 19:40 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Jay Soffian, git discussion list,
Jakub Narebski
In-Reply-To: <20110923193341.GA26820@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We do some of this already. For example, textconv will look up each side
> based on its individual filename. But the funcname code, for example
> does this ("one" is the "from" side of the diff, "two" is the "to"
> side):
>
> pe = diff_funcname_pattern(one);
> if (!pe)
> pe = diff_funcname_pattern(two);
What text would we see on the actual hunk header line? I had an impression
that we always take from the preimage. I might be wrong, but if that is
indeed the case, shouldn't we be ignoring the attribute tacked on to the
postimage side altogether?
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-23 19:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, Jay Soffian, git discussion list,
Jakub Narebski
In-Reply-To: <7vobybt5bw.fsf@alter.siamese.dyndns.org>
On Fri, Sep 23, 2011 at 12:40:51PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > We do some of this already. For example, textconv will look up each side
> > based on its individual filename. But the funcname code, for example
> > does this ("one" is the "from" side of the diff, "two" is the "to"
> > side):
> >
> > pe = diff_funcname_pattern(one);
> > if (!pe)
> > pe = diff_funcname_pattern(two);
>
> What text would we see on the actual hunk header line? I had an impression
> that we always take from the preimage. I might be wrong, but if that is
> indeed the case, shouldn't we be ignoring the attribute tacked on to the
> postimage side altogether?
Sort of. I think this is Michael's fallback case of "if there was no
attribute before, use the other side". In other words, we are guessing
if there was no attribute before, and there is one now, the reason is
not because they are two different formats but rather because the
attribute simply hadn't been added yet on the other side.
So if you have three commits, and the second one adds the attribute, you
can diff commits 1 and 3 in either direction, and still get the benefit
of the attribute.
Like reading .gitattributes from the current directory to look at old
(or even unrelated) commits, I think this is a convenience and is right
in most cases, but can be spectacularly wrong in some corner cases.
-Peff
^ permalink raw reply
* config-file includes
From: Jeff King @ 2011-09-23 19:58 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty, Jay Soffian, Junio C Hamano, Jakub Narebski
On Fri, Sep 23, 2011 at 03:33:41PM -0400, 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.
Here's one solution I've given a little thought to. Comments welcome.
I've sometimes wanted an "include" mechanism in git config files.
Partially to just keep things tidier, partially to avoid
cutting-and-pasting between some repo-specific config, and partially
because I'd like a conditional inclusion mechanism[1]. I was thinking of
something that would be syntactically compatible but semantically
meaningless in current versions of git, like:
[include]
path = /some/file
path = /some/other/file
path = ~/some/file/in/your/homedir
You could extend this to look in refs, with something like:
[include]
ref = meta:config
which would resolve meta:config to a blob and examine it (i.e., it would
look at refs/heads/meta).
So the procedure for importing and updating config from a remote would
look like:
git clone project.git
cd project
# check that the upstream config looks good
git show origin/meta:config
# if so, use it
git branch meta origin/meta
git config --add include.ref meta:config
# later, check updates to upstream's config
git fetch
git diff meta origin/meta -- config
# looks ok, use it
git branch -f meta origin/meta
And obviously if you wanted to streamline that, you could make "meta"
and "config" well-known names and have clone and fetch interactively
show the config and say "do you want this [y/N]?" or something. Though I
think there is some value to doing it manually, as it gives projects the
flexibility to have different config profiles in their meta branch.
And if you really wanted to live dangerously, you could do:
git config --add include.ref origin/meta:config
That of course just covers "config". But I think you might be able to do
something similar with core.attributesfile (which could be included from
the config).
-Peff
[1] I want conditional inclusion because sometimes the rules for config
entries changes from version to version. For example, I have
pager.diff set to a script in my ~/.gitconfig. But older versions of
git don't understand non-boolean values and barf. I'd really like to
do something like:
[include-ifdef "has-pager-scripts"]
path = ~/.gitconfig-pager
where "has-pager-scripts" would be a magic flag compiled into git
versions that understand that config.
^ permalink raw reply
* Re: [PATCH 0/6] A handful of "branch description" patches
From: Jeff King @ 2011-09-23 20:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4E7C49CF.60508@drmicha.warpmail.net>
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.
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)
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.
-Peff
^ permalink raw reply
* Re: [PATCH 0/6] A handful of "branch description" patches
From: Junio C Hamano @ 2011-09-23 20:52 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20110923201824.GA27999@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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.
A more fundamental issue I have with this is that names of the refs are
local by nature (what I call "master" branch is not "master" to you, but
rather it is "origin/master" or "jch/master") while notes is meant to be
the mechanism to share. The following shares the same issue, but at least
it does not abuse "notes", so in that sense it may be cleaner at the
design level...
> 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)
>
> 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.
^ permalink raw reply
* Re: [PATCH 0/6] A handful of "branch description" patches
From: Jeff King @ 2011-09-23 20:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git
In-Reply-To: <7vk48zt211.fsf@alter.siamese.dyndns.org>
On Fri, Sep 23, 2011 at 01:52:10PM -0700, Junio C Hamano wrote:
> A more fundamental issue I have with this is that names of the refs are
> local by nature (what I call "master" branch is not "master" to you, but
> rather it is "origin/master" or "jch/master") while notes is meant to be
> the mechanism to share. The following shares the same issue, but at least
> it does not abuse "notes", so in that sense it may be cleaner at the
> design level...
Good point. For that reason, your config-based solution perhaps makes
more sense.
-Peff
^ permalink raw reply
* "git log --simplify-by-decoration" but including branch & merge points
From: David Röthlisberger @ 2011-09-23 21:20 UTC (permalink / raw)
To: git
Hi,
I'd like something like "git log --simplify-by-decoration" that also includes the commit that a branch was branched *from*. I find this useful to understanding the relationships between branches.
For example, for the following repository with 2 branches "master" and "branch":
git log --graph --all --pretty="format:%d %s"
* (branch) b
* a
| * (master) 4
| * 3
|/
* 2
* 1
I would like a way to hide commits "a" and "3" (like --simplify-by-decoration) but to *include* commit "2" (unlike --simplify-by-decoration) because it shows me the crucial information of *when* "branch" and "master" started to diverge. Ideally I would also like to see merge commits.
In summary:
* Show any commit referred to by some branch or tag (as with --simplify-by-decoration),
* or with more than one parent (merges),
* or with more than one child, as long as at least 2 children are reachable from the commits you've specified (this is to include branch-points of any branches you are interested in, but to exclude branches you don't care about. It's probably impossible to get this criteria absolutely perfect, but better to include some additional commits than to exclude ones I want to see).
I don't think this is currently possible. What would be the best way to achieve it? Maybe a new flag to git-log, to be used together with --simplify-by-decoration? I am willing to work on a patch for this if people agree that it would be useful and likely to be accepted.
In general, when providing several commit-limiting and history-simplification parameters to git-log, should they be ANDed or ORed together? For example "git log --merges --simplify-by-decoration" doesn't seem to provide any useful output; would it makes sense to change this to mean "show anything that simplify-by-decoration would show, but also show merge commits"?
Thanks,
David Röthlisberger.
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Jay Soffian @ 2011-09-23 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Michael Haggerty
In-Reply-To: <7vobybw6mv.fsf@alter.siamese.dyndns.org>
On Fri, Sep 23, 2011 at 12:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If you want to allow use of in-tree attributes in _all_ callers of
> diff_tree_sha1(), then the right approach is to add an instance of "struct
> index_state" to "struct diff_options", have the caller _explicitly_ ask
> for use of in-tree attributes by setting a bit somewhere in "struct
> diff_options", and read the tree into that separate index_state using
> tree.c::read_tree(). I however doubt it is worth it.
>
> I would think it makes more sense to add a codeblock like that at the
> beginning of builtin/diff.c::builtin_diff_tree() when a new command option
> asks for it. In that codepath, you _know_ that we are not using the index
> at all, and reading the index there will not interfere with other uses of
> the index in the program.
Hmm, I looked at that, but then it would work for git-diff, but not
git-diff-tree. I don't think there's any other diff options that work
only at the porcelain layer, are there?
j.
^ permalink raw reply
* Re: [PATCH 2/2] diff_index: honor in-index, not working-tree, .gitattributes
From: Junio C Hamano @ 2011-09-23 21:48 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git, Jeff King, Michael Haggerty
In-Reply-To: <CAG+J_DwGuR6bqE4iG26-xwc0_TuRRKUDmmJZ44Qr+y5EEzTnNA@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Hmm, I looked at that, but then it would work for git-diff, but not
> git-diff-tree.
Why not?
The same helper function that you would write for calling from
builtin_diff_tree() would certainly be usable in git-diff-tree, no?
^ permalink raw reply
* [PATCH] credential-cache: don't cache items without context
From: Jeff King @ 2011-09-23 21:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The credential helper should get a --unique=<whatever>
context from the callers. It would be meaningless to cache
a username and password combination without being given any
context, since we have no idea when we should use them
again. The current code will reuse them next time we have no
context again, but that is probably not sane; there is no
guarantee that it is the same "lack of context" situation.
Git doesn't currently actually make requests of credential
helpers without a context, so this is a non-issue outside of
specialized testing. But it should do the sane thing given
any input, and it's nice to set a good example for other
helpers (which may not be tied to a specific git version,
and so arguments like "git doesn't currently do this" don't
apply to them).
Signed-off-by: Jeff King <peff@peff.net>
---
On top of jk/http-auth-keyring, naturally.
credential-cache.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/credential-cache.c b/credential-cache.c
index f495043..14d751e 100644
--- a/credential-cache.c
+++ b/credential-cache.c
@@ -155,9 +155,11 @@ int main(int argc, const char **argv)
printf("username=%s\n", c.username);
printf("password=%s\n", c.password);
- if (do_cache(socket_path, "store", &c, timeout) < 0) {
- spawn_daemon(socket_path);
- do_cache(socket_path, "store", &c, timeout);
+ if (c.unique) {
+ if (do_cache(socket_path, "store", &c, timeout) < 0) {
+ spawn_daemon(socket_path);
+ do_cache(socket_path, "store", &c, timeout);
+ }
}
return 0;
}
--
1.7.7.rc2.4.ga9aee2.dirty
^ permalink raw reply related
* credential helper tests
From: Jeff King @ 2011-09-23 22:15 UTC (permalink / raw)
To: git
Cc: Lukas Sandström, Jay Soffian, John Szakmeister,
Erik Faye-Lund, Ted Zlatanov
Since we've had a few credential helpers posted to the list recently, I
really want to try them all out. This can be a little bit tricky for
automated testing, though, for two reasons:
- they run on lots of platforms with lots of dependencies
- they interact with parts of the systems that are opaque to git. So
we can't make a test that reliably simulates "and then the user
types 'foo' into a dialog box" across all platforms.
Instead, I came up with a separate test script that is intended to be
run interactively with the user. It runs the helpers through a battery
of tests, and tells the user what to expect and what to input to any
dialogs or prompts.
I've run it already on the helpers I've written. I plan on running it
with the helpers that have been posted, as well. But I also wanted to
make it public so that authors could use it as a development aid.
It's not integrated with git's tests at all. In theory it could be part
of t/, but disabled unless the user asks for it. However, I'm not sure
that makes much sense. It's intended to test helpers that aren't
necessarily even shipped with git, and wouldn't necessarily even need
git to run.
Also, it is by no means a strict set of tests. A helper that did not
store credentials, but only presented dialogs in a different way, or one
that was about accessing a read-only store of credentials would not
pass. So think of it as a best-practices guide and an exercise script
for certain types of helpers, not necessarily as a set of tests that
must be passed.
-- >8 --
#!/bin/sh
# e.g., "cache"
helper=$1
say() {
echo >&2 "==> $*"
}
check() {
for i in username password; do
v=$1; shift
case "$v" in
auto:*)
v=${v#auto:}
say " $i should be automatic ($v)"
;;
*)
say " Input $i=$v"
;;
esac
echo $i=$v
done >expect
if git credential-$helper "$@" >actual &&
git --no-pager diff --no-index expect actual; then
say OK
else
say FAIL
fi
}
reject() {
git credential-$helper --reject "$@" || exit 1
}
say 'Cleaning old invocations...'
reject --unique=https:foo.tld
reject --unique=https:bar.tld
say 'No context (initial, should ask)'
check user pass
say 'No context (again, should ask)'
check user2 pass2
say 'Context foo.tld (initial, should ask)'
check foo-user foo-pass --unique=https:foo.tld
say 'Context foo.tld (again)'
check auto:foo-user auto:foo-pass --unique=https:foo.tld
say 'Context bar.tld (should ask)'
check bar-user bar-pass --unique=https:bar.tld
say 'Context bar.tld (again)'
check auto:bar-user auto:bar-pass --unique=https:bar.tld
say 'Context foo.tld (should still remember)'
check auto:foo-user auto:foo-pass --unique=https:foo.tld
say 'Forget foo.tld (should ask)'
reject --unique=https:foo.tld
check foo-user2 foo-pass2 --unique=https:foo.tld
say 'Context foo.tld (again)'
check auto:foo-user2 auto:foo-pass2 --unique=https:foo.tld
say 'Context bar.tld (should still remember)'
check auto:bar-user auto:bar-pass --unique=https:bar.tld
say 'Alternate user at foo.tld (should ask)'
check auto:foo-user3 foo-pass3 --unique=https:foo.tld --username=foo-user3
say 'Remember new user'
check auto:foo-user3 auto:foo-pass3 --unique=https:foo.tld --username=foo-user3
say 'Remember old user'
check auto:foo-user2 auto:foo-pass2 --unique=https:foo.tld --username=foo-user2
say 'Forget new user (should ask)'
reject --unique=https:foo.tld --username=foo-user3
check auto:foo-user3 foo-pass4 --unique=https:foo.tld --username=foo-user3
say 'New user is now remembered'
check auto:foo-user3 auto:foo-pass4 --unique=https:foo.tld --username=foo-user3
say 'Remember old user'
check auto:foo-user2 auto:foo-pass2 --unique=https:foo.tld --username=foo-user2
^ permalink raw reply
* Re: Fwd: permission to re-license strbuf subsystem as LGPL
From: Jonathan Nieder @ 2011-09-23 22:16 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <CA+sFfMcmsKkKM7C0g4vKmjmCCNqRHuvz-hwEHAm=+stqnOPpAw@mail.gmail.com>
Brandon Casey wrote:
> Jonathan Nieder suggested using a more permissive license than LGPL.
> BSD seems to have the most support. If the remaining contributors
> agree, then I'm fine with licensing under BSD.
A few words of clarification. My opinion shouldn't matter much here
--- I am more of a bystander and user than a contributor to strbuf. :)
The main reason I suggested a permissive license is that the strbuf
lib contains some inline functions and I do not want it to be
complicated to use them. To comply with the LGPL, in addition to
releasing any changes made to the library, distributors usually do one
of a few things:
a. offer the source code for your work that uses the library in
addition to any binaries,
b. use dynamic linking, or
c. provide object files for your work that uses the library, so it
can be re-linked against a modified version of the library.
(b) and (c) don't handle inline functions. Luckily, there is a way out:
d. only use the inline functions from within a subset of your work
for which you are willing to provide source. Dynamically link to
it or provide object files to allow re-linking.
With that in mind, I have nothing against the use of the LGPL here
(and one of the two main authors of the strbuf lib explained a good
reason to prefer it over the BSD license). The inline functions in
the strbuf lib are pretty small, so the above was probably not too
important in the first place.
Thanks, and sorry for the unnecessary noise.
Regards,
Jonathan
^ permalink raw reply
* Re: credential helper tests
From: Junio C Hamano @ 2011-09-23 22:26 UTC (permalink / raw)
To: Jeff King
Cc: git, Lukas Sandström, Jay Soffian, John Szakmeister,
Erik Faye-Lund, Ted Zlatanov
In-Reply-To: <20110923221513.GA3087@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Since we've had a few credential helpers posted to the list recently, I
> really want to try them all out. This can be a little bit tricky for
> automated testing, though, for two reasons:
>
> - they run on lots of platforms with lots of dependencies
>
> - they interact with parts of the systems that are opaque to git. So
> we can't make a test that reliably simulates "and then the user
> types 'foo' into a dialog box" across all platforms.
>
> Instead, I came up with a separate test script that is intended to be
> run interactively with the user. It runs the helpers through a battery
> of tests, and tells the user what to expect and what to input to any
> dialogs or prompts.
>
> I've run it already on the helpers I've written. I plan on running it
> with the helpers that have been posted, as well. But I also wanted to
> make it public so that authors could use it as a development aid.
>
> It's not integrated with git's tests at all. In theory it could be part
> of t/, but disabled unless the user asks for it. However, I'm not sure
> that makes much sense. It's intended to test helpers that aren't
> necessarily even shipped with git, and wouldn't necessarily even need
> git to run.
Perhaps throw it in somewhere under contrib/ hierarchy?
^ permalink raw reply
* [PATCH] merge-recursive: Do not look at working tree during a virtual ancestor merge
From: Junio C Hamano @ 2011-09-23 22:29 UTC (permalink / raw)
To: git; +Cc: Elijah Newren
Fix another instance of a recursive merge incorrectly paying attention to
the working tree file during a virtual ancestor merge, that resulted in
spurious and useless "addinfo_cache failed" error message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* The regression this fixes was seen while I was preparing a merge of
maint (soon to become 1.7.6.4) back to master (I cannot write "soon to
become 1.7.7" because I want to cook the fix at least for a few days)
today.
merge-recursive.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 6bbc451..3efc04e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1627,7 +1627,7 @@ static int merge_content(struct merge_options *o,
path_renamed_outside_HEAD = !path2 || !strcmp(path, path2);
if (!path_renamed_outside_HEAD) {
add_cacheinfo(mfi.mode, mfi.sha, path,
- 0 /*stage*/, 1 /*refresh*/, 0 /*options*/);
+ 0, (!o->call_depth), 0);
return mfi.clean;
}
} else
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* SSL certificate password storage?
From: James B @ 2011-09-23 22:41 UTC (permalink / raw)
To: git
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?
R/
James
^ permalink raw reply
* Re: Fwd: permission to re-license strbuf subsystem as LGPL
From: Brandon Casey @ 2011-09-23 22:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3mxdvqj31.fsf@localhost.localdomain>
2011/9/23 Jakub Narebski <jnareb@gmail.com>:
> Brandon Casey <drafnel@gmail.com> writes:
>
>> ---------- Forwarded message ----------
>> From: Brandon Casey <drafnel@gmail.com>
>> Date: Thu, Sep 22, 2011 at 11:21 PM
>> Subject: permission to re-license strbuf subsystem as LGPL
>>
>> To those who have contributed to git's strbuf subsystem,
>>
>> I'd like to turn git's strbufs into a library. So with your consent
>> I'd like to re-license the code in strbuf.c and strbuf.h, and any
>> compat/ dependencies as LGPL so that I can create a strbuf library.
>
> That's a laudable goal. Do you plan on librarizing other universal
> mini-libraries, like parseopt or test-lib?
Not at the moment.
> I wonder if for example "perf" tool in Linux kernel sources (userspace
> companion to perf events subsystem) will move to using it; currently
> it reuses some of internal git minilibraries, IIRC strbuf and parseopt
> included.
I would be pleased if it was useful to them.
> By the way, how the 'strbuf' from git (which I think was created among
> others to avoid additional external dependencies) differs from
> existing C (not C++) string libraries, like 'bstring'[1], The Better
> String Library, or the C libraries in http://bstring.sourceforge.net/features.html?
>
> [1]: http://bstring.sourceforge.net
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)
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.
-Brandon
^ permalink raw reply
* What's cooking in git.git (Sep 2011, #07; Fri, 23)
From: Junio C Hamano @ 2011-09-23 23:33 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
We are at 1.7.7-rc3 as of today; I had to make a quick fix for a recent
regression directly on master, and I would like to cook it for a few days,
so the final has to wait til mid next week.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo, html and man:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
With only maint, master, html and man:
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
url = https://github.com/gitster/git
Until kernel.org comes back to life, it might be a good idea to
tentatively have the following in your $HOME/.gitconfig:
[url "http://code.google.com/p/git-core"]
insteadOf = git://git.kernel.org/pub/scm/git/git.git
--------------------------------------------------
[New Topics]
* jc/maint-diffstat-numstat-context (2011-09-22) 1 commit
- diff: teach --stat/--numstat to honor -U$num
* nd/maint-sparse-errors (2011-09-22) 2 commits
- Add explanation why we do not allow to sparse checkout to empty working tree
- sparse checkout: show error messages when worktree shaping fails
* rs/diff-cleanup-records-fix (2011-09-22) 1 commit
- Revert a part of rc/diff-cleanup-records
It seems that the differences (the reverse of) this patch introduces are
of harmless kind but not very well explained in the original series. We
would need to try harder to write our log messages better next time.
* di/fast-import-empty-tag-note-fix (2011-09-22) 2 commits
- fast-import: don't allow to note on empty branch
- fast-import: don't allow to tag empty branch
* js/check-attr-cached (2011-09-22) 2 commits
- t0003: remove extra whitespaces
- Teach '--cached' option to check-attr
--------------------------------------------------
[Stalled]
* jc/signed-push (2011-09-12) 7 commits
- push -s: support pre-receive-signature hook
- push -s: receiving end
- push -s: send signed push certificate
- push -s: skeleton
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch uses jc/run-receive-hook-cleanup; is tangled with jc/signed-push-3.)
This was the v2 that updated notes tree on the receiving end.
* jc/signed-push-3 (2011-09-12) 4 commits
. push -s: signed push
- Split GPG interface into its own helper library
- rename "match_refs()" to "match_push_refs()"
- send-pack: typofix error message
(this branch uses jc/run-receive-hook-cleanup; is tangled with jc/signed-push.)
This is the third edition, that moves the preparation of the notes tree to
the sending end.
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Will be dropped.
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jk/generation-numbers (2011-09-11) 8 commits
- metadata-cache.c: make two functions static
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) in bk/ancestry-path would help.
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
Incomplete with respect to backslash processing in prefix_filename(), and
also loses the ability to escape glob specials. Perhaps drop?
--------------------------------------------------
[Cooking]
* bw/grep-no-index-no-exclude (2011-09-15) 2 commits
- grep --no-index: don't use git standard exclusions
- grep: do not use --index in the short usage output
* jc/namespace-doc-with-old-asciidoc (2011-09-16) 1 commit
- Documentation/gitnamespaces.txt: cater to older asciidoc
* jc/want-commit (2011-09-15) 1 commit
- Allow git merge ":/<pattern>"
* jc/ls-remote-short-help (2011-09-16) 1 commit
- ls-remote: a lone "-h" is asking for help
* jc/maint-bundle-too-quiet (2011-09-19) 1 commit
- Teach progress eye-candy to fetch_refs_from_bundle()
* jk/filter-branch-require-clean-work-tree (2011-09-15) 1 commit
- filter-branch: use require_clean_work_tree
* jn/gitweb-highlite-sanitise (2011-09-16) 1 commit
- gitweb: Strip non-printable characters from syntax highlighter output
* mh/check-ref-format-3 (2011-09-16) 22 commits
- add_ref(): verify that the refname is formatted correctly
- resolve_ref(): expand documentation
- resolve_ref(): also treat a too-long SHA1 as invalid
- resolve_ref(): emit warnings for improperly-formatted references
- resolve_ref(): verify that the input refname has the right format
- remote: avoid passing NULL to read_ref()
- remote: use xstrdup() instead of strdup()
- resolve_ref(): do not follow incorrectly-formatted symbolic refs
- resolve_ref(): extract a function get_packed_ref()
- resolve_ref(): turn buffer into a proper string as soon as possible
- resolve_ref(): only follow a symlink that contains a valid, normalized refname
- resolve_ref(): use prefixcmp()
- resolve_ref(): explicitly fail if a symlink is not readable
- Change check_refname_format() to reject unnormalized refnames
- Inline function refname_format_print()
- Make collapse_slashes() allocate memory for its result
- Do not allow ".lock" at the end of any refname component
- Refactor check_refname_format()
- Change check_ref_format() to take a flags argument
- Change bad_ref_char() to return a boolean value
- git check-ref-format: add options --allow-onelevel and --refspec-pattern
- t1402: add some more tests
* cn/eradicate-working-copy (2011-09-21) 1 commit
- Remove 'working copy' from the documentation and C code
* js/bisect-no-checkout (2011-09-21) 1 commit
(merged to 'next' on 2011-09-21 at e94ad3e)
+ bisect: fix exiting when checkout failed in bisect_start()
* mg/maint-doc-sparse-checkout (2011-09-21) 3 commits
(merged to 'next' on 2011-09-21 at f316dec)
+ git-read-tree.txt: correct sparse-checkout and skip-worktree description
+ git-read-tree.txt: language and typography fixes
+ unpack-trees: print "Aborting" to stderr
* ms/patch-id-with-overlong-line (2011-09-22) 1 commit
- patch-id.c: use strbuf instead of a fixed buffer
* sn/doc-update-index-assume-unchanged (2011-09-21) 1 commit
(merged to 'next' on 2011-09-21 at 325e796)
+ Documentation/git-update-index: refer to 'ls-files'
* jc/request-pull-show-head-4 (2011-09-21) 7 commits
- request-pull: use the branch description
- request-pull: state what commit to expect
- request-pull: modernize style
- branch: teach --edit-description option
- format-patch: use branch description in cover letter
- branch: add read_branch_desc() helper function
- Merge branch 'bk/ancestry-path' into jc/branch-desc
(this branch uses bk/ancestry-path.)
* jm/mergetool-pathspec (2011-09-16) 2 commits
- mergetool: no longer need to save standard input
- mergetool: Use args as pathspec to unmerged files
* nd/maint-autofix-tag-in-head (2011-09-18) 4 commits
- Accept tags in HEAD or MERGE_HEAD
- merge: remove global variable head[]
- merge: use return value of resolve_ref() to determine if HEAD is invalid
- merge: keep stash[] a local variable
* jk/maint-fetch-submodule-check-fix (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 3c73b8c)
+ fetch: avoid quadratic loop checking for updated submodules
(this branch is used by jk/argv-array.)
This probably can wait, as long as the other half of the regression fix
is in the upcoming release.
* bc/attr-ignore-case (2011-09-14) 5 commits
- attr: read core.attributesfile from git_default_core_config
- attr.c: respect core.ignorecase when matching attribute patterns
- builtin/mv.c: plug miniscule memory leak
- cleanup: use internal memory allocation wrapper functions everywhere
- attr.c: avoid inappropriate access to strbuf "buf" member
* jc/maint-fsck-fwrite-size-check (2011-09-11) 1 commit
(merged to 'next' on 2011-09-16 at 2258f11)
+ fsck: do not abort upon finding an empty blob
* jk/argv-array (2011-09-14) 7 commits
(merged to 'next' on 2011-09-16 at 90feab4)
+ run_hook: use argv_array API
+ checkout: use argv_array API
+ bisect: use argv_array API
+ quote: provide sq_dequote_to_argv_array
+ refactor argv_array into generic code
+ quote.h: fix bogus comment
+ add sha1_array API docs
(this branch uses jk/maint-fetch-submodule-check-fix.)
* js/cred-macos-x-keychain-2 (2011-09-14) 1 commit
- contrib: add a pair of credential helpers for Mac OS X's keychain
(this branch uses jk/http-auth-keyring.)
Welcome addition to build our confidence in the jk/http-auth-keyring topic.
* rj/maint-t9159-svn-rev-notation (2011-09-21) 1 commit
- t9159-*.sh: skip for mergeinfo test for svn <= 1.4
* tr/doc-note-rewrite (2011-09-13) 1 commit
(merged to 'next' on 2011-09-16 at 5fe813a)
+ Documentation: basic configuration of notes.rewriteRef
Updated to a safer wording.
* jk/default-attr (2011-09-12) 1 commit
- attr: map builtin userdiff drivers to well-known extensions
Will be re-rolled after 1.7.7 final.
* hl/iso8601-more-zone-formats (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 270f5c7)
+ date.c: Support iso8601 timezone formats
* jc/run-receive-hook-cleanup (2011-09-12) 1 commit
(merged to 'next' on 2011-09-12 at 68dd431)
+ refactor run_receive_hook()
(this branch is used by jc/signed-push and jc/signed-push-3.)
Just to make it easier to run a hook that reads from its standard input.
* jk/for-each-ref (2011-09-08) 5 commits
(merged to 'next' on 2011-09-14 at 36ed515)
+ for-each-ref: add split message parts to %(contents:*).
+ for-each-ref: handle multiline subjects like --pretty
+ for-each-ref: refactor subject and body placeholder parsing
+ t6300: add more body-parsing tests
+ t7004: factor out gpg setup
* wh/normalize-alt-odb-path (2011-09-07) 1 commit
(merged to 'next' on 2011-09-14 at 96f722b)
+ sha1_file: normalize alt_odb path before comparing and storing
* fk/use-kwset-pickaxe-grep-f (2011-09-11) 2 commits
(merged to 'next' on 2011-09-14 at 436d858)
+ obstack.c: Fix some sparse warnings
+ sparse: Fix an "Using plain integer as NULL pointer" warning
In general we would prefer to see these fixed at the upstream first, but
we have essentially forked from them at their last GPLv2 versions...
* jc/make-static (2011-09-14) 4 commits
(merged to 'next' on 2011-09-14 at c5943ff)
+ exec_cmd.c: prepare_git_cmd() is sometimes used
+ environment.c: have_git_dir() has users on Cygwin
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
(this branch is tangled with jc/reflog-walk-use-only-nsha1.)
With a few fix-ups; probably needs to be ejected after 1.7.7 happens.
* rj/quietly-create-dep-dir (2011-09-11) 1 commit
(merged to 'next' on 2011-09-12 at 93d1c6b)
+ Makefile: Make dependency directory creation less noisy
* mz/remote-rename (2011-09-11) 4 commits
- remote: only update remote-tracking branch if updating refspec
- remote rename: warn when refspec was not updated
- remote: "rename o foo" should not rename ref "origin/bar"
- remote: write correct fetch spec when renaming remote 'remote'
* cb/common-prefix-unification (2011-09-12) 3 commits
(merged to 'next' on 2011-09-14 at 24f571f)
+ rename pathspec_prefix() to common_prefix() and move to dir.[ch]
+ consolidate pathspec_prefix and common_prefix
+ remove prefix argument from pathspec_prefix
* cb/send-email-help (2011-09-12) 1 commit
(merged to 'next' on 2011-09-14 at ae71999)
+ send-email: add option -h
A separate set of patches to remove the hidden fully-spelled "help" from
other commands would be nice to have as companion patches as well.
* jc/fetch-pack-fsck-objects (2011-09-04) 3 commits
(merged to 'next' on 2011-09-12 at a031347)
+ test: fetch/receive with fsckobjects
+ transfer.fsckobjects: unify fetch/receive.fsckobjects
+ fetch.fsckobjects: verify downloaded objects
We had an option to verify the sent objects before accepting a push but
lacked the corresponding option when fetching. In the light of the recent
k.org incident, a change like this would be a good addition.
* jc/fetch-verify (2011-09-01) 3 commits
(merged to 'next' on 2011-09-12 at 3f491ab)
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/receive-verify.)
During a fetch, we verify that the pack stream is self consistent,
but did not verify that the refs that are updated are consistent with
objects contained in the packstream, and this adds such a check.
* jc/receive-verify (2011-09-09) 6 commits
(merged to 'next' on 2011-09-12 at 856de78)
+ receive-pack: check connectivity before concluding "git push"
+ check_everything_connected(): libify
+ check_everything_connected(): refactor to use an iterator
+ fetch: verify we have everything we need before updating our ref
+ rev-list --verify-object
+ list-objects: pass callback data to show_objects()
(this branch uses jc/traverse-commit-list; is tangled with jc/fetch-verify.)
While accepting a push, we verify that the pack stream is self consistent,
but did not verify that the refs the push updates are consistent with
objects contained in the packstream, and this adds such a check.
* jn/maint-http-error-message (2011-09-06) 2 commits
(merged to 'next' on 2011-09-12 at a843f03)
+ http: avoid empty error messages for some curl errors
+ http: remove extra newline in error message
* bk/ancestry-path (2011-09-15) 4 commits
(merged to 'next' on 2011-09-15 at aa64d04)
+ t6019: avoid refname collision on case-insensitive systems
(merged to 'next' on 2011-09-02 at d05ba5d)
+ revision: do not include sibling history in --ancestry-path output
+ revision: keep track of the end-user input from the command line
+ rev-list: Demonstrate breakage with --ancestry-path --all
(this branch is used by jc/request-pull-show-head-4.)
* mg/branch-list (2011-09-13) 7 commits
(merged to 'next' on 2011-09-14 at 6610a2e)
+ t3200: clean up checks for file existence
(merged to 'next' on 2011-09-11 at 20a9cdb)
+ branch: -v does not automatically imply --list
(merged to 'next' on 2011-09-02 at b818eae)
+ branch: allow pattern arguments
+ branch: introduce --list option
+ git-branch: introduce missing long forms for the options
+ git-tag: introduce long forms for the options
+ t6040: test branch -vv
* mm/rebase-i-exec-edit (2011-08-26) 2 commits
(merged to 'next' on 2011-09-02 at e75b1b9)
+ rebase -i: notice and warn if "exec $cmd" modifies the index or the working tree
+ rebase -i: clean error message for --continue after failed exec
* hv/submodule-merge-search (2011-08-26) 5 commits
- submodule: Search for merges only at end of recursive merge
- allow multiple calls to submodule merge search for the same path
- submodule: Demonstrate known breakage during recursive merge
- push: Don't push a repository with unpushed submodules
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with fg/submodule-auto-push.)
The second from the bottom one needs to be replaced with a properly
written commit log message.
* mm/mediawiki-as-a-remote (2011-09-01) 2 commits
(merged to 'next' on 2011-09-12 at 163c6a5)
+ git-remote-mediawiki: allow push to set MediaWiki metadata
+ Add a remote helper to interact with mediawiki (fetch & push)
Fun.
* bc/unstash-clean-crufts (2011-08-27) 4 commits
(merged to 'next' on 2011-09-02 at 7bfd66f)
+ git-stash: remove untracked/ignored directories when stashed
+ t/t3905: add missing '&&' linkage
+ git-stash.sh: fix typo in error message
+ t/t3905: use the name 'actual' for test output, swap arguments to test_cmp
* da/make-auto-header-dependencies (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at e04a4af)
+ Makefile: Improve compiler header dependency check
(this branch uses fk/make-auto-header-dependencies.)
* gb/am-hg-patch (2011-08-29) 1 commit
(merged to 'next' on 2011-09-02 at 3edfe4c)
+ am: preliminary support for hg patches
* jc/diff-index-unpack (2011-08-29) 3 commits
(merged to 'next' on 2011-09-02 at 4206bd9)
+ diff-index: pass pathspec down to unpack-trees machinery
+ unpack-trees: allow pruning with pathspec
+ traverse_trees(): allow pruning with pathspec
* nm/grep-object-sha1-lock (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at 336f57d)
+ grep: Fix race condition in delta_base_cache
* tr/mergetool-valgrind (2011-08-30) 1 commit
(merged to 'next' on 2011-09-02 at f5f2c61)
+ Symlink mergetools scriptlets into valgrind wrappers
* fg/submodule-auto-push (2011-09-11) 2 commits
(merged to 'next' on 2011-09-11 at 3fc86f7)
+ submodule.c: make two functions static
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
(this branch is tangled with hv/submodule-merge-search.)
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
(this branch is used by jc/fetch-verify and jc/receive-verify.)
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
(this branch is used by da/make-auto-header-dependencies.)
* mh/iterate-refs (2011-09-11) 7 commits
- refs.c: make create_cached_refs() static
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
* jk/http-auth-keyring (2011-09-16) 21 commits
(merged to 'next' on 2011-09-16 at b4195eb)
+ check_expirations: don't copy over same element
+ t0300: add missing EOF terminator for <<
(merged to 'next' on 2011-09-14 at 589c7c9)
+ credential-store: use a better storage format
+ t0300: make alternate username tests more robust
+ t0300: make askpass tests a little more robust
+ credential-cache: fix expiration calculation corner cases
+ docs: minor tweaks to credentials API
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is tangled with js/cred-macos-x-keychain and js/cred-macos-x-keychain-2.)
* rr/revert-cherry-pick-continue (2011-09-11) 19 commits
(merged to 'next' on 2011-09-11 at 7d78054)
+ builtin/revert.c: make commit_list_append() static
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
--------------------------------------------------
[Discarded]
* js/cred-macos-x-keychain (2011-09-11) 15 commits
(merged to 'next' on 2011-09-12 at 8d17f94)
+ contrib: add a credential helper for Mac OS X's keychain
(merged to 'next' on 2011-09-11 at 491ce6a)
+ credentials: make credential_fill_gently() static
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
(this branch is tangled with jk/http-auth-keyring and js/cred-macos-x-keychain-2.)
Reverted out of 'next'.
* jc/reflog-walk-use-only-nsha1 (2011-09-13) 4 commits
. (baloon) teach reflog-walk to look at only new-sha1 field
+ environment.c: have_git_dir() has users on Cygwin
(merged to 'next' on 2011-09-11 at 2acb0af)
+ vcs-svn: remove unused functions and make some static
+ make-static: master
(this branch is tangled with jc/make-static.)
* hw/maint-abspath-cwd-limit (2011-09-21) 3 commits
(merged to 'next' on 2011-09-21 at 210cf9a)
+ Revert 622fea4 (abspath.c: increase array size of cwd variable)
(merged to 'next' on 2011-09-19 at 7d5e921)
+ abspath.c: increase array size of cwd variable to PATH_MAX
+ path.c: increase array size of cwd variable to PATH_MAX
Reverted out of 'next'.
* jc/request-pull-show-head (2011-09-13) 2 commits
(merged to 'next' on 2011-09-13 at c82fb3a)
+ Revert "State what commit to expect in request-pull"
(merged to 'next' on 2011-09-12 at c1c7b73)
+ State what commit to expect in request-pull
Reverted out of 'next'.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.6.4
From: Junio C Hamano @ 2011-09-23 23:37 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
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
Also the following public repositories all have a copy of the v1.7.6.4
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.7.6.4 Release Notes
==========================
Fixes since v1.7.6.3
--------------------
* The error reporting logic of "git am" when the command is fed a file
whose mail-storage format is unknown was fixed.
* "git branch --set-upstream @{-1} foo" did not expand @{-1} correctly.
* "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/".
* "git clone" failed to clone locally from a ".git" file that itself
is not a directory but is a pointer to one.
* "git clone" from a local repository that borrows from another
object store using a relative path in its objects/info/alternates
file did not adjust the alternates in the resulting repository.
* "git describe --dirty" did not refresh the index before checking the
state of the working tree files.
* "git ls-files ../$path" that is run from a subdirectory reported errors
incorrectly when there is no such path that matches the given pathspec.
* "git mergetool" could loop forever prompting when nothing can be read
from the standard input.
Also contains minor fixes and documentation updates.
^ permalink raw reply
* [ANNOUNCE] Git 1.7.7.rc3
From: Junio C Hamano @ 2011-09-23 23:41 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git 1.7.7.rc3 is available for testing but not at the
usual places.
The tarball is found at:
http://code.google.com/p/git-core/downloads/list
and its SHA-1 checksum is:
c6ba05a833cab49dd66dd1e252306e187effbf2b git-1.7.7.rc3.tar.gz
Also the following public repositories all have a copy of the v1.7.7-rc3
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
I had to make a quick fix for a recent regression directly on master, and
I would like to cook it for a few days, so the final has to wait til mid
next week.
Until then please help testing to find other regressions.
----------------------------------------------------------------
Changes since v1.7.7-rc2 are as follows:
Allan Caffee (1):
describe: Refresh the index when run with --dirty
Jay Soffian (1):
git-mergetool: check return value from read
Jeff King (1):
t4014: clean up format.thread config after each test
Junio C Hamano (3):
Git 1.7.6.4
merge-recursive: Do not look at working tree during a virtual ancestor merge
Git 1.7.7-rc3
^ permalink raw reply
* Re: SSL certificate password storage?
From: Jay Soffian @ 2011-09-24 1:04 UTC (permalink / raw)
To: James B; +Cc: git
In-Reply-To: <CAEsSSh2MDPgcFtrwYJ7uCDHBHPEfo35deE4dsWrb7Ukp7b310A@mail.gmail.com>
On Fri, Sep 23, 2011 at 6:41 PM, James B <coderer@gmail.com> wrote:
> 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?
It's being worked on -
http://www.google.com/search?q=git+credential+helper+site:gmane.org
j.
^ 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