the command line). This setting overrides merge.ff when pulling.
--
View this message in context:
http://git.661346.n2.nabble.com/Use-git-pull-ff-only-by-default-tp5084103p7654696.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "uns
Jiang Xin writes:
> Please pull this update to the maint branch. It should have been merged to
> Git 2.8.0, but I was busy these weeks and forgot to check my private mailbox.
Thanks, will do.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...
Hi Junio,
Please pull this update to the maint branch. It should have been merged to
Git 2.8.0, but I was busy these weeks and forgot to check my private mailbox.
The following changes since commit 26e4cbec4558ea21cd572bfc915a462f63c1ebb4:
l10n: zh_CN: review for git v2.8.0 l10n round 2 (2016
Hi Junio,
The following changes since commit 26e4cbec4558ea21cd572bfc915a462f63c1ebb4:
l10n: zh_CN: review for git v2.8.0 l10n round 2 (2016-03-20 18:46:02 +0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 103ee5c21ea4d63e
Thanks.
On Sun, Mar 20, 2016 at 4:08 AM, Jiang Xin wrote:
> Hi Junio,
>
> The following changes since commit 5c0c220c53823e2a9ebe8e566e649ca30cd7e8e0:
>
> l10n: zh_CN: for git v2.8.0 l10n round 3 (2016-03-16 00:27:40 +0800)
>
> are available in the git repository at:
>
> git://github.com/git-
Hi Junio,
The following changes since commit 5c0c220c53823e2a9ebe8e566e649ca30cd7e8e0:
l10n: zh_CN: for git v2.8.0 l10n round 3 (2016-03-16 00:27:40 +0800)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.8.0-rnd3
for you to fetch changes up to 26e4cbec4
Linus Torvalds writes:
> The code in the recursive merge that allows this to happen is this:
> ...
> And I do think that's right, and I think it's clever, and it goes back to
> 2006:
>
> 934d9a24078e merge-recur: if there is no common ancestor, fake empty one
>
> but I think there should be an
Johannes Schindelin writes:
> Hi Linus,
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
> http://thread.gmane.org/gmane.c
erge the remote tracking branch
into that new project, and we ended up with a silly new root.
"git pull-request" will complain about not having a commit in common,
but "git merge" apparently does not even warn.
Adding Junio and the git list. This seems like much too easy a way
Linus Torvalds writes:
> It's literally just the fact that "git merge" does it with no extra
> flags or checks. I'd like people to have to be aware of what they are
> doing when they merge two different projects, not do it by mistake.
>
> So making it conditional on a flag like "--no-common-root"
On Fri, Mar 18, 2016 at 7:32 AM, Johannes Schindelin
wrote:
>
> On Fri, 18 Mar 2016, Linus Torvalds wrote:
>
>> I thought git didn't merge two branches that have no common base by
>> default, but it seems it will happily do so.
>
> What happened to "The coolest merge EVER!"?
>
> http://thr
On Fri, Mar 18, 2016 at 9:37 AM, Junio C Hamano wrote:
>
>> I don't think the original "resolve" did it, for example. You can't do
>> a three-way merge without a base.
>
> Yes, and that continues to this day:
Yeah, "octopus" also refuses it cleanly:
common=$(git merge-base --all $SHA1 $M
Hi Linus,
On Fri, 18 Mar 2016, Linus Torvalds wrote:
> I thought git didn't merge two branches that have no common base by
> default, but it seems it will happily do so.
What happened to "The coolest merge EVER!"?
http://thread.gmane.org/gmane.comp.version-control.git/5126/
Ciao,
Dscho
On Fri, Mar 4, 2016 at 12:13 AM, Mehul Jain wrote:
> Signed-off-by: Mehul Jain
> ---
> Documentation/git-pull.txt | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index a62a2a6..a593972 100644
> --- a/Documentatio
Mehul Jain writes:
> On Thu, Mar 3, 2016 at 10:44 PM, Junio C Hamano wrote:
>> Should this entry this verbose?
>>
>> - Is there a non-temporary stash?
>>
>> - I think "This means that ..." is totally unnecessary.
>>
>> - It probably makes sense to have "This option is only valid..." as
>>
On Thu, Mar 3, 2016 at 10:44 PM, Junio C Hamano wrote:
> Should this entry this verbose?
>
> - Is there a non-temporary stash?
>
> - I think "This means that ..." is totally unnecessary.
>
> - It probably makes sense to have "This option is only valid..." as
>a separate second paragraph as
Mehul Jain writes:
> Signed-off-by: Mehul Jain
> ---
> Documentation/git-pull.txt | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index a62a2a6..a593972 100644
> --- a/Documentation/git-pull.txt
> +++ b/Document
Signed-off-by: Mehul Jain
---
Documentation/git-pull.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index a62a2a6..a593972 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -128,6 +128,21 @
git pull --rebase understands --[no-]autostash flag.
This flag overrides config variable "rebase.autoStash"
if set (default is false).
When calling "git pull --rebase" with "--autostash",
pull passes the "--autostash" option to rebase,
which then runs
From: "Matthieu Moy"
Hi,
Some minor nits in addition to Paul's comments:
Subject: Re: [GSoC] Microproject :- Teaching git pull --rebase
the --no-autostash flag
The ":-" is typically Indian. Just use ":" here (without a space
before).
I think it was we
HEAD:file)"
>> '
>>
>> +test_expect_success '--rebase --no-autostash fails with dirty working
>> directory' '
>
> Maybe add ..."and rebase.autostash set" to the test name? Describes
> the test better, and is consistent wit
Hi,
Some minor nits in addition to Paul's comments:
> Subject: Re: [GSoC] Microproject :- Teaching git pull --rebase the
> --no-autostash flag
The ":-" is typically Indian. Just use ":" here (without a space
before).
Mehul Jain writes:
> With this patch,
On Fri, Feb 26, 2016 at 7:23 PM, Mehul Jain wrote:
> Subject: [PATCH] Add --no-autostash flag to git pull --rebase
We usually don't capitalize the first word of the commit title. We
also usually prefix the commit title with the relevant subsystem, file
or command. So something lik
On Fri, Feb 26, 2016 at 5:21 PM, Paul Tan wrote:
> That was the point of the microproject ;-). --[no-]autostash means
> both --autostash and --no-autostash.
Oops, my bad. I will add the necessary changes :-).
Thanks,
Mehul
--
To unsubscribe from this list: send the line "unsubscribe git" in
the
On Fri, Feb 26, 2016 at 7:23 PM, Mehul Jain wrote:
> With this patch, git pull --rebase will understand --no-autostash command
> line flag.
> This flag will override "rebase.autostash" configuration(if set) and leads to
> a
> failure if current working directory is di
git pull --rebase now understand --no-autostash flag. If directory is found
to be dirty then command will die. This flag override "rebase.autostash"
configuration(if set). If this flag is not passed in command line then
default behaviour is choosen, given by "rebas
With this patch, git pull --rebase will understand --no-autostash command line
flag.
This flag will override "rebase.autostash" configuration(if set) and leads to a
failure if current working directory is dirty. If "rebase.autostash" is not
configured
and no flag is pa
a "git for-each-ref" after pulling and then check (for
>> each one of those refs) if an update is warranted, but this can get slow
>> with that many branches. Is there some way to get something like the
>> post-receive hook to be run for "git pull", so that th
nch before pushing:
git pull --rebase branch origin branch
Problem is: the pull --rebase will delete the empty commit. I see git
rebase has a --keep-empty option. I cannot find such option for the
pull --rebase operation.
Thanks in advance,
Bastian
--
To unsubscribe from this list: sen
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/majordomo-info.html
Hi Junio,
Ralf completed his work on German l10n for Git 2.7.0, please pull.
The following changes since commit 28274d02c489f4c7e68153056e9061a46f62d7a0:
Git 2.7-rc3 (2015-12-28 14:00:52 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.7.0-rnd2+de
Hi Junio,
The following changes since commit 1d88dab47aaa32d134b9bfe1cda09f1b55528b24:
Update release notes to 2.7 (2015-12-21 11:08:20 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.7.0-rnd2
for you to fetch changes up to 5fa9ab808033c081b69c54
ently, I use a "git for-each-ref" after pulling and then check (for
> each one of those refs) if an update is warranted, but this can get slow
> with that many branches. Is there some way to get something like the
> post-receive hook to be run for "git pull", so that th
and then check (for
each one of those refs) if an update is warranted, but this can get slow
with that many branches. Is there some way to get something like the
post-receive hook to be run for "git pull", so that the script gets told
directly which (remote tracking) branches h
Jiang Xin writes:
> Hi Junio,
>
> Please pull the following into the maint branch. It includes l10n
> updates in Russian which missed the update window for 2.6.
>
> The following changes since commit 8d530c4d64ffcc853889f7b385f554d53db375ed:
>
> Git 2.6-rc3 (2015-09-21 13:26:13 -0700)
>
> are
Hi Junio,
Please pull the following into the maint branch. It includes l10n
updates in Russian which missed the update window for 2.6.
The following changes since commit 8d530c4d64ffcc853889f7b385f554d53db375ed:
Git 2.6-rc3 (2015-09-21 13:26:13 -0700)
are available in the git repository at:
Hi Junio,
On 2015-10-12 22:28, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>>> I think the most sensible regression fix as the first step at this
>>> point is to call it as a separate process, just like the code calls
>>> "apply" as a separate process for each patch. Optimization can
Johannes Schindelin writes:
>> I think the most sensible regression fix as the first step at this
>> point is to call it as a separate process, just like the code calls
>> "apply" as a separate process for each patch. Optimization can come
>> later when it is shown that it matters---we need to r
5 at 8:52 AM, Junio C Hamano wrote:
>>>>> Johannes Schindelin writes:
>>>>>
>>>>>> Brendan Forster noticed that we no longer see the helpful message after
>>>>>> a failed `git pull --rebase`. It turns out that the builtin `am` ca
Hi Junio,
On 2015-10-09 20:55, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> I would prefer the endgame to be an efficient implementation of
> merge_recursive_generic(), a function that you can call without you
> having to worry about it dying.
>
> But the patch in this thread is not that,
Hi Junio,
On 2015-10-09 20:40, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>>> Instead, stepping back a bit, I wonder if we can extend coverage of
>>> the helpful message to all die() calls when running git-am. We could
>>> just install a die routine with set_die_routine() in builtin/am.c.
;>>>
>>>>> Brendan Forster noticed that we no longer see the helpful message after
>>>>> a failed `git pull --rebase`. It turns out that the builtin `am` calls
>>>>> the recursive merge function directly, not via a separate process.
>>&
;>>>
>>>>> Brendan Forster noticed that we no longer see the helpful message after
>>>>> a failed `git pull --rebase`. It turns out that the builtin `am` calls
>>>>> the recursive merge function directly, not via a separate process.
>>&
Johannes Schindelin writes:
> I finally have that test case working, took way longer than I wanted to:
This certainly fails without any fix and passes either with your
two-patch or a more conservative run_command() fix that I sent
separately.
However, this new test (becomes 5520.20) seems to br
Junio C Hamano writes:
> I think the most sensible regression fix as the first step at this
> point is to call it as a separate process, just like the code calls
> "apply" as a separate process for each patch. Optimization can come
> later when it is shown that it matters---we need to regain
> c
Junio C Hamano writes:
> I looked at the codepath involved, and I do not think that is a
> feasible way forward in this case. It is not about a "helpful
> message" at all. You would have to do everything that is done in
> the error codepath in your custom die routine, which does not make
> much
Junio C Hamano writes:
>> Instead, stepping back a bit, I wonder if we can extend coverage of
>> the helpful message to all die() calls when running git-am. We could
>> just install a die routine with set_die_routine() in builtin/am.c.
>> Then, should die() be called anywhere, the helpful error m
Paul Tan writes:
> That said, I do agree that even if we die(), we could try to be more
> helpful by printing additional helpful instructions.
>
>> If that is the case, I'd thinkg that we'd prefer, as a regression
>> fix to correct "that", i.e., let recursive-merge die and let the
>> caller catch
Me again,
On 2015-10-09 11:50, Johannes Schindelin wrote:
>
> On 2015-10-09 03:40, Paul Tan wrote:
>> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
>>> Johannes Schindelin writes:
>>>
>>>> Brendan Forster noticed that we no longer see the hel
Hi Junio & Paul,
On 2015-10-09 03:40, Paul Tan wrote:
> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
>> Johannes Schindelin writes:
>>
>>> Brendan Forster noticed that we no longer see the helpful message after
>>> a failed `git pull --rebase`. It
On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> Brendan Forster noticed that we no longer see the helpful message after
>> a failed `git pull --rebase`. It turns out that the builtin `am` calls
>> the recursive merge function dire
Johannes Schindelin writes:
> Brendan Forster noticed that we no longer see the helpful message after
> a failed `git pull --rebase`. It turns out that the builtin `am` calls
> the recursive merge function directly, not via a separate process.
>
> But that function was not re
Brendan Forster noticed that we no longer see the helpful message after
a failed `git pull --rebase`. It turns out that the builtin `am` calls
the recursive merge function directly, not via a separate process. But
that function was not really safe to be called that way, as it die()s
pretty
Hi Junio,
This pull request fixes typo of commit " l10n: fr.po v1.6.0 round 1 ..."
(should replace 1.6.0 to 2.6.0), and also includes new updates from
Ralf. I also create a signed tag (l10n-2.6.0-rnd2+de) for this.
Would you please pull the following git l10n updates.
The following changes sinc
2015-09-21 0:21 GMT+08:00 Jiang Xin :
> Hi Junio,
>
> Would you please pull the following git l10n updates.
>
> The following changes since commit f4d9753a89bf04011c00e943d85211906e86a0f6:
>
> Update RelNotes to 2.6 to describe leftover bits since -rc2
> (2015-09-14 15:00:41 -0700)
>
> are availa
Hi Junio,
Would you please pull the following git l10n updates.
The following changes since commit f4d9753a89bf04011c00e943d85211906e86a0f6:
Update RelNotes to 2.6 to describe leftover bits since -rc2
(2015-09-14 15:00:41 -0700)
are available in the git repository at:
git://github.com/git-
On Sun, Aug 09, 2015 at 07:42:38PM -0400, Jeff King wrote:
> It looks like the use of a pager is fooling our "should we colorize the
> diff" check when generating the patches. Usually we check isatty(1) to
> see if we should use color, so "git format-patch >patches" does the
> right thing. But if
On Mon, Aug 03, 2015 at 05:21:43PM +0200, Per Cederqvist wrote:
> If you run:
>
> git config pager.pull true
>
> in the hope of getting the output of "git pull" via a pager, you are
> in for a surpise the next time you run "git pull --rebase" and it ha
If you run:
git config pager.pull true
in the hope of getting the output of "git pull" via a pager, you are
in for a surpise the next time you run "git pull --rebase" and it has
to rebase your work. It will fail with a nonsensical error message:
> Applying:
Junio C Hamano writes:
> On Thu, Jul 30, 2015 at 11:31 AM, Joey Hess wrote:
>> I think this comes down to a lack of quoting where git-pull runs
>> git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
>> "$@" was passed through to git-fetch, but now ther
On Thu, Jul 30, 2015 at 11:31 AM, Joey Hess wrote:
> I think this comes down to a lack of quoting where git-pull runs
> git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
> "$@" was passed through to git-fetch, but now there is a $upload_pack
> which is passed with
I think this comes down to a lack of quoting where git-pull runs
git-fetch. Before eb2a8d9ed3fca2ba2f617b704992d483605f3bb6,
"$@" was passed through to git-fetch, but now there is a $upload_pack
which is passed without being quoted.
--
see shy jo
signature.asc
Description: Digital signature
Joey Hess writes:
> In git 2.1.4, I can run: git pull --upload-pack 'echo --foo'
>
> This also seems to work in 2.4.6, but in 2.5.0, the option parser
> does something weird, apparently looking inside the quoted parameter
> and parsing parameters in there:
>
> erro
In git 2.1.4, I can run: git pull --upload-pack 'echo --foo'
This also seems to work in 2.4.6, but in 2.5.0, the option parser
does something weird, apparently looking inside the quoted parameter
and parsing parameters in there:
error: unknown option `foo'
usage: git fetch [] [ [
Hi Junio,
The following changes since commit 961abca02c532626df631c851688ec433095d93d:
Merge tag 'l10n-2.5.0-rnd1' of git://github.com/git-l10n/git-po
(2015-07-13 15:37:24 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.5.0-rnd2
for you to fetch
On Fri, Jun 19, 2015 at 4:13 AM, Junio C Hamano wrote:
> I didn't look carefully, but does that mean 04/19 has the "what if
> you start from a subdirectory and are still using the scripted one?"
> issue we discussed recently for "am"?
It does, but git-pull.sh does not care about the original work
Paul Tan writes:
> This is a re-roll of [v3]. It squashes in Ramsay's patch "fix some sparse
> warnings", and fixes the use-before-free reported by Duy. Thanks a lot for
> dealing with my mess :-).
>
> Other than that, there are no other changes as I'm working on the git-am side
> of things.
I d
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cle
versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/269258
[v2] http://thread.gmane.org/gmane.comp.version-control.git/270639
[v3] http://thread.gmane.org/gmane.comp.version-control.git/271614
git-pull is a commonly executed command to check for new changes in the
upstream reposito
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/majordomo-info.html
The following changes since commit 9eabf5b536662000f79978c4d1b6e4eff5c8d785:
Git 2.4.2 (2015-05-26 13:49:59 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.4-maint-de-updates
for you to fetch changes up to a9845c5f504498644abcb5f6fd6adc2ffd076f2b:
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cle
This is a re-roll of [v2]. Thanks Junio, Stefan for the reviews last round.
Previous versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/269258
[v2] http://thread.gmane.org/gmane.comp.version-control.git/270639
git-pull is a commonly executed command to check for new changes
Paul Tan writes:
> +/**
> + * Returns remote's upstream branch for the current branch. If remote is
> NULL,
> + * the current branch's configured default remote is used. Returns NULL if
> + * `remote` does not name a valid remote, HEAD does not point to a branch,
> + * remote is not the branch's
Paul Tan writes:
> so it's more or less a direct translation of the shell script, and we
> can be sure it will have the same behavior. I'm definitely in favor of
> switching this to use remote_find_tracking(), the question is whether
> we want to do it in this patch or in a future patch on top.
On Wed, Jun 10, 2015 at 10:44 PM, Junio C Hamano wrote:
> Paul Tan writes:
>
>>> Hmph, it is somewhat surprising that we do not have such a helper
>>> already. Wouldn't we need this logic to implement $branch@{upstream}
>>> syntax?
>>
>> Right, the @{upstream} syntax is implemented by branch_get_
Paul Tan writes:
>> Hmph, it is somewhat surprising that we do not have such a helper
>> already. Wouldn't we need this logic to implement $branch@{upstream}
>> syntax?
>
> Right, the @{upstream} syntax is implemented by branch_get_upstream()
> in remote.c. It, however, does not check to see if t
On Wed, Jun 10, 2015 at 9:56 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> +enum rebase_type {
>> + REBASE_INVALID = -1,
>> + REBASE_FALSE = 0,
>> + REBASE_TRUE,
>> + REBASE_PRESERVE
>> +};
>> +
>> +/**
>> + * Parses the value of --rebase, branch.*.rebase or pull.rebase. If va
Paul Tan writes:
> +enum rebase_type {
> + REBASE_INVALID = -1,
> + REBASE_FALSE = 0,
> + REBASE_TRUE,
> + REBASE_PRESERVE
> +};
> +
> +/**
> + * Parses the value of --rebase, branch.*.rebase or pull.rebase. If value is
> a
> + * false value, returns REBASE_FALSE. If value is a t
Since cd67e4d (Teach 'git pull' about --rebase, 2007-11-28), if the
--rebase option is set, git-rebase is run instead of git-merge.
Re-implement this by introducing run_rebase(), which is called instead
of run_merge() if opt_rebase is a true value.
Since c85c792 (pull --rebase: be cle
This is a re-roll of [v1]. Thanks Johannes, Stefan and Junio for the reviews
last round.
Previous versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/269258
git-pull is a commonly executed command to check for new changes in the
upstream repository and, if there are, fetch and
k point calculation, I do agree that we
> should probably give an warning() here as well if the user provided
> more than one refspec, like "Cannot calculate rebase fork point as you
> provided more than one refspec. git-pull will not be able to handle a
> rebased upstream".
eed to consider if the user provided a wildcard
refspec, as it will not make sense in this case. From my reading,
remote_find_tracking(), which calls query_refspecs(), would just match
the src part literally, so I guess we should explicitly detect and
error out in this case.
> return
.sh in SCRIPT_SH in the Makefile will generate 2
> targets to ./git-pull (they will clobber each other). For GNU Make,
> the last defined target will win, so in this case it just happens that
> git-pull.sh will win because the build targets for the shell scripts
> are defined after the
Hi,
On Tue, May 19, 2015 at 3:21 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> This series rewrites git-pull.sh into a C builtin, thus improving its
>> performance and portability. It is part of my GSoC project to rewrite
>> git-pull
>> and git-am into bui
Paul Tan writes:
> This is a re-roll of [1].
>
> This patch series improves test coverage of git-pull.sh, and is part of my
> GSoC project to rewrite git-pull into a builtin. Improving test coverage
> helps to prevent regressions that could occur due to the rewrite.
>
> T
This is a re-roll of [1].
This patch series improves test coverage of git-pull.sh, and is part of my
GSoC project to rewrite git-pull into a builtin. Improving test coverage
helps to prevent regressions that could occur due to the rewrite.
Thanks Junio, Johannes and Stefan for the reviews last
Hi Paul,
I already commented on patches 1-10, and I will look in depth at 11-14 tomorrow.
It is a very pleasant read so far. Thank you.
Ciao,
Dscho
P.S.: I have the feeling about patch 12 that reading `opt_rebase` from the
config could be delayed until after we know that the user did not speci
This series directly depends on the changes made in jc/merge and
pt/pull-tests. The commit messages assume that the behavioral changes
proposed in pt/pull-log-n, pt/pull-tags-error-diag, pt/pull-ff-vs-merge-ff,
and [1] have been introduced.
git-pull is a commonly executed command to check for new
This is a re-roll of [1]. This series depends on jc/merge.
This patch series improves test coverage of git-pull.sh, and is part of my
GSoC project to rewrite git-pull into a builtin. Improving test coverage
helps to prevent regressions that could occur due to the rewrite.
This re-roll includes
Hi Junio,
On Fri, May 8, 2015 at 4:15 AM, Junio C Hamano wrote:
> I do not think touching this test which does not have anything to do
> with "git pull" in your series is sensible at all, and you shouldn't
> flip test_expect_success temporarily to _expect_failure, if th
Since "git fetch ." does not update any refs, "git pull . side" is
equivalent to calling "git merge side".
As such, replace the call to git-pull with a call to git-merge to reduce
the dependence on git-pull's functionality to reduce irrelevant test
break
Hi Junio,
On 2015-04-20 21:28, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> This is primarily note-to-self; even though I haven't got around
>> bisecting yet, I think I know I did some bad change myself.
>>
>> "git pull $URL $tag" seems t
Junio C Hamano writes:
> This is primarily note-to-self; even though I haven't got around
> bisecting yet, I think I know I did some bad change myself.
>
> "git pull $URL $tag" seems to:
>
> * fail to invoke the editor without "--edit".
> * show th
t; >;;
>> > esac
>> > eval "exec $eval"
>> >
>> > as we seem to special-case the name FETCH_HEAD. It assumes that
>> > git-merge's parsing of FETCH_HEAD is the same as what we do in git-pull,
>> > but that seems safe.
>>
> >
> > as we seem to special-case the name FETCH_HEAD. It assumes that
> > git-merge's parsing of FETCH_HEAD is the same as what we do in git-pull,
> > but that seems safe.
>
> Unfortunately, "git merge"'s parsing of FETCH_HEAD forgets that we
>
s"
> - eval="$eval -m \"\$merge_name\" $merge_head"
> + eval="$eval FETCH_HEAD"
> ;;
> esac
> eval "exec $eval"
>
> as we seem to special-case the name FETCH_HEAD. It assumes that
> git-merge's parsing of
val FETCH_HEAD"
> > ;;
> > esac
> > eval "exec $eval"
> >
> > as we seem to special-case the name FETCH_HEAD. It assumes that
> > git-merge's parsing of FETCH_HEAD is the same as what we do in git-pull,
> > but that seems safe. Unfortuna
"$eval FETCH_HEAD"
> ;;
> esac
> eval "exec $eval"
>
> as we seem to special-case the name FETCH_HEAD. It assumes that
> git-merge's parsing of FETCH_HEAD is the same as what we do in git-pull,
> but that seems safe. Unfortunately we still have
On Sat, Apr 18, 2015 at 06:39:20PM -0700, Junio C Hamano wrote:
> This is primarily note-to-self; even though I haven't got around
> bisecting yet, I think I know I did some bad change myself.
>
> "git pull $URL $tag" seems to:
>
> * fail to invoke the edito
201 - 300 of 584 matches
Mail list logo
