RE: [RFC] git clone add option to track all remote branches

[Randall S. Becker]

On April 1, 2018 11:22 PM Junio C Hamano wrote:
> Junio C Hamano  writes:
> > If you are really doing your own development, then you would have some
> > topic branches of your own, with forks of some (but most likely not
> > all, especiallyi when there are many branches at the upstream)
> > branches you got from the upstream, and "git branch --list" that shows
> > only your own and what you are interested in (i.e. those that you
> > actually bothered to "git checkout ") without showing
> > random other branches that exist at the remote but do not interest you
> > is a feature.  Your hypothetical "clone" that indiscriminatedly forks
> > all branches at remote locally will destroy the usefulness of it.
> 
> Related to this, a feature I have long thought we wished to have is
complete
> opposite of this.  After creating and working on a local topic branch and
then
> concluding the work on it, a user would "git push" the branch out to a
> remote, and then check out a different branch (e.g. the 'master' branch).
I
> wish we had a mode that would automatically *delete* the local topic
branch
> that has already been pushed out (and more importantly, a branch that I
> have *done* with, at least for now), to unclutter my local branch
> namespace.  When I want to further work on it, I can ask "git checkout" to
> dwim to recreate one on demand.
> 
> Of course, there are some wrinkles due to pesky impleemntation details
> (e.g. the "autonuke-and-recreate" would lose reflog), but I do not think
it is
> fundamental hurdle.

I'm a little skeptical and confused here. The original RFC does not appear
to stipulate that this is isolated to a single bare. If B,C,D all clone
A.git from one server, it might be ok. If B clones A.git, and C clones B,
and D mirrors C, where would the remote tracking occur. The main value, as a
repo admin of A.git would be to know everything, but that's unlikely.
Stating the obvious rub is, in a DVCS, where connections are not guaranteed,
one can easily move a clone or delete a clone, and your tracking branch
becomes worthless. You might never know about C/D mirrors or even be able to
establish a connection between A.git and those two, in practice - I have
examples of those.
OTOH I have been toying with suggesting a solution to this for a couple of
years, differentiating a transient clone from a (pick a term) authentic
clone, the latter which has some blockchainish so that git will whine
without a valid signature on the clone. Changing the clone without
communicating with the upstream to revalidate it (deferrals could be
implemented), temporarily or permanently invalidates the authentic clone so
it effective becomes pruneable, like a worktree. I see a very deep potential
rabbit hole here that detracts from DVCS principles unless we do have the
conceptual split of the two classes of clones. rm .git is just too easy and
too frequent an operation to just ignore the implication of the deliberate
loss of tracking that is highly unlikely to be trackable by the farthest
upstream, resulting in a whole lot of clutter with no way back.
Alternatively, if the downstreams periodically are forced to revalidate the
tracking branches, then you have sometime potentially workable but annoying
at best, and impractical in some security policies at worst.

Just my $0.02 from managing boat-loads of 4 and 5 level deep repositories.

Cheers,
Randall

[PATCH 2/2] ls-remote: create option to sort by versions

[Harald Nordgren]

Updating tests and documentation

Signed-off-by: Harald Nordgren 
---
 Documentation/git-ls-remote.txt |  5 +
 t/t5512-ls-remote.sh| 19 ++-
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
index 5f2628c8f..81c518a90 100644
--- a/Documentation/git-ls-remote.txt
+++ b/Documentation/git-ls-remote.txt
@@ -30,6 +30,11 @@ OPTIONS
both, references stored in refs/heads and refs/tags are
displayed.
 
+-V::
+--version-sort::
+   Sort ref names by version semantics, so that refs/tags/v1.2 is sorted
+   before refs/tags/v1.10.
+
 --refs::
Do not show peeled tags or pseudorefs like HEAD in the output.
 
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 02106c922..680a31223 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -10,6 +10,9 @@ test_expect_success setup '
test_tick &&
git commit -m initial &&
git tag mark &&
+   git tag mark1.1 &&
+   git tag mark1.2 &&
+   git tag mark1.10 &&
git show-ref --tags -d | sed -e "s/ /   /" >expected.tag &&
(
echo "$(git rev-parse HEAD) HEAD"
@@ -39,6 +42,17 @@ test_expect_success 'ls-remote self' '
test_cmp expected.all actual
 '
 
+test_expect_success 'ls-remote --version-sort --tags self' '
+   cat >expect <<-\EOF &&
+   1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark
+   1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.1
+   1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.2
+   1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.10
+   EOF
+   git ls-remote --version-sort --tags self >actual &&
+   test_cmp expect actual
+'
+
 test_expect_success 'dies when no remote specified and no default remotes 
found' '
test_must_fail git ls-remote
 '
@@ -131,7 +145,7 @@ test_expect_success 'Report no-match with --exit-code' '
 
 test_expect_success 'Report match with --exit-code' '
git ls-remote --exit-code other.git "refs/tags/*" >actual &&
-   git ls-remote . tags/mark >expect &&
+   git ls-remote . tags/mark* >expect &&
test_cmp expect actual
 '
 
@@ -178,6 +192,9 @@ test_expect_success 'ls-remote --symref' '
1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/remotes/origin/HEAD
1bd44cb9d13204b0fe1958db0082f5028a16eb3a
refs/remotes/origin/master
1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark
+   1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.1
+   1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.10
+   1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.2
EOF
git ls-remote --symref >actual &&
test_cmp expect actual
-- 
2.14.3 (Apple Git-98)

Re: [RFC] git clone add option to track all remote branches

[Junio C Hamano]

Junio C Hamano  writes:

> If you are really doing your own development, then you would have
> some topic branches of your own, with forks of some (but most likely
> not all, especiallyi when there are many branches at the upstream)
> branches you got from the upstream, and "git branch --list" that
> shows only your own and what you are interested in (i.e. those that
> you actually bothered to "git checkout ") without
> showing random other branches that exist at the remote but do not
> interest you is a feature.  Your hypothetical "clone" that
> indiscriminatedly forks all branches at remote locally will destroy
> the usefulness of it.

Related to this, a feature I have long thought we wished to have is
complete opposite of this.  After creating and working on a local
topic branch and then concluding the work on it, a user would "git
push" the branch out to a remote, and then check out a different
branch (e.g. the 'master' branch).  I wish we had a mode that would
automatically *delete* the local topic branch that has already been
pushed out (and more importantly, a branch that I have *done* with,
at least for now), to unclutter my local branch namespace.  When I
want to further work on it, I can ask "git checkout" to dwim to
recreate one on demand.

Of course, there are some wrinkles due to pesky impleemntation
details (e.g. the "autonuke-and-recreate" would lose reflog), but I
do not think it is fundamental hurdle.

Re: [RFC] git clone add option to track all remote branches

[Junio C Hamano]

Yubin Ruan  writes:

> I am writing to ask that whether or not you think will be appropriate to add
> an option to "git clone" so that whenever a repo is cloned, branches are
> created automatically to track corresponding remote branches. (or is there any
> equivelant option?)
>
> You can obviously do this by a bash command like this
>
> git branch -r | grep -v '\->' | while read remote; do git branch --track 
> "${remote#origin/}" "$remote"; done
>
> but it will be better if we can have an option in "git clone".

I am not sure how it will be more useful than what you already have.
In short, you are getting "all of the remote branches" but with a
twist.  You get them "on demand".

With your hypothetical "clone" command that makes copies of each and
every remote branch to a local one, you can ask "git branch"
to show all of them (i.e. "please list what is happening at the
central repository").  With the current system, you would instead
need to ask "git branch -r", which may be a bit more to type.

Also when you want to look at or work on top of a remote branch, say
"frotz", you do not have to do "git checkout -b frotz origin/frotz"
to create one, as your hypothetical "clone" would have already
created it when you cloned.  But I think "git checkout frotz" in
such a situation would create a local "frotz" branch out of the
"origin/frotz" remote-tracking branch with the current system, so
I do not think your hypothetical "clone" is all that more useful.

And there certainly is a huge downside.

If you are really doing your own development, then you would have
some topic branches of your own, with forks of some (but most likely
not all, especiallyi when there are many branches at the upstream)
branches you got from the upstream, and "git branch --list" that
shows only your own and what you are interested in (i.e. those that
you actually bothered to "git checkout ") without
showing random other branches that exist at the remote but do not
interest you is a feature.  Your hypothetical "clone" that
indiscriminatedly forks all branches at remote locally will destroy
the usefulness of it.

[RFC] git clone add option to track all remote branches

[Yubin Ruan]

Hi,

I am writing to ask that whether or not you think will be appropriate to add
an option to "git clone" so that whenever a repo is cloned, branches are
created automatically to track corresponding remote branches. (or is there any
equivelant option?)

You can obviously do this by a bash command like this

git branch -r | grep -v '\->' | while read remote; do git branch --track 
"${remote#origin/}" "$remote"; done

but it will be better if we can have an option in "git clone".

Regards,
Yubin

Re: [PATCH] Support long format for log-based submodule diff

[Robert Dailey]

On Tue, Mar 27, 2018 at 5:17 PM, Stefan Beller  wrote:
>> >> $ git diff --submodule=log --submodule-log-detail=(long|short)
>> >>
>> >> I'm not sure what makes sense here. I welcome thoughts/discussion and
>> >> will provide follow-up patches.
>> >
>> > The case of merges is usually configured with --[no-]merges, or
>> > --min-parents=.
>
>> But that is a knob that controls an irrelevant aspect of the detail
>> in the context of this discussion, isn't it?  This code is about "to
>> what degree the things that happened between two submodule commits
>> in an adjacent pair of commits in the superproject are summarized?"
>
> And I took it a step further and wanted to give a general solution, which
> allows giving any option that the diff machinery accepts to only apply
> to the submodule diffing part of the current diff.
>
>> The hack Robert illustrates below is to change it to stop favouring
>> such projects with "clean" histories, and show "log --oneline
>> --no-merges --left-right".  When presented that way, clean histories
>> of topic-branch based projects will suffer by losing conciseness,
>> but clean histories of totally linear projects will still be shown
>> the same way, and messy history that sometimes merges, sometimes
>> merges mergy histories, and sometimes directly builds on the trunk
>> will be shown as an enumeration of individual commits in a flat way
>> by ignoring merges and not restricting the traversal to the first
>> parent chains, which would appear more uniform than what the current
>> code shows.
>
> Oh, I realize this is in the *summary* code path, I was thinking about the
> show_submodule_inline_diff, which would benefit from more diff options.
>
>> I do not see a point in introducing --min/max-parents as a knob to
>> control how the history is summarized.
>
> For a summary a flat list of commits may be fine, ignoring
> (ideally non-evil) merges.
>
>> This is a strongly related tangent, but I wonder if we can and/or
>> want to share more code with the codepath that prepares the log
>> message for a merge.  It summarizes what happened on the side branch
>> since it forked from the history it is joining back to (I think it
>> is merge.c::shortlog() that computes this)
>
> I do not find code there. To me it looks like builtin/fmt-merge-msg.c
> is responsible for coming up with a default merge message?
> In that file there is a shortlog() function, which walks revisions
> and puts together the subject lines of commits.
>
>> and it is quite similar
>> to what Robert wants to use for submodules here.  On the other hand,
>> in a project _without_ submodule, if you are pulling history made by
>> your lieutenant whose history is full of linear merges of topic
>> branches to the mainline, it may not be a bad idea to allow
>> fmt-merge-msg to alternatively show something similar to the "diff
>> --submodule=log" gives us, i.e. summarize the history of the side
>> branch being merged by just listing the commits on the first-parent
>> chain.  So I sense some opportunity for cross pollination here.
>
> The cross pollination that I sense is the desire in both cases to freely
> specify the format as it may depend on the workflow.

First I want to apologize for having taken so long to get back with
each of you about this. I actually have a lot of work started to
expand the --submodule option to add a "full-log" option in addition
to the existing "log". This is a pretty big task for me already,
mostly because I'm unfamiliar with git and have limited personal time
to do this at home (this is part of what I am apologizing for). I kind
of get what Stefan and Junio are saying. There's a lot of opportunity
for cleanup. More specific to my use case, adding some functionality
to generate a log message (although I've developed a bash script to do
this since I wrote my original email. I'll attach it to this email for
those interested). Also I get that taking this a notch higher and
adding a new option to pass options down to submodules also addresses
my case. Before I waste anyone's time on this, I want to make sure
that my very narrow and specific implementation will be ideal. By all
means I do not want to do things the easy way which ends up adding
"cruft" you'll have to deal with later. If there's a larger effort to
generalize this and other things related to submodules maybe I can
just wait for that to happen instead? What direction would you guys
recommend?

Junio basically hit the nail on the head with the comparisons of
different mainlines. I think some repositories are more disciplined
than others. At my workplace, I deal with a lot of folks that aren't
interested in learning git beyond the required day to day
responsibilities. It's difficult to enforce very specific branching,
rebase, and merge habits. As such, the best I can do to work around
that for building release notes is to exclude merge commits (since
most of the time, people keep the default message which is generally

[PATCH] ls-remote: create option to sort by versions

[Harald Nordgren]

Create the options '-V ' and '--version-sort' to sort
'git ls-remote' output by version semantics. This is useful e.g. for
the Go repository after the release of version 1.10, where otherwise
v1.10 is sorted before v1.2. See:

$ git ls-remote -t https://go.googlesource.com/go
...
205f850ceacfc39d1e9d76a9569416284594ce8crefs/tags/go1.1
d260448f6b6ac10efe4ae7f6dfe944e72bc2a676refs/tags/go1.1.1
1d6d8fca241bb611af51e265c1b5a2e9ae904702refs/tags/go1.1.2
bf86aec25972f3a100c3aa58a6abcbcc35bdea49refs/tags/go1.10
ac7c0ee26dda18076d5f6c151d8f920b43340ae3refs/tags/go1.10.1
9ce6b5c2ed5d3d5251b9a6a0c548d5fb2c8567e8refs/tags/go1.10beta1
594668a5a96267a46282ce3007a584ec07adf705refs/tags/go1.10beta2
5348aed83e39bd1d450d92d7f627e994c2db6ebfrefs/tags/go1.10rc1
20e228f2fdb44350c858de941dff4aea9f3127b8refs/tags/go1.10rc2
1c5438aae896edcd1e9f9618f4776517f08053b3refs/tags/go1.1rc2
46a6097aa7943a490e9bd2e04274845d0e5e200frefs/tags/go1.1rc3
402d3590b54e4a0df9fb51ed14b2999e85ce0b76refs/tags/go1.2
9c9802fad57c1bcb72ea98c5c55ea2652efc5772refs/tags/go1.2.1
...

Signed-off-by: Harald Nordgren 
---
 builtin/ls-remote.c | 27 +--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index 540d56429..740c6f117 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -1,6 +1,7 @@
 #include "builtin.h"
 #include "cache.h"
 #include "transport.h"
+#include "ref-filter.h"
 #include "remote.h"
 
 static const char * const ls_remote_usage[] = {
@@ -33,11 +34,20 @@ static int tail_match(const char **pattern, const char 
*path)
return 0;
 }
 
+static int cmp_ref_versions(const void *_a, const void *_b)
+{
+   const struct ref *a = *(const struct ref **)_a;
+   const struct ref *b = *(const struct ref **)_b;
+
+   return versioncmp(a->name, b->name);
+}
+
 int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 {
const char *dest = NULL;
unsigned flags = 0;
int get_url = 0;
+   int version_sort = 0;
int quiet = 0;
int status = 0;
int show_symref_target = 0;
@@ -47,6 +57,8 @@ int cmd_ls_remote(int argc, const char **argv, const char 
*prefix)
struct remote *remote;
struct transport *transport;
const struct ref *ref;
+   const struct ref **refs = NULL;
+   int nr = 0;
 
struct option options[] = {
OPT__QUIET(, N_("do not print remote URL")),
@@ -60,6 +72,8 @@ int cmd_ls_remote(int argc, const char **argv, const char 
*prefix)
OPT_BIT(0, "refs", , N_("do not show peeled tags"), 
REF_NORMAL),
OPT_BOOL(0, "get-url", _url,
 N_("take url..insteadOf into account")),
+   OPT_BOOL('V', "version-sort", _sort,
+N_("sort tags by version numbers")),
OPT_SET_INT_F(0, "exit-code", ,
  N_("exit with exit code 2 if no matching refs are 
found"),
  2, PARSE_OPT_NOCOMPLETE),
@@ -101,13 +115,22 @@ int cmd_ls_remote(int argc, const char **argv, const char 
*prefix)
if (transport_disconnect(transport))
return 1;
 
-   if (!dest && !quiet)
-   fprintf(stderr, "From %s\n", *remote->url);
for ( ; ref; ref = ref->next) {
if (!check_ref_type(ref, flags))
continue;
if (!tail_match(pattern, ref->name))
continue;
+   REALLOC_ARRAY(refs, nr + 1);
+   refs[nr++] = ref;
+   }
+
+   if (version_sort)
+   QSORT(refs, nr, cmp_ref_versions);
+
+   if (!dest && !quiet)
+   fprintf(stderr, "From %s\n", *remote->url);
+   for (int i = 0; i < nr; i++) {
+   const struct ref *ref = refs[i];
if (show_symref_target && ref->symref)
printf("ref: %s\t%s\n", ref->symref, ref->name);
printf("%s\t%s\n", oid_to_hex(>old_oid), ref->name);
-- 
2.14.3 (Apple Git-98)

Need help debugging issue in git

[Robert Dailey]

I'm struggling with a bug that I found introduced in git v2.13.2. The
bug was not reproducible in v2.13.1. The issue is that using arguments
like "@{-1}" to aliases causes those curly braces to be removed, so
once the command is executed after alias processing the argument looks
like "@-1". This breaks any aliases you have that wrap `git log` and
such. I originally opened the bug on the Git for Windows project
(since I use Git mostly on Windows):

https://github.com/git-for-windows/git/issues/1220

After digging into the code of run-command.c some more, I have a
change that fixes the issue but it doesn't feel like the right
solution. Furthermore, the function I'm modifying doesn't seem to have
been changed in the diff between v2.13.1 and v2.13.2. I'll provide my
diff at the bottom of this email for those curious as to what I've
modified.

I was not able to reproduce this bug on Linux. However, the way
aliases get expanded seems extremely wasteful. Essentially if an alias
already has $@ in it, Git shouldn't try to insert another one. This
results in the alias being repeated multiple times. I'll give you an
example (Note there's a ton of detail in the github post linked
earlier, and most of this is already there).

Here is the alias being used for a test:

[alias]
lgtest = !git log --oneline \"$@\"

And here is the command I invoke for the test:

$ git lgtest @{-1}

I should get logs for the previously-checked-out branch.

When `prepare_shell_cmd()` is called in run-command.c, it gets expanded like so:

+ [0] "sh" const char *
+ [1] "-c" const char *
+ [2] "git log --oneline \"$@\" \"$@\"" const char *
+ [3] "git log --oneline \"$@\"" const char *
+ [4] "@{-1}" const char *

With my modifications (again, patch inline below) I get this:

+ [0] "sh" const char *
+ [1] "-c" const char *
+ [2] "git log --oneline \"$@\"" const char *
+ [3] "@{-1}" const char *

The second version looks much better. I think the constant nesting of
commands inside each other that the first version does is somehow
causing curly braces to be removed. I don't understand enough about
shell processing to know why it would do this.

Essentially I don't feel like I'm addressing the root cause here. I
hope that someone has the time to take a peek and point me in the
right direction. If I can make sense of this maybe I can make a proper
fix somewhere.

Here is the patch:

diff --git a/run-command.c b/run-command.c
index 31fc5ea86e..39bab7f5b2 100644
--- a/run-command.c
+++ b/run-command.c
@@ -261,10 +261,10 @@ static const char **prepare_shell_cmd(struct
argv_array *out, const char **argv)
  if (!argv[1])
  argv_array_push(out, argv[0]);
  else
- argv_array_pushf(out, "%s \"$@\"", argv[0]);
+ argv_array_pushf(out, "%s", argv[0]);
  }

- argv_array_pushv(out, argv);
+ argv_array_pushv(out, argv+1);
  return out->argv;
 }

Re: [PATCH] builtin/commit.c: prevent bad commits

[Jeff King]

On Sun, Apr 01, 2018 at 05:06:50PM +0300, Dan Aloni wrote:

> These commits which have hashes starting with the hex string 'bad',
> always give me the chills. Why should a perfectly good commit be
> jinxed?
> 
> Statistically, one of 4096 commits may be 'bad'. This change adds a
> '--prevent-bad' switch to the commit command in order to prevent such
> commit hashes from being generated. Internally, the commit is retried
> with a slight commit meta-data modification - a newline is added to the
> end of the commit message. The meta-data change results in a different
> hash, that if we are lucky enough (4095/4096 chance) may not be 'bad'.
> 
> Note that this change does not affect actual software quality maintained
> using Git. Thus, it is recommended keep testing all generated versions
> regardless of commit hash jinxes.

Cute.

A while back we had patches to generate "desirable" commit prefixes, and
they were focused on making the brute-forcing as fast as possible. I
don't think I've seen this reverse case, but it's much easier: we can be
fairly slow since the probability of hitting the bad case repeatedly is
low.

> @@ -1583,12 +1585,34 @@ int cmd_commit(int argc, const char **argv, const 
> char *prefix)
>   append_merge_tag_headers(parents, );
>   }
>  
> - if (commit_tree_extended(sb.buf, sb.len, _cache_tree->oid,
> -  parents, , author_ident.buf, sign_commit,
> -  extra)) {
> - rollback_index_files();
> - die(_("failed to write commit object"));
> + for (;;) {
> + char *oid_hex;
> + struct commit_list *copy_parents;
> +
> + copy_parents = copy_commit_list(parents);
> +
> + if (commit_tree_extended(sb.buf, sb.len, 
> _cache_tree->oid,
> +  parents, , author_ident.buf, 
> sign_commit,
> +  extra)) {
> + rollback_index_files();
> + die(_("failed to write commit object"));
> + }

You could still have a "bad" tree. :)

-Peff

[PATCH] graph.c: log.showRootMark to indicate root commits

[Lyubomyr Shaydariv]

When log.showRootMark is set, root commits are marked with
the at sign (@).

When log.showRootMark is not set, root commits are marked with
the asterisk sign (*). This is the default behavior.

Signed-off-by: Lyubomyr Shaydariv 
---
 Documentation/config.txt  |  5 +
 Documentation/git-log.txt |  5 +
 graph.c   | 20 
 t/t4202-log.sh| 16 
 4 files changed, 46 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 4e0cff87f62f5..0a32357e3c625 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2254,6 +2254,11 @@ log.showRoot::
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
 
+log.showRootMark::
+   If true, the initial commit in `git log --graph` will be marked
+   with the at sign (`@`). Otherwise the initial commit will be
+   marked with the default asterisk sign (`*`). False by default.
+
 log.showSignature::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--show-signature`.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5437f8b0f0e66..7f5436231b6d7 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -205,6 +205,11 @@ log.showRoot::
`git log -p` output would be shown without a diff attached.
The default is `true`.
 
+log.showRootMark::
+   If true, the initial commit in `git log --graph` will be marked
+   with the at sign (`@`). Otherwise the initial commit will be
+   marked with the default asterisk sign (`*`). False by default.
+
 log.showSignature::
If `true`, `git log` and related commands will act as if the
`--show-signature` option was passed to them.
diff --git a/graph.c b/graph.c
index e1f6d3bddb38a..d14ffec7a975c 100644
--- a/graph.c
+++ b/graph.c
@@ -80,6 +80,7 @@ static void graph_show_line_prefix(const struct diff_options 
*diffopt)
 
 static const char **column_colors;
 static unsigned short column_colors_max;
+static int show_root_mark;
 
 static void parse_graph_colors_config(struct argv_array *colors, const char 
*string)
 {
@@ -256,6 +257,16 @@ void graph_setup_line_prefix(struct diff_options *diffopt)
 }
 
 
+static int git_graph_config(const char *var, const char *value, void *cb)
+{
+   if (!strcmp(var, "log.showrootmark")) {
+   show_root_mark = git_config_bool(var, value);
+   return 0;
+   }
+
+   return git_default_config(var, value, cb);
+}
+
 struct git_graph *graph_init(struct rev_info *opt)
 {
struct git_graph *graph = xmalloc(sizeof(struct git_graph));
@@ -276,6 +287,7 @@ struct git_graph *graph_init(struct rev_info *opt)
custom_colors.argc - 1);
}
}
+   git_config(git_graph_config, NULL);
 
graph->commit = NULL;
graph->revs = opt;
@@ -835,6 +847,14 @@ static void graph_output_commit_char(struct git_graph 
*graph, struct strbuf *sb)
return;
}
 
+   /*
+* If the commit has no parents, it's a root commit
+*/
+   if (show_root_mark && !graph->num_parents) {
+   strbuf_addch(sb, '@');
+   return;
+   }
+
/*
 * get_revision_mark() handles all other cases without assert()
 */
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 25b1f8cc73bc3..350e35264362f 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -455,6 +455,22 @@ test_expect_success 'simple log --graph' '
test_cmp expect actual
 '
 
+cat > expect  expect 

[ANNOUNCE] Git developers contacted by an advanced alien species

[Christian Couder]

Members of an Alien species that have a far superior technology have
recently privately contacted some Git developers. They said that they
are amazed by Git technology and mostly wanted to thank us all for our
hard work on Git, as they are surely going to use it due to its free
software nature.

At the same time they expressed that they are a bit appalled by the
state of our free software operating systems like Linux, though they
told us Windows might have been used by them if it was not proprietary
and especially if it was faster at running the awesome Git test suite.

The Git developers are all the more amazed by the fact that Dscho, the
Git for Windows maintainer, had written just a few days before this
contact 
(https://public-inbox.org/git/nycvar.qro.7.76.6.1803301415240.5...@qfpub.tvgsbejvaqbjf.bet/):

"An alien digging up ancient Earth history in the far future might be
tempted to assume that Git was developed to develop Linux which was
developed to develop Git, and then ask herself why humans bothered at all."

Proposal

[Melisa Mehmet]

Hello 


   
   Greetings to you today i asked before but i did't get a response please i 
know this might come to you as a surprise because you do not know me personally 
so i will give you a video call to explain more but did you get my previous 
email ? Let me know asap.





Best Regards,

Miss Melisa Mehmet 

Esentepe Mahallesi Büyükdere 

Caddesi Kristal Kule Binasi
No:215
 Sisli - Istanbul, Turkey 

Re: [PATCH] builtin/commit.c: prevent bad commits

[Junio C Hamano]

Dan Aloni  writes:

> These commits which have hashes starting with the hex string 'bad',
> always give me the chills. Why should a perfectly good commit be
> jinxed?
> ...
> Note that this change does not affect actual software quality maintained
> using Git. Thus, it is recommended keep testing all generated versions
> regardless of commit hash jinxes.
>
> Signed-off-by: Dan Aloni 
> ---

Ah, I forgot that it's that time of the year again.

> + ...
> + oid_hex = oid_to_hex();
> + if (prevent_bad &&
> + oid_hex[0] == 'b' &&
> + oid_hex[1] == 'a' &&
> + oid_hex[2] == 'd' )
> + {
> + parents = copy_parents;
> + strbuf_add(, "\n", 1);
> + continue;

We used to allow a variant of this that lets you append invisible
cruft at the end of the log message by hiding it after a NUL.  You
also could loop here to turn the abbreviated commit object name to
an actively good one, not just "not bad" name ;-).

> + }
> +
> + free_commit_list(copy_parents);
> + break;
>   }
> +
>   strbuf_release(_ident);
>   free_commit_extra_headers(extra);

Greetings,

[miss meryem ramazan]

Hello 

   Greetings to you today i asked before but i did't get a response please i 
know this might come to you as a surprise because you do not know me personally 
so i will give you a video call to explain more but did you get my previous 
email ? Let me know asap.



Best Regards,

miss meryem ramazan. 
Esentepe Mahallesi Büyükdere 
Caddesi Kristal Kule Binasi
No:215
 Sisli - Istanbul, Turkey 

Re: [GSoC] [PATCH] travis-ci: added clang static analysis

[Lars Schneider]

> On 13 Mar 2018, at 18:45, Siddhartha Mishra  wrote:
> 
> On Mon, Mar 12, 2018 at 3:49 PM, Lars Schneider
>  wrote:
>> Hi,
>> 
>> That looks interesting but I agree with Dscho that we should not limit
>> this to master/maint.
>> 
>> I assume you did run this on TravisCI already? Can you share a link?
>> I assume you did find errors? Can we fix them or are there too many?
>> If there are existing errors, how do we define a "successful" build?
>> 
>> Thanks for working on this,
>> Lars
>> 
> 
> Thanks for the reply,
> 
> I assume there will be false positives in the code which we can't fix
> by making small modifications to the code as recommended in the FAQ
> (https://clang-analyzer.llvm.org/faq.html). According to the FAQ,
> there is no solid mechanism for suppressing a specific warning, so are
> options are limited. Some of the things which might help reduce the
> noise are:
> 
> 1) To add specific tags in our source code to tell the analyzer to
> ignore the code. This is probably a bad idea since it is intrusive and
> forces changes to the actual source code which only affect one task.
> 
> 2) Count the number of bugs in the previous pushed build and fail the
> build if the number of bugs increases. It doesn't help remove the
> noise from the error log but it does tell you if you've added more
> bugs. However if you add a bug and remove one, it'll pass the job and
> might mislead you into thinking that the code is correct.
> 
> 3) Write a script to check the diff of the error log from that of the
> previous pushed build(ignoring the line numbers). I haven't thought
> about how exactly it would be implemented so I'm not commenting on it.
> 
> Is there a better solution that I'm missing or should I try coming up
> with a script to come up the diff?

That's a good summary and I don't see a better solution. While (3)
sounds nice, I think (2) is the fastest/most pragmatic solution.

We already use the Travis cache [1]. You could use that mechanism to 
store a file with the latest number of bugs in the cache directory 
$HOME/travis-cache

If the "number of bugs" file does not exist, then create it and don't
complain. If the file exists and the previous number of bugs is higher
or equal, then don't complain either. If the file exists and the previous
number of bugs is lower, then let the build fail.

Do you think that could work?

Cheers,
Lars 

[1] https://docs.travis-ci.com/user/caching/


> 
> Thanks for the time,
> Siddhartha
> 
> On Mon, Mar 12, 2018 at 3:49 PM, Lars Schneider
>  wrote:
>> Hi,
>> 
>> That looks interesting but I agree with Dscho that we should not limit
>> this to master/maint.
>> 
>> I assume you did run this on TravisCI already? Can you share a link?
>> I assume you did find errors? Can we fix them or are there too many?
>> If there are existing errors, how do we define a "successful" build?
>> 
>> Thanks for working on this,
>> Lars
>> 
>>> On 05 Mar 2018, at 21:04, SiddharthaMishra  wrote:
>>> 
>>> Added a job to run clang static code analysis on the master and maint branch
>>> 
>>> Signed-off-by: SiddharthaMishra 
>>> ---
>>> .travis.yml   | 17 -
>>> ci/run-static-analysis.sh |  9 -
>>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/.travis.yml b/.travis.yml
>>> index 4684b3f4f..9b891d182 100644
>>> --- a/.travis.yml
>>> +++ b/.travis.yml
>>> @@ -48,7 +48,7 @@ matrix:
>>>  before_install:
>>>  before_script:
>>>  script: ci/run-linux32-docker.sh
>>> -- env: jobname=StaticAnalysis
>>> +- env: jobname=CocciStaticAnalysis
>>>  os: linux
>>>  compiler:
>>>  addons:
>>> @@ -59,6 +59,21 @@ matrix:
>>>  before_script:
>>>  script: ci/run-static-analysis.sh
>>>  after_failure:
>>> +- if: branch IN (master, maint)
>>> +  env: jobname=ClangStaticAnalysis
>>> +  os: linux
>>> +  compiler:
>>> +  add_ons:
>>> +apt:
>>> +  sources:
>>> +  - ubuntu-toolchain-r-test
>>> +  - llvm-toolchain-trusty
>>> +  packages:
>>> +  - clang
>>> +  before_install:
>>> +  before_script:
>>> +  script: ci/run-static-analysis.sh
>>> +  after_failure:
>>>- env: jobname=Documentation
>>>  os: linux
>>>  compiler:
>>> diff --git a/ci/run-static-analysis.sh b/ci/run-static-analysis.sh
>>> index fe4ee4e06..6ae032f54 100755
>>> --- a/ci/run-static-analysis.sh
>>> +++ b/ci/run-static-analysis.sh
>>> @@ -5,6 +5,13 @@
>>> 
>>> . ${0%/*}/lib-travisci.sh
>>> 
>>> -make coccicheck
>>> +case "$jobname" in
>>> +ClangStaticAnalysis)
>>> + scan-build -analyze-headers --status-bugs make
>>> + ;;
>>> +CocciStaticAnalysis)
>>> + make coccicheck
>>> + ;;
>>> +esac
>>> 
>>> save_good_tree
>>> --
>>> 2.16.2.248.ge2408a6f7.dirty
>>> 
>> 

Re: [PATCH v12 04/10] utf8: teach same_encoding() alternative UTF encoding names

[Lars Schneider]

> On 16 Mar 2018, at 19:19, Eric Sunshine  wrote:
> 
> On Fri, Mar 16, 2018 at 1:50 PM, Junio C Hamano  wrote:
>> Eric Sunshine  writes:
>>> However, I'm having a tough time imagining cases in which callers
>>> would want same_encoding() to return true if both arguments are NULL,
>>> but outright crash if only one is NULL (which is the behavior even
>>> before this patch). In other words, same_encoding() takes advantage of
>>> is_encoding_utf8() for its convenience, not for its NULL-handling.
>>> Given that view, the two explicit is_encoding_utf8() calls in
>>> same_encoding() seem redundant once the same_utf_encoding() call is
>>> added.
>> 
>> So... does that mean we'd want something like this, or do you have
>> something else in mind?
>> 
>>int same_encoding(const char *src, const char *dst)
>>{
>>static const char utf8[] = "UTF-8";
>> 
>>if (!src)
>>src = utf8;
>>if (!dst)
>>dst = utf8;
>>if (same_utf_encoding(src, dst))
>>return 1;
>>return !strcasecmp(src, dst);
>>}
> 
> I am not proposing anything like that for this patch or patch series.
> I'm merely asking why, after this patch, same_encoding() still
> contains the (in my mind) now-unneeded conditional:
> 
>if (is_encoding_utf8(src) && is_encoding_utf8(dst))
>return 1;

My main motivation was to keep the existing behavior "as-is"
to avoid any regressions.

However, I agree with your critic of the inconsistencies. 

Therefore, I will use Junio's suggestion above as it makes 
the intented behaivior clear.

Thanks,
Lars

[PATCH] builtin/commit.c: prevent bad commits

[Dan Aloni]

These commits which have hashes starting with the hex string 'bad',
always give me the chills. Why should a perfectly good commit be
jinxed?

Statistically, one of 4096 commits may be 'bad'. This change adds a
'--prevent-bad' switch to the commit command in order to prevent such
commit hashes from being generated. Internally, the commit is retried
with a slight commit meta-data modification - a newline is added to the
end of the commit message. The meta-data change results in a different
hash, that if we are lucky enough (4095/4096 chance) may not be 'bad'.

Note that this change does not affect actual software quality maintained
using Git. Thus, it is recommended keep testing all generated versions
regardless of commit hash jinxes.

Signed-off-by: Dan Aloni 
---
 builtin/commit.c | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index 37fcb55ab0a0..afaa7cefaedf 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -89,6 +89,7 @@ static int edit_flag = -1; /* unspecified */
 static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship;
 static int config_commit_verbose = -1; /* unspecified */
 static int no_post_rewrite, allow_empty_message;
+static int prevent_bad;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg, 
*ignored_arg;
 static char *sign_commit;
 
@@ -1449,6 +1450,7 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
OPT_BOOL('z', "null", _termination,
 N_("terminate entries with NUL")),
OPT_BOOL(0, "amend", , N_("amend previous commit")),
+   OPT_BOOL(0, "prevent-bad", _bad, N_("prevent a bad 
commit")),
OPT_BOOL(0, "no-post-rewrite", _post_rewrite, N_("bypass 
post-rewrite hook")),
{ OPTION_STRING, 'u', "untracked-files", _files_arg, 
N_("mode"), N_("show untracked files, optional modes: all, normal, no. 
(Default: all)"), PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
/* end commit contents options */
@@ -1583,12 +1585,34 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
append_merge_tag_headers(parents, );
}
 
-   if (commit_tree_extended(sb.buf, sb.len, _cache_tree->oid,
-parents, , author_ident.buf, sign_commit,
-extra)) {
-   rollback_index_files();
-   die(_("failed to write commit object"));
+   for (;;) {
+   char *oid_hex;
+   struct commit_list *copy_parents;
+
+   copy_parents = copy_commit_list(parents);
+
+   if (commit_tree_extended(sb.buf, sb.len, 
_cache_tree->oid,
+parents, , author_ident.buf, 
sign_commit,
+extra)) {
+   rollback_index_files();
+   die(_("failed to write commit object"));
+   }
+
+   oid_hex = oid_to_hex();
+   if (prevent_bad &&
+   oid_hex[0] == 'b' &&
+   oid_hex[1] == 'a' &&
+   oid_hex[2] == 'd' )
+   {
+   parents = copy_parents;
+   strbuf_add(, "\n", 1);
+   continue;
+   }
+
+   free_commit_list(copy_parents);
+   break;
}
+
strbuf_release(_ident);
free_commit_extra_headers(extra);
 
-- 
2.14.3

Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute

[Lars Schneider]

> On 18 Mar 2018, at 08:24, Torsten Bögershausen  wrote:
> 
> Some comments inline
> 
> On Fri, Mar 09, 2018 at 06:35:32PM +0100, lars.schnei...@autodesk.com wrote:
>> From: Lars Schneider 
>> 
>> Git recognizes files encoded with ASCII or one of its supersets (e.g.
>> UTF-8 or ISO-8859-1) as text files. All other encodings are usually
>> interpreted as binary and consequently built-in Git text processing
>> tools (e.g. 'git diff') as well as most Git web front ends do not
>> visualize the content.
>> 
>> Add an attribute to tell Git what encoding the user has defined for a
>> given file. If the content is added to the index, then Git converts the
> 
> Minor comment:
> "Git converts the content"
> Everywhere else (?) "encodes or reencodes" is used.
> "Git reencodes the content" may be more consistent.

OK, will change.


>> 
>> +static const char *default_encoding = "UTF-8";
>> +
>> +static int encode_to_git(const char *path, const char *src, size_t src_len,
>> + struct strbuf *buf, const char *enc, int conv_flags)
>> +{
>> +char *dst;
>> +int dst_len;
>> +int die_on_error = conv_flags & CONV_WRITE_OBJECT;
>> +
>> +/*
>> + * No encoding is specified or there is nothing to encode.
>> + * Tell the caller that the content was not modified.
>> + */
>> +if (!enc || (src && !src_len))
>> +return 0;
> 
> (This may have been discussed before.
> As we checked (enc != NULL) I think we can add here:)
>   if (is_encoding_utf8(enc))
>   return 0;

This should be covered in git_path_check_encoding(),
introduced in v12:

/* Don't encode to the default encoding */
if (same_encoding(value, default_encoding))
return NULL;

In that function the encoding of a certain file is read from
the .gitattributes. If the encoding matches the compile-time
defined default encoding (= UTF-8), then the encoding is set
to NULL.


>> 
>> +
>> +static int encode_to_worktree(const char *path, const char *src, size_t 
>> src_len,
>> +  struct strbuf *buf, const char *enc)
>> +{
>> +char *dst;
>> +int dst_len;
>> +
>> +/*
>> + * No encoding is specified or there is nothing to encode.
>> + * Tell the caller that the content was not modified.
>> + */
>> +if (!enc || (src && !src_len))
>> +return 0;
> 
> Same as above:
>   if (is_encoding_utf8(enc))
>   return 0;
> 
>> +
>> +dst = reencode_string_len(src, src_len, enc, default_encoding,
>> +  _len);
>> +if (!dst) {
>> +error("failed to encode '%s' from %s to %s",
>> +path, default_encoding, enc);
>> +return 0;
>> +}
>> +
>> +strbuf_attach(buf, dst, dst_len, dst_len + 1);
>> +return 1;
>> +}
>> +
>> static int crlf_to_git(const struct index_state *istate,
>> const char *path, const char *src, size_t len,
>> struct strbuf *buf,
>> @@ -978,6 +1051,25 @@ static int ident_to_worktree(const char *path, const 
>> char *src, size_t len,
>>  return 1;
>> }
>> 
>> +static const char *git_path_check_encoding(struct attr_check_item *check)
>> +{
>> +const char *value = check->value;
>> +
>> +if (ATTR_UNSET(value) || !strlen(value))
>> +return NULL;
>> +
> 
> 
>> +if (ATTR_TRUE(value) || ATTR_FALSE(value)) {
>> +error(_("working-tree-encoding attribute requires a value"));
>> +return NULL;
>> +}
> 
> TRUE or false are values, but just wrong ones.
> If this test is removed, the user will see "failed to encode "TRUE" to 
> "UTF-8",
> which should give enough information to fix it.

I see your point. However, I would like to stop the processing right
there for these invalid values. How about 

  error(_("true/false are no valid working-tree-encodings"));

I think that is the most straight forward/helpful error message
for the enduser (I consider the term "boolean" but dismissed it
as potentially confusing to folks not familiar with the term).

OK with you?

> 
>> +
>> +/* Don't encode to the default encoding */
>> +if (!strcasecmp(value, default_encoding))
>> +return NULL;
> Same as above ?:
>   if (is_encoding_utf8(value))
>   return 0;

Yes, that was fixed in v12 as mentioned above :-)

- Lars

Re: What's cooking in git.git (Mar 2018, #05; Wed, 28)

[Lars Schneider]

> On 30 Mar 2018, at 12:32, Lars Schneider  wrote:
> 
> 
>> On 30 Mar 2018, at 11:24, Ævar Arnfjörð Bjarmason  wrote:
>> 
>> 
>> On Wed, Mar 28 2018, Junio C. Hamano wrote:
>> 
>>> * ls/checkout-encoding (2018-03-16) 10 commits
>>> - convert: add round trip check based on 'core.checkRoundtripEncoding'
>>> - convert: add tracing for 'working-tree-encoding' attribute
>>> - convert: check for detectable errors in UTF encodings
>>> - convert: add 'working-tree-encoding' attribute
>>> - utf8: add function to detect a missing UTF-16/32 BOM
>>> - utf8: add function to detect prohibited UTF-16/32 BOM
>>> - utf8: teach same_encoding() alternative UTF encoding names
>>> - strbuf: add a case insensitive starts_with()
>>> - strbuf: add xstrdup_toupper()
>>> - strbuf: remove unnecessary NUL assignment in xstrdup_tolower()
>>> 
>>> The new "checkout-encoding" attribute can ask Git to convert the
>>> contents to the specified encoding when checking out to the working
>>> tree (and the other way around when checking in).
>> 
>> There's an issue in ca16fc3635 ("convert: check for detectable errors in
>> UTF encodings", 2018-03-15) flagged by Coverity:
>> https://public-inbox.org/git/CAGZ79kbAOcwaRzjuMtZ_HVsYvUr_7UAPbOcnrmPgsdE19q=p...@mail.gmail.com/
> 
> Thanks a lot for pointing me at this!
> I'll prepare a new round soonish.


The report says:

  >>> CID 1433528:  Null pointer dereferences  (FORWARD_NULL)
  >>> Passing null pointer "src" to "validate_encoding", which dereferences 
it.

  411 if (validate_encoding(path, enc, src, src_len, die_on_error))

However, validate_encoding() does not dereference it. It just passes the
pointer to has_prohibited_utf_bom() and is_missing_required_utf_bom().
These functions just pass the pointer to has_bom_prefix().

In has_bom_prefix() we pass the pointer to memcmp() which is undefined
for null pointers. I think that is what Coverity is complaining about,
right?


- Lars

[PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches

[Thomas Gummerer]

Signed-off-by: Thomas Gummerer 
---

So while playing with it a bit more I found one case where the new UI
is not ideal and a bit confusing.  Namely when the new check out dwim
kicks in, but there is already a file/directory at the path we're
giving to 'git worktree add'.

In that case something like the following would be printed:

$ g worktree add ../next
Checking out branch 'next'
fatal: '../next' already exists

Instead I think we'd just want the error without the "Checking out
branch" message, which is what this fixup here does.

One thing that gets a bit strange is that the "Checking out branch"
message and the "Creating branch" messages are printed from different
places.  But without doing quite some refactoring I don't think
there's a good way to do that, and I think having the UI do the right
thing is more important.

One thing I also noticed is that if a branch is created by 'git
worktree add', but we fail, we never clean up that branch again, which
I'm not sure is ideal.  As a pre-existing problem I'd like to keep
fixing that out of the scope of this series though (at least after
this series the user would get some output showing that this happened,
even when the branch is not set up to track a remote), so I'd like to
keep fixing that out of the scope of this series.

Junio: could you please squash this in in 6/6 while queuing?  I'd
prefer not to re-send the whole series just for fixing this up, but
obviously can if that makes your life easier :)

Thanks!

 builtin/worktree.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/builtin/worktree.c b/builtin/worktree.c
index 511d0aa370..ccc2e63e0f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -27,6 +27,7 @@ struct add_opts {
int detach;
int checkout;
int keep_locked;
+   int checkout_existing_branch;
 };
 
 static int show_only;
@@ -316,6 +317,8 @@ static int add_worktree(const char *path, const char 
*refname,
if (ret)
goto done;
 
+   if (opts->checkout_existing_branch)
+ fprintf_ln(stderr, _("Checking out branch '%s'"), refname);
if (opts->checkout) {
cp.argv = NULL;
argv_array_clear();
@@ -397,7 +400,6 @@ static int add(int ac, const char **av, const char *prefix)
const char *branch;
const char *new_branch = NULL;
const char *opt_track = NULL;
-   int checkout_existing_branch = 0;
struct option options[] = {
OPT__FORCE(, N_("checkout  even if already 
checked out in other worktree")),
OPT_STRING('b', NULL, _branch, N_("branch"),
@@ -443,7 +445,7 @@ static int add(int ac, const char **av, const char *prefix)
 
if (ac < 2 && !new_branch && !opts.detach) {
const char *s = dwim_branch(path, _branch,
-   _existing_branch);
+   _existing_branch);
if (s)
branch = s;
}
@@ -478,8 +480,6 @@ static int add(int ac, const char **av, const char *prefix)
if (run_command())
return -1;
branch = new_branch;
-   } else if (checkout_existing_branch) {
- fprintf_ln(stderr, _("Checking out branch '%s'"), branch);
} else if (opt_track) {
die(_("--[no-]track can only be used if a new branch is 
created"));
}
-- 
2.16.1.78.g71f731ae26.dirty

URGENT

[bedie thiery]

Re:
PRIVATE
Dear Madam/Sir,
I trust this email finds you in good health.
I write in respect of an amount held in the account of an expatriate
investor, an associate physician, working on Cancer Vaccines
Immunotherapy Research.
The closing balance is the sum of US$13, 400, 000 (Thirteen Million
and Four Hundred Thousand).
He was aged 68 when he left the country for the US in 2001.

It has been well over 16 years and nobody has since then come for the
claim over the time.

The bank does not have record of contact information of his family
relatives in the file for the claim and the funds will be credited to
the government treasury as “unclaimed”, unless someone shows up with
corresponding data to authorize the payment.

Please I need your cooperation on this urgent confidential matter.
I am willing to provide all relevant data details.
This will be disbursed or shared in percentage of 45% to me, 15% to
the accountant and 40% to you.
Dr. K.Dankwa Anissan.M.D.,
D.G.O., F.I.C.S., Sonologist in obstetrics Gynecology
St. Nicholas Hospital, Lagos.
 dr.anissa...@gmail.com

[GIT PULL] l10n updates for 2.17.0 round 1

[Jiang Xin]

Hi Junio,

Would you please pull the following git l10n updates.

The following changes since commit 0afbf6caa5b16dcfa3074982e5b48e27d452dbbb:

  Git 2.17-rc0 (2018-03-15 15:01:05 -0700)

are available in the Git repository at:

  git://github.com/git-l10n/git-po tags/l10n-2.17.0-rnd1

for you to fetch changes up to 8bb6d60dd6b6f2f72fe091cb03d571dbdc01aa3e:

  l10n: de.po: translate 132 new messages (2018-03-31 13:21:09 +0200)


l10n for Git 2.17.0 round 1


Alexander Shopov (1):
  l10n: bg.po: Updated Bulgarian translation (3376t)

Changwoo Ryu (1):
  l10n: ko.po: Update Korean translation

Christopher Diaz Riveros (2):
  l10n: es.po: fixes to Spanish translation
  l10n: es.po: Update Spanish translation 2.17.0

Jean-Noël Avila (2):
  l10n: fr.po v2.17.0 round 1
  l10n: fr.po: v2.17.0 no fuzzy

Jiang Xin (10):
  Merge branch 'merge' of https://github.com/ChrisADR/git-po into maint
  l10n: git.pot: v2.17.0 round 1 (132 new, 44 removed)
  Merge remote-tracking branch 'git-po/maint'
  Merge branch 'master' of git://github.com/alshopov/git-po
  Merge branch 'master' of https://github.com/vnwildman/git
  Merge branch 'fr_v2.17.0' of git://github.com/jnavila/git
  Merge branch 'master' of https://github.com/Softcatala/git-po
  Merge branch 'master' of git://github.com/nafmo/git-l10n-sv
  Merge branch 'fr_v2.17.0' of git://github.com/jnavila/git
  l10n: zh_CN: for git v2.17.0 l10n round 1

Jordi Mas (1):
  l10n: Update Catalan translation

Peter Krefting (1):
  l10n: sv.po: Update Swedish translation (3376t0f0u)

Ralf Thielow (1):
  l10n: de.po: translate 132 new messages

Ray Chen (1):
  l10n: zh_CN: review for git v2.17.0 l10n round 1

Trần Ngọc Quân (1):
  l10n: vi.po(3376t): Updated Vietnamese translation for v2.17

 po/bg.po| 4598 
 po/ca.po| 7551 ++-
 po/de.po| 4670 +++-
 po/es.po| 5213 ++---
 po/fr.po| 4586 +++-
 po/git.pot  | 4396 ++
 po/ko.po| 4583 
 po/sv.po| 4571 
 po/vi.po| 4591 
 po/zh_CN.po | 4561 
 10 files changed, 26709 insertions(+), 22611 deletions(-)