Git development
 help / color / mirror / Atom feed
* 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

* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Jonas Fonseca @ 2008-11-09 18:52 UTC (permalink / raw)
  To: Piotr Findeisen; +Cc: git
In-Reply-To: <ddb82bf60811090044l43eb4bb1ga5a16718a4176c29@mail.gmail.com>

> On Fri, Nov 7, 2008 at 04:09, Piotr Findeisen <piotr.findeisen@gmail.com> wrote:
>> Hello!

Hello,

>> The attached file is a result of running `git diff HEAD~1`.

Please read Documentation/SubmittingPatches for the preferred way to
contribute patches.

>> Asciidoc replaces "--" with "—" when not in verbatim mode. This is
>> sometimes unwanted -- especially when citing command line options like
>> "git diff --cached". This commit includes proper quotes in user-manual.txt.

Newer asciidoc versions have the following "workaround". Maybe adding
something like this to Documentation/asciidoc.conf would be more
future proof.

# -- Spaced and unspaced em dashes (entity reference &mdash;)
# But disallow unspaced in man pages because double-dash option name prefixes
# are pervasive.
ifndef::doctype-manpage[]
(^|[^-\\])--($|[^-])=\1&#8212;\2
endif::doctype-manpage[]
ifdef::doctype-manpage[]
(^|\s*[^\S\\])--($|\s+)=\1&#8212;\2
endif::doctype-manpage[]
\\--(?!-)=--

-- 
Jonas Fonseca

^ permalink raw reply

* Re: force a merge conflict
From: Deskin Miller @ 2008-11-09 18:39 UTC (permalink / raw)
  To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0811090709s483506c1h6f9cb0f96216ef22@mail.gmail.com>

On Sun, Nov 09, 2008 at 10:09:49AM -0500, Caleb Cushing wrote:
> is there any way to force a merge conflict?

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.

> in this case I have a dev branch and fork branch the fork is a copy of
> dev except I committed one of the files from the fork. I need to merge
> this file back into dev, but git thinks it's a fast forward, because
> it really is for git, in reality it isn't, both files have newer
> history than their common ancestry.

git merge --no-ff ?

Hope that helps,
Deskin Miller

^ permalink raw reply

* Re: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
From: Junio C Hamano @ 2008-11-09 18:33 UTC (permalink / raw)
  To: Simon Hausmann, Han-Wen Nienhuys; +Cc: John Chapman, git
In-Reply-To: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>

These are patches to fast-import/git-p4, which you two seem to in charge
of.

    From:	John Chapman <thestar@fussycoder.id.au>
    Subject: [PATCH 1/2] Added support for purged files and also optimised memory usage.
    Date:	Sat,  8 Nov 2008 14:22:48 +1100
    Message-Id: <1226114569-8506-1-git-send-email-thestar@fussycoder.id.au>

    From:	John Chapman <thestar@fussycoder.id.au>
    Subject: [PATCH 2/2] Cached the git configuration, which is now noticibly faster on windows.
    Date:	Sat,  8 Nov 2008 14:22:49 +1100
    Message-Id: <1226114569-8506-2-git-send-email-thestar@fussycoder.id.au>

It was unfortunately not immediately obvious from the Subject: line what
these patches are about, and I am guessing you missed them because of that.

^ permalink raw reply

* [ANNOUNCE] GIT 1.6.0.4
From: Junio C Hamano @ 2008-11-09 18:07 UTC (permalink / raw)
  To: git; +Cc: linux-kernel

The latest maintenance release GIT 1.6.0.4 is available at the
usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.0.4.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.0.4.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.0.4.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are also provided
as courtesy.

  RPMS/$arch/git-*-1.6.0.4-1.fc9.$arch.rpm	(RPM)

Fixes since v1.6.0.3
--------------------

* 'git add -p' said "No changes" when only binary files were changed.

* 'git archive' did not work correctly in bare repositories.

* 'git checkout -t -b newbranch' when you are on detached HEAD was broken.

* when we refuse to detect renames because there are too many new or
  deleted files, 'git diff' did not say how many there are.

* 'git push --mirror' tried and failed to push the stash; there is no
  point in sending it to begin with.

* 'git push' did not update the remote tracking reference if the corresponding
  ref on the remote end happened to be already up to date.

* 'git pull $there $branch:$current_branch' did not work when you were on
  a branch yet to be born.

* when giving up resolving a conflicted merge, 'git reset --hard' failed
  to remove new paths from the working tree.

* 'git send-email' had a small fd leak while scanning directory.

* 'git status' incorrectly reported a submodule directory as an untracked
  directory.

* 'git svn' used deprecated 'git-foo' form of subcommand invocaition.

* 'git update-ref -d' to remove a reference did not honor --no-deref option.

* Plugged small memleaks here and there.

* Also contains many documentation updates.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox