Hi, what is the state of this patch?
What else should I do to get it merged into git?
Thanks.
> On 4 Jul 2017, at 11:33, Łukasz Gryglicki wrote:
>
> Some projects require every commit to be signed off.
> Our workflow is to create feature branches and require every commit to
> be signed off. When
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
dete
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 storing a copy
> of th
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
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 will
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
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 when the head changes.
>>> T
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 no
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 keep track of the change
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.
>
It would be fun to create
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 a
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 to find out that
>> much of the information is i
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% opposed to this hack.
It's really very small, see:
* https://github.com/
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 Hamano wrote:
Shaw
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
>>> wrote:
>
>> * What would you think about being extravagant and
+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
>> wrote:
>
> On second thought, the idea of havi
> 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 and does an equivale
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 not get that care - their s
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 is running "git commit --amend" an
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 the original
> source and run t
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 writes:
where `time_sec` is the update
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:
> - efficient lookup b
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 as simply
as t
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 07/10, because of th
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 that it doesn't. If th
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
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 implemente
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 tal
greetings Git
http://rootyu.cn/upload_video.php?note=ex2c7kzp4rz85
madhan_dc
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 show-ref does not se
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 because color isn't pass
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 --porcel
32 matches
Mail list logo
