Hi Junio,
On 2015-06-23 22:46, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> On 2015-06-23 00:49, Junio C Hamano wrote:
>>
>>> * js/rebase-i-clean-up-upon-continue-to-skip (2015-06-18) 3 commits
>>> - rebase -i: do not leave a CHERRY_PICK_HEAD file behind
>>> - SQUASH: test_must_fai
From: Charles Bailey
The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which is expands
to a valid check for recent gcc versions and to 0 for older gcc
versions but is not defined on non-gcc builds.
Non-gcc builds need this macro to expand to 0 as well. The current
outer test (defined(__GN
On Tue, Jun 23, 2015 at 02:05:28PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > This extension does not change git's behavior at all. It is useful only
> > for testing format-1 compatibility.
> > +
> > +`preciousObjects`
> > +~
> > +
> > +When the config key `extensio
On Tue, Jun 23, 2015 at 05:31:14PM -0400, David Turner wrote:
> On Tue, 2015-06-23 at 06:54 -0400, Jeff King wrote:
> > + mkconfig 1 preciousObjects >.git/config &&
>
> nit: I think it's better to use git config rather than manually writing
> config files. git config is more future-proof if we
Okay, let's focus only on the API design issues.
For the record, I'm not completely satisfied with the current code
organization and API, however I don't have really good ideas at hand to
improve it, so any ideas with examples would be appreciated.
On Fri, Jun 19, 2015 at 09:13:00AM -0700, Junio
On Tue, Jun 23, 2015 at 06:54:11AM -0400, Jeff King wrote:
> diff --git a/builtin/prune.c b/builtin/prune.c
> index 0c73246..fc0c8e8 100644
> --- a/builtin/prune.c
> +++ b/builtin/prune.c
> @@ -218,6 +218,9 @@ int cmd_prune(int argc, const char **argv, const char
> *prefix)
> return
On Fri, Jun 19, 2015 at 5:02 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> +static int is_email(const char *filename)
>> +{
>> + struct strbuf sb = STRBUF_INIT;
>> + FILE *fp = xfopen(filename, "r");
>> + int ret = 1;
>> +
>> + while (!strbuf_getline(&sb, fp, '\n')) {
>> +
On Tue, Jun 23, 2015 at 08:10:03PM +0700, Duy Nguyen wrote:
> > - we keep a key/value index mapping the name of any branch that exists
> > to the byte offset of its entry in the logfile. This would probably
>
> One key/value mapping per branch, pointing to the latest reflog entry,
> or one
On Tue, Jun 23, 2015 at 02:18:36PM -0400, David Turner wrote:
> > Can you describe a bit more about the reflog handling?
> >
> > One of the problems we've had with large-ref repos is that the reflog
> > storage is quite inefficient. You can pack all the refs, but you may
> > still be stuck with a
On Tue, Jun 23, 2015 at 11:09:40PM -0700, Shawn Pearce wrote:
> Yes. $DAY_JOB's DFS implementation never expires reflogs, allowing it
> to be used as a history to inspect what happened. Its been useful a
> couple of times to investigate and recover from a few accidental
> deletions.
>
> Once you
On Tue, Jun 23, 2015 at 11:50 PM, Junio C Hamano wrote:
>> This patch tightens the "exists in index" check, ignoring i-t-a
>> entries. For fixing the above problem, only the change in
>> check_to_create() is needed.
>
> And the first thing I noticed and found a bit disturbing was that
> this chang
On Wed, Jun 24, 2015 at 1:09 PM, Shawn Pearce wrote:
>>> I chose to use LMDB for the database. LMDB has a few features that make
>>> it suitable for usage in git:
>>
>> One of the complaints that Shawn had about sqlite is that there is no
>> native Java implementation, which makes it hard for JGi
On Wed, Jun 24, 2015 at 3:12 PM, Jeff King wrote:
> On Tue, Jun 23, 2015 at 06:54:11AM -0400, Jeff King wrote:
>
>> diff --git a/builtin/prune.c b/builtin/prune.c
>> index 0c73246..fc0c8e8 100644
>> --- a/builtin/prune.c
>> +++ b/builtin/prune.c
>> @@ -218,6 +218,9 @@ int cmd_prune(int argc, const
Hi Junio,
On Tue, Jun 16, 2015 at 5:03 PM, Paul Tan wrote:
> This reverts commit d25e51596be9271ad833805a3d6f9012dc24ee79, removing
> git-mailsplit's --no-inbody-headers option.
>
> While --no-inbody-headers was introduced to prevent commit messages from
> being munged by git-mailinfo while rebas
Summary:
When creating a linked working directory with `git checkout --to`, you
cannot clone from the local path. This works when cloning the main
repository directory.
I couldn't find anything the the documentation for `git checkout` that
indicates that this shouldn't work.
Repro:
Creating a rep
On Wed, Jun 24, 2015 at 5:38 PM, Bjørnar Snoksrud wrote:
> Summary:
> When creating a linked working directory with `git checkout --to`, you
> cannot clone from the local path. This works when cloning the main
> repository directory.
>
> I couldn't find anything the the documentation for `git chec
Since Perl 5.22, "A literal '{' should now be escaped in a pattern".
Silence the recently added warning by using \{ instead.
Signed-off-by: Christian Neukirchen
---
git-cvsimport.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
inde
On Tue, Jun 23, 2015 at 10:32:08PM -0700, Junio C Hamano wrote:
>
> Regarding loose object files, given that we write to a temporary,
> optionally fsync, close and then move to the final name, would we
> still see partially written file if we omit the fsync, or would the
> corruption be limited to
Hi Paul,
On 2015-06-18 13:25, Paul Tan wrote:
> diff --git a/builtin/am.c b/builtin/am.c
> index dbc8836..af68c51 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -6,6 +6,158 @@
> #include "cache.h"
> #include "builtin.h"
> #include "exec_cmd.h"
> +#include "parse-options.h"
> +#include "
Hi Paul,
On 2015-06-18 13:25, Paul Tan wrote:
> diff --git a/builtin/am.c b/builtin/am.c
> index e9a3687..7b97ea8 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -121,6 +121,96 @@ static void am_destroy(const struct am_state *state)
> strbuf_release(&sb);
> }
>
> +/*
> + * Returns
This is a minor iteration over v7 to take into account Junio and
Eric's comments, AND fix an important typo that I introduced in the
strbuf code conversion (I used name_good instead of name_bad). This
fixes the "git bisect visualize" bug I found earlier. I played a bit
with the result and didn't fi
From: Antoine Delaite
To add new tags like old/new and have keywords less confusing, the
first step is to avoid hardcoding the keywords.
The default mode is still bad/good.
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
Signed-off-by: Valentin Duperray
Signed-off-by: Franck Jonas
From: Antoine Delaite
Signed-off-by: Antoine Delaite
Signed-off-by: Matthieu Moy
---
bisect.c| 2 +-
t/t6030-bisect-porcelain.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bisect.c b/bisect.c
index 03d5cd9..5b8357d 100644
--- a/bisect.c
+++ b/bis
From: Antoine Delaite
Introduction of the git bisect terms function.
The user can set its own terms.
It will work exactly like before. The terms must be set
before the start.
Signed-off-by: Antoine Delaite
Signed-off-by: Louis Stuber
Signed-off-by: Matthieu Moy
---
Documentation/git-bisect.t
From: Antoine Delaite
We create a file BISECT_TERMS in the repository .git to be read during a
bisection. The fonctions to be changed if we add new terms are quite
few.
In git-bisect.sh:
check_and_set_terms
bisect_voc
Co-authored-by: Louis Stuber
Tweaked-by: Matthieu Moy
Signed
From: Antoine Delaite
When not looking for a regression during a bisect but for a fix or a
change in another given property, it can be confusing to use 'good'
and 'bad'.
This patch introduce `git bisect new` and `git bisect old` as an
alternative to 'bad' and good': the commits which have a cert
Hi all,
sorry for not having sent these informations in my first e-mail.
I'm working on a Debian Jessie laptop, with git version 2.1.4.
I watched the same behavior in a workmate's laptop which uses last
version of Ubuntu, but now I cannot contact him to get git version.
Afger "apt-get update" and
Paul Tan writes:
> 3. I'm over-thinking this and you just want the "struct strbufs" in the
>struct am_state to be switched to "char*"s?
Yes, everybody interacts with am_state, and these fields are
supposed to be constant during the processing of each patch input
message; they should be simpl
Paul Tan writes:
> On Tue, Jun 16, 2015 at 5:03 PM, Paul Tan wrote:
>> This reverts commit d25e51596be9271ad833805a3d6f9012dc24ee79, removing
>> git-mailsplit's --no-inbody-headers option.
>>
>> While --no-inbody-headers was introduced to prevent commit messages from
>> being munged by git-maili
Hi Paul,
On 2015-06-18 13:25, Paul Tan wrote:
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 0cc7ae8..bc77d77 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -719,6 +719,7 @@ extern void *xrealloc(void *ptr, size_t size);
> extern void *xcalloc(size_t nmemb, size_t
Hi Paul,
On 2015-06-18 13:25, Paul Tan wrote:
> diff --git a/builtin/am.c b/builtin/am.c
> index 7b97ea8..d6434e4 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -94,6 +126,105 @@ static int read_state_file(struct strbuf *sb,
> const char *file, size_t hint, int
> }
>
> /**
> + * Reads
On Wed, Jun 24, 2015 at 9:28 AM, Johannes Schindelin
wrote:
> Hi Paul,
>
> On 2015-06-18 13:25, Paul Tan wrote:
>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index 0cc7ae8..bc77d77 100644
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -719,6 +719,7 @@ extern void *xreallo
Duy Nguyen writes:
> Take checkout for example, when you do "git checkout -- foo" where foo
> is i-t-a, the file foo on disk will be emptied because the SHA-1 in
> the i-t-a entry is an empty blob, mostly to help "git diff". I think
> it should behave as if foo is not i-t-a: checkout should error
Jeff King writes:
>> > + if (delete_redundant && repository_format_precious_objects)
>> > + die("cannot repack in a precious-objects repo");
>>
>> This message initially threw me off during my cursory reading, but
>> the code tells me that this is only about "repack -d".
>>
>> Unfortu
Matthieu Moy writes:
> This is a minor iteration over v7 to take into account Junio and
> Eric's comments, AND fix an important typo that I introduced in the
> strbuf code conversion (I used name_good instead of name_bad). This
> fixes the "git bisect visualize" bug I found earlier. I played a bi
Matthieu Moy writes:
> diff --git a/bisect.c b/bisect.c
> index 2d3dbdc..08be634 100644
> --- a/bisect.c
> +++ b/bisect.c
> @@ -747,7 +747,10 @@ static void handle_bad_merge_base(void)
> "between %s and [%s].\n",
> bad_hex, bad_hex, good
On Tue, 2015-06-23 at 23:27 +0200, Michael Haggerty wrote:
> On 06/23/2015 09:53 PM, David Turner wrote:
> > On Tue, 2015-06-23 at 17:51 +0200, Michael Haggerty wrote:
> > [...]
> >> * I don't like the fact that you have replaced `struct ref_transaction
> >> *` with `void *` in the public interface
On Wed, 2015-06-24 at 05:14 -0400, Jeff King wrote:
> On Tue, Jun 23, 2015 at 02:18:36PM -0400, David Turner wrote:
>
> > > Can you describe a bit more about the reflog handling?
> > >
> > > One of the problems we've had with large-ref repos is that the reflog
> > > storage is quite inefficient.
Matthieu Moy writes:
> +Alternative terms: use your own terms
> +~
> +
> +If the builtins terms bad/good and new/old do not satisfy you, you can
> +set your own terms.
> +
> +
> +git bisect terms term1 term2
> +--
Hello,
If someone downloads code to their notebook PC and leaves the company, what
protection do we have against them not being able to access the local code copy
anymore?
Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.
Hello,
What type of code scope should a repository contain? Can it be one large
program with many elements or should it just be part of a program or can it be
a project with multiple programs? What are the recommendations?
Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubsc
On Wed, 24 Jun 2015 18:18:00 +
BGaudreault Brian wrote:
> If someone downloads code to their notebook PC and leaves the
> company, what protection do we have against them not being able to
> access the local code copy anymore?
What do you mean by "local code"?
That one which is on the notebo
On Wed, 24 Jun 2015 18:19:42 +
BGaudreault Brian wrote:
> What type of code scope should a repository contain? Can it be one
> large program with many elements or should it just be part of a
> program or can it be a project with multiple programs? What are the
> recommendations?
There are
Thanks. Yes, I meant that "local code" is code pulled down to a person's PC,
so we don't want them to leave the company with access to this code. So we can
only prevent this scenario by running GitLab in our environment instead of
running GitHub in the cloud? Would removing a GitHub account f
Hi Stefan,
On 2015-06-24 18:59, Stefan Beller wrote:
> On Wed, Jun 24, 2015 at 9:28 AM, Johannes Schindelin
> wrote:
>>
>> On 2015-06-18 13:25, Paul Tan wrote:
>>
>>> + int fd = open(path, oflag, mode);
>>> + if (fd >= 0)
>>> + return fd;
>>> +
Thanks. So are you saying there are tools that will let us start a repo for a
project with multiple submodules and then pull out the coding history for a
specific submodule so we can create a separate repository just for that
submodule?
I've actually been doing a lot of research about Git for
Add err argument to log_ref_setup that can explain the reason for a
failure. This then eliminates the need to manage errno through this
function since we can just add strerror(errno) to the err string when
meaningful. No callers relied on errno from this function for anything
else than the error me
This set of patches is a preamble to pluggable ref backends. The
intent is to use the ref infrastructure for special refs like
CHERRY_PICK_HEAD where possible, and to use git plumbing commands to
access refs and reflogs instead of directly writing files to the .git
directory.
This series is on to
This is in support of alternate ref backends which don't necessarily
store reflogs as files.
Signed-off-by: David Turner
---
git-stash.sh | 4 ++--
refs.c | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 8e9e2cd..27155bc 100755
--- a/g
This ref needs to go through the refs backend, since some code assumes
that it can be written and read as a ref.
Signed-off-by: David Turner
---
contrib/completion/git-completion.bash | 2 +-
git-bisect.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff
In a moment, we will use this to add reflog creation commands to
git-reflog.
Signed-off-by: David Turner
---
builtin/checkout.c | 2 +-
refs.c | 4 ++--
refs.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
i
Also use refs infrastructure for REVERT_HEAD. These refs
need to go through the refs backend, since some code
assumes that they can be read as refs.
Signed-off-by: David Turner
---
branch.c | 4 ++--
builtin/commit.c | 7 ---
builtin/merge.c
These are necessary because ref backends manage reflogs. In a moment,
we will use these functions to make git stash work with alternate
ref backends.
Signed-off-by: David Turner
---
builtin/reflog.c | 81 +++-
1 file changed, 80 insertions(+),
On Wed, 24 Jun 2015, BGaudreault Brian wrote:
Thanks. Yes, I meant that "local code" is code pulled down to a person's PC,
so we don't want them to leave the company with access to this code. So we can only
prevent this scenario by running GitLab in our environment instead of running GitHub
What most companies do is this: they issue their employees computers,
and then when the employee leaves, they take the computers away. Of
course, someone could have copied the code before leaving the company.
The typical remedy for this is a contract saying "don't do that". But I
guess some compa
Matthieu Moy writes:
> Documentation/git-bisect.txt | 67 +-
> bisect.c | 94 +++-
> git-bisect.sh| 207
> +++
> revision.c | 20 -
> t/t6030-bisect-porcelain.sh |
v4 of this patch series can be found here :
http://article.gmane.org/gmane.comp.version-control.git/272285
This is a continuation of my GSoC project to unify git tag -l, git
branch -l and for-each-ref. Continued from this patch series :
http://thread.gmane.org/gmane.comp.version-control.git/271563
Hi David Lang,
I'm sorry, but I'm confused by your first two responses. Am I not contacting
Git when I e-mail this e-mail address? You sound like you don't know exactly
how GitHub works. Should I be contacting someone else for GitHub support?
Thanks,
Brian
-Original Message-
From: D
In 'tag -l' we have '--points-at' option which lets users
list only tags which point to a particular commit. Implement
this option in 'ref-filter.{c,h}' so that other commands can
benefit from this.
This is duplicated from tag.c, we will eventually remove that
when we port tag.c to use ref-filter
Rename 'parse_opt_points_at()' to 'parse_opt_object_name()' and
move it from 'tag.c' to 'parse-options'. This now acts as a common
parse_opt function which accepts an objectname and stores it into
a sha1_array.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Add 'parse_opt_merge_filter()' to parse '--merged' and '--no-merged'
options and write macros for the same.
This is copied from 'builtin/branch.c' which will eventually be removed
when we port 'branch.c' to use ref-filter APIs.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored
In 'branch -l' we have '--merged' option which only lists refs (branches)
merged into the named commit and '--no-merged' option which only lists
refs (branches) not merged into the named commit. Implement these two
options in ref-filter.{c,h} so that other commands can benefit from this.
Based-on-
Rename parse_opt_with_commit() to parse_opt_commits() to show
that it can be used to obtain a list of commits and is not
constricted to usage of '--contains' option.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
builtin/branch.c | 4 ++--
builtin/ta
Add the '--points-at' option provided by 'ref-filter'. The
option lets the user to pick only refs which point to a particular
commit.
Add documentation and tests for the same.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
Add a test suite for testing the ref-filter APIs used
by for-each-ref. We just intialize the test suite for now.
More tests will be added in the following patches as more
options are added to for-each-ref.
Based-on-patch-by: Jeff King
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Sign
Add the '--merged' and '--no-merged' options provided by 'ref-filter'.
The '--merged' option lets the user to only list refs merged into the
named commit. The '--no-merged' option lets the user to only list refs
not merged into the named commit.
Add documentation and tests for the same.
Based-on-
Add a macro for using the '--contains' option in parse-options.h
also include an optional '--with' option macro which performs the
same action as '--contains'.
Make tag.c and branch.c use this new macro.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Nayak
---
'tag -l' and 'branch -l' have two different ways of finding
out if a certain ref contains a commit. Implement both these
methods in ref-filter and give the caller of ref-filter API
the option to pick which implementation to be used.
'branch -l' uses 'is_descendant_of()' from commit.c which is
left
Add the '--contains' option provided by 'ref-filter'. The '--contains'
option lists only refs which contain the mentioned commit (HEAD if no
commit is explicitly given).
Add documentation and tests for the same.
Mentored-by: Christian Couder
Mentored-by: Matthieu Moy
Signed-off-by: Karthik Naya
Git is not GitHub (any more than a cat is a cathouse). Git is a piece
of software; GitHub is a hosting service for Git. Contact GitHub for
GitHub support.
On Wed, 2015-06-24 at 19:53 +, BGaudreault Brian wrote:
> Hi David Lang,
>
> I'm sorry, but I'm confused by your first two responses.
On Wed, 24 Jun 2015, BGaudreault Brian wrote:
Hi David Lang,
I'm sorry, but I'm confused by your first two responses. Am I not contacting
Git when I e-mail this e-mail address? You sound like you don't know exactly
how GitHub works. Should I be contacting someone else for GitHub support?
Ok, thanks. I didn't realize there was a difference! I thought Git SCM ran
GitHub. I haven't yet read this clear distinction. Of course I wasn't the one
who chose GitHub in the first place.
-Original Message-
From: David Turner [mailto:dtur...@twopensource.com]
Sent: Wednesday, June
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Some of the topics in flight have overlaps with each other and have
been excluded from 'pu'; most notably, I think the remainder of
bc/object-id
Junio C Hamano writes:
> they would call "term2" into "term1" somewhere. e.g.
>
> -ancestors of term1.
> +ancestors of term1. For example, if something was buggy in
> +the old part of the history, you know somewhere the bug was
> +fixed, and you want to find the exact
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> diff --git a/bisect.c b/bisect.c
>> index 2d3dbdc..08be634 100644
>> --- a/bisect.c
>> +++ b/bisect.c
>> @@ -747,7 +747,10 @@ static void handle_bad_merge_base(void)
>> "between %s and [%s].\n",
>>
From: Charles Bailey
The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which is expands
to a valid check for recent gcc versions and to 0 for older gcc
versions but is not defined on non-gcc builds.
Non-gcc builds need this macro to expand to 0 as well. The current outer
test (defined(__GN
On Wed, Jun 24, 2015 at 11:12:07PM +0100, Charles Bailey wrote:
> From: Charles Bailey
>
> The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which is expands
> to a valid check for recent gcc versions and to 0 for older gcc
> versions but is not defined on non-gcc builds.
Actually hitting
Add the Microsoft .manifest pattern, and correct the generic 'Debug'
and 'Release' directory patterns which were mechanically adjusted way
back in c591d5f (gitignore: root most patterns at the top-level directory,
2009-10-26) to allow multi-level projects within the Git suite.
Signed-off-by: Phili
Signed-off-by: Philip Oakley
---
contrib/buildsystems/engine.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 23da787..5398315 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.
Implement the README to facilitate cross community development.
Include comments for those Windows folks not yet fully familiar
with bash commands.
This is identical to the msysgit script, except for the 'cd toplevel'
step, and comments for the edification of converts from Windows.
Original author
ee9be06 (perl: detect new files in MakeMaker builds, 2012-07-27)
did not include dry-run support for the generation of the PM.stamp
file, though the dry-run output is used by the build engine.
Disable the perl processing during the dry-run to avoid the issue.
Signed-off-by: Philip Oakley
---
co
The i18n 5e9637c (i18n: add infrastructure for translating
Git with gettext, 2011-11-18) introduced an extra '-o' option
into the make file.
If the msvc buildsystem is run without NO_GETTEXT being set
then this broke the engine.pl code for extracting the git.sln
for msvc gui-IDE. The setting of NO
Signed-off-by: Philip Oakley
---
.gitignore | 3 +++
1 file changed, 3 insertions(+)
diff --git a/.gitignore b/.gitignore
index 55498c1..706d0d9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -177,6 +177,7 @@
/gitweb/gitweb.cgi
/gitweb/static/gitweb.js
/gitweb/static/gitweb.min.*
+/libgit
/test
The engine.pl script barfs on the properly quoted spaces in
filename options prevalent on Windows. Use shellwords() rather
than split() to separate such options.
Helped-by: Junio C Hamano
Signed-off-by: Philip Oakley
---
$gamane/21145 & $gmane/21147
---
contrib/buildsystems/engine.pl | 7 --
Delete the duplicated GUID from the generation code for the Visual Studio
.sln project file.
The duplicate GUID tended to be allocated to test-svn-fe, which was then
ignored by Visual Studio / MSVC, and it's omission from the build never
noticed.
Signed-off-by: Philip Oakley
---
contrib/buildsy
Commit 4b623d8 (MSVC: link in invalidcontinue.obj for better
POSIX compatibility, 2014-03-29) is not processed correctly
by the buildsystem. Ignore it.
Also split the .o and .obj processing; 'make' does not produce .obj
files. Only substitute filenames ending with .o when generating the
source .c
Save the stderr from the dry MSVC make to a well named file for
later review. Use 'msvc-build-makedryerrors.txt' which should be
obvious as to its source, and is not ignored by 'git status'.
Signed-off-by: Philip Oakley
---
contrib/buildsystems/engine.pl | 5 -
1 file changed, 4 insertions(+
Add a debug suggestion for capturing to file the stdout from the dry-run
of the make file used in determining the msvc-build structure for easy
debugging.
Signed-off-by: Philip Oakley
---
contrib/buildsystems/engine.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/buildsystems/engi
A 'make -n' dry-run is used as part of the /compat/vcbuild and
/contrib/buildsystems code. The commit ee9be06 (perl: detect new files
in MakeMaker builds, 2012-07-27) was not aware of that dry-run usage
and thus would not execute the target.
Add a comment to the make file stating the issue and the
Visual Studio take the first listed application/library as the default
startup project [1]. Parse the application list for git.exe, then list
the libraries, then the other git dashed forms in the git.sln file.
Detect the 'git' project and place it the head of the apps list, rather
than the tail.
Signed-off-by: Philip Oakley
---
config.mak.uname | 9 +
1 file changed, 9 insertions(+)
diff --git a/config.mak.uname b/config.mak.uname
index 943c439..1c27828 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -1,5 +1,9 @@
# Platform specific Makefile tweaks based on uname detect
Assist developers transitioning between the two cultures
by including appropriate, but commented out, debug statements.
The exception is when an unhandled compiler option is detected,
where printing of the full line will supplement the line number and
option part. Otherwise the OP has no immediate
Layout the 'either/or' with more white space to clarify
which alternatives are matched up.
Reference the Msysgit build script which automates one sequence of options.
Signed-off-by: Philip Oakley
---
compat/vcbuild/README | 27 +++
1 file changed, 19 insertions(+), 8 del
This series fixes the scripts which generated Visual Studio project
files. The scripts had bit rotted over the years as other commits
changed the git makefile which it post processed.
The series doesn't attempt to install the Visual Studio compiled product
but allows Windows developers familiar wi
Keep the build clean of extraneous files if it is indeed clean.
Otherwise leave the msvc-build-makedryerrors.txt file both as
a flag for any CI system or for manual debugging.
Note that the file will contain the new values of the GIT_VERSION
and GITGUI_VERSION if they were generated by the make fi
Sitaram Chamarty writes:
> This *is* documented, but I'm curious why this distinction is made.
I think it is from mere laziness, and also in a smaller degree
coming from an expectation that --stdin would be fed by another
script like rev-list where feeding full 40-hex is less work than
feeding u
Karthik Nayak writes:
> t/t6301-for-each-ref-filter.sh | 19 +++
t6301 is already used in mh/reporting-broken-refs-from-for-each-ref
topic. Please renumber.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
M
> * pt/pull-builtin (2015-06-18) 19 commits
> - pull: remove redirection to git-pull.sh
> - pull --rebase: error on no merge candidate cases
> - pull --rebase: exit early when the working directory is dirty
> - pull: configure --rebase via branch..rebase or pull.rebase
> - pull: teach git pull
On Wed, Jun 24, 2015 at 05:49:20AM -0400, Jeff King wrote:
> I don't know how much that helps for the JGit situation. It punts the
> native code out of JGit, but people using JGit still have to have the
> native helper from git on their system. I have no problems at all with
> pluggable $FANCY_DB
On 06/25/2015 05:41 AM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> This *is* documented, but I'm curious why this distinction is made.
>
> I think it is from mere laziness, and also in a smaller degree
> coming from an expectation that --stdin would be fed by another
> script like rev
100 matches
Mail list logo