Jonathan Tan writes:
> Use singly-linked lists (instead of doubly-linked lists) in trailer to
> keep track of arguments (whether implicit from configuration or explicit
> from the command line) and trailer items.
>
> This change significantly reduces the code length and simplifies the code.
> The
Larry Finger writes:
> On 10/11/2016 11:18 AM, Matthieu Moy wrote:
>> Larry Finger writes:
>>
>>> That added information at the end is intended to be passed on to the
>>> stable group. In this case, the patch needs to be applied to kernel
>>> versions 4.8 and later.
>>
>> OK, but where do people
This is update of the second variant for request to add option to change
suffix of name of temporary files generated by git mergetool. This
change is requested for cases, when is git mergetool used for local
comparison between two version of same package during package rebase.
Signed-off-by: Josef
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to
transfer into your account,
I will send you more details about this deal and the procedures to
follow when I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
Hello Jakub,
Thank you for addition. Eventually, I've merged your explanations into single
answer post
(http://stackoverflow.com/questions/39954265/git-merge-s-subtree-works-incorrectly/
). I hope this will prevent other confused people from disturbing you by
similar emails on this mailing lis
Hello,
first, I observed a bug with git pull --rebase:
if the remote branch got rebased and the loval branch was updated,
pull tried to rebase the whole branch, not the local increment.
A reproducer would look like that
# in repo1:
git checkout tmp
cd ..
git clone repo1 repo2
cd repo1
git rebase
Hi.
I created a new branch named hotfix from master.
I switched to the branch, changed 1 file.
Now I want to see the diff from the both using
git diff hotfix master
I do not see any output (difference).
When I do a git status I see my file with status mofified, not staged for
commit.
Also, I ca
W dniu 12.10.2016 o 00:26, Lars Schneider pisze:
>> On 09 Oct 2016, at 01:06, Jakub Narębski wrote:
>>
>> Part 1 of review, starting with the protocol v2 itself.
>>
>> W dniu 08.10.2016 o 13:25, larsxschnei...@gmail.com pisze:
>>> From: Lars Schneider
>>>
>>> +upon checkin. By default these comm
On Wed, Oct 12, 2016 at 6:50 AM, wrote:
> Hi.
>
> I created a new branch named hotfix from master.
> I switched to the branch, changed 1 file.
>
> Now I want to see the diff from the both using
>
> git diff hotfix master
>
> I do not see any output (difference).
> When I do a git status I see my
Hi Junio,
On Tue, 11 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/sequencer.c b/sequencer.c
> > index afc494e..7ba5e07 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -708,6 +708,8 @@ static int read_and_refresh_cache(struct replay_opts
> > *opts)
Hi Junio,
On Tue, 11 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/sequencer.c b/sequencer.c
> > index 678fdf3..cee7e50 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -774,6 +774,9 @@ static int parse_insn_buffer(char *buf, struct
> > todo_list *to
Hi Junio,
On Tue, 11 Oct 2016, Junio C Hamano wrote:
> > @@ -370,19 +383,79 @@ static int is_index_unchanged(void)
> > }
> >
> > /*
> > + * Read the author-script file into an environment block, ready for use in
> > + * run_command(), that can be free()d afterwards.
> > + */
> > +static char
Hi Junio,
On Tue, 11 Oct 2016, Junio C Hamano wrote:
> The only reason why the OPT_STRDUP appeared convenient was because
> options[] element happened to use a field in the structure directly.
> The patch under discussion does an equivalent of
>
> app.x_field = xstrdup_or_null(opt_x);
Oh, t
The concerned message was marked for translation by 0c99171
("get_short_sha1: mark ambiguity error for translation", 2016-09-26).
Signed-off-by: Vasco Almeida
---
t/t1512-rev-parse-disambiguation.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1512-rev-parse-disambiguat
Hi Kuba,
On Tue, 11 Oct 2016, Jakub Narębski wrote:
> W dniu 11.10.2016 o 18:09, Johannes Schindelin pisze:
>
> > SYNOPSIS
> >
> > [verse]
> > -'git reset' [-q] [] [--] ...
> > +'git reset' [-q] [--stdin [-z]] [] [--] ...
>
> I think you meant here
>
> +'git reset' [-q] [--stdin
Hi Junio,
On Tue, 11 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > + if (read_from_stdin) {
> > + strbuf_getline_fn getline_fn = nul_term_line ?
> > + strbuf_getline_nul : strbuf_getline_lf;
> > + int flags = PATHSPEC_PREFER_FULL |
>
On Fri, Oct 07, 2016 at 10:59:29AM -0700, Stefan Beller wrote:
> On Fri, Oct 7, 2016 at 8:06 AM, Heiko Voigt wrote:
> > +static void free_submodules_sha1s(struct string_list *submodules)
> > +{
> > + int i;
> > + for (i = 0; i < submodules->nr; i++) {
> > + struct string_
On Fri, Oct 07, 2016 at 11:16:31AM -0700, Stefan Beller wrote:
> > diff --git a/submodule.c b/submodule.c
> > index 59c9d15905..5044afc2f8 100644
> > --- a/submodule.c
> > +++ b/submodule.c
> > @@ -522,6 +522,13 @@ static int has_remote(const char *refname, const
> > struct object_id *oid,
> >
According to gpg2's doc/DETAILS:
For each signature only one of the codes GOODSIG, BADSIG,
EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.
gpg1 ("classic") behaves the same (although doc/DETAILS differs).
Currently, we parse gpg's status output for GOODSIG, BADSIG and
trust infor
On Mon, Oct 10, 2016 at 03:43:13PM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> >> +static struct sha1_array *get_sha1s_from_list(struct string_list
> >> *submodules,
> >> + const char *path)
> >
> > So this will take the stringlist `submodules` and insert the path into
On Tue, Oct 11, 2016 at 01:55:22PM -0700, Stefan Beller wrote:
> On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin
> wrote:
> > I assume somebody familiar with GIT's code base could make this change
> > in about 10 minutes.
>
> Can you elaborate how you come to that estimate?
Hm, a false belie
On Mon, Oct 10, 2016 at 03:56:13PM -0700, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > -static int submodule_needs_pushing(const char *path, const unsigned char
> > sha1[20])
> > +static int check_has_hash(const unsigned char sha1[20], void *data)
> > {
> > - if (add_submodule_odb(path)
From: Torsten Bögershausen
Changes since v1:
- Rename earlyout into search_only
- Increase buffer from 2KiB to 16KiB
- s/mask/eol_bits/
- Reduce the "noise"
- Document "split gather_stats() into gather_all_stats()/gather_stats_partly()
Torsten Bögershausen (2):
read-cache: factor out get_sha1_
From: Torsten Bögershausen
When statistics are done for the autocrlf handling, the search in
the content can be stopped, if e.g
- a search for binary is done, and a NUL character is found
- a search for CRLF is done, and the first CRLF is found.
Similar when statistics for binary vs non-binary a
From: Torsten Bögershausen
Factor out the retrieval of the sha1 for a given path in
read_blob_data_from_index() into the function get_sha1_from_index().
This will be used in the next commit, when convert.c can do the
analyze for "text=auto" without slurping the whole blob into memory
at once.
A
Thanks, Mike. Now I understood.
-fuz
> Mike Rappazzo hat am 12. Oktober 2016 um 13:06
> geschrieben:
>
> On Wed, Oct 12, 2016 at 6:50 AM, wrote:
> > Hi.
> >
> > I created a new branch named hotfix from master.
> > I switched to the branch, changed 1 file.
> >
> > Now I want to see the diff fro
Hi.
I have created a release_x branch to work on a new release. The branch is based
on master.
Later I needed to create a hotfix_x branch to work on a hotfix. This branch is
also based on master.
In the hotfix_x branch I needed to correct an IP address to communicate with.
After doing so, I merged
Hi Stefan,
On Mon, 10 Oct 2016, Stefan Beller wrote:
> Before 63e95beb0 (2016-04-15, submodule: port resolve_relative_url from
> shell to C), it did not matter if the superprojects URL had a trailing
> slash or not. It was just chopped off as one of the first steps
> (The "remoteurl=${remoteurl%/
Hi Ramsay!
On Wed, 12 Oct 2016, Ramsay Jones wrote:
> If you need to re-roll your 'js/prepare-sequencer' branch, could you
> please squash this into commit 53f8024e ("sequencer: completely revamp
> the "todo" script parsing", 10-10-2016).
Will do!
Thanks,
Dscho
Hi,
the IP will not be overwritten, you'll still have the new IP in
master. Nothing to worry about :)
--
Mit freundlichen Grüßen,
Anatoly Borodin
Hi,
I'm a FreeBSD ports developer, and while our main repository is in
Subversion, some of us use git-svn a lot for development.
I discovered git worktree earlier this week, and I found it a great
asset to be able to have more than one branch of my worktree accessible
at the same time...
Anyway,
On 10/12/2016 02:36 AM, Matthieu Moy wrote:
Larry Finger writes:
On 10/11/2016 11:18 AM, Matthieu Moy wrote:
Larry Finger writes:
That added information at the end is intended to be passed on to the
stable group. In this case, the patch needs to be applied to kernel
versions 4.8 and later.
On 10/12/2016 02:36 AM, Matthieu Moy wrote:
Larry Finger writes:
On 10/11/2016 11:18 AM, Matthieu Moy wrote:
Larry Finger writes:
That added information at the end is intended to be passed on to the
stable group. In this case, the patch needs to be applied to kernel
versions 4.8 and later.
Larry Finger writes:
> On 10/12/2016 02:36 AM, Matthieu Moy wrote:
>> Larry Finger writes:
>>
>>> On 10/11/2016 11:18 AM, Matthieu Moy wrote:
Larry Finger writes:
> That added information at the end is intended to be passed on to the
> stable group. In this case, the patch nee
Larry Finger writes:
> On 10/12/2016 02:36 AM, Matthieu Moy wrote:
>> Larry Finger writes:
>>
>>> On 10/11/2016 11:18 AM, Matthieu Moy wrote:
Larry Finger writes:
> That added information at the end is intended to be passed on to the
> stable group. In this case, the patch nee
On Wed, Oct 12, 2016 at 3:23 AM, Jonathan Tan wrote:
> Use singly-linked lists (instead of doubly-linked lists) in trailer to
> keep track of arguments (whether implicit from configuration or explicit
> from the command line) and trailer items.
>
> This change significantly reduces the code length
On 10/12/2016 10:45 AM, Matthieu Moy wrote:
Larry Finger writes:
On 10/12/2016 02:36 AM, Matthieu Moy wrote:
Larry Finger writes:
On 10/11/2016 11:18 AM, Matthieu Moy wrote:
Larry Finger writes:
That added information at the end is intended to be passed on to the
stable group. In this
Hi Stefan,
On Tue, 11 Oct 2016, Stefan Beller wrote:
> On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin
> wrote:
> > I assume somebody familiar with GIT's code base could make this change
> > in about 10 minutes.
>
> Can you elaborate how you come to that estimate?
Why do you ask? He obvio
Howdy git gurus,
I have the dubious distinction of working with a remote repo (master)
that has a class loader run-time error when cloned, built and executed.
The reason for the runtime issue is a directory hierarchical path has to
directories (folders) with the same name spelling but one of
Stefan Beller writes:
>> I am not sure if the updates to the callers fulfill that purpose.
>> For example, look at this hunk.
>>
>>> @@ -111,6 +111,7 @@ static int write_archive_entry(const unsigned char
>>> *sha1, const char *base,
>>> struct archiver_args *args = c->args;
>>> write
Hi Joshua,
On Wed, 12 Oct 2016, Joshua N Pritikin wrote:
> On Tue, Oct 11, 2016 at 01:55:22PM -0700, Stefan Beller wrote:
> > On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin
> > wrote:
> > > I assume somebody familiar with GIT's code base could make this
> > > change in about 10 minutes.
>
Johannes Schindelin writes:
>> > + const char *arg;
>> > + int arg_len;
>> >size_t offset_in_buf;
>>
>> micronit: you can make it to size_t and lose the cast below, no?
>
> No. The primary users of arg_len call a printf() style function with %.*s,
> expecting an int. So your suggestion wou
On Wed, Oct 12, 2016 at 12:37:16PM +0200, Stepan Kasal wrote:
> A reproducer would look like that
>
> # in repo1:
> git checkout tmp
> cd ..
> git clone repo1 repo2
> cd repo1
> git rebase elsewhere tmp
> cd ../repo2
> # edit
> git commit -a -m 'Another commit'
> git pull -r
>
> The last command
On Wed, Oct 12, 2016 at 12:25:33PM +, Vasco Almeida wrote:
> The concerned message was marked for translation by 0c99171
> ("get_short_sha1: mark ambiguity error for translation", 2016-09-26).
Thanks, this looks obviously correct.
-Peff
In bare repositories, get_worktrees() still returns the main repository,
so git worktree list can show it. ignore it in find_shared_symref so we
can still check out the main branch.
Signed-off-by: Dennis Kaarsemaker
---
t/t2025-worktree-add.sh | 8
worktree.c | 2 ++
2 file
Johannes Schindelin writes:
>> Hmph, didn't we recently add parse_key_value_squoted() to build
>> read_author_script() in builtin/am.c on top of it, so that this
>> piece of code can also take advantage of and share the parser?
>
> I already pointed out that the author-script file may *not* be qu
On Wed, Oct 12, 2016 at 06:24:37PM +0200, Johannes Schindelin wrote:
> No, a false belief in your own shortcomings, as you thought it would be
> easier to address your wishes for somebody else than you.
Ah, shucks, I guess I could jump in.
> But maybe I read it all wrong and you do want to make t
On Wed, Oct 12, 2016 at 6:30 AM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Mon, 10 Oct 2016, Stefan Beller wrote:
>
>> Before 63e95beb0 (2016-04-15, submodule: port resolve_relative_url from
>> shell to C), it did not matter if the superprojects URL had a trailing
>> slash or not. It was just
Heiko Voigt writes:
> Which seems quite extensively long for a static function so how about
> we shorten it a bit and add a comment:
>
> /* lookup or create commit object list for submodule */
> get_commit_objects_for_submodule_path(...
Or you can even lose "get_" and "path", I guess
On Wed, Oct 12, 2016 at 05:38:14PM +0200, Christian Couder wrote:
> On Wed, Oct 12, 2016 at 3:23 AM, Jonathan Tan
> wrote:
> > Use singly-linked lists (instead of doubly-linked lists) in trailer to
> > keep track of arguments (whether implicit from configuration or explicit
> > from the command
Heiko Voigt writes:
>> If we do not even have these commits locally, then there is no point
>> attempting to push, so returning 0 (i.e. it is not "needs pushing"
>> situation) is correct but it is a but subtle. It's not "we know
>> they already have them", but it is "even if we tried to push, it
I have tested this successfully with git 2.10.1 built from source
(failing), then patched as above (passing).
Thanks!
M.
On Wed, Oct 12, 2016 at 11:41 AM, Dennis Kaarsemaker
wrote:
> In bare repositories, get_worktrees() still returns the main repository,
> so git worktree list can show it.
Josef Ridky writes:
> This is update of the second variant for request to add option to change
> suffix of name of temporary files generated by git mergetool. This
> change is requested for cases, when is git mergetool used for local
> comparison between two version of same package during package
Johannes Schindelin writes:
> On Tue, 11 Oct 2016, Junio C Hamano wrote:
>
>> The only reason why the OPT_STRDUP appeared convenient was because
>> options[] element happened to use a field in the structure directly.
>> The patch under discussion does an equivalent of
>>
>> app.x_field = xst
Dennis Kaarsemaker writes:
> OK, so here it is as a proper patch.
>
> D.
>
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> index 4bcc335..2996c38 100755
> --- a/t/t2025-worktree-add.sh
> +++ b/t/t2025-worktree-add.sh
> @@ -138,6 +138,14 @@ test_expect_success 'checkout from a b
Junio C Hamano writes:
> Dennis Kaarsemaker writes:
>
>> OK, so here it is as a proper patch.
Here is what I queued. Duy, what do you think? It seems OK to me.
Thanks.
-- >8 --
From: Dennis Kaarsemaker
Date: Wed, 12 Oct 2016 18:41:07 +0200
Subject: [PATCH] worktree: allow the main brach of
Hello,
On Wed, Oct 12, 2016 at 12:32:09PM -0400, Jeff King wrote:
> The --fork-point option looks in the reflog [...]
> On Wed, Oct 12, 2016 at 12:37:16PM +0200, Stepan Kasal wrote:
> > Could you please fix merge-base so that it understands packed refs?
I bet you nailed it; nothing with packed re
On Wed, Oct 12, 2016 at 9:20 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> I am not sure if the updates to the callers fulfill that purpose.
>>> For example, look at this hunk.
>>>
@@ -111,6 +111,7 @@ static int write_archive_entry(const unsigned char
*sha1, const char *base,
Am 12.10.2016 um 01:59 schrieb Stefan Beller:
+void git_attr_check_initl(struct git_attr_check **check_,
+ const char *one, ...)
{
- struct git_attr_check *check;
int cnt;
va_list params;
const char *param;
+ struct git_attr_check *chec
On Wed, Oct 12, 2016 at 12:32:09PM -0400, Jeff King wrote:
> > The problem seems to be that command
> > git merge-base --fork-point refs/remotes/origin/tmp refs/heads/tmp
> > returns nothing, because the refs are packed.
>
> The --fork-point option looks in the reflog to notice that the upstrea
Am 10.10.2016 um 19:26 schrieb Johannes Schindelin:
> There was actually only one error message that was not yet marked for
> translation.
>
> Signed-off-by: Johannes Schindelin
> ---
> sequencer.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git
Matthieu Moy writes:
>>> If it's not in the body of the message, then where is it?
>>
>> This point is clarified in the thread
>> http://marc.info/?l=linux-wireless&m=147625930203434&w=2, which is
>> with my upstream maintainer.
>
> Which explicitly states that the syntax is not [$number], but #
+cc Duy who knows about worktree,
+cc Eric Wong, who knows about git-svn
On Wed, Oct 12, 2016 at 7:45 AM, Mathieu Arnold wrote:
> Hi,
>
> I'm a FreeBSD ports developer, and while our main repository is in
> Subversion, some of us use git-svn a lot for development.
>
> I discovered git worktree
Johannes Sixt writes:
> Can we please have the following change instead? I think it makes sense
> to deviate from the usual conventions in a case like this.
You have at least two independent changes relative to Dscho's
version.
(1) Show line breaks more prominently by avoiding "\n\n" and
Stefan Beller writes:
> This version adds the actual thread safety,
> that is promised in the documentation, however it doesn't add any
> optimization,
> i.e. it's a single global lock. But as we do not expect contention, that is
> fine.
Because we have to start _somewhere_, I agree it is a go
Jeff King writes:
> Subject: merge-base: handle --fork-point without reflog
>
> The --fork-point option looks in the reflog to try to find
> where a derived branch forked from a base branch. However,
> if the reflog for the base branch is totally empty (as it
> commonly is right after cloning, wh
On Wed, Oct 12, 2016 at 2:28 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This version adds the actual thread safety,
>> that is promised in the documentation, however it doesn't add any
>> optimization,
>> i.e. it's a single global lock. But as we do not expect contention, that is
>>
On Wed, Oct 12, 2016 at 2:38 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
>> Sigh. DCLP, the Double Checked Locking Pattern. ...
>> I suggest you go without it, then measure, and only *then* optimize if
>> it is a bottleneck.
>
> That comes from me in earlier discussion before the patch, n
Johannes Sixt writes:
> Sigh. DCLP, the Double Checked Locking Pattern. ...
> I suggest you go without it, then measure, and only *then* optimize if
> it is a bottleneck.
That comes from me in earlier discussion before the patch, namely in
, where I wondered if
a cheap check outside the lock ma
Stefan Beller writes:
> On Wed, Oct 12, 2016 at 2:28 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> This version adds the actual thread safety,
>>> that is promised in the documentation, however it doesn't add any
>>> optimization,
>>> i.e. it's a single global lock. But as we do no
On Wed, Oct 12, 2016 at 1:07 PM, Johannes Sixt wrote:
>
> Sigh. DCLP, the Double Checked Locking Pattern. These days, it should be
> common knowledge among professionals that this naïve version _does_not_work_
> [1]!
>
> I suggest you go without it, then measure, and only *then* optimize if it is
Stefan Beller writes:
>>> Well all of the hunks in the patch are not threaded, so they
>>> don't follow a threading pattern, but the static pattern to not be
>>> more expensive than needed.
>>
>> Is it too invasive a change to make them as if they are thread-ready
>> users of API that happen to k
Stefan Beller writes:
> On Wed, Oct 12, 2016 at 2:38 PM, Junio C Hamano wrote:
>> Johannes Sixt writes:
>>
>>> Sigh. DCLP, the Double Checked Locking Pattern. ...
>>> I suggest you go without it, then measure, and only *then* optimize if
>>> it is a bottleneck.
>>
>> That comes from me in earli
Hi all,
I've bisected a performance regression (noticed by Quentin and myself)
which caused a 'git fetch' to go from ~1m30s to ~2m40s:
commit 47bf4b0fc52f3ad5823185a85f5f82325787c84b
Author: Jeff King
Date: Mon Jun 30 13:04:03 2014 -0400
prepare_packed_git_one: refactor duplicate-pack ch
This revamps the API of the attr subsystem to be thread safe.
Before we had the question and its results in one struct type.
The typical usage of the API was
static struct git_attr_check *check;
if (!check)
check = git_attr_check_initl("text", NULL);
git_check_attr(path, chec
Vegard Nossum writes:
> A closer inspection reveals the problem to really be that this is an
> extremely hot path with more than -- holy cow -- 4,106,756,451
> iterations on the 'packed_git' list for a single 'git fetch' on my
> repository. I'm guessing the patch above just made the inner loop
>
On Wed, Oct 12, 2016 at 2:45 PM, Jacob Keller wrote:
> On Wed, Oct 12, 2016 at 1:07 PM, Johannes Sixt wrote:
>>
>> Sigh. DCLP, the Double Checked Locking Pattern. These days, it should be
>> common knowledge among professionals that this naïve version _does_not_work_
>> [1]!
>>
>> I suggest you g
On Thu, Oct 13, 2016 at 12:30:52AM +0200, Vegard Nossum wrote:
> However, the commit found by 'git blame' above appears just fine to me,
> I haven't been able to spot a bug in it.
>
> A closer inspection reveals the problem to really be that this is an
> extremely hot path with more than -- holy
Stefan Beller writes:
>> But many callers do not follow that; rather they do
>>
>> loop to iterate over paths {
>> call a helper func to learn attr X for path
>> use the value of attr X
>> }
>>
>> using a callchain that embeds a helper function deep
On Wed, Oct 12, 2016 at 01:53:52PM -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> >>> If it's not in the body of the message, then where is it?
> >>
> >> This point is clarified in the thread
> >> http://marc.info/?l=linux-wireless&m=147625930203434&w=2, which is
> >> with my upstream m
On Wed, Oct 12, 2016 at 07:01:43PM -0400, Jeff King wrote:
> On Thu, Oct 13, 2016 at 12:30:52AM +0200, Vegard Nossum wrote:
>
> > However, the commit found by 'git blame' above appears just fine to me,
> > I haven't been able to spot a bug in it.
> >
> > A closer inspection reveals the problem t
On Wed, 2016-10-12 at 11:37 -0700, Junio C Hamano wrote:
> > ++test_expect_success '"add" default branch of a bare repo' '
>
> Huh?
Copy paste error. And I missed
ok 17 - checkout from a bare repo without "add"
./t2025-worktree-add.sh: 141: ./t2025-worktree-add.sh: +test_expect_success:
not fou
Stefan Beller writes:
> @@ -89,15 +114,20 @@ static void setup_check(void)
>
>
> const char *path;
> + struct git_attr_result *result;
>
> setup_check();
> - git_check_attr(path, check);
> + result = git_check_attr(path, check);
This looks stale by a few
Currently, creation and addition (to a list) of trailer items are spread
across multiple functions. Streamline this by only having 2 functions:
one to parse the user-supplied string, and one to add the parsed
information to a list.
---
trailer.c | 130 +-
Currently, interpret-trailers requires that a trailer be only on 1 line.
For example:
a: first line
second line
would be interpreted as one trailer line followed by one non-trailer line.
Make interpret-trailers support RFC 822-style folding, treating those
lines as one logical trailer.
--
Change "const char *" to "char *" in struct trailer_item and in the
return value of apply_command (since those strings are owned strings).
Change "struct conf_info *" to "const struct conf_info *" (since that
struct is not modified).
---
trailer.c | 14 +++---
1 file changed, 7 insertions
Thanks, Peff, for the pointer to list.h. Using list.h does simplify the
code by a similar amount to switching it to a singly-linked list, so I
have done that (replacing my earlier "trailer: use singly-linked list,
not doubly" patch). Another advantage is that I no longer need to change
the algorith
Replace the existing handwritten implementation of a doubly-linked list
in trailer.c with the functions and macros from list.h. This
significantly simplifies the code.
---
trailer.c | 258 ++
1 file changed, 91 insertions(+), 167 deletion
Currently, interpret-trailers requires all lines of a trailer block to
be trailers (or comments) - if not it would not identify that block as a
trailer block, and thus create its own trailer block, inserting a blank
line. For example:
echo -e "\na: b\nnot trailer" |
git interpret-trailers --t
Improve type safety by making arguments (whether from configuration or
from the command line) have their own "struct arg_item" type, separate
from the "struct trailer_item" type used to represent the trailers in
the buffer being manipulated.
This change also prepares "struct trailer_item" to be fu
On Wed, Oct 12, 2016 at 07:18:07PM -0400, Jeff King wrote:
> Also, is it possible to make the repository in question available? I
> might be able to reproduce based on your description, but it would save
> time if I could directly run gdb on your example.
I tried this by making a bunch of packs i
Stefan Beller wrote:
> On Wed, Oct 12, 2016 at 7:45 AM, Mathieu Arnold wrote:
>
> > I discovered git worktree earlier this week, and I found it a great
> > asset to be able to have more than one branch of my worktree accessible
> > at the same time...
> >
> > Anyway, back to my problem, the way
On Wed, Oct 12, 2016 at 10:59:46AM -0700, Junio C Hamano wrote:
> Josef Ridky writes:
>
> > This is update of the second variant for request to add option to change
> > suffix of name of temporary files generated by git mergetool. This
> > change is requested for cases, when is git mergetool used
On Thu, Oct 06, 2016 at 08:43:02AM -0400, Josef Ridky wrote:
> This is the first of two variant for request to add option to change
> suffix of name of temporary files generated by git mergetool. This
> change is requested for cases, when is git mergetool used for local
> comparision between two ve
Junio C Hamano writes:
> People write things like these
>
> Cc: Stable # 4.8
> Cc: Stable [4.8+]
>
> in the trailer part in the body of the message. Are these lines
> meant to be usable if they appear as Cc: headers of an outgoing
> piece of e-mail as-is?
I think this is not the right
Jeff King writes:
> 2. Drop everything after the trailing ">". This gives a valid rfc2822
> cc, and people can pick the "# 4.8" from the cc line in the body.
That would work for me, but it's inconsistent with Mail::Address and I'd
really like to avoid having a behavior depending on librar
The test introduced in this commit succeeds without the patch to Git.pm
if Mail::Address is installed, but fails otherwise because our in-house
parser does not accept any text after the email address. They succeed
both with and without Mail::Address after this commit.
Mail::Address accepts extra t
Hello,
thank you for this nice and quick fix of this corner case!
Stepan
98 matches
Mail list logo
