change the filetype from binary to text after the file is commited to a git repo

Hey everybody, I have a problem with an already committed file into my repo. This git repo was converted from svn to git some years ago. Last week I have change some lines in a file and I saw in the diff that it is marked as binary (it's a simple .cpp file). I think on the first commit it was

Re: Should I store large text files on Git LFS?

Hi Farshid, On 24 July 2017 at 13:45, Farshid Zavareh wrote: > I'll probably test this myself, but would modifying and committing a 4GB > text file actually add 4GB to the repository's size? I anticipate that it > won't, since Git keeps track of the changes only, instead of

Re: Should I store large text files on Git LFS?

On Mon, 24 Jul 2017, Farshid Zavareh wrote: I'll probably test this myself, but would modifying and committing a 4GB text file actually add 4GB to the repository's size? I anticipate that it won't, since Git keeps track of the changes only, instead of storing a copy of the whole file (whereas

Re: Should I store large text files on Git LFS?

On Mon, 24 Jul 2017, Farshid Zavareh wrote: I see your point. So I guess it really comes down to how the file is anticipated to change. If only one or two line are going to change every now and then, then LFS is not really necessary. But, as you mentioned, text files that change drastically

Re: Should I store large text files on Git LFS?

I see your point. So I guess it really comes down to how the file is anticipated to change. If only one or two line are going to change every now and then, then LFS is not really necessary. But, as you mentioned, text files that change drastically will affect the repository in the same way that

Re: git gc seems to break --symbolic-full-name

On Sun, Jul 23, 2017 at 12:23 PM, Stas Sergeev wrote: > 23.07.2017 11:40, Jacob Keller пишет: >> >> On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote: >>> >>> I wanted some kind of file to use it as a >>> build dependency for the files that needs >>> to be re-built

Re: Should I store large text files on Git LFS?

Hi Andrew. Thanks for your reply. I'll probably test this myself, but would modifying and committing a 4GB text file actually add 4GB to the repository's size? I anticipate that it won't, since Git keeps track of the changes only, instead of storing a copy of the whole file (whereas this is

Re: Should I store large text files on Git LFS?

Hi Farshid, On 24 July 2017 at 12:01, Farshid Zavareh wrote: > I'v been handed over a project that uses Git LFS for storing large CSV files. > > My understanding is that the main benefit of using Git LFS is to keep the > repository small for binary files, where Git can't

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

2017-07-23 10:33 GMT+08:00 Jean-Noël AVILA : > Plus, I hope that some day, instead of translators finding afterwards > that a change broke i18n capabilities, developpers would have some kind > of sanity check. Requiring special versions of i18n tooling stops this hope.

Should I store large text files on Git LFS?

Hey all. I'v been handed over a project that uses Git LFS for storing large CSV files. My understanding is that the main benefit of using Git LFS is to keep the repository small for binary files, where Git can't keep track of the changes and ends up storing whole files for each revision. For

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

2017-07-22 23:48 GMT+08:00 Junio C Hamano : > Johannes Schindelin writes: > >>> >> A very small hack on gettext. >> >> I am 100% opposed to this hack. It is already cumbersome enough to find >> out what is involved in i18n (it took *me* five minutes

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

2017-07-22 19:28 GMT+08:00 Johannes Schindelin : > Hi, > > On Sat, 22 Jul 2017, Jiang Xin wrote: > >> 2017-07-22 7:34 GMT+08:00 Junio C Hamano : >> > Jiang Xin writes: >> > >> >> A very small hack on gettext. > > I am 100%

Re: reftable [v2]: new ref storage format

On Sun, Jul 23 2017, Shawn Pearce jotted: > My apologies for not responding to this piece of feedback earlier. > > On Wed, Jul 19, 2017 at 7:02 AM, Ævar Arnfjörð Bjarmason > wrote: >> On Tue, Jul 18 2017, Shawn Pearce jotted: >>> On Mon, Jul 17, 2017 at 12:51 PM, Junio C

Re: reftable: new ref storage format

On Sun, Jul 23, 2017 at 3:56 PM, Shawn Pearce wrote: > On Mon, Jul 17, 2017 at 6:43 PM, Michael Haggerty > wrote: >> On Sun, Jul 16, 2017 at 12:43 PM, Shawn Pearce wrote: >>> On Sun, Jul 16, 2017 at 10:33 AM, Michael Haggerty

Re: reftable: new ref storage format

+git@vger.kernel.org. I originally sent the below reply privately by mistake. On Mon, Jul 17, 2017 at 6:43 PM, Michael Haggerty wrote: > On Sun, Jul 16, 2017 at 12:43 PM, Shawn Pearce wrote: >> On Sun, Jul 16, 2017 at 10:33 AM, Michael Haggerty

Re: Remove help advice text from git editors for interactive rebase and reword

> On 24 Jul 2017, at 01:09 , Junio C Hamano wrote: > > Who is running "git commit --amend" and "git rebase -i" in the > workflow of a user of your tool? Is it the end user who types these > commands to the shell command prompt, or does your tool formulate > the command line

Re: Bug^Feature? fetch protects only current working tree branch

Andreas Heiduk writes: > A `git fetch . origin/master:master` protects the currently checked out > branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a > mismatch between the index and HEAD. BUT branches which are HEADs in other > working trees do

Re: Remove help advice text from git editors for interactive rebase and reword

Kirill Likhodedov writes: > My motivation is the following: I'm improving the Git client > inside of IntelliJ IDEA IDE and I would like to provide only the > plain commit message text to the user (any hints can be shown > separately, not inside the editor). Who

Re: [PATCH] PRItime: wrap PRItime for better l10n compatibility

Jean-Noël AVILA writes: > Le 22/07/2017 à 02:43, Jiang Xin a écrit : >> >> Benefit of using the tweak version of gettext: >> >> 1. `make pot` can be run in a tar extract directory (without git controlled). > > This issue is real for packet maintainers who can patch

Re: reftable [v2]: new ref storage format

My apologies for not responding to this piece of feedback earlier. On Wed, Jul 19, 2017 at 7:02 AM, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 18 2017, Shawn Pearce jotted: >> On Mon, Jul 17, 2017 at 12:51 PM, Junio C Hamano wrote: >>> Shawn Pearce

Re: reftable [v3]: new ref storage format

On Sat, Jul 22, 2017 at 8:29 PM, Shawn Pearce wrote: > 3rd iteration of the reftable storage format. > > You can read a rendered version of this here: > https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md > > Significant changes from v2:

Re: git gc seems to break --symbolic-full-name

23.07.2017 11:40, Jacob Keller пишет: On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote: I wanted some kind of file to use it as a build dependency for the files that needs to be re-built when the head changes. This works very well besides git gc. What other method can be used

Re: [PATCH v2 00/10] tag: only respect `pager.tag` in list-mode

On 21 July 2017 at 00:27, Junio C Hamano wrote: > I tend to agree with you that 1-3/10 may be better off being a > single patch (or 3/10 dropped, as Brandon is working on losing it > nearby). I would have expected 7-8/10 to be a single patch, as by > the time a reader reaches

Re: Expected behavior of "git check-ignore"...

From: "John Szakmeister" Sent: Thursday, July 20, 2017 11:37 AM A StackOverflow user posted a question about how to reliably check whether a file would be ignored by "git add" and expected "git check-ignore" to return results that matched git add's behavior. It turns out

Bug^Feature? fetch protects only current working tree branch

A `git fetch . origin/master:master` protects the currently checked out branch (HEAD) unless the `-u/--update-head-ok` is supplied. This avoids a mismatch between the index and HEAD. BUT branches which are HEADs in other working trees do not get that care - their state is silently screwed up. Is

Re: Remove help advice text from git editors for interactive rebase and reword

On 23 July 2017 at 13:03, Kirill Likhodedov wrote: > Hello, > > is it possible to remove the helping text which appears at the bottom > of the Git interactive rebase editor (the one with the list of > instructions) I believe currently there is not way to do it. The interactive rebase is

Remove help advice text from git editors for interactive rebase and reword

Hello, is it possible to remove the helping text which appears at the bottom of the Git interactive rebase editor (the one with the list of instructions), and the one which appears at the bottom of the commit editor (which appears on rewording a commit or squashing commits)? The texts I'm

[no subject]

greetings Git http://rootyu.cn/upload_video.php?note=ex2c7kzp4rz85 madhan_dc

Re: git gc seems to break --symbolic-full-name

On Fri, Jul 21, 2017 at 12:03 PM, Stas Sergeev wrote: > I wanted some kind of file to use it as a > build dependency for the files that needs > to be re-built when the head changes. > This works very well besides git gc. > What other method can be used as simply > as that? git

Re: recursive grep doesn't respect --color=always inside submodules

On Sat, Jul 22, 2017 at 11:02 PM, Orgad Shaneh wrote: > Hi, > > When git grep --color=always is used, and the output is redirected to > a file or a pipe, results inside submodules are not colored. Results > in the supermodule are colored correctly. > > - Orgad This occurs

index.lock porcelain interface?

While working on some scripts for continuous integration, we wanted to check if git was doing anything, before running our script. The best we came up with was checking for the existence of index.lock or if a merge in progress. The MERGE_HEAD can be checked, but we chose to use git status

fetch-any-blob / ref-in-want proposal

Hi, Jonathan Tan proposed a design and a patch series for requesting a specific ref on fetch 4 months ago[1]. Is there any progress with this? - Orgad [1] https://public-inbox.org/git/ffd92ad9-39fe-c76b-178d-6e3d6a425...@google.com/

recursive grep doesn't respect --color=always inside submodules

Hi, When git grep --color=always is used, and the output is redirected to a file or a pipe, results inside submodules are not colored. Results in the supermodule are colored correctly. - Orgad