> I agree that the approach taken here is a sensible way to implement
> the design, _if_ the design and the problem it tries to solve makes
> sense. I am not sure about that yet myself, though.
This is a "first things first".
What aspect of the problem to be solved is in question?
Jeff King writes:
> This is the first use of gitattributes in the unpack-trees code path. I
> cannot think offhand of any philosophical reason that should not be OK,
> but it is something worth considering (i.e., this code path is deep
> plumbing; are there cases where we would not want to suppor
On Mon, Nov 17, 2014 at 05:21:03PM -0500, Daniel Hagerty wrote:
> > I don't think there is an easy way to get what you want. You would have
> > to write a new merge 3-way strategy that handles this case differently.
> > And most of the file-level heavy lifting in merge strategies is done by
>
> Just to be clear, you were expecting "git merge b" to produce a
> conflict?
Yessir.
> I can imagine there might be times you would like to notice this case
> and visit it manually (e.g., even though the conflict would show both
> sides with the same content, you might want the resoluti
On Mon, Nov 17, 2014 at 01:39:43PM -0500, Daniel Hagerty wrote:
> "git merge b" produces a successful merge, as both branches perform
> the "same" work.
Just to be clear, you were expecting "git merge b" to produce a
conflict?
> For the body of content in question, this is a merge conflict. Git
Given a repository setup thusly:
$ git --version
git version 2.2.0.rc2
git init .
echo '0.0' > version
git add version
git commit -m "master"
for i in a b ; do
git checkout -b $i master
echo '0.1' > version
git commit -a -m "leg $i"
done
git checkout -b c master
echo '0.2' > version
6 matches
Mail list logo
