On Aug 13, 2007, at 8:14 AM, Junio C Hamano wrote:
Junio C Hamano <gitster@xxxxxxxxx> writes:
Steffen Prohaska <prohaska@xxxxxx> writes:
...
This works only together with the commit
'attr: fix attribute handling if .gitattributes is involved'
While I think it is _one_ good approach to make things two-pass,
I do not know if this is enough. A logic similar to this should
be made available to the codepath that switches branches,
shouldn't it?
Ok, let's step back a bit and I'll suggest an alternative
approach to your 1/2. This would hopefully solve 2/2 without
any code change your patch 2/2 has.
That would be great.
I think this approach is very much in line with how the git
plumbing works, but you would need to know how the world is
designed to work in order to appreciate it fully. Let's have a
few paragraphs to give the readers some background.
The work tree side of git is primarily about the index, and what
is on the work tree is more or less secondary. At the lower
level, often we deliberately treat not having a working tree
file as equivalent to having an unmodified work tree file. We
can apply the same principle to this "missing .gitattributes
file" case.
People who only know modern git may not be aware of this, but
you can apply patches and perform a merge in a work tree that
does not have any file checked out, as long as your index is
fully populated. For example, you can do something like this:
$ git clone -n git://.../git.git v.git
$ cd v.git
$ git update-ref --no-deref HEAD $(git rev-parse v1.5.3-rc4^0)
$ git read-tree HEAD
$ git apply --index patch.txt
You will have the files that are patched in the resulting work
tree, so that you can inspect the result. If you like the
result, you can even make a commit in such a sparsely populated
tree:
$ git commit
Of course, "git commit -a" and "git add -u" Porcelain options
are more recent inventions, and they would not work with such a
sparsely populated work tree. But the above demonstration shows
that at the plumbing level the index is the king and the work
tree is secondary, and this is very much as designed. The merge
operation has similar characteristics:
$ git merge master
... will check out the paths that need file-level 3-way merge,
so that you can inspect the result, but what you will have is a
sparsely populated work tree, and this is as designed.
Ah, merge ...
Currently, the attr_stack code reads only from the work tree
and work tree alone. We could change it to:
- If the directory on the work tree has .gitattributes, use it
(this is what the current code does);
- Otherwise if the index has .gitattributes at the
corresponding path, use that instead.
This essentially treats not having .gitattributes files checked
out as equivalent to having these files checked out unmodified,
which is very much in line with how the world is designed to
work.
We may have conflicts in the .gitattributes file during a merge.
.gitattributes may be present in different stages, and with
conflict markers in the work tree.
Could we drop reading the file in the work tree completely?
.gitattributes would be a property of the index alone. To control
attributes you first need to add them to the index, before adding
the file that has attributes set in .gitattributes.
If we have .gitattributes in different stages, the right one
should be chosen to checkout corresponding files in the same stage.
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
