"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> One question, of course, is if one should simply keep additional
> metadata around to handle this sort of situations. One could, for
> example, keep a UUID for each file,...
If I am not mistaken, that is exactly what tla does. It seems
to work we
Junio C Hamano wrote:
But previous argument by Linus made in a distant (in git
timescale) past is now ingrained in my brain: "the additional
metadata" recorded at the commit time can only help us what we
envisioned in the past when the tool to record that metadata was
written. If we try to "tra
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Of course, if you don't push it back, but keep the two trees separate and
> keep on modifying files that have different names in the other repository,
> you'll keep on getting into the situation that the trivial merge doesn't
> work. So we _do_ want
Linus Torvalds wrote:
It's a totally broken model. Really.
You think it solves issues, but it just creates more bugs and problems
than it solves.
Trust me. The whole point of git is that "content is the only thing that
matters", and that there isn't any other meta-data. If you break that
f
On Mon, 5 Sep 2005, H. Peter Anvin wrote:
>
> It would also hade the somewhat interesting possibility that one could
> "remove and recreate" a file and have it exist as a different entity.
> That probably needs to be a user option.
It's a totally broken model. Really.
You think it solves iss
Junio C Hamano wrote:
1
/ \
0-2-3-5-7
\ /
4-6
It shouldn't matter to the merge at 7 if the 2-3 reorganization was done
locally, by applying a patch, or by merging.
There was another problem in my message that treated #3
specially. I did it that way primarily because I wanted to ha
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I think this is actually quite a regular merge, and I think we should be
> able to offer some assistance. The situation with K is normal: case #3ALT.
> If someone introduces a file and there's no file or directory with that
> name in other trees, we
On Sun, 4 Sep 2005, Junio C Hamano wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> writes:
>
> > If the problem is not fully understood it can be difficult to come up
> > with the proper solution. And with the example above the problem should
> > be really easy to understand.
> > Then we have the tree
Junio C Hamano <[EMAIL PROTECTED]> writes:
> All true. Let's redraw that simplified scenario, and see if
> what I said still holds. It may be interesting to store my
> previous message and this one in a file and run diff between
> them.
There are a couple of things worth mentioning about the tw
Sam Ravnborg <[EMAIL PROTECTED]> writes:
> If the problem is not fully understood it can be difficult to come up
> with the proper solution. And with the example above the problem should
> be really easy to understand.
> Then we have the tree as used by hpa with a few more mergers in it. But
> the
Martin Langhoff wrote:
Probably should be hacked into cg-merge. When the merge reports a file
is missing, what happens? Does it leave a .rej file or anything?
The error message is:
MERGE ERROR: nfsmount/mount.c: Not handling case
3225ecdf8d172cda2a6ea5276af0d3edc566a0e7 -> ->
c02da9e576a5
On Sat, Sep 03, 2005 at 12:32:03PM -0700, Junio C Hamano wrote:
> Sam Ravnborg <[EMAIL PROTECTED]> writes:
>
> > As explained in another mail what we want to do is actually to
> > transpose the changes made to F to the now renamed file G.
> > So we end up with G containing the modifications made t
Sam Ravnborg <[EMAIL PROTECTED]> writes:
> As explained in another mail what we want to do is actually to
> transpose the changes made to F to the now renamed file G.
> So we end up with G containing the modifications made to F.
>
> Also we want to include the new file K.
Thanks for the clarifica
On Sat, Sep 03, 2005 at 11:46:53AM -0700, Junio C Hamano wrote:
[lots of good stuff]
I obviously misunderstood the complexity of this merge case. Thank you
for the explanation.
- Fredrik
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED
On Sat, Sep 03, 2005 at 11:46:53AM -0700, Junio C Hamano wrote:
> This is a simplified scenario of klibc vs klibc-kbuild HPA had
> trouble with, to help us think of a way to solve this
> interesting merge problem.
>
>#1 - #3 - #5 - #7
>// /
> #0 - #2 - #4 - #6
>
>
On Sat, Sep 03, 2005 at 01:25:50AM -0700, Junio C Hamano wrote:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
> > "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> >
> >> I currently have two klibc trees,
> >
> > I cloned them to take a look. You_do_ seem to have a lot of
> > renames.
>
> Well, I
Fredrik Kuivinen <[EMAIL PROTECTED]> writes:
> Maybe I am missing something... but why should the merge operation
> ignore renames? Is there a merge case when ignoring renames is the
> Right Thing to do?
>
> Lets say the branches A and B has the common ancestor C which contains
> a file named "foo
This is a simplified scenario of klibc vs klibc-kbuild HPA had
trouble with, to help us think of a way to solve this
interesting merge problem.
#1 - #3 - #5 - #7
// /
#0 - #2 - #4 - #6
There are two lines of developments. #0->#2 renames F to G and
introduces K. #
On Sat, Sep 03, 2005 at 01:25:50AM -0700, Junio C Hamano wrote:
> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
> > "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> >
> >> I currently have two klibc trees,
> >
> > I cloned them to take a look. You_do_ seem to have a lot of
> > renames.
>
> Well, I
Junio C Hamano <[EMAIL PROTECTED]> writes:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
>> I currently have two klibc trees,
>
> I cloned them to take a look. You_do_ seem to have a lot of
> renames.
Well, I think I understand how your trees ancestry looks like,
but still haven't come up wit
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> I currently have two klibc trees,
>
> rsync://rsync.kernel.org/pub/scm/libs/klibc/klibc.git
>
> and
>
> rsync://rsync.kernel.org/pub/scm/libs/klibc/klibc-kbuild.git
I cloned them to take a look. You_do_ seem to have a lot of
renames.
$ git clon
On 9/3/05, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Is there any way I can record in the repository that these files are
> actually moved files, and that the merge should apply the patch elsewhere?
Well, if you run pickaxe at merge-time on the file-paths that weren't
found, you can probably wal
22 matches
Mail list logo
