* Re: [TOY PATCH] git-resurrect: find traces of a branch name and resurrect it
From: Boyd Stephen Smith Jr. @ 2009-01-20 16:57 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901201001.54979.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
On Tuesday 2009 January 20 03:01:50 Thomas Rast wrote:
>It was really intended as a toy patch, but if people find it useful
>(Boyd?) I can add the rest of the options so that all searches can be
>chosen independently, and shape it as a "real" contrib patch.
I'll test it out later today and get back to you.
[OT]
I actually prefer Stephen; My father is Boyd.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-20 17:08 UTC (permalink / raw)
To: Brent Goodrick; +Cc: git
In-Reply-To: <18805.64312.289059.660023@hungover.brentg.com>
Hi,
On Tue, 20 Jan 2009, Brent Goodrick wrote:
> I am considering converting from CVS over to using git. I'm currently
> using git version 1.5.6.5 on Debian Linux "testing".
First of all, 1.5.6.5 is from last August, so chances are that the
behavior you complain about was fixed in the meantime. We're at 1.6.1 at
the moment.
> One of the first things I ran into was having to set PAGER to "cat" to
> avoid the problems when running git from anything other than a terminal.
> The second thing is that "git pull" (and possibly other commands) are
> emitting ^M (octal 013) codes on output, possibly caused by the same
> assumption as causes the problem that is fixed by setting PAGER to
> "cat".
The only place I can think about where a CR is output is when showing the
progress of downloading.
Usually, our code checks if stdout is a tty, and does not show progress.
As a work-around, piping into cat should work, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-20 17:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Boyd Stephen Smith Jr., Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901201058520.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> @@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
>> }
>> if (!strcmp(var, "diff.external"))
>> return git_config_string(&external_diff_cmd_cfg, var, value);
>> + if (!strcmp(var, "diff.color-words"))
>
> I'd call it diff.wordregex, because that's what it is.
If we want to add a new word-oriented option to diff that is not about
coloring the word differences, is it safe and sane to reuse the same
definition? That is, "git diff --color-words" would be affected when
diff.wordregex is set to some value, so does any new word-oriented
operation we will add, and the single regex configured would be used as
the default value to define how a word would look like.
I think it makes sense; I do not think of a case offhand where you would
want to define what a word is for the purpose of coloring diffs in one
way, and would want to use a different definition for another
word-oriented operation.
>> @@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
>> o->word_regex = userdiff_word_regex(one);
>> if (!o->word_regex)
>> o->word_regex = userdiff_word_regex(two);
>> + if (!o->word_regex)
>> + o->word_regex = diff_color_words_cfg;
>
> IMHO this is the wrong order. config should not override attributes,
> which are by definition more specific.
Isn't it merely giving a fallback value when attributes does not give one?
By the way, wouldn't it make sense to optimize the precontext of that hunk
by doing _something_ like:
if (!o->word_regex && strcmp(one->path, two->path))
o->word_regex = userdiff_word_regex(two);
"Something like" comes from special cases like /dev/null for new/deleted
files, etc.
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 17:14 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901201053.03256.bss@iguanasuicide.net>
Hi,
On Tue, 20 Jan 2009, Boyd Stephen Smith Jr. wrote:
> You are up too late Dscho.
You, sir, are absolutely correct.
> >Let's squash the two, okay?
>
> Will do. I expected the code changes to be larger than the test, and
> when I finished it was completely the other way. My next patch will be
> all-in-one.
FWIW I think it is the correct thing to start with the test script, so
that you get a better idea what to look out for.
And for patches of which I don't know if they are still necessary, I like
to "git checkout <name>^ && make -j50 && git checkout <name> && (cd t &&
sh <test>)".
But for submission, I think it makes sense to squash them, except if you
submit a bug report with a test script to show the validity of the report
first, and only later decide that you want to fix it yourself.
Ciao,
Dscho
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Matthieu Moy @ 2009-01-20 17:10 UTC (permalink / raw)
To: Dilip M; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <c94f8e120901200851n21c6d67r3c43e3efd435e3db@mail.gmail.com>
"Dilip M" <dilipm79@gmail.com> writes:
>> repeating Reece's question, what is the permissions/owner
>> _of_the_directory_which_contains_ the '.git/' directory?
>> I can reproduce this behaviour (git 1.6.0.4) simply by
>> denying myself search (née execute) permission on that
>> directory, for entirely obvious reasons.
>
> It's the same issue....
You didn't answer the question.
> Any ENV variable I can set to debug this...?
GIT_TRACE can help.
--
Matthieu
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Johannes Schindelin @ 2009-01-20 17:16 UTC (permalink / raw)
To: Dilip M; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <c94f8e120901200851n21c6d67r3c43e3efd435e3db@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1266 bytes --]
Hi,
On Tue, 20 Jan 2009, Dilip M wrote:
> On Tue, Jan 20, 2009 at 1:42 PM, Brian Foster
> <brian.foster@innova-card.com> wrote:
> > On Monday 19 January 2009 15:37:06 Dilip M wrote:
> >> On Mon, Jan 19, 2009 at 5:29 PM, Reece Dunn <msclrhd@googlemail.com> wrote:
> >> > 2009/1/19 Dilip M <dilipm79@gmail.com>:
> >> >> ..I recently install GIT on Ubuntu (hardy) box....I am able to use
> >> >> 'gitk' only If I do 'sudo'. Without 'sudo' it complains 'repository
> >> >> not found'
> >> >
> >> > Who is the owner of the repository directory (and the .git directory)
> >> > and what are the permissions on the directory? [ ... ]
> >>
> >> dm-laptop:~/repos/atria> id -a
> >> uid=1000(dm) gid=1000(dm) [ ... ]
> >> dm-laptop:~/repos/atria> ls -lh .git/
> >>[... all looks Ok ...]
> >
> > repeating Reece's question, what is the permissions/owner
> > _of_the_directory_which_contains_ the '.git/' directory?
> > I can reproduce this behaviour (git 1.6.0.4) simply by
> > denying myself search (née execute) permission on that
> > directory, for entirely obvious reasons.
>
> It's the same issue....Any ENV variable I can set to debug this...?
I'd try running it with strace, and then search the output for stat()
calls involving <something>/.git.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 17:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Boyd Stephen Smith Jr., Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <7vskndkip9.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 20 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> @@ -92,6 +93,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
> >> }
> >> if (!strcmp(var, "diff.external"))
> >> return git_config_string(&external_diff_cmd_cfg, var, value);
> >> + if (!strcmp(var, "diff.color-words"))
> >
> > I'd call it diff.wordregex, because that's what it is.
>
> If we want to add a new word-oriented option to diff that is not about
> coloring the word differences, is it safe and sane to reuse the same
> definition? That is, "git diff --color-words" would be affected when
> diff.wordregex is set to some value, so does any new word-oriented
> operation we will add, and the single regex configured would be used as
> the default value to define how a word would look like.
>
> I think it makes sense; I do not think of a case offhand where you would
> want to define what a word is for the purpose of coloring diffs in one
> way, and would want to use a different definition for another
> word-oriented operation.
Why not cross that bridge when we're there? Should we ever feel the need
for different word regexes, we would just introduce color.wordregex.
> >> @@ -1550,6 +1553,8 @@ static void builtin_diff(const char *name_a,
> >> o->word_regex = userdiff_word_regex(one);
> >> if (!o->word_regex)
> >> o->word_regex = userdiff_word_regex(two);
> >> + if (!o->word_regex)
> >> + o->word_regex = diff_color_words_cfg;
> >
> > IMHO this is the wrong order. config should not override attributes,
> > which are by definition more specific.
>
> Isn't it merely giving a fallback value when attributes does not give one?
Yep. Boyd (or Stephen, as he wants to be called, making it hard to guess
from his email address, but that's all part of the fun, in't it?) already
realized that I was up too late and got the order wrong myself.
> By the way, wouldn't it make sense to optimize the precontext of that
> hunk by doing _something_ like:
>
> if (!o->word_regex && strcmp(one->path, two->path))
> o->word_regex = userdiff_word_regex(two);
>
> "Something like" comes from special cases like /dev/null for new/deleted
> files, etc.
You mean to avoid the cost of initializing the regex in case one and the
same file is diffed against itself? But that would be better handled
before calling builtin_diff(), don't you think?
I do not know off-hand if diffcore_std() handles that already, so that the
diff_flush() ... builtin_diff() cascade is not even called.
But you raise a valid concern: the regular expression is initialized every
time we look at a file. We probably should have a member
word_regex_compiled in diff_options, then, and only initialize it the
first time.
Ciao,
Dscho "who does not have the time to work on Git right now"
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-20 17:35 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <vpq4oztgaz8.fsf@bauges.imag.fr>
On Tue, Jan 20, 2009 at 10:40 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Dilip M" <dilipm79@gmail.com> writes:
>
>>> repeating Reece's question, what is the permissions/owner
>>> _of_the_directory_which_contains_ the '.git/' directory?
>>> I can reproduce this behaviour (git 1.6.0.4) simply by
>>> denying myself search (née execute) permission on that
>>> directory, for entirely obvious reasons.
>>
>> It's the same issue....
>
> You didn't answer the question.
Sorry..I read it for .git directory...
.git's parent directory is owned by user who us issuing gitk command
and permisssion bit of 755 is set.
dm-laptop:~/repos/atria> ls -ld .
drwxr-xr-x 6 dm dm 4096 2009-01-18 23:28 .
dm-laptop:~/repos/atria> ls -ld .git/
drwxr-xr-x 8 dm dm 4096 2009-01-20 22:22 .git/
>> Any ENV variable I can set to debug this...?
>
> GIT_TRACE can help.
I tried with that but it didn't help for gitk. But sure, it helps with
git command(s).
-- DM
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Markus Heidelberg @ 2009-01-20 17:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Boyd Stephen Smith Jr., Johannes Schindelin, Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <7v1vuympie.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 20.01.2009:
> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>
> > When diff is invoked with --color-words (w/o =regex), use the regular
> > expression the user has configured as diff.color-words.
> >
> > diff drivers configured via attributes take precedence over the
> > diff.color-words setting. If the user wants to change them, they have
> > their own configuration variables.
>
> This needs an entry in Documentation/config.txt
>
> None of the existing configuration variables defined use hyphens in
> multi-word variable names.
Except for diff.suppress-blank-empty
Should it be converted or is it intention to reflect GNU diff's option?
Markus
^ permalink raw reply
* Re: [PATCH (topgit)] tg-patch: add support for generating patches against worktree and index
From: Kirill Smelkov @ 2009-01-20 17:56 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <20090120002103.GA12549@lapse.rw.madduck.net>
On Tue, Jan 20, 2009 at 11:21:03AM +1100, martin f krafft wrote:
> also sprach Kirill Smelkov <kirr@landau.phys.spbu.ru> [2009.01.19.0206 +1100]:
> > I don't understand why this gets ignored. Maybe I do something wrong?
>
> I am not ignoring it, I am just currently flooded and travelling.
> I don't see any obvious problems with your patch, but I do not have
> the time to test it right now. I will do my best to do another
> release when I return from Tasmania, hopefully on the plane trip
> home. Maybe Petr can get around to it before I do.
>
> Cheers, and sorry,
No problem and take your time.
It was just me having no idea about what's going on.
Happy travelling,
Kirill
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Boyd Stephen Smith Jr. @ 2009-01-20 17:58 UTC (permalink / raw)
To: markus.heidelberg
Cc: Junio C Hamano, Johannes Schindelin, Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <200901201842.24000.markus.heidelberg@web.de>
[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]
On Tuesday 2009 January 20 11:42:23 Markus Heidelberg wrote:
>Junio C Hamano, 20.01.2009:
>> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
>> > When diff is invoked with --color-words (w/o =regex), use the regular
>> > expression the user has configured as diff.color-words.
>> >
>> > diff drivers configured via attributes take precedence over the
>> > diff.color-words setting. If the user wants to change them, they have
>> > their own configuration variables.
>>
>> This needs an entry in Documentation/config.txt
>>
>> None of the existing configuration variables defined use hyphens in
>> multi-word variable names.
>
>Except for diff.suppress-blank-empty
>Should it be converted or is it intention to reflect GNU diff's option?
I think best would be to have a project policy, use that for the wordRegex
option and other options moving forward, then fix the others at some point in
the future (1.7?) while having some period of time where both old and "per
policy" names work. But, then I'm a big fan of standardization.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Reece Dunn @ 2009-01-20 18:00 UTC (permalink / raw)
To: Dilip M; +Cc: Matthieu Moy, Brian Foster, git list
In-Reply-To: <c94f8e120901200935t75dba11fw3ce14b4ba965c878@mail.gmail.com>
2009/1/20 Dilip M <dilipm79@gmail.com>:
> On Tue, Jan 20, 2009 at 10:40 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> "Dilip M" <dilipm79@gmail.com> writes:
>>
>>>> repeating Reece's question, what is the permissions/owner
>>>> _of_the_directory_which_contains_ the '.git/' directory?
>>>> I can reproduce this behaviour (git 1.6.0.4) simply by
>>>> denying myself search (née execute) permission on that
>>>> directory, for entirely obvious reasons.
>>>
>>> It's the same issue....
>>
>> You didn't answer the question.
>
> Sorry..I read it for .git directory...
>
> .git's parent directory is owned by user who us issuing gitk command
> and permisssion bit of 755 is set.
>
>>> Any ENV variable I can set to debug this...?
>>
>> GIT_TRACE can help.
>
> I tried with that but it didn't help for gitk. But sure, it helps with
> git command(s).
So can you run git commands that modify the git tree, e.g. git add? If
these are failing, that may explain why gitk is failing, and you can
use GIT_TRACE.
Also, do you know what commands are being executed by gitk that are
causing the failure you are experiencing?
Or... is your ENV (e.g. your PATH) the same for dm and root? In
particular, can they find the git commands? This would also be visible
by not being able to do things like `git log` (or, if it is an issue
with the deprecation of the `git-foo`-style command invocation, is the
GIT_EXEC_PATH set to point to the correct location and does dm have
the rights to execute it -- that is, is the x bit set for the
GIT_EXEC_PATH directory, as per
http://www.digizenstudio.com/blog/2008/11/09/weird-git-gui-startup-problem/?).
What error message are you getting from gitk? Is it possible to debug
gitk to find out what command is being executed and what error
code/exception it is returning/throwing?
- Reece
^ permalink raw reply
* Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-20 18:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <alpine.DEB.1.00.0901201815010.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 10:46 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 'd try running it with strace, and then search the output for stat()
> calls involving <something>/.git.
Seems like we are almost there....here is the log..
dm-laptop:~/repos/atria> grep gitk /tmp/gitk_1.log
execve("/usr/bin/gitk", ["/usr/bin/gitk"], [/* 37 vars */]) = 0
open("/usr/bin/gitk", O_RDONLY) = 3
execve("/usr/bin/wish8.4", ["/usr/bin/wish8.4", "/usr/bin/gitk",
"--"], [/* 37 vars */]) = 0
stat("/usr/bin/gitk", {st_mode=S_IFREG|0755, st_size=237778, ...}) = 0
open("/usr/bin/gitk", O_RDONLY) = 6
lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/usr/share/gitk/lib/msgs/en_in.msg", F_OK) = -1 ENOENT (No
such file or directory) <======
lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/usr/share/gitk/lib/msgs/en.msg", F_OK) = -1 ENOENT (No such
file or directory) <======
stat("/home/dm/.gitk", {st_mode=S_IFREG|0644, st_size=683, ...}) = 0
open("/home/dm/.gitk", O_RDONLY) = 6
writev(5, [{"\22\0\7\0\16\0@\3\'\0\0\0\37\0\0\0\10NG\0\4\0\0\0gitk\20"...,
48}], 1) = 48
writev(5, [{"\22\0\7\0\16\0@\3(\1\0\0\37\1\0\0\10AME\4\0\0\0gitk\22"...,
112}], 1) = 112
dm-laptop:~/repos/atria> ls -l /usr/share/gitk/lib/msgs/en_in.msg
ls: cannot access /usr/share/gitk/lib/msgs/en_in.msg: No such file or directory
But how is it working when I do 'sudo'..
-- DM
^ permalink raw reply
* Re: [PATCH resend] bash completion: add 'rename' subcommand to git-remote
From: Markus Heidelberg @ 2009-01-20 18:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vd4em8ilx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, 17.01.2009:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Markus Heidelberg <markus.heidelberg@web.de> wrote:
> >>
> >> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
> >
> > Acked-by: Shawn O. Pearce <spearce@spearce.org>
> >
> >> I've just accidently read in the completion file itself, that
> >> Shawn is the maintainer, so I give it a third try. The first two
> >> haven't been sent to him.
> >
> > Sorry, I must have missed the other two attempts. :-)
>
> And I seem to have missed all three.
I really don't like to bother you again, but compared to the inclusion
of the other patches, I guess you have forgotten the third try of this
patch.
Thus this fourth try :)
Markus
> >> contrib/completion/git-completion.bash | 4 ++--
> >> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> >> index 049ded0..6623344 100755
> >> --- a/contrib/completion/git-completion.bash
> >> +++ b/contrib/completion/git-completion.bash
> >> @@ -1384,7 +1384,7 @@ _git_config ()
> >>
> >> _git_remote ()
> >> {
> >> - local subcommands="add rm show prune update"
> >> + local subcommands="add rename rm show prune update"
> >> local subcommand="$(__git_find_subcommand "$subcommands")"
> >> if [ -z "$subcommand" ]; then
> >> __gitcomp "$subcommands"
> >> @@ -1392,7 +1392,7 @@ _git_remote ()
> >> fi
> >>
> >> case "$subcommand" in
> >> - rm|show|prune)
> >> + rename|rm|show|prune)
> >> __gitcomp "$(__git_remotes)"
> >> ;;
> >> update)
> >> --
> >> 1.6.1.35.g0c23
^ permalink raw reply
* SOLVED: Re: gitk doesn't work w/o sudo.
From: Dilip M @ 2009-01-20 18:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Foster, Reece Dunn, git list
On Tue, Jan 20, 2009 at 11:50 PM, Dilip M <dilipm79@gmail.com> wrote:
> On Tue, Jan 20, 2009 at 10:46 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> 'd try running it with strace, and then search the output for stat()
>> calls involving <something>/.git.
>
> Seems like we are almost there....here is the log..
>
> dm-laptop:~/repos/atria> grep gitk /tmp/gitk_1.log
> execve("/usr/bin/gitk", ["/usr/bin/gitk"], [/* 37 vars */]) = 0
> open("/usr/bin/gitk", O_RDONLY) = 3
> execve("/usr/bin/wish8.4", ["/usr/bin/wish8.4", "/usr/bin/gitk",
> "--"], [/* 37 vars */]) = 0
> stat("/usr/bin/gitk", {st_mode=S_IFREG|0755, st_size=237778, ...}) = 0
> open("/usr/bin/gitk", O_RDONLY) = 6
> lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> access("/usr/share/gitk/lib/msgs/en_in.msg", F_OK) = -1 ENOENT (No
> such file or directory) <======
> lstat("/usr/share/gitk", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/usr/share/gitk/lib/msgs", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> access("/usr/share/gitk/lib/msgs/en.msg", F_OK) = -1 ENOENT (No such
> file or directory) <======
> stat("/home/dm/.gitk", {st_mode=S_IFREG|0644, st_size=683, ...}) = 0
> open("/home/dm/.gitk", O_RDONLY) = 6
> writev(5, [{"\22\0\7\0\16\0@\3\'\0\0\0\37\0\0\0\10NG\0\4\0\0\0gitk\20"...,
> 48}], 1) = 48
> writev(5, [{"\22\0\7\0\16\0@\3(\1\0\0\37\1\0\0\10AME\4\0\0\0gitk\22"...,
> 112}], 1) = 112
>
> dm-laptop:~/repos/atria> ls -l /usr/share/gitk/lib/msgs/en_in.msg
> ls: cannot access /usr/share/gitk/lib/msgs/en_in.msg: No such file or directory
>
> But how is it working when I do 'sudo'..
Just re-installed tcl/tk...it is working fine..:)
Many thanks to Reece Dunn, Johannes Schindelin, Brian Foster....who
all helped me out...:)
-- DM
^ permalink raw reply
* Re: John (zzz) Doe <john.doe@xz> (Comment)
From: Kirill Smelkov @ 2009-01-20 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vmydoxxcr.fsf_-_@gitster.siamese.dyndns.org>
On Sun, Jan 18, 2009 at 10:50:12AM -0800, Junio C Hamano wrote:
> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>
> AUTHOR_EMAIL=john.doe@xz
> AUTHOR_NAME="John (zzz) Doe (Comment)"
>
> and leave it like so, I think.
Ok, here you are:
Subject: [PATCH 1/3] mailinfo: cleanup extra spaces for complex 'From'
As described in RFC822 (3.4.3 COMMENTS, and A.1.4.), comments, as e.g.
John (zzz) Doe <john.doe@xz> (Comment)
should "NOT [be] included in the destination mailbox"
On the other hand, quoting Junio:
> The above quote from the RFC is irrelevant. Note that it is only about
> how you extract the e-mail address, discarding everything else.
>
> What mailinfo wants to do is to separate the human-readable name and the
> e-mail address, and we want to use _both_ results from it.
>
> We separate a few example From: lines like this:
>
> Kirill Smelkov <kirr@smelkov.xz>
> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>
> kirr@smelkov.xz (Kirill Smelkov)
> ==> AUTHOR_EMAIL="kirr@smelkov.xz" AUTHOR_NAME="Kirill Smelkov"
>
> Traditionally, the way people spelled their name on From: line has been
> either one of the above form. Typically comment form (i.e. the second
> one) adds the name at the end, while "Name <addr>" form has the name at
> the front. But I do not think RFC requires that, primarily because it is
> all about discarding non-address part to find the e-mail address aka
> "destination mailbox". It does not specify how humans should interpret
> the human readable name and the comment.
>
> Now, why is the name not AUTHOR_NAME="(Kirill Smelkov)" in the latter
> form?
>
> It is just common sense transformation. Otherwise it looks simply ugly,
> and it is obvious that the parentheses is not part of the name of the
> person who used "kirr@smelkov.xz (Kirill Smelkov)" on his From: line.
>
> So we can separate "John (zzz) Doe <john.doe@xz> (Comment)" into:
>
> AUTHOR_EMAIL=john.doe@xz
> AUTHOR_NAME="John (zzz) Doe (Comment)"
>
> and leave it like so, I think.
So let's just correctly remove extra spaces which could be left inside
name.
We need this functionality to pass all RFC2047 based tests in the next commit.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
builtin-mailinfo.c | 21 +++++++++++++++++----
t/t5100/info0001 | 2 +-
t/t5100/sample.mbox | 4 ++--
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index dacc8ac..8030823 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -29,6 +29,9 @@ static struct strbuf **p_hdr_data, **s_hdr_data;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
+static void cleanup_space(struct strbuf *sb);
+
+
static void get_sane_name(struct strbuf *out, struct strbuf *name, struct strbuf *email)
{
struct strbuf *src = name;
@@ -109,10 +112,14 @@ static void handle_from(const struct strbuf *from)
strbuf_add(&email, at, el);
strbuf_remove(&f, at - f.buf, el + (at[el] ? 1 : 0));
- /* The remainder is name. It could be "John Doe <john.doe@xz>"
- * or "john.doe@xz (John Doe)", but we have removed the
- * email part, so trim from both ends, possibly removing
- * the () pair at the end.
+ /* The remainder is name. It could be
+ *
+ * - "John Doe <john.doe@xz>" (a), or
+ * - "john.doe@xz (John Doe)" (b), or
+ * - "John (zzz) Doe <john.doe@xz> (Comment)" (c)
+ *
+ * but we have removed the email part, so trim from both ends, possibly
+ * removing the () pair at the end for case 'b'.
*/
strbuf_trim(&f);
if (f.buf[0] == '(' && f.len && f.buf[f.len - 1] == ')') {
@@ -120,6 +127,12 @@ static void handle_from(const struct strbuf *from)
strbuf_setlen(&f, f.len - 1);
}
+ /* Otherwise we want comments to stay. It's just time to cleanup extra
+ * spaces
+ */
+ cleanup_space(&f);
+ strbuf_trim(&f);
+
get_sane_name(&name, &f, &email);
strbuf_release(&f);
}
diff --git a/t/t5100/info0001 b/t/t5100/info0001
index 8c05277..f951538 100644
--- a/t/t5100/info0001
+++ b/t/t5100/info0001
@@ -1,4 +1,4 @@
-Author: A U Thor
+Author: A (zzz) U Thor (Comment)
Email: a.u.thor@example.com
Subject: a commit.
Date: Fri, 9 Jun 2006 00:44:16 -0700
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 38725f3..4f80b82 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -2,10 +2,10 @@
From nobody Mon Sep 17 00:00:00 2001
-From: A
+From: A (zzz)
U
Thor
- <a.u.thor@example.com>
+ <a.u.thor@example.com> (Comment)
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: [PATCH] a commit.
--
1.6.1.79.g92b9.dirty
Is it ok?
And by the way, please pull the whole updated series from
git://repo.or.cz/git/kirr.git for-junio-maint
Kirill Smelkov (3):
mailinfo: cleanup extra spaces for complex 'From'
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U Thor)'
mailinfo: tests for RFC2047 examples
Thanks,
Kirill
^ permalink raw reply related
* Re: [PATCH 2/2] expand --pretty=format color options
From: Jeff King @ 2009-01-20 19:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, René Scharfe, Markus Heidelberg, git
In-Reply-To: <alpine.DEB.1.00.0901201553200.5159@intel-tinevez-2-302>
On Tue, Jan 20, 2009 at 03:58:29PM +0100, Johannes Schindelin wrote:
> > The behavior I would propose it along the lines of:
> >
> > - plumbing _always_ has color off
> >
> > - porcelain respects color.* config, --color, etc
>
> Right, that'd be the sane behavior, even for %Cred.
OK, good. I think our disagreement was just confused wording on both
sides, then.
-Peff
^ permalink raw reply
* Re: [PATCH,v4] git-checkout(1): mention fate of extraneous files
From: jidanni @ 2009-01-20 19:45 UTC (permalink / raw)
To: gitster; +Cc: bss, git, johannes.schindelin
In-Reply-To: <7vy6x6odiw.fsf@gitster.siamese.dyndns.org>
Thank you all for your responses. I hope one day the git-checkout man
page will document what git-checkout does.
I believe that when classified in terms of their differing fates,
there are two or three different types of files that might be sitting
around in one's working tree at the time a "git checkout comes down on
their heads".
Perhaps a brief table of their different fates might nice to have on
the bottom of the man page.
OK, never mind.
^ permalink raw reply
* Newbie Query
From: Chris Willard @ 2009-01-20 19:19 UTC (permalink / raw)
To: Git List
Hello All,
I am having a go at using git and need a bit of help.
I have git installed on my laptop and on my pc. I created some files
on the pc then used git close via ssh to put them on my laptop - all
OK so far!
I then modified the files, added them, commited the changes and then
used git push to put them on the PC - still no problems.
Both systems show the commits but the PC does not have the latest
version of the files. Git status on the PC shows the file as changed
but commiting give an error when pushing from the laptop.
I assume that I need to run a command on the PC to get both systems
the same. Is it a reset or something else?
Regards,
Chris
--
... "Even the gods did not spring into being overnight." Spock
--
This message was scanned by ESVA and is believed to be clean.
^ permalink raw reply
* Re: parent-filter loses my merged branch -- what am I doing wrong?
From: Ask Bjørn Hansen @ 2009-01-20 20:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <49743CB7.4030300@viscovery.net>
On Jan 19, 2009, at 0:41, Johannes Sixt wrote:
> Ask Bjørn Hansen schrieb:
>> On Sam Villain's recommendation I'm spending a bit of time cleaning
>> up
>> the branches and merges with git filter-branch, but I don't think I'm
>> quite understanding how it's supposed to work.
>
> Don't use --parent-filter for this; use grafts. You can see the
> history in
> gitk right away. Later run filter-branch without a filter (except
> perhaps
> the tag-name-filter).
Aha - excellent. I didn't understand clearly from the documentation
that they'd be "written in stone" by filter-branch. Building the
grafts with .git/info/grafts was much much easier.
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Ludvig Strigeus @ 2009-01-20 20:09 UTC (permalink / raw)
To: git
Hi,
I'm having some weird problem with Git on Cygwin on Windows XP. I
start with a totally clean repo, and then run interactive rebase to
edit a historical commit. I exit the editor without doing anything (I
get similar issues if I modify stuff inside the editor).
$ git st
# On branch master
nothing to commit (working directory clean)
$ git rebase -i 4a1552c81b622f85b0e9170c6fd7a22b4a3e633c
error: git checkout-index: unable to create file util/stringfuncs.cpp
(File exists)
fatal: Could not reset index file to revision '4965936'.
error: Entry 'util/boink-py.cc' not uptodate. Cannot merge.
fatal: merging of trees 0c27b10e163f00655486976896d096302b0f5c21 and
7c7dfd93d678cfc564649738d45260e0b5d9f5a7 failed
Could not apply d9c7ac9... Various reorganizations.
Any clues?
Thanks,
Ludde
^ permalink raw reply
* Re: An idea: maybe Git should use a lock/unlock file mode for problematic files? [Was: Re: after first git clone of linux kernel repository there are changed files in working dir]
From: Daniel Barkalow @ 2009-01-20 20:11 UTC (permalink / raw)
To: thestar; +Cc: Hannu Koivisto, rdkrsr, git
In-Reply-To: <20090120105228.xbo3gyc0odwcgcsc@webmail.fussycoder.id.au>
On Tue, 20 Jan 2009, thestar@fussycoder.id.au wrote:
> Quoting Hannu Koivisto <azure@iki.fi>:
> <snip>
> > Kernel source contains pairs of files whose names differ only by
> > case. Windows cannot store such pairs (at least by default) and
> > apparently there is no support for such a situation in git so
> > you'll only get one file from each pair to your workspace and the
> > other file is shown as modified.
>
> Could git be modified to allow such repositories to be used on windows
> by locking files that are problematic, for example, a given repository
> could have files 'AAA' and 'aAa'.
>
> The one that correctly represents the on-disk file would be 'open for
> edit', while the other file would be locked. To edit the other file,
> the existing file would need to be locked, and then the other file
> would then need to be open for edit.
>
> This could even be extended to allow one to "open file AAA for edit as
> aAa.v2', giving the file an alternate name.
>
> Such a workflow would only need to be used for such files, and could
> also be used when there are incompatible file names for that given
> partition type.
The hard part is actually identifying what the user's filesystem has done.
There's pretty good internal support for git knowing that, for a
particular entry, the filesystem should not be consulted for information.
I don't think anyone's come up with a suitably cross-platform and
automatic way to figure out what's happened when git tries to write to a
particular filename and the system decides it is the same as some other
filename or it decides to use a different filename instead.
Of course, it is reasonably likely that a project whose files can't all be
checked out can't be dealt with anyway on that platform (IIRC, the Linux
kernel build system assumes that it can create both .S and .s files, so it
won't build on FAT). So nobody's been sufficiently motivated to try to
implement a fix.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git rebase -i failing on cygwin -- git checkout-index says File Exists
From: Ludvig Strigeus @ 2009-01-20 20:12 UTC (permalink / raw)
To: git
In-Reply-To: <4285cd450901201209i792195dfmdec1fb14d627b25e@mail.gmail.com>
By the way, the version I use is:
$ git --version
git version 1.6.1.48.ge9b8
/Ludde
On Tue, Jan 20, 2009 at 9:09 PM, Ludvig Strigeus <strigeus@gmail.com> wrote:
> Hi,
>
> I'm having some weird problem with Git on Cygwin on Windows XP. I
> start with a totally clean repo, and then run interactive rebase to
> edit a historical commit. I exit the editor without doing anything (I
> get similar issues if I modify stuff inside the editor).
>
> $ git st
> # On branch master
> nothing to commit (working directory clean)
>
> $ git rebase -i 4a1552c81b622f85b0e9170c6fd7a22b4a3e633c
> error: git checkout-index: unable to create file util/stringfuncs.cpp
> (File exists)
> fatal: Could not reset index file to revision '4965936'.
> error: Entry 'util/boink-py.cc' not uptodate. Cannot merge.
> fatal: merging of trees 0c27b10e163f00655486976896d096302b0f5c21 and
> 7c7dfd93d678cfc564649738d45260e0b5d9f5a7 failed
> Could not apply d9c7ac9... Various reorganizations.
>
> Any clues?
>
> Thanks,
> Ludde
>
^ permalink raw reply
* Re: Newbie Query
From: Sverre Rabbelier @ 2009-01-20 20:16 UTC (permalink / raw)
To: Chris Willard; +Cc: Git List
In-Reply-To: <20090120191952.GA25322@uts.thewillards.local>
Heya,
On Tue, Jan 20, 2009 at 20:19, Chris Willard <chris@thewillards.co.uk> wrote:
> I then modified the files, added them, commited the changes and then
> used git push to put them on the PC - still no problems.
>
> Both systems show the commits but the PC does not have the latest
> version of the files. Git status on the PC shows the file as changed
> but commiting give an error when pushing from the laptop.
Please read http://git.or.cz/gitwiki/GitFaq#head-b96f48bc9c925074be9f95c0fce69bcece5f6e73
and let us know if you have any other problems.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Newbie Query
From: Reece Dunn @ 2009-01-20 20:17 UTC (permalink / raw)
To: Chris Willard; +Cc: Git List
In-Reply-To: <20090120191952.GA25322@uts.thewillards.local>
2009/1/20 Chris Willard <chris@thewillards.co.uk>:
> Hello All,
>
> I then modified the files, added them, commited the changes and then
> used git push to put them on the PC - still no problems.
>
> Both systems show the commits but the PC does not have the latest
> version of the files. Git status on the PC shows the file as changed
> but commiting give an error when pushing from the laptop.
>
> I assume that I need to run a command on the PC to get both systems
> the same. Is it a reset or something else?
So IIUC running 'git log' on the machine you pushed the changes to,
you can see the checkin you made on the machine you made the change
on? You need to run 'git checkout' on the machine you pushed to, to
tell git that you want these files. This is a safety feature, since
someone may be working on the files on that machine locally, and so
doesn't want them being overwritten by your push.
You may find the documentation (http://git-scm.com/documentation)
useful, especially
http://www.kernel.org/pub/software/scm/git/docs/everyday.html which
has your scenario under "Push into another repository. ".
If you want someone to take some changes you made, it is recommended
to let them know so that they can run 'git pull' or 'git fetch' to get
your changes (performing a merge or rebase as desired). This means
that they control when they get the updates and what they want to do
with them.
If you are committing the files to a shared public repository (e.g. a
central repository, or build server repository), a pussible approach
is to create that as a "bare" repository (one with just the contents
of the .git folder - i.e. it does not have any files checked out). You
can do this by running:
git clone --bare source/git/path/project project.git
you can then clone from this:
git clone my/shared/project.git
and push any changes to it as normal.
The build server can then do a 'git pull' to get the new changes from
that repository.
You can keep it setup like you currently have (assuming that where you
are pushing to is a shared repository), and do:
git checkout HEAD
before you run a build (assuming this is the repository that you are
using for your builds). The advantage of a bare repository is that it
will take up less space, and using a different (cloned) repository for
performing builds keeps the main repository clean.
One of the great things about git is that you can customise it to fit
different workflows.
HTH,
- Reece
^ 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