On 20 Aug 2012, at 13:32, Alexey Muranov wrote:
> The problem of mapping branch names to file paths looks to me very similar to
> the problem of mapping URLs to file paths for static web sites, so i would
> propose to use the same solution: add a special extension to distinguish a
&g
Dear Junio,
On 20 Aug 2012, at 02:26, Junio C Hamano wrote:
> We are not particularly interested in "it is possible" when many
> implementations can all trivially allow it to be "possible"; the
> question is what a sensible solution is among them, and I didn't
> find "a directory with timestamp i
On 19 Aug 2012, at 19:38, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> 2. I think that allowing both "next" and "next/foo" complicates
>> the mapping from branch names to file paths, and it does not seem
>> necessary if dead reflogs are
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> Excuse me if i miss something again, but i might be willing to
>> discuss the "ultimate destination". Could you possibly state in
>> simple terms what the problem with determinin
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> I hope my opinion might be useful because i do not know anything
>> about the actual implementation of Git,...
>
> That sounds like contradiction.
I meant that i am psychologically not
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> I hope my opinion might be useful because i do not know anything
>> about the actual implementation of Git,...
>
> That sounds like contradiction.
I think that the implementation (the c
On 18 Aug 2012, at 22:39, Junio C Hamano wrote:
> Do we _know_ already what the "ultimate destination" looks like?
>
> If the answer is yes, then I agree, but otherwise, I doubt it is a
> good idea to introduce unnecessary complexity to the system that may
> have to be ripped out and redone.
>
On 26 Jul 2012, at 18:59, Jeff King wrote:
> Not to mention git itself, as it splits up the refs/remotes hierarchy
> into subdirectories. I think deprecating "/" is out of the question.
>
> -Peff
Ok, i guess you know better than me, my vision of Git is probably still too
simplistic.
-Alexey.--
On 26 Jul 2012, at 14:47, Nguyen Thai Ngoc Duy wrote:
> So we haven't found any way to present both branches "foo" and
> "foo/bar" on file system at the same time. How about when we a new
> branch introduces such a conflict, we push the new branch directly to
> packed-refs? If we need either of th
On 22 Jul 2012, at 15:14, Jeff King wrote:
> 3. Most importantly, it does not resolve D/F conflicts (it has the
> same problem as "logs/refs/heads/a~"). If you delete "foo/bar", you
> will end up with "logs/refs/heads/foo/bar@{...}". That will prevent
> D/F conflicts with a new branch
On 22 Jul 2012, at 13:10, Alexey Muranov wrote:
> Sorry if this idea is stupid or if i miss something, but how about putting
> deleted reflogs for
>
> refs/heads/a
> refs/heads/a/b
> refs/heads/a/b/c
>
> to
>
> refs/heads/a@-mm-dd-hhmmss
> refs/heads/a/b
On 20 Jul 2012, at 17:44, Jeff King wrote:
> On Fri, Jul 20, 2012 at 11:49:07AM +0200, Michael Haggerty wrote:
>
>>> This patch moves reflog entries into a special "graveyard"
>>> namespace, and appends a tilde (~) character, which is
>>> not allowed in a valid ref name. This means that the delet
On 20 Jul 2012, at 19:09, Jeff King wrote:
> On Fri, Jul 20, 2012 at 06:37:02PM +0200, Johannes Sixt wrote:
>
>> Am 20.07.2012 17:44, schrieb Jeff King:
>>> So I think a suffix like ":d" is probably the least horrible.
>>
>> Not so. It does not work on Windows :-( in the expected way. Trying to
On 20 Jul 2012, at 16:26, Jeff King wrote:
> On Fri, Jul 20, 2012 at 12:23:12AM +0200, Alexey Muranov wrote:
>
>> i have no idea about Git source and little idea of how it is working
>> internally, but reading through your message i wonder: wouldn't it be
>> a go
On 20 Jul 2012, at 09:11, Johannes Sixt wrote:
> Am 7/19/2012 23:20, schrieb Alexey Muranov:
>> On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote:
>>
>>> On Thu, 19 Jul 2012 18:21:21 +0200 Alexey Muranov
>>> wrote:
>>>
>>> [...]
>>&
Jeff,
i have no idea about Git source and little idea of how it is working
internally, but reading through your message i wonder: wouldn't it be a good
idea to timestamp the dead reflogs ?
Alexey.
On 19 Jul 2012, at 23:33, Jeff King wrote:
> When a ref is deleted, we completely delete its ref
I just want to correct my mistake in what i've just sent:
On 19 Jul 2012, at 23:20, Alexey Muranov wrote:
> because the owner of the branch can reset or rebase it anytime. I do not
> develop on tracking branches. In fact, i am not even using "git pull".
> I do
On 19 Jul 2012, at 19:34, Konstantin Khomoutov wrote:
> On Thu, 19 Jul 2012 18:21:21 +0200
> Alexey Muranov wrote:
>
> [...]
>> I do not still understand very well some aspects of Git, like the
>> exact purpose of "remote tracking branches" (are they for pull o
On 19 Jul 2012, at 18:48, Dan Johnson wrote:
> From the git-gc man page:
> git gc tries very hard to be safe about the garbage it collects. In
> particular, it will keep not only objects referenced by your current
> set of branches and tags, but also objects referenced by the index,
> remote-track
On 19 Jul 2012, at 13:55, Jeff King wrote:
> I agree it would be much less confusing. However, one downside is that
> we do not keep reflogs on deleted branches (and nor did the commits in
> remote branches necessarily make it into the HEAD reflog). That makes
> "git fetch" a potentially destructi
On 19 Jul 2012, at 13:55, Jeff King wrote:
> On Thu, Jul 19, 2012 at 09:30:59AM +0200, Alexey Muranov wrote:
>
>> i would like
>>
>> `git fetch --prune `
>>
>> to be the default behavior of
>>
>> `git fetch `
>>
>> In fact, i thin
you.
Alexey Muranov.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
22 matches
Mail list logo
