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
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 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
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 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
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
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
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
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.
>
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
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
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
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
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
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
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
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
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
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
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
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
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: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
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 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
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
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
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
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 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 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 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)
32 matches
Mail list logo
