On Mon, Dec 09, 2013 at 03:37:50PM -0800, Junio C Hamano wrote:
> > +void submodule_config_cache_free(struct submodule_config_cache *cache)
> > +{
> > + /* NOTE: its important to iterate over the name hash here
> > +* since paths might have multiple entries */
>
> Style (multi-line comments)
On Wed, Dec 11, 2013 at 03:16:24PM -0800, Junio C Hamano wrote:
> Jens Lehmann writes:
>
> >> I think this is closely related to Martin's list of wishes we
> >> earlier saw in the thread: remind the user to push necessary
> >> submodule tip before the top-level commit that needs that commit in
>
On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
> You'll have to remind me what you mean by "incremental" here. Possibly
> it's something cvs-fast-export could support.
User can
- run a cvs to git import at time T, resulting in repo G
- make commits to cvs repo
- run cvs to git impor
On Thu, 12 Dec 2013 08:42:25 +, Martin Langhoff wrote:
...
> - run a cvs to git import at time T, resulting in repo G
> - make commits to cvs repo
> - run cvs to git import at time T1, pointed to G, and the import tool
> will only add the new commits found in cvs between T and T1.
I'm prett
On Thu, Dec 12, 2013 at 12:17 PM, Andreas Krey wrote:
> But anyway, the replacement question is a) how fast the cvs-fast-export is
> and b) whether its output is stable
In my prior work, the "better" CVS importers would not have stable
output, so were not appropriate for incremental imports.
And
Martin Langhoff :
> On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond wrote:
> > You'll have to remind me what you mean by "incremental" here. Possibly
> > it's something cvs-fast-export could support.
>
> User can
>
> - run a cvs to git import at time T, resulting in repo G
> - make commits t
Andreas Krey :
> But anyway, the replacement question is a) how fast the cvs-fast-export is
> and b) whether its output is stable, that is, if the cvs repo C yields
> a git repo G, will then C with a few extra commits yield G' where every
> commit in G (as identified by its SHA1) is also in G', and
On Mon, Apr 22, 2013 at 09:18:46AM +0200, Jeremy Rosen wrote:
> David Green wrote:
> > Please remember that I don't consider myself a gatekeeper to git
> > subtree. In fact I could use some help reviewing and approving
> > patches.
> > If anyone thinks a patch looks good, let Junio know. It's my
Martin Langhoff :
> In my prior work, the "better" CVS importers would not have stable
> output, so were not appropriate for incremental imports.
That is disturbing. I would consider lack of stability a severe and
unacceptable failure mode in such a tool, if only because of the
difficulties it cr
On Thu, Dec 12, 2013 at 1:15 PM, Eric S. Raymond wrote:
> That terminology -- "flying fish" and "dovetail" -- is interesting, and
> I have not heard it before. It might be woth putting in the Jargon File.
> Can you point me at examples of live usage?
The canonical reference would be
http://cvsbo
Am 12.12.2013 02:16, schrieb Junio C Hamano:
> "W. Trevor King" writes:
>
>> For
>> safety, maybe the default `init` should copy *everything* into
>> .git/config, after which users can remove stuff they'd like to
>> delegate to .gitmodules.
>
> Copying everything into config is "be unsafe and in
On Thu, Dec 12, 2013 at 1:29 PM, Eric S. Raymond wrote:
> I am almost certain the output of cvs-fast-export is stable. I
> believe the output of cvsps-3.x was, too. Not sure about 2.x.
IIRC, making the output stable is nontrivial, specially on branches.
Two cases are still in my mind, from when
On Thu, Dec 12, 2013 at 07:57:51PM +0100, Jens Lehmann wrote:
> Am 12.12.2013 02:16, schrieb Junio C Hamano:
> > I think the solution we want is to copy only minimum to the config
> > (and that "minimum" may turn out to be "nothing"), and to default
> > keys that are only absolutely safe to .gitmod
Jens Lehmann wrote:
> Am 12.12.2013 02:16, schrieb Junio C Hamano:
>> I think the solution we want is to copy only minimum to the config
>> (and that "minimum" may turn out to be "nothing"), and to default
>> keys that are only absolutely safe to .gitmodules file.
>
> I agree and will prepare a pa
Adam Spiers writes:
> On Mon, Apr 22, 2013 at 09:18:46AM +0200, Jeremy Rosen wrote:
>> David Green wrote:
>> > Please remember that I don't consider myself a gatekeeper to git
>> > subtree. In fact I could use some help reviewing and approving
>> > patches.
>> > If anyone thinks a patch looks go
Martin Langhoff :
> IIRC, making the output stable is nontrivial, specially on branches.
> Two cases are still in my mind, from when I was wrestling with cvsps.
>
> 1 - For a history with CVS HEAD and a long-running "stable release"
> branch ("STABLE"), which branched at P1...
>
>a - adding a
On Thu, Dec 12, 2013 at 2:39 PM, Eric S. Raymond wrote:
> Yikes! That is a much stricter stability criterion than I thought you
> were specifying.
:-) -- cvsps's approach is: if you have a cache, you can remember the
lies you told earlier.
It is impossible to be stable purely from the source da
Christian Couder writes:
> Here is version 3 of a patch series to improve the way
> sha1_object_info_extended() behaves when it is passed a
> replaced object. The idea is to add a flags argument to it
> in the same way as what has been done to read_sha1_file().
Thanks.
Will take a look again (i
Thomas Gummerer writes:
> git diff --no-index ... currently reads the index, during setup, when
> calling gitmodules_config(). This results in worse performance when the
> index is not actually needed. This patch avoids calling
> gitmodules_config() when the --no-index option is given. The tim
Martin Langhoff :
> If someone creates a nonsensical tag or branch point, tagging files
> from different commits, how do you handle it?
>
> - without commit ids, does it affect your guesses?
No. Tagging is never used to deduce changesets. Look:
/*
* The heart of the merge operation; detect wh
Jens Lehmann writes:
> Am 12.12.2013 02:16, schrieb Junio C Hamano:
>> "W. Trevor King" writes:
>>
>>> For
>>> safety, maybe the default `init` should copy *everything* into
>>> .git/config, after which users can remove stuff they'd like to
>>> delegate to .gitmodules.
>>
>> Copying everything
Krzesimir Nowak writes:
> First patch splits some code to a function.
>
> Second patch fixes validation functions to return either 0 or 1,
> instead of undef or passed $input.
>
> Third patch adds the extra-branch-feature and some documentation.
>
> Fourth patch adds some visual differentation of
On Thu, Dec 12, 2013 at 3:58 PM, Eric S. Raymond wrote:
>> - regardless of commit ids, do you synthesize an artificial commit?
>> How do you define parenthood for that artificial commit?
>
> Because tagging is never used to deduce changesets, the case does not arise.
So if a branch has a nonsens
Martin Langhoff :
> On Thu, Dec 12, 2013 at 3:58 PM, Eric S. Raymond wrote:
> >> - regardless of commit ids, do you synthesize an artificial commit?
> >> How do you define parenthood for that artificial commit?
> >
> > Because tagging is never used to deduce changesets, the case does not arise.
>
Commit f2c681cf ("send-pack: support pushing from a shallow clone
via http", 05-12-2013) adds the 'advertise_shallow_grafts_buf'
function as an external symbol. This symbol does not require
more than file visibility.
Noticed by sparse. ("'advertise_shallow_grafts_buf' was not declared.
Should it
John Szakmeister writes:
> On Mon, Dec 9, 2013 at 1:06 PM, Junio C Hamano wrote:
> [snip]
>>
>> I thought we cast without SP after the (typename), i.e.
>>
>> gpointer *data = (gpointer *)user_data;
>
> I've found a mixture of both in the code base, and the
> CodingGuidelines doesn't say
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-publi
On Fri, Dec 13, 2013 at 6:15 AM, Ramsay Jones
wrote:
> BTW, I have not been following these patches, but I noticed that the
> 'remove_nonexistent_ours_in_pack()' function has no callers. (There are
> two commented out callers - but they seem to have *always* been commented
> out ;-) ). So, step 5
On Fri, Dec 13, 2013 at 7:57 AM, Junio C Hamano wrote:
> * nd/negative-pathspec (2013-12-06) 3 commits
> (merged to 'next' on 2013-12-12 at 9f340c8)
> + pathspec.c: support adding prefix magic to a pathspec with mnemonic magic
> + Support pathspec magic :(exclude) and its short form :!
> + gl
On Thu, Dec 12, 2013 at 6:04 PM, Eric S. Raymond wrote:
> I'm not sure what counts as a nonsensical branching point. I do know that
> Keith left this rather cryptic note in a REAME:
Keith names exactly what we are talking about. At that time, Keith was
struggling with the old xorg cvs repo which
Martin Langhoff :
> On Thu, Dec 12, 2013 at 6:04 PM, Eric S. Raymond wrote:
> > I'm not sure what counts as a nonsensical branching point. I do know that
> > Keith left this rather cryptic note in a REAME:
>
> Keith names exactly what we are talking about.
Oh, yeah, I figured that much out. Wha
On 12/13/2013 01:57 AM, Junio C Hamano wrote:
[Cooking]
* fc/transport-helper-fixes (2013-12-09) 6 commits
- remote-bzr: support the new 'force' option
- test-hg.sh: tests are now expected to pass
- transport-helper: check for 'forced update' message
- transport-helper: add 'force' to 'e
32 matches
Mail list logo
