On 7 August 2017 at 23:12, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> The series looks fine to me overall, though patch 5 is overly gentle IMHO.
>> We could have removed it right there as Junio is very good at resolving
>> conflicts or producing
Junio C Hamano wrote:
> Urs Thuermann writes:
>
> > In parse_svn_date() prepend the correct UTC offset to the timestamp
> > returned. This is the offset in effect at the commit time instead of
> > the offset in effect at calling time.
> >
> >
--
Permit me to communicate with you in private.
I have a profitable transaction to discuss with you and i will
disclose the details once i receive your acceptance reply.
Junio C Hamano writes:
> Martin Koegler writes:
>
>> From: Martin Koegler
>>
>> The current delta code produces incorrect pack objects for files > 4GB.
>>
>> Signed-off-by: Martin Koegler
>> ---
Add a '.clang-format' file which outlines the git project's coding
style. This can be used with clang-format to auto-format .c and .h
files to conform with git's style.
Signed-off-by: Brandon Williams
---
I'm sure this sort of thing comes up every so often on the list but
Hi Todd
Thanks for replying, below is my current install information
Current ( STASH and GIT are installed on the same server ):
STASH ( BitBucket ) = 3.9.2
Git = 2.0.4 ( installed from tar Ball and not from an RPM as the RPM was too
old.
Centos = 6.6
Required:
BitBucket = 5.2
Git = 2.2 +
On Mon, 7 Aug 2017 15:12:11 -0400
Ben Peart wrote:
> I missed the offline discussion and so am trying to piece together what
> this latest design is trying to do. Please let me know if I'm not
> understanding something correctly.
>
> From what I can tell, objects are
Junio C Hamano writes:
> This is not about where the bar is set. It is about expectation
After having thought about this a bit more, I think in the message I
am responding to I mischaracterised the aspect of a patch that
influences the "expectation". It is much less
Mahmoud Al-Qudsi writes:
> Looking back, I probably should have started with that. `git
> status` gives the status of the _relative_ current state of the
> local repository without printing any information that can be used
> as an _absolute_ reference to "frame" the results
Mahmoud Al-Qudsi writes:
> The default git behavior when attempting to `git checkout xxx` for
> some value of "xxx" that cannot be resolved to a single, unique
> file/path/branch/tag/commit/etc is to display the following:
>
>> error: pathspec 'xxx' did not match any file(s)
Jeff King writes:
> On Mon, Aug 07, 2017 at 09:55:56PM +0200, Nicolas Morey-Chaisemartin wrote:
>
>> > On the other hand, if we're hoping to get rid of this code in favor of
>> > the curl-based approach, then it's not worth spending time on
>> > cosmetic refactoring, as long as it
On 07/08/2017 23:25, Igor Djordjevic wrote:
> On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
>> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>>> I actually consider "branch" to *never* invoking a checkout. Even
>>> when "git branch -m A B" happens to be done when your checked out
>>> branch
No change of behaviour intended.
Signed-off-by: Junio C Hamano
--
perl/Git.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index f4b56e6d4d..ffa09ace92 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -532,7 +532,7 @@ If TIME is
Urs Thuermann writes:
> In parse_svn_date() prepend the correct UTC offset to the timestamp
> returned. This is the offset in effect at the commit time instead of
> the offset in effect at calling time.
>
> Signed-off-by: Urs Thuermann
> ---
>
Hello,
The default git behavior when attempting to `git checkout xxx` for
some value of "xxx" that cannot be resolved to a single, unique
file/path/branch/tag/commit/etc is to display the following:
> error: pathspec 'xxx' did not match any file(s) known to git
Unfortunately, this is (IMHO) at
Johannes Schindelin writes:
> I feel a bit talked to my hand, as the only reply I was graced was a "I
> think I already did". So this will be my last reply on this matter for a
> while.
Ah, I meant this thing:
On Mon, Aug 7, 2017 at 11:18 PM, Prathamesh Chavan wrote:
> +static enum {
> + DIFF_INDEX,
> + DIFF_FILES
> +} diff_cmd = DIFF_INDEX;
Using an enum could be a good idea, but I am not sure about using a
static variable.
> +static int
On Fri, Jun 16, 2017 at 4:41 PM, Junio C Hamano wrote:
>
> HEAD is, unless you are about to create a root commit, always a
> commit and not other kind of commit-ish, so there is no need to say
> "or commit-ish" here.
I apologize for my errant terminology, I thought commitish
Am 14.09.2016 um 23:07 schrieb Thomas Gummerer:
> When the chmod option was added to git add, it was hooked up to the diff
> machinery, meaning that it only works when the version in the index
> differs from the version on disk.
>
> As the option was supposed to mirror the chmod option in
Johannes Schindelin writes:
> So are you saying that starting with v2.14.0, you accept patches into `pu`
> for which you would previously have required multiple iterations before
> even considering it for `pu`?
>
> Frankly, I am a bit surprised that this obvious
On 06/08/2017 22:26, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Aug 05 2017, Junio C. Hamano jotted:
>> I actually consider "branch" to *never* invoking a checkout. Even
>> when "git branch -m A B" happens to be done when your checked out
>> branch is A and you end up being on B. That is not a
This aims to make git-submodule foreach a builtin. This is the very
first step taken in this direction. Hence, 'foreach' is ported to
submodule--helper, and submodule--helper is called from git-submodule.sh.
The code is split up to have one function to obtain all the list of
submodules. This
It was observed that the variable '$displaypath' was accessible but
undocumented. Hence, document it.
Discussed-with: Ramsay Jones
Signed-off-by: Stefan Beller
Signed-off-by: Prathamesh Chavan
---
The submodule subcommand 'summary' is ported in the process of
making git-submodule a builtin. The function cmd_summary() from
git-submodule.sh is ported to functions module_summary(),
compute_summary_module_list(), prepare_submodule_summary() and
generate_submodule_summary(), print_summary().
As using a variable '$path' may be harmful to users due to
capitalization issues, see 64394e3ae9 (git-submodule.sh: Don't
use $path variable in eval_gettext string, 2012-04-17). Adjust
the documentation to advocate for using $sm_path, which contains
the same value. We still make the 'path'
It does not contain the topmost superproject as the author assumed,
but the direct superproject, such that $toplevel/$sm_path is the
actual absolute path of the submodule.
Discussed-with: Ramsay Jones
Signed-off-by: Stefan Beller
Signed-off-by:
When running 'git submodule foreach' from a subdirectory of your
repository, nested submodules get a bogus value for $sm_path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' would report
path='../nested' for the nested submodule.
Change the scope of function count_lines for allowing the function
to be reused in other parts of the code as well.
Mentored-by: Christian Couder
Mentored-by: Stefan Beller
Signed-off-by: Prathamesh Chavan
---
diff.c | 2 +-
The same mechanism is used even for porting this submodule
subcommand, as used in the ported subcommands till now.
The function cmd_deinit in split up after porting into three
functions: module_deinit(), for_each_submodule_list() and
deinit_submodule().
Mentored-by: Christian Couder
This aims to make git-submodule 'status' a built-in. Hence, the function
cmd_status() is ported from shell to C. This is done by introducing
three functions: module_status(), submodule_status() and print_status().
The function module_status() acts as the front-end of the subcommand.
It parses
Port the submodule subcommand 'sync' from shell to C using the same
mechanism as that used for porting submodule subcommand 'status'.
Hence, here the function cmd_sync() is ported from shell to C.
This is done by introducing three functions: module_sync(),
sync_submodule() and
Introduce function get_submodule_displaypath() to replace the code
occurring in submodule_init() for generating displaypath of the
submodule with a call to it.
This new function will also be used in other parts of the system
in later patches.
Mentored-by: Christian Couder
SUMMARY OF MY PROJECT:
Git submodule subcommands are currently implemented by using shell script
'git-submodule.sh'. There are several reasons why we'll prefer not to
use the shell script. My project intends to convert the subcommands into
C code, thus making them builtins. This will increase
Introduce function for_each_submodule_list() and
replace a loop in module_init() with a call to it.
The new function will also be used in other parts of the
system in later patches.
Mentored-by: Christian Couder
Mentored-by: Stefan Beller
Function set_name_rev() is ported from git-submodule to the
submodule--helper builtin. The function get_name_rev() generates the
value of the revision name as required, and the function
print_name_rev() handles the formating and printing of the obtained
revision name.
Mentored-by: Christian
Hi René,
On Mon, 7 Aug 2017, René Scharfe wrote:
> The parameter to basename(3) and dirname(3) traditionally had the type
> "char *", but on OpenBSD it's been "const char *" for years. That
> causes (at least) Clang to throw an incompatible-pointer-types warning
> for test-path-utils, where we
Stefan Beller writes:
> The series looks fine to me overall, though patch 5 is overly gentle IMHO.
> We could have removed it right there as Junio is very good at resolving
> conflicts or producing dirty merges for such a situation.
> But delaying it until no other series'
Hi Junio,
On Mon, 7 Aug 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> The patch obviously makes the code better and self consistent in
> >> that "struct delta_index" has src_size as ulong, and this function
> >> takes trg_size as ulong, and it was
Hi Junio,
I feel a bit talked to my hand, as the only reply I was graced was a "I
think I already did". So this will be my last reply on this matter for a
while.
On Mon, 7 Aug 2017, Junio C Hamano wrote:
> IIUC, you will need "$GIT_EXEC_PATH/git-checkout" on the filesystem if
> you want your
Kaartic Sivaraam writes:
> I refactored builtin/branch.c to remove the '--set-upstream'
> option,successfully. The corresponding patch follows.
>
> There's just one issue with the version of git that doesn't
> have the '--set-upstream' option. It's described in
On Sun, Aug 06, 2017 at 09:12:16PM +0200, Nicolas Morey-Chaisemartin wrote:
> Also it probably make sense to have at least one release where --curl
> is the default. Until your mail I had no idea this option existed so I
> never tried it out.
> Making it the default will make sure almost everyone
Martin Ågren writes:
> When accepting booleans as command-line or config options throughout
> Git, there are several documented synonyms for true and false.
> However, one particular user is slightly broken: `git push --signed=..`
> does not understand the integer
On Mon, Aug 07, 2017 at 09:55:56PM +0200, Nicolas Morey-Chaisemartin wrote:
> > On the other hand, if we're hoping to get rid of this code in favor of
> > the curl-based approach, then it's not worth spending time on
> > cosmetic refactoring, as long as it still behaves correctly in the
> >
On Mon, Aug 07, 2017 at 04:04:05PM +0200, Nicolas Morey-Chaisemartin wrote:
> Signed-off-by: Nicolas Morey-Chaisemartin
Thanks for moving forward with this.
Can you please flesh out your commit messages with some of the reasoning
and related discussion? I know
Le 07/08/2017 à 21:42, Jeff King a écrit :
> On Mon, Aug 07, 2017 at 07:18:32PM +0200, Martin Ågren wrote:
>
"cred.username" is checked further down, but now it will always be NULL,
no?
>>> You're right I missed this.
>>> Not sure if this is needed though.
>>> From what I understand
76e368c378 (t3700: fix broken test under !SANITY) explains that the test
'git add --chmod=[+-]x changes index with already added file' can fail
if xfoo3 is still present as a symlink from a previous test and deletes
it with rm(1). That still leaves it present in the index, which causes
the test
On Mon, Aug 07, 2017 at 07:06:07PM +0200, Nicolas Morey-Chaisemartin wrote:
> >> - server_fill_credential();
> >> - curl_easy_setopt(curl, CURLOPT_USERNAME, server.user);
> >> - curl_easy_setopt(curl, CURLOPT_PASSWORD, server.pass);
> >> + server_fill_credential(srvc);
>
Johannes Schindelin writes:
> So I would love to hear the arguments for keeping the dashed forms of
> builtins, even if the only surviving argument may be "I dig in my feet
> because I always said we'd keep them".
I think I already did ;-)
Johannes Schindelin writes:
>> The patch obviously makes the code better and self consistent in
>> that "struct delta_index" has src_size as ulong, and this function
>> takes trg_size as ulong, and it was plain wrong for the code to
>> assume that "i", which is uint,
On Mon, Aug 07, 2017 at 07:18:32PM +0200, Martin Ågren wrote:
> >> "cred.username" is checked further down, but now it will always be NULL,
> >> no?
> >
> > You're right I missed this.
> > Not sure if this is needed though.
> > From what I understand this means the username/password are store for
Ben Peart writes:
> My concern with this proposal is the combination of 1) writing a new
> pack file for every git command that ends up bringing down a missing
> object and 2) gc not compressing those pack files into a single pack
> file.
Your noticing these is a sign that
Hi,
On Mon, 7 Aug 2017, Junio C Hamano wrote:
> Martin Koegler writes:
>
> > From: Martin Koegler
> >
> > The current delta code produces incorrect pack objects for files > 4GB.
> >
> > Signed-off-by: Martin Koegler
Hi Hannes,
On Mon, 7 Aug 2017, Johannes Sixt wrote:
> Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:
> > On Sun, 6 Aug 2017, Johannes Sixt wrote:
> > > Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
> > > > * Comes with [BusyBox
> > > >
Hi Junio,
On Mon, 7 Aug 2017, Junio C Hamano wrote:
> Michael Forney writes:
>
> > This way, they still work even if the built-in symlinks aren't
> > installed.
> >
> > Signed-off-by: Michael Forney
> > ---
> > It looks like there was an effort to do
Hi,
Ben Peart wrote:
>> On Fri, 04 Aug 2017 15:51:08 -0700
>> Junio C Hamano wrote:
>>> Jonathan Tan writes:
"Imported" objects must be in a packfile that has a ".remote"
file with arbitrary text (similar to the ".keep" file). They come
On 8/4/2017 8:21 PM, Jonathan Tan wrote:
On Fri, 04 Aug 2017 15:51:08 -0700
Junio C Hamano wrote:
Jonathan Tan writes:
"Imported" objects must be in a packfile that has a ".remote"
file with arbitrary text (similar to the ".keep" file). They
On Mon, Aug 7, 2017 at 11:20 AM, Martin Ågren wrote:
> When we want to parse a boolean config item without dying on error, we
> call git_config_maybe_bool() which takes two arguments: the value to be
> parsed (obviously) and a `name` which is completely ignored. Junio has
Martin Koegler writes:
> From: Martin Koegler
>
> The current delta code produces incorrect pack objects for files > 4GB.
>
> Signed-off-by: Martin Koegler
> ---
> diff-delta.c | 23 ---
> 1 file
On Mon, Aug 7, 2017 at 11:27 AM, Stefan Beller wrote:
> On Sun, Aug 6, 2017 at 6:47 PM, Shawn Pearce wrote:
>> 6th iteration of the reftable storage format.
>>
>> You can read a rendered version of this here:
>>
On 8/7/2017 2:17 PM, Jonathan Tan wrote:
On Mon, 7 Aug 2017 19:51:04 +0200
Lars Schneider wrote:
On 07 Aug 2017, at 19:21, Jonathan Tan wrote:
On Sun, 6 Aug 2017 21:58:24 +0200
Lars Schneider wrote:
+
On Sun, Aug 6, 2017 at 6:47 PM, Shawn Pearce wrote:
> 6th iteration of the reftable storage format.
>
> You can read a rendered version of this here:
> https://googlers.googlesource.com/sop/jgit/+/reftable/Documentation/technical/reftable.md
>
> Changes from v5:
> -
Since we're about to touch the behavior of --signed=, do this as a
preparatory step.
The documentation mentions --sign=, and it works. But that's just
because it's an unambiguous abbreviation of --signed, which is how it is
actually implemented. This was added in commit 30261094 ("push: support
When we want to parse a boolean config item without dying on error, we
call git_config_maybe_bool() which takes two arguments: the value to be
parsed (obviously) and a `name` which is completely ignored. Junio has
suggested to drop `name` and rename the function [1]. That effort even
started
Commit 9a549d43 ("config.c: rename git_config_maybe_bool_text and export
it as git_parse_maybe_bool", 2015-08-19) intended git_parse_maybe_bool
to be a replacement for git_config_maybe_bool, which could then be
retired. That is not obvious from the commit message, but that is what
the background
The only difference between these is that the former takes an argument
`name` which it ignores completely. Still, the callers are quite careful
to provide reasonable values for it.
Once in-flight topics have landed, we should be able to remove
git_config_maybe_bool. In the meantime, document it
When accepting booleans as command-line or config options throughout
Git, there are several documented synonyms for true and false.
However, one particular user is slightly broken: `git push --signed=..`
does not understand the integer synonyms for true and false.
This is hardly wanted. The
Both of these act on a string `value` which they parse as a boolean. The
"parse"-variant was introduced as a replacement for the "config"-variant
which for historical reasons takes an unused argument `name`. That it
was intended as a replacement is not obvious from commit 9a549d43
("config.c:
The previous commit left it unused.
Signed-off-by: Martin Ågren
---
builtin/log.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 9182f0ee3..483d15a94 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -58,7
Michael Forney writes:
> However, I still think the patch should be applied for
> self-consistency at least (git-submodule.sh currently calls both `git
> rev-parse` and `git-rev-parse`).
Oh, there is no question about the changes in the patch being good,
as I already said.
On Mon, 7 Aug 2017 19:51:04 +0200
Lars Schneider wrote:
>
> > On 07 Aug 2017, at 19:21, Jonathan Tan wrote:
> >
> > On Sun, 6 Aug 2017 21:58:24 +0200
> > Lars Schneider wrote:
> >
> >>> + struct cmd2process *entry
From: Martin Koegler
The current delta code produces incorrect pack objects for files > 4GB.
Signed-off-by: Martin Koegler
---
diff-delta.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Just pass any file >
On Mon, 07 Aug 2017 10:49:28 -0700
Junio C Hamano wrote:
> Phillip Wood writes:
>
> > From: Phillip Wood
> >
> > If there was no 'Signed-off-by:' trailer but another trailer such as
> > 'Reported-by:' then 'git am
On Aug 06 2017, Ævar Arnfjörð Bjarmason wrote:
> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
> index 0ef7b94394..0e2e57aa3d 100755
> --- a/t/t7004-tag.sh
> +++ b/t/t7004-tag.sh
> @@ -1887,7 +1887,7 @@ EOF"
> run_with_limited_stack git tag --contains HEAD >actual &&
>
On 8/7/17, Junio C Hamano wrote:
> Just to avoid possible confusion, the above is not to say "once it
> is decided, you are not allowed to bring fresh arguments to the
> discussion". As Peff said [*2*] in that old discussion thread, the
> circumstances may have changed over 9
> On 07 Aug 2017, at 19:21, Jonathan Tan wrote:
>
> On Sun, 6 Aug 2017 21:58:24 +0200
> Lars Schneider wrote:
>
>>> + struct cmd2process *entry = (struct cmd2process *)subprocess;
>>> + return subprocess_handshake(subprocess,
Phillip Wood writes:
> From: Phillip Wood
>
> If there was no 'Signed-off-by:' trailer but another trailer such as
> 'Reported-by:' then 'git am --signoff' would add a blank line between
> the existing trailers and the added
On 7 August 2017 at 19:10, Nicolas Morey-Chaisemartin
wrote:
>
>
> Le 07/08/2017 à 18:37, Martin Ågren a écrit :
>> On 7 August 2017 at 16:04, Nicolas Morey-Chaisemartin
>> wrote:
>>> Signed-off-by: Nicolas Morey-Chaisemartin
Ævar Arnfjörð Bjarmason writes:
> Change an argument to test_line_count (which'll ultimately be turned
> into a "test" expression) to use "-gt" instead of ">" for an
> arithmetic test.
>
> This broken on e.g. OpenBSD as of v2.13.0 with my commit
> ac3f5a3468 ("ref-filter: add
Am 07.08.2017 um 12:02 schrieb Johannes Schindelin:
On Sun, 6 Aug 2017, Johannes Sixt wrote:
Am 06.08.2017 um 01:00 schrieb Johannes Schindelin:
* Comes with [BusyBox v1.28.0pre.15857.9480dca7c](https://github.com/
git-for-windows/busybox-w32/commit/9480dca7c].
What is the
On Sun, 6 Aug 2017 21:58:24 +0200
Lars Schneider wrote:
> > + struct cmd2process *entry = (struct cmd2process *)subprocess;
> > + return subprocess_handshake(subprocess, "git-filter", versions, NULL,
> > + capabilities,
> > +
On 7 August 2017 at 19:04, Nicolas Morey-Chaisemartin
wrote:
>
>
> Le 07/08/2017 à 18:30, Martin Ågren a écrit :
>> On 7 August 2017 at 16:03, Nicolas Morey-Chaisemartin
>> wrote:
>>> Signed-off-by: Nicolas Morey-Chaisemartin
Junio C Hamano writes:
> Earlier there was a more ambitious proposal to remove all "git-foo"
> even from $GIT_EXEC_PATH for built-in commands, but that plan was
> scuttled [*1*].
>
> The changes in your patch still are good changes to make sure people
> who copy & paste code
Le 07/08/2017 à 18:30, Martin Ågren a écrit :
> On 7 August 2017 at 16:03, Nicolas Morey-Chaisemartin
> wrote:
>> Signed-off-by: Nicolas Morey-Chaisemartin
>> ---
>> imap-send.c | 38 --
>> 1
Le 07/08/2017 à 18:37, Martin Ågren a écrit :
> On 7 August 2017 at 16:04, Nicolas Morey-Chaisemartin
> wrote:
>> Signed-off-by: Nicolas Morey-Chaisemartin
>> ---
>> imap-send.c | 6 --
>> 1 file changed, 6 deletions(-)
>>
>>
Ævar Arnfjörð Bjarmason wrote:
On Mon, Aug 07 2017, James Wells jotted:
I am fairly new to git, however I have a challenge of upgrading git
from 2.0.4 to 2.4.12 and my initial 2.0.4 install was done via TAR
BALL on my server.
I have a centos server running git and Atlassian STASH and my
Le 07/08/2017 à 18:34, Martin Ågren a écrit :
> On 7 August 2017 at 16:04, Nicolas Morey-Chaisemartin
> wrote:
>> Signed-off-by: Nicolas Morey-Chaisemartin
>> ---
>> imap-send.c | 24
>> 1 file changed,
On 7 August 2017 at 16:04, Nicolas Morey-Chaisemartin
wrote:
> Signed-off-by: Nicolas Morey-Chaisemartin
> ---
> imap-send.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/imap-send.c b/imap-send.c
> index
Michael Forney writes:
> This way, they still work even if the built-in symlinks aren't
> installed.
>
> Signed-off-by: Michael Forney
> ---
> It looks like there was an effort to do this a number of years ago (through
> `make remove-dashes`). These are
On 7 August 2017 at 16:04, Nicolas Morey-Chaisemartin
wrote:
> Signed-off-by: Nicolas Morey-Chaisemartin
> ---
> imap-send.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git
On 7 August 2017 at 16:03, Nicolas Morey-Chaisemartin
wrote:
> Signed-off-by: Nicolas Morey-Chaisemartin
> ---
> imap-send.c | 38 --
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff
> -Original Message-
> From: Shawn Pearce [mailto:spea...@spearce.org]
> In git-core, I'm worried about the caveats related to locking. Git tries to
> work
> nicely on NFS, and it seems LMDB wouldn't. Git also runs fine on a read-only
> filesystem, and LMDB gets a little weird about that.
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index b2d0b849b..38b3c817e 100644
--- a/imap-send.c
+++ b/imap-send.c
On Mon, 2017-07-24 at 14:25 -0700, Junio C Hamano wrote:
> I suspect that with a moderately-sized refactoring around
> validate_new_branchname() function, this should be doable. Instead
> of passing two "int" parameters force and attr_only, make them into
> a single "unsigned flag"
I guess it's
On Sun, Aug 6, 2017 at 4:37 PM, Ben Alex wrote:
> Just on the LmdbJava specific pieces:
>
> On Mon, Aug 7, 2017 at 8:56 AM, Shawn Pearce wrote:
>>
>> Looks pretty complete. Its a Java wrapper around the C implementation
>> of LMDB, which may be
Signed-off-by: Kaartic Sivaraam
---
branch.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/branch.c b/branch.c
index ad5a2299b..a40721f3c 100644
--- a/branch.c
+++ b/branch.c
@@ -90,24 +90,24 @@ int install_branch_config(int
The '--set-upstream' option of branch was deprecated in,
b347d06bf branch: deprecate --set-upstream and show help if we detect
possible mistaken use (Thu, 30 Aug 2012 19:23:13 +0200)
It was deprecated for the reasons specified in the commit message of
the referenced commit.
Refactor
I refactored builtin/branch.c to remove the '--set-upstream'
option,successfully. The corresponding patch follows.
There's just one issue with the version of git that doesn't
have the '--set-upstream' option. It's described in the commit
log message of the following patch.
I guess it would be
On Wed, 2017-08-02 at 10:58 -0700, Stefan Beller wrote:
> That may be either a contributors problem (lacking time or
> motivation to go through a long document) or a problem with
> the community.
>
I'm trying to avoid the former.
> I would not want to explain the same thing over and
On Wed, 2017-08-02 at 09:01 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
> > On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote:
> > > So maybe we want to cut a lot of workflow related commendatory from
> > > the SubmitingPatches and then
Signed-off-by: Nicolas Morey-Chaisemartin
---
imap-send.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 90b8683ed..4ebc16437 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -35,13 +35,7 @@ typedef void *SSL;
#include
1 - 100 of 113 matches
Mail list logo