* Re: [PATCH 0/2] config includes, take 2
From: Jeff King @ 2012-02-07 5:17 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <CAJDDKr6A2UvB3D-Dapw7WCEzWfzLoLd0E8MSDjT0RtdxFeWZAQ@mail.gmail.com>
On Mon, Feb 06, 2012 at 09:01:21PM -0800, David Aguilar wrote:
> I have a questions about this. Let's say I have ~/foo1.gitconfig:
>
> [foo]
> bar = 1
>
> ...and ~/.gitconfig (I forgot the syntax):
>
> [foo]
> bar = 0
>
> #include "~/foo1.gitconfig"
>
>
> Does that mean that:
>
> $ git config -f ~/.gitconfig foo.bar
>
> ...prints 0 and not 1?
Yes, though the syntax is:
[include]
path = foo1.gitconfig
(it doesn't respect tilde-expansion, but it probably should). Note that
the syntax was specifically selected for backwards compatibility, and to
allow manipulation with existing tools.
> I can see cases where this would be undesirable behavior.
>
> For example, an application that uses "git config -z --list -f
> ~/.gitconfig" might expect that the result encompasses all of the
> user-specific config bits.
The problem is that an application might also expect it _not_ to happen
(e.g., if the application is really interested in knowing what's in
~/.gitconfig). Because includes aren't respected now, the safe default
seems to be not to have includes (i.e., don't change behavior for this
case).
A bigger question for me is: if you are interested in getting an answer
from anywhere, why are you restricting with "-f"? IOW, is this a
real-world problem, or a hypothetical one? And if real-world, what is
the actual use case?
> Following this to its natural conclusion means "git config" might
> learn some kind of --no-include flag for use with e.g. "git config
> --no-include -f ~/.gitconfig". That said, I don't know where I would
> ever actually use such a flag.
It already learned it as part of my series (and --includes, as well).
> I do know where I would use an `--include` flag (if following includes
> were not the default behavior when using '-f'), though, and that's why
> I'm asking. The problem with not having it be the default means we
> have to use a flag. This makes it harder to support multiple versions
> of git.
Yes, that's a general problem of adding new command-line options to turn
features off or on. We could add an environment variable to control this
feature. But I'd really like to hear the compelling use case first
(i.e., both why it cannot simply be spelled "git config -z --list", and
why not following includes is not OK).
> Maybe I'm mis-interpreting what you mean by, 'do not use includes for
> "git config" in single-file mode', though.
No, I think you understand the described behavior.
-Peff
^ permalink raw reply
* Re: [PATCH 3/6] Stop producing index version 2
From: Junio C Hamano @ 2012-02-07 5:21 UTC (permalink / raw)
To: Shawn Pearce
Cc: Nguyễn Thái Ngọc, git, Thomas Rast,
Joshua Redstone
In-Reply-To: <CAJo=hJvtRnmvALcn3vKpYTr3j6ada8iboPjWN3cQnwwKzRvrDA@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> <thinking type="wishful" probability="never-happen"
> probably-inflating-flame-from="linus">
>
> I have long wanted to scrap the current index format. I unfortunately
> don't have the time to do it myself. But I suspect there may be a lot
> of gains by making the index format match the canonical tree format
> better by keeping the tree structure within a single file stream,
> nesting entries below their parent directory, and keeping tree SHA-1
> data along with the directory entry.
I suspect that is not so "never-happen wishful thinking".
In an earlier message, I alluded to a data structure that starts with a
single top-level tree entry that is lazily expanded as the index entries
are updated. The above shows that at least two of us share the same (day)
dream, and I suspect there are others that share the same "gut feeling"
that such a tree-based structure would be the way to do large index right.
It would be a large and possibly painful change, but the good thing is
that the index is a local matter and we won't have to worry too much about
a flag day event.
</thinking>
^ permalink raw reply
* Re: [PATCH] add -e: ignore dirty submodules
From: Junio C Hamano @ 2012-02-07 5:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.1202070504340.24259@s15462909.onlinehome-server.info>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> We cannot add untracked/modified files in submodules anyway.
I can see the updated code would not break "git apply" that will be run on
this output, but the above cannot be the whole story. It is unclear to me
what it is trying to achieve (in other words, "this patch does not break
the system" is not the whole purpose of the patch).
When a submodule is updated and is dirty, we would get:
diff --git a/submodule b/submodule
@@ -1,+1 @@
-Subproject commit XXXX...
+Subproject commit YYYY...-dirty
and leaving this diff in the edited patch adds YYYY... for submodule, even
though "-dirty" suffix is there. So it is not fixing "the user tries to
update but fails because we do not filter dirty submodules" bug, or somesuch.
Besides, showing -dirty may be a good reminder that submodule has further
changes on top of what is going to be committed in this case.
When a submodule is only dirty, we would see:
diff --git a/submodule b/submodule
@@ -1,+1 @@
-Subproject commit XXXX...
+Subproject commit XXXX...-dirty
and leaving this diff in the edited patch keeps the submodule at XXXX...,
again without failing, so it is not fixing "the user gets unnecessary
error message" bug, or somesuch. In this case, leaving this diff will be
a no-op so it is wasteful and distracting to the user who edits the patch.
Is that what this patch is about? "For a submodule that is unchanged but
is dirty, submodule diff whose difference is only the '-dirty' suffix is
given but the user cannot update the index with such a diff anyway, so it
is a waste of space", or something like that?
That is the best guess I arrived at, but I suspect that it cannot be it,
as that discards the "-dirty" clue from the output when the submodule path
does have difference, as we saw in the earlier example. So there must be
something I am missing.
So I am out of ideas guessing what this patch is trying to achieve. The
commit log shouldn't force the readers of the history to _guess_ like the
above.
> builtin/add.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index 1c42900..b79336d 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -280,6 +280,7 @@ static int edit_patch(int argc, const char **argv, const char *prefix)
>
> argc = setup_revisions(argc, argv, &rev, NULL);
> rev.diffopt.output_format = DIFF_FORMAT_PATCH;
> + DIFF_OPT_SET(&rev.diffopt, IGNORE_DIRTY_SUBMODULES);
> out = open(file, O_CREAT | O_WRONLY, 0644);
> if (out < 0)
> die (_("Could not open '%s' for writing."), file);
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Junio C Hamano @ 2012-02-07 6:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <7vwr7z653f.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> It still is not clear to me how best to sell this change to the end-user
> community.
OK, sorry for wavering.
Unless you are doing "commit -a" or "commit pathspec", you are responsible
for adding all contents you want to have in the commit before you run the
"git commit" command (and for the purpose of this statement, "add -N" to
tell Git to keey an eye on a path does _not_ add contents). A change to
the file in the working tree that is left unadded is what you decided to
deliberately leave out of the commit, be it a change to a path already in
HEAD, or a path marked with "add -N". Forgetting to add modified file and
forgetting to add a file you earlier used "add -N" amount to the same kind
of risk, and "git status" is the way to make sure your partial commit has
exactly what you want (if you are not worried about partial commit, you
would be doing "commit -a", so the "safety" is a moot point).
I was worried too much about backward compatibility and was blind to the
above, and was mistakenly defending a false "safety" that did not exist at
all. Sorry for wasting everybody's time.
So let's bite the bullet and admit in the Release Notes that the current
behaviour was a UI mistake based on the misguided assumption that we can
give some kind of "safety" by committing when there are "add -N" entries
in the index, which is untrue, and we are fixing it in the new release.
We do not need configuration nor command line options.
Let me try to reroll your patch tomorrow (unless you beat me to it) and
see if I can come up with an easy-to-understand explanation to it.
Thanks.
^ permalink raw reply
* User authentication in GIT
From: supadhyay @ 2012-02-07 6:12 UTC (permalink / raw)
To: git
Hi All,
I want to migrate my existing version control system (CVS) into GIT. The
first question which comes to me is in CVS we have user authentication like
username and their password while in GIT there is SSH authentication.
Can any one suggest me what is the optimal way to manage the users in GIT?
Does all users having username,passowrd and SSH key? or thre is no users
credential but only SSH authentication? if I have 1000 users in old system
CVS then do I need to create a key for all 1000 users in GIT? or etc.
Thanks in advance...
--
View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7261349.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Nguyen Thai Ngoc Duy @ 2012-02-07 6:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <7v1uq741ip.fsf@alter.siamese.dyndns.org>
2012/2/7 Junio C Hamano <gitster@pobox.com>:
> Unless you are doing "commit -a" or "commit pathspec", you are responsible
> for adding all contents you want to have in the commit before you run the
> "git commit" command (and for the purpose of this statement, "add -N" to
> tell Git to keey an eye on a path does _not_ add contents). A change to
> the file in the working tree that is left unadded is what you decided to
> deliberately leave out of the commit, be it a change to a path already in
> HEAD, or a path marked with "add -N". Forgetting to add modified file and
> forgetting to add a file you earlier used "add -N" amount to the same kind
> of risk, and "git status" is the way to make sure your partial commit has
> exactly what you want (if you are not worried about partial commit, you
> would be doing "commit -a", so the "safety" is a moot point).
We need something in the commit message so that 5 years from now, when
someone raises the issue again, (s)he does not have to search the mail
archive. May I steal the above paragraph, maybe rephrase a little bit,
for commit message?
--
Duy
^ permalink raw reply
* [PATCHv2] tag: add --points-at list option
From: Tom Grennan @ 2012-02-07 7:01 UTC (permalink / raw)
To: git; +Cc: gitster, peff, jasampler
In-Reply-To: <20120206081119.GA3939@sigill.intra.peff.net>
The following is version 2 of the "points-at" feature. I think that I've
addressed all of the comments on this discussion other than the name objection.
I suggest "of" instead, as in: "Show me the tags of...".
But, this may be too terse, so I welcome any other suggestions.
Note that this has been rebased onto pu for integration of 'jk/maint-tag-show-fixes'.
Thanks,
Tom Grennan (1):
tag: add --points-at list option
Documentation/git-tag.txt | 5 ++-
builtin/tag.c | 87 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 86 insertions(+), 6 deletions(-)
--
1.7.8
^ permalink raw reply
* [PATCHv2] tag: add --points-at list option
From: Tom Grennan @ 2012-02-07 7:01 UTC (permalink / raw)
To: git; +Cc: gitster, peff, jasampler
In-Reply-To: <20120206081119.GA3939@sigill.intra.peff.net>
This filters the list for annotated|signed tags of the given object.
Example,
john$ git tag -s v1.0-john v1.0
john$ git tag -l --points-at v1.0
v1.0-john
Signed-off-by: Tom Grennan <tmgrennan@gmail.com>
---
Documentation/git-tag.txt | 5 ++-
builtin/tag.c | 86 ++++++++++++++++++++++++++++++++++++++++++---
2 files changed, 85 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 5ead91e..97bedec 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
<tagname> [<commit> | <object>]
'git tag' -d <tagname>...
-'git tag' [-n[<num>]] -l [--contains <commit>]
+'git tag' [-n[<num>]] -l [--contains <commit>] [--points-at <object>]
[--column[=<options>] | --no-column] [<pattern>...]
'git tag' -v <tagname>...
@@ -95,6 +95,9 @@ This option is only applicable when listing tags without annotation lines.
--contains <commit>::
Only list tags which contain the specified commit.
+--points-at <object>::
+ Only list annotated or signed tags of the given object.
+
-m <msg>::
--message=<msg>::
Use the given tag message (instead of prompting).
diff --git a/builtin/tag.c b/builtin/tag.c
index 5fbd62c..a1d3a04 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -20,17 +20,34 @@
static const char * const git_tag_usage[] = {
"git tag [-a|-s|-u <key-id>] [-f] [-m <msg>|-F <file>] <tagname> [<head>]",
"git tag -d <tagname>...",
- "git tag -l [-n[<num>]] [<pattern>...]",
+ "git tag -l [-n[<num>]] [--contains <commit>] [--points-at <object>] \\"
+ "\n\t\t[<pattern>...]",
"git tag -v <tagname>...",
NULL
};
+struct points_at {
+ struct points_at *next;
+ unsigned char *sha1;
+};
+
struct tag_filter {
const char **patterns;
int lines;
struct commit_list *with_commit;
+ struct points_at *points_at;
};
+static void free_points_at (struct points_at *points_at)
+{
+ while (points_at) {
+ struct points_at *next = points_at->next;
+ free(points_at->sha1);
+ free(points_at);
+ points_at = next;
+ }
+}
+
static unsigned int colopts;
static int match_pattern(const char **patterns, const char *ref)
@@ -44,6 +61,29 @@ static int match_pattern(const char **patterns, const char *ref)
return 0;
}
+static struct points_at *match_points_at(struct points_at *points_at,
+ const unsigned char *sha1)
+{
+ char *buf;
+ struct tag *tag;
+ unsigned long size;
+ enum object_type type;
+
+ buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return NULL;
+ if (type != OBJ_TAG
+ || (tag = lookup_tag(sha1), !tag)
+ || parse_tag_buffer(tag, buf, size) < 0) {
+ free(buf);
+ return NULL;
+ }
+ while (points_at && hashcmp(points_at->sha1, tag->tagged->sha1))
+ points_at = points_at->next;
+ free(buf);
+ return points_at;
+}
+
static int in_commit_list(const struct commit_list *want, struct commit *c)
{
for (; want; want = want->next)
@@ -141,6 +181,10 @@ static int show_reference(const char *refname, const unsigned char *sha1,
return 0;
}
+ if (filter->points_at
+ && !match_points_at(filter->points_at, sha1))
+ return 0;
+
if (!filter->lines) {
printf("%s\n", refname);
return 0;
@@ -154,16 +198,19 @@ static int show_reference(const char *refname, const unsigned char *sha1,
}
static int list_tags(const char **patterns, int lines,
- struct commit_list *with_commit)
+ struct commit_list *with_commit,
+ struct points_at *points_at)
{
struct tag_filter filter;
filter.patterns = patterns;
filter.lines = lines;
filter.with_commit = with_commit;
+ filter.points_at = points_at;
for_each_tag_ref(show_reference, (void *) &filter);
+ free_points_at(points_at);
return 0;
}
@@ -389,12 +436,33 @@ static int strbuf_check_tag_ref(struct strbuf *sb, const char *name)
return check_refname_format(sb->buf, 0);
}
+int parse_opt_points_at(const struct option *opt, const char *arg, int unset)
+{
+ struct points_at *new, **opt_value = (struct points_at **)opt->value;
+ unsigned char *sha1;
+
+ if (!arg)
+ return error(_("missing <object>"));
+ new = xmalloc(sizeof(struct points_at));
+ sha1 = xmalloc(20);
+ if (get_sha1(arg, sha1)) {
+ free(new);
+ free(sha1);
+ return error(_("malformed object name '%s'"), arg);
+ }
+ new->sha1 = sha1;
+ new->next = *opt_value;
+ *opt_value = new;
+ return 0;
+}
+
int cmd_tag(int argc, const char **argv, const char *prefix)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf ref = STRBUF_INIT;
unsigned char object[20], prev[20];
const char *object_ref, *tag;
+ struct points_at *points_at = NULL;
struct ref_lock *lock;
struct create_tag_options opt;
char *cleanup_arg = NULL;
@@ -432,6 +500,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
PARSE_OPT_LASTARG_DEFAULT,
parse_opt_with_commit, (intptr_t)"HEAD",
},
+ {
+ OPTION_CALLBACK, 0, "points-at", &points_at, "object",
+ "print only annotated|signed tags of the object",
+ PARSE_OPT_LASTARG_DEFAULT,
+ parse_opt_points_at, (intptr_t)NULL,
+ },
OPT_END()
};
@@ -471,15 +545,17 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
copts.padding = 2;
run_column_filter(colopts, &copts);
}
- ret = list_tags(argv, lines == -1 ? 0 : lines, with_commit);
+ ret = list_tags(argv, lines == -1 ? 0 : lines, with_commit,
+ points_at);
if (lines == -1 && colopts & COL_ENABLED)
stop_column_filter();
return ret;
}
if (lines != -1)
die(_("-n option is only allowed with -l."));
- if (with_commit)
- die(_("--contains option is only allowed with -l."));
+ if (with_commit || points_at)
+ die(_("--contains and --points-at options "
+ "are only allowed with -l."));
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
--
1.7.8
^ permalink raw reply related
* cloning a tree which has detached branch checked out
From: Michael S. Tsirkin @ 2012-02-07 7:06 UTC (permalink / raw)
To: git
I have a tree where I checked out a remote, without
creating a local branch, this detaches the HEAD:
# git branch
* (no branch)
master
#git log|head -1
commit cec64082f689f949a397cb9b39423dc41545fa0e
#git log master..HEAD|head -1
commit cec64082f689f949a397cb9b39423dc41545fa0e
Now if I try to clone it:
#git clone -n lab:/home/mst/scm/linux
Initialized empty Git repository in /home/mst/scm/linux/.git/
remote: Counting objects: 1693446, done.
remote: Compressing objects: 100% (277054/277054), done.
Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
done.
remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
Resolving deltas: 100% (1414353/1414353), done.
error: Trying to write ref HEAD with nonexistant object
cec64082f689f949a397cb9b39423dc41545fa0e
fatal: Cannot update the ref 'HEAD'.
Looks like a bug, doesn't it?
--
MST
^ permalink raw reply
* Re: User authentication in GIT
From: Robin H. Johnson @ 2012-02-07 7:30 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1328595129258-7261349.post@n2.nabble.com>
On Mon, Feb 06, 2012 at 10:12:09PM -0800, supadhyay wrote:
> Hi All,
[snip]
1. Go and use gitolite.
2. All users must have their own SSH key. You do not create keys for them.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
^ permalink raw reply
* Re: [PATCH] add -e: ignore dirty submodules
From: Johannes Schindelin @ 2012-02-07 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa4v42fi.fsf@alter.siamese.dyndns.org>
Dear Junio C Hamano,
On Mon, 6 Feb 2012, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > We cannot add untracked/modified files in submodules anyway.
The purpose of "add -e" is to stage changes. It does so by presenting a
diff which the user can edit (and applying it after recounting the numbers
in the hunk headers).
If the diff does not apply, it does not make sense to present it to the
user.
Offering to add changes represented by a diff like
diff --git <blub>
<header>
-deadbeef...
+deadbeef...-dirty
does not make sense.
Even a diff like
diff --git <blah>
<header>
-deadbeef...
-coffeebabe...-dirty
would be refused by git-apply.
Indeed, due to the design of the submodules, it is impossible to stage
dirty files in a submodule and a supercommit at the same time. Oh, and this
discussion is not the place to wish for a feature like that, just in case
you want to ask me to implement that in order to be allowed to have my puny
little patch applied. (I guess this is the reason why I waited so long
before I dared to submit the patch to the mailing list.)
Now, due to these concerns, even stripping out the -dirty part can lead to
a comically non-sensical diff like
diff --git <blergh>
<header>
-deadbeef...
+deadbeef...
So keeping the diff generation as-is but preparing the patch by munching
away the -dirty suffix would not fix the problem.
Also, it would be wrong to assume that the user asked to get a status
update. git add -e != git status. If the user wanted to know what changes
are in the worktree, including the worktrees of the submodules, but only
those that have been checked out, git status would be the command to call
(even if it was touted as a git commit --dry-run once upon a time, which
is kind of wrong, see above, you cannot commit the untracked or dirty
files in a submodule, yet git status shows them).
So: showing the fact that a submodule has untracked or dirty files in the
patch that the user wants to edit with git add -e is wrong, wrong, wrong.
The only submodule-related thing we should ever present to the user who
called git add -e is a diff like
diff --git <narf>
<header>
-deadcad...
+beda551ed...
because that is a stageable change.
Alas, salvation is nigh! Yes, just a little line which asks for the level
"dirty" (which implies "untracked", as detailed by diff-options.txt, uhm,
sorry, I was asked to be precise, Documentation/diff-options.txt) fixes
that!
With this flag, there are no more "-dirty" lines in the submodule diffs.
None! Only diffs between different submodule commits are shown, and even
if the worktree of the submodule is dirty, or has untracked files, the
-dirty suffix is omitted. Just what you need for git-apply to work! Yay!
As a plus, it makes the diff generation faster because what cannot be
staged anyway is not even discovered! Super-yay!
I actually enjoyed writing this text so much, may I respectfully ask to
include it verbatim in the commit message?
Thank you very much,
Johannes Schindelin
^ permalink raw reply
* Re: [PATCH 2/4] commit: introduce a config key to allow as-is commit with i-t-a entries
From: Junio C Hamano @ 2012-02-07 7:57 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <CACsJy8CaFhyzgh6N4ov49Tf0mA8qV5uQESFP2u8U7AduOd59PA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 2012/2/7 Junio C Hamano <gitster@pobox.com>:
>> Unless you are doing "commit -a" or "commit pathspec", you are responsible
>> for adding all contents you want to have in the commit before you run the
>> "git commit" command (and for the purpose of this statement, "add -N" to
>> tell Git to keey an eye on a path does _not_ add contents). A change to
>> the file in the working tree that is left unadded is what you decided to
>> deliberately leave out of the commit, be it a change to a path already in
>> HEAD, or a path marked with "add -N". Forgetting to add modified file and
>> forgetting to add a file you earlier used "add -N" amount to the same kind
>> of risk, and "git status" is the way to make sure your partial commit has
>> exactly what you want (if you are not worried about partial commit, you
>> would be doing "commit -a", so the "safety" is a moot point).
>
> We need something in the commit message so that 5 years from now, when
> someone raises the issue again, (s)he does not have to search the mail
> archive. May I steal the above paragraph, maybe rephrase a little bit,
> for commit message?
Surely, and thanks.
^ permalink raw reply
* Re: Bug: "git checkout -b" should be allowed in empty repo
From: Michael Haggerty @ 2012-02-07 8:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Andrew Ardill, git
In-Reply-To: <7vpqdr7rn0.fsf@alter.siamese.dyndns.org>
On 02/06/2012 07:17 PM, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> Probably I am slower than my usual slow self this morning. Does Michael's
> approach go like this:
>
> git init project
> cd project
> import import import
> git branch -m vendor
> git checkout -b master
>
> to fork from third-party codebase?
I'm not really forking the third-party code; I'm just importing a
snapshot to a particular subdirectory of my own project. I wanted to do
something like:
git init project
cd project
git checkout -b vendor
import import import commit (into subdirectory "foo")
git checkout --orphan master
git clean -fxd
hack commit hack commit
# Then when the vendor stuff is logically needed in master:
git merge vendor
With the option to import later snapshots of the third-party code to the
"vendor" branch then re-merge it to master.
> Care to come up with a patch to Documentation/git-checkout.txt? The
> description there strongly implies that <start point> is an existing
> commit. Not much is said about what the lack of <start point> mean when
> it describes "checkout -b", and a standalone description of <start point>
> says "The name of a comit at which to start... Defaults to HEAD". These
> need to be loosened and described in terms of the closer-to-the-user "at
> my current state".
I'll work on it as soon as I have time.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] add -e: ignore dirty submodules
From: Junio C Hamano @ 2012-02-07 8:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.1202070124020.4897@bonsai2>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Offering to add changes represented by a diff like
>
> diff --git <blub>
> <header>
> -deadbeef...
> +deadbeef...-dirty
>
> does not make sense.
Now you are being much clearer. If you had the above from the beginning,
I wouldn't have had to ask.
So after all, this is a noise reduction patch, and I think that it is a
good change.
> Even a diff like
>
> diff --git <blah>
> <header>
> -deadbeef...
> -coffeebabe...-dirty
>
> would be refused by git-apply.
That would be refused, but if you replace '-coffeebabe' with '+coffeebabe',
which is what you would get from "git diff" without ignore-dirty-submodule,
I think it would be accepted by "git apply" just fine.
Have you tried it?
> I actually enjoyed writing this text so much, may I respectfully ask to
> include it verbatim in the commit message?
With mostly irrelevant mumblings and all? Of course not.
I was asking what you meant to achieve with the patch, because you did not
even include relevant bits of information.
But now I think I learned what you meant by this patch, so let me try to
see if I understood it correctly by rephrasing it.
Like this?
-- >8 --
Subject: add -e: do not show difference in a submodule that is merely dirty
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Tue, 7 Feb 2012 05:05:48 +0100 (CET)
When the HEAD of the submodule matches what is recorded in the index of
the superproject, and it has local changes or untracked files, the patch
offered by "git add -e" for editing shows a diff like this:
diff --git a/submodule b/submodule
<header>
-deadbeef...
+deadbeef...-dirty
Because applying such a patch has no effect to the index, this is a
useless noise. Generate the patch with IGNORE_DIRTY_SUBMODULES flag to
prevent such a change from getting reported.
This patch also loses the "-dirty" suffix from the output when the HEAD of
the submodule is different from what is in the index of the superproject.
As such dirtiness expressed by the suffix does not affect the result of
the patch application at all, there is no information lost if we remove
it. The user could still run "git status" before "git add -e" if s/he
cares about the dirtiness.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin/add.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 1c42900..b79336d 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -280,6 +280,7 @@ static int edit_patch(int argc, const char **argv, const char *prefix)
argc = setup_revisions(argc, argv, &rev, NULL);
rev.diffopt.output_format = DIFF_FORMAT_PATCH;
+ DIFF_OPT_SET(&rev.diffopt, IGNORE_DIRTY_SUBMODULES);
out = open(file, O_CREAT | O_WRONLY, 0644);
if (out < 0)
die (_("Could not open '%s' for writing."), file);
^ permalink raw reply related
* Re: [PATCHv2] tag: add --points-at list option
From: Junio C Hamano @ 2012-02-07 8:35 UTC (permalink / raw)
To: Tom Grennan; +Cc: git, peff, jasampler
In-Reply-To: <1328598076-7773-2-git-send-email-tmgrennan@gmail.com>
Tom Grennan <tmgrennan@gmail.com> writes:
> +struct points_at {
> + struct points_at *next;
> + unsigned char *sha1;
> +};
struct points_at {
struct points_at *next;
unsigned char sha1[20];
};
would save you from having to allocate and free always in pairs, no?
> +static void free_points_at (struct points_at *points_at)
Please lose the SP before (.
> + if (type != OBJ_TAG
> + || (tag = lookup_tag(sha1), !tag)
> + || parse_tag_buffer(tag, buf, size) < 0) {
Even though I personally prefer to cascade a long expression like this, so
that you see a parse tree when you tilt your head 90-degrees to the left,
I think the prevalent style in Git codebase is
if (A-long-long-expression ||
B-long-long-expression ||
C-long-long-expression) {
Also we try to avoid assignment in the conditional.
> @@ -432,6 +500,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
> PARSE_OPT_LASTARG_DEFAULT,
> parse_opt_with_commit, (intptr_t)"HEAD",
> },
> + {
> + OPTION_CALLBACK, 0, "points-at", &points_at, "object",
> + "print only annotated|signed tags of the object",
> + PARSE_OPT_LASTARG_DEFAULT,
> + parse_opt_points_at, (intptr_t)NULL,
> + },
If you are going to reject NULL anyway, do you still need to mark this as
lastarg-default?
Looking for example in parse-options.h, I found this:
#define OPT_STRING_LIST(s, l, v, a, h) \
{ OPTION_CALLBACK, (s), (l), (v), (a), \
(h), 0, &parse_opt_string_list }
which is used by "git clone" to mark its -c option.
Running "git clone -c" gives me
error: switch 'c' requires a value
without any extra code in the caller of parse_options().
Other than that, looks cleanly done.
Thanks. I'll take another look after I wake up in the morning.
^ permalink raw reply
* Re: [PATCH 3/6] Stop producing index version 2
From: Nguyen Thai Ngoc Duy @ 2012-02-07 8:51 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git, Thomas Rast, Joshua Redstone
In-Reply-To: <CACsJy8Ayqea75xeFKJNm6iT7GSUGDEfvZD17uEv7ihr4SS2LMg@mail.gmail.com>
On Tue, Feb 7, 2012 at 11:50 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> Version 3 was a mistake because of the variable length record sizes.
>> Saving 2 bytes on some records that don't use the extended flags makes
>> the index file *MUCH* harder to parse. So much so that we should take
>> version 3 and kill it, not encourage it as the default!
>
> Probably too late for that, but it's good to know there are strong
> user base for v2.
OK probably not too late. We cannot kill it, but we could deprecate
it. We can introduce a mandatory extension to store extra flags. The
extension is basically an array of
struct ce_extended_flags {
int ce_index; /* points to istate->cache[ce_index] */
unsigned long flags;
};
On reading the extension, extra flags is applied back in mem, the
extension is created again when new index is written. There are only
two users of index v3: skip-worktree and intent-to-add bits, which are
not used often, I think. Still want to kill it?
Switching from sha-1 to crc32 could be done the same way (i.e. new
mandatory extension _at the end_ that contains crc32 checksum and skip
sha-1 check on reading if it's all zero) if we agree to move to crc32.
--
Duy
^ permalink raw reply
* Re: Git performance results on a large repository
From: Emanuele Zattin @ 2012-02-07 8:58 UTC (permalink / raw)
To: git
In-Reply-To: <CB5074CF.3AD7A%joshua.redstone@fb.com>
Joshua Redstone <joshua.redstone <at> fb.com> writes:
>
> Hi Git folks,
>
Hello everybody!
I would just like to contribute a small set of blog posts
about this issue and a possible solution.
Sorry for the tone in which I wrote those posts,
but I think there are some valid points in there.
https://gist.github.com/1758346
BR,
Emanuele Zattin
^ permalink raw reply
* Re: User authentication in GIT
From: Jakub Narebski @ 2012-02-07 9:12 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1328595129258-7261349.post@n2.nabble.com>
supadhyay <supadhyay@imany.com> writes:
> I want to migrate my existing version control system (CVS) into GIT. The
> first question which comes to me is in CVS we have user authentication like
> username and their password while in GIT there is SSH authentication.
Do you use _unencrypted_ pserver, or tunelling over SSH (with CVS_RSH)?
> Can any one suggest me what is the optimal way to manage the users in GIT?
> Does all users having username, passoword and SSH key? or there is no users
> credential but only SSH authentication? if I have 1000 users in old system
> CVS then do I need to create a key for all 1000 users in GIT? or etc.
First, Git supports unauthenticated anonymous fetching via custom
git:// protocol and via HTTP. If you only need read-only access to
repository, it would be enough. No account or SSH key necessary.
Second, Git uses SSH for authenthication instead of hand-rolling its
own security system, badly. You don't need to create 1000 shell
accounts for SSH access: use tool like gitolite to manage git
repositories, which uses public-key infrastructure without need to
generate 1000 accounts. You would still need for each user to
generate their own SSH key.
See gitolite documentation for more detail (older gitosis tool is no
longer maintained, as far as I know).
HTH
--
Jakub Narebski
^ permalink raw reply
* Merging only a subdirectory from one branch to the other
From: Howard Miller @ 2012-02-07 9:38 UTC (permalink / raw)
To: git
Hi,
I've been Googling for this one and am, mostly, more confused than
when I started so if you could humor me for a moment.
I have a branch with a particular subdirectory tree. The tree has a
lot of history. However, all the history for that subdirectory is
exclusive to it (no commits changed anything outside it). I now need
to merge that subdirectory into a completely different branch without
loosing any history. I think git-read-tree might have something to do
with it but I don't understand the help file at all. Any help
appreciated.
Cheers....
^ permalink raw reply
* Re: [PATCH 0/2] config includes, take 2
From: David Aguilar @ 2012-02-07 10:05 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120207051719.GA11598@sigill.intra.peff.net>
On Mon, Feb 6, 2012 at 9:17 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Feb 06, 2012 at 09:01:21PM -0800, David Aguilar wrote:
>
>> I have a questions about this. Let's say I have ~/foo1.gitconfig:
>>
>> [foo]
>> bar = 1
>>
>> ...and ~/.gitconfig (I forgot the syntax):
>>
>> [foo]
>> bar = 0
>>
>> #include "~/foo1.gitconfig"
>>
>>
>> Does that mean that:
>>
>> $ git config -f ~/.gitconfig foo.bar
>>
>> ...prints 0 and not 1?
>
> Yes, though the syntax is:
>
> [include]
> path = foo1.gitconfig
>
> (it doesn't respect tilde-expansion, but it probably should). Note that
> the syntax was specifically selected for backwards compatibility, and to
> allow manipulation with existing tools.
>
>> I can see cases where this would be undesirable behavior.
>>
>> For example, an application that uses "git config -z --list -f
>> ~/.gitconfig" might expect that the result encompasses all of the
>> user-specific config bits.
>
> The problem is that an application might also expect it _not_ to happen
> (e.g., if the application is really interested in knowing what's in
> ~/.gitconfig). Because includes aren't respected now, the safe default
> seems to be not to have includes (i.e., don't change behavior for this
> case).
>
> A bigger question for me is: if you are interested in getting an answer
> from anywhere, why are you restricting with "-f"? IOW, is this a
> real-world problem, or a hypothetical one? And if real-world, what is
> the actual use case?
It's a real-world problem. I haven't had to change the code in a
while which is why this thread caught my eye ;-)
I won't claim it's the best solution, but this has worked extremely
well in practice:
https://github.com/git-cola/git-cola/blob/master/cola/gitcfg.py
Here's the problem. I need to know which config items are "user"
config (~/.gitconfig), which are "repo" config (.git/config), and
which are "system" config (/etc/gitconfig).
I also need to avoid calling "git config" too many times so I query
these files once and cache it all in memory. We need only stat()
these files to know whether to redo the "git config" call.
Figuring out the repo config is tricky. You can't just say "git
config --list" because that includes the user config stuff in
~/.gitconfig.
Figuring out the user config is easy because you can say "git config
--global --list". This is inconsistent with the behavior for "git
config --list" because it does not include the --system config, which
one would expect given the overlay semantics.
Figuring out the system config can be done with --system. That works fine.
The generic interface for getting a concise listing of values from
these sources is to use "git config -f" on ~/.gitconfig, .git/config,
and $(prefix)/etc/gitconfig.
git config --global and git config --system are both consistent in
that they return just the information relevant to them. Is --global
just a shortcut for "-f ~/.gitconfig"? If yes, then does that mean
"git config --global" will not honor includes? If it is not a
shortcut, does that mean that "git config --global" and "git config -f
~/.gitconfig" are not really the same thing? The documentation does
lead one to believe that they should be equivalent...
The takeaway is that querying these files provides a convenient way to
access the effective configuration values for the system, user, and
repo.
>> I do know where I would use an `--include` flag (if following includes
>> were not the default behavior when using '-f'), though, and that's why
>> I'm asking. The problem with not having it be the default means we
>> have to use a flag. This makes it harder to support multiple versions
>> of git.
>
> Yes, that's a general problem of adding new command-line options to turn
> features off or on. We could add an environment variable to control this
> feature. But I'd really like to hear the compelling use case first
> (i.e., both why it cannot simply be spelled "git config -z --list", and
> why not following includes is not OK).
Hopefully my explanation conveys why "git config -z --list" is insufficient.
Basically, I've been relying on the fact that querying each of these
files gives me exactly what users have effectively configured.
Pushing knowledge of includes onto the application is less fun.
Applications would either have to understand the [include] path = ...
construct and do something with it themselves or they'd have to check
the git version at runtime.
I would rather do without the runtime version check and have
everything "keep working".
So let's explore why I think it should follow includes. Here are a
few reasons...
When the file format supports including other files then the most
logical thing for it to do is to follow those includes, no? I know,
this is a tautology ;-). I'll try again.
From a naive user's POV --
I am asking "git config" to evaluate this file. I don't care what's
inside of it; it's a black box to me. All I know is that I get config
values out the other side. Sometimes git respects the included files.
Sometimes it does not (when using -f).
^^^^^^^^^
I think this subtle difference in behavior is best avoided.
Here's another. The naive user will do: `git config --list -f file`.
They will then edit that file to add an include statement. They will
then run `git config --list -f file` again and be confused as to why
their included configuration is not honored.
Right now these two are synonymous: "git config --system --list" and
"git config -f $(prefix)/etc/gitconfig --list". Having one form honor
includes and not the other is inconsistent.
What if we frame this the other way around -- when would we not want
it to follow includes? I can imagine someone writing a "git config"
editing program, but I think that use case is rare (and they haven't
spoken up, either ;-).
Well.. okay. My use case is rare too! The dumb "cache the values
behind a stat() call" thing has worked really well in practice so I've
been happy with it so far. It's dumb, and it won't notice when
included files change, but I really don't care because it solves the
99% case.
I'd be happy to rewrite it using another approach. The
overlay-semantics inconsistency is what led me to using the generic
"-f" interface. Performance issues led me to use a stat cache. Using
each file's stat info as the cache key mapped nicely onto the generic
approach of using "-f".
Rewriting it (for me) would mean using --global and --system and
probably not caring so much about the distinction of repo vs. user
configuration (or rather, deal with the fact that `git config --list`
returns both the user config and the repo config). At that point I
might as well just write (reuse) a proper .gitconfig parser, but
what's the fun in that when "git config" is so nice and easy to parse?
;-)
--
David
^ permalink raw reply
* Re: cloning a tree which has detached branch checked out
From: Jakub Narebski @ 2012-02-07 10:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20120207070628.GA24698@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> I have a tree where I checked out a remote, without
> creating a local branch, this detaches the HEAD:
> # git branch
> * (no branch)
> master
> #git log|head -1
> commit cec64082f689f949a397cb9b39423dc41545fa0e
> #git log master..HEAD|head -1
> commit cec64082f689f949a397cb9b39423dc41545fa0e
>
>
> Now if I try to clone it:
> #git clone -n lab:/home/mst/scm/linux
> Initialized empty Git repository in /home/mst/scm/linux/.git/
> remote: Counting objects: 1693446, done.
> remote: Compressing objects: 100% (277054/277054), done.
> Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
> done.
> remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
> Resolving deltas: 100% (1414353/1414353), done.
> error: Trying to write ref HEAD with nonexistant object
> cec64082f689f949a397cb9b39423dc41545fa0e
> fatal: Cannot update the ref 'HEAD'.
>
> Looks like a bug, doesn't it?
Which git version? IIRC there was some bugfix recently in that
area...
--
Jakub Narebski
^ permalink raw reply
* Re: cloning a tree which has detached branch checked out
From: Michael S. Tsirkin @ 2012-02-07 10:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m362fjklb7.fsf@localhost.localdomain>
On Tue, Feb 07, 2012 at 02:08:33AM -0800, Jakub Narebski wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
> > I have a tree where I checked out a remote, without
> > creating a local branch, this detaches the HEAD:
> > # git branch
> > * (no branch)
> > master
> > #git log|head -1
> > commit cec64082f689f949a397cb9b39423dc41545fa0e
> > #git log master..HEAD|head -1
> > commit cec64082f689f949a397cb9b39423dc41545fa0e
> >
> >
> > Now if I try to clone it:
> > #git clone -n lab:/home/mst/scm/linux
> > Initialized empty Git repository in /home/mst/scm/linux/.git/
> > remote: Counting objects: 1693446, done.
> > remote: Compressing objects: 100% (277054/277054), done.
> > Receiving objects: 100% (1693446/1693446), 418.16 MiB | 7.63 MiB/s,
> > done.
> > remote: Total 1693446 (delta 1414353), reused 1681280 (delta 1402358)
> > Resolving deltas: 100% (1414353/1414353), done.
> > error: Trying to write ref HEAD with nonexistant object
> > cec64082f689f949a397cb9b39423dc41545fa0e
> > fatal: Cannot update the ref 'HEAD'.
> >
> > Looks like a bug, doesn't it?
>
> Which git version? IIRC there was some bugfix recently in that
> area...
Sorry, forgot to mention that. It's pretty recent:
$ git --version
git version 1.7.9.111.gf3fb0
> --
> Jakub Narebski
^ permalink raw reply
* Re: User authentication in GIT
From: supadhyay @ 2012-02-07 11:47 UTC (permalink / raw)
To: git
In-Reply-To: <1328595129258-7261349.post@n2.nabble.com>
Hi Robin and Jakub,
Thanks for your reply. But I am still not getting what exactly I need to
perform on GIT server. Please find my reply on your suggestion below:
Robin:
All users must have their own SSH key. You do not create keys for them.
My rely: can you please give some more idea about how it works.. I am not
getting this or if you can provide any link for this to understand.
Jakub:
My reply: existing version control system used pserver protocol.
You would still need for each user to generate their own SSH key.
My reply: Do I need to store all end users sSH key in .ssh/authorized_keys
file on GIT server?
--
View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7262113.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Git documentation at kernel.org
From: Petr Onderka @ 2012-02-07 12:28 UTC (permalink / raw)
To: git
Hi,
since the hacking of kernel.org, the online version of git
documentation [1] is not available. I realize that I can use local
version of the documentation and there is also at least one mirror
[2]. But I think it's very useful to have an "official" version of the
documentation online. And, more importantly, there is now lots of dead
links all over the Internet to the kernel.org version of the
documentation.
Can someone with the ability to do so restore the documentation at the
old location?
Thanks.
Petr Onderka
[1]: http://www.kernel.org/pub/software/scm/git/docs/git.html
[2]: http://schacon.github.com/git/git.html
^ permalink raw reply
* Re: User authentication in GIT
From: compufreak @ 2012-02-07 12:31 UTC (permalink / raw)
To: supadhyay; +Cc: git
In-Reply-To: <1328615262741-7262113.post@n2.nabble.com>
Inline respon
On Tue, Feb 7, 2012 at 12:47 PM, supadhyay <supadhyay@imany.com> wrote:
> Hi Robin and Jakub,
> ...
> Robin:
> All users must have their own SSH key. You do not create keys for them.
> My rely: can you please give some more idea about how it works.. I am not
> getting this or if you can provide any link for this to understand.
SSH authentication can use private/public keys. The user generates a
keypair on their computer and gives you their public key, the private
key stays on their computer.
>
> Jakub:
> My reply: existing version control system used pserver protocol.
>
> You would still need for each user to generate their own SSH key.
> My reply: Do I need to store all end users sSH key in .ssh/authorized_keys
> file on GIT server?
If you were to do it manually, yes. But if you use gitolite [1], then
you add them to another git repository which handles everything for
you.
> --
> View this message in context: http://git.661346.n2.nabble.com/User-authentication-in-GIT-tp7261349p7262113.html
> Sent from the git mailing list archive at Nabble.com.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[1]: https://github.com/sitaramc/gitolite
^ 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