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
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 issues,
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
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 to
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 well in
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 as used by
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
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 think I understand how
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]
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 clarification.
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 - -
12 matches
Mail list logo
