Hi Junio,
On Wed, 8 Oct 2014, Junio C Hamano wrote:
> Marat Radchenko writes:
>
> > #define DEFAULT_PACKED_GIT_LIMIT \
> > - ((1024L * 1024L) * (sizeof(void*) >= 8 ? 8192 : 256))
> > + ((size_t)(1024L * 1024L) * (sizeof(void*) >= 8 ? 8192 : 256))
>
> 1024 * 1024 * 8192 overflows 32-bit un
On 2014-10-08 17:37, Jess Austin wrote:
> On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen wrote:
>> On 2014-10-08 15:04, Jess Austin wrote:
>>> Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
>>> tells __git_ps1 to display nothing when the current directory is
>>> set (e.g. via .
On Wed, Oct 08, 2014 at 01:02:10PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Marat Radchenko writes:
> >
> >> Signed-off-by: Marat Radchenko
> >> ---
> >> git-compat-util.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/git-compat-util.h b/g
On Wed, Oct 08, 2014 at 12:26:52PM -0700, Junio C Hamano wrote:
> Marat Radchenko writes:
>
> > When crosscompiling, one cannot rely on `uname` from host system.
>
> That may well be true, but is that limited to cross-compiling to
> mingw? Would it be generally true for any cross compilation,
When GIT_EXTERNAL_DIFF is defined and git diff is called with any of the
'ignore whitespace' type command line arguments such as -w, -b or
--ignore-space-at-eol, git diff ignores these flags and invokes
GIT_EXTERNAL_DIFF for each changed file in the diff queue. If the diff
queue contains file(s) wi
On Wed, Oct 08, 2014 at 10:31:33PM -0400, Jeff King wrote:
> I'm still going to report this to the AsciiDoctor folks; they should
> probably be shooting for compatibility with vanilla AsciiDoc.
Please do. I contribute occasionally to Asciidoctor, so I may pick it
up and fix it.
I'm interested in
On Wed, Oct 08, 2014 at 02:50:14PM +0530, Tanay Abhra wrote:
> I think problem lies with show_stash() which just shows the
> diff between working tree and the base tree, it ignores the
> untracked files. A quick and dirty fix can be to just show
> the diff between the untracked files and a NULL c
On Wed, Oct 08, 2014 at 08:46:10PM +, brian m. carlson wrote:
> Neither the AsciiDoc nor the Asciidoctor documentation specify whether
> the same number of delimiter characters must be used to end a block as
> to begin it, although both sets of documentation show exactly matching
> pairs. Asc
On Wed, Oct 08, 2014 at 12:49:54PM -0500, Derek Moore wrote:
> The HTML for the git-log man page is being misrendered on the official site.
>
> See the placehoders list under "format:" in the PRETTY FORMATS
> section.
Thanks for the report. This renders fine locally with asciidoc, but the
git-s
Add the attribute "id" to category headers and project rows in the
web interface. These ids are intended to work as anchors, allowing
links with the fragment component pointing to a given category, which
may be useful when dealing with long project lists.
IDs are generated from the category name a
On Wed, Oct 8, 2014 at 8:00 PM, Marat Radchenko wrote:
> Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.
>
> Signed-off-by: Marat Radchenko
> Acked-by: Eric Faye-Lund
I spell my name with a K, "Erik Faye-Lund".
--
To unsubscribe from this list: send the line "unsubscribe git
On Wed, Oct 8, 2014 at 4:12 PM, Richard Hansen wrote:
>
> On 2014-10-08 15:04, Jess Austin wrote:
> > Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
> > tells __git_ps1 to display nothing when the current directory is
> > set (e.g. via .gitignore) to be ignored by git. In the a
On Wed, Oct 8, 2014 at 1:12 PM, Junio C Hamano wrote:
>
>
> Can you mention that this is abomination limited only to zsh
> somewhere in the log message? Or does bash share the same glitch?
>
> If this is limited to zsh, I wonder if we can take advantage of the
> fact that we have git-completion.b
Software, such as RVM (ruby version manager), may set chpwd functions
that result in an endless loop when cding. chpwd functions should be
ignored.
As I've only seen this so far on ZSH, I'm applying this change only to
the git-completion.zsh overrides.
Signed-off-by: Brandon Turner
---
This app
Software, such as RVM (ruby version manager), may set chpwd functions
that result in an endless loop when cding. chpwd functions should be
ignored.
I have only noticed the RVM bug on ZSH, bash seems unaffected. However
this change seems safe to apply to both bash and zsh as we cannot
control wha
On 2014-10-08 15:04, Jess Austin wrote:
> Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
> tells __git_ps1 to display nothing when the current directory is
> set (e.g. via .gitignore) to be ignored by git. In the absence of
> GIT_PS1_OMITIGNORED this change has no effect.
>
> M
"brian m. carlson" writes:
> Neither the AsciiDoc nor the Asciidoctor documentation specify whether
> the same number of delimiter characters must be used to end a block as
> to begin it, although both sets of documentation show exactly matching
> pairs. AsciiDoc allows mismatches, but AsciiDoct
Neither the AsciiDoc nor the Asciidoctor documentation specify whether
the same number of delimiter characters must be used to end a block as
to begin it, although both sets of documentation show exactly matching
pairs. AsciiDoc allows mismatches, but AsciiDoctor apparently does not.
Adjust the pr
On Wed, Oct 08, 2014 at 01:22:33PM +0200, Richard Hartmann wrote:
> Notwithstanding if the setting is correct, shouldn't rev-parse be
> resilient enough to at least be able to tell if we're in a work tree?
> I understand why `git status` and the like would need to parse the
> full config, but deter
Junio C Hamano writes:
> Marat Radchenko writes:
>
>> Signed-off-by: Marat Radchenko
>> ---
>> git-compat-util.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index b338277..101c9d7 100644
>> --- a/git-compat-util.h
>> +++
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> I do not offhand think of a good example of an variable that we may
>> want to allow overriding but still want to limit its values myself.
>
> I just thought of a semi-realistic use-case : diff.*.{command,textconv}.
>
> One may want to allow per
Marat Radchenko writes:
> When crosscompiling, one cannot rely on `uname` from host system.
That may well be true, but is that limited to cross-compiling to
mingw? Would it be generally true for any cross compilation,
wouldn't it?
What I am wondering is if it is a better solution to make it e
Marat Radchenko writes:
> To ease cross-compilation process, introduce a single variable
> with the prefix to all compiler-related executables.
>
> Define CROSS_COMPILE=foo- if your compiler and binary utilities
> are foo-cc, foo-ar, foo-strip, etc. More specific variables
> override this, so if
Marat Radchenko writes:
> All MinGW flavors have inttypes.h, so just include it.
>
> However, we need to pass -D__USE_MINGW_ANSI_STDIO=1 to select
> GNU-compatible macro definitions on MinGW-W64:
> http://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
>
> As a side-effect, Git no longer builds w
Marat Radchenko writes:
> Subject: Re: [PATCH 07/14] Fix BASIC_LDFLAGS and COMPAT_CFLAGS for 64bit
> MinGW-w64
Please prefix with MinGW: like you did for other changes.
> From: Ray Donnelly
Needs a bit of explanation what breaks without this change. I can
see that unconditional use of USE_3
Marat Radchenko writes:
> This patch series fixes building on modern MinGW and MinGW-W64 (including
> x86_64).
As Dscho explained in a sub-thread, I really do not want to bypass
msysgit folks when dealing with things that relate to Windows, for
at least two reasons:
* I can be a patch monkey
Marat Radchenko writes:
> Signed-off-by: Marat Radchenko
> ---
> git-compat-util.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index b338277..101c9d7 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -474,7 +474,
Introduce a new environmental variable, GIT_PS1_OMITIGNORED, which
tells __git_ps1 to display nothing when the current directory is
set (e.g. via .gitignore) to be ignored by git. In the absence of
GIT_PS1_OMITIGNORED this change has no effect.
Many people manage e.g. dotfiles in their home direct
On 10/8/2014 11:05 PM, Junio C Hamano wrote:
> Richard Hartmann writes:
>
>> So this is not a real bug report, more of a "is this intended this way?"
>> richih@titanium ~/git_test % git rev-parse --is-inside-work-tree
>> error: Malformed value for branch.autosetuprebase
>> fatal: bad config file
Junio C Hamano writes:
> I do not offhand think of a good example of an variable that we may
> want to allow overriding but still want to limit its values myself.
I just thought of a semi-realistic use-case : diff.*.{command,textconv}.
One may want to allow per-project sets of diff drivers, but
When crosscompiling, one cannot rely on `uname` from host system.
Signed-off-by: Marat Radchenko
---
config.mak.uname | 5 +
1 file changed, 5 insertions(+)
diff --git a/config.mak.uname b/config.mak.uname
index 9f7037e..182da50 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -14,6
Signed-off-by: Marat Radchenko
---
git-compat-util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index b338277..101c9d7 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -474,7 +474,7 @@ extern int git_munmap(void *start, size_
This commit touches regcomp.c from Gnulib,
was fixed upstream in 3a4836d1.
This commit also touches poll.c from Gnulib,
was fixed upstream in d295f6c5.
This commit also touches regex_internal.h from Gnulib,
was fixed upstream in 8335a4d6.
Wrt ShellExecute in winansi.c, quoting [1]:
MSDN says
1. Unlike MinGW, MinGW-W64 already provides _ReadWriteBarrier macro,
so don't try to redefine it.
2. MinGW-W64 has a strange definition FORCEINLINE as
extern __inline__ __attribute__((__always_inline__,__gnu_inline__))
'extern' doesn't work together with 'static', so #undef MinGW-W64
To ease cross-compilation process, introduce a single variable
with the prefix to all compiler-related executables.
Define CROSS_COMPILE=foo- if your compiler and binary utilities
are foo-cc, foo-ar, foo-strip, etc. More specific variables
override this, so if you set CC=gcc CROSS_COMPILE=ia64-li
Brandon Turner writes:
> Software, such as RVM (ruby version manager), may set chpwd functions
> that result in an endless loop when cding. chpwd functions should be
> ignored.
>
> Signed-off-by: Brandon Turner
> ---
Can you mention that this is abomination limited only to zsh
somewhere in the
-D__USE_MINGW_ACCESS only affects MinGW and does nothing when
MSVC is used.
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.mak.uname b/config.mak.uname
index a2f380f..20cbdcf 100644
--- a/co
Is it absolutely valid and possible to have cURL in generic
MinGW environment. Building Git without cURL is still possible
by passing NO_CURL=1
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
config.mak.uname | 2 --
1 file changed, 2 deletions(-)
diff --git a/config.mak.uname b/co
This patch series fixes building on modern MinGW and MinGW-W64 (including
x86_64).
*Compilation* tested on:
- MSVC
- msysGit environment (twice)
- Linux cross-toolchain i686-pc-mingw32
- Linux cross-toolchain i686-w64-mingw32
- Linux cross-toolchain x86_64-w64-mingw32
Also, this patchset is
fork() is not used in MinGW builds but causes a compiler warning
on x86_64 MinGW-W64: conflicting types for built-in function 'fork'
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
in
pid_t is available in sys/types.h on both MinGW and MinGW-W64
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 1 -
compat/msvc.h | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 1ddd663..ba05044 100644
---
All MinGW flavors have inttypes.h, so just include it.
However, we need to pass -D__USE_MINGW_ANSI_STDIO=1 to select
GNU-compatible macro definitions on MinGW-W64:
http://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/
As a side-effect, Git no longer builds with MSVC < 2010 due to
its lack of std
From: Ray Donnelly
Signed-off-by: Ray Donnelly
Signed-off-by: Marat Radchenko
---
config.mak.uname | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 324a7fc..4470a928 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -6,
Unlike MinGW, MinGW-W64 has lseek already properly defined in io.h.
Signed-off-by: Marat Radchenko
Acked-by: Eric Faye-Lund
---
compat/mingw.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5e499cf..36a47cb 100644
--- a/compat/mingw.h
+++ b/compat/mi
HAVE_LIBCHARSET_H and NO_R_TO_GCC_LINKER are not specific to
msysGit, they're general MinGW settings.
Logic behind HAVE_LIBCHARSET_H: if user is on MinGW and has iconv,
we expect him to have libcharset.h. If user doesn't have iconv,
he has to explicitly say so via NO_ICONV=1 regardless of this
com
Unlike MinGW, MinGW-W64 has CONSOLE_FONT_INFOEX already properly defined
in wincon.h.
Signed-off-by: Marat Radchenko
---
compat/winansi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/winansi.c b/compat/winansi.c
index efc5bb3..0ac3297 100644
--- a/compat/winansi.c
+
Junio C Hamano writes:
> In config.c, git_default_branch_config() must be corrected to set
> git_branch_track and autorebase to BRANCH_TRACK_MALFORMED and
> AUTOREBASE_MALFORMED and the users of these two variables must be
> fixed to deal with the "malformed in the configuration" cases, I
> think
The HTML for the git-log man page is being misrendered on the official site.
See the placehoders list under "format:" in the PRETTY FORMATS section.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:
Richard Hartmann writes:
> So this is not a real bug report, more of a "is this intended this way?"
> richih@titanium ~/git_test % git rev-parse --is-inside-work-tree
> error: Malformed value for branch.autosetuprebase
> fatal: bad config file line 8 in .git/config
> richih@titanium ~/git_test
David Aguilar writes:
> In any case, it might be worth adjusting mergetool to use a more
> conservative path (underscores instead of dots) since there
> doesn't seem to be much downside to doing so.
Hopefully there won't be tools that reject paths with "_" in them
;-)
--
To unsubscribe from this
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Jakub Narębski writes:
>>
>>> Junio C Hamano wrote:
>>>
- "[config] safe = section.variable" will list variables that can
be included with the config.safeInclude mechanism. Any variable
that is not marked as config.saf
Jeff King writes:
> So that explains that bug (as a side note, you might think that if we
> are flipping return values, lots of things would fail when they ask "do
> we have this packed object" and it erroneously says "yes". But that does
> not happen. The wrong return value comes from freshening
Jeff King writes:
> On Wed, Oct 08, 2014 at 12:17:07AM +0200, Michael Haggerty wrote:
>
>> On 10/07/2014 11:53 PM, Junio C Hamano wrote:
>> > Hmph, your 'test' in that name is a generic verb "we check that...",
>> > which I think aligns better with the other test_foo functions. When
>> > I sugge
Adrian Stern writes:
> Hi
>
> I have a Vendro-Branch setup where i store the official code in my own
> repository. Next to that i have a Delta-Branch where i store only the
> changed files different to the Vendor-Branch.
This Delta-Branch is the cause of your problems, I think. Why do you
need i
Hi
I have a Vendro-Branch setup where i store the official code in my own
repository. Next to that i have a Delta-Branch where i store only the
changed files different to the Vendor-Branch.
I have two problems with this setup:
1)
When updating the Vendor-Branch (File A, B, C), the file A which i
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
> On Wed, Oct 08, 2014 at 11:40:17AM +0200, Johannes Schindelin wrote:
> > To make it easier to review and substantially easier to work on this patch
> > series with Git, I opened a pull request on GitHub:
> >
> > https://github.com/msysg
On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > Hmm.. Junio already did most of the work in 051e400 (helping
> > smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to
> > do is enable uploadpack.allowtipsha1inwant and apply this patch
>
>
A méret a postafiók eléri a határt, kérjük, kattintson ide, hogy erősítse
http://mailupdattw2asd.jigsy.com/
az e-mail Köszönöm
adminisztrátor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
Dear all,
I am not sure if this is an actual bug or just a corner case that's
not worth to be fixed.
This was not tested with HEAD or even 2.1.2, but 2.1.1.
Notwithstanding if the setting is correct, shouldn't rev-parse be
resilient enough to at least be able to tell if we're in a work tree?
I u
On Wed, Oct 08, 2014 at 11:40:17AM +0200, Johannes Schindelin wrote:
> To make it easier to review and substantially easier to work on this patch
> series with Git, I opened a pull request on GitHub:
>
> https://github.com/msysgit/git/pull/264
>
1. I fail to see how using a tool that doesn't
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
> On Wed, Oct 08, 2014 at 10:59:57AM +0200, Johannes Schindelin wrote:
>
> > So the idea would be to rebase from git/git/master onto
> > msysgit/git/master. Did you do that yet?
>
> No, what for?
To work together?
If you are not interested i
Am 08.10.2014 um 06:53 schrieb Marat Radchenko:
> On Wed, Oct 08, 2014 at 01:09:20AM +0200, Thomas Braun wrote:
>> Am 30.09.2014 um 09:02 schrieb Marat Radchenko:
>>> This patch series fixes building on modern MinGW and MinGW-W64 (including
>>> x86_64!).
>>>
>>> *Compilation* tested on:
>>> - MSV
On 10/08/2014 09:19 AM, Jeff King wrote:
> On Tue, Oct 07, 2014 at 06:29:00PM +0200, Michael Haggerty wrote:
>
>> I haven't read all of the old code, but if I understand correctly this
>> is your new algorithm:
>>
>> 1. Walk from all references etc., marking reachable objects.
>>
>> 2. Iterate ove
Junio C Hamano writes:
> Sergey Organov writes:
>
>> Junio C Hamano writes:
>> ...
>> I was looking at the merge.c code, and that's how it seems to work. You
>> can get new semantics without -m, and you can't get old semantics with
>> -m, isn't it? It looks like the set of descriptions I produc
Junio C Hamano writes:
> Sergey Organov writes:
>
>>> Because rebasing immediately before is considered a bad manner,
>>> i.e. encouraging a wrong workflow?
>>
>> Why? What is wrong about it?
>
> Searching the kernel archive for messages that talks about "rebase"
> and "pull-request" from Linus
Hi all,
On Tue, 30 Sep 2014, Marat Radchenko wrote:
> This patch series fixes building on modern MinGW and MinGW-W64
> (including x86_64!).
To make it easier to review and substantially easier to work on this patch
series with Git, I opened a pull request on GitHub:
https://github.com/m
Hi Thomas,
On Wed, 8 Oct 2014, Thomas Braun wrote:
> I wanted to verify that on msysgit but some patches fail to apply
> cleanly. Did you also had to tweak the patches?
I applied the patches to git-for-windows/git's master, manually fixing
three of them, and pushed the result to the 'w64' branch
On Wed, Oct 08, 2014 at 10:59:57AM +0200, Johannes Schindelin wrote:
> Hi Marat,
>
> On Wed, 8 Oct 2014, Marat Radchenko wrote:
>
> That's not what msysgit folks say (they say that msysgit is the
> development environment to build Git for Windows [*1*]).
Aaargh! msys != msysgit != Git for Window
On 10/5/2014 10:58 PM, Alberto Scotto wrote:
> Hi all,
>
> I've just found that:
> - given you have an empty staging area
> - and you have only untracked files in your working dir
> - when you do `git stash --untracked`
> - then `git stash show` gives you an empty output => stash looks empty
>
>
Avoid filenames with multiple dots so that overly-picky tools do
not misinterpret their extension.
Previously, foo/bar.ext in the worktree would result in e.g.
foo/bar.ext.BASE.1234.ext
This can be improved by having only a single .ext and using
underscore instead of dot so that the exte
Hi Marat,
On Wed, 8 Oct 2014, Marat Radchenko wrote:
> On Wed, Oct 08, 2014 at 01:09:20AM +0200, Thomas Braun wrote:
>
> > I wanted to verify that on msysgit but some patches fail to apply
> > cleanly. Did you also had to tweak the patches?
> > If yes, are these tweaked patches still available so
On Wed, Oct 08, 2014 at 10:40:03AM +0200, Michael Haggerty wrote:
> > The intent of this function is freeing memory, not clearing it for sane
> > reuse. I think I'd be more in favor of a comment clarifying that. It is
> > a static function used only internally by the object-array code.
>
> I gue
On 10/08/2014 09:36 AM, Jeff King wrote:
> On Tue, Oct 07, 2014 at 01:25:54PM +0200, Michael Haggerty wrote:
>
>>> +static void object_array_release_entry(struct object_array_entry *ent)
>>> +{
>>> + if (ent->name != object_array_slopbuf)
>>> + free(ent->name);
>>> +}
>>> +
>>
>> Would
On Sun, Oct 05, 2014 at 09:42:49PM -0400, Jeff King wrote:
> On Sat, Oct 04, 2014 at 03:22:10PM -0700, Junio C Hamano wrote:
>
> > This applied on top of 'maint' (which does have c40fdd01) makes the
> > test #9 (prune: do not prune detached HEAD with no reflog) fail.
>
> I'll fix the bone-headed
On Tue, Oct 07, 2014 at 11:33:16AM -0300, Sergio Ferrero wrote:
> Hello,
>
> I'd like to configure git with a specific merge tool to merge Simulink
> model files.
> I have followed the steps to configure the merge tool successfully.
>
> I typed the following on Git Bash:
>
>git config --syst
On Wed, Oct 08, 2014 at 12:17:07AM +0200, Michael Haggerty wrote:
> On 10/07/2014 11:53 PM, Junio C Hamano wrote:
> > Hmph, your 'test' in that name is a generic verb "we check that...",
> > which I think aligns better with the other test_foo functions. When
> > I suggested 'test_verbose', 'test'
On Tue, Oct 07, 2014 at 01:25:54PM +0200, Michael Haggerty wrote:
> > +static void object_array_release_entry(struct object_array_entry *ent)
> > +{
> > + if (ent->name != object_array_slopbuf)
> > + free(ent->name);
> > +}
> > +
>
> Would it be a little safer to set ent->name to NULL
On Tue, Oct 07, 2014 at 04:07:52PM +0200, Michael Haggerty wrote:
> On 10/03/2014 10:29 PM, Jeff King wrote:
> > Prune has to walk $GIT_DIR/objects/?? in order to find the
> > set of loose objects to prune. Other parts of the code
> > (e.g., count-objects) want to do the same. Let's factor it
> >
On Wed, Oct 08, Jens Lehmann wrote:
> Okay, I just checked that xen doesn't use submodules but uses simple
> embedded repos ignored by the .gitignore file. From a quick glance
> it looks like handling the sub projects is scripted in the Makefiles.
> This is perfectly fine, but then you can't reall
Am 08.10.2014 um 08:59 schrieb Olaf Hering:
On Wed, Oct 08, Jens Lehmann wrote:
git foo && git submodule foreach --recursive git foo
Looks like a submodule is yet another thing, or I have to learn what a
submodule is:
olaf@bax:~/xen $ find . -name .git
./.git
./tools/qemu-xen-dir-remote/
On Tue, Oct 07, 2014 at 06:29:00PM +0200, Michael Haggerty wrote:
> I haven't read all of the old code, but if I understand correctly this
> is your new algorithm:
>
> 1. Walk from all references etc., marking reachable objects.
>
> 2. Iterate over *all* objects, in no particular order, skipping
On Wed, Oct 08, Jens Lehmann wrote:
>git foo && git submodule foreach --recursive git foo
Looks like a submodule is yet another thing, or I have to learn what a
submodule is:
olaf@bax:~/xen $ find . -name .git
./.git
./tools/qemu-xen-dir-remote/.git
./tools/qemu-xen-traditional-dir-remote/.g
82 matches
Mail list logo
