2

We have a repo with a file say x.APK that is pulled by client machines.
These client machine will modify this file and keep it locally for their use.

In normal usage we will update this file very rarely say once in 2-3 months.
The first time it will pull the files many along with x.APK and modify it and store it locally. We then update other files and push. On pull in client we get a local change but since x.APK did not change there are no conflicts.
Now is there any way to update x.APK ignoring whatever local changes were made to that file with only git pull.

git pull are done by a script and we cannot access the clients always. so running other commands will be tricky.

We tried:

git update-index --assume-unchanged

this ignores the changes but is not able to pull

Using gitignore it will delete the file from the clients and repo which we don't want.

It is a peculiar case if someone could help out it would be great.

goldsmit409
  • 478
  • 4
  • 26

1 Answers1

0

It depends on the nature of the local modification done in x.txt.

If those modifications are well defined (and not all over the place in x.txt) then you could consider a content filter driver in order to generate the right x.txt on checkout:

  • it means that you do not version x.txt anymore, but a template version "x.template".
    git mv x.txt x.txt.tpl.
    Add x.txt to your .gitignore.

  • Then, add a smudge script associated to x.txt files in a .gitattributes declaration:

    x.txt filter=updatex

smudge
(image from "Customizing Git - Git Attributes", from "Pro Git book")

git config filter.updatex.smudge 'update_x'

The style_smudge script can be versioned, and will have to fetch local modification content from a file outside the repo (meaning those a private modification), and inject its content in the template in order to generate the actual x.txt.

That way, a git pull which triggers an update of the working tree would automatically re-generate x.txt with the new updates as well as the local modifications.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I am sorry I should have been a more specific, it is not txt but rather a android APK – goldsmit409 Jan 29 '16 at 09:50
  • @goldsmit409 an apk file? (https://en.wikipedia.org/wiki/Android_application_package). That is a binary (archive), no? If so, ... not much to do expect to *not* modify it locally (or to modify a copy, and reports the changes each time the apk changes) – VonC Jan 29 '16 at 09:52
  • yes apk is the binary android file, basically a container file for android apps. Seems like I cannot achieve what I want. Maybe the modified files has to move out the repo but it will be a long process and want to avoid it – goldsmit409 Jan 29 '16 at 09:56
  • @goldsmit409 isn't possible to use the content filter driver I mention to re-generate the right content for that apk on each checkout? – VonC Jan 29 '16 at 09:57
  • I am going to read about the filter you mention, its new to me but is it something (taking a wild guess) like diff is created from original to modified file and then that diff is applied. Also the modification I am looking to do is that pushing a APK ~15mb OTA is a huge network task which we dont have access to in remote. So we push diff ~1-2mb that are Ok for us and this is what modifies the file – goldsmit409 Jan 29 '16 at 10:06
  • @goldsmit409 actually, the filter can be any script you want. As long as you have a way to rebuild the right content for the apk file, you can then declare that process as a "content filer driver". – VonC Jan 29 '16 at 10:08
  • Why do you have a build artifact in the version control system in the first place? That's not an optimal solution. – 1615903 Jan 29 '16 at 10:20
  • It's not actually a build artifact, it is actually the final APK that is relased. As I said before we have a peculiar system. I know git is not supposed to be used as we are using but to update a lot of clients with latest code and APK's this was a solution for us. – goldsmit409 Jan 29 '16 at 10:44