Dear customer,
We offer a loan on 3.5 APR, same day approval- For more information email us at
-edward.henry.garn...@gmail.com
We would like to finance your project, business loans and consolidation are all
type of application are Welcome. We also do the financing of the car and the
mort
On Sat, Oct 28, 2017 at 6:22 PM, Junio C Hamano wrote:
>> Some thoughts:
>> * We may want to do a follow on patch to convert all the flags from being in
>>uppercase to lower case.
>
> If and only if we do not use macros to set/clr/test, this makes a
> lot of sense. Otherwise, probably not.
Junio C Hamano writes:
> I wonder how fast "git diff-index --cached -r HEAD --", with the
> same pathspec used for the problematic "git rm", runs in this same
> 50,000 path project.
>
> If it runs in a reasonable time, one easy way out may be to revamp
> the codepath to call check_local_mod() t
Stefan Beller writes:
> On Sat, Oct 28, 2017 at 8:22 PM, Stefan Beller wrote:
>
>>
>> (Not making excuses, but...) I remembered some other senior members
>> having such commit messages, so I felt like I had to step up my game.
>>
>> https://public-inbox.org/git/70fbcd573f5c8a78a19a08ffc255437c36
On Sat, Oct 28, 2017 at 10:32 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Fri, 27 Oct 2017, Stefan Beller wrote:
>
>> Sometimes users are given a hash of an object and they want to identify
>> it further (ex.: Use verify-pack to find the largest blobs, but what are
>> these? or [1])
>>
>> T
On Sat, Oct 28, 2017 at 8:22 PM, Stefan Beller wrote:
>
> (Not making excuses, but...) I remembered some other senior members
> having such commit messages, so I felt like I had to step up my game.
>
> https://public-inbox.org/git/70fbcd573f5c8a78a19a08ffc255437c36e7f49d.1495014840.git.mhag...@al
On Sat, Oct 28, 2017 at 10:20 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Fri, 27 Oct 2017, Stefan Beller wrote:
>
>> This will be useful shortly.
>
> Something tells me that I will hate you in the future when I read this
> commit message and lack the context (e.g. when blaming, where I can
On Sat, Oct 28, 2017 at 10:15 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> [I was intrigued enough by your work to postpone to later this coming week
> reading the What's cooking email in favor of reviewing your patch series.]
>
> On Fri, 27 Oct 2017, Stefan Beller wrote:
>
>> With traverse_tre
Hi Junio,
Please pull this last time l10n update for Git 2.15.0. It contains
squash merge of
[PR#267][1] and [PR#268][2].
The following changes since commit 1165e3c317b51a3f47afe1a5762b92cac695fe5c:
Merge branch 'jx/zh_CN-proposed' of github.com:jiangxin/git
(2017-10-24 10:11:48 +0800)
are av
Brandon Williams writes:
> We have have reached the limit of the number of flags that can be stored
s/have have/have/; but bit #9 is unused.
"We cannot add many more flags even if we wanted to" would be more
flexible and does not take this change hostage to whatever topic
that tries to claim
On Sat, Oct 28, 2017 at 2:12 PM, brian m. carlson
wrote:
> In future versions of Git, we plan to support an additional hash
> algorithm. Integrate the enumeration of hash algorithms with repository
> setup, and store a pointer to the enumerated data in struct repository.
> Of course, we currently
On Sat, Oct 28, 2017 at 2:12 PM, brian m. carlson
wrote:
> Since in the future we want to support an additional hash algorithm, add
> a structure that represents a hash algorithm and all the data that must
> go along with it. Add a constant to allow easy enumeration of hash
> algorithms. Impleme
Brandon Williams writes:
> Instead of explicitly setting the 'DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG'
> flag, use the 'DIFF_OPT_SET' macro.
>
> Signed-off-by: Brandon Williams
> ---
Looks good. It's not like one of 1/3 and 2/3 could be a good idea
while the other is not, so it would make a lot mor
Brandon Williams writes:
> There has be some desire to add additional flags to the diff machineery
> (https://public-inbox.org/git/20171024000931.14814-1-sbel...@google.com/) but
> due to the limits of the number of bits in an unsigned int on some systems we
> can't add any additonal flags to the
"brian m. carlson" writes:
>> Looking at an optimized profile, all the time seems to be spent in
>> “get_tree_entry” — I assume there is some huge object representing the
>> directory which is being re-expanded for each file?
>
> Yes, there's a tree object that represents each directory.
>
>> I
Lars Schneider writes:
> BTW: I am using this little snippet to apply patches from the mailing:
>
> PATCH=$(curl -L --silent
> https://public-inbox.org/git/xmqqr2tpcn6g@gitster.mtv.corp.google.com/raw);
>
> ((printf '%s' "$PATCH" | git am -3) || (git am --abort; printf '%s'
> "$PA
"brian m. carlson" writes:
> There is discussion in the Austin Group issue tracker about adding this
> feature to POSIX, but it's gotten bogged down over lexical versus
> dynamic scoping. Everyone agrees that it's a desirable feature, though.
> ...
In short, unless you are a binary packager on
From: "Brandon Williams"
Sent: Friday, October 20, 2017 6:18 PM
Objective
===
Replace Git's current wire protocol with a simpler, less wasteful
protocol that can evolve over time.
Capability Advertisement
--
A server which decides to communicate (based on
On Sat, Oct 28, 2017 at 10:32 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
>
> Nicely done, sir!
>
> I wonder whether it would make sense to extend this to tree objects while
> we are at it, but maybe that's an easy up-for-grabs.
>
> Thank you very much!
> Dscho
I'd very much like the same abili
On Sat, Oct 28, 2017 at 9:00 AM, Johannes Schindelin
wrote:
> Hi Jake,
>
> On Fri, 27 Oct 2017, Jacob Keller wrote:
>
>> From: Jacob Keller
>>
>> I noticed a failure with git rebase interactive mode which causes "exec"
>> commands to be run with GIT_DIR set. When GIT_DIR is in the environment,
>>
On Sat, Oct 28, 2017 at 05:02:02PM +, Christopher Jefferson wrote:
> I stupidly added a directory with many files ( ~450,000 ) to git, and want to
> delete them — later I plan to rebase/squash various commits to remove the
> files from the history altogether.
>
> However, ‘git rm’ is VERY sl
I stupidly added a directory with many files ( ~450,000 ) to git, and want to
delete them — later I plan to rebase/squash various commits to remove the files
from the history altogether.
However, ‘git rm’ is VERY slow. For example, in a directory with 10,000 files
(on a Mac), git v2.14.2
Git a
This is a series proposing a basic abstraction for hash functions.
As we get closer to converting the remainder of the codebase to use
struct object_id, we should think about the design we want our hash
function abstraction to take. This series is a proposal for one idea.
Input on any aspect of t
Switch the uses of empty_tree_oid and empty_blob_oid to use the
current_hash abstraction that represents the current hash algorithm in
use.
Signed-off-by: brian m. carlson
---
builtin/am.c | 2 +-
builtin/checkout.c | 2 +-
builtin/diff.c | 2 +-
builtin/pull.c | 2 +-
cache.h
In future versions of Git, we plan to support an additional hash
algorithm. Integrate the enumeration of hash algorithms with repository
setup, and store a pointer to the enumerated data in struct repository.
Of course, we currently only support SHA-1, so hard-code this value in
read_repository_fo
We enumerate several different items as part of struct
repository_format, but then actually set up those values using the
global variables we've initialized from them. Instead, let's pass a
pointer to the structure down to the code where we enumerate these
values, so we can later on use those valu
Since in the future we want to support an additional hash algorithm, add
a structure that represents a hash algorithm and all the data that must
go along with it. Add a constant to allow easy enumeration of hash
algorithms. Implement function typedefs to create an abstract API that
can be used by
Hello,
Did you received my previous message?
Regards.
From: "Philip Oakley"
From: "Sergey Organov"
Is there anything like this:
$ git merge b
[... lot of conflicts ...]
$ git re-merge -X ours -- x/ # Leaves 0 conflicts in x/
$ git re-merge -X theirs -- y/ # Leaves 0 conflicts in y/
[... resolve the rest of conflicts manually ...]
$ git commit
From: "Sergey Organov"
Is there anything like this:
$ git merge b
[... lot of conflicts ...]
$ git re-merge -X ours -- x/ # Leaves 0 conflicts in x/
$ git re-merge -X theirs -- y/ # Leaves 0 conflicts in y/
[... resolve the rest of conflicts manually ...]
$ git commit
[*] I do mean '-X' abov
Hi Stefan,
On Fri, 27 Oct 2017, Stefan Beller wrote:
> Sometimes users are given a hash of an object and they want to identify
> it further (ex.: Use verify-pack to find the largest blobs, but what are
> these? or [1])
>
> The best identification of a blob hash is done via a its path at a
> give
Hi Stefan,
On Fri, 27 Oct 2017, Stefan Beller wrote:
> This will be useful shortly.
Something tells me that I will hate you in the future when I read this
commit message and lack the context (e.g. when blaming, where I cannot see
the child commits let alone the comment in the Merge commit).
How
On Thu, Oct 26, 2017 at 02:33:37PM -0700, Jonathan Nieder wrote:
> Now I'm even more curious.
>
> I don't think we have the full picture to understand whether this
> change is needed. When adding a configuration item, we need to be
> able to explain to users what the configuration item is for, an
Hi Stefan,
[I was intrigued enough by your work to postpone to later this coming week
reading the What's cooking email in favor of reviewing your patch series.]
On Fri, 27 Oct 2017, Stefan Beller wrote:
> With traverse_trees_and_blobs factored out of the main traverse function,
> the next patch
On Fri, 2017-10-27 at 17:32 +0900, Junio C Hamano wrote:
> * jc/branch-name-sanity (2017-10-14) 3 commits
> (merged to 'next' on 2017-10-16 at 174646d1c3)
> + branch: forbid refs/heads/HEAD
> + branch: split validate_new_branchname() into two
> + branch: streamline "attr_only" handling in vali
I just noticed this recently while trying to see if a recent change [1]
that disallowed the possibility of creating HEAD also allowed renaming
branches named "HEAD" that were created using previous versions that
allowed it. Unfortunately (or fortunately (?)), I was in the middle of
an interactive r
> On 28 Oct 2017, at 18:40, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Fri, 27 Oct 2017, Lars Schneider wrote:
>
>>> On 27 Oct 2017, at 14:11, Lars Schneider wrote:
>>>
On 21 Oct 2017, at 00:22, Johannes Schindelin
wrote:
[cutting linux-kernel]
On Fri
On Wed, Oct 25, 2017 at 11:32:51PM -0700, Jeff King wrote:
> On Wed, Oct 25, 2017 at 10:03:09AM +0200, Michael Haggerty wrote:
>
> > > Yeah. It's supported by dash and many other shells, but we do try to
> > > avoid it[1]. I think in this case we could just drop it (but keep
> > > setting the "loc
Hi Lars,
On Fri, 27 Oct 2017, Lars Schneider wrote:
> > On 27 Oct 2017, at 14:11, Lars Schneider wrote:
> >
> >> On 21 Oct 2017, at 00:22, Johannes Schindelin
> >> wrote:
> >>
> >> [cutting linux-kernel]
> >>
> >> On Fri, 20 Oct 2017, Junio C Hamano wrote:
> >>
> >>> A release candidate Gi
Hi Stefan,
On Fri, 27 Oct 2017, Stefan Beller wrote:
> Occasionally a user is given an object hash from a blob as an error message
> or other output (e.g. [1]).
>
> It would be useful to get a further description of such a blob, such as
> the (commit, path) tuple where this blob was introduced.
Hi Jake,
On Fri, 27 Oct 2017, Jacob Keller wrote:
> From: Jacob Keller
>
> I noticed a failure with git rebase interactive mode which causes "exec"
> commands to be run with GIT_DIR set. When GIT_DIR is in the environment,
> then any command which results in running a git command in
> a subdire
On 28 October 2017 at 22:21, Kevin Daudt wrote:
>
> On Sat, Oct 28, 2017 at 08:04:40PM +0800, Anthony Wong wrote:
> > When cherry-picking from a commit whose commit message already
> > contains the "(cherry picked from commit ...)" line, this option will
> > not add another one. This is useful whe
> On 27 Oct 2017, at 04:57, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> It is fine to leave the original code broken at this step while we
>> purely move the lines around, and hopefully this will be corrected
>> in a later step in the series (I am responding as I read on, so I do
>>
Hi Jason,
On 28/10/2017 14:49, Jason Pyeron wrote:
> I would like to efficiently backup my project directories.
>
> I am thinking that the backup of a git enabled project should only backup the
> following sets of files:
>
> Files under .git/
> The results of git clean -ndx
> The results of git
On Sat, Oct 28, 2017 at 08:04:40PM +0800, Anthony Wong wrote:
> When cherry-picking from a commit whose commit message already
> contains the "(cherry picked from commit ...)" line, this option will
> not add another one. This is useful when you are cherry-picking from a
> bunch of commits, some ar
I would like to efficiently backup my project directories.
I am thinking that the backup of a git enabled project should only backup the
following sets of files:
Files under .git/
The results of git clean -ndx
The results of git status
Does this make sense? Is there a less expensive way to calc
When cherry-picking from a commit whose commit message already
contains the "(cherry picked from commit ...)" line, this option will
not add another one. This is useful when you are cherry-picking from a
bunch of commits, some are cherry-picks and already contains the
upstream hash but some do not.
git rm doesn't seem to be very useful without the use of shell
wildcards, especially with the use of a .gitignore file. If a .gitignore
file is used, the git rm command does not consider the .gitignore file,
and errs out when an ignored file is present.
In my opinion, git rm should take .gitig
Underscores are cheap, and help readability.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 71e088e811..bb10b715a8 100644
--- a/refs/files-backend.c
Nothing earth-shattering here; just cleaning up some internal details
that have bothered me for a while:
* Make it clearer which flag values the packed backend might confront.
* Reduce the visibility of the constants that are only relevant to the
files backend. The most notable of these is `REF
The files backend uses `ref_update::flags` for several internal flags.
But those flags have no meaning to the packed backend. So when adding
updates for the packed-refs transaction, only use flags that make
sense to the packed backend.
`REF_NODEREF` is part of the public interface, and it's logica
Even after working with this code for years, I still see this constant
name as "ref node ref". Rename it to make it's meaning clearer.
Signed-off-by: Michael Haggerty
---
builtin/am.c | 2 +-
builtin/branch.c | 2 +-
builtin/checkout.c | 2 +-
builtin/clone.c| 4 +
The constants used for `ref_update::flags` were rather disorganized:
* The definitions in `refs.h` were not close to the functions that
used them.
* Maybe constants were defined in `refs-internal.h`, making them
visible to the whole refs module, when in fact they only made sense
for the fil
`prune_ref()` needs to use the `REF_ISPRUNING` flag, but we want to
make that flag private to the files backend. So instead of calling
`ref_transaction_delete()`, which is a public function and therefore
shouldn't allow the `REF_ISPRUNING` flag, change `prune_ref()` to call
`ref_transaction_add_upd
We want to make `REF_ISPRUNING` internal to the files backend. For
this to be possible, `ref_transaction_add_update()` mustn't know about
it. So move the check that `REF_ISPRUNING` is only used with
`REF_NODEREF` from this function to `files_transaction_prepare()`.
Signed-off-by: Michael Haggerty
Callers shouldn't be passing disallowed flags into
`ref_transaction_update()`. So instead of masking them off, treat it
as a bug if any are set.
Signed-off-by: Michael Haggerty
---
refs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 62a7621025..7c1e
There is no need to rewrite the `packed-refs` file except for the case
that we are deleting a reference that has a packed version. Verify
that `packed-refs` is not rewritten when it shouldn't be.
In fact, two of these tests fail:
* A new (empty) `packed-refs` file is created when deleting any loo
This reroll make some logically small changes to v1 [1] that are
textually very big:
* Invert the sense of `is_packed_transaction_noop()` and rename it to
`is_packed_transaction_needed()`. This makes the logic easier to
follow and document.
* Add a big comment to that function, describing the
Even when we are deleting references, we needn't overwrite the
`packed-refs` file if the references that we are deleting only exist
as loose references. Implement this optimization as follows:
* Add a function `is_packed_transaction_needed()`, which checks
whether a given packed-refs transaction
On Fri, Oct 27 2017, Joe Perches jotted:
> On Sat, 2017-10-28 at 00:11 +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Oct 27 2017, Joe Perches jotted:
> []
>> > git grep performance has already been
>> > quite successfully improved.
>>
>> ...and I have WIP patches to use the PCRE engine for pat
60 matches
Mail list logo
