Hi,
In the past few months have noticed some confusing behavior with
ignored submodules. I finally got around to bisecting this to commit
5556808690ea245708fb80383be5c1afee2fb3eb (add, reset: ensure
submodules can be added or reset).
Here is a demonstration of the problem:
First some repository
From: David Pursehouse
Fixes a minor typo in the merge-strategies documentation.
David Pursehouse (1):
Fix typo in merge-strategies documentation
Documentation/merge-strategies.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.16.2
From: David Pursehouse
Signed-off-by: David Pursehouse
---
Documentation/merge-strategies.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/merge-strategies.txt
b/Documentation/merge-strategies.txt
index
Hi Sergey,
On 16/03/2018 08:31, Sergey Organov wrote:
>
> > > As I said, putting myself on the user side, I'd prefer entirely
> > > separate first step of the algorithm, exactly as written, with
> > > its own conflict resolution, all running entirely the same way as
> > > it does with non-merge
On 15/03/2018 00:11, Igor Djordjevic wrote:
>
> > > > Second side note: if we can fast-forward, currently we prefer
> > > > that, and I think we should keep that behavior with -R, too.
> > >
> > > I agree.
> >
> > I'm admittedly somewhat lost in the discussion, but are you
> > talking
Jonathan Nieder writes:
>> I was hoping to hear quick Acks for remove-ignore-env (and also
>> Duy's reroll of their topics on it) from people involved in all the
>> related topics, so that we can advance them more-or-less at the same
>> time.
>
> I can go along with this for
--
I am Aisha Gaddafi, I have a business proposal for you and I need your
Mutual Respect, Trust, Honesty & Transparency,kind support and
assistance. This business is hitch free and i assure you that you are
100% safe.Contact me For more info,.
Sincerely,
Aisha.
--
Roger Solano writes:
> patch for too chatty command when is invalid
> ex. git tag --contains
>
> It is possible to skip 'goto show_usage_error' when
> parse_long_opt fails? and return directly from there.
Can you explain how this relates to and/or compares with a recent
On Fri, Mar 16 2018, Jeff King jotted:
> I really like the idea of being able to send our machine-readable output
> in some "standard" syntax for which people may already have parsers. But
> one big hangup with JSON is that it assumes all strings are UTF-8.
FWIW It's not UTF-8 but "Unicode
An earlier change bba067d2 ("stash: don't delete untracked files
that match pathspec", 2018-01-06) was made by taking a suggestion in
a list discussion [1] but did not copy the suggested snippet
correctly. And the bug was unnoticed during the review and slipped
through.
This fixes it.
[1]
Here is a preliminary fix for an earlier copy-pasto, plus two
patches from your v3.
I tried to reduce the nesting level by swapping the order of if/elif
chain; please double check the logic to ensure I didn't make stupid
mistakes while doing so.
Junio C Hamano (1):
stash: fix nonsense pipeline
From: Thomas Gummerer
When introducing the stash push feature, and thus allowing users to pass
in a pathspec to limit the files that would get stashed in
df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor
pathspec", 2017-02-28), this developer missed one place
From: Thomas Gummerer
'git stash push -u -- ' prints the following errors if
only matches untracked files:
fatal: pathspec 'untracked' did not match any files
error: unrecognized input
This is because we first clean up the untracked files using 'git clean
', and
patch for too chatty command when is invalid
ex. git tag --contains
It is possible to skip 'goto show_usage_error' when
parse_long_opt fails? and return directly from there.
Signed-off-by: Roger Solano
---
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1
Todd Zullinger writes:
> Document changes to core and non-core Perl module handling in 2.17.
> ...
> Maybe something like this? I had intended to suggest a note about
> NO_PERL_CPAN_FALLBACKS as well, so that's included too.
Thanks. A help like this in individual areas from
I wrote:
> Document changes to core and non-core Perl module handling in 2.17.
This should have:
Signed-off-by: Todd Zullinger
And perhaps also:
Helped-by: Junio C Hamano
since I borrowed liberally from your initial text. :)
> ---
> Junio C Hamano
Document changes to core and non-core Perl module handling in 2.17.
---
Junio C Hamano writes:
>> I haven't wordsmithed it fully, but it should say something along
>> the lines of ...
>>
>> Documentation/RelNotes/2.16.0.txt | 10 ++
>> 1 file changed, 10 insertions(+)
Hi,
Junio C Hamano wrote:
> Jonathan Tan writes:
>> On Wed, 14 Mar 2018 18:34:49 -0700
>> Junio C Hamano wrote:
>>> * sb/object-store (2018-03-05) 27 commits
>>
>> [snip list of commits]
>>
>>> (this branch is used by sb/packfiles-in-repository;
Jonathan Tan writes:
> On Wed, 14 Mar 2018 18:34:49 -0700
> Junio C Hamano wrote:
>
>> * sb/object-store (2018-03-05) 27 commits
>
> [snip list of commits]
>
>> (this branch is used by sb/packfiles-in-repository; uses
>>
On Fri, Mar 16, 2018 at 5:33 PM, Thomas Gummerer wrote:
> Subject: [PATCH] SubmittingPatches: mention the git contacts command
>
> Instead of just mentioning 'git blame' and 'git shortlog', which make
> it harder than necessary for new contributors to pick out the
>
Nguyễn Thái Ngọc Duy writes:
> For reviewers, a couple fewer lines from diffstat (either cover letter
> or patches) is a good thing because there's less to read.
I can certainly accept that there may be some reviewers who share
that view, but me personally, I would rather
Junio C Hamano writes:
> Also, don't we want to use uintmax_t throughout the callchain? How
> would the code in this series work when your ulong is 32-bit?
My own answer to this question is "no conversion to uintmax_t, at
least not in this series." As long as the original
On Wed, 14 Mar 2018 18:34:49 -0700
Junio C Hamano wrote:
> * sb/object-store (2018-03-05) 27 commits
[snip list of commits]
> (this branch is used by sb/packfiles-in-repository; uses
> nd/remove-ignore-env-field.)
>
> Refactoring the internal global data structure to
Thomas Gummerer writes:
> @@ -322,9 +322,12 @@ push_stash () {
>
> if test $# != 0
> then
> - git add -u -- "$@" |
> - git checkout-index -z --force --stdin
This obviously is not something this patch
On 03/08, Eddy Petrișor wrote:
> 2018-03-06 22:21 GMT+02:00 Jonathan Nieder :
> >
> > (cc list snipped)
> > Hi,
> >
> > Eddy Petrișor wrote:
> >
> > > Cc: [a lot of people]
> >
> > Can you say a little about how this cc list was created? E.g. should
> > "git send-email" get a
On Fri, Mar 16, 2018 at 09:01:42PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Suggestion for a thing to add to it, I don't have the time on the Go
> tuits:
>
> One thing that can make repositories very pathological is if the ratio
> of trees to commits is too low.
>
> I was dealing with a repo the
On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted:
> struct option builtin_gc_options[] = {
> OPT__QUIET(, N_("suppress progress reporting")),
> @@ -362,6 +390,8 @@ int cmd_gc(int argc, const char **argv, const char
> *prefix)
> OPT_BOOL(0, "aggressive", ,
On Fri, Mar 16, 2018 at 08:33:55PM +0100, Nguyễn Thái Ngọc Duy wrote:
> We have DEVELOPER config to enable more warnings, but since we can't set
> a fixed gcc version to all devs, that has to be a bit more conservative.
> On travis, we know almost exact version to be used (bumped to 6.x for
>
On Fri, Mar 16, 2018 at 2:01 PM, Briggs, John wrote:
> No, it was a fresh install. Plus file search reveals only one copy of the
> file.
>
> I also noticed that I cannot use the file properties to run as administrator.
> I must right-click on Git GUI and select "More >>
On Fri, Mar 16, 2018 at 07:40:55PM +, g...@jeffhostetler.com wrote:
> This patch series adds a set of utility routines to compose data in JSON
> format into a "struct strbuf". The resulting string can then be output
> by commands wanting to support a JSON output format.
>
> This is a stand
On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted:
> + struct packed_git * p = find_base_packs(_pack, 0);
Style nit: space after "*".
On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted:
> This config allows us to keep packs back if their size is larger
> than a limit. But if this N >= gc.autoPackLimit, we may have a
> problem. We are supposed to reduce the number of packs after a
> threshold because it affects performance.
>
>
On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted:
> +--keep-base-pack::
> + All packs except the base pack and those marked with a `.keep`
> + files are consolidated into a single pack. The largest pack is
> + considered the base pack.
> +
I wonder if all of this would be less
On Fri, Mar 16 2018, Nguyễn Thái Ngọc Duy jotted:
Awesome, thanks for making this support N large packs.
> +gc.bigPackThreshold::
> + If non-zero, all packs larger than this limit are kept when
> + `git gc` is run. This is very similar to `--keep-base-pack`
> + except that all packs
Nguyễn Thái Ngọc Duy writes:
> Previous patches leave lots of holes and padding in this struct. This
> patch reorders the members and shrinks the struct down to 80 bytes
> (from 136 bytes, before any field shrinking is done) with 16 bits to
> spare (and a couple more in
No, it was a fresh install. Plus file search reveals only one copy of the file.
I also noticed that I cannot use the file properties to run as administrator. I
must right-click on Git GUI and select "More >> Run as administrator" in the
start menu. Even though I have "run as administrator"
Nguyễn Thái Ngọc Duy writes:
> These delta pointers always point to elements in the objects[] array
> in packing_data struct. We can only hold maximum 4GB of those objects
4GB, as in "number of bytes"? Or "We can hold 4 billion or so of
those objects"?
> because the array
Briggs, John wrote:
> Jonathan Nieder wrote:
>> Briggs, John wrote:
>>> I just installed git for windows 10 and am getting "git-gui: fatal
>>> error" "Cannot parse Git version string.
>>>
>>> When I execute "git version" in the command prompt I get Git version
>>> 2.16.2.windows.1
>>>
>>>
On Fri, Mar 16, 2018 at 11:33:55AM -0700, Junio C Hamano wrote:
> It is not so surprising that history walking runs rings around
> enumerating objects in packfiles, if packfiles are built well.
>
> A well-built packfile tends to has newer objects in base form and
> has delta that goes in
Nguyễn Thái Ngọc Duy writes:
> An extra field type_valid is added to carry the equivalent of OBJ_BAD
> in the original "type" field. in_pack_type always contains a valid
> type so we only need 3 bits for it.
> ...
> @@ -1570,7 +1576,7 @@ static void drop_reused_delta(struct
Currently 'git stash push -u -- ' prints the following errors
if only matches untracked files:
fatal: pathspec 'untracked' did not match any files
error: unrecognized input
This is because we first clean up the untracked files using 'git clean
', and then use a command chain involving
When introducing the stash push feature, and thus allowing users to pass
in a pathspec to limit the files that would get stashed in
df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor
pathspec", 2017-02-28), this developer missed one place where the
pathspec should be passed in.
Namely
Thanks Marc for catching the regression I almost introduced and Junio
for the review of the second patch. Here's a re-roll that should fix
the issues of v2.
Interdiff below:
diff --git a/git-stash.sh b/git-stash.sh
index 7a4ec98f6b..dbedc7fb9f 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@
Nguyễn Thái Ngọc Duy writes:
> The role of this comment block becomes more important after we shuffle
> fields around to shrink this struct. It will be much harder to see what
> field is related to what.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
>
Got it figured out. Git gui must be ran as administrator.
John
-Original Message-
From: Jonathan Nieder
Sent: Friday, March 16, 2018 1:58 PM
To: Briggs, John
Cc: git@vger.kernel.org; git-for-wind...@googlegroups.com
Subject: Re: getting fatal
On Fri, Mar 16, 2018 at 04:06:39PM -0400, Jeff King wrote:
> > Furthermore, in order to look at an object it has to be zlib inflated
> > first, and since commit objects tend to be much smaller than trees and
> > especially blobs, there are a lot less bytes to inflate:
> >
> > $ grep ^commit
On Fri, Mar 16, 2018 at 7:33 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> You should forget '--stdin-packs' and use '--stdin-commits' to generate
>> the initial graph, it's much faster even without '--additive'[1]. See
>>
>>
>>
>But for a generic branch like 'master', that arrangement would not
>work well, I am afraid. You may have N copies of the same project,
>where the 'master' branch of each is used to work on separate topic.
>The focus of the 'master' branch of the overall project would be
>quite different from
Nguyễn Thái Ngọc Duy writes:
> It's very very rare that an uncompressd object is larger than 4GB
> (partly because Git does not handle those large files very well to
> begin with). Let's optimize it for the common case where object size
> is smaller than this limit.
>
>
On Fri, Mar 16, 2018 at 8:14 PM, Duy Nguyen wrote:
> On Mon, Mar 12, 2018 at 7:32 PM, Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Tue, Mar 06 2018, Nguyễn Thái Ngọc Duy jotted:
>>
>>> We only show progress when there are new objects to be packed. But
>>> when
On 03/15, Marc Strapetz wrote:
> On 14.03.2018 22:46, Thomas Gummerer wrote:
> >Currently 'git stash push -u -- ' prints the following errors
> >if only matches untracked files:
> >
> > fatal: pathspec 'untracked' did not match any files
> > error: unrecognized input
> >
> >This is
On 03/15, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > no_changes () {
> > git diff-index --quiet --cached HEAD --ignore-submodules -- "$@" &&
> > git diff-files --quiet --ignore-submodules -- "$@" &&
> > - (test -z "$untracked" || test -z
For reviewers, a couple fewer lines from diffstat (either cover letter
or patches) is a good thing because there's less to read.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
I realize that rename percentage is lost with this change. I just
hope that nobody cares about that, or
On Fri, Mar 16, 2018 at 08:48:49PM +0100, SZEDER Gábor wrote:
> I came up with a different explanation back then: we are only interested
> in commit objects when creating the commit graph, and only a small-ish
> fraction of all objects are commit objects, so the "enumerate objects in
> packfiles"
Nguyễn Thái Ngọc Duy writes:
> We only cache deltas when it's smaller than a certain limit. This limit
> defaults to 1000 but save its compressed length in a 64-bit field.
> Shrink that field down to 16 bits, so you can only cache 65kb deltas.
> Larger deltas must be
On Fri, Mar 16 2018, Michael Haggerty jotted:
> What makes a Git repository unwieldy to work with and host? It turns
> out that the respository's on-disk size in gigabytes is only part of
> the story. From our experience at GitHub, repositories cause problems
> because of poor internal layout at
From: Jeff Hostetler
This patch series adds a set of utility routines to compose data in JSON
format into a "struct strbuf". The resulting string can then be output
by commands wanting to support a JSON output format.
This is a stand alone patch. Nothing currently uses
From: Jeff Hostetler
Add basic routines to generate data in JSON format.
Signed-off-by: Jeff Hostetler
---
Makefile | 1 +
json-writer.c | 224 ++
json-writer.h | 120
From: Jeff Hostetler
Signed-off-by: Jeff Hostetler
---
Makefile| 1 +
t/helper/test-json-writer.c | 146
t/t0019-json-writer.sh | 10 +++
3 files changed, 157 insertions(+)
Hi,
Briggs, John wrote:
> I just installed git for windows 10 and am getting "git-gui: fatal error"
> "Cannot parse Git version string.
>
> When I execute "git version" in the command prompt I get
> Git version 2.16.2.windows.1
>
> Everything else seems to be working. How can I get the gui to
We have DEVELOPER config to enable more warnings, but since we can't set
a fixed gcc version to all devs, that has to be a bit more conservative.
On travis, we know almost exact version to be used (bumped to 6.x for
more warnings), we could be more aggressive.
Signed-off-by: Nguyễn Thái Ngọc Duy
This is not in mergeable state yet. But since there's lots of changes
and I'm pretty sure there's still room for improvement when it comes
to configuration and stuff, I'm posting it anyway to get the
discussion continue.
- --keep-pack does not imply --honor-pack-keep or --pack-kept-objects
This adds a new repack mode that combines everything into a secondary
pack, leaving the largest/base pack alone.
This could help reduce memory pressure. On linux-2.6.git, valgrind
massif reports 1.6GB heap in "pack all" case, and 535MB in "pack
all except the base pack" case. We save roughly 1GB
This config allows us to keep packs back if their size is larger
than a limit. But if this N >= gc.autoPackLimit, we may have a
problem. We are supposed to reduce the number of packs after a
threshold because it affects performance.
We could tell the user that they have incompatible
pack-objects could be a big memory hog especially on large repos,
everybody knows that. The suggestion to stick a .keep file on the
giant base pack to avoid this problem is also known for a long time.
Recent patches add an option to do just this, but it has to be either
configured or activated
The --keep-base-pack option is not very convenient to use because you
need to tell gc to do this explicitly (and probably on just a few
large repos).
Add a config key that enables this mode when packs larger than a
limit are found.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
We only show progress when there are new objects to be packed. But
when --keep-pack is specified on the base pack, we will exclude most
of objects. This makes 'pack-objects' stay silent for a long time
while the counting phase is going.
Let's show some progress whenever we visit an object
We allow to keep existing packs by having companion .keep files. This
is helpful when a pack is permanently kept. In the next patch, git-gc
just wants to keep a pack temporarily, for one pack-objects
run. git-gc can use --keep-pack for this use case.
A note about why the pack_keep field cannot be
This code is mostly about reading object headers, which is cheap. But
when the number of objects is very large (e.g. 6.5M on linux-2.6.git)
and the system is under memory pressure, this could take some time (86
seconds on my system).
Show something during this time to let the user know
On Mon, Mar 12, 2018 at 7:32 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Tue, Mar 06 2018, Nguyễn Thái Ngọc Duy jotted:
>
>> We only show progress when there are new objects to be packed. But
>> when --keep-pack is specified on the base pack, we will exclude most
>> of objects.
I just installed git for windows 10 and am getting "git-gui: fatal error"
"Cannot parse Git version string.
When I execute "git version" in the command prompt I get
Git version 2.16.2.windows.1
Everything else seems to be working. How can I get the gui to work?
John
SZEDER Gábor writes:
> You should forget '--stdin-packs' and use '--stdin-commits' to generate
> the initial graph, it's much faster even without '--additive'[1]. See
>
>
> https://public-inbox.org/git/CAM0VKj=wmkBNH=pscrztxfrc13rig1easw89q6ljansdjde...@mail.gmail.com/
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 3 +++
pack-objects.h | 28 +---
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 13f6a44fb2..09f8b4ef3e
It's very very rare that an uncompressd object is larger than 4GB
(partly because Git does not handle those large files very well to
begin with). Let's optimize it for the common case where object size
is smaller than this limit.
Shrink size field down to 32 bits [1] and one overflow bit. If the
These delta pointers always point to elements in the objects[] array
in packing_data struct. We can only hold maximum 4GB of those objects
because the array length, nr_objects, is uint32_t. We could use
uint32_t indexes to address these elements instead of pointers. On
64-bit architecture (8 bytes
Allowing a delta size of 64 bits is crazy. Shrink this field down to
31 bits with one overflow bit.
If we find an existing delta larger than 2GB, we do not cache
delta_size at all and will get the value from oe_size(), potentially
from disk if it's larger than 4GB.
Signed-off-by: Nguyễn Thái
This field is only need for pack-bitmap, which is an optional
feature. Move it to a separate array that is only allocated when
pack-bitmap is used (it's not freed in the same way that objects[] is
not).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 3 ++-
Instead of using 8 bytes (on 64 bit arch) to store a pointer to a
pack. Use an index instead since the number of packs should be
relatively small.
This limits the number of packs we can handle to 16k. For now if you hit
16k pack files limit, pack-objects will simply fail [1].
[1] The escape
We only cache deltas when it's smaller than a certain limit. This limit
defaults to 1000 but save its compressed length in a 64-bit field.
Shrink that field down to 16 bits, so you can only cache 65kb deltas.
Larger deltas must be recomputed at when the pack is written down.
Signed-off-by: Nguyễn
Previous patches leave lots of holes and padding in this struct. This
patch reorders the members and shrinks the struct down to 80 bytes
(from 136 bytes, before any field shrinking is done) with 16 bits to
spare (and a couple more in in_pack_header_size when we really run out
of bits).
An extra field type_valid is added to carry the equivalent of OBJ_BAD
in the original "type" field. in_pack_type always contains a valid
type so we only need 3 bits for it.
A note about accepting OBJ_NONE as "valid" type. The function
read_object_list_from_stdin() can pass this value [1] and it
Because of struct packing from now on we can only handle max depth
4095 (or even lower when new booleans are added in this struct). This
should be ok since long delta chain will cause significant slow down
anyway.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
The most important change in v4 is it fixes a case where I failed to
propagate an error condition to later code in 02/11. This results in
new wrappers, oe_type() and oe_set_type(). This also reveals another
extra object type, OBJ_NONE, that's also used by pack-objects.
Other changes are comments
The role of this comment block becomes more important after we shuffle
fields around to shrink this struct. It will be much harder to see what
field is related to what.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pack-objects.h | 44
1
On Fri, Mar 16, 2018 at 1:50 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> However, I'm having a tough time imagining cases in which callers
>> would want same_encoding() to return true if both arguments are NULL,
>> but outright crash if only
On Friday 16 March 2018 01:57 AM, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> So... I am not finding dont_fail that was mentioned on the title
> anywhere else in the patch. Such lack of attention to detail is
> a bit off-putting.
>
I'm absolutely sorry x-<
Junio C Hamano writes:
> I haven't wordsmithed it fully, but it should say something along
> the lines of ...
>
> Documentation/RelNotes/2.16.0.txt | 10 ++
> 1 file changed, 10 insertions(+)
Eh, of course the addition should go to 2.17 release notes ;-) I
just
Ævar Arnfjörð Bjarmason writes:
> On Fri, Mar 16 2018, Junio C. Hamano jotted:
>
>> gitweb: hard-depend on the Digest::MD5 5.8 module
>
> I've just noticed this now, but while this module is in 5.8 RedHat's
> butchered perl doesn't have it in the base system, thus this
Eric Sunshine writes:
> However, I'm having a tough time imagining cases in which callers
> would want same_encoding() to return true if both arguments are NULL,
> but outright crash if only one is NULL (which is the behavior even
> before this patch). In other words,
On Thu, Mar 15, 2018 at 8:21 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Mar 15 2018, Duy Nguyen jotted:
>
>> On Mon, Mar 12, 2018 at 8:30 PM, Ævar Arnfjörð Bjarmason
>> wrote:
>>> We already have pack.packSizeLimit, perhaps we could call this
>>> e.g.
Morten Welinder writes:
> You need to cast those arguments of tolower to (unsigned char). That's
> arguably a bug of the language.
Don't we do so in git-compat-util.h already?
You need to cast those arguments of tolower to (unsigned char). That's
arguably a bug of the language.
Character values less than zero aren't valid for tolower, unless they
happen to equal
EOF in which case the tolower calls don't mean what you want them to mean. Per
the man page:
"If c is
On Thu, Mar 15, 2018 at 6:16 PM, Johannes Schindelin
wrote:
> To add some interesting information to this: in MinGit (the light-weight
> "Git for applications" we bundle to avoid adding a hefty 230MB to any
> application that wants to bundle Git for Windows), we simply
What makes a Git repository unwieldy to work with and host? It turns
out that the respository's on-disk size in gigabytes is only part of
the story. From our experience at GitHub, repositories cause problems
because of poor internal layout at least as often as because of their
overall size. For
Johannes Schindelin writes:
>> > Stolee, you definitely want to inspect those changes (`git log --check`
>> > was introduced to show you whitespace problems). If all of those
>> > whitespace issues are unintentional, you can fix them using `git rebase
>> >
On Fri, Mar 16, 2018 at 4:06 PM, Ævar Arnfjörð Bjarmason
wrote:
> I noticed that it takes a *long* time to generate the graph, on a bigger
> repo I have it takes 20 minutes, and this is a repo where repack -A -d
> itself takes 5-8 minutes, probably on the upper end of that with
> On 14 Mar 2018, at 21:43, Junio C Hamano wrote:
>
> Derrick Stolee writes:
>
>> This v6 includes feedback around csum-file.c and the rename of hashclose()
>> to finalize_hashfile(). These are the first two commits of the series, so
>> they could be
On Wed, Mar 14 2018, Derrick Stolee jotted:
> Hopefully this version is ready to merge. I have several follow-up topics
> in mind to submit soon after, including:
I've been doing some preliminary testing of this internally, all good so
far, on a relatively small repo (~100k commits) I was using
On Fri, Mar 16, 2018 at 07:38:07PM +0530, JYOTIK MAYUR wrote:
> i am working on a project that is git hosting website like GitHub. I
> am a student so i don't know much on how to make a website like GitHub
> so could please tell me what can be the appropriate steps to make a
> website like
i am working on a project that is git hosting website like GitHub. I
am a student so i don't know much on how to make a website like GitHub
so could please tell me what can be the appropriate steps to make a
website like that(mostly the server part).
1 - 100 of 119 matches
Mail list logo