Re: git merge a b when a == b but neither == o is always a successful merge?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 > 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?

    From here, it seems obvious that there is textual data where the
 supression of sha1 identical files as non-conflicting isn't always
 proper.  I'm somewhat doubtful that the workflow design is really the
 problem -- I either have to remove a required feature of the broader
 design, or I have to move the problem somewhere else that isn't as
 well suited to handle it.  git seems the right tool for the job, but
 for the parameterization of merge.

    I'd be happy for some route that doesn't involve changing upstream
git, but it doesn't sound like that exists.

    Thanks!
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]