Hi,
i'm not entirely sure if this is a bug or intended (couldn't find it in the
changelogs though)...
Before 2.12.0 a `git commit --int` / `git add --int` followed by [p] for
patch-mode, would allow a numeric selection of the files to patch hunks for
(this behavior is well documented all over
Hi,
I've been hacking away on a library for quite some time and have a lot of
commits in my private repository:
A -> B -> C -> D -> E
Finally, I'm nearing completion of a first version, and want to publish it to a
remote called public from D onward keeping A..C to myself, so public should
aft
On 4 Aug 2013, at 15:31, Felipe Contreras wrote:
> git config --get-regexp '^remote.*.url' is probably more appropriate.
>
> Either way, I don't see why such a change should be in the same patch.
+1
> This is my solution:
>
> --- a/contrib/remote-helpers/git-remote-hg.py
> +++ b/contrib/remot
Hi,
On 4 Aug 2013, at 01:17, Felipe Contreras wrote:
> On Sat, Aug 3, 2013 at 11:36 AM, Jörn Hees wrote:
>
>> it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a
>> mercurial repo the timezone information of commits gets transformed into
>&g
Hi,
On 4 Aug 2013, at 12:38, Antoine Pelisse wrote:
> […]
> I also decided to always clone local repositories because what Jörn Hees
> said makes sense:
> If you have a local clone of a big repository, and then want to add a slow
> remote, you would have to reclone everything
Hi,
it seems that if you use the 1.8.3.4 remote-helpers/git-remote-hg to clone a
mercurial repo the timezone information of commits gets transformed into your
current timezone.
(command: git clone hg::…)
I noticed this when a colleague in another timezone used Kiln to also export
the same merc
On 25 Jul 2013, at 21:12, Felipe Contreras wrote:
>> […]
>> ---
>> contrib/remote-helpers/git-remote-hg | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/contrib/remote-helpers/git-remote-hg
>> b/contrib/remote-helpers/git-remote-hg
>> index 0194c67..f4e9d1c 100755
>> -
On 25 Jul 2013, at 23:10, Antoine Pelisse wrote:
> On Thu, Jul 25, 2013 at 10:40 PM, Felipe Contreras
> wrote:
>> That's true. Maybe something like:
>>
>> for x in repos:
>> local_hg = os.path.join(shared_path, x, 'clone', '.hg')
>> if os.path.exists(local_hg):
>>shutil.copytree(local_hg,
On 25 Jul 2013, at 01:02, Junio C Hamano wrote:
> Joern Hees writes:
>>
>> Changing shared_path to ".git/hg/.shared" will solve this problem
>
> Here you say "shared" and the code says "share"; which one is
> preferred (I know either would work, but we would want to be
> consistent).
>
> I'd
On 24 Jul 2013, at 17:20, Junio C Hamano wrote:
> Antoine Pelisse writes:
>
>> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees wrote:
>>> On 24.07.2013, at 10:52, Antoine Pelisse wrote:
>>>> I think the best way would be to create the shared repository in
>&
On 24.07.2013, at 15:14, Antoine Pelisse wrote:
> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees wrote:
>> On 24.07.2013, at 10:52, Antoine Pelisse wrote:
>>> I think the best way would be to create the shared repository in
>>> .git/hg/$share, with $share being a path
Hi,
On 24.07.2013, at 10:52, Antoine Pelisse wrote:
> I think the best way would be to create the shared repository in
> .git/hg/$share, with $share being a path that can't be a remote name
> (so that it doesn't conflict with remote directories),
> and then apply the following patch (copied in gm
12 matches
Mail list logo
