On Sun, Sep 16, 2018 at 03:15:20AM -0700, David Aguilar wrote:
> On Thu, Feb 02, 2017 at 03:26:56AM +0100, Jeff King wrote:
> >
> > - Commands like "git-foo" (so you run "git foo") are generally OK.
> > This is Git's well-known extension mechanism, so it doesn't really
> > imply
On Sun, Sep 16, 2018 at 08:39:03AM +0200, Duy Nguyen wrote:
> On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote:
> > * jn/gc-auto (2018-07-17) 3 commits
> > - gc: do not return error for prior errors in daemonized mode
> > - gc: exit with status 128 on failure
> > - gc: improve handling
On Mon, Sep 17, 2018 at 03:27:21AM +0200, Chris Coutinho wrote:
> On Sep-16-18, Jonathan Nieder wrote:
>> Chris Coutinho wrote:
>>> Currently my gitconfig contains the following line:
>>>
>>> sendemail.smtpserveroption=-a
>>>
>>> Whereas, the following results in an 'account' not found error:
The following:
git add -u :\(glob,attr:-someAttr\):src/**
Produces an error that, according to the source code, should never be visible
to the user. This attribute/pathspec *should* be supported according to the
documentation provided by git:
fatal: BUG:builtin/add.c:498: unsupported magic 40
On Sep-16-18, Jonathan Nieder wrote:
Hi,
Chris Coutinho wrote:
Currently my gitconfig contains the following line:
sendemail.smtpserveroption=-a
Whereas, the following results in an 'account' not found error:
sendemail.smtpserveroption=-a
Do you mean that your
Hi,
Chris Coutinho wrote:
> Currently my gitconfig contains the following line:
>
> sendemail.smtpserveroption=-a
>
> Whereas, the following results in an 'account' not found error:
>
> sendemail.smtpserveroption=-a
Do you mean that your ~/.gitconfig literally contains that exact
Hello Git community,
To send a formatted git patch as an email using git I use `git
send-email`. Using another email address than my default one requires
the 'smtp-server-option' to be set, and currently this flag doesn't care
much for spaces. Is this desired?
Currently my gitconfig
Hi,
On Sun, Sep 16, 2018 at 11:17:27AM -0700, John Austin wrote:
> Taylor Blau wrote:
>> Right, though this still subjects the remote copy to all of the
>> difficulty of packing large objects (though Christian's work to support
>> other object database implementations would go a long way to help
Thanks for all the thoughts so far -- I'm going to try to collate some
of my responses to avoid this getting too lengthy.
## Regarding Merging / Diffing
A couple of folks have suggested that we could improve merging /
diffing of binary files in general. I think this is useful, but can
only ever
Dear Supplier,
We wish to make some purchase from your company.We need assurance
that good quality of this items would be delivered to us after
you receive our order.Please get back to us with the following
information's.
1. Price list..
2. Payment terms.
3. Specified delivery date
> Right, though this still subjects the remote copy to all of the
> difficulty of packing large objects (though Christian's work to support
> other object database implementations would go a long way to help this).
Ah, interesting -- I didn't realize this step was part of the
bottleneck. I
On Sun, Sep 16 2018, Duy Nguyen wrote:
> On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote:
>> * jn/gc-auto (2018-07-17) 3 commits
>> - gc: do not return error for prior errors in daemonized mode
>> - gc: exit with status 128 on failure
>> - gc: improve handling of errors reading gc.log
On Sat, Sep 15 2018, Taylor Blau wrote:
> On Fri, Sep 14, 2018 at 02:09:12PM -0700, John Austin wrote:
>> I've been working myself on strategies for handling binary conflicts,
>> and particularly how to do it in a git-friendly way (ie. avoiding as
>> much centralization as possible and playing
--
join the Illuminati secret brotherhood and get $3,000,000.00
--
join the Illuminati secret brotherhood and get $3,000,000.00
On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote:
> * bc/hash-independent-tests (2018-09-13) 12 commits
> - t5318: use test_oid for HASH_LEN
> - t1407: make hash size independent
> - t1406: make hash-size independent
> - t1405: make hash size independent
> - t1400: switch
--
Hi friend
I am a banker in ADB BANK. I want to transfer an abandoned sum of
USD15.6Million to your Bank account. 40/percent will be your share.
No risk involved but keeps it as secret. Contact me for more details.
Please reply me through my alternative email id only (salif.musa...@gmail.com)
Hi Peff,
On Thu, Feb 02, 2017 at 03:26:56AM +0100, Jeff King wrote:
>
> - Commands like "git-foo" (so you run "git foo") are generally OK.
> This is Git's well-known extension mechanism, so it doesn't really
> imply endorsement (on the other hand, you do not get to complain if
>
On Fri, Sep 14, 2018 at 02:13:28PM -0700, John Austin wrote:
> Hey Taylor,
>
> Great to have your support! I think LFS has done a great job so far
> solving the large file issue. I've been working myself on strategies
> for handling binary conflicts, and particularly how to do it in a
>
Introduce a testing suite that is dedicated to aliases.
For now, check only if nested aliases work and if looping
aliases are detected successfully.
The looping aliases check for mixed execution is there but
disabled, because it is blocking the test suite for a full
minute. As soon as there is a
Just printing the command that the user entered is not particularly
helpful when trying to find the alias that causes the loop.
Print the history of substituted commands to help the user find the
offending alias. Mark the entrypoint of the loop with "<==" and the
last command (which looped back
Aliases can only contain non-alias git commands and their
arguments, not other user-defined aliases. Resolving further
(nested) aliases is prevented by breaking the loop after the
first alias was processed. Git then fails with a command-not-found
error.
Allow resolving nested aliases by not
On 08.09.18 15:28, Duy Nguyen wrote:
On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
+ /*
+* It could be an alias -- this works around the insanity
* of overriding "git log" with "git show" by having
* alias.log = show
On Fri, Sep 14, 2018 at 7:12 PM Tim Schumacher wrote:
> This is the first multi-patch series that I submitted, so I'm unsure if I
> should send the updated patch only or if I should send the complete series
> again as v5. Any pointers to what the correct procedure for this case is would
> be
On Fri, Sep 14, 2018 at 7:29 PM Ramsay Jones
wrote:
> At one time, the POSIX standard required the type used to represent
> a thread handle (pthread_t) be an arithmetic type. This is no longer
> the case, probably because different platforms used to regularly
> ignore that requirement. For
On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus wrote:
> Looks like the issue appeared after updating git from brew.
>
> A quick search revealed that brew changed how it builds git recently.
> I think, it just didn't include i18n by default before, so I never
> noticed this.
>
> Anybody here familiar
On Fri, Sep 7, 2018 at 8:30 PM Ævar Arnfjörð Bjarmason wrote:
> @@ -989,11 +990,14 @@ int verify_commit_graph(struct repository *r, struct
> commit_graph *g)
> if (verify_commit_graph_error & ~VERIFY_COMMIT_GRAPH_ERROR_HASH)
> return verify_commit_graph_error;
>
> +
ATENÇÃO;
Sua caixa de correio excedeu o limite de armazenamento, que é de 5 GB como
definido pelo administrador, que está atualmente em execução no 10.9GB, você
pode não ser capaz de enviar ou receber novas mensagens até que você re-validar
a sua caixa de correio. Para revalidar sua caixa de
On Fri, Sep 14, 2018 at 11:56 PM Junio C Hamano wrote:
> * jn/gc-auto (2018-07-17) 3 commits
> - gc: do not return error for prior errors in daemonized mode
> - gc: exit with status 128 on failure
> - gc: improve handling of errors reading gc.log
>
> "gc --auto" ended up calling exit(-1) upon
This is about mixing "git add -p" and "git commit -a" (or "git commit
") where you may accidentally lose staged changes. After the
discussion with Jonathan, I'm going with a bit different approach than
v1, this behavior now becomes default, and if the user wants the old
behavior back, they can use
"git commit" can be used in two different workflows:
- the user never bothers with "git add" and uses "git commit" for
both adding content to the index and committing it
- the user uses "git add" to carefully prepare what they want to
commit, and "git commit" creates a new commit out of
On Wed, Aug 29, 2018 at 09:18:38AM +0200, H.Merijn Brand wrote:
> On Tue, 28 Aug 2018 12:37:40 -0700, Junio C Hamano
> wrote:
>
> > "H.Merijn Brand" writes:
> >
> > > So, my wish would be to have an option, possibly using -- to pass
> > > additional command line arguments to git difftool, so
32 matches
Mail list logo
