[PATCH] http-walker: remove unused parameter from fetch_object

[Eric Wong]

This parameter has not been used since commit 1d389ab65dc6
("Add support for parallel HTTP transfers") back in 2005

Signed-off-by: Eric Wong 
---
 I might followup in a few days/weeks with further updates in
 this area, but at least should be trivially correct :)

 http-walker.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/http-walker.c b/http-walker.c
index 2c721f0..9f28523 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -447,7 +447,7 @@ static void abort_object_request(struct object_request 
*obj_req)
release_object_request(obj_req);
 }
 
-static int fetch_object(struct walker *walker, struct alt_base *repo, unsigned 
char *sha1)
+static int fetch_object(struct walker *walker, unsigned char *sha1)
 {
char *hex = sha1_to_hex(sha1);
int ret = 0;
@@ -518,7 +518,7 @@ static int fetch(struct walker *walker, unsigned char *sha1)
struct walker_data *data = walker->data;
struct alt_base *altbase = data->alt;
 
-   if (!fetch_object(walker, altbase, sha1))
+   if (!fetch_object(walker, sha1))
return 0;
while (altbase) {
if (!http_fetch_pack(walker, altbase, sha1))
-- 
EW
--
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://vger.kernel.org/majordomo-info.html

Re: Dependencies required for offline installation

[brian m. carlson]

On Tue, Jul 05, 2016 at 09:53:15PM +0200, Dennis Kaarsemaker wrote:
> On di, 2016-07-05 at 14:06 -0400, Kevin Paxton wrote:
> > Thank you for the response.
> > 
> > I apologize. RHEL 6.5, not 5.5.
> 
> That's less ancient, but still not recommended. When using RHEL, try to
> stay with the latest point release so you get security updates.
> 
> > Would the same version be applicable to 6.5 as well as the
> > dependencies that you mentioned?
> 
> Red hat actually ships a version of git with RHEL 6.  So the 
> version will be different (I believe it's a 1.7.something). The
> dependencies should be similar, if not the same.

At $DAYJOB, we build and ship Git with our software, which runs on RHEL
6 and 7.  I'd have to check to be certain, but I'm pretty sure the
dependencies for core Git are the same as Red Hat's version.  We choose
to compile with PCRE because it enables git grep -P, which we use in
development.  If you want git-svn, you'll of course need subversion.

In case you do move back to RHEL 5 (which I don't recommend), be aware
that the libcurl version is old enough that some features (DAV is one,
if I remember correctly) don't work.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Fwd: git rm

[Peter]

Greetings to the community of this wonderful piece of software!


I am a lightweigt git user so by all means not a reference, but I was
wondering why exactly does "git rm" also delete the file (remove it
from the working tree). I see it as an unintended behaviour as git is
written in a way that it preserves the most data. Usually git commands
are very basic and the usual workflow requires more consecutive
commands, it even has its own shell. But "git rm" does everything in
one step even though there are lots of scenarios where the file should
be kept. I am aware of the "git rm --cache" command, but from my
perspective "git rm --delete" is the one that is needed...

GUI users and some CLI users (by using trash-put or similar tool) also
use trash before removing the file completely. Does "git rm" support
freedesktop.org trash specification?


Thank you for your answers in advance,
Peter
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

[Jacob Keller]

On Tue, Jul 5, 2016 at 1:44 PM, Jeff King  wrote:
> On Tue, Jul 05, 2016 at 04:28:20PM -0400, Jeff King wrote:
>
>> I wonder if parse_options_concat should simply allocate a new list
>> (after computing the total required size). I guess this is the only
>> caller, though, so perhaps it's not the end of the world. In the
>> meantime, your patch is certainly an improvement.
>
> Something like the patch below.
>
> I admit this isn't buggy _now_, so this is potentially just churn. It
> does make further patches look nicer, though (they don't have to add
> apparently meaningless OPT_END() slots).
>
> -- >8 --
> Subject: [PATCH] parse_options: allocate a new array when concatenating
>
> In exactly one callers (builtin/revert.c), we build up the
> options list dynamically from multiple arrays. We do so by
> manually inserting "filler" entries into one array, and then
> copying the other array into the allocated space.
>
> This is tedious and error-prone, as you have to adjust the
> filler any time the second array is modified (although we do
> at least check and die() when the counts do not match up).
>
> Instead, let's just allocate a new array.

This seems much preferable to me.

>
> Signed-off-by: Jeff King 
> ---
>  builtin/revert.c   | 13 -
>  parse-options-cb.c | 29 +
>  parse-options.h|  2 +-
>  3 files changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/builtin/revert.c b/builtin/revert.c
> index 56a2c36..4e69380 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -76,7 +76,7 @@ static void parse_args(int argc, const char **argv, struct 
> replay_opts *opts)
> const char * const * usage_str = revert_or_cherry_pick_usage(opts);
> const char *me = action_name(opts);
> int cmd = 0;
> -   struct option options[] = {
> +   struct option base_options[] = {
> OPT_CMDMODE(0, "quit", , N_("end revert or cherry-pick 
> sequence"), 'q'),
> OPT_CMDMODE(0, "continue", , N_("resume revert or 
> cherry-pick sequence"), 'c'),
> OPT_CMDMODE(0, "abort", , N_("cancel revert or 
> cherry-pick sequence"), 'a'),
> @@ -91,13 +91,9 @@ static void parse_args(int argc, const char **argv, struct 
> replay_opts *opts)
> N_("option for merge strategy"), option_parse_x),
> { OPTION_STRING, 'S', "gpg-sign", >gpg_sign, 
> N_("key-id"),
>   N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) 
> "" },
> -   OPT_END(),
> -   OPT_END(),
> -   OPT_END(),
> -   OPT_END(),
> -   OPT_END(),
> -   OPT_END(),
> +   OPT_END()
> };
> +   struct option *options = base_options;
>
> if (opts->action == REPLAY_PICK) {
> struct option cp_extra[] = {
> @@ -108,8 +104,7 @@ static void parse_args(int argc, const char **argv, 
> struct replay_opts *opts)
> OPT_BOOL(0, "keep-redundant-commits", 
> >keep_redundant_commits, N_("keep redundant, empty commits")),
> OPT_END(),
> };
> -   if (parse_options_concat(options, ARRAY_SIZE(options), 
> cp_extra))
> -   die(_("program error"));
> +   options = parse_options_concat(options, cp_extra);
> }
>
> argc = parse_options(argc, argv, NULL, options, usage_str,
> diff --git a/parse-options-cb.c b/parse-options-cb.c
> index 239898d..2d87520 100644
> --- a/parse-options-cb.c
> +++ b/parse-options-cb.c
> @@ -117,19 +117,24 @@ int parse_opt_tertiary(const struct option *opt, const 
> char *arg, int unset)
> return 0;
>  }
>
> -int parse_options_concat(struct option *dst, size_t dst_size, struct option 
> *src)
> +struct option *parse_options_concat(struct option *a, struct option *b)
>  {
> -   int i, j;
> -
> -   for (i = 0; i < dst_size; i++)
> -   if (dst[i].type == OPTION_END)
> -   break;
> -   for (j = 0; i < dst_size; i++, j++) {
> -   dst[i] = src[j];
> -   if (src[j].type == OPTION_END)
> -   return 0;
> -   }
> -   return -1;
> +   struct option *ret;
> +   size_t i, a_len = 0, b_len = 0;
> +
> +   for (i = 0; a[i].type != OPTION_END; i++)
> +   a_len++;
> +   for (i = 0; b[i].type != OPTION_END; i++)
> +   b_len++;
> +
> +   ALLOC_ARRAY(ret, st_add3(a_len, b_len, 1));
> +   for (i = 0; i < a_len; i++)
> +   ret[i] = a[i];
> +   for (i = 0; i < b_len; i++)
> +   ret[a_len + i] = b[i];
> +   ret[a_len + b_len] = b[b_len]; /* final OPTION_END */
> +
> +   return ret;
>  }
>
>  int parse_opt_string_list(const struct option *opt, const char *arg, int 
> unset)
> diff --git a/parse-options.h b/parse-options.h
> index ea4af92..78f8384 100644
> --- 

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

[Jeff King]

On Tue, Jul 05, 2016 at 04:28:20PM -0400, Jeff King wrote:

> I wonder if parse_options_concat should simply allocate a new list
> (after computing the total required size). I guess this is the only
> caller, though, so perhaps it's not the end of the world. In the
> meantime, your patch is certainly an improvement.

Something like the patch below.

I admit this isn't buggy _now_, so this is potentially just churn. It
does make further patches look nicer, though (they don't have to add
apparently meaningless OPT_END() slots).

-- >8 --
Subject: [PATCH] parse_options: allocate a new array when concatenating

In exactly one callers (builtin/revert.c), we build up the
options list dynamically from multiple arrays. We do so by
manually inserting "filler" entries into one array, and then
copying the other array into the allocated space.

This is tedious and error-prone, as you have to adjust the
filler any time the second array is modified (although we do
at least check and die() when the counts do not match up).

Instead, let's just allocate a new array.

Signed-off-by: Jeff King 
---
 builtin/revert.c   | 13 -
 parse-options-cb.c | 29 +
 parse-options.h|  2 +-
 3 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/builtin/revert.c b/builtin/revert.c
index 56a2c36..4e69380 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -76,7 +76,7 @@ static void parse_args(int argc, const char **argv, struct 
replay_opts *opts)
const char * const * usage_str = revert_or_cherry_pick_usage(opts);
const char *me = action_name(opts);
int cmd = 0;
-   struct option options[] = {
+   struct option base_options[] = {
OPT_CMDMODE(0, "quit", , N_("end revert or cherry-pick 
sequence"), 'q'),
OPT_CMDMODE(0, "continue", , N_("resume revert or 
cherry-pick sequence"), 'c'),
OPT_CMDMODE(0, "abort", , N_("cancel revert or cherry-pick 
sequence"), 'a'),
@@ -91,13 +91,9 @@ static void parse_args(int argc, const char **argv, struct 
replay_opts *opts)
N_("option for merge strategy"), option_parse_x),
{ OPTION_STRING, 'S', "gpg-sign", >gpg_sign, N_("key-id"),
  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" 
},
-   OPT_END(),
-   OPT_END(),
-   OPT_END(),
-   OPT_END(),
-   OPT_END(),
-   OPT_END(),
+   OPT_END()
};
+   struct option *options = base_options;
 
if (opts->action == REPLAY_PICK) {
struct option cp_extra[] = {
@@ -108,8 +104,7 @@ static void parse_args(int argc, const char **argv, struct 
replay_opts *opts)
OPT_BOOL(0, "keep-redundant-commits", 
>keep_redundant_commits, N_("keep redundant, empty commits")),
OPT_END(),
};
-   if (parse_options_concat(options, ARRAY_SIZE(options), 
cp_extra))
-   die(_("program error"));
+   options = parse_options_concat(options, cp_extra);
}
 
argc = parse_options(argc, argv, NULL, options, usage_str,
diff --git a/parse-options-cb.c b/parse-options-cb.c
index 239898d..2d87520 100644
--- a/parse-options-cb.c
+++ b/parse-options-cb.c
@@ -117,19 +117,24 @@ int parse_opt_tertiary(const struct option *opt, const 
char *arg, int unset)
return 0;
 }
 
-int parse_options_concat(struct option *dst, size_t dst_size, struct option 
*src)
+struct option *parse_options_concat(struct option *a, struct option *b)
 {
-   int i, j;
-
-   for (i = 0; i < dst_size; i++)
-   if (dst[i].type == OPTION_END)
-   break;
-   for (j = 0; i < dst_size; i++, j++) {
-   dst[i] = src[j];
-   if (src[j].type == OPTION_END)
-   return 0;
-   }
-   return -1;
+   struct option *ret;
+   size_t i, a_len = 0, b_len = 0;
+
+   for (i = 0; a[i].type != OPTION_END; i++)
+   a_len++;
+   for (i = 0; b[i].type != OPTION_END; i++)
+   b_len++;
+
+   ALLOC_ARRAY(ret, st_add3(a_len, b_len, 1));
+   for (i = 0; i < a_len; i++)
+   ret[i] = a[i];
+   for (i = 0; i < b_len; i++)
+   ret[a_len + i] = b[i];
+   ret[a_len + b_len] = b[b_len]; /* final OPTION_END */
+
+   return ret;
 }
 
 int parse_opt_string_list(const struct option *opt, const char *arg, int unset)
diff --git a/parse-options.h b/parse-options.h
index ea4af92..78f8384 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -215,7 +215,7 @@ extern int parse_options_step(struct parse_opt_ctx_t *ctx,
 
 extern int parse_options_end(struct parse_opt_ctx_t *ctx);
 
-extern int parse_options_concat(struct option *dst, size_t, struct option 
*src);
+extern struct option *parse_options_concat(struct option *a, struct option *b);
 
 /*- 

Hello..

[Meirit Leeba]

-- 
Hello,

Can i talk with you..?
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] Refactor recv_sideband()

[Nicolas Pitre]

On Wed, 29 Jun 2016, Junio C Hamano wrote:

> Nicolas Pitre  writes:
> 
> > To make it clearer, here's a patch on top of pu that fixes all the 
> > issues I think are remaining. All tests pass now.
> 
> Lukas, can you see what is in 'pu' after I push out today's
> integration result in several hours and tell us if you like the
> result of the SQUASH??? change?

Here's a patch on top of it providing small optimizations.

- >8
Subject: sideband.c: small optimization of strbuf usage

Signed-off-by: Nicolas Pitre 

diff --git a/sideband.c b/sideband.c
index 3cf3ced..b7e196b 100644
--- a/sideband.c
+++ b/sideband.c
@@ -68,12 +68,12 @@ int recv_sideband(const char *me, int in_stream, int out)
int linelen = brk - b;
 
if (!outbuf.len)
-   strbuf_addf(, "%s", PREFIX);
+   strbuf_addstr(, PREFIX);
if (linelen > 0) {
strbuf_addf(, "%.*s%s%c",
linelen, b, suffix, *brk);
} else {
-   strbuf_addf(, "%c", *brk);
+   strbuf_addch(, *brk);
}
xwrite(2, outbuf.buf, outbuf.len);
strbuf_reset();
@@ -97,7 +97,7 @@ int recv_sideband(const char *me, int in_stream, int out)
}
 
if (outbuf.len) {
-   strbuf_addf(, "\n");
+   strbuf_addch(, "\n");
xwrite(2, outbuf.buf, outbuf.len);
}
strbuf_release();
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH] revert: clarify seemingly bogus OPT_END repetition

[Jeff King]

On Tue, Jul 05, 2016 at 01:58:51PM +0200, Johannes Schindelin wrote:

> This developer stumbled over repeated OPT_END entries and was *so
> close* (almost touches his thumb with his index finger) to collapse
> them into a single one. Only inspecting the file's history with
> `git log -p -SOPT_END` clarified why they are there.

Wow, that's really ugly, and confused me, too.

I've been trying to move us away from this kind of manually-computed
array size, simply because it's error-prone and often not obviously
correct[1].

I wonder if parse_options_concat should simply allocate a new list
(after computing the total required size). I guess this is the only
caller, though, so perhaps it's not the end of the world. In the
meantime, your patch is certainly an improvement.

By the way, I notice that the error message when concat fails is just:

  if (parse_options_concat(options, ARRAY_SIZE(options), cp_extra))
die(_("program error"));

Should this become:

die("BUG: not enough room to concatenate options");

as part of your BUG cleanups elsewhere?

-Peff

[1] At least the concat interface takes ARRAY_SIZE(), so that we will
catch an error, rather than silently causing memory corruption. A
much more likely error is to forget OPT_END(), which will cause
parse_options to read past the end of the array.
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] index-pack: correct "len" type in unpack_data()

[Johannes Sixt]

Am 05.07.2016 um 19:05 schrieb Nguyễn Thái Ngọc Duy:

+   die(Q_("premature end of pack file, %"PRIuMAX" byte 
missing",
+  "premature end of pack file, %"PRIuMAX" bytes 
missing",


I would be surprised if this form of translation worked...


+  (unsigned int)len),
+   (uintmax_t)len);


-- Hannes

--
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://vger.kernel.org/majordomo-info.html

Re: Dependencies required for offline installation

[Dennis Kaarsemaker]

On di, 2016-07-05 at 14:06 -0400, Kevin Paxton wrote:
> Thank you for the response.
> 
> I apologize. RHEL 6.5, not 5.5.

That's less ancient, but still not recommended. When using RHEL, try to
stay with the latest point release so you get security updates.

> Would the same version be applicable to 6.5 as well as the
> dependencies that you mentioned?

Red hat actually ships a version of git with RHEL 6.  So the 
version will be different (I believe it's a 1.7.something). The
dependencies should be similar, if not the same.

> On Tue, Jul 5, 2016 at 1:53 PM, Dennis Kaarsemaker
>  wrote:
> > 
> > On di, 2016-07-05 at 07:45 -0400, Kevin Paxton wrote:
> > > 
> > > Hi,
> > > 
> > > I’m looking to install git on a separate network that is running
> > > Redhat 5.5.
> > That's ancient and unsupported. If you insist on using rhel 5, at
> > least
> > do 5.11 so you get the security updates.
> > 
> > > 
> > > I need to know what is the list of packages that I need to
> > > download to be able to install git-all? I plan on using git-svn
> > > to
> > > migrate an existing svn repo over to git as well. Svn version we
> > > have
> > > installed is 1.9.3.
> > There are rpms for git 1.8 in EPEL. git-all is probably overkill,
> > but
> > you'll need at least git, perl-Git, perl-Git-SVN and perl-Error.
> > 
> > > 
> > > Does the tarball contain all dependencies already? Should I go
> > > that
> > > route? Or should I try and find all the rpm's required?
> > The source tarball of git contains no dependencies. Also be aware
> > that
> > building git from source requires even more dependencies.
> > 
> > D.
--
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://vger.kernel.org/majordomo-info.html

[PATCH] difftool: fix argument handling in subdirs

[John Keeping]

On Mon, Jul 04, 2016 at 08:37:39PM +0200, Bernhard Kirchen wrote:
> Today I started using --dir-diff and noticed a problem when specifying a
> non-full path limiter. My diff tool is setup to be meld (*1).
> 
> OK while working directory is repo root; also OK while working directory is
> repo subfolder "actual":
> git difftool --dir-diff HEAD~1 HEAD -- actual/existing/path
> => meld opens with proper dir-diff.
> 
> NOT OK while working directory is repo subfolder "actual":
> git difftool --dir-diff HEAD~1 HEAD -- existing/path
> => nothing happens, as if using "non/such/path" as the path limiter.
> 
> Because "git diff HEAD~1 HEAD -- existing/path" while the working directory
> is the repo subfolder "actual" works, I epxected the difftool to work
> similarly. Is this a bug?

I think it is, yes.  The patch below fixes it for me and doesn't break
any existing tests, but I still don't understand why the separate
$diffrepo was needed originally, so I'm not certain this won't break
some other corner case.

-- >8 --
When in a subdirectory of a repository, path arguments should be
interpreted relative to the current directory not the root of the
working tree.

The Git::repository object passed into setup_dir_diff() is configured to
handle this correctly but we create a new Git::repository here without
setting the WorkingSubdir argument.  By simply using the existing
repository, path arguments are handled relative to the current
directory.

Signed-off-by: John Keeping 
---
 git-difftool.perl | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/git-difftool.perl b/git-difftool.perl
index ebd13ba..c9d3ef8 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -115,16 +115,9 @@ sub setup_dir_diff
 {
my ($repo, $workdir, $symlinks) = @_;
 
-   # Run the diff; exit immediately if no diff found
-   # 'Repository' and 'WorkingCopy' must be explicitly set to insure that
-   # if $GIT_DIR and $GIT_WORK_TREE are set in ENV, they are actually used
-   # by Git->repository->command*.
my $repo_path = $repo->repo_path();
-   my %repo_args = (Repository => $repo_path, WorkingCopy => $workdir);
-   my $diffrepo = Git->repository(%repo_args);
-
my @gitargs = ('diff', '--raw', '--no-abbrev', '-z', @ARGV);
-   my $diffrtn = $diffrepo->command_oneline(@gitargs);
+   my $diffrtn = $repo->command_oneline(@gitargs);
exit(0) unless defined($diffrtn);
 
# Build index info for left and right sides of the diff
@@ -176,12 +169,12 @@ EOF
 
if ($lmode eq $symlink_mode) {
$symlink{$src_path}{left} =
-   $diffrepo->command_oneline('show', "$lsha1");
+   $repo->command_oneline('show', "$lsha1");
}
 
if ($rmode eq $symlink_mode) {
$symlink{$dst_path}{right} =
-   $diffrepo->command_oneline('show', "$rsha1");
+   $repo->command_oneline('show', "$rsha1");
}
 
if ($lmode ne $null_mode and $status !~ /^C/) {
-- 
2.9.0.465.g8850cbc

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

[Christoph Michelbach]

Thank you very much!

-- 
With kind regards
Christoph Michelbach

On Tue, 2016-07-05 at 19:05 +0200, Nguyễn Thái Ngọc Duy wrote:
> Since I now could reproduce the problem that Christoph showed, I
> decided to send the good patches out. To sum up, we use "unsigned
> long" in some places related to file size. On 32-bit systems, it's
> limited to 32 bits even though the system can handle files larger
> than
> that (off_t is 64-bit). This fixes it.
> 
> clang -Wshorten-64-to-32 is very helpful to spot these problems. I
> have a couple more patches to clean all these warnings, but some need
> more code study to see what is the right way to do.
> 
> Most of the rest seems harmless, except for the local variable "size"
> in builtin/pack-objects.c:write_one(). I might send 6/5 for that one.
> 
> Nguyễn Thái Ngọc Duy (5):
>   pack-objects: pass length to check_pack_crc() without truncation
>   sha1_file.c: use type off_t* for object_info->disk_sizep
>   index-pack: correct "len" type in unpack_data()
>   index-pack: report correct bad object offsets even if they are
> large
>   index-pack: correct "offset" type in unpack_entry_data()
> 
>  builtin/cat-file.c |  4 ++--
>  builtin/index-pack.c   | 23 ---
>  builtin/pack-objects.c |  2 +-
>  cache.h|  2 +-
>  sha1_file.c|  2 +-
>  5 files changed, 17 insertions(+), 16 deletions(-)
> 
--
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://vger.kernel.org/majordomo-info.html

Re: Dependencies required for offline installation

[Konstantin Khomoutov]

On Tue, 5 Jul 2016 07:45:12 -0400
Kevin Paxton  wrote:

> I’m looking to install git on a separate network that is running
> Redhat 5.5. I need to know what is the list of packages that I need to
> download to be able to install git-all? I plan on using git-svn to
> migrate an existing svn repo over to git as well. Svn version we have
> installed is 1.9.3.
> 
> Does the tarball contain all dependencies already?

No, it does not.  It depends on a few of external libraries (and
software packages) -- check it out yourself at [1].

It should be noted though that this list is not fixed.
IIUC the only hard dependency is zlib and all the other stuff is
optional.  SSH transport is implemented by calling an OpenSSH (or
compatible) client program, so this is a soft dependency.

Note that in your case you will need to have Perl 5.8+ because it's
used by the git-svn implementation, and that will use the Perl bindings
for Subversion (which, in turn, depend on both Perl and libsvn).
You'll need to have that stuff available and installed as well.

> Should I go that route?
> Or should I try and find all the rpm's required?

It's hard to tell.

RH 5.5 appears to be really really old so it's unlikely you'll find
official RPMs for recent Git versions.  You might try to look them up
in unofficial 3rd-party repos maintained by those who need to support
outdated systems.

This might get further complicated by the fact you appear to have
non-standard Subversion package (too fresh for RH 5.5 IMO).

Failing that, I'd have a VM running RH 5.5 and tried to build a set of
RPMs against the software packages you have deployed on the target
system.  The RPM specs can be grabbed from any up-to-date Redhatoid
system and backported.

1. https://github.com/git/git/blob/master/INSTALL
--
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://vger.kernel.org/majordomo-info.html

Re: Missing Package in git Installation Instructions (git-scm.com)

[Christoph Michelbach]

Thank you both!

I cloned the repository to fix it yet found it already fixed so assumed
either of you did that. But according to git blame, that line was last
touched 94 days ago by Yue Lin Ho and they made exactly that change. It
seems to take a long time until they publish it on the website.

-- 
With kind regards
Christoph Michelbach

On Tue, 2016-07-05 at 15:24 +0200, Jakub Narębski wrote:
> W dniu 2016-07-05 o 08:10, Johannes Schindelin pisze:
> > 
> > Hi Chris,
> > 
> > On Tue, 5 Jul 2016, Christoph Michelbach wrote:
> > 
> > > 
> > > Hi, I noticed that the instructions on https://git-scm.com/book/e
> > > n/v2/G
> > > etting-Started-Installing-Git don't work without dh-autoreconf
> > > installed on an apt-get system which isn't listed on that site.
> > > Can you
> > > fix that or tell me whom to tell about this? The website doesn't
> > > offer
> > > contact information. Just tried this on a fresh Ubuntu 16.04
> > > installation.
> > When you follow that link, do you see this text on the left side?
> > 
> > The source of this book is hosted on GitHub.
> > Patches, suggestions and comments are welcome.
> > 
> > It links to https://github.com/progit/progit2 and I am sure your
> > bug
> > report would make an excellent contribution to the bug tracker
> > ("Issues")
> > in that repository.
> > 
> > It would probably be even better if you cloned said repository,
> > found the
> > respective file via `git grep apt-get`, fixed it, and opened a Pull
> > Request.
> Or you can even fix it from a web interface, if you have a GitHub
> account.
> Behind the scene, GitHub would fork a repository, edit file and
> create
> a commit, then create a pull request.  Very easy for one-off fixes,
> assuming
> that you have a GitHub account.
> 
--
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://vger.kernel.org/majordomo-info.html

Re: Dependencies required for offline installation

[Kevin Paxton]

Thank you for the response.

I apologize. RHEL 6.5, not 5.5.

Would the same version be applicable to 6.5 as well as the
dependencies that you mentioned?

On Tue, Jul 5, 2016 at 1:53 PM, Dennis Kaarsemaker
 wrote:
> On di, 2016-07-05 at 07:45 -0400, Kevin Paxton wrote:
>> Hi,
>>
>> I’m looking to install git on a separate network that is running
>> Redhat 5.5.
>
> That's ancient and unsupported. If you insist on using rhel 5, at least
> do 5.11 so you get the security updates.
>
>> I need to know what is the list of packages that I need to
>> download to be able to install git-all? I plan on using git-svn to
>> migrate an existing svn repo over to git as well. Svn version we have
>> installed is 1.9.3.
>
> There are rpms for git 1.8 in EPEL. git-all is probably overkill, but
> you'll need at least git, perl-Git, perl-Git-SVN and perl-Error.
>
>> Does the tarball contain all dependencies already? Should I go that
>> route? Or should I try and find all the rpm's required?
>
> The source tarball of git contains no dependencies. Also be aware that
> building git from source requires even more dependencies.
>
> D.
--
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://vger.kernel.org/majordomo-info.html

[PATCH 4/5] index-pack: report correct bad object offsets even if they are large

[Nguyễn Thái Ngọc Duy]

Use the right type for offsets in this case, off_t, which makes a
difference on 32-bit systems with large file support, and change
formatting code accordingly.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 builtin/index-pack.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index cafaab7..73f7cd2 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -338,10 +338,10 @@ static void parse_pack_header(void)
use(sizeof(struct pack_header));
 }
 
-static NORETURN void bad_object(unsigned long offset, const char *format,
+static NORETURN void bad_object(off_t offset, const char *format,
   ...) __attribute__((format (printf, 2, 3)));
 
-static NORETURN void bad_object(unsigned long offset, const char *format, ...)
+static NORETURN void bad_object(off_t offset, const char *format, ...)
 {
va_list params;
char buf[1024];
@@ -349,7 +349,8 @@ static NORETURN void bad_object(unsigned long offset, const 
char *format, ...)
va_start(params, format);
vsnprintf(buf, sizeof(buf), format, params);
va_end(params);
-   die(_("pack has bad object at offset %lu: %s"), offset, buf);
+   die(_("pack has bad object at offset %"PRIiMAX": %s"),
+   (intmax_t)offset, buf);
 }
 
 static inline struct thread_local *get_thread_data(void)
-- 
2.8.2.537.g0965dd9

--
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://vger.kernel.org/majordomo-info.html

[PATCH 2/5] sha1_file.c: use type off_t* for object_info->disk_sizep

[Nguyễn Thái Ngọc Duy]

This field, filled by sha1_object_info() contains the on-disk size of
an object, which could go over 4GB limit of unsigned long on 32-bit
systems. Use off_t for it instead and update all callers.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 builtin/cat-file.c | 4 ++--
 cache.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 618103f..5b34bd0 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -131,7 +131,7 @@ struct expand_data {
unsigned char sha1[20];
enum object_type type;
unsigned long size;
-   unsigned long disk_size;
+   off_t disk_size;
const char *rest;
unsigned char delta_base_sha1[20];
 
@@ -191,7 +191,7 @@ static void expand_atom(struct strbuf *sb, const char 
*atom, int len,
if (data->mark_query)
data->info.disk_sizep = >disk_size;
else
-   strbuf_addf(sb, "%lu", data->disk_size);
+   strbuf_addf(sb, "%"PRIuMAX, data->disk_size);
} else if (is_atom("rest", atom, len)) {
if (data->mark_query)
data->split_on_whitespace = 1;
diff --git a/cache.h b/cache.h
index c73becb..a4465cb 100644
--- a/cache.h
+++ b/cache.h
@@ -1508,7 +1508,7 @@ struct object_info {
/* Request */
enum object_type *typep;
unsigned long *sizep;
-   unsigned long *disk_sizep;
+   off_t *disk_sizep;
unsigned char *delta_base_sha1;
struct strbuf *typename;
 
-- 
2.8.2.537.g0965dd9

--
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://vger.kernel.org/majordomo-info.html

[PATCH 3/5] index-pack: correct "len" type in unpack_data()

[Nguyễn Thái Ngọc Duy]

On 32-bit systems with large file support, one entry could be larger
than 4GB and overflow "len". Correct it so we can unpack a full entry.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 builtin/index-pack.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index e8c71fc..cafaab7 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -549,13 +549,13 @@ static void *unpack_data(struct object_entry *obj,
 void *cb_data)
 {
off_t from = obj[0].idx.offset + obj[0].hdr_size;
-   unsigned long len = obj[1].idx.offset - from;
+   off_t len = obj[1].idx.offset - from;
unsigned char *data, *inbuf;
git_zstream stream;
int status;
 
data = xmallocz(consume ? 64*1024 : obj->size);
-   inbuf = xmalloc((len < 64*1024) ? len : 64*1024);
+   inbuf = xmalloc((len < 64*1024) ? (int)len : 64*1024);
 
memset(, 0, sizeof(stream));
git_inflate_init();
@@ -563,15 +563,15 @@ static void *unpack_data(struct object_entry *obj,
stream.avail_out = consume ? 64*1024 : obj->size;
 
do {
-   ssize_t n = (len < 64*1024) ? len : 64*1024;
+   ssize_t n = (len < 64*1024) ? (ssize_t)len : 64*1024;
n = xpread(get_thread_data()->pack_fd, inbuf, n, from);
if (n < 0)
die_errno(_("cannot pread pack file"));
if (!n)
-   die(Q_("premature end of pack file, %lu byte missing",
-  "premature end of pack file, %lu bytes missing",
-  len),
-   len);
+   die(Q_("premature end of pack file, %"PRIuMAX" byte 
missing",
+  "premature end of pack file, %"PRIuMAX" bytes 
missing",
+  (unsigned int)len),
+   (uintmax_t)len);
from += n;
len -= n;
stream.next_in = inbuf;
-- 
2.8.2.537.g0965dd9

--
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://vger.kernel.org/majordomo-info.html

[PATCH 5/5] index-pack: correct "offset" type in unpack_entry_data()

[Nguyễn Thái Ngọc Duy]

unpack_entry_data() receives an off_t value from unpack_raw_entry(),
which could be larger than unsigned long on 32-bit systems with large
file support. Correct the type so truncation does not happen. This
only affects bad object reporting though.

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 builtin/index-pack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 73f7cd2..f35a9dc 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -430,7 +430,7 @@ static int is_delta_type(enum object_type type)
return (type == OBJ_REF_DELTA || type == OBJ_OFS_DELTA);
 }
 
-static void *unpack_entry_data(unsigned long offset, unsigned long size,
+static void *unpack_entry_data(off_t offset, unsigned long size,
   enum object_type type, unsigned char *sha1)
 {
static char fixed_buf[8192];
-- 
2.8.2.537.g0965dd9

--
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://vger.kernel.org/majordomo-info.html

[PATCH 1/5] pack-objects: pass length to check_pack_crc() without truncation

[Nguyễn Thái Ngọc Duy]

On 32 bit systems with large file support, unsigned long is 32-bit
while the two offsets in the subtraction expression (pack-objects has
the exact same expression as in sha1_file.c but not shown in diff) are
in 64-bit. If an in-pack object is larger than 2^32 len/datalen is
truncated and we get a misleading "error: bad packed object CRC for
..." as a result.

Use off_t for len and datalen. check_pack_crc() already accepts this
argument as off_t and can deal with 4+ GB.

Noticed-by: Christoph Michelbach 
Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 builtin/pack-objects.c | 2 +-
 sha1_file.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 8f5e358..df6ecd5 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -349,7 +349,7 @@ static unsigned long write_reuse_object(struct sha1file *f, 
struct object_entry
struct revindex_entry *revidx;
off_t offset;
enum object_type type = entry->type;
-   unsigned long datalen;
+   off_t datalen;
unsigned char header[10], dheader[10];
unsigned hdrlen;
 
diff --git a/sha1_file.c b/sha1_file.c
index d5e1121..cb571ac 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2281,7 +2281,7 @@ void *unpack_entry(struct packed_git *p, off_t obj_offset,
 
if (do_check_packed_object_crc && p->index_version > 1) {
struct revindex_entry *revidx = find_pack_revindex(p, 
obj_offset);
-   unsigned long len = revidx[1].offset - obj_offset;
+   off_t len = revidx[1].offset - obj_offset;
if (check_pack_crc(p, _curs, obj_offset, len, 
revidx->nr)) {
const unsigned char *sha1 =
nth_packed_object_sha1(p, revidx->nr);
-- 
2.8.2.537.g0965dd9

--
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://vger.kernel.org/majordomo-info.html

[PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

[Nguyễn Thái Ngọc Duy]

Since I now could reproduce the problem that Christoph showed, I
decided to send the good patches out. To sum up, we use "unsigned
long" in some places related to file size. On 32-bit systems, it's
limited to 32 bits even though the system can handle files larger than
that (off_t is 64-bit). This fixes it.

clang -Wshorten-64-to-32 is very helpful to spot these problems. I
have a couple more patches to clean all these warnings, but some need
more code study to see what is the right way to do.

Most of the rest seems harmless, except for the local variable "size"
in builtin/pack-objects.c:write_one(). I might send 6/5 for that one.

Nguyễn Thái Ngọc Duy (5):
  pack-objects: pass length to check_pack_crc() without truncation
  sha1_file.c: use type off_t* for object_info->disk_sizep
  index-pack: correct "len" type in unpack_data()
  index-pack: report correct bad object offsets even if they are large
  index-pack: correct "offset" type in unpack_entry_data()

 builtin/cat-file.c |  4 ++--
 builtin/index-pack.c   | 23 ---
 builtin/pack-objects.c |  2 +-
 cache.h|  2 +-
 sha1_file.c|  2 +-
 5 files changed, 17 insertions(+), 16 deletions(-)

-- 
2.8.2.537.g0965dd9

--
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://vger.kernel.org/majordomo-info.html

Re: reflogs and worktrees?

[Duy Nguyen]

On Tue, Jul 5, 2016 at 5:07 PM, Johannes Schindelin
 wrote:
> Hi Duy,
>
> ever since I started working extensively with worktrees, I end up with
> these funny gc problems, like broken links and stale reflogs.

Yeah we have problem with gc not traversing all worktree refs. I had
something that could fix it temporarily [1] but the decision was to
wait for refs code to support new "worktree storage" so that we can
walk worktree refs properly, then fix gc [2]. We should get pretty
close to that point after [3] lands.

[1] http://thread.gmane.org/gmane.comp.version-control.git/295961/focus=296076
[2] http://thread.gmane.org/gmane.comp.version-control.git/295961/focus=296219
[3] http://thread.gmane.org/gmane.comp.version-control.git/296409

> Is it maybe possible that the reflogs (which are per-worktree now) are not
> traversed completely when gc'ing (which is *not* per-worktree)?
-- 
Duy
--
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://vger.kernel.org/majordomo-info.html

FEDEX DELIEVERY

[fedEx Express]

Sehr geehrter Kunde,
Sie haben ein Paket von FedEx am Samstag, den 7. März 2015 um 13:16 Uhr Uhr
Wir haben darauf gewartet, dass Sie uns für Ihre Bestätigte Paket zu 
kontaktieren, die unser Büro angekommen zu Ihrem Land ansässigen Versand. Das 
Paket wurde von Herrn John "Jack" Lange geschickt, der 24. September eine 
Lotterie in den Vereinigten Staat gewonnen, 2014 in Kalifornien. Sie wurden per 
E-Mail als eine seiner Spende Gewinner der Wahl Ihrer Familie und Ihrem Land zu 
helfen. Er sagte auch, in seinem Dokument, dass er dieses Angebot gibt, weil er 
alt ist und er keine andere Wahl haben, als die Welt zu helfen, weil er sehr 
alt ist.

Klirren diesen Link Herr John "Jack" Lange auf Sie es sehen können

http://www.powerball.com/powerball/winners/2014/071914CA_Long.shtml

Bitte füllen und das unten stehende Formular für Ihre Lieferung abzuschließen.

Dies ist obligatorisch, Ihre Postanschrift und Telefonnummern zu bestätigen.

GANZE NAMEN:
TELEFON:
ANSCHRIFT:
STADT:
BUNDESLAND:
LAND:

Die oben angeforderten Informationen ist wird es uns ermöglichen, Ihr Paket 
liefern korrekt und ohne Fehler oder Ihr Paket an eine falsche Person zu 
liefern.

Zu Ihrer Information, lädt die Mehrwertsteuer und Versand sowie 
Bearbeitungsgebühren wurden von John "Jack" Lange bevor Ihr Paket registriert 
wurde, gezahlt worden ist.

Dies ist, was Sie jetzt für den sofortigen Versand Ihres Paketes zu tun haben, 
müssen Sie die FedEx Lieferung Abteilung für die Sicherheit Keeping Gebühr 
Ihres Paketes eine Summe von $ 205 USD zu zahlen. FedEx Unternehmen, wie in 
unserer Datenschutzbestimmungen & Zustand Seite angegeben. Auch darüber 
informiert, dass die John "Jack" Lange wollte für die Sicherheit Keeping 
Gebühren zu bezahlen, aber wir akzeptieren keine solche Zahlungen, die Fakten 
unter Berücksichtigung, dass alle Posten und Pakete registriert mit uns eine 
Zeitbegrenzung hat und wir können nicht die Zahlung akzeptieren nicht zu 
wissen, wenn Sie wird das Paket werden Abholung oder sogar zu uns reagieren. So 
können wir nicht das Risiko eingehen, um eine solche Zahlung im Falle eines 
möglichen demurrage angenommen haben.

Sie befinden sich wieder uns sofort zu bekommen, so dass wir Problem, das Sie 
Informationen darüber, wie SIE das Geld für die SECURITY KEEPING Gebühr von $ 
105 US Dollar zu bezahlen.

Wir warten auf Ihre Antwort

Hochachtungsvoll,
Frau Monika Holtz
FedEx Online Geschäftsführer.
Alle Rechte vorbehalten. © 1995-2016
--
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://vger.kernel.org/majordomo-info.html

reflogs and worktrees?

[Johannes Schindelin]

Hi Duy,

ever since I started working extensively with worktrees, I end up with
these funny gc problems, like broken links and stale reflogs.

Is it maybe possible that the reflogs (which are per-worktree now) are not
traversed completely when gc'ing (which is *not* per-worktree)?

Ciao,
Dscho
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 02/17] Report bugs consistently

[Johannes Schindelin]

Hi Kuba,

On Tue, 5 Jul 2016, Jakub Narębski wrote:

> W dniu 2016-07-05 o 13:23, Johannes Schindelin pisze:
> > diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> > index f02e3d2..00ea91a 100644
> > --- a/builtin/ls-files.c
> > +++ b/builtin/ls-files.c
> > @@ -118,7 +118,8 @@ static void show_killed_files(struct dir_struct *dir)
> >  */
> > pos = cache_name_pos(ent->name, ent->len);
> > if (0 <= pos)
> > -   die("bug in show-killed-files");
> > +   die("BUG: killed-file %.*s not found",
> > +   ent->len, ent->name);
> > pos = -pos - 1;
> > while (pos < active_nr &&
> >ce_stage(active_cache[pos]))
> 
> This has an additional improvement (not mentioned in the commit
> message, but probably not worth it) in that it shows which file
> was not found, not only that there was some bug, isn't it?

Sure, it improves that report. In the unlikely event that a bug is
encountered :-)

Is it really worth mentioning in the commit message?

Looking at it again, however, I think there is a bug in my patch. It says
that the file was not found, but pos was non-negative, so it was found
unexpectedly. So I think I should strike the "not" part. Would you concur?

Ciao,
Dscho

Re: Missing Package in git Installation Instructions (git-scm.com)

[Jakub Narębski]

W dniu 2016-07-05 o 08:10, Johannes Schindelin pisze:
> Hi Chris,
> 
> On Tue, 5 Jul 2016, Christoph Michelbach wrote:
> 
>> Hi, I noticed that the instructions on https://git-scm.com/book/en/v2/G
>> etting-Started-Installing-Git don't work without dh-autoreconf
>> installed on an apt-get system which isn't listed on that site. Can you
>> fix that or tell me whom to tell about this? The website doesn't offer
>> contact information. Just tried this on a fresh Ubuntu 16.04
>> installation.
> 
> When you follow that link, do you see this text on the left side?
> 
>   The source of this book is hosted on GitHub.
>   Patches, suggestions and comments are welcome.
> 
> It links to https://github.com/progit/progit2 and I am sure your bug
> report would make an excellent contribution to the bug tracker ("Issues")
> in that repository.
> 
> It would probably be even better if you cloned said repository, found the
> respective file via `git grep apt-get`, fixed it, and opened a Pull
> Request.

Or you can even fix it from a web interface, if you have a GitHub account.
Behind the scene, GitHub would fork a repository, edit file and create
a commit, then create a pull request.  Very easy for one-off fixes, assuming
that you have a GitHub account.

-- 
Jakub Narębski

--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH] add documentation to mw-to-git

[Matthieu Moy]

Hi, and thanks for your contribution.

Alexandru Zbarcea  writes:

> Signed-off-by: Alexandru Zbarcea 
> ---
>  contrib/mw-to-git/Makefile |  44 -
>  contrib/mw-to-git/git-mediawiki.txt| 100 
> +
>  contrib/mw-to-git/git-remote-mediawiki.txt |   7 --
>  3 files changed, 142 insertions(+), 9 deletions(-)

Git-Mediawiki did not contain any in-tree documentation, but already has a
user manual:

  https://github.com/moy/Git-Mediawiki/wiki/User-manual

I have no objection to moving the documentation in-tree (I even created
an issue a long time ago but never did it:
https://github.com/moy/Git-Mediawiki/issues/9 ). However, you patch
alone does not do that: it partly duplicates the existing user-manual,
and complements it with (useful) things that did not appear there (doc
for "git mw" and a recap of config variables). I think this is a step in
the wrong direction and I'd very much prefer a single documentation.

Two more things to know about Git-Mediawiki:

https://github.com/moy/Git-Mediawiki/issues/34
Move Git-Mediawiki's code out of git.git's contrib/

Essentially, having the code in git.git's contrib does not bring much
today, and reduces the number of potential contributors. There seems to
be a consensus to move it out of git.git and develop it separately.

One consequence is that asciidoc may not be the best choice as a markup
format. Having a format that renders directly on GitHub probably
overweights the benefit of using the same system as Git. GitHub can
render asciidoc, but needs *.asciidoc file names and won't read the
config file AFAIK.

https://github.com/moy/Git-Mediawiki/issues/33
Git-Mediawiki is looking for a new maintainer

Git-Mediawiki was a fun experience, but I'm not using it as much as I
planed, and my time budget for it approaches 0, so a new maintainer
would be very much welcome (typically to fix issue #34 above).

> +COMMANDS
> +
> +help::
> +Display help information about git mw.
> +
> +preview::
> +Parse and render local file into HTML. Preview a page without actually 
> pushing it to the wiki.

Better write the commands completely like

git mw help::

to avoid ambiguity with git-remote-mediawiki (which is a separate
command).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 02/17] Report bugs consistently

[Jakub Narębski]

W dniu 2016-07-05 o 13:23, Johannes Schindelin pisze:
> diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> index f02e3d2..00ea91a 100644
> --- a/builtin/ls-files.c
> +++ b/builtin/ls-files.c
> @@ -118,7 +118,8 @@ static void show_killed_files(struct dir_struct *dir)
>*/
>   pos = cache_name_pos(ent->name, ent->len);
>   if (0 <= pos)
> - die("bug in show-killed-files");
> + die("BUG: killed-file %.*s not found",
> + ent->len, ent->name);
>   pos = -pos - 1;
>   while (pos < active_nr &&
>  ce_stage(active_cache[pos]))

This has an additional improvement (not mentioned in the commit
message, but probably not worth it) in that it shows which file
was not found, not only that there was some bug, isn't it?

-- 
Jakub Narębski


--
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://vger.kernel.org/majordomo-info.html

git diff A...B is both overly forgiving and weird

[Chris Torek]

(This is not a big bug, but it is clearly not right.)

The problem is mostly described in the patch below.

This patch can perhaps be improved a bit by using an abbreviated
hash for the chosen merge base, in the case of multiple merge
bases, and/or by removing some of the paranoia-style checking (but
as I'm not terribly familiar with Git internals, I left these in).

Extra negative references given on the command line, as in "git
diff master~5...master^^2 ^origin/master^", now pass undetected; I
am not sure if there is a good way to catch them.  (In the
original code, they apparently substituted in for the merge-base.)

Chris


commit 2b9288cc90175557766ef33e350e0514470b6ad4
Author: Chris Torek 
Date:   Tue Jul 5 05:15:23 2016 -0700

git diff: improve A...B merge-base handling

When git diff is given a symmetric difference A...B, it chooses
some merge base between the two specified commits.

This fails, however, if there is *no* merge base: instead, you
see the difference between A and B, which is certainly not what
is expected:

git diff origin/master...origin/todo
[same output as "git diff origin/master origin/todo"]

Moreover, if additional revisions are specified on the command
line:

git diff origin/master...origin/todo origin/master^
git diff master~5...master^^2 origin/master^
git diff master~5...master^^2 ^origin/master^

the result gets a bit weird.  If there is a symmetric difference
merge base, that will provide the left side of the diff.  An
extra positive ref, if given, becomes the right side.  If there
is no merge base, the symmetric difference is completely lost:
for the Git repository, "origin/master...origin/todo origin/master^"
runs a combined diff!  (This follows from treating the lack of
a merge base as an ordinary diff of the two specified revisions.)

To avoid all this, add a routine to catch the A...B case and
verify that there is at least one merge base.  As a side effect,
produce a warning showing *which* merge base is being used when
there are multiple choices; die if there is no merge base.

diff --git a/builtin/diff.c b/builtin/diff.c
index b7a9405..c040b47 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -256,6 +256,97 @@ static int builtin_diff_files(struct rev_info *revs, int 
argc, const char **argv
return run_diff_files(revs, options);
 }
 
+/*
+ * Check for symmetric-difference arguments, and if present,
+ * convert A...B to $(merge-base A B) B.
+ */
+static int builtin_diff_sdiff(struct rev_info *rev, struct object_array *ent)
+{
+   int i;
+   int on_left = 0, uninteresting = 0, unflagged = 0;
+   int lpos = -1, rpos = -1, upos = -1;
+   char *lname, *rname, *uname;
+   struct object *robj, *uobj;
+
+   /*
+* If there were any A...B symmetric differences specified,
+* we'll have A marked with SYMMETRIC_LEFT | UNINTERESTING,
+* and each merge base marked with UNINTERESTING.  B will
+* be unmarked.  If we were given additional revisions they
+* may have other markings, so remember the first A and B
+* for error messages as well.
+*
+* The actual order of these are that the merge bases come
+* first, then A, then B, but we don't depend on that in
+* this code.
+*
+* If we don't have just one merge base, we pick one
+* at (essentially) random (by using the first).
+*
+* Note that we don't check obj->parsed, since symmetric
+* difference objects are always pre-parsed: a non-parsed
+* object is by definition not part of a symmetric difference.
+*/
+   for (i = 0; i < rev->pending.nr; i++) {
+   struct object *obj = rev->pending.objects[i].item;
+
+   if (obj->flags & SYMMETRIC_LEFT) {
+   on_left++;
+   if (lpos < 0)
+   lpos = i;
+   } else if (obj->flags & UNINTERESTING) {
+   uninteresting++;
+   if (upos < 0)
+   upos = i;
+   } else {
+   unflagged++;
+   if (lpos >= 0 && rpos < 0)
+   rpos = i;
+   }
+   }
+
+   if (on_left == 0)   /* no symmetric differences */
+   return (0);
+
+   /*
+* N.B.: lname retains the three dots.  The name of
+* the right hand side object (there should be one) is
+* a subset of this string.
+*/
+   lname = rev->pending.objects[lpos].name;
+   /* demand exactly 1 on left and 1 unflagged */
+   if (unflagged > 1)
+   die(_("%s: must not list additional revs"), lname);
+   if (unflagged < 1)
+   die(_("%s: internal error: '...' but no unflagged 

Re: topological index field for commit objects

[Jakub Narębski]

W dniu 2016-07-05 o 13:43, Johannes Schindelin pisze:
> On Wed, 29 Jun 2016, Jeff King wrote:
> 
>> I haven't thought hard specifically about merge bases computation, so
>> perhaps that is a case that isn't helped at all.
> 
> I guess it is not helped by generation numbers.
> 
> But then, we often ask: "is commit A an ancestor of commit B" e.g. to
> check whether we can fast-forward. The way we do it now is to compute the
> merge base (singular: if there are more than one, we stop at the first one
> we found) and then look whether commit A is identical to the merge base.

I wonder if this query can be answered faster than finding the merge base
(the common ancestor) with Git core, and if it would be worth it to expose
this functionality to shell...

> If we had generation numbers available, then we would have to change those
> computations in order to benefit from them when determining ancestry.

Generation numbers (node level / topological rank) can help with such
query.  First, if level of A is greater than level of B, then A cannot
be an ancestor of B.  Second, when following from B we can prune path
if we get to node with level lower than A.  This is so called "level
filter" in literature.

FELINE indices cut search space even more... though I don't know if
they would help with finding common ancestors. Perhaps some other
technique would be better (taking into account Git use of EWAH bitmaps
for reachability of objects).

> 
> But then, reachability would accelerate that even more than generation
> numbers.

I wonder if Git uses bitmap indices here, if possible -- they are generated
sparsely.  They can help both in reachability queries (is A in reachability
of B, or in reachability of one of ancestors of B?) and in finding merge
bases (intersection of reachabilities of A and B, or their ancestors...
or something like that, I think, probably more complicated).

-- 
Jakub Narębski


--
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://vger.kernel.org/majordomo-info.html

[PATCH] revert: clarify seemingly bogus OPT_END repetition

[Johannes Schindelin]

This developer stumbled over repeated OPT_END entries and was *so
close* (almost touches his thumb with his index finger) to collapse
them into a single one. Only inspecting the file's history with
`git log -p -SOPT_END` clarified why they are there.

This confusion can be easily prevented by inserting a simple and
clear comment.

Signed-off-by: Johannes Schindelin 
---

Another patch from the rebase--helper queue.

Published-As: https://github.com/dscho/git/releases/tag/clarify-opt-end-v1
 builtin/revert.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builtin/revert.c b/builtin/revert.c
index 56a2c36..b4da1f6 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -92,6 +92,7 @@ static void parse_args(int argc, const char **argv, struct 
replay_opts *opts)
{ OPTION_STRING, 'S', "gpg-sign", >gpg_sign, N_("key-id"),
  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" 
},
OPT_END(),
+   /* place-holders for REPLAY_PICK's extra options, see below */
OPT_END(),
OPT_END(),
OPT_END(),
-- 
2.9.0.280.g32e2a70

base-commit: cf4c2cfe52be5bd973a4838f73a35d3959ce2f43
--
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://vger.kernel.org/majordomo-info.html

Dependencies required for offline installation

[Kevin Paxton]

Hi,

I’m looking to install git on a separate network that is running
Redhat 5.5. I need to know what is the list of packages that I need to
download to be able to install git-all? I plan on using git-svn to
migrate an existing svn repo over to git as well. Svn version we have
installed is 1.9.3.


Does the tarball contain all dependencies already? Should I go that
route? Or should I try and find all the rpm's required?


Thanks,

Kevin Paxton
--
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://vger.kernel.org/majordomo-info.html

Re: topological index field for commit objects

[Johannes Schindelin]

Hi Peff,

On Wed, 29 Jun 2016, Jeff King wrote:

> I haven't thought hard specifically about merge bases computation, so
> perhaps that is a case that isn't helped at all.

I guess it is not helped by generation numbers.

But then, we often ask: "is commit A an ancestor of commit B" e.g. to
check whether we can fast-forward. The way we do it now is to compute the
merge base (singular: if there are more than one, we stop at the first one
we found) and then look whether commit A is identical to the merge base.

If we had generation numbers available, then we would have to change those
computations in order to benefit from them when determining ancestry.

But then, reachability would accelerate that even more than generation
numbers.

Ciao,
Dscho
--
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://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] Report bugs consistently

[Johannes Schindelin]

Hi Duy,

On Sat, 2 Jul 2016, Duy Nguyen wrote:

> You're changing the string and adding more work to translators. So
> either leave the string untouched, or drop _().

Thanks. I addressed that concern in v2. Could you please now have a look at
the parts of the patch series which could possibly regress Git's
functionality? I am quite a bit more interested in having extra pairs of
eyes look over those.

Thanks,
Dscho
--
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://vger.kernel.org/majordomo-info.html

Re: GIT Integration with Siebel

[Johannes Schindelin]

Hi Tarun,

On Tue, 5 Jul 2016, tarun patanwar wrote:

> Siebel is a Oracle Product for CRM implementation, just like SAP and
> SalesForce. So Siebel as a product provides option to integrate any
> third party Source Control tool with it.
> 
> Integration between Siebel and Source Control tool is facilitated by the
> batch file (srcctrl.bat) which contains configuration details about
> Source Control tool. While developers checks in/out their code into
> Siebel Server, this batch file gets triggered and invokes Source Control
> command line to check in a version into repository.
> 
> I'll be happy to provide further information is needed.

I believe that you will find it more productive to try to explain more
thoroughly what srcctrl.bat is supposed to do, preferably such that
anybody who has *not* licensed Siebel knows what you can do with
srcctrl.bat.

So it is not so much that you need to provide further information. It is
more that you want to provide further information, in order to entice
anybody to help you.

Ciao,
Johannes
--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 11/17] am: counteract gender bias

[Johannes Schindelin]

Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
almost 11 years already, we demonstrated our disrespect to the pioneers
of software development like Ada Lovelace, Grace Hopper and Margaret
Hamilton, by pretending that each and every software developer is male
("his_tree"). It appears almost as if we weren't fully aware that the
first professional software developers were all female.

We know our field to have this unfortunate gender bias that has nothing
to do with qualification or biological reasons, and we are very sad
about the current gender imbalance of the Git developer community.

Let's start changing that by using the variable name "her_tree" for an
equal number of years out of fairness, and change to the gender neutral
"their_tree" after that.

Signed-off-by: Johannes Schindelin 
---
 builtin/am.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/builtin/am.c b/builtin/am.c
index 3dfe70b..f07f89a 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1578,14 +1578,14 @@ static int build_fake_ancestor(const struct am_state 
*state, const char *index_f
 }
 
 /**
- * Do the three-way merge using fake ancestor, his tree constructed
+ * Do the three-way merge using fake ancestor, her tree constructed
  * from the fake ancestor and the postimage of the patch, and our
  * state.
  */
 static int run_fallback_merge_recursive(const struct am_state *state,
unsigned char *orig_tree,
unsigned char *our_tree,
-   unsigned char *his_tree)
+   unsigned char *her_tree)
 {
struct child_process cp = CHILD_PROCESS_INIT;
int status;
@@ -1593,7 +1593,7 @@ static int run_fallback_merge_recursive(const struct 
am_state *state,
cp.git_cmd = 1;
 
argv_array_pushf(_array, "GITHEAD_%s=%.*s",
-sha1_to_hex(his_tree), linelen(state->msg), 
state->msg);
+sha1_to_hex(her_tree), linelen(state->msg), 
state->msg);
if (state->quiet)
argv_array_push(_array, "GIT_MERGE_VERBOSITY=0");
 
@@ -1601,7 +1601,7 @@ static int run_fallback_merge_recursive(const struct 
am_state *state,
argv_array_push(, sha1_to_hex(orig_tree));
argv_array_push(, "--");
argv_array_push(, sha1_to_hex(our_tree));
-   argv_array_push(, sha1_to_hex(his_tree));
+   argv_array_push(, sha1_to_hex(her_tree));
 
status = run_command() ? (-1) : 0;
discard_cache();
@@ -1614,7 +1614,7 @@ static int run_fallback_merge_recursive(const struct 
am_state *state,
  */
 static int fall_back_threeway(const struct am_state *state, const char 
*index_path)
 {
-   unsigned char orig_tree[GIT_SHA1_RAWSZ], his_tree[GIT_SHA1_RAWSZ],
+   unsigned char orig_tree[GIT_SHA1_RAWSZ], her_tree[GIT_SHA1_RAWSZ],
  our_tree[GIT_SHA1_RAWSZ];
 
if (get_sha1("HEAD", our_tree) < 0)
@@ -1651,7 +1651,7 @@ static int fall_back_threeway(const struct am_state 
*state, const char *index_pa
return error(_("Did you hand edit your patch?\n"
"It does not apply to blobs recorded in its 
index."));
 
-   if (write_index_as_tree(his_tree, _index, index_path, 0, NULL))
+   if (write_index_as_tree(her_tree, _index, index_path, 0, NULL))
return error("could not write tree");
 
say(state, stdout, _("Falling back to patching base and 3-way 
merge..."));
@@ -1661,13 +1661,13 @@ static int fall_back_threeway(const struct am_state 
*state, const char *index_pa
 
/*
 * This is not so wrong. Depending on which base we picked, orig_tree
-* may be wildly different from ours, but his_tree has the same set of
+* may be wildly different from ours, but her_tree has the same set of
 * wildly different changes in parts the patch did not touch, so
 * recursive ends up canceling them, saying that we reverted all those
 * changes.
 */
 
-   if (run_fallback_merge_recursive(state, orig_tree, our_tree, his_tree)) 
{
+   if (run_fallback_merge_recursive(state, orig_tree, our_tree, her_tree)) 
{
rerere(state->allow_rerere_autoupdate);
return error(_("Failed to merge in the changes."));
}
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 12/17] am -3: use merge_recursive() directly again

[Johannes Schindelin]

Last October, we had to change this code to run `git merge-recursive`
in a child process: git-am wants to print some helpful advice when the
merge failed, but the code in question was not prepared to return, it
die()d instead.

We are finally at a point when the code *is* prepared to return errors,
and can avoid the child process again.

This reverts commit c63d4b2 (am -3: do not let failed merge from
completing the error codepath, 2015-10-09).

Note: the code now calls merge_recursive_generic() again. Unlike
merge_trees() and merge_recursive(), this function returns 0 upon success,
as most of Git's functions. Therefore, the error value -1 naturally is
handled correctly, and we do not have to take care of it specifically.

Signed-off-by: Johannes Schindelin 
---
 builtin/am.c | 49 -
 1 file changed, 16 insertions(+), 33 deletions(-)

diff --git a/builtin/am.c b/builtin/am.c
index f07f89a..be652f9 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1578,44 +1578,16 @@ static int build_fake_ancestor(const struct am_state 
*state, const char *index_f
 }
 
 /**
- * Do the three-way merge using fake ancestor, her tree constructed
- * from the fake ancestor and the postimage of the patch, and our
- * state.
- */
-static int run_fallback_merge_recursive(const struct am_state *state,
-   unsigned char *orig_tree,
-   unsigned char *our_tree,
-   unsigned char *her_tree)
-{
-   struct child_process cp = CHILD_PROCESS_INIT;
-   int status;
-
-   cp.git_cmd = 1;
-
-   argv_array_pushf(_array, "GITHEAD_%s=%.*s",
-sha1_to_hex(her_tree), linelen(state->msg), 
state->msg);
-   if (state->quiet)
-   argv_array_push(_array, "GIT_MERGE_VERBOSITY=0");
-
-   argv_array_push(, "merge-recursive");
-   argv_array_push(, sha1_to_hex(orig_tree));
-   argv_array_push(, "--");
-   argv_array_push(, sha1_to_hex(our_tree));
-   argv_array_push(, sha1_to_hex(her_tree));
-
-   status = run_command() ? (-1) : 0;
-   discard_cache();
-   read_cache();
-   return status;
-}
-
-/**
  * Attempt a threeway merge, using index_path as the temporary index.
  */
 static int fall_back_threeway(const struct am_state *state, const char 
*index_path)
 {
unsigned char orig_tree[GIT_SHA1_RAWSZ], her_tree[GIT_SHA1_RAWSZ],
  our_tree[GIT_SHA1_RAWSZ];
+   const unsigned char *bases[1] = {orig_tree};
+   struct merge_options o;
+   struct commit *result;
+   char *her_tree_name;
 
if (get_sha1("HEAD", our_tree) < 0)
hashcpy(our_tree, EMPTY_TREE_SHA1_BIN);
@@ -1667,11 +1639,22 @@ static int fall_back_threeway(const struct am_state 
*state, const char *index_pa
 * changes.
 */
 
-   if (run_fallback_merge_recursive(state, orig_tree, our_tree, her_tree)) 
{
+   init_merge_options();
+
+   o.branch1 = "HEAD";
+   her_tree_name = xstrfmt("%.*s", linelen(state->msg), state->msg);
+   o.branch2 = her_tree_name;
+
+   if (state->quiet)
+   o.verbosity = 0;
+
+   if (merge_recursive_generic(, our_tree, her_tree, 1, bases, )) 
{
rerere(state->allow_rerere_autoupdate);
+   free(her_tree_name);
return error(_("Failed to merge in the changes."));
}
 
+   free(her_tree_name);
return 0;
 }
 
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 07/17] merge-recursive: avoid returning a wholesale struct

[Johannes Schindelin]

It is technically allowed, as per C89, for functions' return type to
be complete structs (i.e. *not* just pointers to structs).

However, it was just an oversight of this developer when converting
Python code to C code in 6d297f8 (Status update on merge-recursive in
C, 2006-07-08) which introduced such a return type.

Besides, by converting this construct to pass in the struct, we can now
start returning a value that can indicate errors in future patches. This
will help the current effort to libify merge-recursive.c.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 93 ++-
 1 file changed, 50 insertions(+), 43 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 716488b..3e3667f 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -886,47 +886,47 @@ static int merge_3way(struct merge_options *o,
return merge_status;
 }
 
-static struct merge_file_info merge_file_1(struct merge_options *o,
+static int merge_file_1(struct merge_options *o,
   const struct diff_filespec *one,
   const struct diff_filespec *a,
   const struct diff_filespec *b,
   const char *branch1,
-  const char *branch2)
+  const char *branch2,
+  struct merge_file_info *result)
 {
-   struct merge_file_info result;
-   result.merge = 0;
-   result.clean = 1;
+   result->merge = 0;
+   result->clean = 1;
 
if ((S_IFMT & a->mode) != (S_IFMT & b->mode)) {
-   result.clean = 0;
+   result->clean = 0;
if (S_ISREG(a->mode)) {
-   result.mode = a->mode;
-   hashcpy(result.sha, a->sha1);
+   result->mode = a->mode;
+   hashcpy(result->sha, a->sha1);
} else {
-   result.mode = b->mode;
-   hashcpy(result.sha, b->sha1);
+   result->mode = b->mode;
+   hashcpy(result->sha, b->sha1);
}
} else {
if (!sha_eq(a->sha1, one->sha1) && !sha_eq(b->sha1, one->sha1))
-   result.merge = 1;
+   result->merge = 1;
 
/*
 * Merge modes
 */
if (a->mode == b->mode || a->mode == one->mode)
-   result.mode = b->mode;
+   result->mode = b->mode;
else {
-   result.mode = a->mode;
+   result->mode = a->mode;
if (b->mode != one->mode) {
-   result.clean = 0;
-   result.merge = 1;
+   result->clean = 0;
+   result->merge = 1;
}
}
 
if (sha_eq(a->sha1, b->sha1) || sha_eq(a->sha1, one->sha1))
-   hashcpy(result.sha, b->sha1);
+   hashcpy(result->sha, b->sha1);
else if (sha_eq(b->sha1, one->sha1))
-   hashcpy(result.sha, a->sha1);
+   hashcpy(result->sha, a->sha1);
else if (S_ISREG(a->mode)) {
mmbuffer_t result_buf;
int merge_status;
@@ -938,62 +938,63 @@ static struct merge_file_info merge_file_1(struct 
merge_options *o,
die(_("Failed to execute internal merge"));
 
if (write_sha1_file(result_buf.ptr, result_buf.size,
-   blob_type, result.sha))
+   blob_type, result->sha))
die(_("Unable to add %s to database"),
a->path);
 
free(result_buf.ptr);
-   result.clean = (merge_status == 0);
+   result->clean = (merge_status == 0);
} else if (S_ISGITLINK(a->mode)) {
-   result.clean = merge_submodule(result.sha,
+   result->clean = merge_submodule(result->sha,
   one->path, one->sha1,
   a->sha1, b->sha1,
   !o->call_depth);
} else if (S_ISLNK(a->mode)) {
-   hashcpy(result.sha, a->sha1);
+   hashcpy(result->sha, a->sha1);
 
if (!sha_eq(a->sha1, b->sha1))
-   result.clean = 0;
+ 

[PATCH v2 08/17] merge-recursive: allow write_tree_from_memory() to error out

[Johannes Schindelin]

It is possible that a tree cannot be written (think: disk full). We
will want to give the caller a chance to clean up instead of letting
the program die() in such a case.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 3e3667f..99f4202 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1873,8 +1873,8 @@ int merge_trees(struct merge_options *o,
else
clean = 1;
 
-   if (o->call_depth)
-   *result = write_tree_from_memory(o);
+   if (o->call_depth && !(*result = write_tree_from_memory(o)))
+   return -1;
 
return clean;
 }
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 13/17] merge-recursive: flush output buffer before printing error messages

[Johannes Schindelin]

The data structure passed to the recursive merge machinery has a feature
where the caller can ask for the output to be buffered into a strbuf, by
setting the field 'buffer_output'.

Previously, we simply swallowed the buffered output when showing error
messages. With this patch, we show the output first, and only then print
the error message.

Currently, the only user of that buffering is merge_recursive() itself,
to avoid the progress output to interfere.

In the next patches, we will introduce a new buffer_output mode that
forces merge_recursive() to retain the output buffer for further
processing by the caller. If the caller asked for that, we will then
also write the error messages into the output buffer. This is necessary
to give the caller more control not only how to react in case of errors
but also control how/if to display the error messages.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 110 --
 1 file changed, 65 insertions(+), 45 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 10010a4..0eb23a6 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -23,6 +23,28 @@
 #include "dir.h"
 #include "submodule.h"
 
+static void flush_output(struct merge_options *o)
+{
+   if (o->obuf.len) {
+   fputs(o->obuf.buf, stdout);
+   strbuf_reset(>obuf);
+   }
+}
+
+static int err(struct merge_options *o, const char *err, ...)
+{
+   va_list params;
+
+   va_start(params, err);
+   flush_output(o);
+   strbuf_vaddf(>obuf, err, params);
+   error("%s", o->obuf.buf);
+   strbuf_reset(>obuf);
+   va_end(params);
+
+   return -1;
+}
+
 static struct tree *shift_tree_object(struct tree *one, struct tree *two,
  const char *subtree_shift)
 {
@@ -148,14 +170,6 @@ static int show(struct merge_options *o, int v)
return (!o->call_depth && o->verbosity >= v) || o->verbosity >= 5;
 }
 
-static void flush_output(struct merge_options *o)
-{
-   if (o->obuf.len) {
-   fputs(o->obuf.buf, stdout);
-   strbuf_reset(>obuf);
-   }
-}
-
 __attribute__((format (printf, 3, 4)))
 static void output(struct merge_options *o, int v, const char *fmt, ...)
 {
@@ -198,7 +212,8 @@ static void output_commit_title(struct merge_options *o, 
struct commit *commit)
}
 }
 
-static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
+static int add_cacheinfo(struct merge_options *o,
+   unsigned int mode, const unsigned char *sha1,
const char *path, int stage, int refresh, int options)
 {
struct cache_entry *ce;
@@ -206,7 +221,7 @@ static int add_cacheinfo(unsigned int mode, const unsigned 
char *sha1,
  (refresh ? (CE_MATCH_REFRESH |
  CE_MATCH_IGNORE_MISSING) : 0 ));
if (!ce)
-   return error(_("addinfo_cache failed for path '%s'"), path);
+   return err(o, _("addinfo_cache failed for path '%s'"), path);
return add_cache_entry(ce, options);
 }
 
@@ -267,7 +282,7 @@ struct tree *write_tree_from_memory(struct merge_options *o)
 
if (!cache_tree_fully_valid(active_cache_tree) &&
cache_tree_update(_index, 0) < 0) {
-   error(_("error building trees"));
+   err(o, _("error building trees"));
return NULL;
}
 
@@ -535,7 +550,8 @@ static struct string_list *get_renames(struct merge_options 
*o,
return renames;
 }
 
-static int update_stages(const char *path, const struct diff_filespec *o,
+static int update_stages(struct merge_options *opt, const char *path,
+const struct diff_filespec *o,
 const struct diff_filespec *a,
 const struct diff_filespec *b)
 {
@@ -554,13 +570,13 @@ static int update_stages(const char *path, const struct 
diff_filespec *o,
if (remove_file_from_cache(path))
return -1;
if (o)
-   if (add_cacheinfo(o->mode, o->sha1, path, 1, 0, options))
+   if (add_cacheinfo(opt, o->mode, o->sha1, path, 1, 0, options))
return -1;
if (a)
-   if (add_cacheinfo(a->mode, a->sha1, path, 2, 0, options))
+   if (add_cacheinfo(opt, a->mode, a->sha1, path, 2, 0, options))
return -1;
if (b)
-   if (add_cacheinfo(b->mode, b->sha1, path, 3, 0, options))
+   if (add_cacheinfo(opt, b->mode, b->sha1, path, 3, 0, options))
return -1;
return 0;
 }
@@ -712,8 +728,8 @@ static int make_room_for_path(struct merge_options *o, 
const char *path)
if (status) {
if (status == SCLD_EXISTS)
/* something else exists */
-   return 

[PATCH v2 09/17] merge-recursive: handle return values indicating errors

[Johannes Schindelin]

We are about to libify the recursive merge machinery, where we only
die() in case of a bug or memory contention. To that end, we must heed
negative return values as indicating errors.

This requires our functions to be careful to pass through error
conditions in call chains, and for quite a few functions this means
that they have to return values to begin with.

The next step will be to convert the places where we currently die() to
return negative values (read: -1) instead.

Note that we ignore errors reported by make_room_for_path(), consistent
with the previous behavior (update_file_flags() used the return value of
make_room_for_path() only to indicate an early return, but not a fatal
error): if the error is really a fatal error, we will notice later; If
not, it was not that serious a problem to begin with. (Witnesses in
favor of this reasoning are t4151-am-abort and t7610-mergetool, which
would start failing if we stopped on errors reported by
make_room_for_path()).

Note: while this patch makes the code slightly less readable in
update_file_flags() (we introduce a new "goto free_buf;" instead of
an explicit "free(buf); return;"), it is a preparatory change for
the next patch where we will convert all of the die() calls in the same
function to go through the free_buf return path instead.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 196 +-
 1 file changed, 121 insertions(+), 75 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 99f4202..209427c 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -734,7 +734,7 @@ static int make_room_for_path(struct merge_options *o, 
const char *path)
return error(msg, path, _(": perhaps a D/F conflict?"));
 }
 
-static void update_file_flags(struct merge_options *o,
+static int update_file_flags(struct merge_options *o,
  const unsigned char *sha,
  unsigned mode,
  const char *path,
@@ -775,8 +775,7 @@ static void update_file_flags(struct merge_options *o,
 
if (make_room_for_path(o, path) < 0) {
update_wd = 0;
-   free(buf);
-   goto update_index;
+   goto free_buf;
}
if (S_ISREG(mode) || (!has_symlinks && S_ISLNK(mode))) {
int fd;
@@ -799,20 +798,22 @@ static void update_file_flags(struct merge_options *o,
} else
die(_("do not know what to do with %06o %s '%s'"),
mode, sha1_to_hex(sha), path);
+ free_buf:
free(buf);
}
  update_index:
if (update_cache)
add_cacheinfo(mode, sha, path, 0, update_wd, 
ADD_CACHE_OK_TO_ADD);
+   return 0;
 }
 
-static void update_file(struct merge_options *o,
+static int update_file(struct merge_options *o,
int clean,
const unsigned char *sha,
unsigned mode,
const char *path)
 {
-   update_file_flags(o, sha, mode, path, o->call_depth || clean, 
!o->call_depth);
+   return update_file_flags(o, sha, mode, path, o->call_depth || clean, 
!o->call_depth);
 }
 
 /* Low level file merging, update and removal */
@@ -1008,7 +1009,7 @@ static int merge_file_one(struct merge_options *o,
return merge_file_1(o, , , , branch1, branch2, mfi);
 }
 
-static void handle_change_delete(struct merge_options *o,
+static int handle_change_delete(struct merge_options *o,
 const char *path,
 const unsigned char *o_sha, int o_mode,
 const unsigned char *a_sha, int a_mode,
@@ -1016,6 +1017,7 @@ static void handle_change_delete(struct merge_options *o,
 const char *change, const char *change_past)
 {
char *renamed = NULL;
+   int ret = 0;
if (dir_in_way(path, !o->call_depth)) {
renamed = unique_path(o, path, a_sha ? o->branch1 : o->branch2);
}
@@ -1026,21 +1028,23 @@ static void handle_change_delete(struct merge_options 
*o,
 * correct; since there is no true "middle point" between
 * them, simply reuse the base version for virtual merge base.
 */
-   remove_file_from_cache(path);
-   update_file(o, 0, o_sha, o_mode, renamed ? renamed : path);
+   ret = remove_file_from_cache(path);
+   if (!ret)
+   ret = update_file(o, 0, o_sha, o_mode,
+ renamed ? renamed : path);
} else if (!a_sha) {
if (!renamed) {
output(o, 1, _("CONFLICT (%s/delete): %s deleted in %s "
   "and %s in %s. 

[PATCH v2 16/17] Ensure that the output buffer is released after calling merge_trees()

[Johannes Schindelin]

The recursive merge machinery accumulates its output in an output
buffer, to be flushed at the end of merge_recursive(). At this point,
we forgot to release the output buffer.

When calling merge_trees() (i.e. the non-recursive part of the recursive
merge) directly, the output buffer is never flushed because the caller
may be merge_recursive() which wants to flush the output itself.

For the same reason, merge_trees() cannot release the output buffer: it
may still be needed.

Forgetting to release the output buffer did not matter much when running
git-checkout, or git-merge-recursive, because we exited after the
operation anyway. Ever since cherry-pick learned to pick a commit range,
however, this memory leak had the potential of becoming a problem.

Signed-off-by: Johannes Schindelin 
---
 builtin/checkout.c | 1 +
 merge-recursive.c  | 2 ++
 sequencer.c| 1 +
 3 files changed, 4 insertions(+)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index 14312f7..ced4ac4 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -573,6 +573,7 @@ static int merge_working_tree(const struct checkout_opts 
*opts,
exit(128);
ret = reset_tree(new->commit->tree, opts, 0,
 writeout_error);
+   strbuf_release();
if (ret)
return ret;
}
diff --git a/merge-recursive.c b/merge-recursive.c
index 29cbdac..fdc624a 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2059,6 +2059,8 @@ int merge_recursive(struct merge_options *o,
commit_list_insert(h2, &(*result)->parents->next);
}
flush_output(o);
+   if (o->buffer_output < 2)
+   strbuf_release(>obuf);
if (show(o, 2))
diff_warn_rename_limit("merge.renamelimit",
   o->needed_rename_limit, 0);
diff --git a/sequencer.c b/sequencer.c
index 13b794a..8ceeb1b 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -293,6 +293,7 @@ static int do_recursive_merge(struct commit *base, struct 
commit *next,
clean = merge_trees(,
head_tree,
next_tree, base_tree, );
+   strbuf_release();
if (clean < 0)
return clean;
 
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 17/17] merge-recursive: flush output buffer even when erroring out

[Johannes Schindelin]

Ever since 66a155b (Enable output buffering in merge-recursive.,
2007-01-14), we had a problem: When the merge failed in a fatal way, all
regular output was swallowed because we called die() and did not get a
chance to drain the output buffers.

To fix this, several modifications were necessary:

- we needed to stop die()ing, to give callers a chance to do something
  when an error occurred (in this case, flush the output buffers),

- we needed to delay printing the error message so that the caller can
  print the buffered output before that, and

- we needed to make sure that the output buffers are flushed even when
  the return value indicates an error.

The first two changes were introduced through earlier commits in this
patch series, and this commit addresses the third one.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index fdc624a..d94f853 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -2050,6 +2050,7 @@ int merge_recursive(struct merge_options *o,
o->ancestor = "merged common ancestors";
clean = merge_trees(o, h1->tree, h2->tree, 
merged_common_ancestors->tree,
);
+   flush_output(o);
if (clean < 0)
return clean;
 
@@ -2058,7 +2059,6 @@ int merge_recursive(struct merge_options *o,
commit_list_insert(h1, &(*result)->parents);
commit_list_insert(h2, &(*result)->parents->next);
}
-   flush_output(o);
if (o->buffer_output < 2)
strbuf_release(>obuf);
if (show(o, 2))
-- 
2.9.0.280.g32e2a70
--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 05/17] Prepare the builtins for a libified merge_recursive()

[Johannes Schindelin]

Previously, callers of merge_trees() or merge_recursive() expected that
code to die() with an error message. This used to be okay because we
called those commands from scripts, and had a chance to print out a
message in case the command failed fatally (read: with exit code 128).

As scripting incurs its own set of problems (portability, speed,
idiosynchracies of different shells, limited data structures leading to
inefficient code), we are converting more and more of these scripts into
builtins, using library functions directly.

We already tried to use merge_recursive() directly in the builtin
git-am, for example. Unfortunately, we had to roll it back temporarily
because some of the code in merge-recursive.c still deemed it okay to
call die(), when the builtin am code really wanted to print out a useful
advice after the merge failed fatally. In the next commits, we want to
fix that.

The code touched by this commit expected merge_trees() to die() with
some useful message when there is an error condition, but merge_trees()
is going to be improved by converting all die() calls to return error()
instead (i.e. return value -1 after printing out the message as before),
so that the caller can react more flexibly.

This is a step to prepare for the version of merge_trees() that no
longer dies,  even if we just imitate the previous behavior by calling
exit(128): this is what callers of e.g. `git merge` have come to expect.

Note that the callers of the sequencer (revert and cherry-pick) already
fail fast even for the return value -1; The only difference is that they
now get a chance to say " failed".

A caller of merge_trees() might want handle error messages themselves
(or even suppress them). As this patch is already complex enough, we
leave that change for a later patch.

Signed-off-by: Johannes Schindelin 
---
 builtin/checkout.c | 4 +++-
 builtin/merge.c| 2 ++
 sequencer.c| 4 
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/builtin/checkout.c b/builtin/checkout.c
index c3486bd..14312f7 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -567,8 +567,10 @@ static int merge_working_tree(const struct checkout_opts 
*opts,
o.ancestor = old->name;
o.branch1 = new->name;
o.branch2 = "local";
-   merge_trees(, new->commit->tree, work,
+   ret = merge_trees(, new->commit->tree, work,
old->commit->tree, );
+   if (ret < 0)
+   exit(128);
ret = reset_tree(new->commit->tree, opts, 0,
 writeout_error);
if (ret)
diff --git a/builtin/merge.c b/builtin/merge.c
index b555a1b..7b898db 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -682,6 +682,8 @@ static int try_merge_strategy(const char *strategy, struct 
commit_list *common,
hold_locked_index(, 1);
clean = merge_recursive(, head,
remoteheads->item, reversed, );
+   if (clean < 0)
+   exit(128);
if (active_cache_changed &&
write_locked_index(_index, , COMMIT_LOCK))
die (_("unable to write %s"), get_index_file());
diff --git a/sequencer.c b/sequencer.c
index c6362d6..13b794a 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -293,6 +293,8 @@ static int do_recursive_merge(struct commit *base, struct 
commit *next,
clean = merge_trees(,
head_tree,
next_tree, base_tree, );
+   if (clean < 0)
+   return clean;
 
if (active_cache_changed &&
write_locked_index(_index, _lock, COMMIT_LOCK))
@@ -561,6 +563,8 @@ static int do_pick_commit(struct commit *commit, struct 
replay_opts *opts)
if (!opts->strategy || !strcmp(opts->strategy, "recursive") || 
opts->action == REPLAY_REVERT) {
res = do_recursive_merge(base, next, base_label, next_label,
 head, , opts);
+   if (res < 0)
+   return res;
write_message(, git_path_merge_msg());
} else {
struct commit_list *common = NULL;
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 14/17] merge-recursive: write the commit title in one go

[Johannes Schindelin]

In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we
changed the code such that it prints the output in one go, to avoid
interfering with the progress output.

Let's make sure that the same holds true when outputting the commit
title: previously, we used several printf() statements to stdout and
speculated that stdout's buffer is large enough to hold the entire
commit title.

Apart from making that speculation unnecessary, we change the code to
add the message to the output buffer before flushing for another reason:
the next commit will introduce a new level of output buffering, where
the caller can request the output not to be flushed, but to be retained
for further processing.

This latter feature will be needed when teaching the sequencer to do
rebase -i's brunt work: it wants to control the output of the
cherry-picks (i.e. recursive merges).

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 0eb23a6..81836f2 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -191,25 +191,26 @@ static void output(struct merge_options *o, int v, const 
char *fmt, ...)
 
 static void output_commit_title(struct merge_options *o, struct commit *commit)
 {
-   int i;
-   flush_output(o);
-   for (i = o->call_depth; i--;)
-   fputs("  ", stdout);
+   strbuf_addchars(>obuf, ' ', o->call_depth * 2);
if (commit->util)
-   printf("virtual %s\n", merge_remote_util(commit)->name);
+   strbuf_addf(>obuf, "virtual %s\n",
+   merge_remote_util(commit)->name);
else {
-   printf("%s ", find_unique_abbrev(commit->object.oid.hash, 
DEFAULT_ABBREV));
+   strbuf_addf(>obuf, "%s ",
+   find_unique_abbrev(commit->object.oid.hash,
+   DEFAULT_ABBREV));
if (parse_commit(commit) != 0)
-   printf(_("(bad commit)\n"));
+   strbuf_addf(>obuf, _("(bad commit)\n"));
else {
const char *title;
const char *msg = get_commit_buffer(commit, NULL);
int len = find_commit_subject(msg, );
if (len)
-   printf("%.*s\n", len, title);
+   strbuf_addf(>obuf, "%.*s\n", len, title);
unuse_commit_buffer(commit, msg);
}
}
+   flush_output(o);
 }
 
 static int add_cacheinfo(struct merge_options *o,
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 10/17] merge-recursive: switch to returning errors instead of dying

[Johannes Schindelin]

The recursive merge machinery is supposed to be a library function, i.e.
it should return an error when it fails. Originally the functions were
part of the builtin "merge-recursive", though, where it was simpler to
call die() and be done with error handling.

The existing callers were already prepared to detect negative return
values to indicate errors and to behave as previously: exit with code 128
(which is the same thing that die() does, after printing the message).

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 59 +++
 1 file changed, 33 insertions(+), 26 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 209427c..10010a4 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -266,8 +266,10 @@ struct tree *write_tree_from_memory(struct merge_options 
*o)
active_cache_tree = cache_tree();
 
if (!cache_tree_fully_valid(active_cache_tree) &&
-   cache_tree_update(_index, 0) < 0)
-   die(_("error building trees"));
+   cache_tree_update(_index, 0) < 0) {
+   error(_("error building trees"));
+   return NULL;
+   }
 
result = lookup_tree(active_cache_tree->sha1);
 
@@ -708,12 +710,10 @@ static int make_room_for_path(struct merge_options *o, 
const char *path)
/* Make sure leading directories are created */
status = safe_create_leading_directories_const(path);
if (status) {
-   if (status == SCLD_EXISTS) {
+   if (status == SCLD_EXISTS)
/* something else exists */
-   error(msg, path, _(": perhaps a D/F conflict?"));
-   return -1;
-   }
-   die(msg, path, "");
+   return error(msg, path, _(": perhaps a D/F conflict?"));
+   return error(msg, path, "");
}
 
/*
@@ -741,6 +741,8 @@ static int update_file_flags(struct merge_options *o,
  int update_cache,
  int update_wd)
 {
+   int ret = 0;
+
if (o->call_depth)
update_wd = 0;
 
@@ -761,9 +763,11 @@ static int update_file_flags(struct merge_options *o,
 
buf = read_sha1_file(sha, , );
if (!buf)
-   die(_("cannot read object %s '%s'"), sha1_to_hex(sha), 
path);
-   if (type != OBJ_BLOB)
-   die(_("blob expected for %s '%s'"), sha1_to_hex(sha), 
path);
+   return error(_("cannot read object %s '%s'"), 
sha1_to_hex(sha), path);
+   if (type != OBJ_BLOB) {
+   ret = error(_("blob expected for %s '%s'"), 
sha1_to_hex(sha), path);
+   goto free_buf;
+   }
if (S_ISREG(mode)) {
struct strbuf strbuf = STRBUF_INIT;
if (convert_to_working_tree(path, buf, size, )) {
@@ -784,8 +788,10 @@ static int update_file_flags(struct merge_options *o,
else
mode = 0666;
fd = open(path, O_WRONLY | O_TRUNC | O_CREAT, mode);
-   if (fd < 0)
-   die_errno(_("failed to open '%s'"), path);
+   if (fd < 0) {
+   ret = error_errno(_("failed to open '%s'"), 
path);
+   goto free_buf;
+   }
write_in_full(fd, buf, size);
close(fd);
} else if (S_ISLNK(mode)) {
@@ -793,18 +799,18 @@ static int update_file_flags(struct merge_options *o,
safe_create_leading_directories_const(path);
unlink(path);
if (symlink(lnk, path))
-   die_errno(_("failed to symlink '%s'"), path);
+   ret = error_errno(_("failed to symlink '%s'"), 
path);
free(lnk);
} else
-   die(_("do not know what to do with %06o %s '%s'"),
-   mode, sha1_to_hex(sha), path);
+   ret = error(_("do not know what to do with %06o %s 
'%s'"),
+   mode, sha1_to_hex(sha), path);
  free_buf:
free(buf);
}
  update_index:
-   if (update_cache)
+   if (!ret && update_cache)
add_cacheinfo(mode, sha, path, 0, update_wd, 
ADD_CACHE_OK_TO_ADD);
-   return 0;
+   return ret;
 }
 
 static int update_file(struct merge_options *o,
@@ -930,20 +936,22 @@ static int merge_file_1(struct merge_options *o,
hashcpy(result->sha, a->sha1);
else if (S_ISREG(a->mode)) {
mmbuffer_t result_buf;
-   int 

[PATCH v2 06/17] merge_recursive: abort properly upon errors

[Johannes Schindelin]

There are a couple of places where return values indicating errors
are ignored. Let's teach them manners.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 66ce27c..716488b 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1942,8 +1942,9 @@ int merge_recursive(struct merge_options *o,
saved_b2 = o->branch2;
o->branch1 = "Temporary merge branch 1";
o->branch2 = "Temporary merge branch 2";
-   merge_recursive(o, merged_common_ancestors, iter->item,
-   NULL, _common_ancestors);
+   if (merge_recursive(o, merged_common_ancestors, iter->item,
+   NULL, _common_ancestors) < 0)
+   return -1;
o->branch1 = saved_b1;
o->branch2 = saved_b2;
o->call_depth--;
@@ -1959,6 +1960,8 @@ int merge_recursive(struct merge_options *o,
o->ancestor = "merged common ancestors";
clean = merge_trees(o, h1->tree, h2->tree, 
merged_common_ancestors->tree,
);
+   if (clean < 0)
+   return clean;
 
if (o->call_depth) {
*result = make_virtual_commit(mrtree, "merged tree");
@@ -2015,6 +2018,9 @@ int merge_recursive_generic(struct merge_options *o,
hold_locked_index(lock, 1);
clean = merge_recursive(o, head_commit, next_commit, ca,
result);
+   if (clean < 0)
+   return clean;
+
if (active_cache_changed &&
write_locked_index(_index, lock, COMMIT_LOCK))
return error(_("Unable to write index."));
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 15/17] merge-recursive: offer an option to retain the output in 'obuf'

[Johannes Schindelin]

Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14),
we already accumulate the output in a buffer. The idea was to avoid
interfering with the progress output that goes to stderr, which is
unbuffered, when we write to stdout, which is buffered.

We extend that buffering to allow the caller to handle the output
(possibly suppressing it). This will help us when extending the
sequencer to do rebase -i's brunt work: it does not want the picks to
print anything by default but instead determine itself whether to print
the output or not.

Note that we also redirect the error messages into the output buffer
when the caller asked not to flush the output buffer, for two reasons:
1) to retain the correct output order, and 2) to allow the caller to
suppress *all* output.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 17 +
 merge-recursive.h |  2 +-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 81836f2..29cbdac 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -25,7 +25,7 @@
 
 static void flush_output(struct merge_options *o)
 {
-   if (o->obuf.len) {
+   if (o->buffer_output < 2 && o->obuf.len) {
fputs(o->obuf.buf, stdout);
strbuf_reset(>obuf);
}
@@ -36,10 +36,19 @@ static int err(struct merge_options *o, const char *err, 
...)
va_list params;
 
va_start(params, err);
-   flush_output(o);
+   if (o->buffer_output < 2)
+   flush_output(o);
+   else {
+   strbuf_complete(>obuf, '\n');
+   strbuf_addstr(>obuf, "error: ");
+   }
strbuf_vaddf(>obuf, err, params);
-   error("%s", o->obuf.buf);
-   strbuf_reset(>obuf);
+   if (o->buffer_output > 1)
+   strbuf_addch(>obuf, '\n');
+   else {
+   error("%s", o->obuf.buf);
+   strbuf_reset(>obuf);
+   }
va_end(params);
 
return -1;
diff --git a/merge-recursive.h b/merge-recursive.h
index 52f0201..407d4fc 100644
--- a/merge-recursive.h
+++ b/merge-recursive.h
@@ -13,7 +13,7 @@ struct merge_options {
MERGE_RECURSIVE_THEIRS
} recursive_variant;
const char *subtree_shift;
-   unsigned buffer_output : 1;
+   unsigned buffer_output : 2; /* 1: output at end, 2: keep buffered */
unsigned renormalize : 1;
long xdl_opts;
int verbosity;
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 01/17] Verify that `git pull --rebase` shows the helpful advice when failing

[Johannes Schindelin]

Signed-off-by: Johannes Schindelin 
---
 t/t5520-pull.sh | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 3159956..b281d6f 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -255,6 +255,36 @@ test_expect_success '--rebase' '
test new = "$(git show HEAD:file2)"
 '
 
+test_expect_success '--rebase with conflicts shows advice' '
+   test_when_finished "git rebase --abort; git checkout -f to-rebase" &&
+   git checkout -b seq &&
+   printf "1\\n2\\n3\\n4\\n5\\n" >seq.txt &&
+   git add seq.txt &&
+   test_tick &&
+   git commit -m "Add seq.txt" &&
+   printf "6\\n" >>seq.txt &&
+   test_tick &&
+   git commit -m "Append to seq.txt" seq.txt &&
+   git checkout -b with-conflicts HEAD^ &&
+   printf "conflicting\\n" >>seq.txt &&
+   test_tick &&
+   git commit -m "Create conflict" seq.txt &&
+   test_must_fail git pull --rebase . seq 2>err >out &&
+   grep "When you have resolved this problem" out
+'
+test_expect_success 'failed --rebase shows advice' '
+   test_when_finished "git rebase --abort; git checkout -f to-rebase" &&
+   git checkout -b diverging &&
+   test_commit attributes .gitattributes "* text=auto" attrs &&
+   sha1="$(printf "1\\r\\n" | git hash-object -w --stdin)" &&
+   git update-index --cacheinfo 0644 $sha1 file &&
+   git commit -m v1-with-cr &&
+   git checkout -f -b fails-to-rebase HEAD^ &&
+   test_commit v2-without-cr file "2" file2-lf &&
+   test_must_fail git pull --rebase . diverging 2>err >out &&
+   grep "When you have resolved this problem" out
+'
+
 test_expect_success '--rebase fails with multiple branches' '
git reset --hard before-rebase &&
test_must_fail git pull --rebase . copy master 2>err &&
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 02/17] Report bugs consistently

[Johannes Schindelin]

The vast majority of error messages in Git's source code which report a
bug use the convention to prefix the message with "BUG:".

As part of cleaning up merge-recursive to stop die()ing except in case of
detected bugs, let's just make the remainder of the bug reports consistent
with the de facto rule.

Signed-off-by: Johannes Schindelin 
---
 builtin/ls-files.c |  3 ++-
 builtin/update-index.c |  2 +-
 grep.c |  8 
 imap-send.c|  4 ++--
 merge-recursive.c  | 15 +++
 sha1_file.c|  4 ++--
 trailer.c  |  2 +-
 transport.c|  2 +-
 wt-status.c|  4 ++--
 9 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index f02e3d2..00ea91a 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -118,7 +118,8 @@ static void show_killed_files(struct dir_struct *dir)
 */
pos = cache_name_pos(ent->name, ent->len);
if (0 <= pos)
-   die("bug in show-killed-files");
+   die("BUG: killed-file %.*s not found",
+   ent->len, ent->name);
pos = -pos - 1;
while (pos < active_nr &&
   ce_stage(active_cache[pos]))
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 6cdfd5f..ba04b19 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1146,7 +1146,7 @@ int cmd_update_index(int argc, const char **argv, const 
char *prefix)
report(_("Untracked cache enabled for '%s'"), 
get_git_work_tree());
break;
default:
-   die("Bug: bad untracked_cache value: %d", untracked_cache);
+   die("BUG: bad untracked_cache value: %d", untracked_cache);
}
 
if (active_cache_changed) {
diff --git a/grep.c b/grep.c
index 1e15b62..f1ca0a0 100644
--- a/grep.c
+++ b/grep.c
@@ -643,10 +643,10 @@ static struct grep_expr *prep_header_patterns(struct 
grep_opt *opt)
 
for (p = opt->header_list; p; p = p->next) {
if (p->token != GREP_PATTERN_HEAD)
-   die("bug: a non-header pattern in grep header list.");
+   die("BUG: a non-header pattern in grep header list.");
if (p->field < GREP_HEADER_FIELD_MIN ||
GREP_HEADER_FIELD_MAX <= p->field)
-   die("bug: unknown header field %d", p->field);
+   die("BUG: unknown header field %d", p->field);
compile_regexp(p, opt);
}
 
@@ -659,7 +659,7 @@ static struct grep_expr *prep_header_patterns(struct 
grep_opt *opt)
 
h = compile_pattern_atom();
if (!h || pp != p->next)
-   die("bug: malformed header expr");
+   die("BUG: malformed header expr");
if (!header_group[p->field]) {
header_group[p->field] = h;
continue;
@@ -1464,7 +1464,7 @@ static int grep_source_1(struct grep_opt *opt, struct 
grep_source *gs, int colle
case GREP_BINARY_TEXT:
break;
default:
-   die("bug: unknown binary handling mode");
+   die("BUG: unknown binary handling mode");
}
}
 
diff --git a/imap-send.c b/imap-send.c
index 938c691..369f72a 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -506,12 +506,12 @@ static char *next_arg(char **s)
 
 static int nfsnprintf(char *buf, int blen, const char *fmt, ...)
 {
-   int ret;
+   int ret = -1;
va_list va;
 
va_start(va, fmt);
if (blen <= 0 || (unsigned)(ret = vsnprintf(buf, blen, fmt, va)) >= 
(unsigned)blen)
-   die("Fatal: buffer too small. Please report a bug.");
+   die("BUG: buffer too small (%d < %d)", ret, blen);
va_end(va);
return ret;
 }
diff --git a/merge-recursive.c b/merge-recursive.c
index 65cb5d6..9849439 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -259,7 +259,7 @@ struct tree *write_tree_from_memory(struct merge_options *o)
fprintf(stderr, "BUG: %d %.*s\n", ce_stage(ce),
(int)ce_namelen(ce), ce->name);
}
-   die("Bug in merge-recursive.c");
+   die("BUG: unmerged index entries in merge-recursive.c");
}
 
if (!active_cache_tree)
@@ -955,9 +955,8 @@ static struct merge_file_info merge_file_1(struct 
merge_options *o,
 
if (!sha_eq(a->sha1, b->sha1))
result.clean = 0;
-   } else {
-   

[PATCH v2 04/17] merge-recursive: clarify code in was_tracked()

[Johannes Schindelin]

It can be puzzling to see that was_tracked() asks to get an index entry
by name, but does not take a negative return value for an answer.

The reason we have to do this is that cache_name_pos() only looks for
entries in stage 0, even if nobody asked for any stage in particular.

Let's rewrite the logic a little bit, to handle the easy case early: if
cache_name_pos() returned a non-negative position, we know it is a match,
and we do not even have to compare the name again (cache_name_pos() did
that for us already). We can say right away: yes, this file was tracked.

Only if there was no exact match do we need to look harder for any
matching entry in stage 2.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index e51f8fc..66ce27c 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -658,23 +658,22 @@ static int was_tracked(const char *path)
 {
int pos = cache_name_pos(path, strlen(path));
 
-   if (pos < 0)
-   pos = -1 - pos;
-   while (pos < active_nr &&
-  !strcmp(path, active_cache[pos]->name)) {
+   if (pos >= 0)
+   return pos < active_nr;
+   /*
+* cache_name_pos() looks for stage == 0, even if we did not ask for
+* it. Let's look for stage == 2 now.
+*/
+   for (pos = -1 - pos; pos < active_nr &&
+!strcmp(path, active_cache[pos]->name); pos++)
/*
 * If stage #0, it is definitely tracked.
 * If it has stage #2 then it was tracked
 * before this merge started.  All other
 * cases the path was not tracked.
 */
-   switch (ce_stage(active_cache[pos])) {
-   case 0:
-   case 2:
+   if (ce_stage(active_cache[pos]) == 2)
return 1;
-   }
-   pos++;
-   }
return 0;
 }
 
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 03/17] Avoid translating bug messages

[Johannes Schindelin]

While working on the patch series that avoids die()ing in recursive
merges, the issue came up that bug reports (i.e. die("BUG: ...")
constructs) should never be translated, as the target audience is the
Git developer community, not necessarily the current user, and hence
a translated message would make it *harder* to address the problem.

So let's stop translating the obvious ones. As it is really, really
outside the purview of this patch series to see whether there are more
die() statements that report bugs and are currently translated, that
task is left for another day and patch.

Signed-off-by: Johannes Schindelin 
---
 merge-recursive.c | 6 +++---
 wt-status.c   | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/merge-recursive.c b/merge-recursive.c
index 9849439..e51f8fc 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -956,7 +956,7 @@ static struct merge_file_info merge_file_1(struct 
merge_options *o,
if (!sha_eq(a->sha1, b->sha1))
result.clean = 0;
} else
-   die(_("BUG: unsupported object type in the tree"));
+   die("BUG: unsupported object type in the tree");
}
 
return result;
@@ -1794,7 +1794,7 @@ static int process_entry(struct merge_options *o,
 */
remove_file(o, 1, path, !a_mode);
} else
-   die(_("BUG: fatal merge failure, shouldn't happen."));
+   die("BUG: fatal merge failure, shouldn't happen.");
 
return clean_merge;
 }
@@ -1852,7 +1852,7 @@ int merge_trees(struct merge_options *o,
for (i = 0; i < entries->nr; i++) {
struct stage_data *e = entries->items[i].util;
if (!e->processed)
-   die(_("BUG: unprocessed path??? %s"),
+   die("BUG: unprocessed path??? %s",
entries->items[i].string);
}
 
diff --git a/wt-status.c b/wt-status.c
index 311ae7c..75c1162 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -263,7 +263,7 @@ static const char *wt_status_unmerged_status_string(int 
stagemask)
case 7:
return _("both modified:");
default:
-   die(_("BUG: unhandled unmerged status %x"), stagemask);
+   die("BUG: unhandled unmerged status %x", stagemask);
}
 }
 
@@ -388,7 +388,7 @@ static void wt_status_print_change_data(struct wt_status *s,
status_printf(s, color(WT_STATUS_HEADER, s), "\t");
what = wt_status_diff_status_string(status);
if (!what)
-   die(_("BUG: unhandled diff status %c"), status);
+   die("BUG: unhandled diff status %c", status);
len = label_width - utf8_strwidth(what);
assert(len >= 0);
if (status == DIFF_STATUS_COPIED || status == DIFF_STATUS_RENAMED)
-- 
2.9.0.280.g32e2a70


--
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://vger.kernel.org/majordomo-info.html

[PATCH v2 00/17] Use merge_recursive() directly in the builtin am

[Johannes Schindelin]

This is the second iteration of the long-awaited re-roll of the attempt to
avoid spawning merge-recursive from the builtin am and use merge_recursive()
directly instead.

The *real* reason for the reroll is that I need a libified recursive
merge to accelerate the interactive rebase by teaching the sequencer to
do rebase -i's grunt work.

In this endeavor, we need to be extra careful to retain backwards
compatibility. The test script t6022-merge-rename.sh, for example, verifies
that `git pull` exits with status 128 in case of a fatal error. To that end,
we need to make sure that fatal errors are handled by existing (builtin)
users via exit(128) (or die(), which calls exit(128) at the end).  New users
(such as a builtin helper doing rebase -i's grunt work) may want to print
some helpful advice what happened and how to get out of this mess before
erroring out.

The changes relative to the first iteration of this patch series:

- a variable that could be used uninitialized is now initialized (thanks,
  Travis & clang!)

- several commit messages were touched up (and I hope y'all agree, improved)

- an unnecessary hunk was reverted (this was a left-over from an
  unpublished iteration that needed to retain return values faithfully, i.e.
  it made a difference between -1 and -128 as error value)

- Junio's patch to use recursive_merge() directly in the builtin am was
  replaced by a different solution

- an error message was identified as, and converted into, a bug report
  instead

- the code in was_tracked() now avoids a loop when it is unnecessary,
  and further clarifies why we keep looking when cache_name_pos() did
  not find the entry we asked for

- die("BUG: ...") statements are no longer translated

- one die("BUG: ...") report that continued in upper-case after the "BUG:"
  prefix was fixed

- I addressed a gender bias that has been bugging me ever since I noticed it

- recursive merge's error messages are now printed after flushing the
  output buffer (instead of swallowing that output)

- callers of the recursive merge can now ask that the output buffer not be
  flushed, but retained without printing it instead. This gives the caller the
  control about handling errors which Junio asked for.

- some long-standing bugs have been recognized and addressed:

  - when the recursive merge failed, it lost the buffered output

  - the output buffer of the recursive merge was never released

  - some stdout/stderr interference that we tried to address in 2007 is
now fully addressed (the progress output could be printed in the
middle of the commit title because the latter was still directly printed
to stdout, which is buffered, instead of being buffered and flushed)

- a lot of unnecessary 'ret' variables are gone now: originally, I wanted to
  retain the *exact* return value, but now errors are indicated by -1,
  always

- lastly, I remembered that my original attempt at fixing the pull --rebase
  issue contained a test case, and I forward-ported that, and augmented it

So while I addressed all comments, I also went through the patch series a
couple of times myself and whatever bugged me, I tried to resolve, too.

This patch series touches rather important code. Now that I addressed
concerns such as fixing translated bug reports, I would appreciate thorough
reviews with a focus on the critical parts of the code, those that could
result in regressions.


Johannes Schindelin (17):
  Verify that `git pull --rebase` shows the helpful advice when failing
  Report bugs consistently
  Avoid translating bug messages
  merge-recursive: clarify code in was_tracked()
  Prepare the builtins for a libified merge_recursive()
  merge_recursive: abort properly upon errors
  merge-recursive: avoid returning a wholesale struct
  merge-recursive: allow write_tree_from_memory() to error out
  merge-recursive: handle return values indicating errors
  merge-recursive: switch to returning errors instead of dying
  am: counteract gender bias
  am -3: use merge_recursive() directly again
  merge-recursive: flush output buffer before printing error messages
  merge-recursive: write the commit title in one go
  merge-recursive: offer an option to retain the output in 'obuf'
  Ensure that the output buffer is released after calling merge_trees()
  merge-recursive: flush output buffer even when erroring out

 builtin/am.c   |  55 ++
 builtin/checkout.c |   5 +-
 builtin/ls-files.c |   3 +-
 builtin/merge.c|   2 +
 builtin/update-index.c |   2 +-
 grep.c |   8 +-
 imap-send.c|   4 +-
 merge-recursive.c  | 490 +
 merge-recursive.h  |   2 +-
 sequencer.c|   5 +
 sha1_file.c|   4 +-
 t/t5520-pull.sh|  30 +++
 trailer.c  |   2 +-
 transport.c|   2 +-
 wt-status.c|   4 +-
 15 files changed, 369 insertions(+), 249 deletions(-)

Published-As: 

Re: GIT Integration with Siebel

[tarun patanwar]

Hi Johannes,

Thanks for getting back.

Siebel is a Oracle Product for CRM implementation, just like SAP and
SalesForce. So Siebel as a product provides option to integrate any
third party Source Control tool with it.

Integration between Siebel and Source Control tool is facilitated by
the batch file (srcctrl.bat) which contains configuration details
about Source Control tool. While developers checks in/out their code
into Siebel Server, this batch file gets triggered and invokes Source
Control command line to check in a version into repository.

I'll be happy to provide further information is needed.

Thanks,
Tarun Patanwar
+44-7778471437

On Tue, Jul 5, 2016 at 11:02 AM, Johannes Schindelin
 wrote:
> Hi Tarun,
>
> On Tue, 5 Jul 2016, tarun patanwar wrote:
>
>> We are trying to integrate GIT with Siebel 8.1 for source code control.
>> We are not able to progress further since there seems to be no
>> documentation available for the same.
>
> Would you kindly explain what Siebel is, and what purpose the batch file
> you want to adapt is supposed to serve?
>
> Ciao,
> Johannes
--
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://vger.kernel.org/majordomo-info.html

Re: GIT Integration with Siebel

[Johannes Schindelin]

Hi Tarun,

On Tue, 5 Jul 2016, tarun patanwar wrote:

> We are trying to integrate GIT with Siebel 8.1 for source code control.
> We are not able to progress further since there seems to be no
> documentation available for the same.

Would you kindly explain what Siebel is, and what purpose the batch file
you want to adapt is supposed to serve?

Ciao,
Johannes
--
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://vger.kernel.org/majordomo-info.html

Re: split directories into branches

[Konstantin Khomoutov]

On Mon, 4 Jul 2016 17:03:46 -0400
shawn wilson  wrote:

[...]
> > I don't possess the official stance on this topic but AFAIK
> > user-level questions are fine on this list.
> 
> In that case :)
> ... still having issues w/ filter-branch:
[...]

I used something along these lines:

  git filter-branch -f --tree-filter \
'test -e my/new/dir || mkdir -p my/new/dir
  find . -mindepth 1 -maxdepth 1 \
  -type d -path ./my -prune -o -print \
  | xargs -n 30 mv -t ./my/new/dir' master 

More background on how it works [1] if you want.

1. https://groups.google.com/d/msg/git-users/hxFmfUZpj_k/9IQAQq40BwAJ
--
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://vger.kernel.org/majordomo-info.html

GIT Integration with Siebel

[tarun patanwar]

Dear GIT Team,

We are trying to integrate GIT with Siebel 8.1 for source code
control. We are not able to progress further since there seems to be
no documentation available for the same.

Siebel provides a batch control file (srcctrl.bat) which can be
amended for Source Control Toll integration.

In the past we have used Microsoft VSS and SVN for source control,
Below is a example srcctrl.bat file for reference.

Any help on this will be greatly appreciated.

rem===
rem === User defined parameters ==
rem 
set PATH=C:\Program Files\TortoiseSVN\bin;%PATH%
set SVN_URL=svn://svn_ip_address/svn_example
set SVN_REPOS=trunk
set SRC_USR=yourusername
set SRC_PSWD=yourpassword
set LOGFILE=D:\development\projects\svn_example\svn_integration.log
set WORKING_DIR=D:\development\projects\svn_example
rem LOGFILE SHOULD NOT HAVE SPACES IN ITS PATH
rem 
rem 


Thanks,
Tarun Patanwar
+44-7778471437
--
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://vger.kernel.org/majordomo-info.html

Re: Missing Package in git Installation Instructions (git-scm.com)

[Johannes Schindelin]

Hi Chris,

On Tue, 5 Jul 2016, Christoph Michelbach wrote:

> Hi, I noticed that the instructions on https://git-scm.com/book/en/v2/G
> etting-Started-Installing-Git don't work without dh-autoreconf
> installed on an apt-get system which isn't listed on that site. Can you
> fix that or tell me whom to tell about this? The website doesn't offer
> contact information. Just tried this on a fresh Ubuntu 16.04
> installation.

When you follow that link, do you see this text on the left side?

The source of this book is hosted on GitHub.
Patches, suggestions and comments are welcome.

It links to https://github.com/progit/progit2 and I am sure your bug
report would make an excellent contribution to the bug tracker ("Issues")
in that repository.

It would probably be even better if you cloned said repository, found the
respective file via `git grep apt-get`, fixed it, and opened a Pull
Request.

Ciao,
Johannes