On 26 Jul 2016, at 00:50, Junio C Hamano wrote:
> [...]
>
>
> * ew/git-svn-http-tests (2016-07-25) 2 commits
> - git svn: migrate tests to use lib-httpd
> - t/t91*: do not say how to avoid the tests
>
> Reuse the lib-httpd test infrastructure when testing the subversion
> integration that int
Eric Wong writes:
> I dug around the freebsd history (git://github.com/freebsd/freebsd.git)
> (~1.5G) and the 3.x and 4.x releases with perl in base still contained
> many references to /usr/local/bin/perl
>
> It also seems FreeBSD 2.x releases were also perl-less in base;
> so yes, I'm alright w
Eric Sunshine writes:
>> @@ -73,10 +73,10 @@ join_commits()
>> test_create_commit() (
>> repo=$1
>> commit=$2
>
> Perhaps &&-chain the above two lines also to future-proof against
> someone inserting important code somewhere above the following 'cd'.
Yup, also we can have them o
Junio C Hamano wrote:
> Eric Wong writes:
> > Junio C Hamano wrote:
> >> Duy Nguyen writes:
> >> > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano
> >> > wrote:
> >> >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy
> >> >> wrote:
> > about the problem sooner.
> >
> >> >>> Signed-off
These caught my eye browsing through my inbox. I'm not a subtree user.
Am 26.07.2016 um 06:14 schrieb David Aguilar:
@@ -50,87 +51,145 @@ prefix=
debug()
{
- if [ -n "$debug" ]; then
- printf "%s\n" "$*" >&2
+ if test -n "$debug"
+ then
+ printf "
On Tue, Jul 26, 2016 at 12:14 AM, David Aguilar wrote:
> Allow whitespace in arguments to subtree_test_create_repo.
> Add missing && chains.
>
> Signed-off-by: David Aguilar
> ---
> diff --git a/contrib/subtree/t/t7900-subtree.sh
> b/contrib/subtree/t/t7900-subtree.sh
> @@ -16,16 +16,16 @@ expor
"git merge" in v2.9 prevents merging unrelated histories.
"git subtree split --rejoin" creates unrelated histories when
creating a split repo from a raw sub-directory that did not
originate from an invocation of "git subtree add".
Restore the original behavior by passing --allow-unrelated-histori
Allow whitespace in arguments to subtree_test_create_repo.
Add missing && chains.
Signed-off-by: David Aguilar
---
contrib/subtree/t/t7900-subtree.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-sub
Prefer "test" over "[ ... ]", use double-quotes around variables, break
long lines, and properly indent "case" statements.
Signed-off-by: David Aguilar
---
contrib/subtree/git-subtree.sh | 544 ++---
1 file changed, 341 insertions(+), 203 deletions(-)
diff --
On 07/25/2016 06:53 PM, Junio C Hamano wrote:
Pranit Bauva writes:
>>> +enum terms_defined {
>>> + TERM_BAD = 1,
>>> + TERM_GOOD = 2,
>>> + TERM_NEW = 4,
>>> + TERM_OLD = 8
>>> +};
>>> +
>>
>> What does TERM stand for ?
The terms (words) used to denote the newer an
It seems that git gui does not adhere to the config settings
git config commit.gpgsign true
git config --global user.signingkey
Commits done through git gui are not signed while done through cli they
are signed
Peter van der Does
--
To unsubscribe from this list: send the line "unsubscribe git"
On Wed, Jul 20, 2016 at 10:24 AM, Nguyễn Thái Ngọc Duy
wrote:
> A new repo extension is added, worktreeConfig. When it is present:
>
> - Repository config reading by default includes $GIT_DIR/config _and_
>$GIT_DIR/config.worktree. "config" file remains shared in multiple
>worktree setup.
On Mon, Jul 25, 2016 at 5:43 PM, Junio C Hamano wrote:
> On Mon, Jul 25, 2016 at 5:38 PM, Stefan Beller wrote:
>> On Tue, Jul 19, 2016 at 4:45 PM, Stefan Beller wrote:
>>> Signed-off-by: Stefan Beller
>>> ---
>>
>> Any comment here?
>
> I personally found it Meh in the sense that those who read
On Tue, Jul 19, 2016 at 4:45 PM, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
Any comment here?
>
> Is it too obvious?
> I was approached off list and this was only obvious after some discussion,
> so I think it is a valid warning.
>
> On the other hand this might show that we
On Mon, Jul 25, 2016 at 5:38 PM, Stefan Beller wrote:
> On Tue, Jul 19, 2016 at 4:45 PM, Stefan Beller wrote:
>> Signed-off-by: Stefan Beller
>> ---
>
> Any comment here?
I personally found it Meh in the sense that those who read
and followed the previous note would find it adding no new
inform
Signed-off-by: Stefan Beller
---
This is logically part of origin/sb/submodule-deinit-all, but this change
failed to be there on time.
As I am touching code in the near vincinity, I noticed.
I do not include this in that series to come as I want to keep that
series focused, so I send
On Fri, Jul 22, 2016 at 10:42 AM, Duy Nguyen wrote:
> On Fri, Jul 22, 2016 at 7:25 PM, Stefan Beller wrote:
>> On Fri, Jul 22, 2016 at 10:09 AM, Duy Nguyen wrote:
>>>
>>> I just quickly glanced through the rest of this mail because, as a
>>> submodule ignorant, it's just mumbo jumbo to me. But w
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 ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
W dniu 2016-07-25 o 21:25, Jeff Hostetler pisze:
> +Porcelain Format Version 2
> +~~
> +
> +Version 2 format adds more detailed information about the state of
> +the worktree and the changed items.
I think it should be "and changed items", but I am not a native speaker.
>
Jeff King writes:
> On Mon, Jul 25, 2016 at 02:44:25PM -0700, Junio C Hamano wrote:
>
>> > diff --git a/imap-send.c b/imap-send.c
>> > index db0fafe..67d67f8 100644
>> > --- a/imap-send.c
>> > +++ b/imap-send.c
>> > @@ -506,12 +506,12 @@ static char *next_arg(char **s)
>> >
>> > static int nfs
John Keeping writes:
> Allow the empty string to stand in for the null SHA-1 when pushing a new
> branch, like we do when deleting branches.
>
> This means that the following command ensures that `new-branch` is
> created on the remote (that is, is must not already exist):
>
> git push --fo
On Mon, Jul 25, 2016 at 12:34:04PM +0200, Jan Smets wrote:
> I have always assumed the post-receive hook to be executed whenever a commit
> is "accepted" by the (gitolite) server. That does not seem to be true any
> more.
Generally, yeah, I would expect that to be the case, too.
> Since 9658846
John Keeping writes:
> On Mon, Jul 25, 2016 at 10:28:01AM -0700, Junio C Hamano wrote:
>> John Keeping writes:
>>
>> > If there is no upstream information for a branch, it is likely that it
>> > is newly created and can safely be pushed under the normal fast-forward
>> > rules. Relax the --for
Johannes Schindelin writes:
> 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
On Mon, Jul 25, 2016 at 02:44:25PM -0700, Junio C Hamano wrote:
> > diff --git a/imap-send.c b/imap-send.c
> > index db0fafe..67d67f8 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, c
Junio C Hamano writes:
> I suspect that the if/else cascade in the loop in apply_cas() can
> also be taught that ':' followed by an empty string asks to check
> that the target ref does not exist, in order to make it a bit more
> useful for folks who do not rely on the "use the last observed
> st
On Mon, Jul 25, 2016 at 02:52:24PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > if (!*found_pack) {
> > ... first find! fill in found pack, etc ...
> > }
> > if (exclude)
> > return 1;
> > if (incremental)
> > return 0;
> > if (!ignore_packed_keep && !local)
> >
Johannes Schindelin writes:
> There are a couple of places where return values indicating errors
> are ignored. Let's teach them manners.
That is because the return value never indicated errors before this
series, isn't it? A true error used to be expressed by dying, and
the return value indica
On Mon, Jul 25, 2016 at 12:56:23PM -0700, Junio C Hamano wrote:
> > This function loops through each existing packfile, looking
> > for the object. When we find it, we mark the pack/offset
> > combo for later use. However, we can't just return "yes, we
> > want it" at that point. If --honor-pack-k
Format the placeholder as monospace to match other occurrences in this
file and obey CodingGuidelines.
Signed-off-by: John Keeping
---
New in v2.
Documentation/git-push.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.tx
Allow the empty string to stand in for the null SHA-1 when pushing a new
branch, like we do when deleting branches.
This means that the following command ensures that `new-branch` is
created on the remote (that is, is must not already exist):
git push --force-with-lease=new-branch: origin
On Mon, Jul 25, 2016 at 10:28:01AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > If there is no upstream information for a branch, it is likely that it
> > is newly created and can safely be pushed under the normal fast-forward
> > rules. Relax the --force-with-lease check so that we
If there is no upstream information for a branch, it is likely that it
is newly created and can safely be pushed under the normal fast-forward
rules. Relax the --force-with-lease check so that we do not reject
these branches immediately but rather attempt to push them as new
branches, using the nu
Jeff King writes:
> if (!*found_pack) {
> ... first find! fill in found pack, etc ...
> }
> if (exclude)
> return 1;
> if (incremental)
> return 0;
> if (!ignore_packed_keep && !local)
> break; /* effectively return 1, but I think the break is more clear */
> if
Johannes Schindelin writes:
> diff --git a/imap-send.c b/imap-send.c
> index db0fafe..67d67f8 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;
> +
Johannes Schindelin writes:
> +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 &&
Make this more readble by using test-write-li
On Mon, Jul 25, 2016 at 6:53 PM, Junio C Hamano wrote:
> Pranit Bauva writes:
>
>>> And why are the defines 1,2,4,8 ?
>>> It looks as if a #define bitmap may be a better choice here ?
>>> How do we do these kind of bit-wise opions otherwise ?
>
> We might want to ask if these should even be bitwi
On Mon, Jul 25, 2016 at 6:04 PM, Duy Nguyen wrote:
>
> Hmm.. can you do the counting separately? A shared cache_entry must
> have its field "index" greater than zero. By counting the number of
> entries whose index is zero (i.e. not shared) against the total number
> of real (*) entries, you shoul
Junio C Hamano wrote:
> Eric Wong writes:
>
> >> Also, doesn't it break "git rebase" (non-interactive), or anything
> >> that internally runs format-patch to individual files and then runs
> >> am on each of them, anything that knows that each output file from
> >> format-patch corresponds to a
Eric Wong writes:
> Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>> > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote:
>> >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy
>> >> wrote:
>> >>> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has
>> >>> been remo
Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote:
> >> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy
> >> wrote:
> >>> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has
> >>> been removed at least on FreeBSD 10.3.
On 25 Jul 2016, at 01:22, Jakub Narębski wrote:
> W dniu 2016-07-25 o 00:36, Ramsay Jones pisze:
>> On 24/07/16 18:16, Lars Schneider wrote:
>>> On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
> [...]
> This patch adds the filter..usePro
Jeff Hostetler writes:
> /*
> + * Print branch and tracking header for porcelain v2 output.
> + * This is printed when the '--branch' parameter is given.
> + *
> + *"## branch: [ [ + -]]"
Just FYI, the only reason why the original "short" output gives this
information on a single line with
On 25 Jul 2016, at 00:36, Ramsay Jones wrote:
> On 24/07/16 18:16, Lars Schneider wrote:
>>
>> On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
>>
>>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter
Jeff Hostetler writes:
> +static void wt_porcelain_v2_print(struct wt_status *s);
> +
There is no point in this forward declaration, if you just place the
implementation of these functions here, no?
> +/*
> + * Print porcelain v2 info for tracked entries with changes.
> + */
> +static void wt_p
On 24 Jul 2016, at 23:30, Jakub Narębski wrote:
> W dniu 2016-07-24 o 22:14, Jakub Narębski pisze:
>> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>
>>> I agree that the name is not ideal. "UseProtocol" as it is would be a
>>> boolean.
>>> I thought about "persistent" but this name wouldn
Jeff Hostetler writes:
> +static void aux_updated_entry_porcelain_v2(
> + struct wt_status *s,
> + struct wt_status_change_data *d,
> + struct diff_filepair *p)
> +{
> + switch (p->status) {
> + case DIFF_STATUS_ADDED:
> + /* {mode,sha1}_head are zero for an add. *
On 24 Jul 2016, at 22:14, Jakub Narębski wrote:
> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>> On 23 Jul 2016, at 02:11, Jakub Narębski wrote:
>>> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
From: Lars Schneider
>>>
>>> Nb. this line is only needed if you want autho
Jeff Hostetler writes:
> Refactor the API between builtin/commit.c and wt-status.[ch].
> Hide details of the various wt_*status_print() routines inside
> wt-status.c behind a single (new) wt_status_print() routine
> and eliminate the switch statements from builtin/commit.c
>
> This will allow us
Jeff King writes:
> When pack-objects collects the list of objects to pack
> (either from stdin, or via its internal rev-list), it
> filters each one through want_object_in_pack().
>
> This function loops through each existing packfile, looking
> for the object. When we find it, we mark the pack/
W dniu 2016-07-25 o 21:25, Jeff Hostetler pisze:
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -144,6 +144,21 @@ static struct strbuf message = STRBUF_INIT;
>
> static enum wt_status_format status_format = STATUS_FORMAT_UNSPECIFIED;
>
> +static int opt_parse_porcelain(const struct opt
Refactor the API between builtin/commit.c and wt-status.[ch].
Hide details of the various wt_*status_print() routines inside
wt-status.c behind a single (new) wt_status_print() routine
and eliminate the switch statements from builtin/commit.c
This will allow us to more easily add new status format
Update --porcelain argument to take optional version parameter
to allow multiple porcelain formats to be supported in the future.
The token "v1" is the default value and indicates the traditional
porcelain format.
Signed-off-by: Jeff Hostetler
---
Documentation/git-status.txt | 7 +--
buil
Unit tests for porcelain v2 status format.
Signed-off-by: Jeff Hostetler
---
t/t7064-wtstatus-pv2.sh | 542
1 file changed, 542 insertions(+)
create mode 100755 t/t7064-wtstatus-pv2.sh
diff --git a/t/t7064-wtstatus-pv2.sh b/t/t7064-wtstatus-pv2.
Print per-file information in porcelain v2 format.
Signed-off-by: Jeff Hostetler
---
wt-status.c | 285 +++-
1 file changed, 284 insertions(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 54aedc1..ffdfe11 100644
--- a/wt-sta
Renamed the various wt_status_print*() routines to be
wt_longstatus_print*() to make it clear that these
routines are only concerned with the normal/long
status output.
This will hopefully reduce confusion as other status
formats are added in the future.
Signed-off-by: Jeff Hostetler
---
builti
Expand porcelain v2 output to include branch and tracking
branch information. This includes the commit SHA, the branch,
the upstream branch, and the ahead and behind counts.
Signed-off-by: Jeff Hostetler
---
builtin/commit.c | 5
wt-status.c | 86 +
The output of `git status --porcelain` leaves out many details
about the current status that clients might like to have. This
can force them to be less efficient as they may need to launch
secondary commands (and try to match the logic within git) to
accumulate this extra information. For example,
Update status manpage to include information about
porcelain v2 format.
Signed-off-by: Jeff Hostetler
---
Documentation/git-status.txt | 83 ++--
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/gi
This patch series adds porcelain V2 format to status.
This provides detailed information about file changes
and about the current branch.
The new output is accessed via:
git status --porcelain=v2 [--branch]
This patch series hopefully addresses all of the
comments from the previous series. T
On Mon, Jul 25, 2016 at 02:40:25PM -0400, Jeff King wrote:
> > @@ -1052,6 +1053,9 @@ static int add_object_entry_from_bitmap(const
> > unsigned char *sha1,
> > {
> > uint32_t index_pos;
> >
> > + if (local && has_loose_object_nonlocal(sha1))
> > + return 0;
> > +
> > if (ha
In want_object_in_pack(), we can exit early from our loop if
neither "local" nor "ignore_pack_keep" are set. If they are,
however, we must examine each pack to see if it has the
object and is non-local or has a ".keep".
It's quite common for there to be no non-local or .keep
packs at all, in which
When pack-objects collects the list of objects to pack
(either from stdin, or via its internal rev-list), it
filters each one through want_object_in_pack().
This function loops through each existing packfile, looking
for the object. When we find it, we mark the pack/offset
combo for later use. How
We sometimes see cases at GitHub where repository maintenance has fallen
behind, and you get a large number of packs. The solution is to repack,
but that process is itself made a lot slower by the number of packs.
We've experimented a bit with fast "just cat all the packfiles together"
type approa
On Wed, Jul 13, 2016 at 01:52:17PM +0300, Kirill Smelkov wrote:
> > So I think if you were to repeatedly "git repack -adb" over time, you
> > would get worse and worse ordering as objects are added to the
> > repository.
>
> Jeff, first of all thanks for clarifying.
>
> So it is not-yet-packed-o
Duy Nguyen writes:
> On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote:
>> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has
>>> been removed at least on FreeBSD 10.3. See [1] for more information.
>>>
>>
Andreas Schwab writes:
>> +colon = line + len - 2;
>> +line += 5;
>> +for (;;) {
>> +if (colon < line)
>> +return 0;
>> +if (*--colon == ':')
>> +break;
>> +}
>> +
>> +if (!isdigit(colon[-4]) ||
>> +!isdig
Vasco Almeida writes:
> static const char note_template[] =
> - "\nWrite/edit the notes for the following object:\n";
> + N_("Write/edit the notes for the following object:");
>
> struct note_data {
> int given;
> @@ -179,7 +179,8 @@ static void prepare_note_data(const unsigned
Eric Wong writes:
> This allows us to use common test infrastructure and parallelize
> the tests. For now, GIT_SVN_TEST_HTTPD=true needs to be set to
> enable the SVN HTTP tests because we reuse the same test cases
> for both file:// and http:// SVN repositories. SVN_HTTPD_PORT
> is no longer h
W dniu 2016-07-25 o 18:58, Junio C Hamano pisze:
> Sidhant Sharma writes:
>
>> I was wondering if it would be a good idea to have a command to check if a
>> push or pull is required. Perhaps it can also suggest if changes are
>> fast-forward or the branches (local and remote) have diverged.
>
>
Eric Wong writes:
>> Also, doesn't it break "git rebase" (non-interactive), or anything
>> that internally runs format-patch to individual files and then runs
>> am on each of them, anything that knows that each output file from
>> format-patch corresponds to a single change and there is no need
W dniu 2016-07-25 o 09:33, Johannes Schindelin pisze:
> Therefore "%s%n%+b" *might* do what you intended (I would not
> know, because that information was missing from the report).
Shouldn't it be "%s%n%n%-b" or "%s%n%-b"?
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsub
On Mon, Jul 25, 2016 at 6:56 PM, Junio C Hamano wrote:
> On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has
>> been removed at least on FreeBSD 10.3. See [1] for more information.
>>
>> [1]
>> https://svnweb.free
John Keeping writes:
> If there is no upstream information for a branch, it is likely that it
> is newly created and can safely be pushed under the normal fast-forward
> rules. Relax the --force-with-lease check so that we do not reject
> these branches immediately but rather attempt to push the
Junio C Hamano writes:
> Jon Forrest writes:
>
>> Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd
>> Edition (or just Pro Git 2nd Edition - it doesn't matter). You see
>> lots of output showing 'git commit' commands and the commit IDs that
>> result. I suspect you'd see the
Sidhant Sharma writes:
> I was wondering if it would be a good idea to have a command to check if a
> push or pull is required. Perhaps it can also suggest if changes are
> fast-forward or the branches (local and remote) have diverged.
Doesn't "branch -v" give that information these days? You'd
On Mon, Jul 25, 2016 at 9:21 AM, Nguyễn Thái Ngọc Duy wrote:
> It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has
> been removed at least on FreeBSD 10.3. See [1] for more information.
>
> [1]
> https://svnweb.freebsd.org/ports/head/UPDATING?r1=386270&r2=386269&pathrev=386270&dif
Pranit Bauva writes:
>>> +enum terms_defined {
>>> + TERM_BAD = 1,
>>> + TERM_GOOD = 2,
>>> + TERM_NEW = 4,
>>> + TERM_OLD = 8
>>> +};
>>> +
>>
>> What does TERM stand for ?
The terms (words) used to denote the newer and the older parts of
the history. Traditionally, as
Jakub Narębski writes:
> Subject: [PATCH] gitweb(1): Document query parameters
>
> The gitweb manpage includes description of gitweb URL structure,
> but it was limited to passing parameters in the path part of URL
> ('path info'), and it didn't include explanation of query parameters.
> ---
I t
It looks the the symlink /usr/bin/perl (to /usr/local/bin/perl) has
been removed at least on FreeBSD 10.3. See [1] for more information.
[1]
https://svnweb.freebsd.org/ports/head/UPDATING?r1=386270&r2=386269&pathrev=386270&diff_format=c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Tested with fbsd
Eric Sunshine writes:
>> Later when the grep API was used in revision graversal machinery,
>
> s/graversal/traversal/
Thanks.
--
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/maj
On Mon, Jul 25, 2016 at 5:16 PM, Junio C Hamano wrote:
> On Mon, Jul 25, 2016 at 2:31 AM, Vasco Almeida wrote:
>> Replace gettext poison text with appropriate values to be able to cut
>> the right output of git fetch command for comparison.
>
> Hmm, as these tests are _all_ about human-readable o
On Sat, Jul 23, 2016 at 6:11 PM, Christian Couder
wrote:
> Ok, I started working on automatically pushing back all changes to the
> shared index when the percentage of entries in linked vs shared
> indexes is greater than 25% (maybe I will make it configurable later).
> It is very basic and doesn'
On Sun, Jul 24, 2016 at 9:11 PM, Lars Schneider
wrote:
>
> On 23 Jul 2016, at 10:14, Eric Wong wrote:
>
>> larsxschnei...@gmail.com wrote:
>>> Please note that the protocol filters do not support stream processing
>>> with this implemenatation because the filter needs to know the length of
>>> th
Stefan Beller writes:
> On Fri, Jul 22, 2016 at 9:55 AM, Junio C Hamano wrote:
>>
>> * submodule.$name.update, submodule.$name.ignore,
>>submodule.$name.branch, etc. would need to be all different among
>>worktrees of the superproject, as that is the whole point of
>>being able to w
On Mon, Jul 25, 2016 at 2:31 AM, Vasco Almeida wrote:
> Replace gettext poison text with appropriate values to be able to cut
> the right output of git fetch command for comparison.
Hmm, as these tests are _all_ about human-readable output, it probably is
sufficient to skip them using prerequiste
Jon Forrest writes:
> Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd
> Edition (or just Pro Git 2nd Edition - it doesn't matter). You see
> lots of output showing 'git commit' commands and the commit IDs that
> result. I suspect you'd see the same in almost any book about Gi
Heiko Voigt writes:
> Thats a good idea. Can send a patch, but I noticed that your change is
> already in next and my change has not been picked up. So I am unsure if
> I should base my patches on next or if Junio wants to keep your change?
When you noticed something you want to touch up in 'nex
Hi,
On Thu, Jul 21, 2016 at 08:57:03PM +0200, René Scharfe wrote:
> >diff --git a/submodule-config.c b/submodule-config.c
> >index 077db40..dccea59 100644
> >--- a/submodule-config.c
> >+++ b/submodule-config.c
[...]
> >@@ -431,14 +432,19 @@ static const struct submodule *config_from(struct
> >
Hi,
I was wondering if it would be a good idea to have a command to check if a
push or pull is required. Perhaps it can also suggest if changes are
fast-forward or the branches (local and remote) have diverged.
The reason I feel the need of such a command is when I need to check if my
branch is up-
On Monday 25 July 2016 10:06:28 Johannes Schindelin wrote:
> Hi Ilya,
>
> On Mon, 25 Jul 2016, Ilya Tumaykin wrote:
> > On Monday 25 July 2016 09:33:00 Johannes Schindelin wrote:
> > > On Sun, 24 Jul 2016, Ilya Tumaykin wrote:
> > > [...]
> > >
> > > > $ git --no-pager log -1 --format='format:%+s
Hi
I have always assumed the post-receive hook to be executed whenever a
commit is "accepted" by the (gitolite) server. That does not seem to be
true any more.
Since 9658846 is appears that, when a client bails out, the pre-receive
hook continues to run and the commit is written to the repos
Replace gettext poison text with appropriate values to be able to cut
the right output of git fetch command for comparison.
The first gettext poison falls from the previous line into the next
because the poison does not add a newline, so we must replace it with
nothing.
Signed-off-by: Vasco Almei
Junio C Hamano wrote:
> Junio C Hamano writes:
> > Eric Wong writes:
> >
> >> Users have mistakenly copied "From " lines into commit messages
> >> in the past, and will certainly make the same mistakes in the
> >> future. Since not everyone uses mboxrd, yet, we should at least
> >> prevent miss
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0b2
[ Previou
Hi Ilya,
On Mon, 25 Jul 2016, Ilya Tumaykin wrote:
> On Monday 25 July 2016 09:33:00 Johannes Schindelin wrote:
> >
> > On Sun, 24 Jul 2016, Ilya Tumaykin wrote:
> > [...]
> > > $ git --no-pager log -1 --format='format:%+s%+b'
> > >
> > > Actual results:
> > > ```
> > >
> > > This is subject
>
On Monday 25 July 2016 09:33:00 Johannes Schindelin wrote:
> Hi Ilya,
>
> On Sun, 24 Jul 2016, Ilya Tumaykin wrote:
> > Steps to reproduce:
> > $ git init
> > $ >123
> > $ git add 123
> > $ git commit -v -m 'This is subject' -m 'And this is body'
> > $ git --no-pager log -1 --format='format:%+s%+b
Hi Ilya,
On Sun, 24 Jul 2016, Ilya Tumaykin wrote:
> Steps to reproduce:
> $ git init
> $ >123
> $ git add 123
> $ git commit -v -m 'This is subject' -m 'And this is body'
> $ git --no-pager log -1 --format='format:%+s%+b'
>
> Actual results:
> ```
>
> This is subject
> And this is body
> ```
>
Lars Schneider wrote:
> On 23 Jul 2016, at 10:14, Eric Wong wrote:
> > larsxschnei...@gmail.com wrote:
> >> +static struct cmd2process *start_protocol_filter(const char *cmd)
> >> +{
> >> + int ret = 1;
> >> + struct cmd2process *entry = NULL;
> >> + struct child_process *process = NULL;
> >
Hi Jon,
On Sun, 24 Jul 2016, Jon Forrest wrote:
> On 7/24/2016 11:27 AM, Jakub Narębski wrote:
>
> > All right. One issue I have after browsing through changes is that
> > description of changes and their granularity is severely lacking. "A
> > few more very minor changes.", "More piddly change
100 matches
Mail list logo