* Re: [PATCH (GIT-GUI,GITK) 6/8] gitk: Port new encoding logic from git-gui.
From: Johannes Sixt @ 2008-09-19 13:04 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Shawn O. Pearce, Paul Mackerras
In-Reply-To: <bb6f213e0809190538m5bbfeb38o5510d06fa6757dd1@mail.gmail.com>
Alexander Gavrilov schrieb:
> On Fri, Sep 19, 2008 at 4:10 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> If I run
>>
>> $ LANG=C gitk 146ed90
>>
>> with this series on the git-gui repository, then I hoped to see the text
>> in the patches in the right encoding. But I understand that I expected too
>> much - the patch text is just a stream of bytes that comes from different
>> files, and the best you can do is to apply the system encoding.
>>
>> But if the view is switched to the tree view, and file contents are
>> inspected, then this patch should help. But it doesn't. If you look at
>> po/ja.po, it is appearent that the file was not read as UTF-8, which is
>> dictated by .gitattributes.
>
> On my system everything works. You must have made a mistake somewhere.
Indeed. I was running above command form a git.git clone. Now, looking at
anything that is in 146ed90 produces paths like
po/de.po
po/ja.po
Yet, .gitattributes says this:
/po/*.po encoding=UTF-8
which does not match any of the *.po files because the *.po are one level
deeper inside git-gui/po/. The change below made a difference.
Everything's fine now!
diff --git a/git-gui/.gitattributes b/git-gui/.gitattributes
index f96112d..8ad5766 100644
--- a/git-gui/.gitattributes
+++ b/git-gui/.gitattributes
@@ -1,3 +1,3 @@
* encoding=US-ASCII
git-gui.sh encoding=UTF-8
-/po/*.po encoding=UTF-8
+*.po encoding=UTF-8
> Also, it should work in the patch mode as well: it reads the patch as
> binary, and decodes each line separately, based on the encoding
> determined for the current file.
This is great. But we'll have to see how this works on a multi-file diff
on Windows. (I sense slowness.)
Thanks,
-- Hannes
^ permalink raw reply related
* Re: Branches with git-svn
From: Björn Steinbrink @ 2008-09-19 13:10 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Xavier Claessens, git
In-Reply-To: <48D39C7B.9020709@drmicha.warpmail.net>
On 2008.09.19 14:35:07 +0200, Michael J Gruber wrote:
> Xavier Claessens venit, vidit, dixit 19.09.2008 12:15:
> > I created a git repository using "git-svn clone <url>" a long time ago.
> > But now I realise that I don't get SVN branches into my git repository.
> > I see that the doc tells to use "git clone -t tags -b branches -T trunk
> > <url>" to create the repository. If I create a new repository with that
> > command, I get branches and tags.
> >
> > However I have lots of contributors having branches based on my git
> > repository. Is there a way to add SVN branch to my existing git repo?
>
> If you haven't use those options back then, then what was the svn repo
> structure - no trunk, just main?
> Did you change the structure now?
No, he was just using "git svn clone svn://host/repo/trunk", ie. single
branch tracking. We solved that on #git, adjusting the url and fetch
line, as well as adding the branches and tags line in the svn-remote
section in the config.
Björn
^ permalink raw reply
* Re: Branches with git-svn
From: Xavier Claessens @ 2008-09-19 13:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <48D39C7B.9020709@drmicha.warpmail.net>
On ven, 2008-09-19 at 14:35 +0200, Michael J Gruber wrote:
> Xavier Claessens venit, vidit, dixit 19.09.2008 12:15:
> > Hi,
> >
> > I created a git repository using "git-svn clone <url>" a long time ago.
> > But now I realise that I don't get SVN branches into my git repository.
> > I see that the doc tells to use "git clone -t tags -b branches -T trunk
> > <url>" to create the repository. If I create a new repository with that
> > command, I get branches and tags.
> >
> > However I have lots of contributors having branches based on my git
> > repository. Is there a way to add SVN branch to my existing git repo?
>
> If you haven't use those options back then, then what was the svn repo
> structure - no trunk, just main?
> Did you change the structure now?
>
> If you git-svn fetch from that new structure then all your new branches
> etc. will show up as subdirectories, which is most certainly not what
> you want.
>
> So, what was the structure in svn like before, and have your
> contributors based their branches on the mis-imported new structure already?
Hi,
Thanks for your email, but Björn Steinbrink on IRC solved my problem.
For the record what I did is:
1) make a new "git svn clone -t tags -b branches -T trunk <url>"
2) copy/past the description of the "svn" remote in .git/config from the
new clone into my old repository. Just replaced, in right part of the
fetch line, "trunk" by "git-svn"
3) "git svn fetch" imported all branches correctly based on the commits
I already have.
Thanks to all git and git-svn developers to make my life easier!
Xavier Claessens.
^ permalink raw reply
* [PATCH] Typo "bogos" in format-patch error message.
From: Mikael Magnusson @ 2008-09-19 13:42 UTC (permalink / raw)
To: git
---
builtin-log.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index f4975cf..69cf564 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -835,7 +835,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
committer = git_committer_info(IDENT_ERROR_ON_NO_NAME);
endpos = strchr(committer, '>');
if (!endpos)
- die("bogos committer info %s\n", committer);
+ die("bogus committer info %s\n", committer);
add_signoff = xmemdupz(committer, endpos - committer + 1);
}
else if (!strcmp(argv[i], "--attach")) {
--
Mikael Magnusson
^ permalink raw reply related
* GIT server over HTTP
From: Hinko Kocevar @ 2008-09-19 13:31 UTC (permalink / raw)
To: git
Hi,
I'm trying to migrate from SVN to GIT and are facing some problems with setting up public GIT repository accessible via HTTP for pull and push. I'm runnig 2.6.26 kernel on Gentoo Linux with apache 2 and git 1.5.6.4. Following the http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt I managed to get following done:
1. create GIT repo in /home/hinkok/public_html:
$ mkdir ~/public_html/gitrepo.git
$ cd ~/public_html/gitrepo.git
$ git --bare init
$ sudo chown -R apache:apache .
2. Create DAV entry for apache web server
$ cat /etc/apache2/modules.d/48_mod_dav_git.conf
<Location /~hinkok/gitrepo.git>
DAV on
# AuthType None
AuthType Basic
AuthName "Git"
AuthUserFile /home/hinkok/passwd.git
Require valid-user
</Location>
$ htpasswd -c ~/passwd.git hinkok
$ cat ~/passwd.git
hinkok:t9871siBkRbaU
$ cat ~/.netrc
machine localhost
login hinkok
password hinkok
3. Test GIT location
$ curl --netrc --location http://hinkok@localhost/~hinkok/gitrepo.git/HEAD
ref: refs/heads/master
Firefox also requests user auth for http://hinkok@localhost/~hinkok/gitrepo.git
4. Pushing some changes to the remote repo
$ cd /tmp
$ mkdir gt
$ cd gt/
$ git init
$ git-config remote.upload.url http://hinkok@localhost/~hinkok/gitrepo.git/
$ git push upload master
error: Cannot access URL http://hinkok@localhost/~hinkok/gitrepo.git/, return code 22
error: failed to push some refs to 'http://hinkok@localhost/~hinkok/gitrepo.git/'
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "upload"]
url = http://hinkok@localhost/~hinkok/gitrepo.git/
$ sudo tail /var/log/apache2/error_log
[Fri Sep 19 15:29:20 2008] [notice] Apache/2.2.9 (Unix) DAV/2 mod_ssl/2.2.9 OpenSSL/0.9.8g SVN/1.5.1 PHP/5.2.6-pl6-gentoo configured -- resuming normal operations
[Fri Sep 19 15:31:03 2008] [error] [client 127.0.0.1] client denied by server configuration: /home/hinkok/public_html/gitrepo.git/
What am I missing here?
Thank you,
Hinko
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@cetrtapot.si
Http: www.cetrtapot.si
^ permalink raw reply
* [PATCH] git-repack uses --no-repack-object, not --no-repack-delta.
From: Mikael Magnusson @ 2008-09-19 13:43 UTC (permalink / raw)
To: git
---
Documentation/git-repack.txt | 2 +-
git-repack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 38ac609..bbe1485 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -60,7 +60,7 @@ OPTIONS
linkgit:git-pack-objects[1].
-f::
- Pass the `--no-reuse-delta` option to 'git-pack-objects'. See
+ Pass the `--no-reuse-object` option to `git-pack-objects`, see
linkgit:git-pack-objects[1].
-q::
diff --git a/git-repack.sh b/git-repack.sh
index 683960b..d39eb6c 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -10,7 +10,7 @@ git repack [options]
a pack everything in a single pack
A same as -a, and turn unreachable objects loose
d remove redundant packs, and run git-prune-packed
-f pass --no-reuse-delta to git-pack-objects
+f pass --no-reuse-object to git-pack-objects
n do not run git-update-server-info
q,quiet be quiet
l pass --local to git-pack-objects
--
Mikael Magnusson
^ permalink raw reply related
* [Useless PATCH to contrib/examples/git-remote.perl] Typo "does not exists" when git remote update remote.
From: Mikael Magnusson @ 2008-09-19 13:48 UTC (permalink / raw)
To: git
---
I fixed this a few weeks before the git-remote C rewrite then never got
around to sending it...
contrib/examples/git-remote.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/examples/git-remote.perl b/contrib/examples/git-remote.perl
index 36bd54c..b17952a 100755
--- a/contrib/examples/git-remote.perl
+++ b/contrib/examples/git-remote.perl
@@ -309,7 +309,7 @@ sub update_remote {
}
}
} else {
- print STDERR "Remote group $name does not exists.\n";
+ print STDERR "Remote group $name does not exist.\n";
exit(1);
}
for (@remotes) {
--
Mikael Magnusson
^ permalink raw reply related
* Default exclude rules for Git
From: Petr Baudis @ 2008-09-19 14:22 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Daniel Barkalow, Bert Wesarg, Git Mailing List
In-Reply-To: <20080919050612.GA4423@roro3>
On Fri, Sep 19, 2008 at 09:06:12AM +0400, Kirill Smelkov wrote:
> On Thu, Sep 18, 2008 at 03:30:35PM -0400, Daniel Barkalow wrote:
> > It's generally better to put a core.excludesfile entry in your
> > ~/.gitconfig pointing to a ignore file with editor temporaries for the
> > editor(s) you personally use. This will then apply to all git projects you
> > work on.
>
> Yes, this makes sense, thanks.
>
> I've had to add the following to my ~/.gitconfig
>
> [core]
> excludesfile= /home/kirr/.gitignore-kirr
>
>
> because it does not work when '~' is used for $HOME
>
> [core]
> excludesfile= ~/.gitignore-kirr # does not work
>
>
> Is it intended?
>
>
> Still I think since a lot of people have to do the same operation, maybe
> it makes sense to put ignores for popular tools right into project's
> .gitignore.
I'm reluctant to put these universal rules to a project-specific
.gitignores, that doesn't feel like the proper solution to me.
I think it would actually make most sense to insert some conservative
default ignore rules to the Git's stock excludes template. (Or better,
have a single file with default Git's exclude rules. Tools newly
installed on the system could even add their entries there during
installation as Git's quest on world dominations progresses.) I'd
shamelessly propose Cogito's set of default excludes for starters:
*.[ao]
.*
!.git*
tags
*~
#*
(or omit the first line if that feels too C-specific - but I think it
should be extremely rare to find files you _want_ to track even in non-C
projects; and I'd argue anytime that by default ignoring hidden files
is absolutely the sanest thing to do.)
I'm not sure if there wouldn't be opposition from others to this,
though. Especially as Junio is extra-careful about backwards
compatibility now after 1.6.0. :-(
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Jeff King @ 2008-09-19 14:25 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: sverre, Junio C Hamano, Git Mailing List
In-Reply-To: <3665a1a00809180931t191b5a24wd58554cdb761535@mail.gmail.com>
On Thu, Sep 18, 2008 at 09:31:24AM -0700, Anatol Pomozov wrote:
> > Can you think of any other cases?
>
> git log??
>
> git log --root for empty repo should not print anything (instead of
> error message that we have now).
I'm not sure that's the same as "--root", though. In existing --root
cases, we are saying "pretend that beyond the initial commit, there is a
commit that contains the empty tree". The logical extension of git-log
here would be to print out that commit.
Not to mention that "git log --root" _already_ has defined semantics
(you just don't really need it since log.showroot defaults to true).
I wonder if my patch is actually confusing things more, and the right
solution is an option that says "pretend that a non-existant HEAD is a
commit with no log and the empty tree." But I think that may just be
confusing things more, because the semantics of such a null commit
wouldn't be clear (e.g., git log would actually produce a little bit of
output).
Maybe it really is better to just force the caller to check the initial
commit condition. It's more work for them, but the semantics are simple
and unambiguous.
> Should documentation (man-pages) reflect your changes as well?
Yes, definitely. However, I'm not sure yet what the changes should _be_
(if any).
-Peff
^ permalink raw reply
* [BUG?]: unpack-file behavior for blobs corresponding to symlinks
From: Elijah Newren @ 2008-09-19 14:31 UTC (permalink / raw)
To: Git Mailing List
Hi,
unpack-file doesn't create symlinks as I'd expect. I'm not sure if
this is a bug in unpack-file, or in my expectations.
To reproduce:
$ git init
Initialized empty Git repository in /home/newren/testing/.git/
$ echo bla > bar
$ ln -s bar foo
$ git add bar foo
$ git ls-files -s foo
120000 ba0e162e1c47469e3fe4b393a8bf8c569f302116 0 foo
$ git unpack-file ba0e162e1c47469e3fe4b393a8bf8c569f302116
.merge_file_J1hTaV
$ ls -l foo .merge_file_J1hTaV
lrwxrwxrwx 1 enewren enewren 3 Sep 19 08:22 foo -> bar
-rw------- 1 enewren enewren 3 Sep 19 08:23 .merge_file_J1hTaV
$ echo $(cat .merge_file_J1hTaV)
bar
Why is .merge_file_J1hTaV a regular file instead of a symlink? Is
there an alternative command I can use that would create a symlink to
bar given the information I have from the git ls-files command (and
which also works for creating normal files and other special file
types)?
Thanks,
Elijah
^ permalink raw reply
* Re: [BUG?]: unpack-file behavior for blobs corresponding to symlinks
From: Mikael Magnusson @ 2008-09-19 14:51 UTC (permalink / raw)
To: Elijah Newren; +Cc: Git Mailing List
In-Reply-To: <51419b2c0809190731j5a77b8ccmba2feecb9c44cc1c@mail.gmail.com>
2008/9/19 Elijah Newren <newren@gmail.com>:
> Hi,
>
> unpack-file doesn't create symlinks as I'd expect. I'm not sure if
> this is a bug in unpack-file, or in my expectations.
>
> To reproduce:
>
> $ git init
> Initialized empty Git repository in /home/newren/testing/.git/
> $ echo bla > bar
> $ ln -s bar foo
> $ git add bar foo
> $ git ls-files -s foo
> 120000 ba0e162e1c47469e3fe4b393a8bf8c569f302116 0 foo
> $ git unpack-file ba0e162e1c47469e3fe4b393a8bf8c569f302116
> .merge_file_J1hTaV
> $ ls -l foo .merge_file_J1hTaV
> lrwxrwxrwx 1 enewren enewren 3 Sep 19 08:22 foo -> bar
> -rw------- 1 enewren enewren 3 Sep 19 08:23 .merge_file_J1hTaV
> $ echo $(cat .merge_file_J1hTaV)
> bar
>
> Why is .merge_file_J1hTaV a regular file instead of a symlink? Is
> there an alternative command I can use that would create a symlink to
> bar given the information I have from the git ls-files command (and
> which also works for creating normal files and other special file
> types)?
This is not a bug. The type of a file is in the tree, not the blob, see:
% echo -n foo > file
% ln -s foo symlink
% git add file symlink
% git commit
Created initial commit 31ad9b0 on master: file and symlink
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 file
create mode 120000 symlink
% git ls-tree HEAD
100644 blob 19102815663d23f8b75a47e7a01965dcdc96468c file
120000 blob 19102815663d23f8b75a47e7a01965dcdc96468c symlink
--
Mikael Magnusson
^ permalink raw reply
* Re: [BUG?]: unpack-file behavior for blobs corresponding to symlinks
From: Elijah Newren @ 2008-09-19 14:55 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Git Mailing List
In-Reply-To: <237967ef0809190751k38defaabk9efc74711f7c63c4@mail.gmail.com>
On Fri, Sep 19, 2008 at 8:51 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> This is not a bug. The type of a file is in the tree, not the blob, see:
>
> % echo -n foo > file
> % ln -s foo symlink
> % git add file symlink
> % git commit
> Created initial commit 31ad9b0 on master: file and symlink
> 2 files changed, 2 insertions(+), 0 deletions(-)
> create mode 100644 file
> create mode 120000 symlink
> % git ls-tree HEAD
> 100644 blob 19102815663d23f8b75a47e7a01965dcdc96468c file
> 120000 blob 19102815663d23f8b75a47e7a01965dcdc96468c symlink
Good to know. Given the mode (100644 or 120000) and the sha1sum, is
there a git command that will create-my-file for me, or do I need to
just use git unpack-file and add my own extra logic on top?
Thanks,
Elijah
^ permalink raw reply
* Re: Default exclude rules for Git
From: Junio C Hamano @ 2008-09-19 15:46 UTC (permalink / raw)
To: Petr Baudis
Cc: Kirill Smelkov, Daniel Barkalow, Bert Wesarg, Git Mailing List
In-Reply-To: <20080919142211.GE10360@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I think it would actually make most sense to insert some conservative
> default ignore rules to the Git's stock excludes template. (Or better,
> have a single file with default Git's exclude rules. Tools newly
> installed on the system could even add their entries there during
> installation as Git's quest on world dominations progresses.) I'd
> shamelessly propose Cogito's set of default excludes for starters:
>
> *.[ao]
> .*
> !.git*
> tags
> *~
> #*
>
> (or omit the first line if that feels too C-specific - but I think it
> should be extremely rare to find files you _want_ to track even in non-C
> projects; and I'd argue anytime that by default ignoring hidden files
> is absolutely the sanest thing to do.)
I do not see a need to change any canned template shipped with git. I
actually think it is a grave regression to add anything arbitrary, even if
one person happens to think the choice is conservative, to the set of
tool-wide ignore patterns. And here is why.
I haven't personally seen any project that wants its users to _edit_ a
file whose names end with ".a" or ".o" and track it. That does not
however mean that there can be no project and/or environment that validly
wants to track files with ".o" suffix (isn't it the case that windows shop
use ".obj" for object files and ".o" suffix do not have any particular
meaning to them?) By placing "*.o" to tool-wide ignore file, your version
of git is making life for participants in such a project harder because
they can now easily forget to add a newly created "*.o" files (status
won't show them). The tool should be extremely conservative not to
encourage such mistakes.
The best place to express such a project wide policy (e.g. "in this
project, '*.o' files will never, or rarely if ever, be tracked and we
expect our developers to appreciate not seeing them in status output by
default") is a tracked .gitignore file.
I earlier said that "*~" should not be in project-wide .gitignore file
because use of Emacs vs vi is a matter of personal taste, and Emacs
specific "*~" pattern does not belong to a project policy, just like
vim "*.swp" pattern doesn't.
But I think that reasoning is flawed. The right criteria should not be
about "use of Emacs vs vi", but about "do we in this project ever want to
track files that match *~ or *.swp as legitimate contents". If a project
expects not to have a tracked file whose name ends with ".swp", even if it
does _not_ mean to encourage use of vim over Emacs or any other editor, I
think it is fine to add such to its tracked .gitignore file for its
developer's benefit.
^ permalink raw reply
* Re: [BUG?]: unpack-file behavior for blobs corresponding to symlinks
From: Junio C Hamano @ 2008-09-19 15:50 UTC (permalink / raw)
To: Elijah Newren; +Cc: Mikael Magnusson, Git Mailing List
In-Reply-To: <51419b2c0809190755l2aa01558l30e07c4141f8d4e0@mail.gmail.com>
"Elijah Newren" <newren@gmail.com> writes:
> On Fri, Sep 19, 2008 at 8:51 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
>> This is not a bug. The type of a file is in the tree, not the blob, see:
>>
>> % echo -n foo > file
>> % ln -s foo symlink
>> % git add file symlink
>> % git commit
>> Created initial commit 31ad9b0 on master: file and symlink
>> 2 files changed, 2 insertions(+), 0 deletions(-)
>> create mode 100644 file
>> create mode 120000 symlink
>> % git ls-tree HEAD
>> 100644 blob 19102815663d23f8b75a47e7a01965dcdc96468c file
>> 120000 blob 19102815663d23f8b75a47e7a01965dcdc96468c symlink
>
> Good to know. Given the mode (100644 or 120000) and the sha1sum, is
> there a git command that will create-my-file for me,...
git checkout -- that-path ;# from the index
git checkout commit that-path ;# from the commit/tree
^ permalink raw reply
* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Brandon Casey @ 2008-09-19 15:55 UTC (permalink / raw)
To: Johan Herland; +Cc: Git Mailing List
In-Reply-To: <200809190140.15489.johan@herland.net>
Johan Herland wrote:
> On Friday 19 September 2008, Brandon Casey wrote:
>> The 'non-GNU' part of this basic RE to extended RE conversion means '\\s'
>> was converted to ' '.
>
> Shouldn't that be '[ \t]' instead? At least I would like that for the HTML
> pattern.
Ah, yes, I think you are right.
-brandon
^ permalink raw reply
* Re: [RFC Redux] strbuf: Add method to convert byte-size to human readable form
From: Marcus Griep @ 2008-09-19 15:56 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <1221279997-9336-1-git-send-email-marcus@griep.us>
[-- Attachment #1: Type: text/plain, Size: 1818 bytes --]
If there is no comment on this, Junio, would you be ok accepting this as a patch,
even as a feature-branch on pu or next?
Marcus Griep wrote:
> Takes a strbuf as its first argument and appends the human-readable
> form of 'value', the second argument, to that buffer.
>
> e.g. strbuf_append_human_readable(sb, 1012, 0, 0, HR_SPACE)
> produces "0.9 Ki".
>
> Documented in strbuf.h; units can be directly appended to the strbuf
> to produce "0.9 KiB/s", "0.9 KiB".
>
> Supports SI magnitude prefixes as well as padding and spacing of
> the units portion of the output.
>
> Also, add in test cases to ensure it produces the expected output
> and to demonstrate what different arguments do.
>
> Signed-off-by: Marcus Griep <marcus@griep.us>
> ---
>
> This is a redux of a prior patch as part of a series on count-objects
> but is now split off and submitted on its own as an RFC for a library
> function to be added to strbuf. If accepted, I'd like to standardize
> upon this method for user visible byte-sizes, thoroughput, large object
> counts, etc.
>
> Provides similar functionality similar to the '-h' size output of du
> in the default case.
>
> Based on master, but also applies cleanly to next.
>
> .gitignore | 1 +
> Makefile | 2 +-
> strbuf.c | 92 +++++++++++++++++++++++++++++++++++++++++++++
> strbuf.h | 30 +++++++++++++++
> t/t0031-human-readable.sh | 49 ++++++++++++++++++++++++
> test-human-read.c | 23 +++++++++++
> 6 files changed, 196 insertions(+), 1 deletions(-)
> create mode 100755 t/t0031-human-readable.sh
> create mode 100644 test-human-read.c
--
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/4] diff.c: convert builtin funcname patterns to non-GNU extended regex syntax
From: Brandon Casey @ 2008-09-19 15:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Boyd Lynn Gerber, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <azRDXO9YgAHlqbMUTpBfy26HVw0xzYFwnT5x-l_nqDw@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Brandon Casey wrote:
>
>> + { "java", "!^[ ]*(catch|do|for|if|instanceof|"
>> + "new|return|switch|throw|while)\n"
>> + "^[ ]*(([ ]*"
>> + "[A-Za-z_][A-Za-z_0-9]*){2,}"
>
> I don't understand the last two lines above.
ok, I figured it out.
I was interpretting the {2,} part in
([ ]*[A-Za-z_][A-Za-z_0-9]*){2,}
as requiring two characters, instead of two or more repetitions of
the pattern inside the parenthesis.
-brandon
^ permalink raw reply
* Re: Default exclude rules for Git
From: Petr Baudis @ 2008-09-19 16:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Kirill Smelkov, Daniel Barkalow, Bert Wesarg, Git Mailing List
In-Reply-To: <7v8wtouoit.fsf@gitster.siamese.dyndns.org>
On Fri, Sep 19, 2008 at 08:46:34AM -0700, Junio C Hamano wrote:
> I do not see a need to change any canned template shipped with git. I
> actually think it is a grave regression to add anything arbitrary, even if
> one person happens to think the choice is conservative, to the set of
> tool-wide ignore patterns. And here is why.
>
> I haven't personally seen any project that wants its users to _edit_ a
> file whose names end with ".a" or ".o" and track it. That does not
> however mean that there can be no project and/or environment that validly
> wants to track files with ".o" suffix (isn't it the case that windows shop
> use ".obj" for object files and ".o" suffix do not have any particular
> meaning to them?) By placing "*.o" to tool-wide ignore file, your version
> of git is making life for participants in such a project harder because
> they can now easily forget to add a newly created "*.o" files (status
> won't show them). The tool should be extremely conservative not to
> encourage such mistakes.
>
> The best place to express such a project wide policy (e.g. "in this
> project, '*.o' files will never, or rarely if ever, be tracked and we
> expect our developers to appreciate not seeing them in status output by
> default") is a tracked .gitignore file.
Yes, but the idea here is to give both the projects and the users
sensible default to work on, in case of users even one that might change
system to system based on tools behavior. It is that VAST MAJORITY of
projects won't care about object or (most kinds of) hidden files, so to
me it makes sense to make people opt out instead of opt in.
If a particular policy is unsuitable for some (rare) project, it can
still undo the ignore rules by adding !*.o to its .gitignore file. The
only issue is that this gets noticed first time a particular new ignore
pattern appears, and I admit I don't have a good solution here.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: Default exclude rules for Git
From: Avery Pennarun @ 2008-09-19 16:42 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Kirill Smelkov, Daniel Barkalow, Bert Wesarg,
Git Mailing List
In-Reply-To: <20080919163311.GH10544@machine.or.cz>
On Fri, Sep 19, 2008 at 12:33 PM, Petr Baudis <pasky@suse.cz> wrote:
> Yes, but the idea here is to give both the projects and the users
> sensible default to work on, in case of users even one that might change
> system to system based on tools behavior. It is that VAST MAJORITY of
> projects won't care about object or (most kinds of) hidden files, so to
> me it makes sense to make people opt out instead of opt in.
The problem here is that the cost of a false positive (ie. too much
ignored) is much greater than the cost of a false negative (ie. too
little ignored).
In the very worst case, if too few files are ignored and a developer
is paying no attention at all, then a *.o or *~ file gets committed;
you can just delete it again. But if too *many* files are ignored,
you can work on your private branch for weeks at a time, thinking
you're keeping regular snapshots, and actually all your commits are
useless because an important file was never versioned.
I never, ever want to end up in the latter situation, so even though I
start virtually every git project by putting "*.[oa]" and "*~" in my
.gitignore, I'm glad it's *me* doing that and not somebody else.
Have fun,
Avery
^ permalink raw reply
* Re: [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Anatol Pomozov @ 2008-09-19 16:54 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Junio C Hamano, Git Mailing List
In-Reply-To: <20080919142537.GA1287@coredump.intra.peff.net>
Hi, Jeff.
On Fri, Sep 19, 2008 at 7:25 AM, Jeff King <peff@peff.net> wrote:
> I'm not sure that's the same as "--root", though. In existing --root
> cases, we are saying "pretend that beyond the initial commit, there is a
> commit that contains the empty tree". The logical extension of git-log
> here would be to print out that commit.
Well yeah, agree. My proposal differs from --root meaning and what you
are doing in your patch. So let's continue this 'git log' discussion
without relation to your changes.
> Not to mention that "git log --root" _already_ has defined semantics
> (you just don't really need it since log.showroot defaults to true).
Hm..
anatol:opensource $ mkdir ex
anatol:opensource $ cd ex/
anatol:ex $ git init
Initialized empty Git repository in /personal/sources/opensource/ex/.git/
anatol:ex $ git log
fatal: bad default revision 'HEAD'
anatol:ex $ git config log.showroot true
anatol:ex $ git config log.showroot
true
anatol:ex $ git log
fatal: bad default revision 'HEAD'
anatol:ex $ git config core.showroot true
anatol:ex $ git config core.showroot
true
anatol:ex $ git log
fatal: bad default revision 'HEAD'
I dont see how does log.showroot or core.showroot affect 'git log'.
man git-log says nothing, git-config only mentions that initial commit
is "a big creation event".
> I wonder if my patch is actually confusing things more, and the right
> solution is an option that says "pretend that a non-existant HEAD is a
> commit with no log and the empty tree." But I think that may just be
> confusing things more, because the semantics of such a null commit
> wouldn't be clear (e.g., git log would actually produce a little bit of
> output).
Yeap - probably it would confuse even more, that is why I brought it
for discussion :)
But for me as for person that still actively works with Subversion it
was quite surprising that I have error messages right after I created
a fresh empty repo. I always thought that "Empty repo" -> "No history"
-> "No log output"
Subversion in the same situation.
anatol:2 $ svn info | grep Revision
Revision: 0
anatol:2 $ svn log
------------------------------------------------------------------------
So svn has the same notion of Initial commit which is "big creation
event" but not visible in "svn log"
The difference from git is that init git repo has no HEAD. HEAD is
undefined. Would it be better if absence of HEAD would mean the same
as "HEAD points to the initial commit".
> Maybe it really is better to just force the caller to check the initial
> commit condition. It's more work for them, but the semantics are simple
> and unambiguous.
What is the best way to check that repo has valid HEAD? Check that
file .git/HEAD exists?
--
anatol
^ permalink raw reply
* Small misspelling in 'Git - SVN crash course'
From: Manuel Freire Morán @ 2008-09-19 15:53 UTC (permalink / raw)
To: git
Hi,
Just wanted to nitpick about a typo in
http://git.or.cz/course/svn.html :
"If you are just after tracking someone else's project, this get you
started quickly:"
should be
"If you are just after tracking someone else's project, this will get
you started quickly:"
kudos for the page,
Manuel Freire
^ permalink raw reply
* Re: [RFC/PATCH] extend meaning of "--root" option to index comparisons
From: Jeff King @ 2008-09-19 17:39 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: sverre, Junio C Hamano, Git Mailing List
In-Reply-To: <3665a1a00809190954q2473e164u5d80d3653d238a27@mail.gmail.com>
On Fri, Sep 19, 2008 at 09:54:15AM -0700, Anatol Pomozov wrote:
> I dont see how does log.showroot or core.showroot affect 'git log'.
> man git-log says nothing, git-config only mentions that initial commit
> is "a big creation event".
Try this:
mkdir repo && cd repo && git init
echo content >file && git add file && git commit -m initial
git show ;# you see initial as creation event
git config log.showroot false
git show ;# you see commit log, but no diff
git show --root ;# same as log.showroot=true
where of course the same holds for log, as show uses the same display
logic.
> But for me as for person that still actively works with Subversion it
> was quite surprising that I have error messages right after I created
> a fresh empty repo. I always thought that "Empty repo" -> "No history"
> -> "No log output"
I agree it is a bit nicer not to get an error in that situation. It is
really a result of the way git thinks of history. It is not "no history"
but rather "some history may or may not exist, but you have no valid
pointer to any history".
However, I wonder if it might be possible to special-case the "branch
yet to be born" case. That is, if HEAD points to a ref which does not
exist, can we treat that specially. I suspect it may turn out to be a
lot of work tracking down all of the spots in the code that would need
to be special-cased, which may make it not worthwhile.
> > Maybe it really is better to just force the caller to check the initial
> > commit condition. It's more work for them, but the semantics are simple
> > and unambiguous.
>
> What is the best way to check that repo has valid HEAD? Check that
> file .git/HEAD exists?
No, HEAD will exist even in a just-created repo. But you can check
whether HEAD points to a valid commit:
git rev-parse --verify HEAD
-Peff
^ permalink raw reply
* git-am strips final ')' character from author name
From: AI @ 2008-09-19 17:58 UTC (permalink / raw)
To: git
In-Reply-To: <2f54d7a20809191057t76c405e7q643912388efe2f01@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
---------- Forwarded message ----------
From: AI <ai0867@gmail.com>
Date: Fri, Sep 19, 2008 at 19:57
Subject: git-am strips final ')' character from author name
To: git@vger.kernel.org
Applying attached patch with git-am strips the ')' character from the name.
Running git-cat-file on the commit gives the following result:
author Alexander van Gessel (AI/AI0867 <AI0867@gmail.com> 1221846001 +0200
committer Alexander van Gessel (AI/AI0867) <AI0867@gmail.com> 1221846254 +0200
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Check-in-environment-and-Makefile-for-opdracht-4.patch --]
[-- Type: text/x-diff; name=0002-Check-in-environment-and-Makefile-for-opdracht-4.patch, Size: 4052 bytes --]
From 49fbe13b3776027e6207d46d473586da9e4ca2bb Mon Sep 17 00:00:00 2001
From: Alexander van Gessel (AI/AI0867) <AI0867@gmail.com>
Date: Fri, 19 Sep 2008 19:40:01 +0200
Subject: [PATCH] Check in environment and Makefile for opdracht 4.
---
src/opdracht4/.gitignore | 3 +++
src/opdracht4/BankAccount.class | Bin 0 -> 729 bytes
src/opdracht4/EasyScanner.class | Bin 0 -> 771 bytes
src/opdracht4/Makefile | 23 +++++++++++++++++++++++
src/opdracht4/Oblong.class | Bin 0 -> 663 bytes
5 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 src/opdracht4/.gitignore
create mode 100644 src/opdracht4/BankAccount.class
create mode 100644 src/opdracht4/EasyScanner.class
create mode 100644 src/opdracht4/Makefile
create mode 100644 src/opdracht4/Oblong.class
diff --git a/src/opdracht4/.gitignore b/src/opdracht4/.gitignore
new file mode 100644
index 0000000..2943223
--- /dev/null
+++ b/src/opdracht4/.gitignore
@@ -0,0 +1,3 @@
+!BankAccount.class
+!EasyScanner.class
+!Oblong.class
diff --git a/src/opdracht4/BankAccount.class b/src/opdracht4/BankAccount.class
new file mode 100644
index 0000000000000000000000000000000000000000..187ebc2b609bf9a8793f99da08980fb1bea363b0
GIT binary patch
literal 729
zcmZ`$%TB^T6g|@dh4K&;pZI`{KrtHE8WYjDBD%n^A4-EoEC!2ymYPURT=)Tgl<`b~
zh@hK$r+3cd>jZ`v-sn<V{4d9zz&eRW?-FG_Yl0TOcWIyW98ti~eoH=?N@U+wwu~
zccj<aulYUKYaI&2#~^v@2pA2?Ynvx=CJ;GtJ=Z@LC=_R@vy)O?AavSol08>-J!j~9
zB^w=1QZ2_n8SN8TWs0R)34!zkZnU?_QDwZBUMz7lqv_mr?_HmU#WUp_eRTcnW=}o}
zn6+-dXFKPvvQ1Z{cQf+cQ_oKzfm{Lxq6x%QF%f496EKo~a=L7^9h)|^ts~ELBg|cg
zrUZD>lt$1g!ybX4ev&oCuOlLL_KfugVU-8atla^0D>Xpqg>&Y_x=dA&6Cx+ZNeXE!
zVxG6@pem(JehK!l^$Pu&hapwjDFOc5KcU(*G)w3rGOR;YEf7$up{FU;9IuuFZ3QiG
lN%fStrLYD2*9%PM0PHZz0!b_Xky?L{$|UWQv`PUDYu`VPc|`yK
literal 0
HcmV?d00001
diff --git a/src/opdracht4/EasyScanner.class b/src/opdracht4/EasyScanner.class
new file mode 100644
index 0000000000000000000000000000000000000000..23d820e85807fa3d9dbd8eafb836bc9ac5929a83
GIT binary patch
literal 771
zcmZvZT~8BH5Qg8=E#0=P<#Q`vMeqZ*MOpR28wm+18X6kBC^7MJTTgIFduo<lBmc?7
zj|)gN@dx;$jPGn4D3#r0_Uz0&GxN^*^Y`a(0MGEWh)FEjST0}%l_D}&6?0F_nwWJl
z_ltOdhc+JB*igvrgeHu46)dm%Rv}yOzt;*=&Cuwhq}SHbanSD4V;lWBZkRYtY$z1v
zf4`rkL9+WpS1XP}bD}WsRhy^5r@-$9=ENU(Un=AUtA7Zhv`(E+tDi(2{W_E;)31WF
z^HwJ?Mn~I1J8*DEVJ5AV#9`MTMr~|5@KBY6nuBS~IGDwpgDtoY9>cZq#KAUvg~^ek
zY;ir*oA#;hP|%30b$%A>o<b%x3hqEa*!LUeV-iz?4tmtE;N2RK^`-J;cif~Xy;*#?
znp}ta_ZZ81jcOh1kZY4?0!sAKmiSlUSBbZF3H6-^UJGq5by_HhXr3kYIV@f*F#8Lc
zcRyfVB70c7z{Jk-mn*Ks9KdF)JjnuI?rVgX=op_n*!()im&i|%mkRT6NBCR%+s&<S
pW4uegO!_YQGVNgg7sL6>H|Nh=7byI%VTCm+?7m8Rf%P+3{0Bi}g{c4l
literal 0
HcmV?d00001
diff --git a/src/opdracht4/Makefile b/src/opdracht4/Makefile
new file mode 100644
index 0000000..26eabf4
--- /dev/null
+++ b/src/opdracht4/Makefile
@@ -0,0 +1,23 @@
+# Practicum IN1205P, Opdracht 2
+# Auteur A. van Gessel, Studienummer 1287974
+# Datum 2008-09-19
+JC = javac
+JR = java
+RM = rm -f
+.SUFFIXES: .java .class
+.java.class:
+ $(JC) $*.java
+
+CLASSES = \
+
+
+all: classes
+
+classes: $(CLASSES:.java=.class)
+
+#Opdracht4_1: Opdracht4_1.class
+# $(JR) Opdracht4_1
+
+clean:
+ @echo "Removing classfiles excluding BankAccount, Oblong and EasyScanner..."
+ @find . -iname '*.class'|grep -Ev '(BankAccount|Oblong|EasyScanner)\.class'|xargs $(RM)
diff --git a/src/opdracht4/Oblong.class b/src/opdracht4/Oblong.class
new file mode 100644
index 0000000000000000000000000000000000000000..3f0e3d8b912e40f9ad90c2529d0566661ef46303
GIT binary patch
literal 663
zcmZvY-Acni5QWb+X=-BHYOR0u-;3H7QPf)z#Ufr5D=6NlaY>_T3NiJyL{J1Td;lLx
zJR55&YL?9I%zQI*cHci<-vI1j#X=7ACJa=RSuhS6R$mT_IV=enfegL4D<GP5y3+T$
zF%SEG=*I^F*;=z%zY@@o``1#S*z!YpHt2O^bm?>gModq}tziqTR%a6xIUV*f??zd@
zmUL2~?{waE0(THNu{?^TBT!2Ha~b(P8Oun(y66ugSDyH4+<3ba^h0m!#<_QFjAPlx
z7)%=$Osf7$3QVZ<cHo5GcDr*UUEYY=uCT@@$no+SE|w)HRwmEE-moE%r?&?US?<Ng
z3q)h%8JR}?8QLR50tMO<bXuD>&+-CSk(nYUh7FcDK#<5bo{)J+%Zwygrk(s3)qbND
zq9shxDp~84rExbBNh38Drva;!yhgJ8KmSAh7hfg6L4G=wvd;S`)s|AtU%UOSXOsDv
Yl&|tR6<;Vr|1NR=)a;U(C6&S4CvL7;I{*Lx
literal 0
HcmV?d00001
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH v2 1/4] diff.c: return pattern entry pointer rather than just the hunk header pattern
From: Boyd Lynn Gerber @ 2008-09-19 18:14 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Arjen Laarhoven, Mike Ralphson, Johannes Sixt,
Jeff King, Git Mailing List, Avery Pennarun, Johan Herland,
Andreas Ericsson, Kirill Smelkov, Giuseppe Bilotta,
Gustaf Hendeby, Jonathan del Strother
In-Reply-To: <hvD4CKeY-shT7TB0JLaQn02KLTvzB720kcwBxBfYbo3S2ySzNzsn9g@cipher.nrlssc.navy.mil>
So on these patches,
What do you want me to do? I applied them and things kinda worked. The
problem is pine/alpine messes them up a bit and it is not easy to manually
fix them. It would be easier to git clone/pull them from either a site or
the trees. I do think that on some we should use the actual charact vers
the C-syntax. "\t" for example.
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH 3/4] diff.*.xfuncname which uses "extended" regex's for hunk header selection
From: Brandon Casey @ 2008-09-19 18:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Arjen Laarhoven, Mike Ralphson, Johannes Sixt, Jeff King,
Git Mailing List
In-Reply-To: <7vd4j212gb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> I personally think it was a mistake that the loop returns failure when
> there is any pattern that does not match (it is a useful feature that a
> match with a negated one forces an early return, though).
>
> We may want to fix the semantics to be something like:
>
> for (i = 0; i < regs->nr; i++) {
> struct ff_reg *reg = ®s->array[i];
> if (!regexec(®->re, line_buffer, 2, pmatch, 0)) {
> if (reg->negate) {
> free(line_buffer);
> return -1;
> }
> break;
> }
> }
> if (regs->nr <= i) {
> free(line_buffer);
> return -1;
> }
> ... use pmatch() ...
>
> I.e. (1) negative match forces an early return (useful for catching
> language keywords), (2) first positive match is used, and (3) no match is
> a failure.
>
> Of course, by definition the above "fix" changes the semantics, and will
> break people's existing setup if somebody has an existing custom pattern
> string that does use more than one positive regexp anded together with
> "\n", but I somehow suspect nobody sane depends on the current broken
> semantics.
>
> It would help making JdS's ObjC alternates easier to write. You can say:
>
>
> /* A or B */
> "...(A|B)$"
> "\n" /* or C or D */
> "...(C|D)$"
>
> and both captures around A|B and C|D would be saved in $1.
Just to let you know another pair of eyes has given the above a
once over, I agree with your proposal. "or" semantics makes more sense
than "and".
-brandon
^ 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