Alexey Muranov [off-list ref] writes:
On 18 Aug 2012, at 22:39, Junio C Hamano wrote:
quoted
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.
I didn't get the impression that we know the "ultimate destination"
from the previous discussion, especially if we discount the tangent
around "having next and next/foo at the same time" which was on
nobody's wish, but I may be misremembering things.
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 determining the "ultimate
destination" is?
Decide if it makes sense to break backward compatibility of loose
ref representation merely to support having a branch "next" and
another branch "next/foo" in the same repository, and if it does,
what the new loose ref representation looks like.
I hope my opinion might be useful because i do not know anything
about the actual implementation of Git,...
That sounds like contradiction.
To just give a quick idea of my ideas, i thought that 'fetching'
in Git was an inevitable evil that stands apart from other
operations and is necessary only because the computer
communication on Earth is not sufficiently developed to keep all
Git repositories constantly in sync,...
It is a feature, not a symptom of an insufficiently developed
technology, that I do not have to know what random tweaks and
experiments are done in repositories of 47 thousands people who
clone from me, and I can sync with any one of them only when I know
there is something worth looking at when I say "git fetch".
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
Alexey Muranov [off-list ref] writes:
quoted
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 code), the model, and the interface are independent.
On the top level, for example, one does not need to know how commit storage is optimized, it is enough to understand that each commit is a snapshot of a subtree in a file directory.
quoted
To just give a quick idea of my ideas, i thought that 'fetching'
in Git was an inevitable evil that stands apart from other
operations and is necessary only because the computer
communication on Earth is not sufficiently developed to keep all
Git repositories constantly in sync,...
It is a feature, not a symptom of an insufficiently developed
technology, that I do not have to know what random tweaks and
experiments are done in repositories of 47 thousands people who
clone from me, and I can sync with any one of them only when I know
there is something worth looking at when I say "git fetch".
Currently, one of the main functions of 'fetch', apart from changing the remote tracking branches, is downloading the remote objects. This is necessary because of an insufficiently developed technology.
The other main function is changing the local copies of remote branches (changing the remote tracking branches), this is what i described as "taking a snapshot".
I did not understand what you meant by
"I do not have to know what random tweaks and experiments are done in repositories of 47 thousands people who clone from me, and I can sync with any one of them only when I know there is something worth looking at when I say "git fetch"."
How is it possible to know and not to know what is going on in the remote repository in the same time?
-Alexey.
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
Alexey Muranov [off-list ref] writes:
quoted
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 attached to the current behavior, and may provide a naïve view point, if you like.
-Alexey.
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
Alexey Muranov [off-list ref] writes:
quoted
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 determining the "ultimate
destination" is?
Decide if it makes sense to break backward compatibility of loose
ref representation merely to support having a branch "next" and
another branch "next/foo" in the same repository, and if it does,
what the new loose ref representation looks like.
I looked again through this thread and tried to understand better the issues.
1. I vote for moving dead reflogs to "logs/graveyard" (or to "logs/deadlogs").
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 moved away to "graveyard" anyway.
3. There remains the question what to do with dead reflogs for different branches having the same name. Maybe, keep the death date and time under the graveyard directory and not allow the user to delete 2 times in less than 1 second?
/logs/graveyard/yyyy-mm-dd-hhmmss/refs/heads/next/foo
In a sense this is similar to the git storage model: an "atomic" destructive operation creates a timestamped "commit" in logs/graveyard directory.