* [PATCH] Move couple of ifdefs after "include config.mk"
From: Timo Hirvonen @ 2005-12-01 1:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0512010144050.11941@wbgn013.biozentrum.uni-wuerzburg.de>
This makes it possible to define WITH_SEND_EMAIL etc. in config.mak.
Also remove GIT_LIST_TWEAK because it isn't used anymore.
---
Makefile | 28 ++++++++++++----------------
1 files changed, 12 insertions(+), 16 deletions(-)
f877acdc3f8c888dd82a1e81ce20c8715e3108e4
diff --git a/Makefile b/Makefile
index 984d167..00521fe 100644
--- a/Makefile
+++ b/Makefile
@@ -138,8 +138,6 @@ ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROG
# Backward compatibility -- to be removed after 1.0
PROGRAMS += git-ssh-pull$X git-ssh-push$X
-GIT_LIST_TWEAK =
-
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
SHELL_PATH = /bin/sh
@@ -154,20 +152,6 @@ endif
PYMODULES = \
gitMergeCommon.py
-ifdef WITH_OWN_SUBPROCESS_PY
- PYMODULES += compat/subprocess.py
-else
- ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
- PYMODULES += compat/subprocess.py
- endif
-endif
-
-ifdef WITH_SEND_EMAIL
- SCRIPT_PERL += git-send-email.perl
-else
- GIT_LIST_TWEAK += -e '/^send-email$$/d'
-endif
-
LIB_FILE=libgit.a
LIB_H = \
@@ -256,6 +240,18 @@ endif
-include config.mak
+ifdef WITH_OWN_SUBPROCESS_PY
+ PYMODULES += compat/subprocess.py
+else
+ ifneq ($(shell $(PYTHON_PATH) -c 'import subprocess;print"OK"' 2>/dev/null),OK)
+ PYMODULES += compat/subprocess.py
+ endif
+endif
+
+ifdef WITH_SEND_EMAIL
+ SCRIPT_PERL += git-send-email.perl
+endif
+
ifndef NO_CURL
ifdef CURLDIR
# This is still problematic -- gcc does not always want -R.
--
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Move "-include config.mak" to end of configuration section
From: Johannes Schindelin @ 2005-12-01 0:46 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, Junio C Hamano
In-Reply-To: <20051201012333.44bd81f2.tihirvon@gmail.com>
Hi,
On Thu, 1 Dec 2005, Timo Hirvonen wrote:
> This makes it possible to define WITH_SEND_EMAIL etc. in config.mak.
... but it breaks setups where config.mak overrides platform
dependent settings...
Hth,
Dscho
^ permalink raw reply
* [Possibly OT] Synchronizing data
From: walt @ 2005-12-01 0:26 UTC (permalink / raw)
To: git
If this is truly irrelevant to git, then I apologize. I'm
posting this link not because I understand all the issues,
rather because of a gut feeling that it may (possibly) be
relevant to people who are trying to share data across a
network:
http://open.itworld.com/4934/051123msrss/page_1.html
This is a typical e-newsletter which may disappear very
quickly. The article concerns extensions to RSS being
proposed by our friends at M$.
I'm sure I would learn a lot if you code-wizards would
explain why this concept would be good (or bad) for git.
Thanks!
^ permalink raw reply
* Re: git bisect enhancements?
From: Linus Torvalds @ 2005-11-30 23:32 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List
In-Reply-To: <1133386585.30767.34.camel@cashmere.sps.mot.com>
On Wed, 30 Nov 2005, Jon Loeliger wrote:
>
> So, I'm proposing something like:
>
> $ git bisect bump +<n>
> $ git bisect bump -<n>
>
> To move the bisection point "up" or "down" a commit chain.
>
> Am I off in the weeds?
No, but we already have it.
If you decide to select a new bisection point by hand, just do it. It's
called
git reset --hard <new-bisect-point>
and it will simply move the bisect branch to the new point.
Then, compile and test that, and use "git bisect good/bad" as necessary.
Now, I agree that maybe I could have made that a bit more obvious, but it
should all work.
Same goes for the case where "git bisect" selects a point that happens to
have a different problem than the one you were looking for. Instead of
saying "git bisect good" (or bad) and praying you got it right, just do
that "git bisect visualize" and select another point entirely, and do that
same "git reset --hard" thing, and leave the one you don't know about
alone.
Of course, if you make a bad selection, you might have that problem again,
or more commonly, you'll just have to test more kernels because your
selection wasn't as close to "midway" as the one "git bisect" had selected
for you. But you'll get there eventually.
[ Now, the _real_ problem with bisection is that some bugs simply cannot
be bisected. If it's timing-related etc, it might be a bug that comes
and goes, and then I'm afraid that git bisect won't really help you. ]
Linus
^ permalink raw reply
* [PATCH] Move "-include config.mak" to end of configuration section
From: Timo Hirvonen @ 2005-11-30 23:23 UTC (permalink / raw)
To: git, Junio C Hamano
This makes it possible to define WITH_SEND_EMAIL etc. in config.mak.
---
Makefile | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
fe5fece83b2ab0d67a4277d851faf50ad944cff4
diff --git a/Makefile b/Makefile
index 984d167..c44f5da 100644
--- a/Makefile
+++ b/Makefile
@@ -75,7 +75,7 @@ RPMBUILD = rpmbuild
# explicitly what architecture to check for. Fix this up for yours..
SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
-
+-include config.mak
### --- END CONFIGURATION SECTION ---
@@ -254,8 +254,6 @@ ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
endif
--include config.mak
-
ifndef NO_CURL
ifdef CURLDIR
# This is still problematic -- gcc does not always want -R.
--
0.99.9.GIT
^ permalink raw reply related
* Re: git-name-rev off-by-one bug
From: Daniel Barkalow @ 2005-11-30 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy835okxs.fsf@assigned-by-dhcp.cox.net>
On Wed, 30 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I actually had that problem with the original tables; there isn't a
> > canonical order in which to list a table of all of the possible matches
> > and non-matches between items so as to be complete.
> >
> > Perhaps it ought to list, on each line, which previous cases would match,
> > so that you could see that case 2 is really the conditions of 2 minus the
> > conditions for 2ALT, which is "all of the ancestors are empty, the head
> > has a directory/file conflict, and remote exists."
>
> Sorry, I was not clear about it when I did that table the first
> time. 2ALT was "alternatives suggested to replace 2" and listed
> in the same table for comparison purpose.
I understood that; actually, when I found it, a number of the ALT cases
had been implemented, and some of them supplimented rather than replaced
the originals.
> The original table was designed in a way that if you have a
> match on case N, there would not be any other case M that matches
> the case, either N<M or M<N. IOW, the order to read the table
> did not matter. At least that was the intention.
>
> If you read "missing" = 0, "exists" = 1, and take OAB as bit2,
> bit1, and bit0, you can easily see the pattern in the table. It
> counts in binary, although bit1 has various subcases so the
> table has more than 8 rows, and it is easy to see it covers all.
The hard thing is to verify that all the subcases are listed. I switched
the orders of matching and non-matching, so that I could make it matching
and need-not-match. Your table is actually missing a few cases: what
happens if O is missing, 2 has a directory, and 3 has a file? You note
that we have to be careful, but don't list the result (which is "no
merge").
Perhaps the table would be clearer if the lines were grouped in
exists/missing? (With 5ALT repeated in the 011 and 111 groups, since it
applies to both) Then you would only need to look at 5 lines with
cascading (in the most complex case), rather than having to read the whole
top of the table.
(It is actually written like that, with the exception of 5ALT, 2ALT, and
3ALT, but it's not visually obvious.)
So case 11 is really: All three exist. Head and remote don't match
(-5ALT), no ancestor matches remote (-13), and no ancestor matches head
(-14). Case 13 is really: All three exist. Head and remote don't match
(-5ALT), there aren't different ancestors which match head and remote
(-16), and an ancestor matches remote.
The tricky bit is really cases 2ALT and 3ALT, which can be used in cases
where some but not all of the ancestors are empty, and can't be used if
there's a directory/file conflict; neither of these conditions matters for
anything else in the table, so it's hard to fit this in. My strategy is to
have those as special cases, and have the rest of the table cover
everything (rather than having case 2 require a directory/file conflict
and case 7 require that no ancestor be empty, which would be accurate, but
would make it harder to check for missing cases).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* What's new in git.git master branch
From: Junio C Hamano @ 2005-11-30 22:57 UTC (permalink / raw)
To: git
As promised (or warned), most of the things are now graduating
from proposed updates to the master branch. The plan is to
merge this into "maint" by the weekend after field testing
(sorry, you guys are guinea pigs, but I did human experiments on
myself first ;-)), and label that 1.0rc4. After that, hopefully
no disrupting feature changes until 1.0 final.
Among the miscellaneous fixes, notable recent changes are:
- bisect can cut down trials if given pathspec (Linus).
- merge-one-file leaves unmerged entries in index (Linus,
linux@horizon.com, me). The recursive merge strategy has
been also updated to match this but only in no-renaming
case.
- diff-files updated to show diff between a higher stage and
working tree (Linus). I reverted most of the butchering I
suggested last night on the list except one obvious bugfix
Linus agreed.
- ls-tree rewrite (Linus).
- making more things work from subdirectories (me).
- repository format version futureproofing (Martin Atukunda and
me). A fix by Tommi Virtanen for the bug reported by David
Woodhouse is included here.
- improved gitk (Paulus, Yann Dirson, Pavel Roskin)
I am still holding back "Disable USE_SYMLINK_HEAD" by Pavel
Roskin in the proposed updates branch. This makes symref
everywhere, not only on symbolic-challenged platforms, to
represent HEAD link. As far as I know, Cogito and StGIT are
ready for this change, but this will break gitweb, which
directly reads from $project/HEAD to find out the object name of
the HEAD commit (it needs to do `GIT_DIR=$project git-rev-parse
HEAD` now). I think we earlier agreed that this patch will go
in sometime after 1.0; correct me if I am wrong.
One interesting change is ls-tree rewrite by Linus. The command
does _not_ show tree nodes when running with -r flag anymore.
Running "git diff v0.99.9i t/t3100-ls-tree-restrict.sh"
after updating to the master tells you the summary of changes in
the behaviour.
I've looked at gitweb, Cogito and StGIT to see if this breaks
things, and while I think it is safe for these three, authors of
Porcelains including these three are asked to double check.
Particularly interesting one is cg-log, which only uses
"git-ls-tree -r" to show the list of things being committed for
the initial commit, and this change actually fixes a small bug
there (I think with the ls-tree before this change it would end
up listing tree entries). cg-restore guards itself with a sed
script from ls-tree spitting out entries other than blob, so it
is not affected, but it could lose that guard now.
Another improvement is around git-merge-one-file and
git-diff-files to change how the conflicting path information is
left in the index after a failed automerge. This change was
prompted by a question from linux@horizon.com (do you have a
real name?). We leave the failed merge result in the working
tree with conflict markers as before, but unlike the previous
round which registered the HEAD commit version at stage0 in the
index file, we now leave the index entries unmerged. "git diff"
command can be used to see what the changes from our HEAD commit
is as before, but you can also say "git diff --base" to see the
differences from the merge base, and "git diff --theirs" to see
the differences from the other branch that was merged.
^ permalink raw reply
* Re: git bisect enhancements?
From: Junio C Hamano @ 2005-11-30 22:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1133386585.30767.34.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
>...
> Two or three "good builds" into things, it proposes a
> new build at a272e24cc8751d125f9582befed0213a2a2b270f.
> Which I build and don't quite boot. It hangs after
> the IDE probe, and before the i2c probe. Bummer.
>
> These are not bugs I was looking for. Move along.
This is not about your "bump", but one thing that may worthwhile
to try is bisect enhancements Linus did a couple of days ago, to
let you limit the number of commits tried by specifying the area
you are interested in.
If may not help if only thing you know is that i2c probe is not
what you are looking for, but if you know what area is suspect,
say arch/powerpc and include/asm-powerpc (just taken randomly, I
do not even know if you work in that area), it lets you say:
$ git bisect reset
$ git bisect start arch/powerpc include/asm-powerpc
$ git bisect good v2.6.13-rc3
$ git bisect bad master
What is interesting is that this cuts down the commits to be
inspected to only the ones that touch the specified paths. So
without the path specifier, you may need to bisect 5000 commits in
total, but with the commits limited to the ones that touch these
two example directories, you would need to bisect 247 commits,
which is only a fraction of the original.
^ permalink raw reply
* Re: [PATCH 7/7] Use a separate directory for patches under each branch subdir
From: Catalin Marinas @ 2005-11-30 22:32 UTC (permalink / raw)
To: cel; +Cc: git
In-Reply-To: <438E2797.2020205@citi.umich.edu>
On 30/11/05, Chuck Lever <cel@citi.umich.edu> wrote:
> Catalin Marinas wrote:
> > This patch doesn't fix the already created branches. It would be
> > useful to upgrade the branch structure automatically if the patches
> > directory is not found.
>
> the reason i didn't do that is because i wanted to allow older versions
> of StGIT to continue to work on existing repositories.
You are right.
> what if i added a migration tool to allow a user to switch back and forth?
A separate stg command for this would be useful. Anyway since the
repository structure might change again in the future, I think it
would be better to have a version string saved somewhere in
.git/patches/version for reference.
--
Catalin
^ permalink raw reply
* Re: [PATCH 7/7] Use a separate directory for patches under each branch subdir
From: Chuck Lever @ 2005-11-30 22:28 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511301423h2885d442r@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
Catalin Marinas wrote:
> On 29/11/05, Chuck Lever <cel@netapp.com> wrote:
>
>>Currently you can't specify a patch name that matches the name of one of
>>the stgit special files under .git/patches/<branch-name>. Let's use a
>>new subdirectory under .git/patches/<branch-name> to contain just the
>>patch directories to remove this limitation.
>
>
> This patch doesn't fix the already created branches. It would be
> useful to upgrade the branch structure automatically if the patches
> directory is not found.
the reason i didn't do that is because i wanted to allow older versions
of StGIT to continue to work on existing repositories.
what if i added a migration tool to allow a user to switch back and forth?
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH 0/7]
From: Catalin Marinas @ 2005-11-30 22:27 UTC (permalink / raw)
To: Chuck Lever; +Cc: git
In-Reply-To: <20051129220552.9885.41086.stgit@dexter.citi.umich.edu>
On 29/11/05, Chuck Lever <cel@citi.umich.edu> wrote:
> + stg-in-subdirectories | Use git-rev-parse to find the local GIT repository
> + fix-branch-description | Align branch descriptions in output of "stg branch -l"
> + stg-series-description | "stg series" option to show patch summary descriptions
> + stg-series-short | Add facility to print short list of patches around 'top'
I applied the above patches.
> + stg-branch-clone | Add a "--clone" option to "stg branch"
I'll comment on this tomorrow since I need to look at it in more
detail. One thing I would prefer is to be able to specify a name for
the newly cloned branch rather than generating one by default (which
can stay as well, as long as a 2nd argument with the name is not
given).
> Before 0.8, you might also consider addressing the patch authorship issues
> that come up when mailing out patches, as discussed on git@vger last week.
Yes, I will.
Thanks for the patches.
--
Catalin
^ permalink raw reply
* Re: git bisect enhancements?
From: Junio C Hamano @ 2005-11-30 22:23 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1133388429.30767.37.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> Sure. But I'm proposing to alter the new bisection
> middle point. I don't know its status yet. I am
> just angling on hedging my bets of a "good midpoint"
> choice by finding something that is likely to be
> more stable than the proposed midpoint.
You could "git reset --hard <that-commit-N-up-or-down>",
compile, test and say "git bisect good" or "git bisect bad".
Even "N commits before" is not so easy. "git reset --hard
bisect~2" would be 2 commits before what git-bisect suggested as
long as that chain in question is a single strand of pearls. "N
commits after" is a bit harder, especially when a merge is
involved. But you are right. Bisect should be able to do what
you can visually do with gitk.
^ permalink raw reply
* Re: [PATCH 7/7] Use a separate directory for patches under each branch subdir
From: Catalin Marinas @ 2005-11-30 22:23 UTC (permalink / raw)
To: Chuck Lever; +Cc: git
In-Reply-To: <20051129220951.9885.59702.stgit@dexter.citi.umich.edu>
On 29/11/05, Chuck Lever <cel@netapp.com> wrote:
> Currently you can't specify a patch name that matches the name of one of
> the stgit special files under .git/patches/<branch-name>. Let's use a
> new subdirectory under .git/patches/<branch-name> to contain just the
> patch directories to remove this limitation.
This patch doesn't fix the already created branches. It would be
useful to upgrade the branch structure automatically if the patches
directory is not found.
--
Catalin
^ permalink raw reply
* Re: git bisect enhancements?
From: Jon Loeliger @ 2005-11-30 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vu0dtokqp.fsf@assigned-by-dhcp.cox.net>
On Wed, 2005-11-30 at 16:04, Junio C Hamano wrote:
> Jon Loeliger <jdl@freescale.com> writes:
>
> > ... I want to "bump" the bisect point
> > up two commits and _then_ build.
> >
> > So, I'm proposing something like:
> >
> > $ git bisect bump +<n>
> > $ git bisect bump -<n>
> >
> > To move the bisection point "up" or "down" a commit chain.
>
> Hmph. Doesn't "bisect good" or "bisect bad" let you explicitly
> say which one is good or bad, instead of just taking what it
> suggests as the next midpoint?
Sure. But I'm proposing to alter the new bisection
middle point. I don't know its status yet. I am
just angling on hedging my bets of a "good midpoint"
choice by finding something that is likely to be
more stable than the proposed midpoint.
jdl
^ permalink raw reply
* Re: git bisect enhancements?
From: Junio C Hamano @ 2005-11-30 22:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <1133386585.30767.34.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
> ... I want to "bump" the bisect point
> up two commits and _then_ build.
>
> So, I'm proposing something like:
>
> $ git bisect bump +<n>
> $ git bisect bump -<n>
>
> To move the bisection point "up" or "down" a commit chain.
Hmph. Doesn't "bisect good" or "bisect bad" let you explicitly
say which one is good or bad, instead of just taking what it
suggests as the next midpoint?
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 22:00 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511301514500.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I actually had that problem with the original tables; there isn't a
> canonical order in which to list a table of all of the possible matches
> and non-matches between items so as to be complete.
>
> Perhaps it ought to list, on each line, which previous cases would match,
> so that you could see that case 2 is really the conditions of 2 minus the
> conditions for 2ALT, which is "all of the ancestors are empty, the head
> has a directory/file conflict, and remote exists."
Sorry, I was not clear about it when I did that table the first
time. 2ALT was "alternatives suggested to replace 2" and listed
in the same table for comparison purpose.
The original table was designed in a way that if you have a
match on case N, there would not be any other case M that matches
the case, either N<M or M<N. IOW, the order to read the table
did not matter. At least that was the intention.
If you read "missing" = 0, "exists" = 1, and take OAB as bit2,
bit1, and bit0, you can easily see the pattern in the table. It
counts in binary, although bit1 has various subcases so the
table has more than 8 rows, and it is easy to see it covers all.
> "If the index exists, it is an error for it not to match either the
> head or (if the merge is trivial) the result."
>
> "A result of "no merge" is an error if the index is not empty and not
> up-to-date."
That is good.
> Certainly, your complaints about the table should be addressed first. I
> think I'd addressed all your complaints from last time, but at that point,
> we got sidetracked into a discussion of the details of case #16.
... which was a good thing to think about in itself. I feel I
understand the new table a bit better.
^ permalink raw reply
* Re: [PATCH 1/7] Make "stg export" save the base commit in the output directory
From: Catalin Marinas @ 2005-11-30 21:53 UTC (permalink / raw)
To: Chuck Lever; +Cc: git
In-Reply-To: <20051129220938.9885.37456.stgit@dexter.citi.umich.edu>
On 29/11/05, Chuck Lever <cel@netapp.com> wrote:
> When trying to apply a series of diffs that was exported from an StGIT
> series, it can be convenient to know exactly which base commit the
> patches apply to. Save that commit in a file patchdir/base.
I would rather save it as a comment ('#' prefixed) in the series file.
--
Catalin
^ permalink raw reply
* git bisect enhancements?
From: Jon Loeliger @ 2005-11-30 21:36 UTC (permalink / raw)
To: Git List
Guys,
So, I'm in the middle of a Git Bisect War.
It all worked around 2.6.13-rc3 time, and doesn't now.
So I launched into some bisecting, and it is all going
pretty smoothly so far. But I think there is an obvious
enhancement that I would like to propose for discussion.
First, the problem I'm seeing is that the current top
of tree hangs an mpc8555_cds_defconfig build. Bummer.
Doesn't get past the traditional "uncompressing image..."
message.
Two or three "good builds" into things, it proposes a
new build at a272e24cc8751d125f9582befed0213a2a2b270f.
Which I build and don't quite boot. It hangs after
the IDE probe, and before the i2c probe. Bummer.
These are not bugs I was looking for. Move along.
So I lie and claim "git bisect good", making a *scratch* note
of where the "git bisect log" seems to think I am so that
I might come back here and claim "git bisect bad" later.
The _next_ proposed split is at
a272e24cc8751d125f9582befed0213a2a2b270f
where I can clearly see using "git bisect visualize" that
a much better, perhaps more quiescent choice is two commits
later. The proposed bisect location is in the middle of
a series of commits from paulus tinkering with the PPC
merge tree. Two commits later, though, Linus has merged
it in totally. It will be less "in the middle" of things
and more quiescent. I want to "bump" the bisect point
up two commits and _then_ build.
So, I'm proposing something like:
$ git bisect bump +<n>
$ git bisect bump -<n>
To move the bisection point "up" or "down" a commit chain.
Am I off in the weeds?
Thanks,
jdl
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Daniel Barkalow @ 2005-11-30 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsltdsxzb.fsf@assigned-by-dhcp.cox.net>
On Wed, 30 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Mon, 28 Nov 2005, Junio C Hamano wrote:
> >
> >> *1* It is a shame that the most comprehensive definition of
> >> 3-way read-tree semantics is in t/t1000-read-tree-m-3way.sh test
> >> script.
> >
> > Isn't Documentation/technical/trivial-merge.txt more comprehensive?
>
> It describes the multi-base extention while the old one was done
> before the multi-base, so content-wise it may be more up to date.
>
> One thing I have most trouble with is that it is not obvious if
> the table is covering all the cases. You have to read from top
> to bottom and consider the first match as its fate [*1*].
I actually had that problem with the original tables; there isn't a
canonical order in which to list a table of all of the possible matches
and non-matches between items so as to be complete.
Perhaps it ought to list, on each line, which previous cases would match,
so that you could see that case 2 is really the conditions of 2 minus the
conditions for 2ALT, which is "all of the ancestors are empty, the head
has a directory/file conflict, and remote exists."
It can't fall off the table, because 1, 2, 3, 4, 6, 7, 9, and 11 cover all
of the possibilities with respect to inputs being empty, and do not care
about matching between the inputs.
> I was about to write "with no match resulting in no merge", but it is
> not even obvious if there are cases that would fall off at the
> end from the table by just looking at it. Even worse, if we add
> "no match results in no merge" at the end, by definition it
> covers all the cases, but it is not obvious what those fall-off
> cases are (IOW, what kinds of conflict they are and why they are
> not handled).
>
> Another thing, perhaps more important, is taht it does not seem
> to talk about index and up-to-dateness requirements much; it
> says something about what happens when "no merge" result is
> taken, but it is not clear about other cases. The table in
> t1000 test marks the case with "must match X" when index and
> tree X must agree at the path, and with "must match X and be
> up-to-date" when in addition the file in the working tree must
> match what is recorded in the index at the path (i.e. the former
> can have local modification in the working tree as long as index
> entry and tree match).
But that is redundant information. I was actually confused by that part of
the table for a long time, because it was not clear that it followed a
couple of simple rules (which I give above the table), and weren't
actually chosen on a case-by-case basis.
The implementation I did is actually much easier to verify, because it
doesn't go into each case for the index requirements, but checks the
actual rules: the index must match either the head or (if there is one)
the merge result, and the index must not be dirty if there is a "no merge"
result. Therefore, you can't lose any work in the index (either you didn't
have any, or you did the same thing), and you can't lose any work in the
working tree (either you didn't have any, or we're not going to use the
working tree).
Last time we discussed it ("Multi-ancestor read-tree notes"), you said:
I like the second sentence in three-way merge description. That
is a very easy-to-understand description of what the index
requirements are.
> This is vital in making sure that read-tree 3-way merge does not
> lose information from the working tree. I am sure your updated
> *code* is doing the right thing, but the documentation is not
> clear about it. E.g. case 3ALT in the table says "take our
> branch if the path does not exist in one or more of common
> ancestors and the other branch does not have it" without saying
> anything about index nor up-to-dateness requirements.
"If the index exists, it is an error for it not to match either the
head or (if the merge is trivial) the result."
"A result of "no merge" is an error if the index is not empty and not
up-to-date."
So the index is permitted to not exist (you missed this case), but if it
exists, it must match HEAD (or, well, HEAD, which is the result). The
index need not be up-to-date (since the result is not "no merge"), so the
working tree doesn't matter.
> > Probably the tables in various other places should be replaced with
> > references to this document.
>
> I agree 100% that having them scattered all over is bad and the
> trivial-merge.txt is the logical place to consolidate them, but
> I do not think simply removing others and pointing at
> trivial-merge.txt without updating it is good enough.
Certainly, your complaints about the table should be addressed first. I
think I'd addressed all your complaints from last time, but at that point,
we got sidetracked into a discussion of the details of case #16.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: More merge questions
From: Junio C Hamano @ 2005-11-30 20:23 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20051130131045.28149.qmail@science.horizon.com>
linux@horizon.com writes:
> 3) This says that if stage1 and state3 exist, use stage3.
> 3-way says if they're equal, delete the file, while if they're
> unequal, it's fail.
>
> Given that it all matches up so nicely, I'd like to honestly ask if
> case 3 of the conditions is correct. I'd think that if I deleted
> a file form te index, and the file wasn't changed on the head I'm
> tracking, the right resolution is to keep it deleted. Why override
> my deletion?
>
> Sorry if this is a dumb question, but it's not obvious to me.
Funny that I asked exactly the same question when it was done
first:
http://marc.theaimsgroup.com/?l=git&m=111804744926989
It was a question about then-current code, so other cases might
have been changed/corrected/enhanced since then, but I believe
the behaviour for the case in question here stays the same til
this day, and the response from Linus to that article still
applies.
http://marc.theaimsgroup.com/?l=git&m=111807024201485
I'll quote only the punch line here, but the whole thing is
worth a read if you want to understand how this evolved and
what the design choices and decisions were:
Right. We didn't lose anything hugely important.
In theory this could be a delete that we've missed, and we could add a
flag to actually reject this case. However, it's always easy to "recover"
deletes (just delete it again ;), so the loss of information is absolutely
minimal, and it allows starting from an empty index file.
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-11-30 20:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511301235390.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Mon, 28 Nov 2005, Junio C Hamano wrote:
>
>> *1* It is a shame that the most comprehensive definition of
>> 3-way read-tree semantics is in t/t1000-read-tree-m-3way.sh test
>> script.
>
> Isn't Documentation/technical/trivial-merge.txt more comprehensive?
It describes the multi-base extention while the old one was done
before the multi-base, so content-wise it may be more up to date.
One thing I have most trouble with is that it is not obvious if
the table is covering all the cases. You have to read from top
to bottom and consider the first match as its fate [*1*]. I was
about to write "with no match resulting in no merge", but it is
not even obvious if there are cases that would fall off at the
end from the table by just looking at it. Even worse, if we add
"no match results in no merge" at the end, by definition it
covers all the cases, but it is not obvious what those fall-off
cases are (IOW, what kinds of conflict they are and why they are
not handled).
Another thing, perhaps more important, is taht it does not seem
to talk about index and up-to-dateness requirements much; it
says something about what happens when "no merge" result is
taken, but it is not clear about other cases. The table in
t1000 test marks the case with "must match X" when index and
tree X must agree at the path, and with "must match X and be
up-to-date" when in addition the file in the working tree must
match what is recorded in the index at the path (i.e. the former
can have local modification in the working tree as long as index
entry and tree match).
This is vital in making sure that read-tree 3-way merge does not
lose information from the working tree. I am sure your updated
*code* is doing the right thing, but the documentation is not
clear about it. E.g. case 3ALT in the table says "take our
branch if the path does not exist in one or more of common
ancestors and the other branch does not have it" without saying
anything about index nor up-to-dateness requirements. In this
case, the index must match HEAD but the working tree file is
allowed to have local modification (t1000 table says "must match
A"). If somebody wants to audit if the current read-tree.c does
the right thing for this case, he needs the documentation to
tell him what should happen. There may be thinko in the design
(IOW, the index requirements the documentation places may not
make sense) that can be found during such an audit. There may
be implementation error that the code does not match what the
documentation says should happen. Not having that information
in the case table makes these verification difficult.
> Probably the tables in various other places should be replaced with
> references to this document.
I agree 100% that having them scattered all over is bad and the
trivial-merge.txt is the logical place to consolidate them, but
I do not think simply removing others and pointing at
trivial-merge.txt without updating it is good enough.
[Footnote]
*1* That is OK from an implementation point of view (i.e. we can
look at the table, and then go to C implementation and follow
its if-elif chain to see if the same checks are done in the same
order as specified in the document), but for somebody who wants
to understand the semantics, i.e. what the thing it does means,
by looking at the documentation it is harder to read.
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY handling broken on master.kernel.org?
From: Junio C Hamano @ 2005-11-30 18:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1133359173.4117.68.camel@baythorne.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> Daily kernel snapshots broke again. Trying to access, literally, "GIT_OBJECT_DIRECTORY".
Sorry about that.
Tommi Virtanen's patch looks correct.
^ permalink raw reply
* Re: More merge questions
From: Daniel Barkalow @ 2005-11-30 18:37 UTC (permalink / raw)
To: linux; +Cc: git, junkio
In-Reply-To: <20051130131045.28149.qmail@science.horizon.com>
On Wed, 30 Nov 2005, linux@horizon.com wrote:
> Given that it all matches up so nicely, I'd like to honestly ask if
> case 3 of the conditions is correct. I'd think that if I deleted
> a file form te index, and the file wasn't changed on the head I'm
> tracking, the right resolution is to keep it deleted. Why override
> my deletion?
You're allowed to do the two-way merge with your index empty, and this
means that you just hadn't read the ancestor, not that you want to remove
everything. I'm not sure what this is useful for.
You're definitely allowed to do a three-way merge with your index empty,
meaning that you don't have any local changes at all, which lets you do a
merge in a temporary index that didn't exist before. (The two-way case is
less interesting, because it's the same as just reading the new tree.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* gitignore and directories
From: Daniel Barkalow @ 2005-11-30 18:21 UTC (permalink / raw)
To: git
There's a bug in .gitignore handling with respect to directories, but I'm
not sure which behavior is intended. If you have some pattern in
.gitignore in your working tree root directory, and you run git-status in
that directory, it will ignore files that match in subdirectories.
However, if you're in a subdirectory when you run git-status, it won't
ignore things that match the pattern. One of these must be a bug, but I'm
not sure which one matches the intent.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Daniel Barkalow @ 2005-11-30 18:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux, junkio, git, pasky
In-Reply-To: <Pine.LNX.4.64.0511291742000.3135@g5.osdl.org>
On Tue, 29 Nov 2005, Linus Torvalds wrote:
> If we left things in the index in an unmerged state, we'd be guaranteed to
> either _fail_ that git commit unless somebody has done the
> git-update-index (or names the files specifically on the commit command
> line, which will do it for you).
At this point, we could have a "git-merged-by-hand" script that would take
filenames, check that they're unmerged now, and, if so, call
git-update-index for them. And it could have a -a to do all of the
unmerged entries (i.e., "I'm done merging by hand"), and maybe also have a
flag to git-commit that does this, so you can say, "Commit the merge I did
by hand, whatever filenames it used, but not any other changes I may have
had beforehand."
The "merged-by-hand" script would probably be a sensible place to complain
about leftover conflict markers (unless you force it).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox