* [PATCH v3 0/3] Detection of directory renames
From: Yann Dirson @ 2008-11-01 22:03 UTC (permalink / raw)
To: git
This new version fixes handling of moves to and from tree toplevel,
adds supports for detecting bulk moves of files into a subdirectory of
their original dir, and adds a couple of other testcases showing what
still has to be done to properly handle moves of directories with
subdirs.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-01 21:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <20081101202922.GB15463@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Pierre Habouzit wrote:
>>> On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
>>>> How about this?
>>>>
>>>> http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
>>> FWIW I've read what you say about types, while this is good design to
>>> make things abstract, accessors are slower _and_ disallow many
>>> optimizations as it's a function call and that it may clobber all your
>>> pointers values.
>
> True, accessors slow things down. But I'm not sure that the
> accessors at the application level are going to be a huge problem.
>
> Where the CPU time really matters is inside the tight loops of the
> library, where we can expose the struct to ourselves, because if
> the layout changes we'd be relinking the library anyway with the
> updated object code.
>
> I would rather stick with accessors right now. We could in the
> future expose the structs and convert the accessors to macros or
> inline functions in a future version of the ABI if performance is
> really shown to be a problem here from the *application*.
>
> Remember we are mostly talking about applications that are happy to
> fork+exec git right now. A little accessor function call is *still*
> faster than that fork call was.
>
>>> struct object in git has not changed since 2006.06. struct commit hasn't
>>> since 2005.04 if you ignore { unsigned int indegree; void *util; } that
>>> if I'm correct are annotations, and is a problem we (I think) have to
>>> address differently anyways (I gave my proposal on this, I'm eager to
>>> hear about what other think on the subject). So if in git.git that _is_
>>> a moving target we have had a 2 year old implementation for those types,
>>> it's that they're pretty well like this.
>>>
>>> It's IMNSHO on the matter that core structures of git _will_ have to be
>>> made explicit. I'm thinking objects and their "subtypes" (commits,
>>> trees, blobs). Maybe a couple of things on the same vein.
>> I agree. "git_commit", "git_tree", "git_blob" and "git_tag" can almost
>> certainly be set in stone straight away.
>
> Eh, I disagree here. In git.git today "struct commit" exposes its
> buffer with the canonical commit encoding. Having that visible
> wrecks what Nico and I were thinking about doing with pack v4 and
> encoding commits in a non-canonical format when stored in packs.
> Ditto with trees.
>
Err... isn't that backwards? Surely you want to store stuff in the
canonical format so you're forced to do as few translations as
possible? Or are you trying to speed up packing by skipping the
canonicalization part? If so, that would slow down reading (or
rather, presenting) the commits, wouldn't it?
> Because git.git code goes against that canonical buffer we cannot
> easily insert pack v4 and test the improvements we want to make.
> The refactoring required is one of the reasons we haven't done pack
> v4 yet. _IF_ we really are going through this effort of building
> a different API and shifting to its use in git.git I want to make
> sure we at least initially leave the door open to make changes
> without rewriting everything *again*.
>
Well, if macro usage is adhered to one wouldn't have to worry,
since the macro can just be rewritten with a function later (if,
for example, translation or some such happens to be required).
Older code linking to a newer library would work (assuming the
size of the commit object doesn't change anyway), but newer code
linking to an older library would not. Otoh, they wouldn't even
build unless they used the wrong header files, so there is nothing
to worry about there.
> Accessor functions can usually be inlined or macro'd away. But
> they cannot be magically inserted by the compiler if they aren't
> there in the first place. This isn't Python... :-)
>
What I meant was this (I'm a tad drunk, so read the spirit, not
the letter):
in "foo-api.h":
--%<--%<--
#ifdef BUILDING_FOR_DEPLOYING
#include "git_foo_decls.h"
# define git_foo_get_buf(git_foo) (git_foo->buf)
#else
#include "git_foo_fwd_decls.h"
extern const char *git_foo_get_buf(git_foo *foo);
#endif
--%<--%<--
foo.c
--%<--%<--
#include "foo-api.h"
#include "git_foo_decls.h"
#ifndef BUILDING_FOR_DEPLOYING
const char git_foo_get_buf(git_foo *foo)
{
return foo->buf;
}
/* other accessors go here */
#endif
/* rest of git_foo manipulators go here */
--%<--%<--
It's almost certainly not worth it for libgit2 though, as git@vger
provides a good review system.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* PHP購物車資料庫網站專案
From: 劉宗毅 @ 2008-11-01 21:44 UTC (permalink / raw)
To: gipservece
山鉧科技網頁設計
我們的宗旨：客戶的每ㄧ件小事情，都是山鉧的大事情
我們在推出企業形象網站包含前台網頁美工+後台管理程式
限時限量專案價 只要$29,900
(在送ㄧ年100MB不限流量網站空間)
我們做的不只是網站，而是您企業的入口
ㄧ個好的企業網站資料即時更新的速度是很重要的
企業ｅ化的高品質團隊，打造您的網路門面
選擇山鉧成就您的夢想
～～～～～～～～～～～～～～～～～～～～～～～～～～
PS: 線上購物網站我們還可提供刷卡機制，
與線上列印帳單全省超商+郵局繳費......等金流服務機制
～～～～～～～～～～～～～～～～～～～～～～～～～～
歡迎來電洽詢黃專員（Sam）：0980119812 / 0938764395
上網搜尋『 網頁設計山鉧 』即可找到我們
～～～～～～～～～～～～～～～～～～～～～～～～～～
本公司另外提供關鍵字SEO排序服務
保證將您的網站在Yx / Gx ...排在第一頁
歡迎來電詢問!!!
～～～～～～～～～～～～～～～～～～～～～～～～～～
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-01 20:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Scott Chacon
In-Reply-To: <490CAB6D.90209@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn O. Pearce wrote:
>> During the GitTogether we were kicking around the idea of a ground-up
>> implementation of a Git library.
>
> Having looked briefly at the code, I've got a couple of comments:
> * GIT_EXTERN() does nothing. Ever. It's noise and should be removed.
I feel the same way.
But I was also under the impression that the brilliant engineers
who work for Microsoft decided that on their platform special
annotations have to be inserted on functions that a DLL wants to
export to applications.
Hence any cross-platform library that I have seen annotates their
exported functions this way, with the macro being empty on POSIX
and expanding to some magic keyword on Microsoft's OS. I think it
goes between the return type and the function name too...
> Instead it would be better to have GIT_PRIVATE(),
I can see why you said this; needing GIT_PRIVATE() is a lot more
rare than needing GIT_EXTERN(). Only a handful of cross-module,
but private, functions are likely to exist, so it makes sense to
mark the smaller subset. But see above. *sigh*
> * Prefixing the files themselves with git_ is useless and only leads
> to developer frustration. I imagine we'd be installing any header
> files in a git/ directory anyway, so we're gaining absolutely
> nothing with the git_ prefix on source-files.
Yes, I realized that this morning. I plan on changing that mess
around so we have "include/git/oid.h" and library and application
code can use "#include <git/oid.h>". Library modules should just
be "src/oid.c" then.
> Apart from that, it seems you've been designing a lot rather than
> trying to use the API to actually do something.
I wanted to get a solid idea of what our API conventions should be,
before we started writing a lot of code around them. Part of the
problem with the git.git code is we don't have conventions that are
really suited for use in a shared library (assuming we even have
conventions in there) so we can't use that code as a library today.
> It would, imo, be
> a lot better to start development with adding functionality shared
> between all programs and then expand further on that, such as
> incorporating all functions needed for manipulating tags into the
> library and then modify existing code to use the library to get
> tag-ish things done.
Tags are mostly pointless. Its a tiny part of the code that isn't
that interesting to most people. And it requires object database
access anyway if you want to talk about parsing or reading a tag.
There's almost no point in a git library that can't read the on
disk object database, or write to it.
> I also think it's quite alright to not strive *too* hard to make
> all functions thread-safe, as very few of them will actually need
> that. It's unlikely that a user program will spawn one thread to
> write a lot of tags while another is trying to parse them, for
> example.
Oh really?
Maybe true for tags, just because they are such an unimportant part
of the git suite compared to everything else.
But right now I'm running a production system using a threaded server
process that is operating on Git repositories. Fortunately threads
suck less on Java than they do on POSIX, and we have a 100% pure
Java library available for Git.
It would be nice if a library created in the late part of 2008
recognized that threads exist, aren't going to disappear tomorrow,
and that consumers of libraries actually may need to run the library
within a threaded process.
Or are you one of those developers who think threads only exist
in the giant monolithic kernel land, and all user space should
be isolated process? I often wonder who such people can justify
the kernel address space being multi-threaded but userland being
stuck to single threaded applications. Oh, right, the kernel has
to go fast...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] add instructions on how to send patches to the mailing list with Gmail
From: Tom Preston-Werner @ 2008-11-01 20:40 UTC (permalink / raw)
To: Santi Béjar; +Cc: git, Junio C Hamano
In-Reply-To: <adf1fd3d0811010300ye0aca83t12d271388d35b8d4@mail.gmail.com>
On Sat, Nov 1, 2008 at 3:00 AM, Santi Béjar <santi@agolina.net> wrote:
> On Sat, Nov 1, 2008 at 8:28 AM, Tom Preston-Werner <tom@github.com> wrote:
>> Gmail is one of the most popular email providers in the world. Now that Gmail
>> supports IMAP, sending properly formatted patches via `git imap-send` is
>> trivial. This section in SubmittingPatches explains how to do so.
>>
>> Signed-off-by: Tom Preston-Werner <tom@github.com>
>> ---
>> Documentation/SubmittingPatches | 27 +++++++++++++++++++++++++++
>> 1 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
>> index a1e9100..f0295c6 100644
>> --- a/Documentation/SubmittingPatches
>> +++ b/Documentation/SubmittingPatches
>> @@ -456,3 +456,30 @@ This should help you to submit patches inline using KMail.
>>
>> 5) Back in the compose window: add whatever other text you wish to the
>> message, complete the addressing and subject fields, and press send.
>> +
>> +
>> +Gmail
>> +-----
>> +
>> +Submitting properly formatted patches via Gmail is simple now that
>> +IMAP support is available. First, edit your ~/.gitconfig to specify your
>> +account settings:
>> +
>> +[imap]
>> + folder = "[Gmail]/Drafts"
>> + host = imaps://imap.gmail.com
>> + user = user@gmail.com
>> + pass = p4ssw0rd
>> + port = 993
>> + sslverify = false
>
> Warning: It is not secure.
It is true that the certificate is not verified, but since the patches
are destined for a public mailing list, this does not represent a
large problem.
>> +
>> +Next, ensure that your Gmail settings are correct. In "Settings" the
>> +"Use Unicode (UTF-8) encoding for outgoing messages" should be checked.
>> +
>> +Once your commits are ready to send to the mailing list, run the following
>> +command to send the patch emails to your Gmail Drafts folder.
>> +
>> + $ git format-patch -M --stdout origin/master | git imap-send
>> +
>> +Go to your Gmail account, open the Drafts folder, find the patch email, fill
>> +in the To: and CC: fields and send away!
>
> Are you sure the mail does not get whitespace damaged?
Yes, I have sent patches using exactly this method. Here is an example
of one I sent today:
http://article.gmane.org/gmane.comp.version-control.git/99759. Tabs
are preserved and lines are not wrapped improperly.
Tom
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Johannes Schindelin @ 2008-11-01 20:37 UTC (permalink / raw)
To: Alex Riesen
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <20081101142434.GA7157@steel.home>
Hi,
On Sat, 1 Nov 2008, Alex Riesen wrote:
> Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> >
> > Well, if you install Git for Windows (as opposed to cygwin), it is
> > minimum hassle, and Perl is delivered right with it.
>
> I'd like to try it again, but weren't ther some fatal problems with
> cygwin1.dll being in PATH? I always work either in Cygwin's bash or just
> have to have it in PATH, because of the build environment even being
> strictly Windows based (case-insensitive and alike) just have to use
> sane tooling in its scripts.
I was talking about Git for Windows, i.e. the result of msysGit (as
opposed to Git in Cygwin).
So no, there have not been any conflicts with cygwin1.dll in the PATH, as
far as I can recall. There have been problems with shell utilities being
found in the Cygwin PATH before being found in the MSys PATH, but I
thought we just prepended the MSys PATH to avoid that. Haven't checked,
though.
> > P.S.: some guys at the GSoC mentor summit convinced me in at least
> > trying to fix _their_ problems on msysGit, so chances are good I'll
> > fix issues you would encounter in the same run.
>
> Do you still plan to distribute MinGW with it? It's very nice to be able
> to track Junio's repo, have own branches and rebuild Git from time to
> time. For me, at least.
You mean to distribute a minimal MSys environment where you have bash?
Yes, we have to do that, as there are still too many important parts of
Git written in Shell.
Ciao,
Dscho
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-01 20:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, git, Scott Chacon
In-Reply-To: <490CA37C.1070107@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Pierre Habouzit wrote:
>> On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
>>> How about this?
>>>
>>> http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
>>
>> FWIW I've read what you say about types, while this is good design to
>> make things abstract, accessors are slower _and_ disallow many
>> optimizations as it's a function call and that it may clobber all your
>> pointers values.
True, accessors slow things down. But I'm not sure that the
accessors at the application level are going to be a huge problem.
Where the CPU time really matters is inside the tight loops of the
library, where we can expose the struct to ourselves, because if
the layout changes we'd be relinking the library anyway with the
updated object code.
I would rather stick with accessors right now. We could in the
future expose the structs and convert the accessors to macros or
inline functions in a future version of the ABI if performance is
really shown to be a problem here from the *application*.
Remember we are mostly talking about applications that are happy to
fork+exec git right now. A little accessor function call is *still*
faster than that fork call was.
>> struct object in git has not changed since 2006.06. struct commit hasn't
>> since 2005.04 if you ignore { unsigned int indegree; void *util; } that
>> if I'm correct are annotations, and is a problem we (I think) have to
>> address differently anyways (I gave my proposal on this, I'm eager to
>> hear about what other think on the subject). So if in git.git that _is_
>> a moving target we have had a 2 year old implementation for those types,
>> it's that they're pretty well like this.
>>
>> It's IMNSHO on the matter that core structures of git _will_ have to be
>> made explicit. I'm thinking objects and their "subtypes" (commits,
>> trees, blobs). Maybe a couple of things on the same vein.
>
> I agree. "git_commit", "git_tree", "git_blob" and "git_tag" can almost
> certainly be set in stone straight away.
Eh, I disagree here. In git.git today "struct commit" exposes its
buffer with the canonical commit encoding. Having that visible
wrecks what Nico and I were thinking about doing with pack v4 and
encoding commits in a non-canonical format when stored in packs.
Ditto with trees.
Because git.git code goes against that canonical buffer we cannot
easily insert pack v4 and test the improvements we want to make.
The refactoring required is one of the reasons we haven't done pack
v4 yet. _IF_ we really are going through this effort of building
a different API and shifting to its use in git.git I want to make
sure we at least initially leave the door open to make changes
without rewriting everything *again*.
Accessor functions can usually be inlined or macro'd away. But
they cannot be magically inserted by the compiler if they aren't
there in the first place. This isn't Python... :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Elijah Newren @ 2008-11-01 20:27 UTC (permalink / raw)
To: Sam Vilain; +Cc: Theodore Tso, git, Sam Vilain
In-Reply-To: <1225389068.19891.28.camel@maia.lan>
Hi,
(Sorry for sending so many emails, and being late to the conversation.
There's a couple others that I wanted to respond to but I'll wait off
on those and finish with this email to avoid spamming everyone any
more right now.)
On Thu, Oct 30, 2008 at 11:51 AM, Sam Vilain <sam@vilain.net> wrote:
> Well, I don't have strong feelings on the exact command name used; I
> suggested "undo", probably also ambiguous. But still, a significant
> number of users are surprised when they type 'git revert' and they get a
> backed out patch. It's such an uncommon operation, it doesn't deserve
> to be triggered so easily. And reverting files to the state in the
> index and/or HEAD is a common operation that deserves being short to
> type.
>
> Making it plain "revert" would violate expectations of existing users;
> it seems a better idea to just deprecate it, and point the users to the
> new method - cherry-pick --revert - or the command they might have meant
> - whatever that becomes.
There is another option, though it has its own problems too. There
are basically two kinds of reverting here -- reverting all the changes
*in* a given revision (which I'll called 'revert-in') and reverting
all the changes *since* a given revision (typically HEAD; I'll call
this 'revert-since'). These two operations can be supported from the
same command, though their use cases are different enough that it may
seem slightly weird:
revert-since revert-in
* is usually used in a dirty tree * is typically used in a clean tree
* specific paths are usually * specific paths are not often
specified specified
* it is rare to want to commit * making a commit after reverting
immediately after reverting is what you usually want
* it is uncommon to need to
specify a revision
I decided to combine them in EasyGit, simply because that made things
the most discoverable for both existing git and svn/bzr/hg users. The
big problem here is that --commit is turned on by default when --in is
specified, and --no-commit is the default when --since is specified.
Anyway, some examples:
eg revert REVISION => Error -- you must specify either --since or
--in when specifying a revision
eg revert --in REVISION => Same as git revert REVISION
eg revert --since HEAD FILE1 FILE2 => Same as svn revert FILE1 FILE2
eg revert FILE1 FILE2 => shorthand for the previous command; --since
HEAD is default when no revision is specified
eg revert --since HEAD~3 SUBDIRECTORY => should be clear; an extension
over what svn revert can do
Then there's also the possibility that users only want to revert
unstaged changes, or only want to revert staged changes...
Anyway, just some food for thought. I've spammed the list enough in
this thread, so I'll break for now. Thanks for listening.
Elijah
^ permalink raw reply
* Re: git/lib and git/git-gui/lib merge mis-hap?
From: Shawn O. Pearce @ 2008-11-01 20:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <490CAE40.4060300@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Settling down to get some libgit2 hacking done (adding build-rules
> to git.git), I noticed that there's a file in git.git called
> lib/remote_add.tcl, which looks as if it belongs in git-gui/lib.
>
> I don't know how this happened, but since I assume it's subtree
> merged (thus requiring more work to correct than a simple patch),
> it would be nifty if it could get corrected so as to make space
> for the up-and-coming git library :-)
That was a bad merge of git-gui on my part. I thought it was fixed.
It only happened in next, and was there only for a day before
someone pointed it out to me, and I fixed it in the tree.
FWIW, "git mv lib/remote_add.tcl git-gui/lib" is all you need to
fix it. There's nothing special about the subtree merge.
--
Shawn.
^ permalink raw reply
* Re: libgit2 - a true git library
From: Johannes Schindelin @ 2008-11-01 20:26 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pierre Habouzit, Shawn O. Pearce, Junio C Hamano, Pieter de Bie,
git, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0811010944000.13034@xanadu.home>
Hi,
On Sat, 1 Nov 2008, Nicolas Pitre wrote:
> Again, please have a look at include/linux/err.h. The pointer range
> from 0xffffffff (or 0xffffffffffffffff on 64-bit machines) down to the
> range you want is for errors, and the top of the address range is almost
> certain to never be valid in user space either.
How certain may I be of that assumption? Because an assumption it is.
Ciao,
Dscho
^ permalink raw reply
* Re: Git remote status
From: Miklos Vajna @ 2008-11-01 20:11 UTC (permalink / raw)
To: Gonsolo; +Cc: git
In-Reply-To: <490CB390.9000206@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 262 bytes --]
On Sat, Nov 01, 2008 at 08:52:48PM +0100, Gonsolo <gonsolo@gmail.com> wrote:
> Is there a "git remote status" or git-status switch to get the same
> information without switching branches?
Just 'git checkout' should print the info for the current branch.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Edward Z. Yang @ 2008-11-01 20:03 UTC (permalink / raw)
To: git
In-Reply-To: <20081101110529.GC3819@artemis.corp>
Pierre Habouzit wrote:
> git checkout HEAD -- <list of the files>
What if I do not know a priori which files *do* need to be updated? Is
there a command that I can get this information from? Also, I may not
necessarily be checking out HEAD.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Elijah Newren @ 2008-11-01 19:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Theodore Tso, Sam Vilain, git, Sam Vilain
In-Reply-To: <4909CC85.1080803@op5.se>
Hi,
On Thu, Oct 30, 2008 at 9:02 AM, Andreas Ericsson <ae@op5.se> wrote:
> I like it, although I guess one would have to add a "--staged" flag to
> git revert-file to be able to checkout files from index as well, or people
> will wonder why that can't be done.
Ew. 'git revert-file --staged foo'? If you want to revert the
*unstaged* changes of a file, it should be 'git revert-file --unstaged
foo'.
I would expect 'git revert-file --staged foo' to revert the staged
changes in foo, i.e. it should do what 'git reset -- foo' does (except
that it should also work for the initial commit). Thus, there'd be
little need for a --staged flag to revert-file, unless we allowed
reverting individual files back to some revision prior to HEAD (like
bzr and hg do)...
^ permalink raw reply
* Re: [PATCH 2/3] git send-email: do not ask questions when --compose is used.
From: Francis Galiegue @ 2008-11-01 19:56 UTC (permalink / raw)
To: git
In-Reply-To: <20081101174352.GG26229@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]
Le Saturday 01 November 2008 18:43:52 Pierre Habouzit, vous avez écrit :
[...]
> Your regex fails to parse:
>
> "Someone with a comma, and an escape double quote \" in its name"
Easy fix: replace "[^"]+" with "[^"]+(?:\\"[^"]*)*".
> <regex.cant.be.used.for.serious.parsing@i.told.you.so>
Oh yes. Regexes _are_ the way to do serious parsing. All MIME packages you
will find floating around use regexes to parse mail headers correctly.
Granted, adhering to the RFC822 to the letter is rather hard. But I have a
sample program here that can not only parse the escaped double quote, but
also take account for the multiple line stuff and multiple headers of the
same type where email addresse are valid (To:, Cc:, Bcc:). See attachment.
Feel free to use the code.
----
fg@erwin ~ $ cat t.txt
To: John Doe <some.address@some.tld>, Random Joe <random.joe@abc.def>,
Superman <batman@nyc.us>, "Someone with a comma, inside its tag name"
<a@b.com>
To: bbr@one2team.com,
u1@whatever.org,
u2@wherever.ru,
u3@blah.com
fg@erwin ~ $ perl t.pl <t.txt
Found mail: John Doe <some.address@some.tld>
Found mail: Random Joe <random.joe@abc.def>
Found mail: Superman <batman@nyc.us>
Found mail: "Someone with a comma, inside its tag name" <a@b.com>
Found mail: bbr@one2team.com
Found mail: u1@whatever.org
Found mail: u2@wherever.ru
Found mail: u3@blah.com
----
--
fge
[-- Attachment #2: t.pl --]
[-- Type: application/x-perl, Size: 1101 bytes --]
^ permalink raw reply
* Git remote status
From: Gonsolo @ 2008-11-01 19:52 UTC (permalink / raw)
To: git
Hi!
If I switch branches with "git checkout master" git tells me something
like "Your branch is ahead of the tracked remote branch 'origin/master'
by 39 commits".
Is there a "git remote status" or git-status switch to get the same
information without switching branches?
Sometimes it's valuable whether one should push changes (for example
before installing a new Ubuntu version ;) ).
Thank you,
g
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Elijah Newren @ 2008-11-01 19:42 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Theodore Tso, Sam Vilain, git
In-Reply-To: <vpqmygmw1mr.fsf@bauges.imag.fr>
Hi,
On Thu, Oct 30, 2008 at 9:20 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Theodore Tso <tytso@mit.edu> writes:
>
>> * Add the command "git revert-file <files>" which is syntactic sugar for:
>>
>> git checkout HEAD -- <files>
>
> I don't think "revert-file" is a good name for this: although other
> SCM often call this "revert", what Git calls "revert" is about
> reverting an existing commit (it's "backout" in hg for example). The
> terminology to revert the working tree to the last commited version is
> already here in Git, it's "reset".
git's reset is _not_ the same as svn/bzr/hg's revert; and it's overlap
in functionality is smaller than you realize.
> I've already argued in favor of allowing "git reset --hard <files>",
> which is consistant with existing terminology and doesn't add an extra
> command, but without success.
Such a command would
* delete newly added files instead of simply untracking them.
That's the right thing for reset, but not for a svn/bzr/hg-like revert
(and unfortunately means unintended data loss.)
* doesn't make sense during an incomplete merge, unless you add some
way of specifying which branch users want to revert their files back
to. Aren't there enough confusing flags for reset already? (One
surprisingly common comment I get about eg is that git reset is too
hard to understand and eg reset fixes it -- despite the fact that I
merely renamed two flags and hid the second form of the command.)
* doesn't work for the initial commit
* provides no way to revert files or subdirectories back to their
state at some previous revision (hg and bzr revert have a flag to
provide this; it's not useful all the time but is on occasion) Also,
if users try to modify their command slightly to get such behavior,
say 'git reset --hard REVISION' instead of 'git reset --hard .', then
they're in trouble. (Recoverable, but they need an 'expert' to help
them now.)
Also, there's three different kinds of "undo": switching to an old
revision (git checkout REVISION, or svn/hg update -r, etc.),
forgetting or discarding commits/merges/rebases (git reset), and
modifying files to undo previous modifications without touching HEAD
(svn/bzr/hg revert). Users get confused enough between these
different kinds of undo; overloading them further would be really bad,
IMO.
(Part of the reason for users getting confused between these kinds of
undo is the fact that git doesn't implemented svn/bzr/hg-like revert,
and tends to steer them towards git checkout and git reset, which are
commands typically meant for the *other* kinds of undo.)
Just my $0.02,
Elijah
^ permalink raw reply
* git/lib and git/git-gui/lib merge mis-hap?
From: Andreas Ericsson @ 2008-11-01 19:30 UTC (permalink / raw)
To: Junio C Hamano, Shawn Pearce, Git Mailing List
Settling down to get some libgit2 hacking done (adding build-rules
to git.git), I noticed that there's a file in git.git called
lib/remote_add.tcl, which looks as if it belongs in git-gui/lib.
I don't know how this happened, but since I assume it's subtree
merged (thus requiring more work to correct than a simple patch),
it would be nifty if it could get corrected so as to make space
for the up-and-coming git library :-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Elijah Newren @ 2008-11-01 19:26 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030143918.GB14744@mit.edu>
Hi,
On Thu, Oct 30, 2008 at 8:39 AM, Theodore Tso <tytso@mit.edu> wrote:
> Here are my favorites:
>
> * Add the command "git revert-file <files>" which is syntactic sugar for:
>
> git checkout HEAD -- <files>
>
> Rationale: Many other SCM's have a way of undoing local edits to a
> file very simply, i.e."hg revert <file>" or "svn revert <file>", and
> for many developers's workflow, it's useful to be able to undo local
> edits to a single file, but not to everything else in the working
> directory. And "git checkout HEAD -- <file>" is rather cumbersome
> to type, and many beginning users don't find it intuitive to look in
> the "git-checkout" man page for instructions on how to revert a
> local file.
I agree with the rationale, but the suggested implementation (as with
the original suggestion for "git undo") is somewhat problematic. I
have a write-up somewhere documenting the ways various individual git
commands fail to be an appropriate replacement for svn/hg/bzr
revert[1], but in short the "git checkout HEAD -- <file>"
implementation for svn/hg/bzr-like revert fails in the following ways:
* It does not work for the initial commit
* It won't untrack or remove files (this is related to the previous
and following items)
* It doesn't allow reverting a file or directory to a revision prior
to HEAD (making it like svn; note though that both bzr and hg have
such an option and I have found it handy a few times)
* It's inappropriate to use during an incomplete merge.
The incomplete merge case is particularly interesting. If the user
specifies a file or subdirectory, they should also specify a branch to
revert relative to (and it should be an error if they don't). If the
user specifies "." then there's the question of whether they are
attempting to undo the merge (meaning that .git/MERGE_MSG and
.git/MERGE_HEAD should be removed).
Just as food for thought, here's what eg does in the incomplete merge case:
$ eg revert foo
Aborting: Cannot revert the changes since the last commit, since you are in
the middle of a merge and there are multiple last commits. Please add
--since BRANCH
to your flags to eg revert, where BRANCH is one of
master, devel
If you simply want to abort your merge and undo its conflicts, run
eg revert --since HEAD
There's a couple more issues here that I could go on about, but I'll
mention just one more thing for this email: Since users often get
confused between different kinds of "reverting" or "undoing", a plain
'eg revert' is also pretty helpful in a wide variety of circumstances
(it always aborts with an error message, but one that detects what the
user might want and suggests appropriate commands in the various
cases.)
Elijah
[1] There are a number of different commands that people suggest for
new users to replace other systems' revert behavior, but each has
areas in which it will fail to do what users expect or do additional
things users don't want (including discarding data) Interestingly,
I've tried four different alternative git porcelains and each one
implemented their svn/hg/bzr-like revert incorrectly. One of these
was EasyGit, in which I got it wrong not once but three separate
times. (And if alternative porcelain authors can't easily get it
right, we clearly can't expect normal users to know how to do so; I
think this is a pretty good argument for providing a function for this
behavior in core git.) I think I finally have it implemented
correctly now in EasyGit, after my fourth try...
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-01 19:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081031170704.GU14786@spearce.org>
Shawn O. Pearce wrote:
> During the GitTogether we were kicking around the idea of a ground-up
> implementation of a Git library. This may be easier than trying
> to grind down git.git into a library, as we aren't tied to any
> of the current global state baggage or the current die() based
> error handling.
>
> I've started an _extremely_ rough draft. The code compiles into a
> libgit.a but it doesn't even implement what it describes in the API,
> let alone a working Git implementation. Really what I'm trying to
> incite here is some discussion on what the API looks like.
>
> API Docs:
> http://www.spearce.org/projects/scm/libgit2/apidocs/html/modules.html
>
> Source Code Clone URL:
> http://www.spearce.org/projects/scm/libgit2/libgit2.git
>
Having looked briefly at the code, I've got a couple of comments:
* GIT_EXTERN() does nothing. Ever. It's noise and should be removed.
Instead it would be better to have GIT_PRIVATE(), which could
set visibility to "internal" or "hidden", meaning the symbol it's
attached to can be used for lookups when creating a shared library
but won't be usable from programs linking to that shared library
(visibility-attributes have zero effect on static libraries). At
least on all archs anyone really cares about.
* Prefixing the files themselves with git_ is useless and only leads
to developer frustration. I imagine we'd be installing any header
files in a git/ directory anyway, so we're gaining absolutely
nothing with the git_ prefix on source-files.
Apart from that, it seems you've been designing a lot rather than
trying to use the API to actually do something. It would, imo, be
a lot better to start development with adding functionality shared
between all programs and then expand further on that, such as
incorporating all functions needed for manipulating tags into the
library and then modify existing code to use the library to get
tag-ish things done. That would also mean that the library would
quickly get used by core git, as once a certain part of it is
complete patches can be fitted to the library rather than to the
current non-libish dying() functions.
I also think it's quite alright to not strive *too* hard to make
all functions thread-safe, as very few of them will actually need
that. It's unlikely that a user program will spawn one thread to
write a lot of tags while another is trying to parse them, for
example.
By adding an init routine that determines the workdir and the
gitdir, one could start using the library straight away.
int git_init(const char *db, const char *worktree)
{
if (git_set_db_dir(db))
return -1;
git_set_worktree((worktree))
return -1;
return 0;
}
and already you have a some few small helpers that are nifty to
to have around:
int git_is_gitdir(const char *path); /* returns 1 on success */
int git_has_gitdir(const char *path); /* returns 1 on success */
const char *git_mkpath(const char *fmt, ...)
This way one will notice rather quickly what's needed (making it
easy to keep a more-or-less public TODO available, with small stuff
on it for the most part), and one can then go look for it in the
existing git code and, if possible, convert stuff or, best case
scenario, steal it straight off so that more apps can benefit from
tried and tested code.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-11-01 18:48 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <490CA37C.1070107@op5.se>
[-- Attachment #1: Type: text/plain, Size: 663 bytes --]
On Sat, Nov 01, 2008 at 06:44:12PM +0000, Andreas Ericsson wrote:
> Pierre Habouzit wrote:
> >For types that _will_ be in the tight loops, we must make the types
> >explicit or it'll bite us hard performance-wise. I'm thinking what is
> >"struct object" or "struct commit" in git.git. It's likely that we will
> >loose a *lot* of those types are opaque.
>
> The last sentence doesn't parse. I assume you mean "if those types
> are..",
This was a typo, indeed s/of/if/
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2] connect.c: add a way for git-daemon to pass an error back to client
From: Tom Preston-Werner @ 2008-11-01 18:44 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The current behavior of git-daemon is to simply close the connection on
any error condition. This leaves the client without any information as
to the cause of the failed fetch/push/etc.
This patch allows get_remote_heads to accept a line prefixed with "ERR"
that it can display to the user in an informative fashion. Once clients
can understand this ERR line, git-daemon can be made to properly report
"repository not found", "permission denied", or other errors.
Example
S: ERR No matching repository.
C: fatal: remote error: No matching repository.
Signed-off-by: Tom Preston-Werner <tom@github.com>
---
Use prefixcmp instead of memcmp and test for "ERR " instead of "ERR"
connect.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/connect.c b/connect.c
index 0c50d0a..584e04c 100644
--- a/connect.c
+++ b/connect.c
@@ -70,6 +70,9 @@ struct ref **get_remote_heads(int in, struct ref **list,
if (buffer[len-1] == '\n')
buffer[--len] = 0;
+ if (len > 4 && !prefixcmp(buffer, "ERR "))
+ die("remote error: %s", buffer + 4);
+
if (len < 42 || get_sha1_hex(buffer, old_sha1) || buffer[40] != ' ')
die("protocol error: expected sha/ref, got '%s'", buffer);
name = buffer + 41;
--
1.6.0.2
^ permalink raw reply related
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-01 18:44 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081101173042.GE26229@artemis.corp>
Pierre Habouzit wrote:
> On Fri, Oct 31, 2008 at 06:41:54PM +0000, Shawn O. Pearce wrote:
>> How about this?
>>
>> http://www.spearce.org/projects/scm/libgit2/apidocs/CONVENTIONS
>
> FWIW I've read what you say about types, while this is good design to
> make things abstract, accessors are slower _and_ disallow many
> optimizations as it's a function call and that it may clobber all your
> pointers values.
>
Accessors are very nifty for one thing though; With a debugging flag,
you can use an accessor-function, while without that debugging flag you
can use a macro instead of a function. In other words, you use the
compiler as a sort of sanity-checker that you're only accessing the
variables through the proper macros.
This method introduces a bit of extra code (50% of which is always
dead) for each struct it's used on, but it makes debugging large-ish
pieces of software relatively simple, since access to all object types
is controlled through the use of macros.
> For types that _will_ be in the tight loops, we must make the types
> explicit or it'll bite us hard performance-wise. I'm thinking what is
> "struct object" or "struct commit" in git.git. It's likely that we will
> loose a *lot* of those types are opaque.
>
The last sentence doesn't parse. I assume you mean "if those types are..",
in which case it'll be solved by using accessor-macros and forward-declaring
the structs.
> struct object in git has not changed since 2006.06. struct commit hasn't
> since 2005.04 if you ignore { unsigned int indegree; void *util; } that
> if I'm correct are annotations, and is a problem we (I think) have to
> address differently anyways (I gave my proposal on this, I'm eager to
> hear about what other think on the subject). So if in git.git that _is_
> a moving target we have had a 2 year old implementation for those types,
> it's that they're pretty well like this.
>
> It's IMNSHO on the matter that core structures of git _will_ have to be
> made explicit. I'm thinking objects and their "subtypes" (commits,
> trees, blobs). Maybe a couple of things on the same vein.
>
I agree. "git_commit", "git_tree", "git_blob" and "git_tag" can almost
certainly be set in stone straight away.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Elijah Newren @ 2008-11-01 18:36 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Sam Vilain
In-Reply-To: <1225338485-11046-1-git-send-email-sam@vilain.net>
Hi,
Good list.. I agree with others that the 'undo' name doesn't sound
right (and will discuss other issues with it in response to another
email) but otherwise nice work.
On Wed, Oct 29, 2008 at 9:48 PM, Sam Vilain <sam@vilain.net> wrote:
> + * 'git push' to checked out branch of non-bare repository not
> + allowed without special configuration. Configuration available
> + that allows working directory to be updated, known caveats
> + notwithstanding. Ideally, it would refuse only in situations
> + where a broken working copy would be left (because you couldn't
> + fix it), and work when it can be known to be safe.
Configuration of remote repository, special command-line override, or both?
Some food for thought: One thing I did in EasyGit was to disallow
pushes to non-bare repositories* unless both source and destinations
references were explicitly specified. For example:
$ eg push origin master # or 'eg push', in this case
Aborting: You are trying to push to a repository with an associated working
copy, which will leave its working copy out of sync with its repository.
Rather than pushing changes to that repository, you should go to where that
repository is located and pull changes into it (using eg pull). If you
know what you are doing and know how to deal with the consequences, you can
override this check by explicitly specifying source and destination
references, e.g.
eg push REMOTE BRANCH:REMOTE_BRANCH
Please refer to
eg help topic refspecs
to learn what this syntax means and what the consequences of overriding this
check are.
$ eg push origin master:master
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 260 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To /home/newren/testing/dumb/.git
852ffee..f5596e4 master -> master
This seems to prevent errors for new users, while still allowing
people to work around firewall issues.
* The big problem was that I was only able to detect if a remote
repository was bare or not if it was accessed via the local filesystem
or via ssh; for git:// (or rsync://) repositories I didn't know how to
perform such a check and so I simply omitted it.
Elijah
^ permalink raw reply
* Re: [PATCH] connect.c: add a way for git-daemon to pass an error back to client
From: Shawn O. Pearce @ 2008-11-01 18:10 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: Junio C Hamano, git
In-Reply-To: <b97024a40810312329o53e37fd5td82aa69634ff1e6b@mail.gmail.com>
Tom Preston-Werner <tom@github.com> wrote:
>
> I saw several methods of testing for a specific prefix in connect.c.
> Looking more closely at the source, the closest similar call is
> actually the test for ACK:
>
> if (!prefixcmp(line, "ACK ")) {
> if (!get_sha1_hex(line+4, result_sha1)) {
> if (strstr(line+45, "continue"))
> return 2;
> return 1;
> }
> }
>
> Explicitly testing for "ERR " (including the space) does seem like the
> more correct thing to do. Would you like me to resubmit a modified
> patch that uses prefixcmp()?
Yes, I think that is what Junio was hinting at. The pattern above
is much more typical in Git sources, so keeping the new "ERR "
check consistent would be appreciated.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2] Introduce receive.denyDeletes
From: Shawn O. Pearce @ 2008-11-01 18:07 UTC (permalink / raw)
To: Jan Krrrger; +Cc: Junio C Hamano, git
In-Reply-To: <20081101154216.45021eee@perceptron>
Jan Krrrger <jk@jk.gs> wrote:
> Occasionally, it may be useful to prevent branches from getting deleted from
> a centralized repository, particularly when no administrative access to the
> server is available to undo it via reflog. It also makes
> receive.denyNonFastForwards more useful if it is used for access control
> since it prevents force-updating by deleting and re-creating a ref.
>
> Signed-off-by: Jan Krüger <jk@jk.gs>
> ---
> Like this, then?
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> Documentation/config.txt | 4 ++++
> builtin-receive-pack.c | 12 ++++++++++++
> t/t5400-send-pack.sh | 11 +++++++++++
> 3 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 29369d0..965ed74 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1188,6 +1188,10 @@ receive.unpackLimit::
> especially on slow filesystems. If not set, the value of
> `transfer.unpackLimit` is used instead.
>
> +receive.denyDeletes::
> + If set to true, git-receive-pack will deny a ref update that deletes
> + the ref. Use this to prevent such a ref deletion via a push.
> +
> receive.denyNonFastForwards::
> If set to true, git-receive-pack will deny a ref update which is
> not a fast forward. Use this to prevent such an update via a push,
> diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
> index 9f60f31..2c0225c 100644
> --- a/builtin-receive-pack.c
> +++ b/builtin-receive-pack.c
> @@ -11,6 +11,7 @@
>
> static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
>
> +static int deny_deletes = 0;
> static int deny_non_fast_forwards = 0;
> static int receive_fsck_objects;
> static int receive_unpack_limit = -1;
> @@ -23,6 +24,11 @@ static int capabilities_sent;
>
> static int receive_pack_config(const char *var, const char *value, void *cb)
> {
> + if (strcmp(var, "receive.denydeletes") == 0) {
> + deny_deletes = git_config_bool(var, value);
> + return 0;
> + }
> +
> if (strcmp(var, "receive.denynonfastforwards") == 0) {
> deny_non_fast_forwards = git_config_bool(var, value);
> return 0;
> @@ -185,6 +191,12 @@ static const char *update(struct command *cmd)
> "but I can't find it!", sha1_to_hex(new_sha1));
> return "bad pack";
> }
> + if (deny_deletes && is_null_sha1(new_sha1) &&
> + !is_null_sha1(old_sha1) &&
> + !prefixcmp(name, "refs/heads/")) {
> + error("denying ref deletion for %s", name);
> + return "deletion prohibited";
> + }
> if (deny_non_fast_forwards && !is_null_sha1(new_sha1) &&
> !is_null_sha1(old_sha1) &&
> !prefixcmp(name, "refs/heads/")) {
> diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
> index 544771d..6fe2f87 100755
> --- a/t/t5400-send-pack.sh
> +++ b/t/t5400-send-pack.sh
> @@ -103,6 +103,17 @@ unset GIT_CONFIG GIT_CONFIG_LOCAL
> HOME=`pwd`/no-such-directory
> export HOME ;# this way we force the victim/.git/config to be used.
>
> +test_expect_failure \
> + 'pushing a delete should be denied with denyDeletes' '
> + cd victim &&
> + git config receive.denyDeletes true &&
> + git branch extra master &&
> + cd .. &&
> + test -f victim/.git/refs/heads/extra &&
> + test_must_fail git send-pack ./victim/.git/ :extra master
> +'
> +rm -f victim/.git/refs/heads/extra
> +
> test_expect_success \
> 'pushing with --force should be denied with denyNonFastforwards' '
> cd victim &&
> --
> 1.6.0.3.524.g86cf.dirty
--
Shawn.
^ 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