Denton Liu writes:
> @@ -139,7 +139,9 @@ thing no matter the case.
>'{caret}0' means the commit itself and is used when '' is the
>object name of a tag object that refers to a commit object.
>
> -'{tilde}', e.g. 'master{tilde}3'::
> +'{tilde}[]', e.g. 'HEAD~, master{tilde}3'::
Why does
Denton Liu writes:
> After merging 'dl/no-extern-in-func-decl' into 'pu', it seems like the
> conflict resolution mostly went well except for one spot, which this
> patch should fix.
I do not think this is a mismerge per-se.
That line is not touched since this February at 7589e636 ("Merge
branc
Jeff King writes:
> The merge of jk/fetch-reachability-error-fix conflicts with
> jt/test-protocol-version, but the conflict resolution done by
> b4ce8375c018 has a typo (looks like an editor mistake):
> ...
Indeed it was. Thanks for spotting.
> The same problem is present in the merges to pu,
In revisions.txt, the '^' form is mentioned but the '~' form
is missing. Although both forms are essentially equivalent (they each
get the first parent of the specified revision), we should mention the
latter for completeness. Make this change.
While we're at it, the brief form of '^' makes it see
Eric Sunshine writes:
> On Sun, Apr 21, 2019 at 9:19 AM Junio C Hamano wrote:
>> diff --git a/Makefile b/Makefile
>> @@ -822,12 +822,12 @@ VCSSVN_LIB = vcs-svn/lib.a
>> -LIB_H := $(shell git ls-files '*.h' ':!t/' ':!Documentation/' 2>/dev/null
>> || \
>> +LIB_H := $(shell (git ls-files '*.h' ':
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
After merging 'dl/no-extern-in-func-decl' into 'pu', it seems like the
conflict resolution mostly went well except for one spot, which this
patch should fix. Although this is only currently only a problem in
'pu', we should fix the entry rerere cache for if this branch ends up
merged in 'next' in t
I noticed earlier that when running 'git difftool --gui', we do not
fallback to 'merge.guitool' when 'diff.guitool' isn't set, even though
this behaviour exists for when we invoke 'git difftool' (i.e. it falls
back from diff.tool to merge.tool).
While fixing this bug up, I noticed a few other plac
In git-difftool.txt, it says
'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
However, when `diff.guitool` is missing, it doesn't fallback to
anything. Make git-difftool fallback to `merge.guitool` when `diff.guitoo
In 063f2bdbf7 (mergetool: accept -g/--[no-]gui as arguments,
2018-10-24), mergetool was taught the --gui option but no tests were
added to ensure that it was working properly. Add a test to ensure that
it works.
Signed-off-by: Denton Liu
---
t/t7610-mergetool.sh | 22 ++
1 fi
In git-difftool, if the tool is called with --gui but `diff.guitool` is
not set, it falls back to `diff.tool`. Make git-mergetool also fallback
from `merge.guitool` to `merge.tool` if the former is undefined.
If git-difftool were to use `get_configured_mergetool`, it would also
get the fallback be
In git-mergetool, the logic for getting which merge tool to use is
duplicated in git-mergetool--lib, except for the fact that it needs to
know whether the tool was guessed or not.
Rewrite `get_merge_tool` to return whether or not the tool was guessed
and make git-mergetool call this function inste
In git-difftool, these options specify which tool to ultimately run. As
a result, they are logically conflicting. Explicitly disallow these
options from being used together.
Signed-off-by: Denton Liu
---
builtin/difftool.c | 11 ++-
t/t7800-difftool.sh | 8
2 files changed, 18
The merge of jk/fetch-reachability-error-fix conflicts with
jt/test-protocol-version, but the conflict resolution done by
b4ce8375c018 has a typo (looks like an editor mistake):
$ git show b4ce8375c018
[...]
- test_must_fail git fetch ../testrepo/.git $SHA1_3 &&
-
On Sun, Apr 21, 2019 at 9:19 AM Junio C Hamano wrote:
> diff --git a/Makefile b/Makefile
> @@ -822,12 +822,12 @@ VCSSVN_LIB = vcs-svn/lib.a
> -LIB_H := $(shell git ls-files '*.h' ':!t/' ':!Documentation/' 2>/dev/null ||
> \
> +LIB_H := $(shell (git ls-files '*.h' ':!t/' ':!Documentation/' 2>/dev/
On 4/21/19 9:27 AM, Andrew Janke wrote:
>
> On 4/21/19 8:59 AM, Philip Oakley wrote:
>> Hi Andrew,
>>
>> On 21/04/2019 12:08, Andrew Janke wrote:
>> https://public-inbox.org/git/d001a2b5-57c3-1eb3-70fd-679919bb2...@apjanke.net/
>>
>>> I don't think it would even have
>>> to be actively maintain
Phil Hord writes:
> Currently it supports these switches:
>
> usage: git rebase [-i] [options] [--exec ] ...
>:
> --break stop before the mentioned ref
> --drop drop the mentioned ref from the todo list
> --edit edit the mentioned ref instead of picking it
>
On 4/21/19 8:35 PM, Duy Nguyen wrote:
> On Sun, Apr 21, 2019 at 6:40 PM Andrew Janke wrote:
>>
>> Hi, Git folks,
>>
>> This is a follow-up to https://marc.info/?l=git&m=154757938429747&w=2.
>
> This says the problem with "en" detection has been fixed. Would
> upgrading gettext fix it?
>
> You
On Sun, Apr 21, 2019 at 6:40 PM Andrew Janke wrote:
>
> Hi, Git folks,
>
> This is a follow-up to https://marc.info/?l=git&m=154757938429747&w=2.
This says the problem with "en" detection has been fixed. Would
upgrading gettext fix it?
You would need to upgrade something (git or gettext) and if
From: Phil Hord
A common use for rebase is to drop or edit some commit in a
feature branch. The commit to be changed is known in advance,
so a user will say 'git rebase -i that-commit^' to see the todo
list in her editor. Then she will change the command on the line
for "that-commit" to edit in
From: Phil Hord
Expand the rebase edit switches to include the break switch. This
switch lets the user add a "break" instruction to the todo-list
before the mentioned reference.
This switch is a little different from the ones added so far because
it adds a new instruction between commits in the
From: Phil Hord
I have a local patch to rebase--interactive.sh that adds "edit" switches
to rebase, permitting me to say, for example,
git rebase --drop $sha
This command creates a todo-list but drops the mentioned commit from the
list by changing the "pick" to "drop". Other switches let me
Philip Oakley writes:
> On 21/04/2019 12:08, Andrew Janke wrote:
> https://public-inbox.org/git/d001a2b5-57c3-1eb3-70fd-679919bb2...@apjanke.net/
>> I don't think it would even have
>> to be actively maintained, because for new message strings that aren't
>> included in the .po file, it would fal
"brian m. carlson" writes:
> It may be helpful to point out that this is essentially the workflow I
> had ...
> I'm not sure if this email is an argument for or against this option,
> but maybe it provides some helpful perspective.
I think you and Phillip misread me.
I did not question if the w
On Sun, Apr 21, 2019 at 02:38:38PM +0900, Junio C Hamano wrote:
> Alex Henrie writes:
>
> > A common workflow is to make a commit on a local branch, push the branch
> > to the remote, check out the remote branch on a second computer, amend
> > the commit on the second computer, force-push back to
I got it to do what I want. I have alias nuke='rm -rfv'
So I did
nuke github.com/alecthomas/gometalinter (modified content)
nuke github.com/kisielk/errcheck (modified content)
nuke github.com/rogpeppe/godef (modified content)
git rm github.com/alecthomas/gometalinter (modifie
I did
git config --global core.trustctime false
git config --global core.checkStat minimal
No difference
-rob
On 4/21/19 1:22 PM, Philip Oakley wrote:
On 21/04/2019 18:07, rob wrote:
possibly. What do I do about that?
--rob
see below.
On 4/21/19 9:03 AM, Philip Oakley wrote:
Hi Ro
On 21/04/2019 18:07, rob wrote:
possibly. What do I do about that?
--rob
see below.
On 4/21/19 9:03 AM, Philip Oakley wrote:
Hi Rob,
On 21/04/2019 13:34, rob wrote:
didn't work. I did not get any error messages, just didn't work.
After I did
git reset --hard
git status
I see the
possibly. What do I do about that?
--rob
On 4/21/19 9:03 AM, Philip Oakley wrote:
Hi Rob,
On 21/04/2019 13:34, rob wrote:
didn't work. I did not get any error messages, just didn't work.
After I did
git reset --hard
git status
I see the same 3 files that say changes not staged for
Hi Alex
On 21/04/2019 08:01, Alex Henrie wrote:
On Sat, Apr 20, 2019 at 11:38 PM Junio C Hamano wrote:
Alex Henrie writes:
A common workflow is to make a commit on a local branch, push the branch
to the remote, check out the remote branch on a second computer, amend
the commit on the second
On 4/21/19 8:59 AM, Philip Oakley wrote:
> Hi Andrew,
>
> On 21/04/2019 12:08, Andrew Janke wrote:
> https://public-inbox.org/git/d001a2b5-57c3-1eb3-70fd-679919bb2...@apjanke.net/
>
>> I don't think it would even have
>> to be actively maintained, because for new message strings that aren't
>>
Since 33533975 ("Makefile: ask "ls-files" to list source files if
available", 2011-10-18), we optionally asked "ls-files" to list the
source files that ought to exist, as a faster approximation for
"find" on working tree files.
This works reasonably well, except that it ends up listing the same
pa
On Apr 20 2019, rob wrote:
> changes not staged for commit:
>
> modified: github.com/alecthomas/gometalinter (modified content)
>
> modified: github.com/kisielk/errcheck (modified content)
>
> modified: github.com/rogpeppe/godef (modified content)
You have submodules with modified content.
Hi Rob,
On 21/04/2019 13:34, rob wrote:
didn't work. I did not get any error messages, just didn't work.
After I did
git reset --hard
git status
I see the same 3 files that say changes not staged for commit:
modified and it lists the same 3 files.
Could this be that the file timestamp
Hi Andrew,
On 21/04/2019 12:08, Andrew Janke wrote:
https://public-inbox.org/git/d001a2b5-57c3-1eb3-70fd-679919bb2...@apjanke.net/
I don't think it would even have
to be actively maintained, because for new message strings that aren't
included in the .po file, it would fall back to the non-trans
didn't work. I did not get any error messages, just didn't work. After
I did
git reset --hard
git status
I see the same 3 files that say changes not staged for commit: modified
and it lists the same 3 files.
--rob
On 4/21/19 1:03 AM, Adrian H wrote:
If I understand the commands you
Hi, Git folks,
This is a follow-up to https://marc.info/?l=git&m=154757938429747&w=2.
With the current git 2.21.0, some users, including myself, are still
having problems with git selecting the "wrong" language for localization.
This happens on macOS in the situation where:
* The user has multip
Emily Shaffer writes:
> This tutorial covers how to add a new command to Git and, in the
> process, everything from cloning git/git to getting reviewed on the
> mailing list. It's meant for new contributors to go through
> interactively, learning the techniques generally used by the git/git
> dev
Good day,
My name is Mr.Yuehan Pan, working as head of risk in Bank
of China.
I'm looking for an investment manager / partner who will represents me in
a mutual business.
Please contact me in my private email for more details.
e-mail (yuehanpa...@gmail.com)
Waiting for your news.
Thank you,
Signed-off-by: Denton Liu
---
t/t3431-rebase-fork-point.sh | 53
1 file changed, 53 insertions(+)
create mode 100755 t/t3431-rebase-fork-point.sh
diff --git a/t/t3431-rebase-fork-point.sh b/t/t3431-rebase-fork-point.sh
new file mode 100755
index 00..
Before, when we rebased with a --fork-point invocation where the
fork-point wasn't empty, we would be setting options.restrict_revision.
The fast-forward logic would automatically declare that the rebase was
not fast-forwardable if it was set. However, this was painting with a
very broad brush.
Re
Hi all,
Sorry for yet another reroll. I realised earlier that rebase doesn't use
--git-completion-helper for completion so I had to manually insert
--keep-base into the completion script.
Between this and forgetting to update the comment around the
can_fast_forward call, I figured with the number
A common scenario is if a user is working on a topic branch and they
wish to make some changes to intermediate commits or autosquash, they
would run something such as
git rebase -i --onto master... master
in order to preserve the merge base. This is useful when contributing a
patch series
Before, when we had the following graph,
A---B---C (master)
\
D (side)
running 'git rebase --onto master... master side' would result in D
being always rebased, no matter what. However, the desired behavior is
that rebase should notice that this is fast-forwarda
When rebase is run on a branch that can be fast-forwarded, this should
automatically be done. Create test to ensure this behavior happens.
There are some cases that currently don't pass. The first case is where
a feature and master have diverged, running
"git rebase master... master" causes a full
Before, can_fast_forward was written with an if-else statement. However,
in the future, we may be adding more termination cases which would lead
to deeply nested if statements.
Refactor to use a goto tower so that future cases can be easily
inserted.
Signed-off-by: Denton Liu
---
builtin/rebase
On Sat, Apr 20, 2019 at 11:38 PM Junio C Hamano wrote:
>
> Alex Henrie writes:
>
> > A common workflow is to make a commit on a local branch, push the branch
> > to the remote, check out the remote branch on a second computer, amend
> > the commit on the second computer, force-push back to the re
47 matches
Mail list logo
