* Re: [PATCH 2/3] base85: No need to initialize the decode table in encode_85
From: Junio C Hamano @ 2010-01-08 15:55 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Andreas Gruenbacher, git
In-Reply-To: <4B475361.60506@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Andreas Gruenbacher venit, vidit, dixit 08.01.2010 14:39:
>> Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
>> ---
>
> For the less informed it may be worthwhile to have an explanation in the
> commit message why encode_85() does not need to initialize the table. (I
> strongly suspect it's a matter of de vs. en, i.e. "because it only
> encodes but does not decode."...)
The title can be reworded to
base85: encode85() does not use the decode table
^ permalink raw reply
* Re: edit Author/Date metadata as part of 'git commit' $EDITOR invocation?
From: Junio C Hamano @ 2010-01-08 16:02 UTC (permalink / raw)
To: Adam Megacz; +Cc: git
In-Reply-To: <xuu28wc9xd42.fsf@nowhere.com>
Adam Megacz <adam@megacz.com> writes:
> I propose instead that "git commit -e" cause the metadata headers to be
> provided to $EDITOR. People who care about the metadata can simply get
> in the habit of always passing that option when invoking "git commit".
That is already done by bb1ae3f (commit: Show committer if automatic,
2008-05-04), so there is no need to propose anything.
I see a bit of room for tightening logic in that ancient commit, though.
^ permalink raw reply
* [PATCH 1/3] ident.c: remove unused variables
From: Junio C Hamano @ 2010-01-08 16:03 UTC (permalink / raw)
To: git; +Cc: Adam Megacz
In-Reply-To: <7vskagh9fg.fsf@alter.siamese.dyndns.org>
d5cc2de (ident.c: Trim hint printed when gecos is empty., 2006-11-28)
reworded the message used as printf() format and dropped "%s" from it;
these two variables that hold the names of GIT_{AUTHOR,COMMITTER}_NAME
environment variables haven't been used since then.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is an independent clean-up
ident.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/ident.c b/ident.c
index 26409b2..e6c1798 100644
--- a/ident.c
+++ b/ident.c
@@ -168,8 +168,6 @@ static int copy(char *buf, size_t size, int offset, const char *src)
return offset;
}
-static const char au_env[] = "GIT_AUTHOR_NAME";
-static const char co_env[] = "GIT_COMMITTER_NAME";
static const char *env_hint =
"\n"
"*** Please tell me who you are.\n"
@@ -204,7 +202,7 @@ const char *fmt_ident(const char *name, const char *email,
if ((warn_on_no_name || error_on_no_name) &&
name == git_default_name && env_hint) {
- fprintf(stderr, env_hint, au_env, co_env);
+ fprintf(stderr, env_hint);
env_hint = NULL; /* warn only once */
}
if (error_on_no_name)
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [PATCH 2/3] ident.c: check explicit identity for name and email separately
From: Junio C Hamano @ 2010-01-08 16:04 UTC (permalink / raw)
To: git, Santi Béjar; +Cc: Adam Megacz
In-Reply-To: <7vskagh9fg.fsf@alter.siamese.dyndns.org>
bb1ae3f (commit: Show committer if automatic, 2008-05-04) added a logic to
check both name and email were given explicitly by the end user, but it
assumed that fmt_ident() is never called before git_default_user_config()
is called, which was fragile. The former calls setup_ident() and fills
the "default" name and email, so the check in the config parser would have
mistakenly said both are given even if only user.name was provided.
Make the logic more robust by keeping track of name and email separately.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit.c | 2 +-
cache.h | 3 +++
config.c | 6 ++----
ident.c | 7 ++++---
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 073fe90..f4974b5 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -624,7 +624,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
author_ident);
free(author_ident);
- if (!user_ident_explicitly_given)
+ if (user_ident_explicitly_given != IDENT_ALL_GIVEN)
fprintf(fp,
"%s"
"# Committer: %s\n",
diff --git a/cache.h b/cache.h
index bf468e5..16c8e8d 100644
--- a/cache.h
+++ b/cache.h
@@ -925,6 +925,9 @@ extern const char *config_exclusive_filename;
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
extern char git_default_name[MAX_GITNAME];
+#define IDENT_NAME_GIVEN 01
+#define IDENT_MAIL_GIVEN 02
+#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
extern int user_ident_explicitly_given;
extern const char *git_commit_encoding;
diff --git a/config.c b/config.c
index 37385ce..fa1a0c0 100644
--- a/config.c
+++ b/config.c
@@ -528,8 +528,7 @@ static int git_default_user_config(const char *var, const char *value)
if (!value)
return config_error_nonbool(var);
strlcpy(git_default_name, value, sizeof(git_default_name));
- if (git_default_email[0])
- user_ident_explicitly_given = 1;
+ user_ident_explicitly_given |= IDENT_NAME_GIVEN;
return 0;
}
@@ -537,8 +536,7 @@ static int git_default_user_config(const char *var, const char *value)
if (!value)
return config_error_nonbool(var);
strlcpy(git_default_email, value, sizeof(git_default_email));
- if (git_default_name[0])
- user_ident_explicitly_given = 1;
+ user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return 0;
}
diff --git a/ident.c b/ident.c
index e6c1798..e67c5ad 100644
--- a/ident.c
+++ b/ident.c
@@ -249,9 +249,10 @@ const char *git_author_info(int flag)
const char *git_committer_info(int flag)
{
- if (getenv("GIT_COMMITTER_NAME") &&
- getenv("GIT_COMMITTER_EMAIL"))
- user_ident_explicitly_given = 1;
+ if (getenv("GIT_COMMITTER_NAME"))
+ user_ident_explicitly_given |= IDENT_NAME_GIVEN;
+ if (getenv("GIT_COMMITTER_EMAIL"))
+ user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
return fmt_ident(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"),
getenv("GIT_COMMITTER_DATE"),
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [RFC PATCH 3/3] ident.c: treat $EMAIL as giving user.email identity explicitly
From: Junio C Hamano @ 2010-01-08 16:08 UTC (permalink / raw)
To: git, Matt Kraai, Pierre Habouzit, Josh Triplett; +Cc: Adam Megacz
In-Reply-To: <7vskagh9fg.fsf@alter.siamese.dyndns.org>
The environment variable EMAIL has been honored since 28a94f8 (Fall back
to $EMAIL for missing GIT_AUTHOR_EMAIL and GIT_COMMITTER_EMAIL,
2007-04-28) as the end-user's wish to use the address as the identity.
When we use it, we should say we are explicitly given email by the user.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is an RFC as some people would feel strongly about _not_ using
$EMAIL as their commit identity and would rather override it explicitly
with user.email; if they weren't told about git using their $EMAIL,
they will complain.
ident.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index e67c5ad..d4f6145 100644
--- a/ident.c
+++ b/ident.c
@@ -85,10 +85,11 @@ static void setup_ident(void)
if (!git_default_email[0]) {
const char *email = getenv("EMAIL");
- if (email && email[0])
+ if (email && email[0]) {
strlcpy(git_default_email, email,
sizeof(git_default_email));
- else {
+ user_ident_explicitly_given |= IDENT_MAIL_GIVEN;
+ } else {
if (!pw)
pw = getpwuid(getuid());
if (!pw)
--
1.6.6.209.g52296.dirty
^ permalink raw reply related
* [PATCH] base85: encode85() does not use the decode table
From: Andreas Gruenbacher @ 2010-01-08 16:17 UTC (permalink / raw)
To: git; +Cc: Andreas Gruenbacher
In-Reply-To: <7v3a2giobm.fsf@alter.siamese.dyndns.org>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
base85.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/base85.c b/base85.c
index 1d165d9..7204ce2 100644
--- a/base85.c
+++ b/base85.c
@@ -84,8 +84,6 @@ int decode_85(char *dst, const char *buffer, int len)
void encode_85(char *buf, const unsigned char *data, int bytes)
{
- prep_base85();
-
say("encode 85");
while (bytes) {
unsigned acc = 0;
--
1.6.6.75.g37bae
^ permalink raw reply related
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 16:24 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jon Schewe, spearce, git
In-Reply-To: <4B4751EA.8060707@drmicha.warpmail.net>
On Fri, Jan 08, 2010 at 04:40:26PM +0100, Michael J Gruber wrote:
> Jon Schewe venit, vidit, dixit 08.01.2010 16:17:
> > If I create a directory "build" at the top of my git repository and then
> > add it to .gitignore, git behaves as expected and ignores the build
> > directory when checking status. Now git-completion.sh has some issues. I
> > have GIT_PS1_SHOWUNTRACKEDFILES to "1", so that I will be notified when
> > there are untracked files in my working directory. When I'm in the
> > top-level directory my prompt looks like expected, no '%'. However if I
> > change to the build directory I get a '%', even though git status shows
> > no untracked files. I see that git-completion.sh is using git ls-files
> > to check this and that function does indeed show output when in my build
> > directory. So the question here: Is git-completion.sh using ls-files
> > improperly or is ls-files behaving improperly?
> >
>
> Neither, but: output between status and ls-files is inconsistent. More
> specifically, different commands behave differently with respect to the
> treatment of subdirs. ls-files assumes "." implicitly, status does not.
> "git status ." should give you the same behavior is "git ls-files" in
> this regard.
It doesn't, and I think there is a bug in ls-files.
Try this:
git init
touch base-cruft
mkdir subdir
touch subdir/cruft
echo subdir >.gitignore
git status ;# shows gitignore and base-cruft
git ls-files -o --exclude-standard ;# ditto
cd subdir
git status . ;# shows nothing, since everything in subdir is ignored
git ls-files -o --exclude-standard ;# BUG: shows cruft
Yes, ls-files operates in the subdirectory, which means it should not
show cruft from the root (and it does not). But it should respect
.gitignore directives going all the way back to the root, and it
doesn't.
-Peff
^ permalink raw reply
* [PATCH] base85: encode_85() does not use the decode table
From: Andreas Gruenbacher @ 2010-01-08 16:22 UTC (permalink / raw)
To: git; +Cc: Andreas Gruenbacher
In-Reply-To: <7v3a2giobm.fsf@alter.siamese.dyndns.org>
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
base85.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/base85.c b/base85.c
index 1d165d9..7204ce2 100644
--- a/base85.c
+++ b/base85.c
@@ -84,8 +84,6 @@ int decode_85(char *dst, const char *buffer, int len)
void encode_85(char *buf, const unsigned char *data, int bytes)
{
- prep_base85();
-
say("encode 85");
while (bytes) {
unsigned acc = 0;
--
1.6.6.75.g37bae
^ permalink raw reply related
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 16:38 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <20100108162404.GA5799@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Try this:
>
> git init
> touch base-cruft
> mkdir subdir
> touch subdir/cruft
> echo subdir >.gitignore
> git status ;# shows gitignore and base-cruft
> git ls-files -o --exclude-standard ;# ditto
> cd subdir
> git status . ;# shows nothing, since everything in subdir is ignored
> git ls-files -o --exclude-standard ;# BUG: shows cruft
>
> Yes, ls-files operates in the subdirectory, which means it should not
> show cruft from the root (and it does not). But it should respect
> .gitignore directives going all the way back to the root, and it
> doesn't.
Shouldn't the ls-files be run from the root with subdir/ as pathspec, if
you wanted to do apples-to-apples comparison between it and status?
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vr5q05z74.fsf@alter.siamese.dyndns.org>
On Fri, Jan 08, 2010 at 08:38:39AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Try this:
> >
> > git init
> > touch base-cruft
> > mkdir subdir
> > touch subdir/cruft
> > echo subdir >.gitignore
> > git status ;# shows gitignore and base-cruft
> > git ls-files -o --exclude-standard ;# ditto
> > cd subdir
> > git status . ;# shows nothing, since everything in subdir is ignored
> > git ls-files -o --exclude-standard ;# BUG: shows cruft
> >
> > Yes, ls-files operates in the subdirectory, which means it should not
> > show cruft from the root (and it does not). But it should respect
> > .gitignore directives going all the way back to the root, and it
> > doesn't.
>
> Shouldn't the ls-files be run from the root with subdir/ as pathspec, if
> you wanted to do apples-to-apples comparison between it and status?
Well, yes, if you wanted to compare apples to apples. But actually, my
point in showing "status" at all was to note that Michael's statement
that they would be the same is wrong.
But just looking at the ls-files output, do you not agree that there is
a bug? Respecting gitignore means respecting _all_ gitignore files in
the repository, not just the subset that you happen to be in.
-Peff
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 16:45 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <20100108164132.GA6171@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Well, yes, if you wanted to compare apples to apples. But actually, my
> point in showing "status" at all was to note that Michael's statement
> that they would be the same is wrong.
>
> But just looking at the ls-files output, do you not agree that there is
> a bug?
If I agreed, I wouldn't have suggested _you_ to cd up and use pathspec,
but instead would have suggested to patch ls-files to make it do so for
you.
You can see it as a feature that you can use to check what would happen
if you stopped ignoring the directory from the higher level. With a patch
to always cd-up and use pathspec, that will become impossible.
Maybe nobody needs such a feature (I don't), in which case we can declare
it as a bug. But I wasn't ready to do so myself when I wrote the message
you are responding to, and I still am not.
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 16:56 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vskag1r5o.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> You can see it as a feature that you can use to check what would happen
> if you stopped ignoring the directory from the higher level. With a patch
> to always cd-up and use pathspec, that will become impossible.
I hate to say this, but I have a feeling that status might be what needs
to be fixed instead. It isn't hard to imagine a use case where you don't
want to be bothered by crufts in lower level directories when you are
looking at the bigger picture (e.g. at the top of the hierarchy) but when
you go to individual subdirectory you would want to see them.
^ permalink raw reply
* Linking multiple Git repositories for version tracking
From: James Beck @ 2010-01-08 17:03 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <op.u573txvdn3qeew@klee>
Hi,
I'm developing firmware that is composed of multiple projects. Each
section of the firmware has it's own git repository (each section
correlates to a physical processor). But the firmware as a whole is
getting to the point where I have to remember which version of Firmware A
is compatible with Firmware B. If I add a feature to B that requires some
tweaks in A, I need to know that both A v3.04 and B v2.7 need to be used
together.
I'm starting to move into alpha with this code, so I really need to have a
system that keeps track of compatible firmware versions. The best I can
come up with is a plain text file (or Excel spreadsheet) that lists the
overall firmware version, and the Git hash for each individual project.
That way, if I want to load up a particular firmware version, I can
checkout each hash for that version. Seems foolproof, but not terribly
easy, and somewhat annoying.
I know submodules might be used, but it's not super obvious how to make
their paradigm work nicely here. (You check out a version you want, and
then list all the submodule git hashes for that version? What happens if
one hash needs updating? Do you branch it?) It seems more complicated than
I'd like.
But this can't be a problem that only I have. What have you done to keep
track of software bundle versions?
Thanks!
James
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vskag1r5o.fsf@alter.siamese.dyndns.org>
On Fri, Jan 08, 2010 at 08:45:55AM -0800, Junio C Hamano wrote:
> > But just looking at the ls-files output, do you not agree that there is
> > a bug?
>
> If I agreed, I wouldn't have suggested _you_ to cd up and use pathspec,
> but instead would have suggested to patch ls-files to make it do so for
> you.
Ah, I missed the subtlety there.
> You can see it as a feature that you can use to check what would happen
> if you stopped ignoring the directory from the higher level. With a patch
> to always cd-up and use pathspec, that will become impossible.
>
> Maybe nobody needs such a feature (I don't), in which case we can declare
> it as a bug. But I wasn't ready to do so myself when I wrote the message
> you are responding to, and I still am not.
That feature seems somewhat insane to me. If I wanted to know how things
would look without gitignore, I would not have said --exclude-standard.
However, I was wrong before that it ignores .gitignore. It doesn't. If
you put "cruft" instead of "subdir" into gitignore in my previous
example, it is correctly ignored. So it is sort of a "half-use
gitignore", which you cannot accomplish any other way.
I still think it's a bit crazy to have as the default behavior. But at
least it's constrained to a plumbing command, which scripts can work
around to get what they want. With the current behavior, that means the
bash prompt code should be doing "git rev-parse --show-cdup --show-prefix"
and moving to the toplevel.
-Peff
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Jeff King @ 2010-01-08 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vaawosfg9.fsf@alter.siamese.dyndns.org>
On Fri, Jan 08, 2010 at 08:56:38AM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > You can see it as a feature that you can use to check what would happen
> > if you stopped ignoring the directory from the higher level. With a patch
> > to always cd-up and use pathspec, that will become impossible.
>
> I hate to say this, but I have a feeling that status might be what needs
> to be fixed instead. It isn't hard to imagine a use case where you don't
> want to be bothered by crufts in lower level directories when you are
> looking at the bigger picture (e.g. at the top of the hierarchy) but when
> you go to individual subdirectory you would want to see them.
For people who have status.relativepaths off, status is still a global
command. So I would hope that behavior would come out only when doing
"git status .", or at the very least be disabled if status.relativepaths
is set.
Personally, I think having ignored files show up as untracked based on
heuristics like cwd is just going to end up confusing people.
-Peff
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 18:21 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7vskag1r5o.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> Well, yes, if you wanted to compare apples to apples. But actually, my
>> point in showing "status" at all was to note that Michael's statement
>> that they would be the same is wrong.
>>
>> But just looking at the ls-files output, do you not agree that there is
>> a bug?
>
> If I agreed, I wouldn't have suggested _you_ to cd up and use pathspec,
> but instead would have suggested to patch ls-files to make it do so for
> you.
Nah, I should have checked the code.
The implementation of ls-files does cd up and uses pathspec, so the intent
is to apply higher level gitignore.
It however feeds paths from the already ignored directories, which _is_
the real bug.
For example, if you have
.gitignore (ignores t/)
t/
t/junk
in your work tree, it will read .gitignore at the top level, and
eventually end up feeding "t/junk" to dir.c::excluded_1(), which does:
for (i = el->nr - 1; 0 <= i; i--) {
struct exclude *x = el->excludes[i];
const char *exclude = x->pattern;
int to_exclude = x->to_exclude;
if (x->flags & EXC_FLAG_MUSTBEDIR) {
if (*dtype == DT_UNKNOWN)
*dtype = get_dtype(NULL, pathname, pathlen);
if (*dtype != DT_DIR)
continue;
}
...
where *x has "'t/' that must be directory". but the path "t/junk" does
not match with "t/" and is not excluded by this rule; this part notices
"t/junk" is not a directory, and continues without giving the later part a
chance to intervene. Of course, the later part also is not prepared to do
a "leading path" match, as the function is not meant to be fed entries
from ignored "t/" directory in the first place.
I think a proper fix should be in dir.c::read_directory() where it calls
read_directory_recursive() without first checking if the directory itself
should be ignored. read_directory_recursive() itself has a logic to see
if the dirent it found is worth recursing into and a similar logic should
be in the toplevel caller.
^ permalink raw reply
* Re: Linking multiple Git repositories for version tracking
From: Avery Pennarun @ 2010-01-08 18:34 UTC (permalink / raw)
To: James Beck; +Cc: git@vger.kernel.org
In-Reply-To: <op.u574cwxqn3qeew@klee>
On Fri, Jan 8, 2010 at 12:03 PM, James Beck <james@jmbeck.com> wrote:
> I'm developing firmware that is composed of multiple projects. Each
> section of the firmware has it's own git repository (each section
> correlates to a physical processor). But the firmware as a whole is
> getting to the point where I have to remember which version of Firmware A
> is compatible with Firmware B. If I add a feature to B that requires some
> tweaks in A, I need to know that both A v3.04 and B v2.7 need to be used
> together.
>
> I'm starting to move into alpha with this code, so I really need to have a
> system that keeps track of compatible firmware versions. The best I can
> come up with is a plain text file (or Excel spreadsheet) that lists the
> overall firmware version, and the Git hash for each individual project.
> That way, if I want to load up a particular firmware version, I can
> checkout each hash for that version. Seems foolproof, but not terribly
> easy, and somewhat annoying.
>
> I know submodules might be used, but it's not super obvious how to make
> their paradigm work nicely here. (You check out a version you want, and
> then list all the submodule git hashes for that version? What happens if
> one hash needs updating? Do you branch it?) It seems more complicated than
> I'd like.
This seems like exactly what submodules were designed to do.
1. create a "superproject" for each physical product
2. use submodules to link to the right firmware versions for that product
3. when you make a new release of that physical product, update the
firmware links.
4. when someone wants to check out a particular version of the
product, they retrieve the product's repo and ask git submodule to
checkout the submodules.
Which part is not working for you?
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Document git-blame triple -C option
From: Ramkumar Ramachandra @ 2010-01-08 18:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B47510E.7040802@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 592 bytes --]
> Above you see why it is difficult to comment on attached patches.
> They're not included!
I'm sorry, but I'm behind a HTTP proxy, and GMail mangles up patches.
I'm left with no choice but to attach the patches.
> You re-wrapped the existing documentation. Please don't do that, because
> it makes it difficult to spot what you really changed.
Okay. Corrected.
> It seems you added one sentence. Please don't use "thrice" for "three
> times", that is very old English and sounds funny.
Okay. I've also modified the second line (what happens when the option
is given twice) for clarity.
[-- Attachment #2: 0001-Document-git-blame-triple-C-option.patch --]
[-- Type: text/x-patch, Size: 1892 bytes --]
From 371705f64576ff7b8dc82bea19c714ce320097b9 Mon Sep 17 00:00:00 2001
From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sat, 9 Jan 2010 00:18:07 +0530
Subject: [PATCH v2] Document git-blame triple -C option
git-blame -CCC is explained in builin-blame.c line 2171, but is
unexplained in the documentation. This patch fixes that.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/blame-options.txt | 6 ++++--
Documentation/git-blame.txt | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 1625ffc..4833cac 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -98,8 +98,10 @@ commit.
files that were modified in the same commit. This is
useful when you reorganize your program and move code
around across files. When this option is given twice,
- the command additionally looks for copies from all other
- files in the parent for the commit that creates the file.
+ the command additionally looks for copies from other
+ files in the commit that creates the file. When this
+ option is given three times, the command additionally
+ looks for copies from other files in any commit.
+
<num> is optional but it is the lower bound on the number of
alphanumeric characters that git must detect as moving
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
index 8c7b7b0..b786471 100644
--- a/Documentation/git-blame.txt
+++ b/Documentation/git-blame.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
- [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
+ [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[<rev> | --contents <file> | --reverse <rev>] [--] <file>
DESCRIPTION
--
1.6.5
^ permalink raw reply related
* Re: Difference between pull --rebase and fetch+rebase
From: martinvz @ 2010-01-08 19:41 UTC (permalink / raw)
To: git
In-Reply-To: <adf1fd3d1001080305k138a2670k17a126cc0b8430b8@mail.gmail.com>
Santi Béjar-2 wrote:
>
> Yes, it is. The code expects that you always branch your topic
> branches from the upstream branch, so all the possible fork points are
> in the reflog. Your flow was to create the topic from a local commit
> and then push that commit.
>
Thanks, Santi! After thinking for a while about what you said, I think I
understand. That could definitely be what I did, although I can't remember
for sure.
Would it make sense to teach "git rebase" the same tricks as "git pull
--rebase"?
Santi Béjar-2 wrote:
>
> By the way, when Git tries to apply these two commits it should detect
> that they are already applied so it should do nothing, isn't it?
>
Almost - it fails, but the merge tool resolves it automatically.
Martin
--
View this message in context: http://n2.nabble.com/Difference-between-pull-rebase-and-fetch-rebase-tp4266164p4274470.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git-log - hide parent (was: merging two equivalent branches)
From: Avery Pennarun @ 2010-01-08 19:50 UTC (permalink / raw)
To: David Reitter; +Cc: git, Christian MICHON
In-Reply-To: <DF05F91F-CBFD-458A-A99F-79E98ACA5146@gmail.com>
On Thu, Jan 7, 2010 at 4:16 PM, David Reitter <david.reitter@gmail.com> wrote:
> I'm still unsure how, after the filter-branch, I would have some ancestor from the
> B series so that future pulls from the remote work, while having an ancestor from
> A, to make sure I can continue merging into C. If history is rewritten, I'll get new
> revisions and lose ancestors.
> I'm beginning to thing that the cutting and pasting I'd like is conceptually impossible.
Hmm, this is pretty nasty. Essentially, you want your repo to include
both sets of commits (so that it doesn't try to re-merge in the other
commits later), but you don't want to *see* them in git log.
Basically, you want git log to lie to you :)
Luckily, it already has this ability: it's called history simplification :)
Try this in your merged repo:
git log .
(note the '.').
Without the dot, git log doesn't simplify any history, and you get
every change. With the dot, it shows only commits that had a tangible
effect on the file in question (in this case, the top directory, which
includes *everything*). Thus, a "git merge -s ours" gets eliminated.
Beware that it might eliminate other equally non-impactful commits, however.
The same trick also works with gitk.
Have fun,
Avery
^ permalink raw reply
* Re: Possible bug in git-completion.sh
From: Junio C Hamano @ 2010-01-08 19:58 UTC (permalink / raw)
To: Jeff King, Linus Torvalds; +Cc: Michael J Gruber, Jon Schewe, spearce, git
In-Reply-To: <7v8wc8jw3k.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nah, I should have checked the code.
>
> The implementation of ls-files does cd up and uses pathspec, so the intent
> is to apply higher level gitignore.
>
> It however feeds paths from the already ignored directories, which _is_
> the real bug.
> ...
> I think a proper fix should be in dir.c::read_directory() where it calls
> read_directory_recursive() without first checking if the directory itself
> should be ignored. read_directory_recursive() itself has a logic to see
> if the dirent it found is worth recursing into and a similar logic should
> be in the toplevel caller.
Actually doing less in fill_directory() turned out to be a simpler
solution.
builtin_add() cares about the return value from fill_directory() and
performs prune_directory() optimization magic, and we may want to change
it not to do so as well, but I didn't want to worry about too many things
at once, so this version still runs the "common_prefix()" that forgets to
take .gitignore at higher levels (or a $GIT_DIR/info/exclude entry that
ignores the common prefix directory of given pathspecs) into account.
Another possibility is to fix common_prefix() and make it walk the path it
returns one level at a time from the top, making sure they are not
ignored, and that would probably be a better fix, but at least this patch
will give you a starting point and tests to check the result against.
diff --git a/dir.c b/dir.c
index d0999ba..56d3f60 100644
--- a/dir.c
+++ b/dir.c
@@ -53,7 +53,6 @@ static int common_prefix(const char **pathspec)
int fill_directory(struct dir_struct *dir, const char **pathspec)
{
- const char *path;
int len;
/*
@@ -61,13 +60,8 @@ int fill_directory(struct dir_struct *dir, const char **pathspec)
* use that to optimize the directory walk
*/
len = common_prefix(pathspec);
- path = "";
-
- if (len)
- path = xmemdupz(*pathspec, len);
-
/* Read the directory and prune it */
- read_directory(dir, path, len, pathspec);
+ read_directory(dir, "", 0, pathspec);
return len;
}
diff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh
index c65bca8..17d1764 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -153,4 +153,42 @@ test_expect_success 'negated exclude matches can override previous ones' '
grep "^a.1" output
'
+test_expect_success 'subdirectory ignore (setup)' '
+ mkdir -p top/l1/l2 &&
+ (
+ cd top &&
+ git init &&
+ echo /.gitignore >.gitignore &&
+ echo l1 >>.gitignore &&
+ echo l2 >l1/.gitignore
+ )
+'
+
+test_expect_success 'subdirectory ignore (toplevel)' '
+ (
+ cd top &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'subdirectory ignore (l1/l2)' '
+ (
+ cd top/l1/l2 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
+test_expect_success 'subdirectory ignore (l1)' '
+ (
+ cd top/l1 &&
+ git ls-files -o --exclude-standard
+ ) >actual &&
+ >expect &&
+ test_cmp expect actual
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Avery Pennarun @ 2010-01-08 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <7vtyux3bx1.fsf@alter.siamese.dyndns.org>
2010/1/7 Junio C Hamano <gitster@pobox.com>:
> I am a bit unhappy about the duplication. The text of this function is
> different from the one in "rebase" proper, but they implement essentially
> the same logic. I was tempted to suggest having a common helper function,
> but as Dscho mentioned "rebase -i" implementation does not share much with
> "rebase" (even though it shares the external command line interface from
> the end user's point of view), and I don't see a readily available place
> (other than in git-sh-setup) to do so.
Is there a reason that non-interactive rebase can't just be
implemented as "git rebase -i" but without actually launching an
editor to edit the commit list?
This would resolve any other inconsistencies between the two as well,
notably that non-interactive rebase sometimes refuses to do the rebase
I requested because "Current branch master is up to date," while
interactive rebase is willing to do it. (Personally I prefer the
latter behaviour, since I don't like tools that think they're smarter
than me :))
Avery
^ permalink raw reply
* Re: [PATCH (v2) 2/2] rebase -i: teach --onto A...B syntax
From: Sverre Rabbelier @ 2010-01-08 20:22 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <32541b131001081216p27d7e29bu269755db895128@mail.gmail.com>
Heya,
On Fri, Jan 8, 2010 at 15:16, Avery Pennarun <apenwarr@gmail.com> wrote:
> This would resolve any other inconsistencies between the two as well,
> notably that non-interactive rebase sometimes refuses to do the rebase
> I requested because "Current branch master is up to date," while
> interactive rebase is willing to do it. (Personally I prefer the
> latter behaviour, since I don't like tools that think they're smarter
> than me :))
I taught rebase the -f|--force-rebase flag a little while back, you
could use that :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* ssh username environment variable
From: Chris Packham @ 2010-01-08 20:24 UTC (permalink / raw)
To: git
Hi List,
Just wondering if there is an environment variable I can use to tell
git or ssh what user name to use for the ssh transport?
I would normally use
git clone ssh://myname@example.com/repo.git
but I'm cloning to a relatively public network drive (corporate
overlords don't want git no mater what I say) so I want to do
something like
GIT_SSH_USER=myname git clone ssh://example.com/repo.git
So that my user name doesn't show in the resulting remote.origin.url
I know I can probably just remove my user name from the config after
the the fact but I have to do this for a few repos so I thought I'd
ask if there was a magic environment variable I could set.
Thanks.
^ permalink raw reply
* Re: ssh username environment variable
From: Shawn O. Pearce @ 2010-01-08 20:29 UTC (permalink / raw)
To: Chris Packham; +Cc: git
In-Reply-To: <a038bef51001081224l33164526y51e5ca064b82b73a@mail.gmail.com>
Chris Packham <judge.packham@gmail.com> wrote:
> Just wondering if there is an environment variable I can use to tell
> git or ssh what user name to use for the ssh transport?
No. But you can hack around it:
cat >$HOME/bin/git-ssh
#!/bin/sh
ssh -l $GIT_SSH_USER "$@"
^D
GIT_SSH=$HOME/bin/git-ssh GIT_SSH_USER=myname git clone ...
--
Shawn.
^ 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