I suggest a new feature: One copy from files

I suggest a new feature: One copy from files

[Rm Beer]

I have a several directories with binary files datas that is discard
by .gitignore.

I recommend make a new .gitonecopy or .gitonelog or something that
take the directories with only 1 copy of last updated and not take
history of files in the repository.
Maybe anyone found other best method for apply this idea.

Re: I suggest a new feature: One copy from files

[Samuel Lijin]

...what?

I'm sorry, I have absolutely no idea what you're asking. You're going
to have to be a lot more specific with your description of the desired
behavior because as is, I have no idea what purpose your .gitonecopy
or .gitonelog would serve. I also have no idea what this has to do
with the binary files ignored by .gitignore.

It would probably make sense for you to describe a use case for this
as well, to help us understand why you want what you're asking for.

On Sun, Apr 23, 2017 at 10:47 PM, Rm Beer <rmbeer2@gmail.com> wrote:
> I have a several directories with binary files datas that is discard
> by .gitignore.
>
> I recommend make a new .gitonecopy or .gitonelog or something that
> take the directories with only 1 copy of last updated and not take
> history of files in the repository.
> Maybe anyone found other best method for apply this idea.

Re: I suggest a new feature: One copy from files

[Samuel Lijin]

Looping the listserv back in, didn't realize this had gone off thread.

I'm not sure what you mean by "update only the last change, and not
record the old changes".

update-index is, like most Git commands, per repo.

On Mon, Apr 24, 2017 at 12:08 AM, Rm Beer <rmbeer2@gmail.com> wrote:
> Yes, but i say about of have a update only the last change, and not
> record the old changes. Interesting command the 'update-index', this
> is a permanent config for each dir/files?
>
> 2017-04-24 1:59 GMT-03:00 Samuel Lijin <sxlijin@gmail.com>:
>> Ah - I see what you're asking for now, basically the ability to tell Git to
>> ignore changes to a file once you've already started tracking it, right?
>>
>> If I'm not mistaken, git update-index --skip-worktree will do this for you.
>> (I'm on my phone, so I don't have easy access to documentation right now.)
>>
>> Hope this helps.
>>
>> On Apr 23, 2017 11:51 PM, "Rm Beer" <rmbeer2@gmail.com> wrote:
>>>
>>> in a repository have two behaviors. (How understand i)
>>>
>>> 1) A file can check and updated in the repository, take any change
>>> from the file like a record logs.
>>> 2) If the file have in .gitignore . Git never see it.
>>>
>>> I suggest add a new behaviors:
>>>
>>> 3) A file can check and updated in the repository. But never add in
>>> the record logs, only have one copy in the repository. (Maybe add
>>> filters in .gitonecopy or something)
>>>
>>>
>>> 2017-04-24 1:02 GMT-03:00 Samuel Lijin <sxlijin@gmail.com>:
>>> > ...what?
>>> >
>>> > I'm sorry, I have absolutely no idea what you're asking. You're going
>>> > to have to be a lot more specific with your description of the desired
>>> > behavior because as is, I have no idea what purpose your .gitonecopy
>>> > or .gitonelog would serve. I also have no idea what this has to do
>>> > with the binary files ignored by .gitignore.
>>> >
>>> > It would probably make sense for you to describe a use case for this
>>> > as well, to help us understand why you want what you're asking for.
>>> >
>>> > On Sun, Apr 23, 2017 at 10:47 PM, Rm Beer <rmbeer2@gmail.com> wrote:
>>> >> I have a several directories with binary files datas that is discard
>>> >> by .gitignore.
>>> >>
>>> >> I recommend make a new .gitonecopy or .gitonelog or something that
>>> >> take the directories with only 1 copy of last updated and not take
>>> >> history of files in the repository.
>>> >> Maybe anyone found other best method for apply this idea.

Re: I suggest a new feature: One copy from files

[Jacob Keller]

On Sun, Apr 23, 2017 at 8:47 PM, Rm Beer <rmbeer2@gmail.com> wrote:
> I have a several directories with binary files datas that is discard
> by .gitignore.
>
> I recommend make a new .gitonecopy or .gitonelog or something that
> take the directories with only 1 copy of last updated and not take
> history of files in the repository.
> Maybe anyone found other best method for apply this idea.

So, clearly you haven't defined the request very well. It *sounds*
like what you want is the ability to say "git please store and
copy/send this file to other people, but only store it once, and don't
allow storing history of it". This pretty much defeats the entire
point of revision control and doesn't make sense to me as part of a
revision control system.

Thanks,
Jake

Re: I suggest a new feature: One copy from files

[Jacob Keller]

On Mon, Apr 24, 2017 at 4:47 PM, Rm Beer <rmbeer2@gmail.com> wrote:
> 2017-04-24 3:13 GMT-03:00 Jacob Keller <jacob.keller@gmail.com>:
>> So, clearly you haven't defined the request very well. It *sounds*
>> like what you want is the ability to say "git please store and
>> copy/send this file to other people, but only store it once, and don't
>> allow storing history of it". This pretty much defeats the entire
>> point of revision control and doesn't make sense to me as part of a
>> revision control system.
>
> Not have sense the save history of revision control system for any
> binary files datas, who need save a multiple files by change any bytes
> from a files? Where i change any pixel of image, a word of odt/doc, or
> sound, music, driver, etc. In this case you only need 1 copy in the
> repository of .git , you not need a 100 copys in the .git, one by each
> day of change. You need a old image with a wrong pixel? not have
> sense...
>

Please don't drop the list :)

If you're not interested in tracking the revision history of a file,
it doesn't need to be stored inside a revision control system.
Instead, you probably want an alternative method for sharing such a
file. Git is primarily about tracking changes over time to a
collection of files in a project. It's also somewhat about sharing
this history to other people, but I wouldn't say that is its primary
goal.

In either case, you could instead use an alternative mechanism for
sharing the large binary file and have people grab the file this way.
However, it is incredibly valuable to share the history of a file so
that the other users can see what changed or make sure that the
version they are using works with the version of the other sources
they have.

In the case of binary files, you might want to use alternative diff
drivers to compare changes more easily, or instead provide some
non-binary data that is used to generate the binary files (such as
source code).

The whole point of revision history is to show that "hey this used to
have a wrong pixel, and now we fixed it, and here's how we did it".
Maybe the "wrong" pixel was actually correct and you find out later
that you need to revert this change. But the "later" is many months
and you no longer have the exact change so you're using memory or
external data to determine what to change again instead of the actual
history of a file.

Thanks,
Jake