* 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
* Re: [PATCH] diff: Support diff.color-words config option
From: Junio C Hamano @ 2009-01-20 20:27 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.0901201819490.5159@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 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?
No.
What I meant is much simpler than that.
If one and two are the same filename, and earlier gitattributes lookup for
the path already failed to produce any when you checked one, isn't it very
likely that the gitattributes lookup for two would fail the same way to
produce any result?
^ permalink raw reply
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
From: Daniel Barkalow @ 2009-01-20 20:29 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
In-Reply-To: <63BEA5E623E09F4D92233FB12A9F794302BC6851@emailmn.mqsoftware.com>
On Tue, 20 Jan 2009, Kelly F. Hickel wrote:
> Hello all,
>
> Back in June I had done a test convert of our CVS repo using git 1.5.5.1
> and cvs2svn 2.2.0 that went reasonably well (although it takes nearly a
> week to finish!). Recently I wanted to try again with the latest
> versions of git and cvs2svn.
>
> When I get to the final stage (running git fast-import to build the
> converted repo), I get the following output:
> cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
> fast-import
> fatal: Unsupported command: '.
> fast-import: dumping crash report to .git/fast_import_crash_19097
>
> The crash is 18MB and I'd rather not post it, but the only bits that
> seem somewhat interesting are:
> fast-import crash report:
> fast-import process: 19097
> parent process : 19095
> at Mon Jan 19 11:44:42 2009
>
> fatal: Unsupported command: '.
>
> Most Recent Commands Before Crash
> ---------------------------------
> (...)
> reset refs/tags/T_9772
> from :1000007127
> reset refs/heads/TAG.FIXUP
>
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> * '.
>
>
> Has anyone got any ideas how to resolve this?
Can you find that part of the input? I wouldn't be too surprised if
something were giving the wrong length in a data command, causing it to
either eat another data command and end up in the data or to use
not-quite-all of the data and end up near the end of the data.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Newbie Query
From: Tomas Carnecky @ 2009-01-20 20:00 UTC (permalink / raw)
To: Chris Willard; +Cc: Git List
In-Reply-To: <20090120191952.GA25322@uts.thewillards.local>
On 01/20/2009 08:19 PM, Chris Willard wrote:
> 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?
http://git.or.cz/gitwiki/GitFaq#non-bare
tom
^ permalink raw reply
* Re: [TOY PATCH] git-resurrect: find traces of a branch name and resurrect it
From: Boyd Stephen Smith Jr. @ 2009-01-20 20:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901201057.18127.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On Tuesday 2009 January 20 10:57:17 Boyd Stephen Smith Jr. wrote:
>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.
In my particular case, it wasn't useful without the -m option, but I
understand why it is not the default.
I think it could be quite nice; "undelete"-type commands are generally
well-received by users and when run against reflogs alone, that's what the
command is.
It's useful enough to me that I'd love to see it mainlined.
--
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: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 21:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Boyd Stephen Smith Jr., Santi Béjar, Thomas Rast, git,
Teemu Likonen
In-Reply-To: <7vk58pk9k5.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 20 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> 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?
>
> No.
>
> What I meant is much simpler than that.
>
> If one and two are the same filename, and earlier gitattributes lookup for
> the path already failed to produce any when you checked one, isn't it very
> likely that the gitattributes lookup for two would fail the same way to
> produce any result?
Oh, I see!
Thanks,
Dscho
^ permalink raw reply
* Re: Newbie Query
From: Nicolas Morey-Chaisemartin @ 2009-01-20 21:07 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git List
In-Reply-To: <3f4fd2640901201217x22262655w115cc2a25e32865e@mail.gmail.com>
Reece Dunn a écrit :
>
> 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.
>
>
Hi,
I did the rookie mistkae on the central server to create the main
reposity in non-bare mode. So i need to checkout the HEAD revision each
time I push.
Is there a cleaner way to convert a non-bare git repo into a bare repo
than cloning it?
My repo have a lot of remote branch registered, and cloning them to a
new bare repo mean I'll have to add all those remote branches again
(except if there is another trick here I don't know about).
Regards
Nicolas
^ permalink raw reply
* Re: [PATCH] diff: Support diff.color-words config option
From: Johannes Schindelin @ 2009-01-20 21:08 UTC (permalink / raw)
To: Markus Heidelberg
Cc: Junio C Hamano, Boyd Stephen Smith Jr., Santi Béjar,
Thomas Rast, git, Teemu Likonen
In-Reply-To: <200901201842.24000.markus.heidelberg@web.de>
Hi,
On Tue, 20 Jan 2009, 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?
Grumble. It's in v1.6.1-rc1~348, so we cannot just go ahead and fix it.
My preference would be to convert it _except_ that the old name should
still work. But it should not be advertized.
Ciao,
Dscho "who loves consistency, and knows new users appreciate it, too"
-- snipsnap --
[PATCH] Rename diff.suppress-blank-empty to diff.suppressBlankEmpty
All the other config variables use CamelCase. This config variable should
not be an exception.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/config.txt | 2 +-
diff.c | 4 +++-
t/t4029-diff-trailing-space.sh | 8 ++++----
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c92e7e6..4f0a0b1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -652,7 +652,7 @@ diff.renames::
will enable basic rename detection. If set to "copies" or
"copy", it will detect copies, as well.
-diff.suppress-blank-empty::
+diff.suppressBlankEmpty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
diff --git a/diff.c b/diff.c
index c6a992d..0100b59 100644
--- a/diff.c
+++ b/diff.c
@@ -118,7 +118,9 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
}
/* like GNU diff's --suppress-blank-empty option */
- if (!strcmp(var, "diff.suppress-blank-empty")) {
+ if (!strcmp(var, "diff.suppressblankempty") ||
+ /* for backwards compatibility */
+ !strcmp(var, "diff.suppress-blank-empty")) {
diff_suppress_blank_empty = git_config_bool(var, value);
return 0;
}
diff --git a/t/t4029-diff-trailing-space.sh b/t/t4029-diff-trailing-space.sh
index 4ca65e0..9ddbbcd 100755
--- a/t/t4029-diff-trailing-space.sh
+++ b/t/t4029-diff-trailing-space.sh
@@ -2,7 +2,7 @@
#
# Copyright (c) Jim Meyering
#
-test_description='diff honors config option, diff.suppress-blank-empty'
+test_description='diff honors config option, diff.suppressBlankEmpty'
. ./test-lib.sh
@@ -24,14 +24,14 @@ test_expect_success \
git add f &&
git commit -q -m. f &&
printf "\ny\n" > f &&
- git config --bool diff.suppress-blank-empty true &&
+ git config --bool diff.suppressBlankEmpty true &&
git diff f > actual &&
test_cmp exp actual &&
perl -i.bak -p -e "s/^\$/ /" exp &&
- git config --bool diff.suppress-blank-empty false &&
+ git config --bool diff.suppressBlankEmpty false &&
git diff f > actual &&
test_cmp exp actual &&
- git config --bool --unset diff.suppress-blank-empty &&
+ git config --bool --unset diff.suppressBlankEmpty &&
git diff f > actual &&
test_cmp exp actual
'
--
1.6.1.439.g22f77c
^ permalink raw reply related
* Re: gitk doesn't work w/o sudo.
From: Johannes Schindelin @ 2009-01-20 21:10 UTC (permalink / raw)
To: Dilip M; +Cc: Brian Foster, Reece Dunn, git list
In-Reply-To: <c94f8e120901201020g32fad692p214fdf1640a4796f@mail.gmail.com>
Hi,
On Tue, 20 Jan 2009, Dilip M 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'..
Let's find out. You can run the strace with sudo, too.
I bet it uses another git.
Ciao,
Dscho
^ 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 22:08 UTC (permalink / raw)
To: John Chapman; +Cc: Hannu Koivisto, rdkrsr, git
In-Reply-To: <1232486929.4179.7.camel@therock.nsw.bigpond.net.au>
On Wed, 21 Jan 2009, John Chapman wrote:
> On Tue, 2009-01-20 at 15:11 -0500, Daniel Barkalow wrote:
> <snip>
> >
> > 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.
>
> This would only need to interact with the git status command, wouldn't
> it?
The information is needed in a bunch of commands (diff and add, for
example), but I believe that's already taken care on. The problem is
getting it set automatically instead of having git not notice that the
filesystem isn't doing what it expects.
> > 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.
>
> I doubt the kernel builds on windows, but this would allow a windows
> user to modify such files, perhaps in preparation for a patch that does
> allow the kernel to be built on windows?
> (Of course, we're using the kernel here as an example, right? Nobody
> would be insane as to want to use windows for that!)
>
> See, a very annoying thing about windows is that it is quite simple for
> a team to commit two files that differ by case alone to a git
> repository.
My impression was that this didn't happen in practice, because teams
would tend to not have two people create the same file at the same time,
but with different cases, and people interacting with the same file at
different times would use whatever case it was introduced with.
I think I'd only heard about problems for people who were using
filesystems with different properties than what the rest of the developers
on the project were using.
But I've only ever worked on projects that expect case-sensitivity, and
mostly on projects that have a standard style that prevents duplication.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Rename detection: Avoid repeated filespec population
From: Jeff King @ 2009-01-20 22:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20090120212723.GA10967@coredump.intra.peff.net>
On Tue, Jan 20, 2009 at 04:27:23PM -0500, Jeff King wrote:
> I have a pathological real-world rename test case from a long time ago.
> It's so awful on rename because almost the whole repo was reorganized,
> but almost every path got its content adjusted, too. I was hoping it
> would be better with your patch, but it isn't: as it turns out, it is
> _too_ uniform. The cheap size checks don't work because all of the files
> are almost the same size (they're all jpgs from a camera).
Nevermind, I'm stupid. Your patch _does_ yield a significant improvement
for my test case. I was accidentally comparing your patch to some of my
previous optimization attempts, not to vanilla git.
Without your patch, I get:
$ time git show -l0 06d28867 >/dev/null
841.88user 146.95system 17:18.99elapsed 95%CPU (0avgtext+0avgdata 0maxresident)k
2476880inputs+0outputs (19372major+27092797minor)pagefaults 0swaps
With it, I get:
$ time git show -l0 06d28867 >/dev/null
100.51user 5.76system 2:31.07elapsed 70%CPU (0avgtext+0avgdata 0maxresident)k
2020176inputs+0outputs (15771major+836127minor)pagefaults 0swaps
So much much better.
-Peff
^ permalink raw reply
* Re: Newbie Query
From: Nicolas Morey-Chaisemartin @ 2009-01-20 21:46 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901201534.16571.bss@iguanasuicide.net>
Boyd Stephen Smith Jr. a écrit :
> On Tuesday 2009 January 20 15:07:55 Nicolas Morey-Chaisemartin wrote:
>
>> I did the rookie mistkae on the central server to create the main
>> reposity in non-bare mode. So i need to checkout the HEAD revision each
>> time I push.
>> Is there a cleaner way to convert a non-bare git repo into a bare repo
>> than cloning it?
>> My repo have a lot of remote branch registered, and cloning them to a
>> new bare repo mean I'll have to add all those remote branches again
>> (except if there is another trick here I don't know about).
>>
>
> Well, if you can make sure no one is pushing into the repo for a bit: clone it
> and replace the original with a symlink to new, bare one. Your clients will
> be able to use the same URL, so they should be happy. (I haven't tried this,
> but it should work.)
>
Well I know there are solutions to convert it to a bare repo.
I was just wondering if there was a "clean" one which really converts
the repo to a bare one and not create a copy which is bare.
I don't know how bare/non-bare is managed but I guess both types of repo
are not differing by much, so it'd be great to have a function to
convert from one to another.
^ permalink raw reply
* Re: Newbie Query
From: Boyd Stephen Smith Jr. @ 2009-01-20 21:34 UTC (permalink / raw)
To: devel; +Cc: git
In-Reply-To: <49763D2B.1000607@morey-chaisemartin.com>
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]
On Tuesday 2009 January 20 15:07:55 Nicolas Morey-Chaisemartin wrote:
>I did the rookie mistkae on the central server to create the main
>reposity in non-bare mode. So i need to checkout the HEAD revision each
>time I push.
>Is there a cleaner way to convert a non-bare git repo into a bare repo
>than cloning it?
>My repo have a lot of remote branch registered, and cloning them to a
>new bare repo mean I'll have to add all those remote branches again
>(except if there is another trick here I don't know about).
Well, if you can make sure no one is pushing into the repo for a bit: clone it
and replace the original with a symlink to new, bare one. Your clients will
be able to use the same URL, so they should be happy. (I haven't tried this,
but it should work.)
--
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
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