* Re: Getting started contributing.
From: adamfraser @ 2013-02-04 8:42 UTC (permalink / raw)
To: git
In-Reply-To: <7v1ucx9o4m.fsf@alter.siamese.dyndns.org>
Thanks for all of the replies. I'll have a look into the suggestions and try
to find somewhere I can help out. :)
--
View this message in context: http://git.661346.n2.nabble.com/Getting-started-contributing-tp7576834p7576901.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Segmentation fault with latest git (070c57df)
From: Junio C Hamano @ 2013-02-04 9:16 UTC (permalink / raw)
To: Jeff King; +Cc: jongman.heo, Jonathan Nieder, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <20130204083701.GA30835@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Do we want to do anything with the other dependency hole I found here:
>
> http://article.gmane.org/gmane.comp.version-control.git/215211
>
> It's definitely a potential problem, but I don't think we have any
> reports of it happening in practice, so it might not be worth worrying
> about. Doing a clean version of the fix here:
>
> http://article.gmane.org/gmane.comp.version-control.git/215212
>
> would probably involve reorganizing our .depend directory structure,
> unless somebody can cook up some clever use of make's patsubst.
As I understand how the current set-up works:
* Initially, we do not have foo.o but foo.c. We automatically
build foo.o because it depends on foo.c via the "%.o : %.c" rule,
and as a side effect, we also build .depend/foo.o.d file;
* Then, if any real dependency used to build the existing foo.o
that is recorded in .depend/foo.o.d file changes, foo.o gets
rebuilt, which would update .depend/foo.o.d again for the next
invocation.
The case where you lose .depend/foo.o.d is a special case of getting
a wrong information in .depend/foo.o.d, which may happen by using a
broken compiler during the initial build, or going over quota and
getting .depend/foo.o.d truncated, or by other breakages. The user
may have done "rm -rf .depend" to lose it, or the user may have done
something like this to munge it:
find -name '.git' -type d -prune -o -print0 |
xargs -0 sed -i -e 's/foo/bar/g'
forgetting that just like .git, .depend is precious and should not
be touched.
I think this really boils down to where we draw the "this is good
enough" line. I am not sure if losing the file as in $gmane/215211
is common enough to be special cased to buy us much, while leaving
other ".depend/foo.o.d was updated to contain a wrong info" cases
still broken.
And of course the case where .depend/foo.o.d is munged by mistake
cannot be solved without recompiling everything all the time, so...
^ permalink raw reply
* Re: Segmentation fault with latest git (070c57df)
From: Junio C Hamano @ 2013-02-04 9:29 UTC (permalink / raw)
To: Jeff King; +Cc: jongman.heo, Jonathan Nieder, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <7vsj5c4exz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> As I understand how the current set-up works:
>
> * Initially, we do not have foo.o but foo.c. We automatically
> build foo.o because it depends on foo.c via the "%.o : %.c" rule,
> and as a side effect, we also build .depend/foo.o.d file;
>
> * Then, if any real dependency used to build the existing foo.o
> that is recorded in .depend/foo.o.d file changes, foo.o gets
> rebuilt, which would update .depend/foo.o.d again for the next
> invocation.
This is unrelated to the case you mentioned, but I wonder what
happens if you did this:
* You are on branch 'next', where foo.c includes (perhaps
indirectly) frotz.h. Compile and you get foo.o and also the
dependency recorded for it, "foo.o: foo.c frotz.h", in the
.depend/foo.o.d file.
* You check out branch 'master', where foo.c does not include
frotz.h. Indeed, the include file does not even exist on the
branch.
Do we get confused, because Makefile includes the depend file from
the previous build, finds that you need foo.c and frotz.h up to date
in order to get foo.o, but there is no rule to generate frotz.h?
^ permalink raw reply
* Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-04 9:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: jongman.heo, Jonathan Nieder, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <7vsj5c4exz.fsf@alter.siamese.dyndns.org>
On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote:
> I think this really boils down to where we draw the "this is good
> enough" line. I am not sure if losing the file as in $gmane/215211
> is common enough to be special cased to buy us much, while leaving
> other ".depend/foo.o.d was updated to contain a wrong info" cases
> still broken.
Hmm. Yeah, I was thinking it might be more common than ordinary munging
due to something like an interrupted "git clean -x". But given that:
1. As far as I can tell, it is not a situation that can happen through
regular use of checkout/make/etc, and...
2. We have zero reports of it happening in practice (I only discovered
it while explicitly trying to break the Makefile), and...
3. It is just one of many possible breakages, all of which can be
fixed by "git clean -dx" if you suspect issues...
let's just leave it. Thanks for a sanity check.
-Peff
^ permalink raw reply
* Re: Segmentation fault with latest git (070c57df)
From: Jeff King @ 2013-02-04 9:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: jongman.heo, Jonathan Nieder, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <7vobg04ebe.fsf@alter.siamese.dyndns.org>
On Mon, Feb 04, 2013 at 01:29:41AM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > As I understand how the current set-up works:
> >
> > * Initially, we do not have foo.o but foo.c. We automatically
> > build foo.o because it depends on foo.c via the "%.o : %.c" rule,
> > and as a side effect, we also build .depend/foo.o.d file;
> >
> > * Then, if any real dependency used to build the existing foo.o
> > that is recorded in .depend/foo.o.d file changes, foo.o gets
> > rebuilt, which would update .depend/foo.o.d again for the next
> > invocation.
>
> This is unrelated to the case you mentioned, but I wonder what
> happens if you did this:
>
> * You are on branch 'next', where foo.c includes (perhaps
> indirectly) frotz.h. Compile and you get foo.o and also the
> dependency recorded for it, "foo.o: foo.c frotz.h", in the
> .depend/foo.o.d file.
>
> * You check out branch 'master', where foo.c does not include
> frotz.h. Indeed, the include file does not even exist on the
> branch.
>
> Do we get confused, because Makefile includes the depend file from
> the previous build, finds that you need foo.c and frotz.h up to date
> in order to get foo.o, but there is no rule to generate frotz.h?
No, because the .d files look like this:
foo.o: frotz.h
frotz.h:
So make sees that it can build frotz.h, which of course does nothing.
But that's OK, because foo.c doesn't actually include it anymore, and
when we recompile it (as we must, since it is different between the two
branches), we will rewrite the .d file without frotz.h.
-Peff
^ permalink raw reply
* Re: [RFC] Should "log --cc" imply "log --cc -p"?
From: Michael J Gruber @ 2013-02-04 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmwvl6lj9.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 04.02.2013 00:10:
> I think a natural way to ask reviewing the recent merges while
> showing tricky ones would be to say:
>
> $ git log --first-parent --cc master..pu
>
> But this does not to show what I expect to see, which is an output
> of:
>
> $ git log --first-parent --cc -p master..pu
>
I'm not Junio, but I guess he would respond that it's a matter of
expectations: "--cc" is a diff option, and just like any other diff
option, it has an effect on "log" only if "log" has been told to show a
diff.
Oh wait, you *are* Junio ;)
> This is only a minor irritation, but I think it might make sense to
> make it notice the --cc in the former and turn -p on automatically.
I think we have a clear distiction between rev-list/log options and diff
options. "log" comes without a diff, "-p" turns on diffs.
"log" passes diff-options to "diff". If the user gives a diff-option to
"log" we can conclude that he meant to request a diff and turn them on
automatically (as if "-p" was there also).
But I'm wondering whether that has adverse effects on scripts/aliases.
For example, I could have a special alias
newpu = log first-parent --cc next..pu
which allows me to use "git newpu" as well as "git newpu -p" to get
those new commits with or without diff in my preferred format, but not
any more after the change you suggest. (I could use a second alias, of
course; and yes, I'm (ab)using current option parser features.)
> The same for
>
> $ git log --cc next~3..next
>
> which may make sense to turn into "git log -p --cc next~3..next".
>
> When deciding if the above makes sense, there are a few things to
> know to be true as prerequisites for the discussion:
>
> * Neither of these
>
> $ git log --first-parent -p master..pu
> $ git log -p master..pu
>
> shows any patches, and it is not a bug. No patches are shown for
> merges unless -m is given, and when -m is given, we give pairwise
> 2-way diffs for the number of parents.
But diffs are on here ("-p"), it's just that the default diff option for
merges is to not display them. Well, I admit there's two different ways
of thinking here:
A) "git log -p" turns on diffs for all commits, and the default diff
options is the (non-existing) "--no-show" diff-option for merges.
B) "git log -p" applies "-p" to all commits except merge commits.
I'm strongly in the A camp, because I think that this gives a clearer
interface. A really describes the user facing side, whereas B is closer
to the implementation.
> * We recently tweaked this:
>
> $ git log --first-parent -m -p master..pu
>
> to omit diffs with second and later parents, as that is what the
> user wishes with --first-parent.
That made --first-parent into a dual-purpose option, i.e. it modifies
the rev-listing to one parent as well as the diff creation. It does not
turn on diffs by itself.
> * The "--cc" option, when comparing two trees (i.e. showing a
> non-merge commit), is designed to show a normal patch. In other
> words, you can view "--cc" as a modifier when you request a patch
> output format with "-p". For "git show", "--cc -p" is turned on
> by default, and giving "-m" explicity (i.e. "git show -m") you
> can turn it off and have it do "-m -p" instead.
>
Yes, I really think of --cc is a diff-option, and that this point of
view gives the clearest ui.
We could argue that any diff-option could switch on diffs (imply -p),
but that change seems to be quite radical. "show" having "-p" as a
default is quite natural, but that is different.
Having only "--cc" imply "-p" would be too much special case auto-magic
for my taste. We have too many of these already.
I really think we should leave it as is.
Michael
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Michael J Gruber @ 2013-02-04 11:18 UTC (permalink / raw)
To: Robert Clausecker; +Cc: git
In-Reply-To: <1359901085.24730.11.camel@t520>
Robert Clausecker venit, vidit, dixit 03.02.2013 15:18:
> Hello!
>
> git currently has the archive command that allows to save an arbitrary
> revision into a tar or zip file. Sometimes it is useful to not save this
> revision into an archive but to directly put all files into an arbitrary
> directory. Currently this seems to be not possible to archive directly;
> the only way I found to do it is to run git archive and then directly
> unpack the archive into a directory.
>
> git --git-dir REPO archive REVISION | tar x
>
> It would be nice to have a command or simply a switch to git archive
> that allows the user to put the files of REVISION into a directory
> instead of making an archive.
>
> Thank you very much for your help. Yours,
>
> Robert Clausecker
Sitaram has said much about the Unix philosophy already, and Konstantin
gave a variant of checkout. Just two more cents:
How would you copy a directory tree? I presume you wouldn't use "tar c .
| tar -xC gothere", but what would be your worklflow?
Depending on what you actually want to achieve, "git clone -b branch"
and removing the superfluous .git-dir might be a viable option. (Beware
the hardlinks, though.)
Michael
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-04 12:14 UTC (permalink / raw)
To: Michael J Gruber, git
In-Reply-To: <510F9907.7010107@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]
Am Montag, den 04.02.2013, 12:18 +0100 schrieb Michael J Gruber:
> Sitaram has said much about the Unix philosophy already, and Konstantin
> gave a variant of checkout. Just two more cents:
>
> How would you copy a directory tree? I presume you wouldn't use "tar c .
> | tar -xC gothere", but what would be your worklflow?
>
> Depending on what you actually want to achieve, "git clone -b branch"
> and removing the superfluous .git-dir might be a viable option. (Beware
> the hardlinks, though.)
>
> Michael
The specific workflow I am planning is this:
I have a server that hosts a bare git repository. This git repository
contains a branch production. Whenever somebody pushes to production a
hook automatically puts a copy of the current production branch
into /var/www/foo. I could of course use pull for that but it just does
not feels right. Why should I have a repository twice on the server?
Adding an option to put the tree of an arbitrary revision into a
directory is something that improves usability as it is an operation
semantically different from tar. Saying that you can already get this
with git archive and ad-hoc unpacking is as saying: You don't need cp.
Just tar the file and untar it somewhere else.
Of course that is a possibility but it does not not feel right and is
not intuitive. Adding this feature won't cause feature creep but would
rather add an operation that makes sense in some scenarios and reduces
the dependencies on other commands that might not be available on other
platforms (If you care about that).
Also, this functionality is in full accordance with the Unix principle
as it is a basic operation ("put tree into files") and not something
super special. Also, it always feels like a hack if you do this ad-hoc
unpacking. Like "git can't do it the simple way".
Yours, Robert Clausecker
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Tomas Carnecky @ 2013-02-04 12:47 UTC (permalink / raw)
To: Robert Clausecker, Michael J Gruber, git
In-Reply-To: <1359980045.24730.32.camel@t520>
On Mon, 04 Feb 2013 13:14:05 +0100, Robert Clausecker <fuzxxl@gmail.com> wrote:
> Of course that is a possibility but it does not not feel right and is
> not intuitive. Adding this feature won't cause feature creep but would
> rather add an operation that makes sense in some scenarios and reduces
> the dependencies on other commands that might not be available on other
> platforms (If you care about that).
I'd really like to see your reply to Sitaram's email regarding the many
options that tar has. Sure, just teaching git-archive the equivalent of `|tar
-x' probably isn't feature creep. But why stop there and not add some of the
other options as well? After all, some might be equally useful in a different
situation. So where do you stop? When you've completely merged tar into git?
> Also, this functionality is in full accordance with the Unix principle
> as it is a basic operation ("put tree into files") and not something
> super special.
That's what `git checkout` is for. And I would even argue that it's the better
choice in your situation because it would delete files from /var/www/foo which
you have deleted in your repo. git archive|tar wouldn't do that.
^ permalink raw reply
* [PATCH 1/2] git-count-objects.txt: describe each line in -v output
From: Nguyễn Thái Ngọc Duy @ 2013-02-04 12:49 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
The current description requires a bit of guessing (what clause
corresponds to what printed line?) and lacks information, such as
the unit of size and size-pack.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-count-objects.txt | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index 23c80ce..e816823 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -20,11 +20,21 @@ OPTIONS
-------
-v::
--verbose::
- In addition to the number of loose objects and disk
- space consumed, it reports the number of in-pack
- objects, number of packs, disk space consumed by those packs,
- and number of objects that can be removed by running
- `git prune-packed`.
+ Report in more detail:
++
+count: the number of loose objects
++
+size: disk space consumed by loose objects, in KiB
++
+in-pack: the number of in-pack objects
++
+size-pack: disk space consumed by the packs, in KiB
++
+prune-packable: the number of loose objects that are also present in
+the packs. These objects could be pruned using `git prune-packed`.
++
+garbage: the number of files in loose object database that are not
+valid loose objects
GIT
---
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* [PATCH 2/2] count-objects: report garbage files in .git/objects/pack directory too
From: Nguyễn Thái Ngọc Duy @ 2013-02-04 12:49 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1359982145-10792-1-git-send-email-pclouds@gmail.com>
While it's unusual to have strange files in loose object database,
.git/objects/pack/tmp_* is normal after a broken fetch and they
can eat up a lot of disk space if the user does not pay attention.
Report them.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
The hook in prepare_packed_git_one is ugly, but I don't want to
duplicate the search file logic there in count-objects. Maybe I'm
wrong.
Interestingly it reports .commits file in my repo too. A nice
reminder to myself to remind Jeff about count-objects improvements
for his commit-cache work :)
Way may also need a more friendly format than this one, which I
assume is plumbing. Something that average git user can understand
without looking up the document. If "git stats" is too much for this
purpose, perhaps "git gc --stats"?
Documentation/git-count-objects.txt | 4 ++--
builtin/count-objects.c | 27 ++++++++++++++++++++++++++-
sha1_file.c | 23 ++++++++++++++++++++---
3 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
index e816823..1611d7c 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -33,8 +33,8 @@ size-pack: disk space consumed by the packs, in KiB
prune-packable: the number of loose objects that are also present in
the packs. These objects could be pruned using `git prune-packed`.
+
-garbage: the number of files in loose object database that are not
-valid loose objects
+garbage: the number of files in object database that are not valid
+loose objects nor valid packs
GIT
---
diff --git a/builtin/count-objects.c b/builtin/count-objects.c
index 9afaa88..e8fabcf 100644
--- a/builtin/count-objects.c
+++ b/builtin/count-objects.c
@@ -9,6 +9,8 @@
#include "builtin.h"
#include "parse-options.h"
+static unsigned long garbage;
+
static void count_objects(DIR *d, char *path, int len, int verbose,
unsigned long *loose,
off_t *loose_size,
@@ -65,6 +67,27 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
}
}
+extern void (*report_pack_garbage)(const char *path, int len, const char *name);
+static void real_report_pack_garbage(const char *path, int len, const char *name)
+{
+ if (is_dot_or_dotdot(name))
+ return;
+ if (has_extension(name, ".pack")) {
+ struct strbuf idx_file = STRBUF_INIT;
+ struct stat st;
+
+ strbuf_addf(&idx_file, "%.*s/%.*s.idx", len, path,
+ (int)strlen(name) - 5, name);
+ if (!stat(idx_file.buf, &st) && S_ISREG(st.st_mode)) {
+ strbuf_release(&idx_file);
+ return;
+ }
+ strbuf_release(&idx_file);
+ }
+ error("garbage found: %.*s/%s", len, path, name);
+ garbage++;
+}
+
static char const * const count_objects_usage[] = {
N_("git count-objects [-v]"),
NULL
@@ -76,7 +99,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
const char *objdir = get_object_directory();
int len = strlen(objdir);
char *path = xmalloc(len + 50);
- unsigned long loose = 0, packed = 0, packed_loose = 0, garbage = 0;
+ unsigned long loose = 0, packed = 0, packed_loose = 0;
off_t loose_size = 0;
struct option opts[] = {
OPT__VERBOSE(&verbose, N_("be verbose")),
@@ -87,6 +110,8 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
/* we do not take arguments other than flags for now */
if (argc)
usage_with_options(count_objects_usage, opts);
+ if (verbose)
+ report_pack_garbage = real_report_pack_garbage;
memcpy(path, objdir, len);
if (len && objdir[len-1] != '/')
path[len++] = '/';
diff --git a/sha1_file.c b/sha1_file.c
index 40b2329..6045946 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1000,6 +1000,17 @@ void install_packed_git(struct packed_git *pack)
packed_git = pack;
}
+static void dummy_report_pack_garbage(const char *path,
+ int len,
+ const char *name)
+{
+}
+
+void (*report_pack_garbage)(const char *path,
+ int len,
+ const char *name) =
+ dummy_report_pack_garbage;
+
static void prepare_packed_git_one(char *objdir, int local)
{
/* Ensure that this buffer is large enough so that we can
@@ -1024,11 +1035,15 @@ static void prepare_packed_git_one(char *objdir, int local)
int namelen = strlen(de->d_name);
struct packed_git *p;
- if (!has_extension(de->d_name, ".idx"))
+ if (!has_extension(de->d_name, ".idx")) {
+ report_pack_garbage(path, len - 1, de->d_name);
continue;
+ }
- if (len + namelen + 1 > sizeof(path))
+ if (len + namelen + 1 > sizeof(path)) {
+ report_pack_garbage(path, len - 1, de->d_name);
continue;
+ }
/* Don't reopen a pack we already have. */
strcpy(path + len, de->d_name);
@@ -1042,8 +1057,10 @@ static void prepare_packed_git_one(char *objdir, int local)
* .pack file that we can map.
*/
p = add_packed_git(path, len + namelen, local);
- if (!p)
+ if (!p) {
+ report_pack_garbage(path, len - 1, de->d_name);
continue;
+ }
install_packed_git(p);
}
closedir(dir);
--
1.8.1.2.536.gf441e6d
^ permalink raw reply related
* Re: Feature request: Allow extracting revisions into directories
From: Andrew Ardill @ 2013-02-04 12:58 UTC (permalink / raw)
To: Robert Clausecker; +Cc: Michael J Gruber, git@vger.kernel.org
In-Reply-To: <1359980045.24730.32.camel@t520>
On 4 February 2013 23:14, Robert Clausecker <fuzxxl@gmail.com> wrote:
> The specific workflow I am planning is this:
>
> I have a server that hosts a bare git repository. This git repository
> contains a branch production. Whenever somebody pushes to production a
> hook automatically puts a copy of the current production branch
> into /var/www/foo. I could of course use pull for that but it just does
> not feels right. Why should I have a repository twice on the server?
Maybe I'm missing something. How does the behaviour you need differ from
> GIT_WORKING_DIR=/var/www/foo git checkout -f <tree-ish>
??
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Matthieu Moy @ 2013-02-04 13:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy, git, Jonathan Niedier
In-Reply-To: <7v1ucx83fz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> --- a/t/t6030-bisect-porcelain.sh
>>> +++ b/t/t6030-bisect-porcelain.sh
>>> @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
>>> cp .git/BISECT_START saved &&
>>> test_must_fail git bisect start $HASH4 foo -- &&
>>> git branch > branch.output &&
>>> - test_i18ngrep "* (no branch)" branch.output > /dev/null &&
>>> + test_i18ngrep "* (bisecting other)" branch.output > /dev/null &&
[...]
> What does "other" refer to when you start your bisection at a
> detached head?
If I read correctly, the branch name is shown only when the bisection
was not started on a detached HEAD:
+ if (!get_sha1_hex(sb.buf, sha1))
+ strbuf_addstr(&result, _("(bisecting)"));
+ else
+ strbuf_addf(&result, _("(bisecting %s)"), sb.buf);
> I personally think "other" has _no_ value in that message, because
> "(no branch, bisecting)" gives the same amount of information,
> especially because "other" does not say which branch it refers to at
> all.
Just to be sure: "other" here is not a hardcoded message "bisecting
other", but an instance of "bisecting <branch-name>" with the branch
being called "other".
I think this is very valuable information, and most likely the
information you'd be looking for when running "git branch". You're
technically on detached HEAD, but morally on some branch, the HEAD being
detached only because a bisect is in progress.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Getting started contributing.
From: Matthieu Moy @ 2013-02-04 13:19 UTC (permalink / raw)
To: adamfraser; +Cc: git
In-Reply-To: <1359872508519-7576834.post@n2.nabble.com>
adamfraser <adamfraser0@gmail.com> writes:
> Hi,
> I would like to start contributing to git and am looking for a small project
> idea to get started with. On the Small Project Ideas wiki
> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas>
Just to make it clear: this page is not "the official TODO-list for
Git", but a list where we (essentially me) can throw ideas of things to
be implemented.
As you did, the first thing to do is to discuss ideas on the list, to
make sure they are actually wanted.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Getting started contributing.
From: Matthieu Moy @ 2013-02-04 13:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: adamfraser, git
In-Reply-To: <7vhaltalre.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> adamfraser <adamfraser0@gmail.com> writes:
>
>> I would like to start contributing to git and am looking for a small project
>> idea to get started with. On the Small Project Ideas wiki
>> <https://git.wiki.kernel.org/index.php/SmallProjectsIdeas> site there is a
>> suggestion for adding a 'git rebase --status' command that sounds like it
>> would be good for someone who has little knowledge of the code base.
>
> I think the two patches Duy just posted tonight overlap with that
> topic, and I suspect it would give the end users a better experience
> to put the information in "git status" output rather than a separate
> "git rebase" subcommand.
(I'm the one who wrote the idea on the wiki)
"git status" already shows a lot of valuable information about rebase,
but my idea was that there's still room for a much more verbose command
(hence too verbose to appear in the output of "git branch" or "git
status"), saying eg.
* Which patch is being applied (we can imagine giving just the subject
line by default, but showing the complete patch with an additional
--patch option). I often miss that when trying to understand the
origin of a conflict. I can manually look at file
.git/rebase-merge/patch (I seem to remember a patch that shows the
path to this file when rebase stops, but I can't find it anymore), but
a nice porcelain would be nice.
* What's still on the todo-list
Also, perhaps this could gather the advices "(run git rebase <something>
to <do something>)" currently in the output of "git status", and "git
status may just say "(run git rebase --status for more information)"
instead of 2 or 3 lines of advices.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: GIT get corrupted on lustre
From: Eric Chamberland @ 2013-02-04 13:58 UTC (permalink / raw)
To: Sébastien Boisvert
Cc: Thomas Rast, Brian J. Murrell, git, kusmabite,
Pyeron, Jason J CTR (US), Maxime Boissonneault, Philippe Vaucher
In-Reply-To: <51002D18.4080201@calculquebec.ca>
Hi,
On 01/23/2013 01:34 PM, Sébastien Boisvert wrote:
> Hello,
>
> Here is a patch (with git format-patch) that removes any timer if
> NO_SETITIMER is set.
>
Even with the patch, I finally got an error... :-/
Here are the log (strace -f) of a clean execution and one with the error:
http://www.giref.ulaval.ca/~ericc/NO_SETITIMER-patch_bin_git_noerror.txt.gz
http://www.giref.ulaval.ca/~ericc/NO_SETITIMER-patch_bin_git_with_error.txt.gz
Eric
^ permalink raw reply
* [WIP/RFH/RFD/PATCH] grep: allow to use textconv filters
From: Michael J Gruber @ 2013-02-04 15:27 UTC (permalink / raw)
To: git; +Cc: Jeff King
Recently and not so recently, we made sure that log/grep type operations
use textconv filters when a userfacing diff would do the same:
ef90ab6 (pickaxe: use textconv for -S counting, 2012-10-28)
b1c2f57 (diff_grep: use textconv buffers for add/deleted files, 2012-10-28)
0508fe5 (combine-diff: respect textconv attributes, 2011-05-23)
"git grep" currently does not use textconv filters at all, that is
neither for displaying the match and context nor for the actual grepping.
Introduce a binary mode "--textconv" (in addition to "--text" and "-I")
which makes git grep use any configured textconv filters for grepping
and output purposes.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Notes:
I'm somehow stuck in textconv/filespec/... hell, so I'm sending this out
in request for help. I'm sure there are people for whom it's a breeze to
get this right.
The difficulty is in getting the different cases (blob/sha1 vs.
worktree) right, and in making the changes minimally invasive. It seems
that some more refactoring could help: "git show --textconv" does not
use textconv filters when used on blobs either. (It does for diffs, of
course.) Most existing helper functions are tailored for diffs.
Nota bene: --textconv does not affect "diff --stat" either...
builtin/grep.c | 5 ++++-
grep.c | 47 +++++++++++++++++++++++++++++------------------
grep.h | 3 ++-
3 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 8025964..2181c22 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -96,7 +96,7 @@ static void add_work(struct grep_opt *opt, enum grep_source_type type,
grep_source_init(&todo[todo_end].source, type, name, path, id);
if (opt->binary != GREP_BINARY_TEXT)
- grep_source_load_driver(&todo[todo_end].source);
+ grep_source_load_driver(&todo[todo_end].source, opt);
todo[todo_end].done = 0;
strbuf_reset(&todo[todo_end].out);
todo_end = (todo_end + 1) % ARRAY_SIZE(todo);
@@ -659,6 +659,9 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_SET_INT('I', NULL, &opt.binary,
N_("don't match patterns in binary files"),
GREP_BINARY_NOMATCH),
+ OPT_SET_INT(0, "textconv", &opt.binary,
+ N_("process binary files with textconv filters"),
+ GREP_BINARY_TEXTCONV),
{ OPTION_INTEGER, 0, "max-depth", &opt.max_depth, N_("depth"),
N_("descend at most <depth> levels"), PARSE_OPT_NONEG,
NULL, 1 },
diff --git a/grep.c b/grep.c
index 4bd1b8b..410b7b8 100644
--- a/grep.c
+++ b/grep.c
@@ -1,10 +1,12 @@
#include "cache.h"
+#include "diff.h"
+#include "diffcore.h"
#include "grep.h"
#include "userdiff.h"
#include "xdiff-interface.h"
-static int grep_source_load(struct grep_source *gs);
-static int grep_source_is_binary(struct grep_source *gs);
+static int grep_source_load(struct grep_source *gs, struct grep_opt *opt);
+static int grep_source_is_binary(struct grep_source *gs, struct grep_opt *opt);
static struct grep_opt grep_defaults;
@@ -1174,7 +1176,7 @@ static int match_funcname(struct grep_opt *opt, struct grep_source *gs, char *bo
{
xdemitconf_t *xecfg = opt->priv;
if (xecfg && !xecfg->find_func) {
- grep_source_load_driver(gs);
+ grep_source_load_driver(gs, opt);
if (gs->driver->funcname.pattern) {
const struct userdiff_funcname *pe = &gs->driver->funcname;
xdiff_set_find_func(xecfg, pe->pattern, pe->cflags);
@@ -1354,14 +1356,15 @@ static int grep_source_1(struct grep_opt *opt, struct grep_source *gs, int colle
switch (opt->binary) {
case GREP_BINARY_DEFAULT:
- if (grep_source_is_binary(gs))
+ if (grep_source_is_binary(gs, opt))
binary_match_only = 1;
break;
case GREP_BINARY_NOMATCH:
- if (grep_source_is_binary(gs))
+ if (grep_source_is_binary(gs, opt))
return 0; /* Assume unmatch */
break;
case GREP_BINARY_TEXT:
+ case GREP_BINARY_TEXTCONV:
break;
default:
die("bug: unknown binary handling mode");
@@ -1372,7 +1375,7 @@ static int grep_source_1(struct grep_opt *opt, struct grep_source *gs, int colle
try_lookahead = should_lookahead(opt);
- if (grep_source_load(gs) < 0)
+ if (grep_source_load(gs, opt) < 0)
return 0;
bol = gs->buf;
@@ -1610,12 +1613,17 @@ void grep_source_clear_data(struct grep_source *gs)
}
}
-static int grep_source_load_sha1(struct grep_source *gs)
+static int grep_source_load_sha1(struct grep_source *gs, struct grep_opt *opt)
{
enum object_type type;
-
grep_read_lock();
- gs->buf = read_sha1_file(gs->identifier, &type, &gs->size);
+ if (opt->binary == GREP_BINARY_TEXTCONV) {
+ struct diff_filespec *df = alloc_filespec(gs->name);
+ gs->size = fill_textconv(gs->driver, df, &gs->buf);
+ free_filespec(df);
+ } else {
+ gs->buf = read_sha1_file(gs->identifier, &type, &gs->size);
+ }
grep_read_unlock();
if (!gs->buf)
@@ -1625,7 +1633,7 @@ static int grep_source_load_sha1(struct grep_source *gs)
return 0;
}
-static int grep_source_load_file(struct grep_source *gs)
+static int grep_source_load_file(struct grep_source *gs, struct grep_opt *opt)
{
const char *filename = gs->identifier;
struct stat st;
@@ -1660,42 +1668,45 @@ static int grep_source_load_file(struct grep_source *gs)
return 0;
}
-static int grep_source_load(struct grep_source *gs)
+static int grep_source_load(struct grep_source *gs, struct grep_opt *opt)
{
if (gs->buf)
return 0;
switch (gs->type) {
case GREP_SOURCE_FILE:
- return grep_source_load_file(gs);
+ return grep_source_load_file(gs, opt);
case GREP_SOURCE_SHA1:
- return grep_source_load_sha1(gs);
+ return grep_source_load_sha1(gs, opt);
case GREP_SOURCE_BUF:
return gs->buf ? 0 : -1;
}
die("BUG: invalid grep_source type");
}
-void grep_source_load_driver(struct grep_source *gs)
+void grep_source_load_driver(struct grep_source *gs, struct grep_opt *opt)
{
if (gs->driver)
return;
- grep_attr_lock();
+ grep_attr_lock(); //TODO
+ printf("Looking up userdiff driver for: %s", gs->path);
if (gs->path)
gs->driver = userdiff_find_by_path(gs->path);
if (!gs->driver)
gs->driver = userdiff_find_by_name("default");
+ if (opt->binary == GREP_BINARY_TEXTCONV)
+ gs->driver = userdiff_get_textconv(gs->driver);
grep_attr_unlock();
}
-static int grep_source_is_binary(struct grep_source *gs)
+static int grep_source_is_binary(struct grep_source *gs, struct grep_opt *opt)
{
- grep_source_load_driver(gs);
+ grep_source_load_driver(gs, opt);
if (gs->driver->binary != -1)
return gs->driver->binary;
- if (!grep_source_load(gs))
+ if (!grep_source_load(gs, opt))
return buffer_is_binary(gs->buf, gs->size);
return 0;
diff --git a/grep.h b/grep.h
index 8fc854f..d272d25 100644
--- a/grep.h
+++ b/grep.h
@@ -105,6 +105,7 @@ struct grep_opt {
#define GREP_BINARY_DEFAULT 0
#define GREP_BINARY_NOMATCH 1
#define GREP_BINARY_TEXT 2
+#define GREP_BINARY_TEXTCONV 3
int binary;
int extended;
int use_reflog_filter;
@@ -173,7 +174,7 @@ void grep_source_init(struct grep_source *gs, enum grep_source_type type,
const void *identifier);
void grep_source_clear_data(struct grep_source *gs);
void grep_source_clear(struct grep_source *gs);
-void grep_source_load_driver(struct grep_source *gs);
+void grep_source_load_driver(struct grep_source *gs, struct grep_opt *opt);
int grep_source(struct grep_opt *opt, struct grep_source *gs);
--
1.8.1.2.718.g9d378fc
^ permalink raw reply related
* Re: [PATCH v2] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Junio C Hamano @ 2013-02-04 16:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Nguyễn Thái Ngọc Duy, git, Jonathan Niedier
In-Reply-To: <vpqr4kwmdcs.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Just to be sure: "other" here is not a hardcoded message "bisecting
> other", but an instance of "bisecting <branch-name>" with the branch
> being called "other".
OK, then I do not have any objection. Thanks.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Michal Nazarewicz @ 2013-02-04 16:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Krzysztof Mazur
In-Reply-To: <20130130074306.GA17868@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]
On Wed, Jan 30 2013, Jeff King wrote:
> I do not mind a .netrc or .authinfo parser, because while those formats
> do have security problems, they are standard files that may already be
> in use. So as long as we are not encouraging their use, I do not see a
> problem in supporting them (and we already do the same with curl's netrc
> support).
>
> But it would probably make sense for send-email to support the existing
> git-credential subsystem, so that it can take advantage of secure
> system-specific storage. And that is where we should be pointing new
> users. I think contrib/mw-to-git even has credential support written in
> perl, so it would just need to be factored out to Git.pm.
As far as I understand, there could be a git-credential helper that
reads ~/.authinfo and than git-send-email would just call “git
credential fill”, right?
I've noticed though, that git-credential does not support port argument,
which makes it slightly incompatible with ~/.authinfo.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
[-- Attachment #2.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2.2: Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Re: [RFC] Should "log --cc" imply "log --cc -p"?
From: Junio C Hamano @ 2013-02-04 16:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <510F95D7.6010107@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> But diffs are on here ("-p"), it's just that the default diff option for
> merges is to not display them. Well, I admit there's two different ways
> of thinking here:
>
> A) "git log -p" turns on diffs for all commits, and the default diff
> options is the (non-existing) "--no-show" diff-option for merges.
>
> B) "git log -p" applies "-p" to all commits except merge commits.
>
> I'm strongly in the A camp,...
I can personally be trained to think either way, but I suspect that
we already came halfway to
C) "-p" asks for two-way patches, and "-c/--cc" ask for n-way
patches (including but not limited to n==2); it is not that -p
asks for patch generation and others modify the finer behaviour
of patch generation.
"git log/diff-files -U8" do not need "-p" to enable textual patches,
for example. It is "I already told you that I want 8-line context.
For what else, other than showing textual diff, do you think I told
you that for?" and replacing "8-line context" with various other
options that affect patch generation will give us a variety of end
user complaints that would tell us that C) is more intuitive to
them.
But I do not feel very strongly that I am *right* on this issue, so
I won't do anything about it hastily right now.
^ permalink raw reply
* Re: [PATCH] git-send-email: add ~/.authinfo parsing
From: Ted Zlatanov @ 2013-02-04 16:40 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
On Sun, 3 Feb 2013 14:41:49 -0500 Jeff King <peff@peff.net> wrote:
JK> On Sat, Feb 02, 2013 at 06:57:29AM -0500, Ted Zlatanov wrote:
>> If the file name ends with ".gpg", it will run "gpg --decrypt FILE" and
>> use the output. So non-interactively, that could hang if GPG was
>> waiting for input. Does Git handle that, or should I check for a TTY?
JK> No, git does not do anything special with respect to credential helpers
JK> and ttys (nor should it, since one use of helpers is to get credentials
JK> when there is no tty). I think it is GPG's problem to deal with, though.
JK> We will invoke it, and it is up to it to decide whether it can acquire
JK> the passphrase or not (either through the tty, or possibly from
JK> gpg-agent). So it would be wrong to do the tty check yourself.
JK> I haven't tested GPG, but I assume it properly tries to read from
JK> /dev/tty and not stdin. Your helper's stdio is connected to git and
JK> speaking the credential-helper protocol, so GPG reading from stdin would
JK> either steal your input (if run before you read it), or just get EOF (if
JK> you have read all of the pipe content already). If GPG isn't well
JK> behaved, it may be worth redirecting its stdin from /dev/null as a
JK> safety measure.
In my testing GPG did the right thing, so I think this is OK.
>> Take a look at the proposed patch and let me know if it's usable, if you
>> need a formal copyright assignment, etc.
JK> Overall looks sane to me, though my knowledge of .netrc is not
JK> especially good. Usually we try to send patches inline in the email
JK> (i.e., as generated by git-format-patch), and include a "Signed-off-by"
JK> line indicating that content is released to the project; see
JK> Documentation/SubmittingPatches.
OK, thanks. I will fire that off.
>> +use Data::Dumper;
JK> I don't see it used here. Leftover from debugging?
It's part of my Perl new script skeleton, sorry.
>> + print <<EOHIPPUS;
JK> Cute, I haven't seen that one before.
Heh heh. I've had to explain that one in code review many times. "See,
it's the precursor to the modern horse..."
>> +$0 [-f AUTHFILE] [-d] get
>> +
>> +Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
JK> I don't know if we have a particular policy for items in contrib/, but
JK> this license may be too vague. In particular, it does not explicitly
JK> allow redistribution, which would make Junio shipping a release with it
JK> a copyright violation.
JK> Any objection to just putting it under some well-known simple license
JK> (GPL, BSD, or whatever)?
No, I didn't know what Git requires, and I'd like it to be the least
restrictive, so BSD is OK. Stated in -h now.
>> +if ($file =~ m/\.gpg$/)
>> +{
>> + $file = "gpg --decrypt $file|";
>> +}
JK> Does this need to quote $file, since the result will get passed to the
JK> shell? It might be easier to just use the list form of open(), like:
JK> my @data = $file =~ /\.gpg$/ ?
JK> load('-|', qw(gpg --decrypt), $file) :
JK> load('<', $file);
JK> (and then obviously update load to just dump all of @_ to open()).
Yes, thanks. Done.
>> +die "Sorry, we could not load data from [$file]"
>> + unless (scalar @data);
JK> Probably not that interesting a corner case, but this means we die on an
JK> empty .netrc, whereas it might be more sensible for it to behave as "no
JK> match".
JK> For the same reason, it might be worth silently exiting when we don't
JK> find a .netrc (or any of its variants). That lets people who share their
JK> dot-files across machines configure git globally, even if they don't
JK> necessarily have a netrc on every machine.
OK; done.
>> +# the query
>> +my %q;
>> +
>> +foreach my $v (values %{$options{tmap}})
>> +{
>> + undef $q{$v};
>> +}
JK> Just my personal style, but I find the intent more obvious with "map" (I
JK> know some people find it unreadable, though):
JK> my %q = map { $_ => undef } values(%{$options{tmap}});
Yes, changed.
>> +while (<STDIN>)
>> +{
>> + next unless m/([a-z]+)=(.+)/;
JK> We don't currently have any exotic tokens that this would not match, nor
JK> do I plan to add them, but the credential documentation defines a valid
JK> line as /^([^=]+)=(.+)/.
JK> It's also possible for the value to be empty, but I do not think
JK> off-hand that current git will ever send such an empty value.
Yes, changed.
JK> The rest of it looks fine to me. I don't think any of my comments are
JK> show-stoppers. Tests would be nice, but integrating contrib/ stuff with
JK> the test harness is kind of a pain.
"I tested it on AIX, it works great!" :)
It's pretty easy to write a local Makefile with a test target, if you
think it worthwhile.
Ted
^ permalink raw reply
* [PATCH 1/3] Add contrib/credentials/netrc with GPG support
From: Ted Zlatanov @ 2013-02-04 16:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
contrib/credential/netrc/git-credential-netrc | 242 +++++++++++++++++++++++++
1 files changed, 242 insertions(+), 0 deletions(-)
create mode 100755 contrib/credential/netrc/git-credential-netrc
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
new file mode 100755
index 0000000..92fc306
--- /dev/null
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -0,0 +1,242 @@
+#!/usr/bin/perl
+
+use strict;
+use warnings;
+
+use Data::Dumper;
+
+use Getopt::Long;
+use File::Basename;
+
+my $VERSION = "0.1";
+
+my %options = (
+ help => 0,
+ debug => 0,
+
+ # identical token maps, e.g. host -> host, will be inserted later
+ tmap => {
+ port => 'protocol',
+ machine => 'host',
+ path => 'path',
+ login => 'username',
+ user => 'username',
+ password => 'password',
+ }
+ );
+
+foreach my $v (values %{$options{tmap}})
+{
+ $options{tmap}->{$v} = $v;
+}
+
+foreach my $suffix ('.gpg', '')
+{
+ foreach my $base (qw/authinfo netrc/)
+ {
+ my $file = glob("~/.$base$suffix");
+ next unless (defined $file && -f $file);
+ $options{file} = $file ;
+ }
+}
+
+Getopt::Long::Configure("bundling");
+
+# TODO: maybe allow the token map $options{tmap} to be configurable.
+GetOptions(\%options,
+ "help|h",
+ "debug|d",
+ "file|f=s",
+ );
+
+if ($options{help})
+{
+ my $shortname = basename($0);
+ $shortname =~ s/git-credential-//;
+
+ print <<EOHIPPUS;
+
+$0 [-f AUTHFILE] [-d] get
+
+Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
+
+Options:
+ -f AUTHFILE: specify a netrc-style file
+ -d: turn on debugging
+
+To enable (note that Git will prepend "git-credential-" to the helper
+name and look for it in the path):
+
+ git config credential.helper '$shortname -f AUTHFILE'
+
+And if you want lots of debugging info:
+
+ git config credential.helper '$shortname -f AUTHFILE -d'
+
+Only "get" mode is supported by this credential helper. It opens
+AUTHFILE and looks for entries that match the requested search
+criteria:
+
+ 'port|protocol':
+ The protocol that will be used (e.g., https). (protocol=X)
+
+ 'machine|host':
+ The remote hostname for a network credential. (host=X)
+
+ 'path':
+ The path with which the credential will be used. (path=X)
+
+ 'login|user|username':
+ The credential’s username, if we already have one. (username=X)
+
+Thus, when we get "protocol=https\nusername=tzz", this credential
+helper will look for lines in AUTHFILE that match
+
+port https login tzz
+
+OR
+
+protocol https login tzz
+
+OR... etc. acceptable tokens as listed above. Any unknown tokens are
+simply ignored.
+
+Then, the helper will print out whatever tokens it got from the line,
+including "password" tokens, mapping e.g. "port" back to "protocol".
+
+The first matching line is used. Tokens can be quoted as 'STRING' or
+"STRING".
+
+No caching is performed by this credential helper.
+
+EOHIPPUS
+
+ exit;
+}
+
+my $mode = shift @ARGV;
+
+# credentials may get 'get', 'store', or 'erase' as parameters but
+# only acknowledge 'get'
+die "Syntax: $0 [-f AUTHFILE] [-d] get" unless defined $mode;
+
+# only support 'get' mode
+exit unless $mode eq 'get';
+
+my $debug = $options{debug};
+my $file = $options{file};
+
+die "Sorry, you need to specify an existing netrc file (with or without a .gpg extension) with -f AUTHFILE"
+ unless defined $file;
+
+die "Sorry, the specified netrc $file is not accessible"
+ unless -f $file;
+
+if ($file =~ m/\.gpg$/)
+{
+ $file = "gpg --decrypt $file|";
+}
+
+my @data = load($file);
+chomp @data;
+
+die "Sorry, we could not load data from [$file]"
+ unless (scalar @data);
+
+# the query
+my %q;
+
+foreach my $v (values %{$options{tmap}})
+{
+ undef $q{$v};
+}
+
+while (<STDIN>)
+{
+ next unless m/([a-z]+)=(.+)/;
+
+ my ($token, $value) = ($1, $2);
+ die "Unknown search token $1" unless exists $q{$token};
+ $q{$token} = $value;
+}
+
+# build reverse token map
+my %rmap;
+foreach my $k (keys %{$options{tmap}})
+{
+ push @{$rmap{$options{tmap}->{$k}}}, $k;
+}
+
+# there are CPAN modules to do this better, but we want to avoid
+# dependencies and generally, complex netrc-style files are rare
+
+if ($debug)
+{
+ foreach (sort keys %q)
+ {
+ printf STDERR "searching for %s = %s\n",
+ $_, $q{$_} || '(any value)';
+ }
+}
+
+LINE: foreach my $line (@data)
+{
+
+ print STDERR "line [$line]\n" if $debug;
+ my @tok;
+ # gratefully stolen from Net::Netrc
+ while (length $line &&
+ $line =~ s/^("((?:[^"]+|\\.)*)"|((?:[^\\\s]+|\\.)*))\s*//)
+ {
+ (my $tok = $+) =~ s/\\(.)/$1/g;
+ push(@tok, $tok);
+ }
+
+ my %tokens;
+ while (@tok)
+ {
+ my ($k, $v) = (shift @tok, shift @tok);
+ next unless defined $v;
+ next unless exists $options{tmap}->{$k};
+ $tokens{$options{tmap}->{$k}} = $v;
+ }
+
+ foreach my $check (sort keys %q)
+ {
+ if (exists $tokens{$check} && defined $q{$check})
+ {
+ print STDERR "comparing [$tokens{$check}] to [$q{$check}] in line [$line]\n" if $debug;
+ next LINE unless $tokens{$check} eq $q{$check};
+ }
+ else
+ {
+ print STDERR "we could not find [$check] but it's OK\n" if $debug;
+ }
+ }
+
+ print STDERR "line has passed all the search checks\n" if $debug;
+ foreach my $token (sort keys %rmap)
+ {
+ print STDERR "looking for useful token $token\n" if $debug;
+ next unless exists $tokens{$token}; # did we match?
+
+ foreach my $rctoken (@{$rmap{$token}})
+ {
+ next if defined $q{$rctoken}; # don't re-print given tokens
+ }
+
+ print STDERR "FOUND: $token=$tokens{$token}\n" if $debug;
+ printf "%s=%s\n", $token, $tokens{$token};
+ }
+
+ last;
+}
+
+sub load
+{
+ my $file = shift;
+ # this supports pipes too
+ my $io = new IO::File($file) or die "Could not open $file: $!\n";
+
+ return <$io>; # whole file
+}
--
1.7.9.rc2
^ permalink raw reply related
* [PATCH 2/3] Skip blank and commented lines in contrib/credentials/netrc
From: Ted Zlatanov @ 2013-02-04 16:42 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
contrib/credential/netrc/git-credential-netrc | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
index 92fc306..a47a223 100755
--- a/contrib/credential/netrc/git-credential-netrc
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -192,6 +192,9 @@ LINE: foreach my $line (@data)
push(@tok, $tok);
}
+ # skip blank lines, comments, etc.
+ next LINE unless scalar @tok;
+
my %tokens;
while (@tok)
{
--
1.7.9.rc2
^ permalink raw reply related
* [PATCH 3/3] Fix contrib/credentials/netrc minor issues: exit quietly; use 3-parameter open; etc.
From: Ted Zlatanov @ 2013-02-04 16:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130203194148.GA26318@sigill.intra.peff.net>
Signed-off-by: Ted Zlatanov <tzz@lifelogs.com>
---
contrib/credential/netrc/git-credential-netrc | 38 +++++++++++++------------
1 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/contrib/credential/netrc/git-credential-netrc b/contrib/credential/netrc/git-credential-netrc
index a47a223..0e35918 100755
--- a/contrib/credential/netrc/git-credential-netrc
+++ b/contrib/credential/netrc/git-credential-netrc
@@ -3,8 +3,6 @@
use strict;
use warnings;
-use Data::Dumper;
-
use Getopt::Long;
use File::Basename;
@@ -58,7 +56,7 @@ if ($options{help})
$0 [-f AUTHFILE] [-d] get
-Version $VERSION by tzz\@lifelogs.com. License: any use is OK.
+Version $VERSION by tzz\@lifelogs.com. License: BSD.
Options:
-f AUTHFILE: specify a netrc-style file
@@ -129,31 +127,36 @@ my $file = $options{file};
die "Sorry, you need to specify an existing netrc file (with or without a .gpg extension) with -f AUTHFILE"
unless defined $file;
-die "Sorry, the specified netrc $file is not accessible"
- unless -f $file;
+unless (-f $file)
+{
+ print STDERR "Sorry, the specified netrc $file is not accessible\n" if $debug;
+ exit 0;
+}
+my @data;
if ($file =~ m/\.gpg$/)
{
- $file = "gpg --decrypt $file|";
+ @data = load('-|', qw(gpg --decrypt), $file)
+}
+else
+{
+ @data = load('<', $file);
}
-my @data = load($file);
chomp @data;
-die "Sorry, we could not load data from [$file]"
- unless (scalar @data);
-
-# the query
-my %q;
-
-foreach my $v (values %{$options{tmap}})
+unless (scalar @data)
{
- undef $q{$v};
+ print STDERR "Sorry, we could not load data from [$file]\n" if $debug;
+ exit;
}
+# the query: start with every token with no value
+my %q = map { $_ => undef } values(%{$options{tmap}});
+
while (<STDIN>)
{
- next unless m/([a-z]+)=(.+)/;
+ next unless m/([^=]+)=(.+)/;
my ($token, $value) = ($1, $2);
die "Unknown search token $1" unless exists $q{$token};
@@ -237,9 +240,8 @@ LINE: foreach my $line (@data)
sub load
{
- my $file = shift;
# this supports pipes too
- my $io = new IO::File($file) or die "Could not open $file: $!\n";
+ my $io = new IO::File(@_) or die "Could not open [@_]: $!\n";
return <$io>; # whole file
}
--
1.7.9.rc2
^ permalink raw reply related
* Re: Segmentation fault with latest git (070c57df)
From: Junio C Hamano @ 2013-02-04 16:46 UTC (permalink / raw)
To: Jeff King; +Cc: jongman.heo, Jonathan Nieder, Thomas Rast, git, Antoine Pelisse
In-Reply-To: <20130204093821.GA32095@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Feb 04, 2013 at 01:16:08AM -0800, Junio C Hamano wrote:
>
>> I think this really boils down to where we draw the "this is good
>> enough" line. I am not sure if losing the file as in $gmane/215211
>> is common enough to be special cased to buy us much, while leaving
>> other ".depend/foo.o.d was updated to contain a wrong info" cases
>> still broken.
>
> Hmm. Yeah, I was thinking it might be more common than ordinary munging
> due to something like an interrupted "git clean -x". But given that:
>
> 1. As far as I can tell, it is not a situation that can happen through
> regular use of checkout/make/etc, and...
>
> 2. We have zero reports of it happening in practice (I only discovered
> it while explicitly trying to break the Makefile), and...
>
> 3. It is just one of many possible breakages, all of which can be
> fixed by "git clean -dx" if you suspect issues...
>
> let's just leave it. Thanks for a sanity check.
The only case that worries me is when make or cc gets interrupted.
As long as make removes the ultimate target *.o in such a case, it
is fine to leave a half-written .depend/foo.o.d (or getting it
removed) behind.
How expensive to generate the dependency for a single foo.c file
into a temporary without compiling it into foo.o, and comparing the
resulting dependency with existing .depend/foo.o.d? If it is very
cheap, it might be worth doing it before linking the final build
product and error the build out when we see discrepancies. I dunno.
^ 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