* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Jonathan Nieder @ 2011-01-11 13:27 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git, Elijah Newren
In-Reply-To: <20110108000131.GR6040@onerussian.com>
Yaroslav Halchenko wrote [abbreviated]:
> CONFLICT (file/directory): There is a directory with name frontiers/code in todonotloose. Adding frontiers/code as frontiers/code~HEAD
> % git ls-files -u
> 160000 a2b5787 2 frontiers/code
> % git diff-tree todonotloose
> a00c497
> :040000 040000 40427e3 c7ba910 M poster-hbm2011_neurodebian
> % git diff-tree todonotloose^ HEAD
> :100644 100644 378e137 c39ced7 M .gitmodules
> :000000 040000 0000000 141dbc1 A challenge-execpapers
> :040000 040000 401fd66 ee190f0 M frontiers
> :040000 040000 26c884a ad3e829 M sty
Here is what happens.
In the heart of merge_trees:
/*
* If there are D/F conflicts, and the paths currently exist
* in the working copy as a file, remove them to make room
* for the corresponding directory. Such paths will later be
* processed in process_df_entry() at the end.
*
* If the corresponding directory ends up being removed by the
* merge, then the file will be reinstated at that time;
* otherwise, if the file is not supposed to be removed by the
* merge, the contents of the file will be placed in another
* unique filename.
*/
make_room_for_directories_of_df_conflicts(o, entries);
In this case I suppose it is rather a directory/submodule conflict; in
any case, there are no regular files involved, so this logic does not
kick in and the directory is left alone.
Next comes rename handling, which is irrelevant for our purposes.
Next comes the per entry merge.
/*
* Per entry merge. D/F conflicts are deferred so files
* contained in such a directory can be resolved first.
*/
for (i = 0; i < entries->nr; i++) {
const char *path = entries->items[i].string;
struct stage_data *e = entries->items[i].util;
if (!e->processed
&& !process_entry(o, path, e))
clean = 0;
}
This is case B: "added in one" (like all directories, the
frontiers/code directory does not have an index entry, while the
submodule does have one). Since that path is in the current directory
set, it is deferred for later processing.
Next comes the per entry merge for D/F conflicts (process_df_entry in
merge-recursive.c). This is the case "directory -> (directory,
file)". Unfortunately the check that the old and new directories
match is not implemented. Even worse, git checks for a directory
(which was not moved out of the way before) and does not realize that
a submodule might be another reason for a directory in the worktree.
In any event, we get a spurious conflict.
Thanks, that was interesting (no patch yet, alas).
^ permalink raw reply
* Re: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: Jakub Narebski @ 2011-01-11 13:21 UTC (permalink / raw)
To: Алексей Шумкин
Cc: git
In-Reply-To: <746745466.20110111134101@mail.ru>
=?windows-1251?B?wOvl6vHl6SDY8+zq6O0=?= <zapped@mail.ru> writes:
> 1.5 years ago I had sources of a project in a SVN repository (actually it does not
> matter what SCM was used before). And I had two branches: v2.4 and v2.5.
> They differed enough at that moment and (as usual for SVN branches)
> laid in two different folders.
> Then I had known of Git and I decided to try to use this powerful DVCS.
> But as I was a newbie I created two git-repositories: one per each
> branch. So v2.4 has its own git-repo. v2.5 (and above) has another one.
>
> Now I'd like to merge them as v2.5 was a continuos branch from v2.4,
> but without a rebasing (i.e. without a global changing of v2.5
> repository, which already has another branches)
> It must look like LAST commit of v2.4 should be a PARENT of FIRST commit of v2.5
>
> Now there's a question: Is it possible to do so (no rebasing!), and If
> "yes" then how to?
As Andreas Ericsson wrote, you can do this using grafts (and you can
make history with grafts permanent using "git filter-branch").
Better solution might be to use more modern replace mechanism, see
e.g. "git replace" manpage. Below there is untested step-by-step
instruction.
First, you have put history of v2.4 and of v2.5 in a single repository
(e.g. using "git remote add"). Then you need to find FIRST commit of
v2.5 among
$ git rev-list master --parents | grep -v ' '
The above finds all parent-less commits in 'master' branch; replace it
with branch holding v2.5 history. Then you need to find LAST commit
of v2.4 and its SHA-1, e.g. via
$ git rev-parse v2.4
Save current state of FIRST commit of v2.5 to a file
$ git cat-file -p FIRST > tmp
Edit this file, adding 'parent' line between 'tree' and 'author'
headers, so the header of this file looks like the following:
tree 13d050266e05f7c66000240814199fcf3b559d43
parent ada9983c4256f5a7bac1f7f0e29d52011741d6aa
author Jakub Narebski <jnareb@gmail.com> 1294231771 +0100
(trailing space added for better readibility).
Then you need to add newly created object to repository:
$ git hash-object -t commit -w tmp
and then use it as replacement
$ git replace <SHA-1 of FIRST> <SHA-1 returned by hash-object>
Finally check that replacement works, e.g.:
$ git show FIRST
$ git log --graph --oneline -3 FIRST
The anyone who would fetch refs/replace/ would get joined history, and
who doesn't would see it not connected.
P.S. This probably should made it into Documentation/howto
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git notes and core.editor config
From: Jeenu V @ 2011-01-11 13:12 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <201101111336.19466.johan@herland.net>
On Tue, Jan 11, 2011 at 6:06 PM, Johan Herland <johan@herland.net> wrote:
>> $ git --version
>> git version 1.7.0.4
>
> Ah, there's your problem. In v1.7.1 "git notes" was builtin-ified (it
> used to be a shell script, but was reimplemented in C), so you're still
> running the shell script version of "git notes". I believe upgrading
> will solve your problem (as well as making "git notes" more
> featureful).
>
Alright, I'll try upgrading then. Thanks.
--
Jeenu
^ permalink raw reply
* Re: Re[2]: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: "Martin Krüger" @ 2011-01-11 12:47 UTC (permalink / raw)
To: "ÐлекÑей Шумкин"
Cc: git
In-Reply-To: <76067992.20110111153329@mail.ru>
> Thank you for the answer, but it's not what I want ))
> Applying patches is the same as rebasing, I guess.
> But I do not want to change v2.5-repo (let's call it so) that much.
> I'd like to know is there any method (low-level I suppose, as far as Git
> manages tree-objects as files) to make v2.4 LAST commit to be the
> parent of v2.5 FIRST commit?
>
This is impossible.
The commit-id is calculated from the history of the whole repository.
So you must rebase in the sense of dependency on another history.
My method enables to rebase on the same content of the repository.
^ permalink raw reply
* Re: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: Andreas Ericsson @ 2011-01-11 12:41 UTC (permalink / raw)
To: Алексей Шумкин
Cc: Martin Krüger, git
In-Reply-To: <76067992.20110111153329@mail.ru>
On 01/11/2011 01:33 PM, Алексей Шумкин wrote:
> Thank you for the answer, but it's not what I want ))
> Applying patches is the same as rebasing, I guess.
> But I do not want to change v2.5-repo (let's call it so) that much.
> I'd like to know is there any method (low-level I suppose, as far as Git
> manages tree-objects as files) to make v2.4 LAST commit to be the
> parent of v2.5 FIRST commit?
>
You want grafts. Check them up in the docs. Googling for "git graft"
should get you a good starting point.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [RFC] Support for arbitrary tags in commits
From: Thomas Rast @ 2011-01-11 12:40 UTC (permalink / raw)
To: Philipp Marek; +Cc: git
In-Reply-To: <74b0628dffbd2bc0adabe5e8b0a10960.squirrel@webmail.hitco.org>
Philipp Marek wrote:
>
> The best way I've found (so far) is to put an additional header line in the
> commit header that references an additional blob.
This comes up every few months. The last large discussion about this
that we had IIRC was
http://thread.gmane.org/gmane.comp.version-control.git/138848
Can you please look through that thread and state in what way your
use-case invalidates the previous reasoning?
In particular, in what way do notes (as in git-notes(1)) fail to solve
your problem?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: git notes and core.editor config
From: Johan Herland @ 2011-01-11 12:36 UTC (permalink / raw)
To: Jeenu V; +Cc: git
In-Reply-To: <AANLkTik-=s-F8dmBRLU8o9LcSztb1P0WnkN5HK_n_No4@mail.gmail.com>
On Tuesday 11 January 2011, Jeenu V wrote:
> On Tue, Jan 11, 2011 at 4:01 PM, Johan Herland <johan@herland.net>
wrote:
> > On Tuesday 11 January 2011, Jeenu V wrote:
> >> My core.editor value in $HOME/.gitconfig is set to
> >>
> >> [core]
> >> editor = vi "+set tw=72 spell"
> >>
> >> so that I've text width of 72 with spell check turned on. I
> >> haven't found problems with any git commands that invoke editor,
> >> but notes. 'git notes' seems to invoke the vi for me with 3
> >> separate arguments instead of just one: "+set, tw=72, and spell".
> >> In other words, I don't think it honors shell quoting for editor
> >> config variable.
> >>
> >> Could this be a bug?
> >
> > What Git version are you running?
>
> $ git --version
> git version 1.7.0.4
Ah, there's your problem. In v1.7.1 "git notes" was builtin-ified (it
used to be a shell script, but was reimplemented in C), so you're still
running the shell script version of "git notes". I believe upgrading
will solve your problem (as well as making "git notes" more
featureful).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re[2]: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: Алексей Шумкин @ 2011-01-11 12:33 UTC (permalink / raw)
To: "Martin Krüger"; +Cc: git
In-Reply-To: <20110111114943.40890@gmx.net>
Thank you for the answer, but it's not what I want ))
Applying patches is the same as rebasing, I guess.
But I do not want to change v2.5-repo (let's call it so) that much.
I'd like to know is there any method (low-level I suppose, as far as Git
manages tree-objects as files) to make v2.4 LAST commit to be the
parent of v2.5 FIRST commit?
MK> It's possible with a little arts an crafts.
MK> You have 2 friends: git format-patch & git am .
MK> With "git format-patch" you will see what a branch really is:
MK> a serie of patches. With "git am" you can apply these patches
MK> to a branch created on the correct point of the commit-history . E
MK> voila the branch is recreated in the repository.
MK> In your case:
MK> On the 2.5 repository master branch:
MK> git format-patch INITIAL_COMMITID
MK> On the 2.4 repository master branch:
MK> git branch 2.5
MK> git checkout 2.4
MK> git reset --hard INITIAL_COMMITID
MK> cat *.patch | git am
MK> E voila you habe both branches in a single repository.
MK> Nearly same procedure for every branch of the 2.5 repository
MK> git checkout branchname
MK> git format-patch master
MK> In the 2.4(Contains now both branches.) respository:
MK> git checkout 2.5
MK> git branch branchname
MK> git reset --hard CORRECT_BRANCHBASE
MK> cat *.patch | git am
^ permalink raw reply
* [RFC] Support for arbitrary tags in commits
From: Philipp Marek @ 2011-01-11 12:23 UTC (permalink / raw)
To: git
Hello everybody,
I'd like to attach some additional data to commits.
The best way I've found (so far) is to put an additional header line in the
commit header that references an additional blob.
Currently I've found "tree", "parent", "author", "committer", and so on; git
accepts additional lines before the "\n\n" separator (and the commit message),
so that's where I'd like to put the line.
"git fsck" allows that, too; only "rebase -i" and similar don't know about them
(yet), and discard them.
Now I want to ask:
* Is this acceptable?
* If yes, I'd try to provide a patch to make "amend" and similar keep the
header-lines (by collecting them in order - obviously with editing commits
a header could exist multiple times).
* Perhaps there should be an option for "git-commit" that inserts arbitrary
header lines?
* Is there some documentation for the commit-file format so that this can be
written down?
* How should namespace-issues be handled?
I can imagine that multiple people want to put data there, how should the
tag be allocated?
This could be solved by the previous point, ie. there's some page that
header tags should be registered at to avoid collisions.
Thank you for all feedback.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
^ permalink raw reply
* Re: git notes and core.editor config
From: Thomas Rast @ 2011-01-11 12:26 UTC (permalink / raw)
To: Jeenu V; +Cc: Johan Herland, git
In-Reply-To: <AANLkTik-=s-F8dmBRLU8o9LcSztb1P0WnkN5HK_n_No4@mail.gmail.com>
Jeenu V wrote:
> On Tue, Jan 11, 2011 at 4:01 PM, Johan Herland <johan@herland.net> wrote:
> >> In other words, I
> >> don't think [git-notes] honors shell quoting for editor config variable.
> >
> > Indeed, it could, but I cannot immediately see what causes it. In
> > current 'master', builtin/notes.c launches the editor like this:
> >
> > if (launch_editor(path, &(msg->buf), NULL)) ...
> >
> > while builtin/commit.c lauches the editor like this:
> >
> > if (launch_editor(git_path(commit_editmsg), NULL, env)) ...
[...]
> $ git --version
> git version 1.7.0.4
git-notes was a script before 1.7.1, and that was indeed buggy in that
it used the editor as
${GIT_EDITOR:-${core_editor:-${VISUAL:-${EDITOR:-vi}}}} "$MSG_FILE"
instead of using git_editor() from git-sh-setup, which would have gone
through eval.
The builtin version of git-notes does not have this problem.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Michael J Gruber @ 2011-01-11 12:11 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4D220500.2000104@syntevo.com>
Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:
> I'm looking for an unobtrusive way to apply (committed) changes for
> text/eol attributes to the working tree. For instance, after having
> changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
> converted from CRLF to LF endings. The only advice I found so far is to
> remove .git/index and do a reset --hard. The disadvantage of this
> approach is that every file will be touched:
>
> - although the content does not change, timestamps will be changed. This
The bytewise content does change.
> makes tools like IDEs assume that the file content has been changed.
It may be that the content is semantically equivalent.
> (Even if the timestamps would be properly reset, the replacement of the
> files would have triggered system file change notifications and I'd
> expect various tools to still reload these files)
>
> - there will be warnings for files which are locked by other processes
> (at least on Windows). I'm usually seeing this for JAR files which are
> not affected by eol-attribute changes at all.
>
> One solution I could think of which might be helpful in other situations
> as well would be to have an "--unobtrusive" option for reset which would
> only replace a file if the content has actually been changed.
How about
git ls-files \*.txt | xargs touch -a
git ls-files \*.txt | git checkout
?
^ permalink raw reply
* Re: Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: "Martin Krüger" @ 2011-01-11 11:49 UTC (permalink / raw)
To: "ÐлекÑей Шумкин",
git
In-Reply-To: <746745466.20110111134101@mail.ru>
>
> Now I'd like to merge them as v2.5 was a continuos branch from v2.4,
> but without a rebasing (i.e. without a global changing of v2.5
> repository, which already has another branches)
> It must look like LAST commit of v2.4 should be a PARENT of FIRST commit
> of v2.5
>
> Now there's a question: Is it possible to do so (no rebasing!), and If
> "yes" then how to?
>
>
It's possible with a little arts an crafts.
You have 2 friends: git format-patch & git am .
With "git format-patch" you will see what a branch really is:
a serie of patches. With "git am" you can apply these patches to a branch created on the correct point of the commit-history . E voila the branch is recreated in the repository.
In your case:
On the 2.5 repository master branch:
git format-patch INITIAL_COMMITID
On the 2.4 repository master branch:
git branch 2.5
git checkout 2.4
git reset --hard INITIAL_COMMITID
cat *.patch | git am
E voila you habe both branches in a single repository.
Nearly same procedure for every branch of the 2.5 repository
git checkout branchname
git format-patch master
In the 2.4(Contains now both branches.) respository:
git checkout 2.5
git branch branchname
git reset --hard CORRECT_BRANCHBASE
cat *.patch | git am
Best regards
martin
^ permalink raw reply
* Re: git notes and core.editor config
From: Jeenu V @ 2011-01-11 11:14 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <201101111131.17429.johan@herland.net>
On Tue, Jan 11, 2011 at 4:01 PM, Johan Herland <johan@herland.net> wrote:
> On Tuesday 11 January 2011, Jeenu V wrote:
>> My core.editor value in $HOME/.gitconfig is set to
>>
>> [core]
>> editor = vi "+set tw=72 spell"
>>
>> so that I've text width of 72 with spell check turned on. I haven't
>> found problems with any git commands that invoke editor, but notes.
>> 'git notes' seems to invoke the vi for me with 3 separate arguments
>> instead of just one: "+set, tw=72, and spell". In other words, I
>> don't think it honors shell quoting for editor config variable.
>>
>> Could this be a bug?
>
> Indeed, it could, but I cannot immediately see what causes it. In
> current 'master', builtin/notes.c launches the editor like this:
>
> if (launch_editor(path, &(msg->buf), NULL)) ...
>
> while builtin/commit.c lauches the editor like this:
>
> if (launch_editor(git_path(commit_editmsg), NULL, env)) ...
>
> In both cases, the details of interpreting core.editor is left to
> git_default_core_config(), and passed to launch_editor() using the
> editor_program global variable. AFAICS there is no difference between
> how "notes" and "commit" interprets core.editor.
>
> What Git version are you running?
$ git --version
git version 1.7.0.4
--
Jeenu
^ permalink raw reply
* Merge two different repositories (v2.4 + v2.5) into the one (v2.4 -> v2.5). Possible?
From: Алексей Шумкин @ 2011-01-11 10:41 UTC (permalink / raw)
To: git
Hi all!
1.5 years ago I had sources of a project in a SVN repository (actually it does not
matter what SCM was used before). And I had two branches: v2.4 and v2.5.
They differed enough at that moment and (as usual for SVN branches)
laid in two different folders.
Then I had known of Git and I decided to try to use this powerful DVCS.
But as I was a newbie I created two git-repositories: one per each
branch. So v2.4 has its own git-repo. v2.5 (and above) has another one.
Now I'd like to merge them as v2.5 was a continuos branch from v2.4,
but without a rebasing (i.e. without a global changing of v2.5
repository, which already has another branches)
It must look like LAST commit of v2.4 should be a PARENT of FIRST commit of v2.5
Now there's a question: Is it possible to do so (no rebasing!), and If
"yes" then how to?
^ permalink raw reply
* [BUG] difference of info from diff and blame
From: Semyon Kirnosenko @ 2011-01-11 10:38 UTC (permalink / raw)
To: git
Hi.
I'm working on automatic processing of info from git. And I have some
problems. Let me show it on an axample.
I have jquery repo (https://github.com/jquery/jquery.git)
Let's get blame for some file in some revision:
git blame -l -s 2ad223aedd1f93c783d98d60adc9fda3bdfbb4b6 --
src/event/event.js
According to blame, line 127 was added in revision
2ad223aedd1f93c783d98d60adc9fda3bdfbb4b6.
Let's get diff for that revision:
git diff-tree -p 2ad223aedd1f93c783d98d60adc9fda3bdfbb4b6 --
src/event/event.js
We can see this:
@@ -105,19 +120,16 @@ jQuery.event = {
// Handle triggering a single element
else {
- var handler = element["on" + type ], val,
- fn = jQuery.isFunction( element[ type
+ var val, ret, fn = jQuery.isFunction( element
+
+ // Pass along a fake event
+ data.unshift( this.fix({ type: type, target:
- if ( handler ) {
As you can see line 127 is not marked with '+' char, which means it was
not added in this revision. But blame sad otherwise.
I had the same problem on a wide range of repos.
I think it's a bug.
^ permalink raw reply
* Re: git notes and core.editor config
From: Johan Herland @ 2011-01-11 10:31 UTC (permalink / raw)
To: Jeenu V; +Cc: git
In-Reply-To: <AANLkTi=0BrBV+DLF_QfDi0mMVdz5tCLFsDMBKvw52nzz@mail.gmail.com>
On Tuesday 11 January 2011, Jeenu V wrote:
> My core.editor value in $HOME/.gitconfig is set to
>
> [core]
> editor = vi "+set tw=72 spell"
>
> so that I've text width of 72 with spell check turned on. I haven't
> found problems with any git commands that invoke editor, but notes.
> 'git notes' seems to invoke the vi for me with 3 separate arguments
> instead of just one: "+set, tw=72, and spell". In other words, I
> don't think it honors shell quoting for editor config variable.
>
> Could this be a bug?
Indeed, it could, but I cannot immediately see what causes it. In
current 'master', builtin/notes.c launches the editor like this:
if (launch_editor(path, &(msg->buf), NULL)) ...
while builtin/commit.c lauches the editor like this:
if (launch_editor(git_path(commit_editmsg), NULL, env)) ...
In both cases, the details of interpreting core.editor is left to
git_default_core_config(), and passed to launch_editor() using the
editor_program global variable. AFAICS there is no difference between
how "notes" and "commit" interprets core.editor.
What Git version are you running?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* git notes and core.editor config
From: Jeenu V @ 2011-01-11 10:11 UTC (permalink / raw)
To: git
My core.editor value in $HOME/.gitconfig is set to
[core]
editor = vi "+set tw=72 spell"
so that I've text width of 72 with spell check turned on. I haven't
found problems with any git commands that invoke editor, but notes.
'git notes' seems to invoke the vi for me with 3 separate arguments
instead of just one: "+set, tw=72, and spell". In other words, I don't
think it honors shell quoting for editor config variable.
Could this be a bug?
--
Jeenu
^ permalink raw reply
* Re: Applying .gitattributes text/eol changes
From: Marc Strapetz @ 2011-01-11 9:29 UTC (permalink / raw)
To: git
In-Reply-To: <4D220500.2000104@syntevo.com>
Any ideas on this?
Thanks,
Marc.
On 03.01.2011 18:18, Marc Strapetz wrote:
> I'm looking for an unobtrusive way to apply (committed) changes for
> text/eol attributes to the working tree. For instance, after having
> changed "*.txt eol=crlf" to "*.txt eol=lf", all *.txt files should be
> converted from CRLF to LF endings. The only advice I found so far is to
> remove .git/index and do a reset --hard. The disadvantage of this
> approach is that every file will be touched:
>
> - although the content does not change, timestamps will be changed. This
> makes tools like IDEs assume that the file content has been changed.
> (Even if the timestamps would be properly reset, the replacement of the
> files would have triggered system file change notifications and I'd
> expect various tools to still reload these files)
>
> - there will be warnings for files which are locked by other processes
> (at least on Windows). I'm usually seeing this for JAR files which are
> not affected by eol-attribute changes at all.
>
> One solution I could think of which might be helpful in other situations
> as well would be to have an "--unobtrusive" option for reset which would
> only replace a file if the content has actually been changed.
>
> Marc.
> --
> 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] userdiff: match Pascal class methods
From: Alexey Shumkin @ 2011-01-11 8:53 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Class declarations were already covered by the second pattern, but class methods have the 'class' keyword in front too. Account for it.
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
Acked-by: Thomas Rast <trast@student.ethz.ch>
---
userdiff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/userdiff.c b/userdiff.c
index f9e05b5..259a382 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -52,7 +52,7 @@ PATTERNS("objc",
"|[-+*/<>%&^|=!]=|--|\\+\\+|<<=?|>>=?|&&|\\|\\||::|->"
"|[^[:space:]]|[\x80-\xff]+"),
PATTERNS("pascal",
- "^((procedure|function|constructor|destructor|interface|"
+ "^(((class[ \t]+)?(procedure|function)|constructor|destructor|interface|"
"implementation|initialization|finalization)[ \t]*.*)$"
"\n"
"^(.*=[ \t]*(class|record).*)$",
--
1.7.3.4.3.g3f811
^ permalink raw reply related
* Re: [PATCH 2/2] t/README: hint about using $(pwd) rather than $PWD in tests
From: Johannes Sixt @ 2011-01-11 8:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20110111083729.GD9445@burratino>
Am 1/11/2011 9:37, schrieb Jonathan Nieder:
> I suspect that the reader will end up wondering "why does this have to
> be so complicated" no matter what.
Unfortunately, yes. Therefore, I'd like to keep the paragraph minimal,
focused on how expected values should be constructed, which is where
errors will happen primarily.
>>> It makes a difference on Windows, where
>>>
>>> - $(pwd) is a Windows-style path such as git might output, and
>>> - $PWD is a Unix-style path that the shell (MSYS bash) will
>>> mangle before passing to native apps like git.
>>
>> This information is already included by reference to 4114156ae9.
>
> ... but if we can summarize it nicely, we can save the reader a
> step, no?
I don't think so: it's not complete enough. Readers will ask: "So what?"
Digging archives or a three paragraph follow-up explanation on the ML will
be required anyway.
> Anyway, what you have already written is useful; clearing up these
> details would just be icing on the top.
OK, thanks for a review.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/2] t/README: hint about using $(pwd) rather than $PWD in tests
From: Jonathan Nieder @ 2011-01-11 8:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4D2C11A5.4050709@viscovery.net>
Johannes Sixt wrote:
> Am 1/11/2011 8:54, schrieb Jonathan Nieder:
>> Perhaps it is also worth explaining the cases where $PWD is needed?
>>
>> By contrast, when a passing a path to git or constructing a URL,
>> use $PWD.
>
> The first part of the "or" is not true: you can pass the result of $(pwd)
> to a command, and it means the same as $PWD; I would even recommend
> against $PWD so that a reader does not have to wonder "why pass $PWD, but
> check for $(pwd)?"
I _think_ that passing $PWD always gives the right result. By
contrast, constructions like
PATH=$(pwd)/bin:$PATH
break iirc.
I suspect that the reader will end up wondering "why does this have to
be so complicated" no matter what.
> The second part I don't know whether it is true: I haven't noticed a
> pattern where people did it the wrong way, therefore, I'don't even know
> whether $PWD is really *always* required. Do *you* know?
24f1136 is one example. I don't know of any utility that treats
file://c:/foo/bar/baz
as a URL representing a resource on localhost (and msys bash has no
rewriting rule for it), so in that particular case
(file://$directory), $PWD really does seem to be always required.
>> It makes a difference on Windows, where
>>
>> - $(pwd) is a Windows-style path such as git might output, and
>> - $PWD is a Unix-style path that the shell (MSYS bash) will
>> mangle before passing to native apps like git.
>
> This information is already included by reference to 4114156ae9.
... but if we can summarize it nicely, we can save the reader a
step, no?
Anyway, what you have already written is useful; clearing up these
details would just be icing on the top.
^ permalink raw reply
* Re: [PATCH 2/2] t/README: hint about using $(pwd) rather than $PWD in tests
From: Johannes Sixt @ 2011-01-11 8:15 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20110111075441.GB9445@burratino>
Am 1/11/2011 8:54, schrieb Jonathan Nieder:
> Perhaps it is also worth explaining the cases where $PWD is needed?
>
> By contrast, when a passing a path to git or constructing a URL,
> use $PWD.
The first part of the "or" is not true: you can pass the result of $(pwd)
to a command, and it means the same as $PWD; I would even recommend
against $PWD so that a reader does not have to wonder "why pass $PWD, but
check for $(pwd)?"
The second part I don't know whether it is true: I haven't noticed a
pattern where people did it the wrong way, therefore, I'don't even know
whether $PWD is really *always* required. Do *you* know?
> It makes a difference on Windows, where
>
> - $(pwd) is a Windows-style path such as git might output, and
> - $PWD is a Unix-style path that the shell (MSYS bash) will
> mangle before passing to native apps like git.
This information is already included by reference to 4114156ae9.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/2] t/README: hint about using $(pwd) rather than $PWD in tests
From: Jonathan Nieder @ 2011-01-11 7:54 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4D2C0A5E.7090708@viscovery.net>
Johannes Sixt wrote:
> This adds just a "do it this way" instruction without a lot of explanation,
> because the details are too complex to be explained at this point.
Thanks, looks very useful.
> --- a/t/README
> +++ b/t/README
> @@ -283,6 +283,12 @@ Do:
> Tests that are likely to smoke out future regressions are better
> than tests that just inflate the coverage metrics.
>
> + - When a test checks for an absolute path that a git command generated,
> + construct the expected value using $(pwd) rather than $PWD,
> + $TEST_DIRECTORY, or $TRASH_DIRECTORY. It makes a difference on
> + Windows, where the shell (MSYS bash) mangles absolute path names.
> + For details, see the commit message of 4114156ae9.
> +
Perhaps it is also worth explaining the cases where $PWD is needed?
By contrast, when a passing a path to git or constructing a URL,
use $PWD. It makes a difference on Windows, where
- $(pwd) is a Windows-style path such as git might output, and
- $PWD is a Unix-style path that the shell (MSYS bash) will
mangle before passing to native apps like git.
^ permalink raw reply
* git-repack & big files
From: Pietro Battiston @ 2011-01-11 7:37 UTC (permalink / raw)
To: git
Hello,
first, I do know git is not optimized for big files, and that's fine.
But it is able, on my machine with 3 GB of RAM, to succesfully backup my
home directory¹, which contains, among others, several files of several
hundreds of megabytes each. And I like that a lot.
Since it perfectly does what it is not optimized to do... I then wonder
when it does not do what it declares: if I run git-repack² with the
parameter --window-memory set to, for instance, "100m", it takes
hundreds and hundreds of MB of memory until it runs out of memory, fails
a malloc and aborts.
So, two questions:
1) is there a bug, is the documentation about that parameter a bit too
optimistic or did I just not understand it?
2) do I have any hope that in one way or another my 500+ MB mailboxes
with relatively small changes over time are archived smartly (=diffs) by
git at the current state of development? If I understand correctly, the
project git-bigfiles³ would just "solve" my problems by not making
differences of big files.
thanks for the clarifications
Pietro
¹ Just for the records: through gibak:
http://eigenclass.org/hiki/gibak-0.3.0
² git version 1:1.7.2.3-2.2 on Debian
³ http://caca.zoy.org/wiki/git-bigfiles
^ permalink raw reply
* [PATCH 2/2] t/README: hint about using $(pwd) rather than $PWD in tests
From: Johannes Sixt @ 2011-01-11 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Nguyen Thai Ngoc Duy, git
In-Reply-To: <4D2C09D7.3070700@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
This adds just a "do it this way" instruction without a lot of explanation,
because the details are too complex to be explained at this point.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/README | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/README b/t/README
index 90718b4..f98ebb3 100644
--- a/t/README
+++ b/t/README
@@ -283,6 +283,12 @@ Do:
Tests that are likely to smoke out future regressions are better
than tests that just inflate the coverage metrics.
+ - When a test checks for an absolute path that a git command generated,
+ construct the expected value using $(pwd) rather than $PWD,
+ $TEST_DIRECTORY, or $TRASH_DIRECTORY. It makes a difference on
+ Windows, where the shell (MSYS bash) mangles absolute path names.
+ For details, see the commit message of 4114156ae9.
+
Don't:
- exit() within a <script> part.
--
1.7.4.rc1.1258.g84aa
^ permalink raw reply related
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