el estado de git muestra modificaciones, pago de git - <archivo> no las elimina


222

Me gustaría eliminar todos los cambios en mi copia de trabajo.
La ejecución git statusmuestra archivos modificados.
Nada de lo que hago parece eliminar estas modificaciones.
P.ej:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

66
No estoy seguro de por qué git reset --hardno funcionó aquí. Nota: debe ser git checkout -- `git ls-files -m`para cancelar los archivos ( --)
VonC

2
Si elimina los archivos y los usa checkout -- <file>, debería funcionar. La detección de cambios es un poco exigente en algunas situaciones (entre otras, si hay una falta de coincidencia de CRLF)
eckes


1
@ BuZZ-dEE: es un duplicado y es más antiguo y, por lo tanto, tendría prioridad. Pero si bien la pregunta a la que se vincula es esencialmente la misma, la respuesta que acepté a continuación es mucho más informativa que cualquiera de las respuestas allí, y resolvió mi problema.
rbellamy

no es una solución, sino un cuchillo suizo para casos aburridos: git update-index --assume-unchagedfuerza el estado sin cambios de los archivos (¡incluso para los cambiados!)
pdem

Respuestas:


126

Existen múltiples problemas que pueden causar este comportamiento:

Normalización de final de línea

También he tenido este tipo de problemas. Se reduce a git convirtiendo automáticamente crlf a lf. Esto generalmente es causado por terminaciones de línea mixtas en un solo archivo. El archivo se normaliza en el índice, pero cuando git lo desnormaliza nuevamente para diferenciarlo del archivo en el árbol de trabajo, el resultado es diferente.

Pero si quieres arreglar esto, debes deshabilitar core.autocrlf , cambiar todas las terminaciones de línea a lf y luego habilitarlo nuevamente. O puede deshabilitarlo por completo haciendo:

git config --global core.autocrlf false

En vez de core.autocrlf , también puede considerar el uso de .gitattributearchivos. De esta manera, puede asegurarse de que todos los que usan el repositorio usen las mismas reglas de normalización, evitando que las terminaciones de líneas mixtas ingresen al repositorio.

También considere configurar core.safecrlf para advertir si desea que git le avise cuando se realice una normalización no reversible.

El imbécil páginas de manual de dicen esto:

La conversión de CRLF tiene una pequeña posibilidad de corromper los datos. autocrlf = true convertirá CRLF a LF durante la confirmación y LF a CRLF durante el pago. Un archivo que contiene una mezcla de LF y CRLF antes de la confirmación no puede ser recreado por git. Para los archivos de texto, esto es lo correcto: corrige las terminaciones de línea de modo que solo tengamos terminaciones de línea LF en el repositorio. Pero para los archivos binarios que se clasifican accidentalmente como texto, la conversión puede dañar los datos.

Sistemas de archivos que no distinguen entre mayúsculas y minúsculas

En los sistemas de archivos que no distinguen entre mayúsculas y minúsculas, cuando el mismo nombre de archivo con una carcasa diferente está en el repositorio, git intenta verificar ambos, pero solo uno termina en el sistema de archivos. Cuando git intenta comparar el segundo, lo compararía con el archivo incorrecto.

La solución sería cambiar a un sistema de archivos que no distinga entre mayúsculas y minúsculas, pero esto en la mayoría de los casos no es factible o renombrar y comprometer uno de los archivos en otro sistema de archivos.


8
De acuerdo ... así que lo hizo ... ahora el estado de git no muestra cambios. He leído sobre la configuración de autocrlf, y parece que no puedo hacerlo bien.
rbellamy

1
¡Buena atrapada! +1. Otro argumento más para mí establecer eso en falso ( stackoverflow.com/questions/1249932/… ).
VonC

¿Qué significa esto: "un archivo que contiene una mezcla de LF y CRLF antes de la confirmación no puede ser recreado por git". ¿Es esto porque git siempre normalizará las terminaciones de línea, en función de la configuración core.autocrlf?
rbellamy

1
Una solución más sensata al problema de mayúsculas y minúsculas es no tener varias carpetas en su repositorio cuyos nombres solo difieran entre mayúsculas y minúsculas .
Ohad Schneider

3
Para buscar nombres de archivos que difieran solo en mayúsculas y minúsculas, puede ejecutar git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d. Para enumerar los nombres en mayúsculas y minúsculas de dichos archivos, ejecutegit ls-tree -r --name-only HEAD | fgrep -i -f <(git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d) | sort -i
Diomidis Spinellis el

220

Estaba teniendo este problema en Windows, pero no estaba preparado para analizar las ramificaciones del uso config --global core.autocrlf false. Tampoco estaba preparado para abandonar otras ramas privadas y otras cosas en mi escondite y comenzar con un nuevo clon. Solo necesito hacer algo. Ahora.

Esto funcionó para mí, con la idea de que dejas que git reescriba tu directorio de trabajo por completo:

git rm --cached -r .
git reset --hard

(Tenga en cuenta que ejecutar simplemente git reset --hardno era lo suficientemente bueno ni era simple rmen los archivos antes de lo resetque se sugiere en los comentarios a la pregunta original)


8
Otro éxito aquí después de cambiar core.autocrlfno tuvo ningún efecto.
Daniel Buckmaster

8
Estaba teniendo este problema en Windows incluso con core.autocrlf false. Esta respuesta funcionó cuando nada más lo haría.
kenchilada

99
He intentado múltiples sugerencias de esta y otras preguntas. Esta es la única solución que funcionó para mí. No tenía ningún archivo de atributos y ya comencé con core.autocrlf en false.
BrotherOdin

44
Esto no funcionó para mí. Entonces, lo hice de una manera más fea al crear una nueva sucursal solo para cometer estos cambios, ya que de todos modos son inútiles para mí. [java] git checkout -b a-branch-to-commit-bad-crlf-files [/ java] [java] git commit -am "confirmando los archivos crlf malos" [/ java]
Mohd Farid

3
A veces, problemas como este me hacen realmente extrañar SVN.
Mike Godin

104

Otra solución que puede funcionar para las personas, ya que ninguna de las opciones de texto funcionó para mí:

  1. Reemplace el contenido de .gitattributescon una sola línea:* binary . Esto le dice a git que trate cada archivo como un archivo binario con el que no puede hacer nada.
  2. Verifique que el mensaje de los archivos ofensivos haya desaparecido; si no es así, puede git checkout -- <files>restaurarlos a la versión del repositorio
  3. git checkout -- .gitattributes para restaurar el .gitattributes archivo a su estado inicial
  4. Compruebe que los archivos todavía no están marcados como modificados.

1
He estado atrapado en no poder revertir, extraer o esconder archivos durante las últimas dos horas. Esta fue la solución para mí! ¡Gracias! (Git 1.8.3.1)
NuSkooler

3
Intenté muchas cosas antes de finalmente encontrar el éxito con esto. ¡Gracias!
ghenghy

1
¿Como funciona esto? Creo que volver .gitattributesal original volvería a introducir el mismo problema, pero, por desgracia, mi problema ya está resuelto. Ninguna de las otras sugerencias funcionó en mi caso.
jdk1.0

1
@ jdk1.0 mi comprensión / suposición es que están involucrados dos métodos de comparación diferentes. El error ocurre cuando tienes una línea diferente que termina en algún lugar, y git a veces lo ignora. Cuando pregunta git status, descubre que son archivos diferentes. Cuando preguntas git checkout, descubre que tienen el mismo contenido. Esta solución está indicando temporalmente a git que ignore cualquier ingenio de final de línea posible y se asegure de que su copia local sea byte por byte idéntica a la de HEAD. Una vez que se haya resuelto, permitir que se reanude la inteligencia está bien, porque no agregará nuevos errores.
zebediah49

3
¡He pasado un par de horas lidiando con esto y esta solución finalmente funcionó para mí!
Maryam

71

Para futuras personas que tienen este problema: Tener cambios en el modo de archivo también puede tener los mismos síntomas. git config core.filemode falselo arreglará


3
Después de hacer esto, es posible que deba hacer ungit checkout .
Marty Neal

2
Me funcionó sin tener que volver a pagar
phillee

3
Para referencia futura: para saber si esta es la solución que necesita (y no las otras soluciones en otras respuestas), use git diffy mostrará archivos con cambios de modo como este old mode 100755 / new mode 100644.
pgr

Esto me lo arregló después de que absolutamente nada más lo haría. Realmente no creo que la gente deba hacer git cheatsheets y "guías simples" en internet. Git realmente no es algo para recoger y usar, creo que es algo en lo que debes tener entrenamiento formal y dedicado y practicar antes de usarlo.

Gracias, me salvaste muchas lágrimas!
Lukasz

33

Esto me ha vuelto loco, especialmente porque no podría solucionarlo sin ninguna de las soluciones que se encuentran en línea. Así es como lo resolví. No puedo tomar los créditos aquí ya que este es el trabajo de un colega :)

Origen del problema: mi instalación inicial de git fue sin conversión automática de línea en Windows. Esto causó que mi confirmación inicial a GLFW no tuviera el final de línea adecuado.

Nota: Esta es solo una solución local. El próximo tipo que clone el repositorio seguirá estancado con este problema. Puede encontrar una solución permanente aquí: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Configuración: Xubuntu 12.04 Git repo con proyecto glfw

Problema: no se pueden restablecer los archivos glfw. Siempre se muestran como modificados, independientemente de lo que intenté.

Resuelto:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Puede ser útil mencionar el contenido de la línea comentada.
rbellamy

Desafortunadamente, la mayoría de los proyectos no tienen este archivo .gitattribute opcional
mchiasson

Gracias. Simplemente no entiendo por qué esto es necesario
diogovk

¿Por qué? Básicamente, esta es una solución temporal para el final de línea. Use la solución permanente siguiendo el enlace en la Nota.
Richard Lalancette

11

Tenía un archivo .bat con el mismo problema (no podía eliminarlo en archivos sin seguimiento). git checkout: no funcionó, tampoco ninguna de las sugerencias en esta página. Lo único que funcionó para mí fue hacer:

git stash save --keep-index

Y luego para eliminar el alijo:

git stash drop

Esto funcionó para mí. Tenga en cuenta que el --keep-indexes importante.
user991710

¿Por qué es importante el --keep-index?
Choylton B. Higginbottom

8

¡Tengo el mismo problema dos veces! Ambas veces cuando escondí algunos cambios que hice y luego traté de recuperarlos. No pude hacer estallar los cambios ya que tengo muchos archivos que se han cambiado, ¡pero NO! Son exactamente lo mismo.

Ahora creo que he probado todas las soluciones anteriores sin éxito. Después de probar el

git rm --cached -r .
git reset --hard

Ahora tengo casi todos los archivos en mi repositorio modificados.

Al diferenciar el archivo, dice que he eliminado todas las líneas y luego las agrego nuevamente.

Un poco inquietante. Ahora evitaré esconderme en el futuro.

La única solución es clonar un nuevo repositorio y comenzar de nuevo. (Lo hice la última vez)


6

Intenta hacer un

git checkout -f

Eso debería eliminar todos los cambios en el repositorio local de trabajo actual


¡Agradable! Esto funcionó para mí. Aunque para un caso terco, primero tuve que git checkout -f <another recent branch>volver a mi sucursal congit checkout -f <branch I'm working on>
Ingeniero invertido

4

Solo pude solucionar esto eliminando temporalmente el archivo .gitattributes de mi repositorio (que definió * text=autoy *.c text).

Corrí git statusdespués de eliminar y las modificaciones desaparecieron. No regresaron incluso después de que .gitattributes se volviera a colocar en su lugar.


Esto funciona incluso con atributos más complicados, por ejemplo, filtros
Samizdis

2

Tener finales de línea consistentes es algo bueno. Por ejemplo, no activará fusiones innecesarias, aunque triviales. He visto a Visual Studio crear archivos con terminaciones de línea mixtas.

Además, algunos programas como bash (en linux) requieren que los archivos .sh estén terminados en LF.

Para asegurarse de que esto suceda, puede usar gitattributes. Funciona a nivel de repositorio sin importar el valor de autcrlf.

Por ejemplo, puede tener atributos .gitat como este: * text = auto

También puede ser más específico por tipo / extensión de archivo si importa en su caso.

Entonces, autocrlf puede convertir terminaciones de línea para programas de Windows localmente.

En un proyecto mixto C # / C ++ / Java / Ruby / R, Windows / Linux, esto funciona bien. No hay problemas hasta ahora.


2

También tuve los mismos síntomas, pero fue causado por algo diferente.

Yo no era capaz de:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

incluso en git rm --cached app.jsél firma como eliminado y en archivos sin seguimiento pude ver app.js. Pero cuando intenté rm -rf app.jsy volví git statusa peform , todavía me muestra el archivo en 'sin seguimiento'.

Después de un par de intentos con un colega, descubrimos que fue causado por Grunt.

A medida que Gruntse ha activado, y debido a que app.js se ha generado a partir de un par de otros archivos js, descubrimos que después de cada operación con archivos js (también este app.js) Grunt recrea nuevamente app.js.


2

Este problema también puede ocurrir cuando un contribuyente al repositorio trabaja en una máquina Linux, o las ventanas con Cygwin y los permisos de archivo cambian. Git solo sabe de 755 y 644.

Ejemplo de este problema y cómo verificarlo:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

Para evitar esto, debes asegurarte de configurar git correctamente usando

git config --global core.filemode false

2

Aquí hay muchas soluciones y tal vez debería haber intentado algunas de ellas antes de encontrar la mía. De todos modos aquí hay uno más ...

Nuestro problema era que no teníamos aplicación para las líneas finales y el repositorio tenía una mezcla de DOS / Unix. Peor aún era que en realidad era un repositorio de código abierto en esta posición, y que habíamos bifurcado. Aquellos con la propiedad principal del repositorio del sistema operativo tomaron la decisión de cambiar todas las líneas finales a Unix y se realizó la confirmación que incluía una .gitattributespara hacer cumplir las terminaciones de línea.

Desafortunadamente, esto parecía causar problemas muy parecidos a los descritos aquí, donde una vez que se fusionó el código antes del DOS-2-Unix, los archivos se marcarían para siempre como modificados y no se podrían revertir.

Durante mi investigación para esto, me encontré con: https://help.github.com/articles/dealing-with-line-endings/ - Si me enfrento a este problema nuevamente, primero comenzaría probando esto.


Aquí esta lo que hice:

  1. Inicialmente hice una fusión antes de darme cuenta de que tenía este problema y tuve que abortarlo git reset --hard HEAD( me encontré con un conflicto de fusión. ¿Cómo puedo abortar la fusión? )

  2. Abrí los archivos en cuestión en VIM y cambié a Unix ( :set ff=unix). Se dos2unixpodría usar una herramienta como

  3. comprometido

  4. fusionó la entrada master(el maestro tiene los cambios de DOS-2-Unix)

    git checkout old-code-branch; git merge master

  5. Se resolvieron los conflictos y los archivos volvieron a ser DOS, así que tuve que hacerlo :set ff=unixcuando estaba en VIM. (Tenga en cuenta que he instalado https://github.com/itchyny/lightline.vim que me permitió ver cuál es el formato del archivo en la línea de estado de VIM)

  6. comprometido. ¡Todo ordenado!

2

El problema con el que me encontré es que Windows no se preocupa por la capitalización del nombre de archivo, pero git sí. Entonces, git almacenó una versión en mayúsculas y minúsculas del archivo, pero solo pudo verificar una.


2

Cometí todos los cambios y luego hice y deshago el commit. Esto funciono para mi

git add.

git commit -m "Confirmación aleatoria"

git reset --HAD HEAD ~ 1


2

Normalmente, en GIT para borrar todas sus modificaciones y archivos nuevos, los siguientes 2 comandos deberían funcionar muy bien (tenga cuidado , esto eliminará todos sus nuevos archivos + carpetas que haya creado y restaurará todos sus archivos modificados al estado de su actual commit ):

$ git clean --force -d
$ git checkout -- .

Tal vez una mejor opción a veces es simplemente hacer "git stash push" con un mensaje opcional, así:

$ git stash push -m "not sure if i will need this later"

Esto también borrará todos sus archivos nuevos y modificados, pero los tendrá escondidos en caso de que desee restaurarlos. El almacenamiento en GIT se lleva de una rama a otra, por lo que puede restaurarlos en una rama diferente, si lo desea.

Como nota al margen, en caso de que ya haya montado algunos archivos recién agregados y desee deshacerse de ellos, esto debería ser el truco:

$ git reset --hard

Si todo lo anterior no funciona para usted , lea a continuación lo que funcionó para mí hace un tiempo:

Me encontré con este problema varias veces antes. Actualmente estoy desarrollando en una máquina con Windows 10 proporcionada por mi empleador. Hoy, este comportamiento particular de git fue causado por crear una nueva rama de mi rama "desarrollar". Por alguna razón, después de que volví a "desarrollar" la rama, algunos archivos aparentemente aleatorios persistieron y aparecían como "modificados" en "estado de git".

Además, en ese momento no podía pagar otra rama, por lo que estaba atascado en mi rama "desarrollar".

Esto es lo que hice:

$ git log

Me di cuenta de que la nueva rama que creé desde "desarrollo" el día de hoy se mostraba en el primer mensaje de "confirmación", al que se hace referencia al final "HEAD -> desarrollo, origen / desarrollo, origen / CABEZA, The-branch-i-created -el día de hoy ".

Como realmente no lo necesitaba, lo eliminé:

$ git branch -d The-branch-i-created-earlier-today

Los archivos modificados seguían apareciendo, así que lo hice:

$ git stash

Esto resolvió mi problema:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Por supuesto $ git stash list, mostrará los cambios escondidos, y como tenía pocos y no necesitaba ninguno de mis escondites, lo hice $ git stash clearpara ELIMINAR TODOS LOS STASHES.

NOTA : No he intentado hacer lo que alguien sugirió aquí antes que yo:

$ git rm --cached -r .
$ git reset --hard

Esto puede haber funcionado también, me aseguraré de intentarlo la próxima vez que me encuentre con este problema.


1

Si clona un repositorio y ve instantáneamente los cambios pendientes, entonces el repositorio está en un estado inconsistente. Por favor NO comente * text=autodesde el.gitattributes archivo. Eso se puso allí específicamente porque el propietario del repositorio quiere que todos los archivos se almacenen de manera consistente con las terminaciones de línea LF.

Según lo indicado por HankCa, seguir las instrucciones en https://help.github.com/articles/dealing-with-line-endings/ es el camino a seguir para solucionar el problema. Botón fácil:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

Luego combine (o solicite) la sucursal con el propietario del repositorio.


1

Nada más en esta página funcionó. Esto finalmente funcionó para mí. No muestra archivos no rastreados o comprometidos.

git add -A
git reset --hard

1

Para mí, el problema fue que Visual Studio se abrió al ejecutar el comando

git checkout <file>

Después de cerrar Visual Studio, el comando funcionó y finalmente pude aplicar mi trabajo desde la pila. Por lo tanto, verifique todas las aplicaciones que puedan realizar cambios en su código, por ejemplo, SourceTree, SmartGit, NotePad, NotePad ++ y otros editores.


0

Nos enfrentamos a una situación similar en nuestra empresa. Ninguno de los métodos propuestos no nos ayudó. Como resultado de la investigación, se reveló el problema. Lo que pasaba era que en Git había dos archivos, cuyos nombres solo diferían en el registro de símbolos. Los sistemas Unix los veían como dos archivos diferentes, pero Windows se estaba volviendo loco. Para resolver el problema, eliminamos uno de los archivos del servidor. Después de eso, en los repositorios locales en Windows ayudó a los siguientes comandos (en diferentes secuencias):

git reset --hard
git pull origin
git merge

0

Lo resolví editando .git / config, agregando:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

Luego fui a .git / refs / heads / name_branch y coloqué la identificación del último commitenter code here


0

Lo resolví de esta manera:

  1. Copie el contenido del código correcto que desee
  2. Elimine el archivo que está causando el problema (el que no puede revertir) de su disco. ahora debería encontrar ambas versiones del mismo archivo marcadas como eliminadas.
  3. Confirmar la eliminación de los archivos.
  4. Vuelva a crear el archivo con el mismo nombre y pegue el código correcto que copió en el paso 1
  5. comprometer la creación del nuevo archivo.

Eso fue lo que funcionó para mí.


0

Una solución propuesta aquí no funcionó, descubrí que el archivo era en realidad un enlace a algunos caracteres especiales:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.