From: Junio C Hamano <hidden> Date: 2016-08-11 20:38:03
Johannes Schindelin [off-list ref] writes:
Unify the handling for cases C (add/add) and D (modify/modify).
Signed-off-by: Johannes Schindelin <redacted>
---
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin [off-list ref] writes:
>
> > How about this: if there is an add/add conflict, we treat it
> > as if there _was_ an empty file, and we let the shiny new
> > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > the file from the index, adding both files with different
> > "~blabla" markers appended to their file names to the working
> > directory.
>
> I was not thinking about this t6024 test failure problem but was
> wondering about doing exactly that in merge-recursive to match
> the "two file merge" magic we have in git-merge-one-file.sh
As can be seen with the test case, the result is more pleasing.
This fixes the behaviour in "both branches add the path
differently" case. Previously merge-recursive did not create
the working tree file, but now it does just like merge-resolve.
Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.
From: Johannes Schindelin <hidden> Date: 2016-08-11 19:25:09
Hi,
On Tue, 12 Dec 2006, Junio C Hamano wrote:
Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.
Indeed. Catalin, do you have any suggestion how to proceed? Do you want to
introduce a check if the file exists prior to re-generating it? Or do you
need some version check?
BTW why is StGit not on kernel.org?
Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
that machine? I am a happy user of the gitweb interface on that box...
Yet another question: On repo.or.cz, I searched for the "commit" "8d41555"
(upper right side, very nice, although the search button is lacking, which
is needed for some browsers like w3m). But I got _two_ results, the one I
expected, and its child (probably because it contains the sha1 as part of
the parent tag). Is this intended behaviour? After all, I search for the
commit...
Ciao,
Dscho
From: Petr Baudis <hidden> Date: 2016-08-11 19:35:44
On Wed, Dec 13, 2006 at 12:46:56PM CET, Johannes Schindelin wrote:
Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
that machine? I am a happy user of the gitweb interface on that box...
See http://repo.or.cz/about.html - two-processor P3 800MHz with 2G RAM,
and it does quite some work besides doing repo.or.cz as well - there are
no load problems so far, though. The gitweb load in particular is pretty
low, though - I think it's about 350 requests per day; the periodical
mirroring is far more intensive, but the intervals for this could be
reduced greatly if that would become a problem.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
From: Jakub Narebski <hidden> Date: 2016-08-11 19:43:36
Petr Baudis wrote:
On Wed, Dec 13, 2006 at 12:46:56PM CET, Johannes Schindelin wrote:
quoted
Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
that machine? I am a happy user of the gitweb interface on that box...
See http://repo.or.cz/about.html - two-processor P3 800MHz with 2G RAM,
and it does quite some work besides doing repo.or.cz as well - there are
no load problems so far, though. The gitweb load in particular is pretty
low, though - I think it's about 350 requests per day; the periodical
mirroring is far more intensive, but the intervals for this could be
reduced greatly if that would become a problem.
Do you do "git repack -a -d" (and "git prune-packed"), or do you use
some kept packs?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Unify the handling for cases C (add/add) and D (modify/modify).
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin [off-list ref] writes:
>
> > How about this: if there is an add/add conflict, we treat it
> > as if there _was_ an empty file, and we let the shiny new
> > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > the file from the index, adding both files with different
> > "~blabla" markers appended to their file names to the working
> > directory.
What is this new xdl_merge()? Is it a better replacement for diff3? In
this situation diff3 would actually show two confict parts, each of
them being the full file, with an empty ancestor.
This fixes the behaviour in "both branches add the path
differently" case. Previously merge-recursive did not create
the working tree file, but now it does just like merge-resolve.
Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.
I don't think it affects StGIT. Previously, "git-read-tree -m" left a
file in the tree in this conflict situation. When I switched to
git-merge-recursive (to handle renames better), I noticed that the
file was no longer there and my merge algorithm failed. It now checks
whether the file is missing and it generates one.
The way StGIT handle any conflicts is not to leave the index in a
state with multiple stages per file. When I push a patch that is
causing an add/add situation, I want a version of the file to be added
to the index (usually the one already in the tree, not in the patch
being pushed) so that a "stg status" won't show like the patch is
removing that file.
--
On 13/12/06, Johannes Schindelin [off-list ref] wrote:
xdl_merge(), as Git uses it, tries harder to find the true conflicts. So,
if the files actually differ in only one line, just this line will be
shown as conflict.
I gave the latest GIT a try and it works OK with StGIT.
This new merge looks much better than diff3 (or rcs merge) because it
only shows the true conflicts.
What it the relation between git-merge-recursive and "git-read-tree
-m" (if any)? I currently still use "git-read-tree -m" for some merges
because of the speed gain due to the --agressive option (really
noticeable when picking a patch from an older branch). Probably
git-merge-recursive cannot implement this since it needs to track
deletion/additions for rename detection.
Are there any other things to be aware if I completely replace the
"git-read-tree + diff3" with git-merge-recursive?
One nice addition to git-merge-recursive (probably only useful to
StGIT) would be more meaningful labeling of the conflict regions,
passed via a command line similar to the "diff3 -L" option. StGIT
generates "patched", "current" and "ancestor" labels with diff3.
Yet another nice feature would be the ancestor region (which diff3
doesn't add either but it gets added by emacs'
ediff-merge-files-with-ancestor function if you use the interactive
merge with StGIT).
--
What it the relation between git-merge-recursive and "git-read-tree
-m" (if any)? I currently still use "git-read-tree -m" for some merges
because of the speed gain due to the --agressive option (really
noticeable when picking a patch from an older branch). Probably
git-merge-recursive cannot implement this since it needs to track
deletion/additions for rename detection.
There is a difference; always has been, probably will be for a
long time.
read-tree -m performs some trivial merges in the index. Its manual
page explains it in gory detail, but its the really trivial, basic
three way merge rules: Given two trees X and Y and some so-called
base B:
* If X == Y == B for that file, take any of the three.
* If X == Y, but not B, take X or Y.
* If X changes a file, but Y == B for that file, take X.
* If Y changes a file, but X == B for that file, take Y.
I believe that the --agressive option has added some additional
rules about trivial file deletes. However notice the all important
rule is not handled by read-tree -m:
* If X changes a file, Y also changes file, merge them to create Z.
This is where read-tree -m punts and hands things off to
merge-recursive, which needs to invoke diff3 (or now the internal
xdl_merge). read-tree -m also currently does not handle file
additions, mode changes, or renames/copies. All of which are a
lot more expensive to compute and are slightly less common.
So Git gets decent performance by going through the rather cheap
read-tree -m, then falling back into the slower merge-recursive
when read-tree -m punted. Given that I see about 50% of my merges
succeed with just read-tree -m and the other half punt over to
merge-recursive it just about balances out over several merges.
Are there any other things to be aware if I completely replace the
"git-read-tree + diff3" with git-merge-recursive?
From what I understand git-merge-recursive will do everything that
git-read-tree -m will do, except its going to be slower doing the
really common, stupid cases that git-read-tree -m can handle on
its own.
--
From: Jakub Narebski <hidden> Date: 2016-08-11 19:59:20
Johannes Schindelin wrote:
Yet another question: On repo.or.cz, I searched for the "commit" "8d41555"
(upper right side, very nice, although the search button is lacking, which
is needed for some browsers like w3m).
The problem is where to put it. The previous version didn't even had the
"select type" but used [undocumented] search operators 'author:',
'committer:' and 'pickaxe:'.
But I got _two_ results, the one I
expected, and its child (probably because it contains the sha1 as part of
the parent tag). Is this intended behaviour? After all, I search for the
commit...
Actually, "commit" is a bit of misnomer, as it searches commits contents
(commit body). You can go to given commit easier by hand editing URL,
editing "a=commit;h=8d41555".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
On 14/12/06, Johannes Schindelin [off-list ref] wrote:
On Thu, 14 Dec 2006, Catalin Marinas wrote:
quoted
What it the relation between git-merge-recursive and "git-read-tree
-m" (if any)?
git-merge-recursive internally calls the equivalent of 'git-read-tree -m'
(it does not fork() and exec(), but rather calls the C functions
directly) and does nothing more if the 'git-write-tree' succeeds. At least
that's the theory...
OK, thanks (I imagined it might work like this).
quoted
One nice addition to git-merge-recursive (probably only useful to
StGIT) would be more meaningful labeling of the conflict regions,
passed via a command line similar to the "diff3 -L" option. StGIT
generates "patched", "current" and "ancestor" labels with diff3.
This is possible. However, it is not _that_ horrible to see "HEAD" and
some SHA1 which is obviously non-HEAD. Added to that, a quite common case
are the intermediate merges which make merge-recursive so powerful, and
they are rightly called "Temporary branch 1" and "... 2".
From the StGIT perspective, it only does a three-way merge and passes
commit id to git-merge-recursive, hence the complicated naming.
However, it wouldn't be hard to modify StGIT to actually replace the
hashes in the file with meaningful names.
quoted
Yet another nice feature would be the ancestor region (which diff3
doesn't add either but it gets added by emacs'
ediff-merge-files-with-ancestor function if you use the interactive
merge with StGIT).
Is this really that nice? I never needed it... Besides, it can get really
crappy when the conflicting regions are too large.
I think I only used the ancestor region for a mental representation of
what xdl_merge already produces :-) since emacs (nor diff3) wasn't
able to show the real differences. Probably no longer needed now.
Thanks for the explanations.
--
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:03:09
Hi,
On Thu, 14 Dec 2006, Catalin Marinas wrote:
On 13/12/06, Johannes Schindelin [off-list ref] wrote:
quoted
xdl_merge(), as Git uses it, tries harder to find the true conflicts. So,
if the files actually differ in only one line, just this line will be
shown as conflict.
I gave the latest GIT a try and it works OK with StGIT.
Great!
What it the relation between git-merge-recursive and "git-read-tree
-m" (if any)?
git-merge-recursive internally calls the equivalent of 'git-read-tree -m'
(it does not fork() and exec(), but rather calls the C functions
directly) and does nothing more if the 'git-write-tree' succeeds. At least
that's the theory...
If the git-write-tree does not succeed, it is because there are unmerged
entries, and only then, merge-recursive does the rename detection and the
file level merges.
One nice addition to git-merge-recursive (probably only useful to
StGIT) would be more meaningful labeling of the conflict regions,
passed via a command line similar to the "diff3 -L" option. StGIT
generates "patched", "current" and "ancestor" labels with diff3.
This is possible. However, it is not _that_ horrible to see "HEAD" and
some SHA1 which is obviously non-HEAD. Added to that, a quite common case
are the intermediate merges which make merge-recursive so powerful, and
they are rightly called "Temporary branch 1" and "... 2".
Yet another nice feature would be the ancestor region (which diff3
doesn't add either but it gets added by emacs'
ediff-merge-files-with-ancestor function if you use the interactive
merge with StGIT).
Feasible, yes. But the code was written without that idea, so it would
involve changes in the xdmerge_t structure (add i0, chg0), recording that
in xdl_append_merge(), and passing also the base to
xdl_fill_merge_buffer().
Is this really that nice? I never needed it... Besides, it can get really
crappy when the conflicting regions are too large.
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:12:47
Hi,
On Wed, 13 Dec 2006, Catalin Marinas wrote:
On 13/12/06, Johannes Schindelin [off-list ref] wrote:
quoted
On Tue, 12 Dec 2006, Junio C Hamano wrote:
quoted
Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.
Indeed. Catalin, do you have any suggestion how to proceed? Do you want to
introduce a check if the file exists prior to re-generating it? Or do you
need some version check?
It currently checks whether the file exists and, if it doesn't, it is
re-generated. I think the patch is good idea.
Thanks.
quoted
BTW why is StGit not on kernel.org?
Why would it be? Unless you know who to talk to for this :-), it's not
really a derivative of the Linux kernel.
There is plenty of stuff on kernel.org which is only related to the Linux
kernel. And StGit (even if I did not try it yet), seems to be very
valuable for working on the kernel.
quoted
Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
that machine? I am a happy user of the gitweb interface on that box...
Hopefully, when I get a bit of time, I'll try to give up the
http-hosted repository and use Pasky's one exclusively.
BTW, how can I notify people that only pull from the http repository
that it will no longer be updated (rather than them thinking the
development stopped)? One solution would be to create a file with a
meaningful name in the top dir and hope people will notice it.
IMHO removing it altogether would be a good idea. The website should carry
the news of the new repository site.
Ciao,
Dscho
One nice addition to git-merge-recursive (probably only useful to
StGIT) would be more meaningful labeling of the conflict regions,
passed via a command line similar to the "diff3 -L" option. StGIT
generates "patched", "current" and "ancestor" labels with diff3.
Indeed. Getting a SHA1 hash of the branch that I merged in by
name with "git merge foof" is horrible UI. I want to see "foof"
in the conflict. Its in my list of things I'd really like to fix,
but is currently low priority compared to the issues I've run into
this past week with git-merge-recursive's basic functions.
On the other hand Git's open source strategy is really paying off on
resolving those problems, typically the issue is fixed and accepted
by Junio into 'next' in under a day of identification. :-)
--
From: Jakub Narebski <hidden> Date: 2016-08-11 20:34:34
Johannes Schindelin wrote:
quoted
BTW, how can I notify people that only pull from the http repository
that it will no longer be updated (rather than them thinking the
development stopped)? One solution would be to create a file with a
meaningful name in the top dir and hope people will notice it.
IMHO removing it altogether would be a good idea. The website should carry
the news of the new repository site.
By the way, would setting http-alternates help? I guess not, not without
having refs copied from the other place...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Robin Rosenberg <hidden> Date: 2016-08-11 20:40:41
onsdag 13 december 2006 23:09 skrev Catalin Marinas:
BTW, how can I notify people that only pull from the http repository
that it will no longer be updated (rather than them thinking the
development stopped)? One solution would be to create a file with a
meaningful name in the top dir and hope people will notice it.
If you also remove all other files, people will notice.
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:43:33
Hi,
On Wed, 13 Dec 2006, Catalin Marinas wrote:
On 13/12/06, Junio C Hamano [off-list ref] wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
Unify the handling for cases C (add/add) and D (modify/modify).
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin [off-list ref] writes:
>
> > How about this: if there is an add/add conflict, we treat it
> > as if there _was_ an empty file, and we let the shiny new
> > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > the file from the index, adding both files with different
> > "~blabla" markers appended to their file names to the working
> > directory.
What is this new xdl_merge()? Is it a better replacement for diff3? In
this situation diff3 would actually show two confict parts, each of them
being the full file, with an empty ancestor.
xdl_merge(), as Git uses it, tries harder to find the true conflicts. So,
if the files actually differ in only one line, just this line will be
shown as conflict.
There is a flag passed to xdl_merge(), which tells it how hard it should
try to make sense of the conflict. We use the "zealous" option, which is
most accurate, but also slowest (although I have no numbers).
quoted
This fixes the behaviour in "both branches add the path
differently" case. Previously merge-recursive did not create
the working tree file, but now it does just like merge-resolve.
Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.
I don't think it affects StGIT. Previously, "git-read-tree -m" left a
file in the tree in this conflict situation. When I switched to
git-merge-recursive (to handle renames better), I noticed that the
file was no longer there and my merge algorithm failed. It now checks
whether the file is missing and it generates one.
On 13/12/06, Johannes Schindelin [off-list ref] wrote:
On Tue, 12 Dec 2006, Junio C Hamano wrote:
quoted
Although I would feel very happy about this change, Catalin
might want to be informed about potential interaction this
change might have with his commit 8d41555 in StGIT.
Indeed. Catalin, do you have any suggestion how to proceed? Do you want to
introduce a check if the file exists prior to re-generating it? Or do you
need some version check?
It currently checks whether the file exists and, if it doesn't, it is
re-generated. I think the patch is good idea.
BTW why is StGit not on kernel.org?
Why would it be? Unless you know who to talk to for this :-), it's not
really a derivative of the Linux kernel.
Not that it matters: repo.or.cz has a nice mirror. Pasky, how powerful is
that machine? I am a happy user of the gitweb interface on that box...
Hopefully, when I get a bit of time, I'll try to give up the
http-hosted repository and use Pasky's one exclusively.
BTW, how can I notify people that only pull from the http repository
that it will no longer be updated (rather than them thinking the
development stopped)? One solution would be to create a file with a
meaningful name in the top dir and hope people will notice it.
--