On Sun, Jul 5, 2015 at 11:58 PM, Johannes Schindelin
wrote:
> On 2015-07-02 20:16, Paul Tan wrote:
>
>> diff --git a/t/t4150-am.sh b/t/t4150-am.sh
>> index dd6fe81..62b678c 100755
>> --- a/t/t4150-am.sh
>> +++ b/t/t4150-am.sh
>> @@ -275,6 +275,48 @@ test_expect_success 'am with failing pre-applypa
On 2015-07-06 21.25, Joey Hess wrote:
> joey@darkstar:~/tmp>git init --shared=world testrepo
> Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
> joey@darkstar:~/tmp>grep shared testrepo/.git/config
> sharedrepository = 2
>
> This magic value of 2 seems to be undocum
Hi,
Please let me know whether Git supports directory level access or not.
For example :- Consider the structure with one repository consisting of
sub directories for each product.
main_repo:
dir1 dir
dir2 dir
shared-dir dir
private dir
One group(user) of developers has access to d
On Sun, Jul 5, 2015 at 11:38 PM, Johannes Schindelin
wrote:
> On 2015-07-02 20:16, Paul Tan wrote:
>
>> diff --git a/t/t4150-am.sh b/t/t4150-am.sh
>> index 3f54bdf..0a19136 100755
>> --- a/t/t4150-am.sh
>> +++ b/t/t4150-am.sh
>> @@ -154,6 +154,17 @@ test_expect_success 'am applies patch correctly'
Today I learned that git push will silently try to recreate a remote
funny ref if you push to it.
"Hypothetically" ... lets say I have a reimplementation of Git called JGit.
Lets say its on a server somewhere on the network.
Lets say its a bit more liberal in what it accepts...
$ git push origin
Translate 65 new messages came from git.pot update in
64f23b0 (l10n: git.pot: v2.5.0 round 1 (65 new, 15 removed))".
Signed-off-by: Ralf Thielow
---
po/de.po | 192 ---
1 file changed, 98 insertions(+), 94 deletions(-)
diff --git a/po/
On Mon, Jul 06, 2015 at 01:39:47PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > rebase learned to stash changes when it encounters a dirty work tree, but
> > git pull --rebase does not.
> >
> > Only verify if the working tree is dirty when rebase.autostash is not
> > enabled.
> >
> >
On Mon, Jul 6, 2015 at 7:20 PM, Daniel Barkalow
wrote:
> On Mon, 6 Jul 2015, Junio C Hamano wrote:
>
>> Jacob Keller writes:
>>
>> > I've been looking at the refspecs for git fetch, and noticed that
>> > globs are partially supported. I wanted to use something like:
>> >
>> > refs/tags/some-prefi
On Mon, 6 Jul 2015, Junio C Hamano wrote:
> Jacob Keller writes:
>
> > I've been looking at the refspecs for git fetch, and noticed that
> > globs are partially supported. I wanted to use something like:
> >
> > refs/tags/some-prefix-*:refs/tags/some-prefix-*
> >
> > as a refspec, so that I can
On Mon, Jul 06, 2015 at 12:19:14PM -0700, Junio C Hamano wrote:
> Eric Sunshine writes:
> > diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> > index 377ae0f..da71f50 100644
> > --- a/Documentation/git-worktree.txt
> > +++ b/Documentation/git-worktree.txt
> > @@ -9,7 +
On Sun, Jul 5, 2015 at 5:30 AM, Junio C Hamano wrote:
> When c6458e60 (index-pack: kill union delta_base to save memory,
> 2015-04-18) attempted to reduce the memory footprint of index-pack,
> one of the key thing it did was to keep track of ref-deltas and
> ofs-deltas separately.
>
> In fix_unres
On Mon, Jul 6, 2015 at 4:01 PM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> What is the reason for not allowing slightly more arbitrary
>> expressions? Obviously no more than one *...
>
> I cannot seem to be able to find related discussions around that
> patch, so this is only my guess, but
Junio C Hamano writes:
> When c6458e60 (index-pack: kill union delta_base to save memory,
> 2015-04-18) attempted to reduce the memory footprint of index-pack,
> one of the key thing it did was to keep track of ref-deltas and
> ofs-deltas separately.
>
> In fix_unresolved_deltas(), however it for
On Tue, Jul 7, 2015 at 3:10 AM, René Scharfe wrote:
> Am 06.07.2015 um 14:42 schrieb Nguyễn Thái Ngọc Duy:
>>
>> Noticed-by: Plamen Totev
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> grep.c | 14 +++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/grep.c
Jacob Keller writes:
> I've been looking at the refspecs for git fetch, and noticed that
> globs are partially supported. I wanted to use something like:
>
> refs/tags/some-prefix-*:refs/tags/some-prefix-*
>
> as a refspec, so that I can fetch only tags which have a specific
> prefix. I know that
Mike Hommey writes:
> One of the first things parse_from does is unconditionally throw away
> the tree for the given branch, and then the "from" tree is loaded. So
> when the "from" commit is the current head of the branch, that make
> fast-import do more work than necessary.
If it is very commo
Hi,
I did something "stupid" with a script using fast-import, and that made
the whole process ~20% slower on Linux and 400~500% slower on Mac. The
reason this happened is that the script was essentially adding a "from"
to every "commit" command, even when the "from" commit is the current
head of t
joey@darkstar:~/tmp>git init --shared=world testrepo
Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
joey@darkstar:~/tmp>grep shared testrepo/.git/config
sharedrepository = 2
This magic value of 2 seems to be undocumented, as is the magic value of 1
that's equvila
This is almost identical to v5. I turned git_path(var) into
git_path("%s", var) as Junio noticed, but I still prefer my version on
the other points discussed.
Guillaume Pagès (4):
status: factor two rebase-related messages together
status: differentiate interactive from non-interactive rebases
From: Guillaume Pagès
git status gives more information during rebase -i, about the list of
command that are done during the rebase. It displays the two last
commands executed and the two next lines to be executed. It also gives
hints to find the whole files in .git directory.
Signed-off-by: Gui
From: Guillaume Pagès
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
t/t7512-status-help.sh | 28 ++--
wt-status.c| 5 -
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/t/t7512-status-help.
From: Guillaume Pagès
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
wt-status.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index eaed4fe..8c4b806 100644
--- a/w
From: Guillaume Pagès
Expand test coverage with one or more than two commands done
and with zero, one or more than two commands remaining.
Signed-off-by: Guillaume Pagès
Signed-off-by: Junio C Hamano
Signed-off-by: Matthieu Moy
---
t/t7512-status-help.sh | 87
Johannes Schindelin writes:
> On 2015-07-03 18:24, Stefan Beller wrote:
>> On Thu, Jul 2, 2015 at 11:16 AM, Paul Tan wrote:
>>> Increase test coverage of git-am.sh to help prevent regressions
>>> that could arise
>>> from the rewrite of git-am.sh to C. This patch series, along with
>>> pt/am-for
Kevin Daudt writes:
> rebase learned to stash changes when it encounters a dirty work tree, but
> git pull --rebase does not.
>
> Only verify if the working tree is dirty when rebase.autostash is not
> enabled.
>
> Signed-off-by: Kevin Daudt
> Helped-by: Paul Tan
> ---
I applied it, tried to r
Am 06.07.2015 um 14:42 schrieb Nguyễn Thái Ngọc Duy:
Noticed-by: Plamen Totev
Signed-off-by: Nguyễn Thái Ngọc Duy
---
grep.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/grep.c b/grep.c
index b58c7c6..48db15a 100644
--- a/grep.c
+++ b/grep.c
@@ -378,7 +
On Mon, Jul 6, 2015 at 9:39 PM, Eric Sunshine wrote:
> On Mon, Jul 06, 2015 at 10:54:28AM -0700, Junio C Hamano wrote:
>> Eric Sunshine writes:
>> > How about this instead: prefixing with "As originally implemented",
>> > with a couple s/is/was/ thrown in...
>> >
>> > As originally implemente
On 16.06.2015 03:17, Eric Raible wrote:
> So naturally I want to check each of them for correctness.
Sorry for joining this thread so late, I only come to know about it from the
draft of the upcoming Git Rev News 5 [1].
A while ago Robin Green was asking a very similar question on StackOverflow
Eric Sunshine writes:
> Now that "git worktree add" has achieved user-facing feature-parity with
> "git checkout --to", retire the latter.
>
> Move the actual linked worktree creation functionality,
> prepare_linked_checkout() and its helpers, verbatim from checkout.c to
> worktree.c.
>
> This ef
On Mon, Jul 06, 2015 at 10:54:28AM -0700, Junio C Hamano wrote:
> Eric Sunshine writes:
> > How about this instead: prefixing with "As originally implemented",
> > with a couple s/is/was/ thrown in...
> >
> > As originally implemented, creation of linked-worktrees was
> > accomplished via
Eric Sunshine writes:
> As a safeguard, checking out a branch already checked out by a different
> worktree is disallowed. This behavior can be overridden with
> --ignore-other-worktrees, however, this option is neither obvious nor
> particularly discoverable. As a common safeguard override, --fo
Eric Sunshine writes:
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> index 377ae0f..da71f50 100644
> --- a/Documentation/git-worktree.txt
> +++ b/Documentation/git-worktree.txt
> @@ -9,7 +9,7 @@ git-worktree - Manage multiple worktrees
> SYNOPSIS
>
>
Eric Sunshine writes:
> As a convenience, like "git branch" and "git checkout -b", make
> "git worktree add -b " default to HEAD when
> is omitted.
>
> Signed-off-by: Eric Sunshine
> ---
> Documentation/git-worktree.txt | 1 +
> builtin/worktree.c | 6 --
> t/t2025-worktree-a
Evgen Druzhynin writes:
This space is for you to explain why it is a good idea to do this
change. What problem does it solve, how often does that problem
appear, what other workarounds exist if any and why they are not
satisfactory, etc, etc?
> ---
Above this line, we would want you to sign-of
Hi,
I've been looking at the refspecs for git fetch, and noticed that
globs are partially supported. I wanted to use something like:
refs/tags/some-prefix-*:refs/tags/some-prefix-*
as a refspec, so that I can fetch only tags which have a specific
prefix. I know that I could use namespaces to sep
Junio C Hamano writes:
> By clarifying that "sender SHOULD terminate with LF, receiver MUST
> NOT require it" is the rule (and fixing the existing implementations
> at places where they violate the "MUST NOT" part, which I think are
> very small number of places), I think we can drop these LF (or
On Mon, Jul 6, 2015 at 2:06 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
>>> Dave Borowitz writes:
>>>
Another way of looking at the problem with my assumptions is, I was
assuming "pkt-line framing" was the same thing as
Dave Borowitz writes:
> On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
>> Dave Borowitz writes:
>>
>>> Another way of looking at the problem with my assumptions is, I was
>>> assuming "pkt-line framing" was the same thing as "pkt-line header".
>>> You seem to be saying the definition of
Dave Borowitz writes:
>> That existing implementations of the receivers treat an empty packet
>> (i.e. "0004")
>
> or "0005\n" ;)
Is that true? I think
len = pkt_line();
if (!len)
break; /* flush */
would give you len == 1 and would not confuse it with a flush.
Eric Sunshine writes:
> How about this instead: prefixing with "As originally implemented",
> with a couple s/is/was/ thrown in...
>
> As originally implemented, creation of linked-worktrees was
> accomplished via `git checkout --to `, and cleanup
> of leftover administrative files,
Paul Tan writes:
> +test_expect_success 'am with applypatch-msg hook' '
> + test_when_finished "rm -f .git/hooks/applypatch-msg" &&
> + rm -fr .git/rebase-apply &&
> + git reset --hard &&
> + git checkout first &&
> + mkdir -p .git/hooks &&
> + cat >.git/hooks/applypatch-m
On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> Another way of looking at the problem with my assumptions is, I was
>> assuming "pkt-line framing" was the same thing as "pkt-line header".
>> You seem to be saying the definition of "pkt-line framing" is "header,
Thanks, both.
--
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
On Mon, Jul 6, 2015 at 1:30 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> I think I understand the confusion now. I think you and I are working
>> from different assumptions about the client behavior.
>
> I agree that we now both understand where we come from ;-)
>
> And sorry for not be
Relocate submodule warning to BUGS and enumerate missing commands.
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.txt | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 3d2889
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 0385e9a..6afff1e 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-wo
Dave Borowitz writes:
> Another way of looking at the problem with my assumptions is, I was
> assuming "pkt-line framing" was the same thing as "pkt-line header".
> You seem to be saying the definition of "pkt-line framing" is "header,
> and optional trailing newline".
Yes. I thought that was w
This was missed when "git prune --worktrees" became "git worktree prune".
Signed-off-by: Eric Sunshine
---
Documentation/git-checkout.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 72def5b..ce223e6 100
Due to the (current) absence of a "git worktree lock" command, locking
a worktree's administrative files to prevent automatic pruning is a
manual task, necessarily requiring low-level understanding of linked
worktree functionality. However, this level of detail does not belong
in the high-level DES
The DESCRIPTION section should provide a high-level overview of linked
worktree functionality to bring users up to speed quickly, without
overloading them with low-level details, so relocate the technical
information to a new DETAILS section.
Signed-off-by: Eric Sunshine
---
Documentation/git-wo
git-worktree options affect some worktree commands but not others, but
this is not necessarily obvious from the option descriptions. Make this
clear by indicating explicitly which commands are affected by which
options.
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.txt | 6 +++---
The only references to 'new' were folded out by the last two patches.
Signed-off-by: Eric Sunshine
---
builtin/checkout.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 162c822..134b6d6 100644
--- a/builtin/checkout.c
+++ b/
prepare_linked_checkout() respects git-checkout's --quiet flag, however,
the plan is to relocate "git checkout --to" functionality to "git
worktree add", and git-worktree does not (yet) have a --quiet flag.
Consequently, make prepare_linked_checkout() unconditionally verbose to
ease eventual code m
With the introduction of "git worktree add", "git checkout --to" is
slated for removal. Therefore, retrofit linked worktree creation tests
to use "git worktree add" instead.
(The test to check exclusivity of "checkout --to" and "checkout "
is dropped altogether since it becomes meaningless with re
The plan is to relocate "git checkout --to" functionality to "git
worktree add", however, worktree.c won't have access to the 'struct
checkout_opts' passed to prepare_linked_worktree(), which it consults
for the pathname of the new worktree and the argv[] of the command it
should run to populate th
A subsequent patch will also need to compute the basename of the new
worktree, so factor out this logic into a new function.
Signed-off-by: Eric Sunshine
---
builtin/worktree.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/builtin/worktree.c b
Now that "git worktree add" has achieved user-facing feature-parity with
"git checkout --to", retire the latter.
Move the actual linked worktree creation functionality,
prepare_linked_checkout() and its helpers, verbatim from checkout.c to
worktree.c.
This effectively reverts changes to checkout.
In order to allow linked worktree creation via "git checkout --to" from
a bare repository, 3473ad0 (checkout: don't require a work tree when
checking out into a new one, 2014-11-30) dropped git-checkout's
unconditional NEED_WORK_TREE requirement and instead performed worktree
setup conditionally ba
Given "git checkout --to HEAD~1", the new worktree's HEAD should
begin life at the current branch's HEAD~1, however, it actually ends up
at HEAD~2. This happens because:
1. git-checkout resolves HEAD~1
2. to satisfy is_git_directory(), prepare_linked_worktree() creates
a HEAD for
The plan is to relocate "git checkout --to" functionality to "git
worktree add", however, this check expects a 'struct branch_info' which
git-worktree won't have at hand. It will, however, have access to its
own command-line from which it can pick up the branch name. Therefore,
as a preparatory ste
As a safeguard, checking out a branch already checked out by a different
worktree is disallowed. This behavior can be overridden with
--ignore-other-worktrees, however, this option is neither obvious nor
particularly discoverable. As a common safeguard override, --force is
more likely to come to mi
As a convenience, when is omitted from "git worktree
" and neither -b nor -B is used, automatically create a new
branch named after , as if "-b $(basename )" was specified.
Thus, "git worktree add ../hotfix" creates a new branch named "hotfix"
and associates it with new worktree "../hotfix".
Sig
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add -b/-B options to create a new
branch and check it out in the new worktree.
(For brevity, only -b is mentioned in the
Now that the git-worktree command exists, its documentation page is the
natural place for the linked worktree description to reside. Relocate
the "MULTIPLE WORKING TREES" description verbatim from git-checkout.txt
to git-worktree.txt.
Signed-off-by: Eric Sunshine
---
Documentation/git-checkout.t
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add a --detach option to detach HEAD
in the new worktree.
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.
This is v3 of the series to replace "git checkout --to" with "git
worktree add". It's built atop Duy's df0b6cf (worktree: new place for
"git prune --worktrees", 2015-06-29). Thanks to Duy for his review
of v2[*1*].
A v2 to v3 interdiff is included below for ease of review.
Changes since v2:
* re
The plan is to relocate "git checkout --to" functionality to "git
worktree add". As a first step, introduce a bare-bones git-worktree
"add" command along with documentation. At this stage, "git worktree
add" merely invokes "git checkout --to" behind the scenes, but an
upcoming patch will move the a
By default, "git worktree add" refuses to create a new worktree when
the requested branch is already checked out elsewhere. Add a --force
option to override this safeguard.
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.txt | 8 +++-
builtin/worktree.c | 6 +-
2
As a convenience, like "git branch" and "git checkout -b", make
"git worktree add -b " default to HEAD when
is omitted.
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.txt | 1 +
builtin/worktree.c | 6 --
t/t2025-worktree-add.sh| 5 +
3 files changed,
Dave Borowitz writes:
> I think I understand the confusion now. I think you and I are working
> from different assumptions about the client behavior.
I agree that we now both understand where we come from ;-)
And sorry for not being clear when I did the "push-cert" originally
in the documentati
On Mon, Jul 6, 2015 at 12:38 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> I'm not familiar with the criteria for deciding what merits mention
>> in the newsletter. Is the recent introduction of git-worktree and the
>> attendant relocation of "add" and "prune" functionality worthy? If
>> s
On Mon, Jul 6, 2015 at 1:11 PM, Dave Borowitz wrote:
> On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano wrote:
>> Dave Borowitz writes:
>>
>>> The server can munge pkt-lines and reinsert LFs, but it _must_ have
>>> some way of reconstructing the payload that the client signed in order
>>> to veri
---
builtin/apply.c | 16 +---
po/bg.po| 15 ---
po/ca.po| 15 ---
po/de.po| 15 ---
po/fr.po| 15 ---
po/git.pot | 11 ---
po/it.po| 11 ---
po/pt_PT.po | 7 ---
po/ru
git-apply fails if '-p' option truncate at least one filename in patch to zero
size.
This solution tries to bring closer "git-apply" to standard Linux patch tool.
Standard patch tool skip the truncated filenames and successfully applies patch.
Evgen Druzhynin (1):
Added ability to scip patch hu
On Mon, Jul 6, 2015 at 12:57 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>> The server can munge pkt-lines and reinsert LFs, but it _must_ have
>> some way of reconstructing the payload that the client signed in order
>> to verify the signature. If we just naively insert LFs where missing
Clemens Buchacher writes:
> On Fri, Jul 03, 2015 at 10:52:32AM -0700, Junio C Hamano wrote:
>> >
>> > Cc: Andrew Wong
>> > Signed-off-by: Clemens Buchacher
>> > Reviewed-by: Jorge Nunes
>>
>> Where was this review made? I may have missed a recent discussion,
>> and that is why I am asking, b
Dave Borowitz writes:
> The server can munge pkt-lines and reinsert LFs, but it _must_ have
> some way of reconstructing the payload that the client signed in order
> to verify the signature. If we just naively insert LFs where missing,
> we lose the ability to verify the signature.
I still do n
On 06/29/2015 10:17 PM, David Turner wrote:
> These are necessary because alternate ref backends might store reflogs
> somewhere other than .git/logs. Code that now directly manipulates
> .git/logs should instead go through git-reflog.
>
> In a moment, we will use these functions to make git stas
On Mon, Jul 6, 2015 at 12:28 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> push cert format is like commit or tag format. You need those LFs. We
>> can't just go declare them optional because of the way pkt-line read
>> function is implemented in git-core.
>
> As I said, I view each of th
Eric Sunshine writes:
> I'm not familiar with the criteria for deciding what merits mention
> in the newsletter. Is the recent introduction of git-worktree and the
> attendant relocation of "add" and "prune" functionality worthy? If
> so, perhaps the following write-up would be suitable?
One iss
[ Please, don't top-post on this list ]
Andrey Hsiao writes:
> It was a bit sad since we use scripts to do the merge, then we can
> check the conflict list in the log message, and assign to separate
> owners to resolve them.
>
> Would it be possible to make it as an config option?
If a script i
Shawn Pearce writes:
> push cert format is like commit or tag format. You need those LFs. We
> can't just go declare them optional because of the way pkt-line read
> function is implemented in git-core.
As I said, I view each of the packets between "push-cert" and
"push-cert-end" packets represe
Shawn Pearce writes:
> push cert format is like commit or tag format. You need those LFs. We
> can't just go declare them optional because of the way pkt-line read
> function is implemented in git-core.
As I said, I view each of the packets between "push-cert" and
"push-cert-end" packets represe
On 06/29/2015 10:17 PM, David Turner wrote:
> The safe_create_reflog function creates a reflog, if it does not
> already exist.
>
> The log_ref_setup function becomes private and gains a force_create
> parameter to force the creation of a reflog even if log_all_ref_updates
> is false or the refnam
It was a bit sad since we use scripts to do the merge, then we can
check the conflict list in the log message, and assign to separate
owners to resolve them.
Would it be possible to make it as an config option?
On Tue, Jul 7, 2015 at 12:08 AM, Matthieu Moy
wrote:
> Andrey Hsiao writes:
>
>> Dea
Dave Borowitz writes:
> Unfortunately, optional LFs still make the stored certs for later
> auditing and parsing a bit illegible. This is one way in which push
> certs are fundamentally different from the rest of the wire protocol,
> which is not intended to be persisted.
Hmm, I am not sure I fo
Andrey Hsiao writes:
> Dear list:
>
> In the past, when we do the merge in git, if conflicts occurred,
> when we commit, the conflict list will be appended to
> the default commit message automatically.
>
> eg:
> Conflicts:
> a.java
> b.java
>
> Today, after using Git 2.3.0 for a merge,
On 06/29/2015 10:17 PM, David Turner wrote:
> Instead of directly writing to and reading from files in
> $GIT_DIR, use ref API to interact with CHERRY_PICK_HEAD
> and REVERT_HEAD.
>
> Signed-off-by: David Turner
> ---
> branch.c | 4 ++--
> builtin/commit.c
On 06/29/2015 10:17 PM, David Turner wrote:
> Add an err argument to log_ref_setup that can explain the reason
> for a failure. This then eliminates the need to manage errno through
> this function since we can just add strerror(errno) to the err string
> when meaningful. No callers relied on errno
Dear list:
In the past, when we do the merge in git, if conflicts occurred,
when we commit, the conflict list will be appended to
the default commit message automatically.
eg:
Conflicts:
a.java
b.java
Today, after using Git 2.3.0 for a merge, it seems now the conflict list
was comment
On Wed, Jul 1, 2015 at 1:49 PM, Junio C Hamano wrote:
> Dave Borowitz writes:
>
>>> I am moderately negative about this; wouldn't it make the end result
>>> cleaner to fix the implementation?
>>
>> I'm not sure I understand your suggestion. Are you saying, you would
>> prefer to make LFs optional
Dear list:
In the past, when we do the merge in git, if conflicts occurred, when
we commit, the conflict list will be appended to the default commit
message automatically.
eg:
Conflicts:
a.java
b.java
Today, after using Git 2.3.0 for a merge, it seems now the conflict
list was commented
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
> The alternatives for someone writing a parser are:
> a. Store the original pkt-line framing.
Or obviously, a2. Frame in some other way, e.g. JSON array of strings
(complete straw man, not seriously proposing this).
--
To unsubscribe from thi
On Mon, Jul 6, 2015 at 11:27 AM, Dave Borowitz wrote:
> On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
>> b. Write a parser in some other clever way, e.g. parsing the entire
>> cert in reverse might work.
>
> ...as long as " " is illegal in nonce and pushee values, which it may
> be but is
On Mon, Jul 6, 2015 at 11:22 AM, Dave Borowitz wrote:
> b. Write a parser in some other clever way, e.g. parsing the entire
> cert in reverse might work.
...as long as " " is illegal in nonce and pushee values, which it may
be but is not explicitly documented. I still have no desire to write
such
On Mon, Jul 6, 2015 at 10:46 AM, Dave Borowitz wrote:
> On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano wrote:
>>
>> Dave Borowitz writes:
>>
>> >> I am moderately negative about this; wouldn't it make the end result
>> >> cleaner to fix the implementation?
>> >
>> > I'm not sure I understand you
On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano wrote:
>
> Dave Borowitz writes:
>
> >> I am moderately negative about this; wouldn't it make the end result
> >> cleaner to fix the implementation?
> >
> > I'm not sure I understand your suggestion. Are you saying, you would
> > prefer to make LFs o
Noticed-by: Plamen Totev
Signed-off-by: Nguyễn Thái Ngọc Duy
---
grep.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/grep.c b/grep.c
index b58c7c6..48db15a 100644
--- a/grep.c
+++ b/grep.c
@@ -378,7 +378,7 @@ static void free_pcre_regexp(struct grep_pat *p)
On Mon, Jul 6, 2015 at 6:28 PM, Plamen Totev wrote:
> Hello,
>
> It looks like the git grep command does not support multi-byte character sets
> like UTF-8. As a result some of the grep functionality is not working. For
> example if you search for non Latin words the ignore case flag does not ha
Hi,
>This message is the title of a listing of git commands, that are
>available from $PATH but not located in git's exec path.
>
>Vorhandene Git-Kommandos in '/usr/libexec/git-core'
>
> add merge-octopus
>...
>
>Vorhandene Git-Kommandos irgendwo in Ihrem $PATH
>
> imerge
1 - 100 of 103 matches
Mail list logo
