* Re: subdirectory-filter does not delete files before the directory came into existence?
From: Thomas Rast @ 2010-12-19 22:51 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <1292751289.21229.26.camel@ct>
Jan Wielemaker wrote:
> On Sun, 2010-12-19 at 03:23 +0100, Thomas Rast wrote:
> > Jan Wielemaker wrote:
> > > * get all tags, use comm and delete the tags not in the `contained'
> > > set above.
[...]
> > http://article.gmane.org/gmane.comp.version-control.git/91708
[...]
> Funny. That was me having problems with filtering out directories
> as well :-) I thought your patch was added using the --prune-empty
> flag. I guess you can comment on that. I can confirm that I've got
> nice and clean filtering using
No, those two are rather different. --prune-empty drops commits that
became "no-ops" in the sense that their tree is the same as their
(only) parent's. In the case of --subdirectory-filter, --prune-empty
is most likely[*] redundant since the former already enables history
simplification limited to that directory.
As you can see from "TOY PATCH", my patch wasn't really meant for
application anyway. I'm now wondering what the ramifications would
be. filter-branch only attempts to change refs that you told it to
(listed positively on the command line), so maybe deleting anything
that was not rewritten is a sensible option (not default, mind you).
[*] Read: I think it is redundant, I'm just too lazy to double-check.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Basic Git Questions
From: Parag Kalra @ 2010-12-19 22:32 UTC (permalink / raw)
To: git
Hi,
1. I generally add the files in my working directory using "git add
.". But sometimes you want to add all the files except 1 or 2 file. Is
there a shortcut way we can tell git to add all the files but exclude
a particular file.
2. Also sometime when the code is committed, I realize that I have
forgot to change or add a file. Is there a way we can we commit a file
to existing commit number with git log showing only the old git commit
number and not creating a new one for the last commit.
Cheers,
Parag
^ permalink raw reply
* Re: [PATCH] convert filter: supply path to external driver
From: Junio C Hamano @ 2010-12-19 21:59 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Jeff King
In-Reply-To: <20101219212925.GA7393@arf.padd.com>
Pete Wyckoff <pw@padd.com> writes:
> Filtering to support keyword expansion may need the name of
> the file being filtered. In particular, to support p4 keywords
> like
>
> $File: //depot/product/dir/script.sh $
>
> the smudge filter needs to know the name of the file it is
> smudging.
>
> Add a "%s" conversion specifier to the gitattribute for filter.
> It will be expanded with the path name to the file when invoking
> the external filter command.
>
> Signed-off-by: Pete Wyckoff <pw@padd.com>
> ---
>
> pw@padd.com wrote on Sat, 18 Dec 2010 17:38 -0500:
>> I'm using git-p4 to import and work with upstream p4
>> repositories. Some of the files are ktext, meaning they expect
>> expansion of $Id$ and similar identifiers.
>>
>> Using the filter driver for this file, I can do the "clean" part
>> easily, but to calculate the "smudge" correctly, I need to know
>> the filename inside the filter driver.
>
> This works fine for me. It is backward compatible, and leaves
> open the possibility of adding other % modifiers if we find
> a need later.
This is not backward compatible for people who wanted to use '%' literal
on their filter command line for whatever reason, so please do not
advertise as such. A fair argument you could make is "Even though this is
not strictly backward compatible, it is very unlikely that people passed a
literal % to their filter command line, and the benefit of being able to
give the pathname information would outweigh the downside of not being
compatible", and people can agree or disagree.
I am personally moderately negative about $any expansion$ (I don't use it
myself, and I don't think sane people use it either). As far as I can
tell, this should has no impact on the correctness and very little impact
on the performance for people who do not use $any expansion$, so I am Ok
with the patch.
Modulo one worry. Don't we have, or don't we at least plant to allow us
to have, a facility to cache expensive blob conversion result, similar to
the textconv caching? How would this change interact with two blobs that
live in different paths?
^ permalink raw reply
* [PATCH] convert filter: supply path to external driver
From: Pete Wyckoff @ 2010-12-19 21:29 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20101218223822.GA18902@arf.padd.com>
Filtering to support keyword expansion may need the name of
the file being filtered. In particular, to support p4 keywords
like
$File: //depot/product/dir/script.sh $
the smudge filter needs to know the name of the file it is
smudging.
Add a "%s" conversion specifier to the gitattribute for filter.
It will be expanded with the path name to the file when invoking
the external filter command.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
pw@padd.com wrote on Sat, 18 Dec 2010 17:38 -0500:
> I'm using git-p4 to import and work with upstream p4
> repositories. Some of the files are ktext, meaning they expect
> expansion of $Id$ and similar identifiers.
>
> Using the filter driver for this file, I can do the "clean" part
> easily, but to calculate the "smudge" correctly, I need to know
> the filename inside the filter driver.
This works fine for me. It is backward compatible, and leaves
open the possibility of adding other % modifiers if we find
a need later.
I have a filter that handles all the p4 $Keyword$ expansions,
now, using this patch. It can go into contrib if others would
find it useful. This seriously reduces many hassles associated
with my git-p4 workflow, where a plethora of ancillary systems
rely on keyword expansion in the source.
Cc Junio for comments as the original author of convert filter
code.
-- Pete
Documentation/gitattributes.txt | 12 ++++++++++++
convert.c | 15 ++++++++++++++-
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 564586b..9ac2138 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -317,6 +317,18 @@ command is "cat").
smudge = cat
------------------------
+If your filter needs the path of the file it is working on,
+you can use the "%s" conversion specification. It will be
+replaced with the relative path to the file. This is important
+for keyword substitution that depends on the name of the
+file. Like this:
+
+------------------------
+[filter "p4"]
+ clean = git-p4-filter --clean %s
+ smudge = git-p4-filter --smudge %s
+------------------------
+
Interaction between checkin/checkout attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/convert.c b/convert.c
index e41a31e..d4c6ed1 100644
--- a/convert.c
+++ b/convert.c
@@ -317,6 +317,7 @@ struct filter_params {
const char *src;
unsigned long size;
const char *cmd;
+ const char *path;
};
static int filter_buffer(int in, int out, void *data)
@@ -329,7 +330,16 @@ static int filter_buffer(int in, int out, void *data)
int write_err, status;
const char *argv[] = { NULL, NULL };
- argv[0] = params->cmd;
+ /* replace optional %s with path */
+ struct strbuf cmd = STRBUF_INIT;
+ struct strbuf_expand_dict_entry dict[] = {
+ "s", params->path,
+ NULL, NULL,
+ };
+
+ strbuf_expand(&cmd, params->cmd, strbuf_expand_dict_cb, &dict);
+
+ argv[0] = cmd.buf;
memset(&child_process, 0, sizeof(child_process));
child_process.argv = argv;
@@ -349,6 +359,8 @@ static int filter_buffer(int in, int out, void *data)
status = finish_command(&child_process);
if (status)
error("external filter %s failed %d", params->cmd, status);
+
+ strbuf_release(&cmd);
return (write_err || status);
}
@@ -376,6 +388,7 @@ static int apply_filter(const char *path, const char *src, size_t len,
params.src = src;
params.size = len;
params.cmd = cmd;
+ params.path = path;
fflush(NULL);
if (start_async(&async))
--
1.7.2.3
^ permalink raw reply related
* Re: Commiting automatically (2)
From: Jonathan Nieder @ 2010-12-19 20:17 UTC (permalink / raw)
To: Taylor Hedberg; +Cc: Maaartin, git
In-Reply-To: <20101219183619.GB11955@burratino>
Jonathan Nieder wrote:
>> On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:
>>> There's one more problem. My script doesn't recognize deleted files, since
>>> git add -A
>>> does nothing to them.
[...]
> Maaartin, could you give an example showing where add -A goes wrong?
Please ignore; looks like Taylor and Junio figured it out. (For
anyone else who was confused like me: the files in question were
removed with the equivalent of
git rm --cached generated.c
rather than
rm -f irrelevant.c
.)
^ permalink raw reply
* Re: [PATCH] am: Allow passing exclude and include args to apply
From: Junio C Hamano @ 2010-12-19 20:13 UTC (permalink / raw)
To: maximilian attems; +Cc: Thiago Farina, git, klibc
In-Reply-To: <20101219171313.GI17034@vostochny.stro.at>
maximilian attems <max@stro.at> writes:
> On Sun, Dec 19, 2010 at 02:56:58PM -0200, Thiago Farina wrote:
>> On Sun, Dec 19, 2010 at 2:17 PM, maximilian attems <max@stro.at> wrote:
>> > When porting patches from dash git to klibc git,
>> > where dash has a different directory structure those
>> > switches are handy:
>> > Exported with format-patch on dash side and used am
>> > as import for klibc side.
>> >
> ...
> when one wants to promote a specific new feature, it is much better to
> come up with it's use case, as burden is on Maintainer to keep it working.
You need to do that with test suite, not with the log message. Otherwise
you are adding undue burden on the Maintainer to download klibc and dash
just to run regression testing whenever somebody else makes changes to
"am/apply" callchain down the road.
While I love patches that are backed by a strong "here is a real-world
problem we needed to solve, and this change made our life much easier by
doing so-and-so" statement, I also tend to think twice before considering
a change that could potentially encourage a bad version control
discipline.
Your use case description in the log message however lacks crucial
information to be useful when judging that aspect. You said that the
directory structure is "different", but didn't say they are different in
what way. In order to skip one mail exchange turnaround, I'd speculate.
If dash repository keeps (perhaps slightly stale version of) the same
files as klibc repository in its libc/ subdirectory, a patch to dash that
fixes its libc part may all have its pathnames prefixed with libc/. In
order to apply such a patch to the klibc tree, you would need to give -p2
to strip one extra level (if you are going the other way, you would
instead give --directory=libc/ to deepen it). But then I do not see a
need for --exclude to remove parts from the patch that touch outside of
libc/ tree.
If the dash patch you needed to deal with touched both inside libc/ and
outside, and if you are taking only libc/ part and discarding everything
else, I see two issues with respect to promoting pottentially bad version
control disciplines.
- Should you be reusing the information in the commit without editing? I
am not worried about Signed-off-by which is about asserting the origin,
and origin of the libc/ part is the same as the origin of the whole.
But what about reviewers' and tester's assertion at the end? Also the
description of the change itself may need to be adjusted to the new
context you are reusing the change for.
- Why does the patch touch two unrelated parts in the first place, if its
libc/ part can stand on its own? This is not about the discipline of
the user of "am", but of the originating project.
Another thing that came to my mind around the vague "different directory
structure" is this question: what if directory A/ in "dash" corresponded
to directory B/ in "klibc" and you saw a patch to A/ (and some others) for
"dash" that you wanted to reuse in "klibc"? Do we need more changes to
make it work, or do we already have enough support for this combination?
I would imagine that "git am --directory=B/ -p2 --exclude=\* --include=A/"
or something like that should work, but I didn't think it through nor I
didn't check the command line syntax, either.
^ permalink raw reply
* Re: Commiting automatically (2)
From: Junio C Hamano @ 2010-12-19 19:32 UTC (permalink / raw)
To: Maaartin; +Cc: git
In-Reply-To: <loom.20101219T090500-396@post.gmane.org>
Maaartin <grajcar1@seznam.cz> writes:
> However, when I use my git-autocom script, those files get marked as deleted.
> This is quite strange, especially because of them still existing. I'd strongly
> prefer git-autocom to behave just like git commit (i.e., tracking the files).
>
> The relevant part of my script follows:
>
> export GIT_INDEX_FILE=.git/autocom.tmp
> git add -A &&
If you really want "just like commit", then it would be more like "make a
commit object out of the current index, and put that somewhere outside the
current branch", and will not involve any "git add", no?
A useful goal would be "as if I said 'git add -u && git commit' from the
current state" (alternatively, you could say s/-u/-A/).
If this autocom.tmp starts out empty, "add" will of course honor what you
wrote in .gitignore hence would not add ignored files. You may have '*.o'
in the ignore mechanism to exclude usual build products. Until you
somehow tell git that you care about a vendor-supplied binary blob file
"binblob1.o" even though it has a name for usual ignored ones, you don't
want to get it tracked, and once you have done so with "git add -f", you
do want to get it tracked from that point. But your script cannot be
clever enough to selectively say "add -f" for such a file.
The "from the current state" part of the sentence of your goal (clarified
by the second paragraph above) fundamentally means you need to start from
your real index, so "cp -p .git/index $TMP_INDEX" is both appropriate and
inevitable for your script.
^ permalink raw reply
* Re: Commiting automatically (2)
From: Jonathan Nieder @ 2010-12-19 18:36 UTC (permalink / raw)
To: Taylor Hedberg; +Cc: Maaartin, git
In-Reply-To: <20101219150850.GC12136@foodlogiq3-xp-d620.thebe.ath.cx>
Taylor Hedberg wrote:
> On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:
>> There's one more problem. My script doesn't recognize deleted files, since
>> git add -A
>> does nothing to them. I'm quite sure I saw a solution to this, but can't find
>> it now...
>
> I believe "git add -u" will do the same thing as "git add -A", plus
> handle deleted files.
Hmm, the "git add" manual suggests it is the other way around:
-A, --all
Like -u, but match <filepattern> against files in the working
tree in addition to the index. That means that it will find new
files as well as staging modified content and removing files
that are no longer in the working tree.
So I would expect "git add -A" to do the same thing as "git add -u",
plus handling added files.
Maaartin, could you give an example showing where add -A goes wrong?
^ permalink raw reply
* Re: [klibc] [PATCH] am: Allow passing exclude and include args to apply
From: maximilian attems @ 2010-12-19 18:27 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Thiago Farina, klibc, Junio C Hamano, git
In-Reply-To: <20101219172657.GA9564@merkur.ravnborg.org>
On Sun, Dec 19, 2010 at 06:26:57PM +0100, Sam Ravnborg wrote:
>
> I had to read it twice to get it..
> Most likely because I read the changelog without reading the title first.
>
> Sam
thanks, fixed in v2.
--
maks
^ permalink raw reply
* [PATCH v2] am: Allow passing exclude and include args to apply
From: maximilian attems @ 2010-12-19 18:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, maximilian attems, klibc, Thiago Farina,
Sam Ravnborg
am already allows to pass several flags to apply as directory or reject,
but not yet the exclude and include args.
When porting dash patches from dash git to klibc git, where dash has a
different directory structure, the exclude and include am switches are handy:
Exported with format-patch on dash side and used am as import for klibc side.
Cc: klibc@zytor.com
Cc: Thiago Farina <tfransosi@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: maximilian attems <max@stro.at>
---
Documentation/git-am.txt | 5 ++++-
git-am.sh | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 51297d0..4c65dba 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,8 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet] [--scissors | --no-scissors]
+ [--exclude=PATH] [--include=PATH] [--reject] [-q | --quiet]
+ [--scissors | --no-scissors]
[(<mbox> | <Maildir>)...]
'git am' (--continue | --skip | --abort)
@@ -87,6 +88,8 @@ default. You can use `--no-utf8` to override this.
-C<n>::
-p<n>::
--directory=<dir>::
+--exclude=<path-pattern>::
+--include=<path-pattern>::
--reject::
These flags are passed to the 'git apply' (see linkgit:git-apply[1])
program that applies
diff --git a/git-am.sh b/git-am.sh
index df09b42..174f6a2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -22,6 +22,8 @@ whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
directory= pass it through git-apply
+exclude= pass it through git-apply
+include= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
patch-format= format the patch(es) are in
@@ -340,7 +342,7 @@ do
;;
--resolvemsg)
shift; resolvemsg=$1 ;;
- --whitespace|--directory)
+ --whitespace|--directory|--exclude|--include)
git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
--
1.7.2.3
^ permalink raw reply related
* Re: [klibc] [PATCH] am: Allow passing exclude and include args to apply
From: Sam Ravnborg @ 2010-12-19 17:26 UTC (permalink / raw)
To: maximilian attems; +Cc: Thiago Farina, klibc, Junio C Hamano, git
In-Reply-To: <20101219171313.GI17034@vostochny.stro.at>
On Sun, Dec 19, 2010 at 05:13:13PM +0000, maximilian attems wrote:
> On Sun, Dec 19, 2010 at 02:56:58PM -0200, Thiago Farina wrote:
> > On Sun, Dec 19, 2010 at 2:17 PM, maximilian attems <max@stro.at> wrote:
> > > When porting patches from dash git to klibc git,
> > > where dash has a different directory structure those
> > > switches are handy:
> > > Exported with format-patch on dash side and used am
> > > as import for klibc side.
> > >
> >
> > I don't know, but this commit message doesn't look good. Can you be
> > more specific about what the patch does, and what it's trying to fix.
>
> hmm, it does what the subject says. (:
> have you ever used `git am'?
>
...
> Please be more specific on what's missing? Your personal taste is
> unknown to me and not of importance.
I had to read it twice to get it..
Most likely because I read the changelog without reading the title first.
Sam
^ permalink raw reply
* Re: [PATCH] am: Allow passing exclude and include args to apply
From: maximilian attems @ 2010-12-19 17:13 UTC (permalink / raw)
To: Thiago Farina; +Cc: git, Junio C Hamano, klibc
In-Reply-To: <AANLkTik5-oJYsfEoeYjy8E9v4T4_7VBsoGnqg7oXwnbC@mail.gmail.com>
On Sun, Dec 19, 2010 at 02:56:58PM -0200, Thiago Farina wrote:
> On Sun, Dec 19, 2010 at 2:17 PM, maximilian attems <max@stro.at> wrote:
> > When porting patches from dash git to klibc git,
> > where dash has a different directory structure those
> > switches are handy:
> > Exported with format-patch on dash side and used am
> > as import for klibc side.
> >
>
> I don't know, but this commit message doesn't look good. Can you be
> more specific about what the patch does, and what it's trying to fix.
hmm, it does what the subject says. (:
have you ever used `git am'?
> Describing a use case is good, but in this case it isn't help me much
> (maybe for others the issue here is clear, but for my taste no).
when one wants to promote a specific new feature, it is much better to
come up with it's use case, as burden is on Maintainer to keep it working.
Please be more specific on what's missing? Your personal taste is
unknown to me and not of importance.
thank you.
--
maks
^ permalink raw reply
* Re: [PATCH] am: Allow passing exclude and include args to apply
From: Thiago Farina @ 2010-12-19 16:56 UTC (permalink / raw)
To: maximilian attems; +Cc: git, Junio C Hamano, klibc
In-Reply-To: <1292775461-26762-1-git-send-email-max@stro.at>
On Sun, Dec 19, 2010 at 2:17 PM, maximilian attems <max@stro.at> wrote:
> When porting patches from dash git to klibc git,
> where dash has a different directory structure those
> switches are handy:
> Exported with format-patch on dash side and used am
> as import for klibc side.
>
I don't know, but this commit message doesn't look good. Can you be
more specific about what the patch does, and what it's trying to fix.
Describing a use case is good, but in this case it isn't help me much
(maybe for others the issue here is clear, but for my taste no).
> Signed-off-by: maximilian attems <max@stro.at>
> ---
> Documentation/git-am.txt | 5 ++++-
> git-am.sh | 4 +++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
> index 51297d0..4c65dba 100644
> --- a/Documentation/git-am.txt
> +++ b/Documentation/git-am.txt
> @@ -13,7 +13,8 @@ SYNOPSIS
> [--3way] [--interactive] [--committer-date-is-author-date]
> [--ignore-date] [--ignore-space-change | --ignore-whitespace]
> [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
> - [--reject] [-q | --quiet] [--scissors | --no-scissors]
> + [--exclude=PATH] [--include=PATH] [--reject] [-q | --quiet]
> + [--scissors | --no-scissors]
> [(<mbox> | <Maildir>)...]
> 'git am' (--continue | --skip | --abort)
>
> @@ -87,6 +88,8 @@ default. You can use `--no-utf8` to override this.
> -C<n>::
> -p<n>::
> --directory=<dir>::
> +--exclude=<path-pattern>::
> +--include=<path-pattern>::
> --reject::
> These flags are passed to the 'git apply' (see linkgit:git-apply[1])
> program that applies
> diff --git a/git-am.sh b/git-am.sh
> index df09b42..174f6a2 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -22,6 +22,8 @@ whitespace= pass it through git-apply
> ignore-space-change pass it through git-apply
> ignore-whitespace pass it through git-apply
> directory= pass it through git-apply
> +exclude= pass it through git-apply
> +include= pass it through git-apply
> C= pass it through git-apply
> p= pass it through git-apply
> patch-format= format the patch(es) are in
> @@ -340,7 +342,7 @@ do
> ;;
> --resolvemsg)
> shift; resolvemsg=$1 ;;
> - --whitespace|--directory)
> + --whitespace|--directory|--exclude|--include)
> git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
> -C|-p)
> git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
> --
> 1.7.2.3
>
> --
> 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
* [PATCH] am: Allow passing exclude and include args to apply
From: maximilian attems @ 2010-12-19 16:17 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, klibc, maximilian attems
When porting patches from dash git to klibc git,
where dash has a different directory structure those
switches are handy:
Exported with format-patch on dash side and used am
as import for klibc side.
Signed-off-by: maximilian attems <max@stro.at>
---
Documentation/git-am.txt | 5 ++++-
git-am.sh | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 51297d0..4c65dba 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,8 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet] [--scissors | --no-scissors]
+ [--exclude=PATH] [--include=PATH] [--reject] [-q | --quiet]
+ [--scissors | --no-scissors]
[(<mbox> | <Maildir>)...]
'git am' (--continue | --skip | --abort)
@@ -87,6 +88,8 @@ default. You can use `--no-utf8` to override this.
-C<n>::
-p<n>::
--directory=<dir>::
+--exclude=<path-pattern>::
+--include=<path-pattern>::
--reject::
These flags are passed to the 'git apply' (see linkgit:git-apply[1])
program that applies
diff --git a/git-am.sh b/git-am.sh
index df09b42..174f6a2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -22,6 +22,8 @@ whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
directory= pass it through git-apply
+exclude= pass it through git-apply
+include= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
patch-format= format the patch(es) are in
@@ -340,7 +342,7 @@ do
;;
--resolvemsg)
shift; resolvemsg=$1 ;;
- --whitespace|--directory)
+ --whitespace|--directory|--exclude|--include)
git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
-C|-p)
git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
--
1.7.2.3
^ permalink raw reply related
* Re: Commiting automatically (2)
From: Taylor Hedberg @ 2010-12-19 15:08 UTC (permalink / raw)
To: Maaartin; +Cc: git
In-Reply-To: <loom.20101219T090500-396@post.gmane.org>
On Sun, Dec 19, 2010 at 08:29:50AM +0000, Maaartin wrote:
> There's one more problem. My script doesn't recognize deleted files, since
> git add -A
> does nothing to them. I'm quite sure I saw a solution to this, but can't find
> it now...
I believe "git add -u" will do the same thing as "git add -A", plus
handle deleted files.
^ permalink raw reply
* Re: [PATCH 2/2] fill_textconv(): Don't get/put cache if sha1 is not valid
From: Kirill Smelkov @ 2010-12-19 12:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, git, Axel Bonnet, Cl??ment Poulain, Diane Gasselin
In-Reply-To: <7vk4j6fnta.fsf@alter.siamese.dyndns.org>
On Sat, Dec 18, 2010 at 07:23:29PM -0800, Junio C Hamano wrote:
> Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
>
> > Thanks for your ACK and for the explanation.
> >
> > My last patches to git were blame related so semi-intuitively I knew
> > that invalid sha1 are coming from files in worktree. Your description
> > makes things much more clear and I'd put it into patch log as well.
> > What is the best practice for this? For me to re-roll, or for Junio to
> > merge texts?
>
> Re-rolling to explain changes in your own words is preferred; thanks.
I see, thanks.
I'm not that familiar with git internals involved, so here is updated
patch with added paragraph about "df->sha1_valid=0 means files from
worktree with unknown sha1", and appropriate excerpt from Jeff's post.
That's the most reasonable I could come up with.
Thanks,
Kirill
P.S. please don't forget to pick patch 1 which is unchanged.
---- 8< ----
From: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Date: Sat, 18 Dec 2010 16:27:28 +0300
Subject: [PATCH v2 2/2] fill_textconv(): Don't get/put cache if sha1 is not valid
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
It turned out, under blame there are requests to fill_textconv() with
sha1=0000000000000000000000000000000000000000 and sha1_valid=0.
As the code did not analyzed sha1 validity, we ended up putting 000000
into textconv cache which was fooling later blames to discover lots of
lines in 'Not Yet Committed' state.
In practice df->sha1_valid=0 means blame requests to run textconv on a
file in worktree whose sha1 is not know yet.
Fix it.
On Sat, Dec 18, 2010 at 11:13:37AM -0500, Jeff King wrote:
>
> In short:
>
> Acked-by: Jeff King <peff@peff.net>
>
> But it took some thinking to convince myself, so the long answer is
> below if anyone cares.
>
> I was dubious at first that this could be the right solution. We still
> end up putting the filespec through run_textconv, which didn't seem
> right if it is not valid.
>
> But reading into it more, there are two levels of invalidity:
>
> 1. !DIFF_FILE_VALID(df) - we are not a valid file at all. I.e., we are
> /dev/null.
>
> 2. !df->sha1_valid - we are pointing to a working tree file whose sha1
> we don't know
>
> I think level (2) never happens at all in the regular diff code, which
> is why this case was completely unhandled. But it is OK in that case
> (required, even) to put the contents through run_textconv.
Cc: Axel Bonnet <axel.bonnet@ensimag.imag.fr>
Cc: Clц╘ment Poulain <clement.poulain@ensimag.imag.fr>
Cc: Diane Gasselin <diane.gasselin@ensimag.imag.fr>
Cc: Jeff King <peff@peff.net>
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Acked-by: Jeff King <peff@peff.net>
---
diff.c | 4 ++--
t/t8006-blame-textconv.sh | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 0a43869..5422c43 100644
--- a/diff.c
+++ b/diff.c
@@ -4412,7 +4412,7 @@ size_t fill_textconv(struct userdiff_driver *driver,
return df->size;
}
- if (driver->textconv_cache) {
+ if (driver->textconv_cache && df->sha1_valid) {
*outbuf = notes_cache_get(driver->textconv_cache, df->sha1,
&size);
if (*outbuf)
@@ -4423,7 +4423,7 @@ size_t fill_textconv(struct userdiff_driver *driver,
if (!*outbuf)
die("unable to read files to diff");
- if (driver->textconv_cache) {
+ if (driver->textconv_cache && df->sha1_valid) {
/* ignore errors, as we might be in a readonly repository */
notes_cache_put(driver->textconv_cache, df->sha1, *outbuf,
size);
diff --git a/t/t8006-blame-textconv.sh b/t/t8006-blame-textconv.sh
index fe90541..ea64cd8 100755
--- a/t/t8006-blame-textconv.sh
+++ b/t/t8006-blame-textconv.sh
@@ -81,8 +81,7 @@ cat >expected_one <<EOF
(Number2 2010-01-01 20:00:00 +0000 1) converted: test 1 version 2
EOF
-# one.bin is blamed as 'Not Committed yet'
-test_expect_failure 'blame --textconv works with textconvcache' '
+test_expect_success 'blame --textconv works with textconvcache' '
git blame --textconv two.bin >blame &&
find_blame <blame >result &&
test_cmp expected result &&
--
1.7.3.4.570.g14308
^ permalink raw reply related
* Re: [PATCH v2] builtin/rm.c: Use ALLOC_GROW instead of alloc_nr and xrealloc.
From: Thiago Farina @ 2010-12-19 11:58 UTC (permalink / raw)
To: git; +Cc: pclouds, Jonathan Nieder
In-Reply-To: <97af5e0255d234e3a7ec5df1e387bec39ed94206.1292759580.git.tfransosi@gmail.com>
Forgot to copy Jonathan when using 'git send-email'. Now copying him.
On Sun, Dec 19, 2010 at 9:56 AM, Thiago Farina <tfransosi@gmail.com> wrote:
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
> ---
> Changes from v1:
> - Remove the add_list function since it's used only once per Nguyen Thai Ngoc Duy
> review.
>
> builtin/rm.c | 12 ++----------
> 1 files changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/builtin/rm.c b/builtin/rm.c
> index c7b7bb3..ff491d7 100644
> --- a/builtin/rm.c
> +++ b/builtin/rm.c
> @@ -20,15 +20,6 @@ static struct {
> const char **name;
> } list;
>
> -static void add_list(const char *name)
> -{
> - if (list.nr >= list.alloc) {
> - list.alloc = alloc_nr(list.alloc);
> - list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
> - }
> - list.name[list.nr++] = name;
> -}
> -
> static int check_local_mod(unsigned char *head, int index_only)
> {
> /*
> @@ -182,7 +173,8 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
> struct cache_entry *ce = active_cache[i];
> if (!match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen))
> continue;
> - add_list(ce->name);
> + ALLOC_GROW(list.name, list.nr + 1, list.alloc);
> + list.name[list.nr++] = ce->name;
> }
>
> if (pathspec) {
> --
> 1.7.3.2.343.g7d43d
>
>
^ permalink raw reply
* [PATCH v2] builtin/rm.c: Use ALLOC_GROW instead of alloc_nr and xrealloc.
From: Thiago Farina @ 2010-12-19 11:56 UTC (permalink / raw)
To: git; +Cc: pclouds
In-Reply-To: <AANLkTim4GE0mnCBqz6QubpL6g9Bz5U-jHoOw=_MR5-1j@mail.gmail.com>
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
Changes from v1:
- Remove the add_list function since it's used only once per Nguyen Thai Ngoc Duy
review.
builtin/rm.c | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index c7b7bb3..ff491d7 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -20,15 +20,6 @@ static struct {
const char **name;
} list;
-static void add_list(const char *name)
-{
- if (list.nr >= list.alloc) {
- list.alloc = alloc_nr(list.alloc);
- list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
- }
- list.name[list.nr++] = name;
-}
-
static int check_local_mod(unsigned char *head, int index_only)
{
/*
@@ -182,7 +173,8 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
struct cache_entry *ce = active_cache[i];
if (!match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen))
continue;
- add_list(ce->name);
+ ALLOC_GROW(list.name, list.nr + 1, list.alloc);
+ list.name[list.nr++] = ce->name;
}
if (pathspec) {
--
1.7.3.2.343.g7d43d
^ permalink raw reply related
* Re: subdirectory-filter does not delete files before the directory came into existence?
From: Jan Wielemaker @ 2010-12-19 9:34 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201012190323.59829.trast@student.ethz.ch>
On Sun, 2010-12-19 at 03:23 +0100, Thomas Rast wrote:
> Jan Wielemaker wrote:
> > The reported problems also apply to the next module. What appears to
> > work is this:
> >
> > * Walk through the history, finding the commit where the directory
> > is created.
> > * use git tag -l --contains <commit that created dir> to get the
> > tags we want to keep.
> > * get all tags, use comm and delete the tags not in the `contained'
> > set above.
> >
> > Not very friendly and I'm (with Thomas) about the status of these
> > findings. I like to thank Thomas for giving me the right clue.
>
> Now I finally remember where I knew this problem from:
>
> http://article.gmane.org/gmane.comp.version-control.git/91708
>
> (My memory really sucks.)
Funny. That was me having problems with filtering out directories
as well :-) I thought your patch was added using the --prune-empty
flag. I guess you can comment on that. I can confirm that I've got
nice and clean filtering using
* git filter-branch --subdirectory-filter <dir> --prune-empty
--tag-name-filter cat -- --all
followed by the steps above. I use qgit with the tree-view enabled
to find the place where the hierarchy changes from the complete one
to the only-this-dir one. You can do a binary search for that and
you spot the exact commit easily by the gap in the history-line. Then
I run this little bit of code:
#!/bin/bash
contains="$1"
git tag | sort > tags.all
git tag -l --contains $contains | sort > tags.keep
for t in `comm -23 tags.all tags.keep`; do
git tag -d $t
done
Not ideal, but doable.
Cheers --- Jan
^ permalink raw reply
* Commiting automatically (2)
From: Maaartin @ 2010-12-19 8:29 UTC (permalink / raw)
To: git
Some time ago I asked how to make a commit of the working tree in a way
influencing neither the current branch nor the index:
http://comments.gmane.org/gmane.comp.version-control.git/157056
I'm going to use it for taking a snapshot of the current working tree without
disturbing my work. It seem to work except for one thing:
There are files tracked by git and later added to .gitignore. AFAIK listing
them in .gitignore is a no-op, since I haven't removed them from the index.
Until now I haven't known about them at all, I'm currently undecided what to do
to them.
However, when I use my git-autocom script, those files get marked as deleted.
This is quite strange, especially because of them still existing. I'd strongly
prefer git-autocom to behave just like git commit (i.e., tracking the files).
The relevant part of my script follows:
export GIT_INDEX_FILE=.git/autocom.tmp
git add -A &&
tree=$(git write-tree) &&
commit=$(echo "$message" | git commit-tree $tree $parent1 $parent2) &&
git update-ref -m "$message" refs/heads/autocom $commit
I'd say using another index is the reason for this behavior. The index gets
created on the first use, which is probably why those files look like being
deleted. Should I always
/bin/cp .git/index $GIT_INDEX_FILE
or is there a better way?
There's one more problem. My script doesn't recognize deleted files, since
git add -A
does nothing to them. I'm quite sure I saw a solution to this, but can't find
it now...
^ permalink raw reply
* [PATCH] t2107: mark passing test as success
From: Jeff King @ 2010-12-19 3:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This failed on the branch where it was introduced, but was fixed
by merging with 6e67619 (Merge branch 'jn/parse-options-extra').
Signed-off-by: Jeff King <peff@peff.net>
---
t/t2107-update-index-basic.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t2107-update-index-basic.sh b/t/t2107-update-index-basic.sh
index 33f8be0..809fafe 100755
--- a/t/t2107-update-index-basic.sh
+++ b/t/t2107-update-index-basic.sh
@@ -13,7 +13,7 @@ test_expect_success 'update-index --nonsense fails' '
test -s msg
'
-test_expect_failure 'update-index --nonsense dumps usage' '
+test_expect_success 'update-index --nonsense dumps usage' '
test_expect_code 129 git update-index --nonsense 2>err &&
grep "[Uu]sage: git update-index" err
'
--
1.7.3.4.761.g98ad5
^ permalink raw reply related
* [PATCH] handle arbitrary ints in git_config_maybe_bool
From: Jeff King @ 2010-12-19 3:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This function recently gained the ability to recognize the
documented "0" and "1" values as false/true. However, unlike
regular git_config_bool, it did not treat arbitrary numbers
as true. While this is undocumented and probably ridiculous
for somebody to rely on, it is safer to behave exactly as
git_config_bool would. Because git_config_maybe_bool can be
used to retrofit new non-bool values onto existing bool
options, not behaving in exactly the same way is technically
a regression.
Signed-off-by: Jeff King <peff@peff.net>
---
This was posted earlier as part of the command-specific pager topic; you
ended up splitting part of that out into jk/maint-decorate-01-bool. This
should logically go on top of that (b2be2f6).
It probably doesn't make a difference in the real world, but I think it
is safer (as described above), and the code is a little cleaner. I
should have just done it this way in the first place.
config.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/config.c b/config.c
index 32c0b2c..d73b090 100644
--- a/config.c
+++ b/config.c
@@ -429,13 +429,11 @@ static int git_config_maybe_bool_text(const char *name, const char *value)
int git_config_maybe_bool(const char *name, const char *value)
{
- int v = git_config_maybe_bool_text(name, value);
+ long v = git_config_maybe_bool_text(name, value);
if (0 <= v)
return v;
- if (!strcmp(value, "0"))
- return 0;
- if (!strcmp(value, "1"))
- return 1;
+ if (git_parse_long(value, &v))
+ return !!v;
return -1;
}
--
1.7.3.4.761.g98ad5
^ permalink raw reply related
* Re: [PATCH 2/2] fill_textconv(): Don't get/put cache if sha1 is not valid
From: Junio C Hamano @ 2010-12-19 3:23 UTC (permalink / raw)
To: Kirill Smelkov
Cc: Jeff King, git, Axel Bonnet, Clément Poulain, Diane Gasselin
In-Reply-To: <20101218205514.GA21249@landau.phys.spbu.ru>
Kirill Smelkov <kirr@landau.phys.spbu.ru> writes:
> Thanks for your ACK and for the explanation.
>
> My last patches to git were blame related so semi-intuitively I knew
> that invalid sha1 are coming from files in worktree. Your description
> makes things much more clear and I'd put it into patch log as well.
> What is the best practice for this? For me to re-roll, or for Junio to
> merge texts?
Re-rolling to explain changes in your own words is preferred; thanks.
^ permalink raw reply
* Re: [PATCH] builtin/rm.c: Use ALLOC_GROW instead of alloc_nr and xrealloc.
From: Nguyen Thai Ngoc Duy @ 2010-12-19 3:02 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <ffd7b63f3ef5e409775a0d730691efdaf4e41592.1292291262.git.tfransosi@gmail.com>
On Tue, Dec 14, 2010 at 8:48 AM, Thiago Farina <tfransosi@gmail.com> wrote:
> static void add_list(const char *name)
> {
> - if (list.nr >= list.alloc) {
> - list.alloc = alloc_nr(list.alloc);
> - list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
> - }
> + ALLOC_GROW(list.name, list.nr + 1, list.alloc);
> list.name[list.nr++] = name;
> }
add_list() is only used at one place, why not remove it and put the
code back in cmd_rm()?
--
Duy
^ permalink raw reply
* Re: subdirectory-filter does not delete files before the directory came into existence?
From: Thomas Rast @ 2010-12-19 2:23 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <1292415733.11607.51.camel@hppc323.few.vu.nl>
Jan Wielemaker wrote:
> The reported problems also apply to the next module. What appears to
> work is this:
>
> * Walk through the history, finding the commit where the directory
> is created.
> * use git tag -l --contains <commit that created dir> to get the
> tags we want to keep.
> * get all tags, use comm and delete the tags not in the `contained'
> set above.
>
> Not very friendly and I'm (with Thomas) about the status of these
> findings. I like to thank Thomas for giving me the right clue.
Now I finally remember where I knew this problem from:
http://article.gmane.org/gmane.comp.version-control.git/91708
(My memory really sucks.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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