* 'push origin master' takes over 8 minutes (local ssh)
From: Yakov Lerner @ 2007-07-14 13:00 UTC (permalink / raw)
To: Git Mailing List
Something happened to the repo, and 'push origin master'
is taking now very long time: > 8 minutes (this is ssh to localhost).
It's in git-pack-objects.
The git-pack-objects sits there for >8 minutes using very low cpu (<1 %)
but lots of RAM (>300MB). Then it bombs with malloc error.
I could add swap to the machine [1], but this long time with
low cpu usage is suspicious, no ?
Repo counters are below [2]
I suspect one file, history of which accumulated thousands commits
from the script. I'd like to erase the history of this file but I don't know
how. And I don't know where there is a connection.
Yakov
[1] This is vps machine that hasb 128MB ram + 256MB swap.
[2] Repo counters.
- the master repo which is being pushed to (it is bare, the "master" repo):
count: 653
size: 140692
in-pack: 21730
packs: 2
prune-packable: 5
garbage: 0
the repo which does the push:
count: 369
size: 42960
in-pack: 22145
packs: 4
prune-packable: 9
garbage: 0
Don't ask me about workflow.
I synchronize files between four hosts using git.
I beleive this is very unusual workflow. No branches.
^ permalink raw reply
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Johannes Schindelin @ 2007-07-14 12:49 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <11842671631635-git-send-email-skimo@liacs.nl>
Hi,
On Thu, 12 Jul 2007, skimo@liacs.nl wrote:
> +SYNOPSIS
> +--------
> +'git-rewrite-commits' [--index-filter <command>] [--commit-filter <command>]
> + [<rev-list options>...]
--write-sha1-mappings is missing.
> +Filters
> +~~~~~~~
> +
> +The filters are applied in the order as listed below. The <command>
> +argument is run as "sh -c '<command'>", with the $GIT_COMMIT
> +environment variable set to the commit that is being rewritten.
> +If any call to a filter fails, then git-rewrite-commits will abort.
Here you should note that a couple of helper functions are defined for
ease of use.
> +--write-sha1-mapping
> + Write mapping of old SHA1s to new SHA1s for use in filters.
Where? How to use it?
> +<rev-list-options>::
> + Selects the commits to be rewritten, defaulting to the history
> + that lead to HEAD.
s/the history that lead to HEAD/the current branch/
> +Examples
> +--------
> +
> +Suppose you want to remove a file (containing confidential information
> +or copyright violation) from all commits:
> +
> +----------------------------------------------------------------------------
> +git rewrite-commits --index-filter 'git update-index --remove filename || :'
We seem to prefer "$ git" instead of just "git" in the other man pages'
examples.
> +----------------------------------------------------------------------------
> +
> +Now, you will get the rewritten history saved in your current branch
> +(the old branch is saved in refs/original).
The "|| :" construct
+ prevents the filter to fail when the given file was not present in the
+ index.
> +To move the whole tree into a subdirectory, or remove it from there:
> +
> +---------------------------------------------------------------
> +git rewrite-commits --index-filter \
> + 'git ls-files -s | sed "s-\t-&newsubdir/-" |
> + GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
> + git update-index --index-info &&
> + mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE'
> +---------------------------------------------------------------
I imagine that this should be replaced (later! in a different patch!) by
either --subdir-filter, or by a shell helper function.
> +#include "grep.h"
I did not compile test, but do you really need that?
> +struct decoration rewrite_decoration = { "rewritten as" };
> [...]
> +
> +struct rewrite_decoration {
> + struct rewrite_decoration *next;
> + unsigned char sha1[20];
> +};
I wonder why you give the instance of a "struct decoration" the same name
as that of a _different_ struct. IOW it is confusing that there is a
"struct rewrite_decoration", but the variable "rewrite_decoration" is no
instance of that struct.
> +static void add_rewrite_decoration(struct object *obj, unsigned char *sha1)
Why "struct object *"? You only rewrite commits. Which makes me suspect
that your "struct rewrite_decoration" should be a "struct commit_list" to
begin with.
> +static char *add_parents(char *dest, struct commit_list *parents)
Since one commit can be rewritten to multiple commits now, you do not know
how much space you need to add the parents. Thus you should take a buf_p
and a space_p, and use ALLOC_GROW() to grow the buffer as needed.
> +static int skip_one_line(char **buf_p, unsigned long *len_p)
Better rename get_one_line to get_line_length and export it, avoiding code
duplication. I have an upcoming patch series adding commit notes, which
has that patch.
Besides, you do not _skip_ that line. You use the line, but advance
*buf_p before doing so.
> +static char *filter_index(char *orig_hex, struct commit *commit)
const char *, in both cases. You do not plan to modify orig_hex, and you
return a sha1_to_hex() buffer, which you also do not plan to modify.
> +{
> + int argc;
> + const char *argv[10];
> + static char index_env[16+PATH_MAX];
Style: "16 + PATH_MAX". That happens elsewhere, too.
> +/* Replace any (short) sha1 of a rewritten commit by the new (short) sha1 */
> +static char *rewrite_body(char *dest, unsigned long len, char *buf)
> +{
> + unsigned char sha1[20];
> +
> + while (len) {
> + size_t ll = non_hex_len(buf, len);
> + memcpy(dest, buf, ll);
> + dest += ll;
> + buf += ll;
> + len -= ll;
Why not make it simpler?
while (!ishex(buf[i]))
dest[i] = buf[i++];
> + ll = hex_len(buf, len);
It is really shorter (because you spare the whole hex_len() function, to
say
for (ll = 0; i + ll < len && ishex(buf[i + ll]); ll++)
; /* do nothing */
> + if (ll >= 8 && ll <= 40 &&
AFAICT our abbreviation allows for 4 characters and up. Default
abbreviation is 7, IIRC.
> + !get_short_sha1(buf, ll, sha1, 1) &&
> + !get_rewritten_sha1(sha1))
> + memcpy(dest, sha1_to_hex(sha1), ll);
> + else
> + memcpy(dest, buf, ll);
What do you do if the rewritten sha1, truncated to ll characters, is
ambiguous? Wouldn't you need more than
> +static int is_ref_to_be_rewritten(const char *ref)
> +{
> + unsigned char sha1[20];
> + int flag;
> +
> + if (prefixcmp(ref, "refs/"))
> + return 0;
> + if (!prefixcmp(ref, "refs/remotes/"))
> + return 0;
> + if (!prefixcmp(ref+5, original_prefix))
Should original_prefix not be "refs/original", then?
> +static int is_pruned(struct commit *commit, int path_pruning)
> +{
> + if (commit->object.flags & PRUNED)
> + return 1;
Hmm. I thought about changing get_revision_1() to mark that commit as
uninteresting, since the parents were already added. But I guess this has
too much side effect potential.
In any case, I think that "NO_MATCH" would be a more descriptive name.
> + if (path_pruning &&
> + !(commit->object.flags & (TREECHANGE | UNINTERESTING)))
> + return 1;
Why only with "path_pruning"? Ah yes. Because otherwise, you would
assume "A" in "A..B" to be pruned. But what do you do if someone says
git rewrite-commits A.. x/y
because she wants _only_ commits later than A rewritten, but everything
from A backwards kept as-is?
If I understand your code correctly, the given command would cut off the
history at A.
I wonder why you bother at all: my impression was that the revisions you
want to filter out here were already filtered out by
revision.c:rewrite_parents()...
> +static void rewrite_sha1(struct object *obj, unsigned char *new_sha1)
> +{
> + if (!hashcmp(obj->sha1, new_sha1))
> + return;
> +
> + add_rewrite_decoration(obj, new_sha1);
This is not so much "rewrite_sha1", as "append_rewritten_sha1", right?
> +/*
> + * Replace any parent that has been removed by its parents
> + * and return the number of new parents.
> + * We directly modify the parent list, so any libification
> + * should probably adapt this function.
I do not think that this code will be libified any time soon.
> +static int rewrite_parents(struct commit *commit, int path_pruning)
Of course, you could always pass a "struct commit_list
**rewritten_parents_p" to this function.
> + get_rewritten_sha1(sha1);
> + if (!is_null_sha1(sha1)) {
> + hashclr(sha1);
> + rewrite_sha1(&list->item->object, sha1);
I guess you'll admit that it is unintuitive to read
"get_rewritten_sha1(sha1); rewrite_sha1(o, sha1);". I thought: "What?
Again?" IMHO that is a strong hint that "rewrite_sha1" is not an apt name
for that function.
> +static int rewrite_ref(const char *refname, const unsigned char *sha1,
> + int flags, void *cb_data)
> +{
> + int prefix_len;
> + int len;
> + char buffer[256], *p;
> + struct object *obj = parse_object(sha1);
> + unsigned char new_sha1[20];
> + struct commit *commit;
> + int pruned;
> +
> + if (!obj)
> + return 0;
> + if (obj->type == OBJ_TAG)
Speaking of tags... We will have to add (in a separate patch, to keep
things reviewable) a method to rewrite them, too.
> + if (!is_ref_to_be_rewritten(refname))
> + return 0;
Hmm. When looking at that code, I wonder if
git rewrite-commits A..B
will rewrite C, too, if it happens to lie in A..B. That would be not
brilliant.
I guess you will need to copy the positive refs in revs->pending, if there
are any, and later _not_ call for_each_ref if that list was empty.
> + commit = lookup_commit_reference(sha1);
> + pruned = is_pruned(commit, !!cb_data);
> +
> + hashcpy(new_sha1, sha1);
> + if (!pruned && get_rewritten_sha1(new_sha1))
> + return 0;
So if pruned == 1, you _do_ rewrite it? I'm not quite sure. Care to
explain?
> +static void filter_and_write_commit(char *commit_body, size_t len,
> + struct commit *commit, unsigned char *sha1)
> +{
> + char commit_path[PATH_MAX];
> + struct child_process cmd;
> + int argc;
> + const char *argv[10];
> + int fd;
> + const char *env[] = { commit_env, NULL };
> + char hex[41];
> + struct commit_list *list = NULL, **end = &list;
> +
> + memcpy(commit_env+sizeof(commit_env)-41,
> + sha1_to_hex(commit->object.sha1), 40);
> +
> + fd = git_mkstemp(commit_path, sizeof(commit_path), ".commit_XXXXXX");;
> + write_or_die(fd, commit_body, len);
> +
> + argc = 0;
> + argv[argc++] = "sh";
> + argv[argc++] = "-c";
> + argv[argc++] = commit_filter;
> + argv[argc] = NULL;
> + memset(&cmd, 0, sizeof(cmd));
> + cmd.in = open(commit_path, O_RDONLY);
> + if (cmd.in < 0)
> + die("Unable to read commit from file '%s'", commit_path);
> + unlink(commit_path);
This will fail on Windows. You do not catch that error, so it is almost
fine: just put the file into rewrite_dir, so the leftovers will be removed
later anyway.
> + hashclr(sha1);
> + commit->object.flags |= PRUNED;
> + /*
> + * If the filter returns two or more commits,
> + * we consider the original commit to have been
> + * removed and put the list in the old commit's
> + * parent list so that all the old commit's children
> + * will copy them.
> + */
> + if (list) {
> + free_commit_list(commit->parents);
> + commit->parents = list;
> + } else
> + add_sha1_map(commit->object.sha1, NULL);
That is almost certainly wrong. If you step away from the notion that
get_rewritten_sha1() returns _one_ SHA-1, all will become clearer. And
the filters should know about them SHA-1s, too.
> + /* Make enough remove for n (possibly extra) parents */
> + p = buf = xmalloc(orig_len + n*48);
As stated above, I'd prefer ALLOC_GROW().
> + p = rewrite_header(p, &orig_len, &orig_buf, commit);
> + p = rewrite_body(p, orig_len, orig_buf);
> + if (!commit_filter) {
> + if (write_sha1_file(buf, p-buf, commit_type, sha1))
> + die("Unable to write new commit");
> + add_sha1_map(commit->object.sha1, sha1);
> + } else
> + filter_and_write_commit(buf, p-buf, commit, sha1);
> + free(buf);
You can really discard the commit->buffer, too, no?
> +
> + rewrite_sha1(&commit->object, sha1);
> +}
> +static char aux_functions[] =
> +"export GIT_REWRITE_DIR=`pwd`\n"
Better put the correct absolute path there.
> +"commit()\n"
> +"{\n"
> +" git-hash-object -w -t commit --stdin\n"
> +"}\n"
> +"map()\n"
> +"{\n"
> +" # if it was not rewritten, take the original\n"
> +" if test -r \"$GIT_REWRITE_DIR/map/$1\"\n"
> +" then\n"
> +" cat \"$GIT_REWRITE_DIR/map/$1\"\n"
> +" else\n"
> +" echo \"$1\"\n"
> +" fi\n"
> +"}\n"
> +"cd t\n";
Then you do not need this extra fork() and cd all the time the filters
source the helper file.
You do not even need the one static global buffer, if you put that script
into the function writing it, inside an fprintf() call.
> +static char filter_prefix[] = ". aux;";
And here, I'd put the absolute path, too.
> +static char *create_filter(const char *command)
> +{
> + int prefix_len = sizeof(filter_prefix)-1;
> + int command_len = strlen(command);
> + char *filter = xmalloc(prefix_len + command_len + 1);
> +
> + memcpy(filter, filter_prefix, prefix_len);
> + memcpy(filter+prefix_len, command, command_len+1);
> + return filter;
> +}
I really like that approach. This makes it so much more convenient for
users.
> +static void setup_temp_dir()
> +{
> + int aux;
> +
> + absolute_git_dir = create_absolute_path(get_git_dir());
> + setenv(GIT_DIR_ENVIRONMENT, absolute_git_dir, 1);
> +
> + if (!rewrite_dir) {
> + rewrite_dir = xstrdup(git_path("rewrite"));
I might read the code wrong, but this does not guarantee that rewrite_dir
is an absolute path, right?
> + if (mkdir(mkpath("%s/map", rewrite_dir), 0777))
> + die("unable to create map directory '%s/map'", rewrite_dir);
Maybe make this dependent on --write-sha1-mappings, and have a check in
"map ()"?
> + if (index_filter || commit_filter)
> + setup_temp_dir();
> + else
> + /* They'll never know. BWUHAHA */
> + write_sha1_mapping = 0;
I like the comment ;-)
> + prepare_revision_walk(&rev);
> + while ((commit = get_revision(&rev)) != NULL) {
> + rewrite_commit(commit, !!rev.prune_fn);
> + }
Please lose the curly brackets for single lines; otherwise it would look
too perl like.
> + rm_rf(git_path("refs/%s", original_prefix));
Would it not be better to move refs/original to refs/original/original?
Pooh. A lot of comments. Please take that as a sign that I am interested
in rewrite-commits. BTW did I mention already that I like the name
"rewrite-commits"?
Ciao,
Dscho
^ permalink raw reply
* Re: Restoring files from old commits
From: martin f krafft @ 2007-07-14 12:37 UTC (permalink / raw)
To: git-list
In-Reply-To: <4698BD17.5080205@random-state.net>
[-- Attachment #1: Type: text/plain, Size: 644 bytes --]
also sprach Nikodemus Siivola <nikodemus@random-state.net> [2007.07.14.1409 +0200]:
> What is the recommended way to restore individual files
> (or directories) in the working tree to the content they
> had in a given commit?
As per my comment on IRC, I think
git checkout <tree-ish> <path>
is the way.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"the difference between genius and stupidity
is that genius has it's limits."
-- albert einstein
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Restoring files from old commits
From: Nikodemus Siivola @ 2007-07-14 12:09 UTC (permalink / raw)
To: git-list
What is the recommended way to restore individual files
(or directories) in the working tree to the content they
had in a given commit?
That is to say, now that Cogito is deprecated, what should
I use instead of cg-restore?
Cheers,
-- Nikodemus
^ permalink raw reply
* Re: [PATCH] git-svn init/clone --stdlayout option to default-init trunk/tags/branches
From: martin f krafft @ 2007-07-14 12:04 UTC (permalink / raw)
To: git
In-Reply-To: <20070714113435.GC14842@muzzle>
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
also sprach Eric Wong <normalperson@yhbt.net> [2007.07.14.1334 +0200]:
> I have highlighting search set in my editor (vim :set hls)
> and usually just search for spaces vs tabs to make sure I'm clean.
Try:
:se lcs=tab:>-,trail,-
augroup listinsert
autocmd InsertEnter * set nolist
autocmd InsertLeave * set list
augroup end
> Of course, maintaining a consistent whitespace style helps a *lot*
> with the git/Linux patch exchange development style because it
> avoids needless patch application conflicts that arise from
> whitespace differences.
Using tabs also makes it impossible to X-cut-paste patches from
emails; you *have* to use git-am and/or a temporary file, which
i don't like at all.
But thanks for the explanation.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
Most Intelligent Customers Realise Our Software Only Fools Them.
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn init/clone --stdlayout option to default-init trunk/tags/branches
From: Eric Wong @ 2007-07-14 11:34 UTC (permalink / raw)
To: git
In-Reply-To: <20070714110431.GA3854@piper.oerlikon.madduck.net>
martin f krafft <madduck@madduck.net> wrote:
> also sprach Eric Wong <normalperson@yhbt.net> [2007.07.14.1250 +0200]:
> > This looks good and useful, but can I also have a shorthand "-s" for
> > this, too? I'm lazy, thanks :)
>
> Of course.
>
> > Also, nitpicking, there's been some whitespace damage:
> >
> > I use tab characters for indentation, and (should be using) spaces for
> > alignment.
>
> What's the difference? Or is it simply:
>
> no. of tabs: int(column / 8)
> no. of spaces: column % 8
It's also easier/faster to navigate code with tabs since there are fewer
characters to iterate over, less granular points for indentation, making
it easier to to get to a desired indentation level.
The less granularity with tabs means I can avoid situations where where
I wonder if I'm correctly aligned with other pieces of code. I even
have auto-indent set, but occasionally with spaces (when I work on Ruby
code) I still have problems with being off-by-one after editing
something.
There's absolutely no way I can misalign a block of code when alignment
granularity is 8 characters no matter how sleepy I get :)
I use tabs for indentation where they denote logically different code
paths / nesting.
Spaces (for alignment, not indentation) are mainly aesthetic. I use
them in spaces when I need finer control (usually long conditionals in
if-statements that are wrapped).
Tabs can also be easily reconfigured in editors to change the amount of
screen real estate they consume. Not really useful in git-svn since
I keep it <80 columns anyways.
> I am sorry, I tried to do it right, even paid attention to the
> tabs/spaces thing, but I guess I failed.
No worries. The maintainers here are also very picky about trailing
whitespace and spaces that appear before tab characters, too and I
became much more disciplined about that myself the past year.
I have highlighting search set in my editor (vim :set hls)
and usually just search for spaces vs tabs to make sure I'm clean.
Of course, maintaining a consistent whitespace style helps a *lot* with
the git/Linux patch exchange development style because it avoids
needless patch application conflicts that arise from whitespace
differences.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn init/clone --stdlayout option to default-init trunk/tags/branches
From: martin f krafft @ 2007-07-14 11:04 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070714105010.GA14842@muzzle>
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
also sprach Eric Wong <normalperson@yhbt.net> [2007.07.14.1250 +0200]:
> This looks good and useful, but can I also have a shorthand "-s" for
> this, too? I'm lazy, thanks :)
Of course.
> Also, nitpicking, there's been some whitespace damage:
>
> I use tab characters for indentation, and (should be using) spaces for
> alignment.
What's the difference? Or is it simply:
no. of tabs: int(column / 8)
no. of spaces: column % 8
?
I am sorry, I tried to do it right, even paid attention to the
tabs/spaces thing, but I guess I failed.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
save the plankton - eat a whale.
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn patch faulty (was: failing to send patches to the list)
From: Eric Wong @ 2007-07-14 10:54 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070713095644.GA26743@lapse.madduck.net>
martin f krafft <madduck@madduck.net> wrote:
> Hi there,
>
> still not having figured out the problem with the list (and I did
> contact postmaster@), I just discovered that in fact the patch only
> handles git-svn clone, not git-svn init. Thus, it's best to ignore
> it for now. I am sorry for not taking enough care before publishing
> it.
Heh, I haven't used git-svn init in months :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn init/clone --stdlayout option to default-init trunk/tags/branches
From: Eric Wong @ 2007-07-14 10:50 UTC (permalink / raw)
To: martin f. krafft; +Cc: git
In-Reply-To: <1184405128718-git-send-email-madduck@madduck.net>
"martin f. krafft" <madduck@madduck.net> wrote:
> The --stdlayout option to git-svn init/clone initialises the default
> Subversion values of trunk,tags,branches: -T trunk -b branches -t tags.
> If any of the -T/-t/-b options are given in addition, they are given
> preference.
>
> Signed-off-by: martin f. krafft <madduck@madduck.net>
Thanks. I've been meaning to do this myself, but keep on putting it
off...
This looks good and useful, but can I also have a shorthand "-s" for
this, too? I'm lazy, thanks :)
Also, nitpicking, there's been some whitespace damage:
I use tab characters for indentation, and (should be using) spaces for
alignment.
> ---
> Documentation/git-svn.txt | 6 +++++-
> git-svn.perl | 11 +++++++++--
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 0a210e4..9e74b27 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -44,10 +44,14 @@ COMMANDS
> --tags=<tags_subdir>;;
> -b<branches_subdir>;;
> --branches=<branches_subdir>;;
> +--stdlayout;;
> These are optional command-line options for init. Each of
> these flags can point to a relative repository path
> (--tags=project/tags') or a full url
> - (--tags=https://foo.org/project/tags)
> + (--tags=https://foo.org/project/tags). The option --stdlayout is
> + a shorthand way of setting trunk,tags,branches as the relative paths,
> + which is the Subversion default. If any of the other options are given
> + as well, they take precedence.
> --no-metadata;;
> Set the 'noMetadata' option in the [svn-remote] config.
> --use-svm-props;;
> diff --git a/git-svn.perl b/git-svn.perl
> index b3dffcc..affba8e 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -77,11 +77,12 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
> \$Git::SVN::_repack_flags,
> %remote_opts );
>
> -my ($_trunk, $_tags, $_branches);
> +my ($_trunk, $_tags, $_branches, $_stdlayout);
> my %icv;
> my %init_opts = ( 'template=s' => \$_template, 'shared:s' => \$_shared,
> 'trunk|T=s' => \$_trunk, 'tags|t=s' => \$_tags,
> 'branches|b=s' => \$_branches, 'prefix=s' => \$_prefix,
> + 'stdlayout' => \$_stdlayout,
> 'minimize-url|m' => \$Git::SVN::_minimize_url,
> 'no-metadata' => sub { $icv{noMetadata} = 1 },
> 'use-svm-props' => sub { $icv{useSvmProps} = 1 },
Yes, I'm not consistent myself with using spaces for alignment :(
Thanks for using spaces here.
> @@ -292,7 +293,8 @@ sub init_subdir {
> sub cmd_clone {
> my ($url, $path) = @_;
> if (!defined $path &&
> - (defined $_trunk || defined $_branches || defined $_tags) &&
> + (defined $_trunk || defined $_branches || defined $_tags ||
> + defined $_stdlayout) &&
The lines above and below use spaces for alignment, so this one should,
definitely be using spaces after the initial tab too.
> $url !~ m#^[a-z\+]+://#) {
> $path = $url;
> }
> @@ -302,6 +304,11 @@ sub cmd_clone {
> }
>
> sub cmd_init {
> + if (defined $_stdlayout) {
> + $_trunk = 'trunk' if (!defined $_trunk);
> + $_tags = 'tags' if (!defined $_tags);
> + $_branches = 'branches' if (!defined $_branches);
> + }
Indentation is always done in tabs in git-svn. I *should* be using
spaces for alignment but I myself have been sloppy :x
> if (defined $_trunk || defined $_branches || defined $_tags) {
> return cmd_multi_init(@_);
> }
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] make git-send-email.perl handle email addresses with no names when Email::Valid is present
From: Stephen Rothwell @ 2007-07-14 10:38 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git
In-Reply-To: <20070714040050.GA11773@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
On Fri, 13 Jul 2007 21:00:50 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Fri, Jul 13, 2007 at 06:28:18PM +1000, Stephen Rothwell wrote:
> >
> > This would be a bug in Email::Valid as it complains that the second
> > address fails the rfc822 check, however rfc822 says that the "display
> > name" before the '<' is optional.
>
> I agree, do you know how to get such a fix made?
I would be inclined to make it my distribution's problem :-) i.e. on
Debian I would report a bug against libemail-valid-perl.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Possible to make a totally empty repository for remote access?
From: martin f krafft @ 2007-07-14 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <20070714025819.GA22559@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
also sprach Jeff King <peff@peff.net> [2007.07.14.0458 +0200]:
> The "new" way (by "new" I mean available for over a year, since v1.4.1)
> is to put such configuration into your .git/config file:
Have a look also at
http://blog.madduck.net/vcs/2007.07.11_publishing-git-repositories
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
it is ok to let your mind go blank,
but please turn off the sound.
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] Define ishex(x) in git-compat-util.h
From: Johannes Schindelin @ 2007-07-14 10:18 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <11842671632000-git-send-email-skimo@liacs.nl>
Hi,
On Thu, 12 Jul 2007, skimo@liacs.nl wrote:
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 362e040..1a36f4c 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -325,12 +325,15 @@ static inline int has_extension(const char *filename, const char *ext)
> extern unsigned char sane_ctype[256];
> #define GIT_SPACE 0x01
> #define GIT_DIGIT 0x02
> -#define GIT_ALPHA 0x04
> +#define GIT_HEXAL 0x04
> +#define GIT_OTHAL 0x08
> +#define GIT_ALPHA (GIT_HEXAL | GIT_OTHAL)
I'd have left GIT_ALPHA, and added GIT_HEXDIGIT.
> #define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> #define isspace(x) sane_istest(x,GIT_SPACE)
> #define isdigit(x) sane_istest(x,GIT_DIGIT)
> #define isalpha(x) sane_istest(x,GIT_ALPHA)
> #define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
> +#define ishex(x) sane_istest(x,GIT_HEXAL | GIT_DIGIT)
I know, I originally proposed this. In the mean time, however, I found
that this gem should be even better (in terms of diff size):
#define ishex(x) (hexval(x) >= 0)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available
From: martin f. krafft @ 2007-07-14 9:24 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
Uses $(CPP) to attempt to preprocess an include <openssl/sha.h> directive. If
that fails, NO_OPENSSL is defined, causing the Makefile to fall back to using
mozilla's SHA implementation.
This should possibly go to configure.ac, but maybe *also* to Makefile to make
from-source compilations easier. git HEAD already comes with a Makefile (rather
than a Makefile.in), so I just ran it while testing out patches. I introduced
the test because I thought the computer could find out about libssl for me,
rather than myself having to forget to specify NO_OPENSSL every time.
Signed-off-by: martin f. krafft <madduck@madduck.net>
---
Makefile | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index d7541b4..1676343 100644
--- a/Makefile
+++ b/Makefile
@@ -532,6 +532,12 @@ ifndef NO_CURL
endif
endif
+HAS_OPENSSL := $(shell echo "\#include <openssl/sha.h>" \
+ | $(CPP) -o/dev/null - 2>/dev/null || echo no)
+ifeq "$(HAS_OPENSSL)" "no"
+ NO_OPENSSL = "openssl_sha.h_not_found"
+endif
+
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
--
1.5.3.rc1.9.gf029
^ permalink raw reply related
* Re: failing to send patches to the list
From: martin f krafft @ 2007-07-14 6:52 UTC (permalink / raw)
To: git discussion list
In-Reply-To: <20070713155516.GA2712@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
also sprach Jeff King <peff@peff.net> [2007.07.13.1755 +0200]:
> vger will reject messages without a message-id. git-format-patch by
> default does not generate a message-id, so unless sendmail generates one
> on the fly, that is your problem.
>
> In general, git-format-patch output is probably not suitable for direct
> sending...have you looked at git-send-email?
I just ran a test and found out: sendmail does generate a message ID
on the fly on the client, so this cannot be the problem.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
http://www.transnationalrepublic.org/
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] fall back to mozilla's sha.h if openssl/sha.h is not available
From: martin f. krafft @ 2007-07-14 9:25 UTC (permalink / raw)
To: git
Uses $(CPP) to attempt to preprocess an include <openssl/sha.h> directive. If
that fails, NO_OPENSSL is defined, causing the Makefile to fall back to using
mozilla's SHA implementation.
This should possibly go to configure.ac, but maybe *also* to Makefile to make
from-source compilations easier. git HEAD already comes with a Makefile (rather
than a Makefile.in), so I just ran it while testing out patches. I introduced
the test because I thought the computer could find out about libssl for me,
rather than myself having to forget to specify NO_OPENSSL every time.
Signed-off-by: martin f. krafft <madduck@madduck.net>
---
Makefile | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index d7541b4..1676343 100644
--- a/Makefile
+++ b/Makefile
@@ -532,6 +532,12 @@ ifndef NO_CURL
endif
endif
+HAS_OPENSSL := $(shell echo "\#include <openssl/sha.h>" \
+ | $(CPP) -o/dev/null - 2>/dev/null || echo no)
+ifeq "$(HAS_OPENSSL)" "no"
+ NO_OPENSSL = "openssl_sha.h_not_found"
+endif
+
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
--
1.5.3.rc1.9.gf029
^ permalink raw reply related
* [PATCH] git-svn init/clone --stdlayout option to default-init trunk/tags/branches
From: martin f. krafft @ 2007-07-14 9:25 UTC (permalink / raw)
To: git
The --stdlayout option to git-svn init/clone initialises the default
Subversion values of trunk,tags,branches: -T trunk -b branches -t tags.
If any of the -T/-t/-b options are given in addition, they are given
preference.
Signed-off-by: martin f. krafft <madduck@madduck.net>
---
Documentation/git-svn.txt | 6 +++++-
git-svn.perl | 11 +++++++++--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 0a210e4..9e74b27 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -44,10 +44,14 @@ COMMANDS
--tags=<tags_subdir>;;
-b<branches_subdir>;;
--branches=<branches_subdir>;;
+--stdlayout;;
These are optional command-line options for init. Each of
these flags can point to a relative repository path
(--tags=project/tags') or a full url
- (--tags=https://foo.org/project/tags)
+ (--tags=https://foo.org/project/tags). The option --stdlayout is
+ a shorthand way of setting trunk,tags,branches as the relative paths,
+ which is the Subversion default. If any of the other options are given
+ as well, they take precedence.
--no-metadata;;
Set the 'noMetadata' option in the [svn-remote] config.
--use-svm-props;;
diff --git a/git-svn.perl b/git-svn.perl
index b3dffcc..affba8e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -77,11 +77,12 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
\$Git::SVN::_repack_flags,
%remote_opts );
-my ($_trunk, $_tags, $_branches);
+my ($_trunk, $_tags, $_branches, $_stdlayout);
my %icv;
my %init_opts = ( 'template=s' => \$_template, 'shared:s' => \$_shared,
'trunk|T=s' => \$_trunk, 'tags|t=s' => \$_tags,
'branches|b=s' => \$_branches, 'prefix=s' => \$_prefix,
+ 'stdlayout' => \$_stdlayout,
'minimize-url|m' => \$Git::SVN::_minimize_url,
'no-metadata' => sub { $icv{noMetadata} = 1 },
'use-svm-props' => sub { $icv{useSvmProps} = 1 },
@@ -292,7 +293,8 @@ sub init_subdir {
sub cmd_clone {
my ($url, $path) = @_;
if (!defined $path &&
- (defined $_trunk || defined $_branches || defined $_tags) &&
+ (defined $_trunk || defined $_branches || defined $_tags ||
+ defined $_stdlayout) &&
$url !~ m#^[a-z\+]+://#) {
$path = $url;
}
@@ -302,6 +304,11 @@ sub cmd_clone {
}
sub cmd_init {
+ if (defined $_stdlayout) {
+ $_trunk = 'trunk' if (!defined $_trunk);
+ $_tags = 'tags' if (!defined $_tags);
+ $_branches = 'branches' if (!defined $_branches);
+ }
if (defined $_trunk || defined $_branches || defined $_tags) {
return cmd_multi_init(@_);
}
--
1.5.3.rc1.9.gf029
^ permalink raw reply related
* Re: failing to send patches to the list
From: martin f krafft @ 2007-07-14 6:59 UTC (permalink / raw)
To: git
In-Reply-To: <f79742$j44$2@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
also sprach Jakub Narebski <jnareb@gmail.com> [2007.07.14.0258 +0200]:
> Shouldn't this be rather in configure.in? Main Makefile has only
> defaults for different systems, but does not do tests.
You are right, except git HEAD already comes with a Makefile (rather
than a Makefile.in), so I just ran it while testing out patches.
I introduced the test because I thought the computer could find out
about libssl for me, rather than myself having to forget to specify
NO_OPENSSL every time.
I agree that this should be (also) in configure.ac; the question is
more whether we *could* also add it to the Makefile to make
from-source compilations easier.
On the other hand, I wonder: if the mozilla/sha.h implementation is
in the tree anyway, why even bother with libssl? The SHA
implementation is unlikely to be changed anytime soon, so the extra
library dependency seems overkill just for the SHA hash
functionality.
Just my 2¢
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
spamtraps: madduck.bogus@madduck.net
"to get back my youth i would do anything in the world, except take
exercise, get up early, or be respectable."
-- oscar wilde
[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] More permissive "git-rm --cached" behavior without -f.
From: Matthieu Moy @ 2007-07-14 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vy7hjjw01.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Although I would not be using it often myself, I think this
>> would make "git rm" more pleasant to use.
>>
>> Thanks for the patch, and my thanks also go to people who
>> commented on the patch.
>
> Having said that, I think this comment is not quite right.
>
> + else if (!index_only) {
> + /* It's not dangerous to git-rm --cached a
> + * file if the index matches the file or the
> + * HEAD, since it means the deleted content is
> + * still available somewhere.
> + */
>
> Personally I do not think "rm --cached" needs any such "safety",
> even though I'll keep the check for now, primarily because
> loosening the restriction later is always easier than adding new
> restriction. I really do not think this is about protecting the
> user from "deleted content is not available anywhere else".
I agree that this is something you can argue about.
But in this case, the behavior without -f should be changed too. If
the file matches HEAD, then "git-rm file" should work, regardless of
the index then (but this situation is less frequent).
In any case, the situation where you might lose content in the index
by doing git-rm are rare: it means you started working on a file, did
"git-add" at least once, and edited the file again later, and then
decided you wanted to remove the file. So, requiring the -f flag in
those situation is not a real problem, even if the situation is
slightly-dangerous-but-not-quite-so.
I'm willing to work on another patch on top of this one if there's an
agreement on a better semantics. This one was about fixing something
which was IMHO wrong, but doesn't necessarily achieve perfection ;-).
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Fix git-rebase -i to allow squashing of fast-forwardable commits
From: Johannes Schindelin @ 2007-07-14 9:53 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20070712223035.GB30532@steel.home>
Hi,
On Fri, 13 Jul 2007, Alex Riesen wrote:
> Without this change the commits will be left standalone, with
> duplicated commit message.
Thanks.
Ciao,
Dscho
^ permalink raw reply
* Re: kernel.org needs gitweb help
From: J.H. @ 2007-07-14 8:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: H. Peter Anvin, Linux Kernel Mailing List, Git Mailing List
In-Reply-To: <7vmyxzjtdq.fsf@assigned-by-dhcp.cox.net>
There's a todo list in the back of my head, I will try and write it up
this weekend and get it posted.
- John 'Warthog9' Hawley
On Sat, 2007-07-14 at 01:12 -0700, Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
> > A lot of people have asked me if there is anything they can do to help
> > out kernel.org. At this point, the number one thing anyone could do to
> > help, and which would be reasonably self-contained a project, would be
> > to help maintain our fork of gitweb:
> >
> > http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary
> >
> > We really need the caching version of gitweb, but it does have a number
> > of problems, including the non-working tarball generator.
>
> Are there an issues-list for the forked gitweb somewhere, or
> would the first step of people who would want to help be to
> build such a list?
>
>
> -
> 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
^ permalink raw reply
* Re: pushing changes to a remote branch
From: Jan Hudec @ 2007-07-14 8:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Jeff King, git discussion list
In-Reply-To: <7v1wfe4op5.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]
On Wed, Jul 11, 2007 at 14:26:14 -0700, Junio C Hamano wrote:
> Jan Hudec <bulb@ucw.cz> writes:
>
> >> $ git checkout origin/master
> >> Note: moving to "origin/master" which isn't a local branch
> >> If you want to create a new branch from this checkout, you may do so
> >> (now or later) by using -b with the checkout command again. Example:
> >> git checkout -b <new_branch_name>
> >> HEAD is now at f4855d4... 1
> >
> > The problem of this warning is, that it does not actually say anything about
> > detached and that potential commit won't update the ref being checked out.
>
> "Being detached" is a rather geekish synonym to "which isn't a
> local branch", isn't it?
In a sense, no, it is not. "Being detached" is a synonym of "HEAD is not
symbolic ref". The current warning does not really convey the information,
that the ref being checked out will not be updated. Maybe it could be
extended along the lines of following patch.
Hm, it will say the same when checking out with commit name, which does not
make sense much, though.
-->8--
Extend the detached head warning in checkout.
The warning when detaching head now explicitely states that ref being checked
out will not be updated.
---
git-checkout.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 17f4392..502b2be 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -178,7 +178,8 @@ then
detached="$new"
if test -n "$oldbranch" && test -z "$quiet"
then
- detach_warn="Note: moving to \"$new_name\" which isn't a local branch
+ detach_warn="Note: moving to \"$new_name\" which isn't a local branch, so it will
+_not_ be updated by local commits.
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>"
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] git-reset: allow --soft in a bare repo
From: Junio C Hamano @ 2007-07-14 8:33 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070714052405.GA26107@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Ah, I hadn't thought of that. It seems a bit of a contortion, though,
> since git-branch is usually used for _making_ a branch, whereas
> git-reset is usually used for _changing_ a branch. But maybe that's just
> me.
"branch -f" is very often used to "reset the branch tip". My
git day typically begins with "branch -f pu next".
> At any rate, it might still be worth applying the patch. It should be
> harmless to loosen the restriction, and even if there are several ways
> to accomplish the same thing, why punish people who try git-reset first?
> On the other hand, this is the first time I've seen it come up, so maybe
> this isn't confusing people.
Actually, after thinking about this a bit more, I have become
somewhat reluctant, as this might confuse new users by giving
them a wrong mental model of what "reset" is about.
To my mind, as an old time git user, reset (any variant) has
always been about reshaping the relationship among the HEAD, the
index and the working tree; if there is no index nor the working
tree (iow, a bare repository), there can be no "relationship"
among them.
We initially had only --mixed and --hard (and the former was not
even called --mixed as there were only two kinds). Then --soft
was invented as a stop-gap measure before "commit --amend" came.
In all cases, the user is saying "I want to make the next commit
I'll make on top of that commit (which may or may not be
different from the HEAD), and I'd want to start working towards
that goal, starting from such and such index and working tree
state". And that "such and such state" is different among three
variants:
* "reset --mixed" means "I like what I have in the working
tree, but I'd want to discard the index and start from what
is in (possibly updated) HEAD instead";
* "reset --hard" means "I want to restart both index and
working tree from scratch, starting from (possibly updated)
HEAD";
* "reset --soft" means "I like what I have in the index and
also I like what I have in the working tree -- do not touch
them -- I want the next commit to go on top of that commit".
"reset --soft" happens to be a variant of reset that does not
touch index nor working tree, but conceptually, "not touching"
and "not having either is Ok" are two quite different things.
^ permalink raw reply
* Re: [PATCH] Use $(RM) in makefiles instead of rm
From: Junio C Hamano @ 2007-07-14 8:33 UTC (permalink / raw)
To: Emil Medve; +Cc: git
In-Reply-To: <11843489233943-git-send-email-Emilian.Medve@Freescale.com>
The title really should read "instead of 'rm -f'".
And who defines "RM = rm -f" when nothing is specified on the
command line? I'd assume the answer is "GNU make", and it
probably is true for all versions we care about, but I would
feel better if we have that spelled explicitly as the fallback
position, just like we define CC, AR and friends.
^ permalink raw reply
* Re: kernel.org needs gitweb help
From: Junio C Hamano @ 2007-07-14 8:12 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linux Kernel Mailing List, Git Mailing List, J.H.
In-Reply-To: <469806EC.1050104@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> A lot of people have asked me if there is anything they can do to help
> out kernel.org. At this point, the number one thing anyone could do to
> help, and which would be reasonably self-contained a project, would be
> to help maintain our fork of gitweb:
>
> http://git.kernel.org/?p=git/warthog9/gitweb.git;a=summary
>
> We really need the caching version of gitweb, but it does have a number
> of problems, including the non-working tarball generator.
Are there an issues-list for the forked gitweb somewhere, or
would the first step of people who would want to help be to
build such a list?
^ permalink raw reply
* Re: why does git perpetually complain about include/asm-blackfin/macros.h?
From: Sam Ravnborg @ 2007-07-14 7:45 UTC (permalink / raw)
To: Jeff Garzik
Cc: Alex Riesen, Jesper Juhl, Robert P. J. Day,
Linux Kernel Mailing List, Git Mailing List, Linus Torvalds
In-Reply-To: <46890DA8.4070400@garzik.org>
On Mon, Jul 02, 2007 at 10:37:28AM -0400, Jeff Garzik wrote:
> Alex Riesen wrote:
> >Do some of your branches miss the commit by which it was removed?
>
> git-clone followed by git-checkout master recreates the problem.
>
> But to answer your question directly, I rebase, so they absolutely do
> not miss any commits.
>
>
> >It is somewhat unclear what "reappear" means, though: do you mean
>
> Attempts to give you precise output to answer your question yielded a
> data point, the kernel's "make distclean" causes this:
>
> [jgarzik@pretzel linux-2.6]$ make distclean && git checkout master &&
> git diff HEAD
> D include/asm-blackfin/macros.h
> Switched to branch "master"
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..0000000
>
> [jgarzik@pretzel linux-2.6]$ git checkout -f
>
> [jgarzik@pretzel linux-2.6]$ make distclean && git checkout master &&
> git diff HEAD
> D include/asm-blackfin/macros.h
> Switched to branch "master"
> diff --git a/include/asm-blackfin/macros.h b/include/asm-blackfin/macros.h
> deleted file mode 100644
> index e69de29..0000000
>
> [jgarzik@pretzel linux-2.6]$ git checkout -f
>
> [jgarzik@pretzel linux-2.6]$ git checkout master && git diff
> HEADSwitched to branch "master"
>
> [jgarzik@pretzel linux-2.6]$ git checkout master && git diff HEAD
> Switched to branch "master"
>
> [jgarzik@pretzel linux-2.6]$
>
>
> So, not a git problem but a kernel Makefile problem. Sorry for the git
> noise.
distclean on purpose delete zero size files.
And the kernel tree shall not contain such files - if it does it is a bug.
So I do not see a 'problem' with the kernel makefile but instead a problem
with the kernel tree wich is about to be fixed.
Agree?
Sam
^ 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