I'm working through Constantine's suggestions today. So far the
.gitignore doesn't work, since the files need to be in the repository.
Also, since most of them are in their own directory, even the directory
wouldn't be a part of the repository. They are text files, not binary,
if that makes a difference.
"git checkout" won't really work as it requires us to manually get zero
to four files for an automated process. Some times one or two of the
files might change, sometimes all of them do.
Looking at "git merge --strategy=ours" next. Not sure how that will
handle files that should be changed, or marked as conflicting.
There my not be a technical solution, and we may have to change our
process. We'll see how things go.
Still working on it.
Leam
On 8/20/20 2:32 PM, Philip Oakley wrote:
Also, you may need to set the files (file types) to be marked as binary, so
that textural merge is not used.
The line by line textural merge can cause confusion for the --ours because
it may be that un-conflicted changes are merged anyway, and it is only in
the case of *conflict *that --ours is used. i.e. read the manual very
carefully - is obvious in hindsight, as it always is ;-) [is it a conflict
resolution strategy, or is it a method of 'merging']
--
Philip
On Wednesday, August 19, 2020 at 8:32:40 PM UTC+1 constantin...@gmail.com
wrote:
Options:
1. Add such files to .gitignore
2. git checkout ...
3. git merge --strategy=ours ...
Regards
On Wed, Aug 19, 2020 at 10:00 PM Leam Hall <leam...@gmail.com> wrote:
Hopefully I can explain this well...
We have some files that are generated as a part of the build process. So
they can get updated frequently during some coding events. They must be in
the repo since other tools use these specific files, but do not run the
build process. However, if there is a push to the master repo, a merge
conflict isn't really an issue, since the files will get regenerated during
build.
Is there a way to mark files as "Keep in the repo, use the current copy,
and don't worry about merge-conflicts"?
Thanks!
Leam
--
You received this message because you are subscribed to the Google Groups
"Git for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to git-users+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/a117a00c-824b-4b1b-b617-84d995d69254o%40googlegroups.com
<https://groups.google.com/d/msgid/git-users/a117a00c-824b-4b1b-b617-84d995d69254o%40googlegroups.com?utm_medium=email&utm_source=footer>
.
--
Constantine Shulyupin
--
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/ea72257a-9c40-560e-e307-4a091234767d%40gmail.com.
