* Re: How it was at GitTogether'08 ?
From: Tim Ansell @ 2008-11-10 3:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce, Jeff King, Petr Baudis, Steven Grimm
In-Reply-To: <200811091249.40735.jnareb@gmail.com>
> > Wed, Oct 29, 2008
> > -----------------
> + What was the difference between "Tim: Large media in Git (Repeat)"
> from Wed, and earlier "Tim: Git as a Media Repository" from Tue?
The first day I got people feed back on my proposal (whiteboard
discussion) and then presented the proposal on Wednesday.
You can find the slides of the presentation at
http://www.thousandparsec.net/~tim/media+git.pdf
Sorry about the duplicate messages, I hit send too soon.
Tim 'mithro' Ansell
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 1:16 UTC (permalink / raw)
To: sverre; +Cc: git
In-Reply-To: <bd6139dc0811091643m31ff6f49o55a4c581be7f38b2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Mon, Nov 10, 2008 at 01:22, Michal Nazarewicz <mina86@tlen.pl> wrote:
>> Now, what I need is such feature in GIT. Upon committing I would like
>> some magic string (say "$Date$") to be replaced with some value
>> identifying uniquely given version of a file (a date of the commit would
>> be sufficient).
>
> Please have a look at the relevant entry in the faq [0].
>
> [0] http://git.or.cz/gitwiki/GitFaq#head-4a0afe71a2bb7734777a8b0b345e0308aefdbd40
Thanks for the quick reply (and yes, I can't believe I couldn't find
that myself...) but it still lacks one thing that I'd like to have.
I would like the "$Id$" sequences to be updated automatically after
a commit (ie. without the need to check out). (Besides I would prefer
$Date$ more but I can live with $Id$ I guess ;) ).
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: git-svn: fix example for centralized SVN clone
From: Eric Wong @ 2008-11-10 1:12 UTC (permalink / raw)
To: Jan Krüger; +Cc: aroben, Git ML, Junio C Hamano
In-Reply-To: <20081109230012.47adbb32@perceptron>
Jan Krüger <jk@jk.gs> wrote:
> The example that tells users how to centralize the effort of the initial
> git svn clone operation doesn't work properly. It uses rebase but that
> only works if HEAD exists. This adds one extra command to create a
> somewhat sensible HEAD that should work in all cases.
>
> Signed-off-by: Jan Krüger <jk@jk.gs>
> ---
> I have a feeling this looks a bit ugly, but I can't think of a simpler
> solution (especially since we're not fetching the central repo's HEAD).
> Still, it's certainly better than a broken example.
*shrug* Seems alright with me.
Adam wrote the original example, maybe he knows better.
> Documentation/git-svn.txt | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 84c8f3c..ba94cd1 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -544,6 +544,8 @@ have each person clone that repository with 'git-clone':
> git remote add origin server:/pub/project
> git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
> git fetch
> +# Create a local branch from one of the branches just fetched
> + git checkout -b master FETCH_HEAD
> # Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
> git svn init http://svn.example.com/project
> # Pull the latest changes from Subversion
> --
> 1.6.0.3.578.g6a50
--
Eric Wong
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Sverre Rabbelier @ 2008-11-10 0:43 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: git
In-Reply-To: <87ljvsjuq7.fsf@erwin.mina86.com>
On Mon, Nov 10, 2008 at 01:22, Michal Nazarewicz <mina86@tlen.pl> wrote:
> Now, what I need is such feature in GIT. Upon committing I would like
> some magic string (say "$Date$") to be replaced with some value
> identifying uniquely given version of a file (a date of the commit would
> be sufficient).
Please have a look at the relevant entry in the faq [0].
[0] http://git.or.cz/gitwiki/GitFaq#head-4a0afe71a2bb7734777a8b0b345e0308aefdbd40
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-10 0:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Galiegue, Git Mailing List, Pierre Habouzit
In-Reply-To: <7viqqwa6wo.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1309 bytes --]
On Sun, 9 Nov 2008, Junio C Hamano wrote:
> Ian Hilt <ian.hilt@gmx.com> writes:
>
> > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> >>
> >> Greedy operators are only supported with perl 5.10 or more... I think it's a
> >> bad idea to use them...
> >
> > The problem here was that a space should follow the field, but it may
> > not. The user may unwarily backup over it. "\s*" would match this
> > case.
> >
> > But if there is a space, it is included in the "(.+)". So I tried
> > "\s+", which did not include the space, but it won't include the first
> > address if there isn't a space after the field.
> >
> > The quantified subpattern seemed to do the trick. But, if it could
> > result in a dependency issue, I would agree this would be a bad idea.
>
> You expect something non-blank there anyway, so why not do:
>
> To:\s*(\S.*?)\s*\n....
That works. Although, I seem to be missing Francis' point. According
to perlre, a quantified subpattern is "greedy". So a "greedy operator"
is any one of the standard quantified subpatterns. The "+" and "?"
modify its matching behavior. And it seems to me that it _has_ to use a
q.s. to work ...
^ permalink raw reply
* Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 0:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 911 bytes --]
Hello,
as probably many of you know CVS supported some magic tags which were
replaced in committed files to a predefined value. For instance, if
there was a "$Revision$" string in a file it would get replaced with
"$Revision: x.y $" (or "$Revision: x.y.z.w $" and so on) where "x.y" is
file's revision number.
Now, what I need is such feature in GIT. Upon committing I would like
some magic string (say "$Date$") to be replaced with some value
identifying uniquely given version of a file (a date of the commit would
be sufficient).
I tried using some hooks for it but couldn't came up with anything that
would actually work.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply
* What's cooking in git.git (Nov 2008, #03; Sun, 09)
From: Junio C Hamano @ 2008-11-10 0:09 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* jk/deny-push-to-current (Sat Nov 8 20:49:27 2008 -0500) 2 commits
+ receive-pack: detect push to current branch of non-bare repo
+ t5516: refactor oddball tests
* dl/xdiff (Fri Nov 7 21:24:33 2008 -0800) 1 commit
+ xdiff: give up scanning similar lines early
This performance fix may eventually need to be cherry-picked to 'maint'.
----------------------------------------------------------------
[Graduated to "master"]
* cb/maint-update-ref-fix (Wed Nov 5 21:55:54 2008 +0100) 2 commits
+ push: fix local refs update if already up-to-date
+ do not force write of packed refs
* rs/blame (Sat Oct 25 15:31:36 2008 +0200) 5 commits
+ blame: use xdi_diff_hunks(), get rid of struct patch
+ add xdi_diff_hunks() for callers that only need hunk lengths
+ Allow alternate "low-level" emit function from xdl_diff
+ Always initialize xpparam_t to 0
+ blame: inline get_patch()
* ds/autoconf (Sun Oct 26 03:52:19 2008 -0800) 1 commit
+ autoconf: Add link tests to each AC_CHECK_FUNC() test
Attempts to help FreeBSD whose compiler does not error out when told to
compile a program that calls unavailable functions.
----------------------------------------------------------------
[Actively Cooking]
* gb/gitweb-snapshot-pathinfo (Sun Nov 2 10:21:39 2008 +0100) 3 commits
+ gitweb: embed snapshot format parameter in PATH_INFO
+ gitweb: retrieve snapshot format from PATH_INFO
+ gitweb: make the supported snapshot formats array global
Got sick of waiting for re-Ack. Merged to 'next'.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
+ gitweb: Better processing format string in custom links in navbar
Got sick of waiting for some sort of response from Pasky. Merged to 'next'.
* st/tag (Wed Nov 5 00:20:36 2008 +0100) 2 commits
+ tag: Add more tests about mixing incompatible modes and options
+ tag: Check that options are only allowed in the appropriate mode
* np/pack-safer (Sun Nov 9 13:11:06 2008 -0800) 11 commits
+ t5303: fix printf format string for portability
+ t5303: work around printf breakage in dash
+ pack-objects: don't leak pack window reference when splitting
packs
+ extend test coverage for latest pack corruption resilience
improvements
+ pack-objects: allow "fixing" a corrupted pack without a full
repack
+ make find_pack_revindex() aware of the nasty world
+ make check_object() resilient to pack corruptions
+ make packed_object_info() resilient to pack corruptions
+ make unpack_object_header() non fatal
+ better validation on delta base object offsets
+ close another possibility for propagating pack corruption
* mv/remote-rename (Mon Nov 3 19:26:18 2008 +0100) 1 commit
+ Implement git remote rename
* lt/decorate (Mon Nov 3 11:25:46 2008 -0800) 4 commits
+ revision traversal: '--simplify-by-decoration'
+ Make '--decorate' set an explicit 'show_decorations' flag
+ revision: make tree comparison functions take commits rather than
trees
+ Add a 'source' decorator for commits
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 5 commits
- autoconf: Enable threaded delta search when pthreads are supported
+ Add autoconf tests for pthreads
+ Make Pthread link flags configurable
+ Add Makefile check for FreeBSD 4.9-SECURITY
+ Build: add NO_UINTMAX_T to support ancient systems
I split the part that unconditionally enable threaded delta search on any
platform on which Pthread library is detected to be available from the
topmost one.
* jk/diff-convfilter (Sun Oct 26 00:50:02 2008 -0400) 8 commits
+ enable textconv for diff in verbose status/commit
+ wt-status: load diff ui config
+ only textconv regular files
+ userdiff: require explicitly allowing textconv
+ refactor userdiff textconv code
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
* jk/diff-convfilter-test-fix (Fri Oct 31 01:09:13 2008 -0400) 4 commits
+ Avoid using non-portable `echo -n` in tests.
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
An update to the one above.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Early parts looked Ok; I am trying to find time to review the whole thing
but fixing bugs in topics from other people here and there took almost all
my time this weekend. Not good.
----------------------------------------------------------------
[Dropped]
* bc/maint-keep-pack (Mon Nov 3 14:43:22 2008 -0600) 3 commits
. pack-objects: honor '.keep' files
. packed_git: convert pack_local flag into a bitfield and add
pack_keep
. t7700: demonstrate mishandling of objects in packs with a .keep
file
It seems this is better rethought from the design level.
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-09 23:52 UTC (permalink / raw)
To: Steven Grimm
Cc: Shawn O. Pearce, Robin Rosenberg, git, Jeff King, Petr Baudis,
Tim Ansell
In-Reply-To: <2E4FE676-0128-4664-86A1-5EED75876A37@midwinter.com>
Steven Grimm wrote:
> On Nov 9, 2008, at 11:55 AM, Shawn O. Pearce wrote:
> > No, its not. The owner of the document can publish the document,
> > making it world-readable, *without* needing a login. I think they
> > just forgot to do that on this particular presentation.
>
>
> My bad. Here's the published, no-login-required version:
>
> http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj
Would it be possible to publish PDF version sowehere, for example
as attachement to http://git.or.cz/gitwiki/GitTogether? My old
web browser doesn't support Google Docs...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jean-Luc Herren @ 2008-11-09 23:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811080254.53202.jnareb@gmail.com>
Jakub Narebski wrote:
> and the rest is being used to order and distribute some git
> t-shirts.
Do such git shirts exist already and could be ordered somewhere?
I might be interested in buying one.
Cheers,
jlh
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Junio C Hamano @ 2008-11-09 22:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, Sam Vilain
In-Reply-To: <20081109014926.GA31276@coredump.intra.peff.net>
Thanks; will be in 'next'.
^ permalink raw reply
* Re: [PATCH] Documentation: bisect: change a few instances of "git-cmd" to "git cmd"
From: Junio C Hamano @ 2008-11-09 22:12 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20081109145314.cab893d7.chriscool@tuxfamily.org>
Thanks; will apply to 'maint'.
^ permalink raw reply
* Re: [PATCH] Documentation: rev-list: change a few instances of "git-cmd" to "git cmd"
From: Junio C Hamano @ 2008-11-09 22:11 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20081109144635.45a62b30.chriscool@tuxfamily.org>
Thanks, will apply to 'maint'.
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Junio C Hamano @ 2008-11-09 22:09 UTC (permalink / raw)
To: Ian Hilt; +Cc: Francis Galiegue, Git Mailing List, Pierre Habouzit
In-Reply-To: <alpine.LFD.2.00.0811091344480.20499@sys-0.hiltweb.site>
Ian Hilt <ian.hilt@gmx.com> writes:
> On Sun, 9 Nov 2008, Francis Galiegue wrote:
>> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
>> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
>>
>> Greedy operators are only supported with perl 5.10 or more... I think it's a
>> bad idea to use them...
>
> The problem here was that a space should follow the field, but it may
> not. The user may unwarily backup over it. "\s*" would match this
> case.
>
> But if there is a space, it is included in the "(.+)". So I tried
> "\s+", which did not include the space, but it won't include the first
> address if there isn't a space after the field.
>
> The quantified subpattern seemed to do the trick. But, if it could
> result in a dependency issue, I would agree this would be a bad idea.
You expect something non-blank there anyway, so why not do:
To:\s*(\S.*?)\s*\n....
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-09 22:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081109195445.GC2932@spearce.org>
Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > Still missing (neither video, nor slides, nor description, nor email)
> > are the following talks from GitTogether'08
>
> JGit slides:
> http://www.spearce.org/2008/11/JGit.pdf
>
> Pack v4 slides:
> http://www.spearce.org/2008/11/Pack_v4.pdf
Thanks. Added to http://git.or.cz/gitwiki/GitTogether
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Documentation: git-svn: fix example for centralized SVN clone
From: Jan Krüger @ 2008-11-09 22:00 UTC (permalink / raw)
To: Git ML; +Cc: Junio C Hamano, Eric Wong
The example that tells users how to centralize the effort of the initial
git svn clone operation doesn't work properly. It uses rebase but that
only works if HEAD exists. This adds one extra command to create a
somewhat sensible HEAD that should work in all cases.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
I have a feeling this looks a bit ugly, but I can't think of a simpler
solution (especially since we're not fetching the central repo's HEAD).
Still, it's certainly better than a broken example.
Documentation/git-svn.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 84c8f3c..ba94cd1 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -544,6 +544,8 @@ have each person clone that repository with 'git-clone':
git remote add origin server:/pub/project
git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
+# Create a local branch from one of the branches just fetched
+ git checkout -b master FETCH_HEAD
# Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
git svn init http://svn.example.com/project
# Pull the latest changes from Subversion
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* Re: How it was at GitTogether'08 ?
From: Steven Grimm @ 2008-11-09 21:58 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Robin Rosenberg, Jakub Narebski, git, Jeff King, Petr Baudis,
Tim Ansell
In-Reply-To: <20081109195538.GD2932@spearce.org>
On Nov 9, 2008, at 11:55 AM, Shawn O. Pearce wrote:
> No, its not. The owner of the document can publish the document,
> making it world-readable, *without* needing a login. I think they
> just forgot to do that on this particular presentation.
My bad. Here's the published, no-login-required version:
http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj
-Steve
^ permalink raw reply
* Re: libgit2 - a true git library
From: Shawn O. Pearce @ 2008-11-09 21:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, Steve Frrrcinaux, git, Scott Chacon
In-Reply-To: <4916B8AA.2080602@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>
> Well, I suggested putting "src/public/public_header.h" quite early on,
I must have missed that suggestion. Its not a bad idea.
> with private headers next to the source. AFAIU, the private and public
> headers both are now located in the same directory, and that directory is
> separate from the .c files.
Currently there are only public headers, and the public headers are
all under include/git/. Private headers are going to be under src/
so they are isolated from the public headers.
But I haven't had a chance to touch libgit2 in over a week. :-\
I've simply got too many projects going on at once. This is one
I really want to work on though, so I'm going to try and make time
for it next week. But I'm also in the middle of a major overhaul
of Gerrit, so it can run on non-Google infrastructure and thus is
usable by pretty much anyone.
--
Shawn.
^ permalink raw reply
* Re: force a merge conflict
From: Deskin Miller @ 2008-11-09 20:35 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0811091219t393ab1faj8d1c4df6de3c260c@mail.gmail.com>
On Sun, Nov 09, 2008 at 03:19:57PM -0500, Caleb Cushing wrote:
> > I'm not sure a 'conflict' is what you want, based on what you say below;
> > rather, it seems you simply want to force a 'merge commit', i.e. a commit with
> > multiple parents.
>
> >
> > git merge --no-ff ?
> >
> I tried that but I don't see that it's any different than a fast
> forward in this scenario. Actually I don't see any difference between
> it and a fast-forward.
Look at the results of 'git merge' and 'git merge --no-ff' in gitk. Or,
compare the resultant sha1 for the two commit objects. Or, look at 'git log'
of the resulting commit objects, and look for a 'Merge:' line.
Deskin Miller
^ permalink raw reply
* Re: force a merge conflict
From: Caleb Cushing @ 2008-11-09 20:19 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081109183917.GA18415@euler>
> I'm not sure a 'conflict' is what you want, based on what you say below;
> rather, it seems you simply want to force a 'merge commit', i.e. a commit with
> multiple parents.
>
> git merge --no-ff ?
>
I tried that but I don't see that it's any different than a fast
forward in this scenario. Actually I don't see any difference between
it and a fast-forward.
--
Caleb Cushing
^ permalink raw reply
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-09 20:09 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Pierre Habouzit
In-Reply-To: <200811091513.55544.fg@one2team.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 765 bytes --]
On Sun, 9 Nov 2008, Francis Galiegue wrote:
> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
>
> Greedy operators are only supported with perl 5.10 or more... I think it's a
> bad idea to use them...
The problem here was that a space should follow the field, but it may
not. The user may unwarily backup over it. "\s*" would match this
case.
But if there is a space, it is included in the "(.+)". So I tried
"\s+", which did not include the space, but it won't include the first
address if there isn't a space after the field.
The quantified subpattern seemed to do the trick. But, if it could
result in a dependency issue, I would agree this would be a bad idea.
Ian
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Shawn O. Pearce @ 2008-11-09 19:55 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Steven Grimm, Jakub Narebski, git, Jeff King, Petr Baudis,
Tim Ansell
In-Reply-To: <200811091958.32893.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> söndag 09 november 2008 17:52:58 skrev Steven Grimm:
> > On Nov 9, 2008, at 3:49 AM, Jakub Narebski wrote:
> > > Still missing (neither video, nor slides, nor description, nor email)
> > > are the following talks from GitTogether'08
> > >> * Steven: Life with git-svn
> >
> > Here are the slides from David's and my talk:
> >
> > http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj&invite=v4t8kr
>
> Requiring a google (or facebook for that matter) account is read public documents
> is not nice.
No, its not. The owner of the document can publish the document,
making it world-readable, *without* needing a login. I think they
just forgot to do that on this particular presentation.
Steven, can you publish that doc, so it doesn't require login
to read?
--
Shawn.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Shawn O. Pearce @ 2008-11-09 19:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Jeff King, Petr Baudis, Steven Grimm, Tim Ansell
In-Reply-To: <200811091249.40735.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
>
> Still missing (neither video, nor slides, nor description, nor email)
> are the following talks from GitTogether'08
JGit slides:
http://www.spearce.org/2008/11/JGit.pdf
Pack v4 slides:
http://www.spearce.org/2008/11/Pack_v4.pdf
I also had these as a Google Doc, but its internal on the google.com
domain so I can't easily publish it. Plus PDF is probably more
portable to older browsers than the Google Docs site is. :-)
--
Shawn.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Robin Rosenberg @ 2008-11-09 18:58 UTC (permalink / raw)
To: Steven Grimm
Cc: Jakub Narebski, git, Shawn O. Pearce, Jeff King, Petr Baudis,
Tim Ansell
In-Reply-To: <F0422D64-2A35-4755-BD28-782BFA634AAC@midwinter.com>
söndag 09 november 2008 17:52:58 skrev Steven Grimm:
> On Nov 9, 2008, at 3:49 AM, Jakub Narebski wrote:
> > Still missing (neither video, nor slides, nor description, nor email)
> > are the following talks from GitTogether'08
> >> * Steven: Life with git-svn
>
> Here are the slides from David's and my talk:
>
> http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj&invite=v4t8kr
Requiring a google (or facebook for that matter) account is read public documents
is not nice.
-- robin
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Junio C Hamano @ 2008-11-09 18:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Jeff King
In-Reply-To: <20081105104001.GA22272@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> Okay, still having --[no-]format-patch is probably a good idea indeed
> for scripts. Will do.
> ...
> Probably, I kept what was done as is, but we probably want do_edit() to
> die() if the user killed it.
> ...
>> So I am not opposed to a sendemail.foo configuration option.
>
> Will do
Thanks.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Kai Blin @ 2008-11-09 18:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Symonds, git, Johannes Schindelin, Tim Ansell
In-Reply-To: <200811091731.48694.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]
On Sunday 09 November 2008 17:31:47 Jakub Narebski wrote:
> The workaround is to put all large files for example in 'media/' folder,
> and make this folder be submodule. Each clone of repository can have
> this 'media' submodule either present (both in object database, although
> usually separate from main project object database), or not present
> (not cloned and not checked out).
Tim was talking about that media/ folder and managing that in git. If you want
to work on the media, you might end up getting hundreds of gigabytes of data
to get that folder, even if you only need to change one single file.
That's the issue we're running into, and I don't thing submodules solve this
at all.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 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