2015-01-12 22:29 GMT-07:00 Scott Schmit :
>
> On Wed, Jan 07, 2015 at 11:28:21PM -0700, Alex Henrie wrote:
> >
> > diff --git a/builtin/diff-files.c b/builtin/diff-files.c
> > index 9200069..1abeba6 100644
> > --- a/builtin/diff-files.c
> > +++ b/builtin/diff-files.c
> > @@ -11,7 +11,7 @@
> > #inc
This patch puts the usage info strings that were not already in docopt-
like format into docopt-like format, which will be a litle easier for
end users and a lot easier for translators. Changes include:
- Placing angle brackets around fill-in-the-blank parameters
- Putting dashes in multiword para
Hi,
Since Git v2.3.0-rc0 had already been released, it's time to start new round
of git l10n. This time there are 13 new messages need to be translated since
last update for v2.2.0:
l10n: git.pot: v2.3.0 round 1 (13 new, 11 removed)
Generate po/git.pot from v2.3.0-rc0 for git v2.3.0 l10n
On Wed, Jan 07, 2015 at 11:28:21PM -0700, Alex Henrie wrote:
> This patch puts the usage info strings that were not already in docopt-
> like format into docopt-like format, which will be a litle easier for
> end users and a lot easier for translators. Changes include:
>
> - Placing angle brackets
When we fetch a symbolic ref file from the remote, we get
the whole string "ref: refs/heads/master\n", recognize it by
skipping past the "ref: ", and store the rest. We should
chomp the trailing newline.
This bug was introduced in ae021d8 (use skip_prefix to avoid
magic numbers, 2014-06-18), which
On Mon, Jan 12, 2015 at 06:21:19PM -0800, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -675,6 +675,11 @@ extern char *xgetcwd(void);
> >
> > #define REALLOC_ARRAY(x, alloc) (x) = xrealloc((x), (alloc) * sizeof(*(x)))
> >
> > +stat
Jeff King wrote:
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -675,6 +675,11 @@ extern char *xgetcwd(void);
>
> #define REALLOC_ARRAY(x, alloc) (x) = xrealloc((x), (alloc) * sizeof(*(x)))
>
> +static inline char *xstrdup_or_null(const char *str)
> +{
> + return str ? xstrdup(s
From: Lukas Fleischer
The helper functions prepare_final() and prepare_initial() return a
pointer to a string that is a member of an object in the revs->pending
array. This array is later rebuilt when running prepare_revision_walk()
which potentially transforms the pointer target into a bogus str
This replaces "x ? xstrdup(x) : NULL" with xstrdup_or_null(x).
The change is fairly mechanical, with the exception of
resolve_refdup, which can eliminate a temporary variable.
There are still a few hits grepping for "?.*xstrdup", but
these are of slightly different forms and cannot be
converted (e
This file had its own identical helper that predates
xstrdup_or_null. Let's use the global one to avoid
repetition.
Signed-off-by: Jeff King
---
You'll note that every one of these could just be a ?:-conditional
(there are no function calls).
builtin/apply.c | 15 +--
1 file changed
The only reason for envdup to be its own function is that we
have to save the result in a temporary string. With
xstrdup_or_null, we can feed the result of getenv()
directly.
Signed-off-by: Jeff King
---
These ones need the temporary. Is the result more readable, or less?
builtin/commit.c | 12
It's a common idiom to duplicate a string if it is non-NULL,
or pass a literal NULL through. This is already a one-liner
in C, but you do have to repeat the name of the string
twice. So if there's a function call, you must write:
const char *x = some_fun(...);
return x ? xstrdup(x) : NULL;
in
On Mon, Jan 12, 2015 at 04:11:06PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > As an aside, I have often been tempted to have xstrdup silently
> > propagate a NULL. It would have been the right thing to do here, but
> > maybe there are cases where the segfault is preferable for catchi
On Thu, Jan 08, 2015 at 06:17:37PM +0900, Mike Hommey wrote:
> `git show-branch --upstream` is equivalent to `git show-branch
> $(git for-each-ref refs/heads --format '%(refname:short)')
> $(git for-each-ref refs/heads --format '%(upstream:short)')`
>
> `git show-branch --upstream foo bar` is equi
"git log --grep=" shows only commits with messages that
match the given string, but sometimes it is useful to be able to
show only commits that do *not* have certain messages (e.g. "show
me ones that are not FIXUP commits").
Originally, we had the invert-grep flag in grep_opt, but because
"git gre
Jens Lehmann writes:
>Am 07.01.2015 um 01:02 schrieb Junio C Hamano:
>> ^"Kyle J. McKay" writes:
>>> I can't find anything in that thread about why vsatisfies was
>>> preferred over vcompare other than the obvious that the vsatisfies
>>> version is only a 1-character change. And that would be m
Csaba Kiraly writes:
>gui.maxfilesdisplayed (added in dd6451f9c7c5a36d3006231b618ac6da06c7c7b4)
>was applied brute force on the file list in alphabetic order. As a result,
>files that had modifications might not be displayed by git-gui. Even
>worse, files that are already in the index might not b
This was missing in 1b70fe5d3054 (2015-01-07, receive-pack.c: negotiate
atomic push support) as I squashed the option in very late in the patch
series.
Signed-off-by: Stefan Beller
---
Notes:
v1:
This goes on top of origin/sb/atomic-push
Documentation/config.txt | 5 +
1 file chang
Jeff King writes:
> As an aside, I have often been tempted to have xstrdup silently
> propagate a NULL. It would have been the right thing to do here, but
> maybe there are cases where the segfault is preferable for catching a
> mistake early (otherwise you might store the NULL and then segfault
Eric Sunshine writes:
> If it's only intended to assist automated testing, then perhaps
> control it via an environment variable rather than a configuration
> option. (See, for instance, GIT_TEST_SPLIT_INDEX or GIT_USE_LOOKUP as
> precedent.)
Note that passing environment to receive-pack is very
An early preview release Git v2.3.0-rc0 is now available for
testing at the usual places.
With the slowness from the end-of-year holiday, this cycle turned
out to be a relatively lean one as I predicted (just 200 changes
since 2.2, as opposed to ~500 changes in an normal cycle), but that
is fine.
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The "preview" release candidate 2.3-rc0 has been tagged. With the
slowness from the end-of-year holiday, this cycle turns out to be a
relativel
The latest maintenance release Git v2.2.2 is now available at
the usual places.
This backports many fixes that were not in 2.2.1 that have been used
on 'master' for the past few weeks.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories
On Mon, Jan 12, 2015 at 3:29 PM, Eric Sunshine wrote:
> Is this needed only to support the tests you add in t5543, or do you
> intend it to be useful to end users?
>
> If it is for end users, then it deserves to be documented. Is also
> deserves proper mention and justification in the commit mess
On Wed, Jan 7, 2015 at 10:23 PM, Stefan Beller wrote:
> This adds tests for the atomic push option.
> The first four tests check if the atomic option works in
> good conditions and the last three patches check if the atomic
s/patches/tests/
> option prevents any change to be pushed if just one r
On Wed, Jan 7, 2015 at 10:23 PM, Stefan Beller wrote:
> From: Ronnie Sahlberg
>
> This adds the atomic protocol option to allow
> receive-pack to inform the client that it has
> atomic push capability.
>
> Signed-off-by: Stefan Beller
> ---
>
> Notes:
> v9:
> We can configure the remote
On Mon, 12 Jan 2015 at 23:55:30, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Lukas Fleischer writes:
> >
> >> The helper functions prepare_final() and prepare_initial() return a
> >> pointer to a string that is a member of an object in the revs->pending
> >> array. This array is later r
On Mon, Jan 12, 2015 at 02:55:30PM -0800, Junio C Hamano wrote:
> With the patch applied on top of 1da1e07c (or the result merged to
> 'next' for that matter), I see test breakages in many places "git
> blame" is used, e.g. t7010. Did you run the test suite?
>
> This is because it is perfectly n
Junio C Hamano writes:
> Lukas Fleischer writes:
>
>> The helper functions prepare_final() and prepare_initial() return a
>> pointer to a string that is a member of an object in the revs->pending
>> array. This array is later rebuilt when running prepare_revision_walk()
>> which potentially tran
Richard Hansen writes:
> Make sure hooks are executed at the top-level directory and that
> GIT_PREFIX is set (as documented).
The same comment as the one for 1/2 applies here. If we substitute
'hook' everywhere with 'post-checkout hook' in this patch, it makes
perfect sense to me, but otherwis
Stefan Beller writes:
> +static int atomic_push_failure(struct send_pack_args *args,
> +struct ref *remote_refs,
> +struct ref *failing_ref)
> +{
> + struct ref *ref;
> + /* Mark other refs as failed */
> + for (ref = remote_refs
Alexander Kuleshov writes:
> 'enum object_type type' and 'unsigned long size' are already defined
> at the top of cat_one_file routine
True. That description applies to two completely different
situations, though, and does not help judging if the change is
correct.
Scenario #1:
unsign
On Mon, Jan 12, 2015 at 04:08:28PM -0500, Jeff King wrote:
> > I do not think profile build is prepared to be run without having
> > our history (after all, it is not test_perf_create_REPO_from, not
> > test_perf_create_source_directory_of_git_from). It wants to create
> > a repository that hosts
On Tue, Jan 06, 2015 at 03:13:30PM -0800, Junio C Hamano wrote:
> > The problem is in the t/perf/perf-lib.sh:test_perf_create_repo_from()
> > function, where we see this:
> >
> > repo="$1"
> > source="$2"
> > source_git=$source/$(cd "$source" && git rev-parse --git-dir)
> >
> > The function
--
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
Junio C Hamano writes:
> Christoph Junghans writes:
>
>> The only useful thing I could image is using it in conjunction with
>> --files-with-matches, but that is what --files-without-match is for.
>
> Yes, "-l" was exactly what I had in mind and I was hoping that "git
> grep -l --no-match -e WIP
On Mon, Jan 12, 2015 at 11:08:26AM -0800, Junio C Hamano wrote:
> Lukas Fleischer writes:
>
> > The helper functions prepare_final() and prepare_initial() return a
> > pointer to a string that is a member of an object in the revs->pending
> > array. This array is later rebuilt when running prepa
Richard Hansen writes:
> Document that hooks are run from the top-level directory and that
> GIT_PREFIX is set to the name of the original subdirectory (relative
> to the top-level directory).
>
> Signed-off-by: Richard Hansen
> ---
> Documentation/githooks.txt | 6 ++
> 1 file changed, 6 i
Lukas Fleischer writes:
> The helper functions prepare_final() and prepare_initial() return a
> pointer to a string that is a member of an object in the revs->pending
> array. This array is later rebuilt when running prepare_revision_walk()
> which potentially transforms the pointer target into a
"Kyle J. McKay" writes:
> The "yes", "no", "auto" settings for the new Makefile configuration
> variable "USE_PARENS_AROUND_GETTEXT_N" are based on the way the
> Makefile variable "COMPUTE_HEADER_DEPENDENCIES" works. So I used
> "yes" and "no" for consistency instead of "Yes" and "No".
Thanks f
Stefan Beller writes:
> I had problems with wording the commit message because I have no
> expertise with the feature. I am sorry for wasting your time there.
Heh, remember, the time spent discussing Git on this list is not a
wasted time.
>> What is not given to the hook is the push-cert-nonce-
Robert Dailey writes:
> So I want a way to clear out the whole rerere cache (i.e. every
> remembered conflict resolution). So I try this command:
>
> $ git rerere forget .
The forget subcommand is to tell Git that you screwed up in this
sequence:
$ git merge other ;# or any "mergy" operatio
So I want a way to clear out the whole rerere cache (i.e. every
remembered conflict resolution). So I try this command:
$ git rerere forget .
It completes silently, I look at .git/rr-cache and there are still a
bunch of SHA1 directories in there. So I guess it didn't work. The
only way I can do t
43 matches
Mail list logo
