gt; Anton Ermolenko wrote:
>
>> My understanding is that recursive merge here won't consider that situation
>> to
>> be a merge conflict as the changes have been introduced in different spots in
>> the file.
>
> Yes, that seems right to me.
>
> Do yo
Anton Ermolenko wrote:
> My understanding is that recursive merge here won't consider that situation to
> be a merge conflict as the changes have been introduced in different spots in
> the file.
Yes, that seems right to me.
Do you have more details about the context? What do th
ge --no-ff -m "merge change-b" change-b
And the resulting content of "example.txt" is:
--- START ---
LINE 1
LINE B
LINE 3
LINE D
LINE E
LINE 3
LINE 4
LINE 5
LINE 6
LINE 7
LINE 8
LINE 9
--- END ---
My understanding is that recursive merge here won'
From: Denton Liu
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Helped-by: Phillip Wood
Signed-off-by: Denton Liu
---
Documentation/git-cherry-pick.txt | 7 +++
Documentation/git-revert.txt
From: Denton Liu
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists i
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Helped-by: Phillip Wood
Signed-off-by: Denton Liu
---
Documentation/git-cherry-pick.txt | 7 +++
Documentation/git-revert.txt | 7
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
H
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
Rev
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Reviewed-by: Phillip Wood
Signed-off-by: Denton Liu
---
Documentation/git-cherry-pick.txt | 7 +++
Documentation/git-revert.txt | 7
Hi Denton
I've got a couple of small comments, but this looks fine to me
On 11/03/2019 03:42, Denton Liu wrote:
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Signed-off-by: Dento
On Sun, Mar 10, 2019 at 11:42 PM Denton Liu wrote:
> This fixes a bug where the scissors line is placed after the Conflicts:
> section, in the case where a merge conflict occurs and
> commit.cleanup = scissors.
>
> Next, if commit.cleanup = scissors is specified, don't produ
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
S
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Signed-off-by: Denton Liu
---
Documentation/git-cherry-pick.txt | 7 +++
Documentation/git-revert.txt | 7 +++
builtin/merge.c
Phillip Wood writes:
>>> What are you basing this series on? builtin/rebase--helper.c was removed
>>> last September in 34b47315d9 ("rebase -i: move rebase--helper modes to
>>> rebase--interactive", 2018-09-27)
>>
>> I was basing this patch on the tip of dl/merge-cleanup-scissors-fix. I
>> can r
On 07/03/2019 17:56, Denton Liu wrote:
> Hi Phillip,
>
> On Thu, Mar 07, 2019 at 03:24:16PM +, Phillip Wood wrote:
>> Hi Denton
>>
>> On 07/03/2019 09:58, Denton Liu wrote:
>>> diff --git a/builtin/rebase--helper.c b/builtin/rebase--helper.c
>>> index f7c2a5fdc8..5f1bc9d383 100644
>>> --- a/bu
Hi Phillip,
On Thu, Mar 07, 2019 at 03:24:16PM +, Phillip Wood wrote:
> Hi Denton
>
> On 07/03/2019 09:58, Denton Liu wrote:
> >Fix a bug where the scissors line is placed after the Conflicts:
> >section, in the case where a merge conflict occurs and
> >commit.clea
Hi Denton
On 07/03/2019 09:58, Denton Liu wrote:
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Note that the removal of the if-else tower in git_sequencer_config may
appear to be a no-op
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Note that the removal of the if-else tower in git_sequencer_config may
appear to be a no-op refactor but it actually isn't. First of all, w
file is the part that would become the
> commit message, so I would have expected the second step would be
> described as "appended to".
I copied this over from 6f06b6aeef (merge: add scissors line on merge
conflict, 2019-01-22). I guess I'll have to fix it up in git-merge too.
&g
Denton Liu writes:
> Fix a bug where the scissors line is placed after the Conflicts:
> section, in the case where a merge conflict occurs and
> commit.cleanup = scissors.
>
> Note that the removal of the if-else tower in git_sequencer_config may
> appear to be a no-op refact
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Note that the removal of the if-else tower in git_sequencer_config may
appear to be a no-op refactor but it actually isn't. First of all, w
Hi Phillip, sorry I forgot to address one of your replies.
On Wed, Mar 06, 2019 at 04:29:20PM +, Phillip Wood wrote:
> Hi Denton
>
> On 06/03/2019 10:30, Denton Liu wrote:
> >Fix a bug where the scissors line is placed after the Conflicts:
> >section, in the case w
Hi Phillip,
On Wed, Mar 06, 2019 at 04:29:20PM +, Phillip Wood wrote:
> Hi Denton
>
> On 06/03/2019 10:30, Denton Liu wrote:
> >Fix a bug where the scissors line is placed after the Conflicts:
> >section, in the case where a merge conflict occurs and
> >commit.c
Hi Denton
On 06/03/2019 10:30, Denton Liu wrote:
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Was that the case with cherry-pick and revert as well as merge, or were
they missing the
Fix a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Note that the removal of the if-else tower in git_sequencer_config may
appear to be a no-op refactor but it actually isn't. First of all, w
There are merge conflicts that do not result in merge conflict markers: e.g.
when one branch extends a function's signature, and another branch adds a
caller.
In this instance, sg/travis-specific-cc wants to use gcc-8 in the osx-gcc
job (which is already installed, but not linked, on T
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
S
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
commit.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
S
wever, since we taught git-merge the --cleanup option, this might be
> misleading for the end-user since they would expect the MERGE_MSG to be
> cleaned up as specified.
>
> I see two resolutions for this. We can either rename --cleanup more
> precisely so users won't be confus
isleading for the end-user since they would expect the MERGE_MSG to be
cleaned up as specified.
I see two resolutions for this. We can either rename --cleanup more
precisely so users won't be confused (perhaps something like
--merge-conflict-scissors but a lot more snappy) or we can actu
Denton Liu writes:
> Changes since V3:
> * Add patch to cleanup 'merge --squash c3 with c7' test in t7600
> * Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
Queued. Thanks, both.
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
merge.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
Fi
merge --squash c3 with c7' test in t7600
* Use test_i18ncmp instead of test_cmp to pass GETTEXT_POISON tests
Denton Liu (2):
t7600: clean up 'merge --squash c3 with c7' test
merge: add scissors line on merge conflict
Documentation/merge-options.txt | 6 ++
On Sat, Nov 17, 2018 at 06:32:33PM -0500, Denton Liu wrote:
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 106148254d..0d3db34f08 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -247,6 +247,54 @@ test_expect_success 'merge --squash c3 with c7' '
> test_cmp expect act
Denton Liu writes:
>> I wonder if this is what you really meant to have instead:
>>
>> >else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&
>> > - whence == FROM_COMMIT)
>> > - wt_status_add_cut_line(s->fp);
>> > + whence == FR
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
merge.cleanup = scissors.
Next, if commit.cleanup = scissors is specified, don't produce a
scissors line in commit if one already exists in the MERGE_MSG file.
Fi
about `#`
_not_ being removed is now silenced in both cases.
Changes since V1:
* Only check MERGE_MSG for a scissors line instead of all prepended
files
* Make a variable static in merge where appropriate
* Add passthrough options in pull
* Add documen
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
merge.cleanup = scissors.
In addition, we give pull the passthrough option of --cleanup so that it
can also take advantage of this change.
Signed-off-by: Denton Liu
ke a variable static in merge where appropriate
* Add passthrough options in pull
* Add documentation for the new option
* Add tests to ensure desired behaviour
Denton Liu (2):
commit: don't add scissors line if one exists
merge: add scissors line on merge conflict
Documentati
On Wed, Nov 14, 2018 at 04:52:59PM +0900, Junio C Hamano wrote:
> Denton Liu writes:
>
> > With this fix, the message becomes the following:
> >
> > Merge branch 'master' into new
> >
> > # >8
> > # Do not modify or remove the line abo
Denton Liu writes:
> With this fix, the message becomes the following:
>
> Merge branch 'master' into new
>
> # >8
> # Do not modify or remove the line above.
> # Everything below it will be ignored.
> #
> # Con
This fixes a bug where the scissors line is placed after the Conflicts:
section, in the case where a merge conflict occurs and
merge.cleanup = scissors.
Signed-off-by: Denton Liu
---
builtin/merge.c | 16
1 file changed, 16 insertions(+)
diff --git a/builtin/merge.c b/builtin
I discovered a bug in Git a while ago where if one is using
commit.cleanup = scissors, if making a commit after a merge conflict,
the scissors line will be placed after the `Conflicts:` section. As a
result, a careless Git user (e.g. me) may accidentally commit the
`Conflicts:` section.
Here is a
Hi everyone,
Last week, Duy posted an interesting RFC patch for improving merge
conflict resolution by coloring the "CONFLICT' messages that are
output during a merge. I have two more ideas (complementary to his)
for improving merge conflict resolution experience. My two ideas
Junio C Hamano writes:
> But by splitting these into separate tests, the patch makes such a
> potential failure with "git commit --short" break the later steps.
>
> Not very nice.
>
> It may be a better change to just do in the original one
>
> git add test-file &&
> git commit --dry-
or of all flags which imply a dry run
> when (1) there is at least one unfixed merge conflict and (2) when all
> merge conflicts are all fixed.
s/conflits/conflicts/
s/fixed/resolved/g (both above and in the patch text)
s/unfixed/unresolved/g (both above and in the patch text)
> Sig
) there is at least one unfixed merge conflict and (2) when all
merge conflicts are all fixed.
Signed-off-by: Samuel Lijin
---
t/t7501-commit.sh | 45 -
1 file changed, 40 insertions(+), 5 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index
entation/core-api/gfp_mask-from-fs-io.rst
> > * unresolved merge conflict (line 27)
> > Documentation/core-api/gfp_mask-from-fs-io.rst:27:===
>
> This message isn't generated by git itself, but rather by a pre-commit
> hook. You can skip the hook by running "git commit --n
On Thu, May 24, 2018 at 01:36:57PM +0200, Michal Hocko wrote:
> `git commit' fails on a newly added file with the following
> *
> * You have some suspicious patch lines:
> *
> * In Documentation/core-api/gfp_mask-from-fs-io.rst
> * unresolved merge conflict (line 27)
&
Hi,
`git commit' fails on a newly added file with the following
*
* You have some suspicious patch lines:
*
* In Documentation/core-api/gfp_mask-from-fs-io.rst
* unresolved merge conflict (line 27)
Documentation/core-api/gfp_mask-from-fs-io.rst:27:===
$ git status --porcela
Ah, the whitespace that was added to enable the >>> markers to be
added... that makes sense.
Which means the output is correct and some assumptions my code makes
about the format of the Combined Diff are wrong.
Thanks!
Nick
On 8 February 2018 at 11:25, Jeff King wrote:
> On Thu, Feb 08, 2018
On Thu, Feb 08, 2018 at 10:51:57AM +, Nick O'Leary wrote:
> $ git diff README.md
> diff --cc README.md
> index 61d78b2,620d806..000
> --- a/README.md
> +++ b/README.md
> @@@ -1,7 -1,1 +1,11 @@@
> -This is my default readme
> ++<<< HEAD
> +merged-history-test
> +===
>
Hi,
I have a merge conflict on a file and the git diff output looks wrong to me.
Here's how to recreate:
On branch 'dev' add/commit a file (called README.md) with the contents
( '--' used to delimit the file, not included in the content):
---
This is my de
Hi. I have merge conflict and this output:
--- a/crypto/lib/Crypto/Routes.pm
+++ b/crypto/lib/Crypto/Routes.pm
@@@ -98,17 -94,16 +98,36 @@@ sub register
,payment_cancel_landing => '/payment-cancel'
}});
# Route configuration is moved from plugin:
++<<&
Hi Francis,
On Fri, 23 Oct 2015, Francis Moreau wrote:
> I have a simple merge conflict use case:
>
> $ mkdir foo
> $ cd foo/
> $ git init
> $ echo line1 > a
> $ git add .
> $ git commit -q -m init
> $ echo line2 >>a
> $ git commit -a -q -m "add l
Hi,
I have a simple merge conflict use case:
$ mkdir foo
$ cd foo/
$ git init
$ echo line1 > a
$ git add .
$ git commit -q -m init
$ echo line2 >>a
$ git commit -a -q -m "add line2"
$ git checkout -b foo HEAD~1
$ git cherry-pick -x master
$ echo line3 >>a
$ git stage
On Tue, Apr 28, 2015 at 07:34:30AM +, Anuradha Dissanayake wrote:
> Let's say I have a file with this content in master:
>
> _
> Line 1
> Line 2
> Line 3
> Line 4
> _
>
> Now say I create and checkout a new branch called Test. In this branch I
> change the file to this:
>
> _
I posted this question to StackOverflow a while ago but no one answered
it so I thought I'd try here.
Let's say I have a file with this content in master:
_
Line 1
Line 2
Line 3
Line 4
_
Now say I create and checkout a new branch called Test. In this branch I
change the file to this:
On Mon, Aug 11, 2014 at 04:59:15PM +1200, Chris Packham wrote:
> Is there any way where we could share the conflict resolution around
> but still end up with a single merge commit. I'm thinking of something
> like the following workflow
This came up once a while back. Here's the discussion:
ht
On Mon, Aug 11, 2014 at 4:29 PM, Chris Packham wrote:
>> So, the "recording" phase may go something like this:
>> ...
>> git checkout merge-fix/$this-$that
>> git read-tree -m -u HEAD $this
>> git commit -a -m 'merge-fix/$this-$that postimage'
>>
>> The rough idea is "git show merge-f
On Tue, Aug 12, 2014 at 6:44 AM, Junio C Hamano wrote:
> Chris Packham writes:
>
>> Is there any way where we could share the conflict resolution around
>> but still end up with a single merge commit.
>
> One idea that immediately comes to me is to use something like
> "rerere" (not its implement
IIUC, this might help,
http://www.mail-archive.com/git@vger.kernel.org/msg56418.html
http://www.mail-archive.com/git@vger.kernel.org/msg56468.html
--
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://
Le 11 août 2014 07:50, "Christian Couder" a écrit :
>
> This should be possible using "git imerge" which is separate tool.
Sorry I sent the above using the gmail app on my mobile phone and
unfortunately I can't make it send plain text emails.
(Emails which are not plain text are rejected by vger.
Chris Packham writes:
> Is there any way where we could share the conflict resolution around
> but still end up with a single merge commit.
One idea that immediately comes to me is to use something like
"rerere" (not its implementation and storage, but the underlying
idea) enhanced with the tric
Hi List,
At $dayjob we maintain internal forks of the a number of upstream repositories.
Unsurprisingly updating these forks can be extremely problematic,
especially when it's only one person doing the merge. Fortunately most
of us are in the same physical location so it is possible to drag in
so
Andrew Wong writes:
> On Mon, Mar 17, 2014 at 7:04 PM, Junio C Hamano wrote:
>> Has this series been tested with existing test suite? ...
> I tested it during RFC, but missed it when I sent it as patch.
> ...
> I'll fix the problem. Sorry about that.
Thanks. Will hold onto the topic branch les
On Mon, Mar 17, 2014 at 7:04 PM, Junio C Hamano wrote:
> Has this series been tested with existing test suite? I tentatively
> queued it to 'pu' but then had to revert because many tests started
> failing, causing me to redo the today's integration cycle for 'pu'
> once again.
I tested it during
Andrew Wong writes:
> 2/3: I've added advice.mergeHints to silent the messages that suggests "git
> merge--abort".
>
> 3/3: I've added a warning message when users used "git reset" during a merge.
> This warning will be printed if the user is in the middle of a merge. In
> future
> releases, we'
2/3: I've added advice.mergeHints to silent the messages that suggests "git
merge--abort".
3/3: I've added a warning message when users used "git reset" during a merge.
This warning will be printed if the user is in the middle of a merge. In future
releases, we'll change this into an error to prev
Matthieu Moy writes:
> $ git status
> On branch master
> nothing to commit, working directory clean
> $
ok, you've lost your conflict resolutions.
>> In fact, it now seems that 'git reset --mixed' is always the same as
>> 'git reset --merge'. So I must be missing something!
>
> "git reset --mer
Stephen Leake writes:
> So as I understand it, this does _not_ lose your conflict resolutions.
Well, then maybe it's time to try the command before continuing
commenting on its behavior ;-).
$ git status
[...]
both modified: foo.txt
[...]
$ git diff
diff --cc foo.txt
index 595f399,
David Kastrup writes:
> Stephen Leake writes:
>
>> David Kastrup writes:
>>
>>> Stephen Leake writes:
>>>
David Kastrup writes:
> "do the right thing" commands also tend to do the wrong thing
> occasionally with potentially disastrous results when they are used
> in scri
Stephen Leake writes:
> David Kastrup writes:
>
>> Stephen Leake writes:
>>
>>> David Kastrup writes:
>>>
"do the right thing" commands also tend to do the wrong thing
occasionally with potentially disastrous results when they are used
in scripts where the followup actions rely
David Kastrup writes:
> Stephen Leake writes:
>
>> David Kastrup writes:
>>
>>> "do the right thing" commands also tend to do the wrong thing
>>> occasionally with potentially disastrous results when they are used
>>> in scripts where the followup actions rely on the actual result.
>>
>> That i
Stephen Leake writes:
> David Kastrup writes:
>
>> "do the right thing" commands also tend to do the wrong thing
>> occasionally with potentially disastrous results when they are used
>> in scripts where the followup actions rely on the actual result.
>
> That is bad, and should not be allowed.
David Kastrup writes:
> Stephen Leake writes:
>
>> I like commands that "do the right thing". So no, this would not be
>> confusing.
>
> I _hate_ commands that think they know better than to do what they are
> told. In particular when doing destructive things. And just because
> _you_ like the
Stephen Leake writes:
> I like commands that "do the right thing". So no, this would not be
> confusing.
I _hate_ commands that think they know better than to do what they are
told. In particular when doing destructive things. And just because
_you_ like them does not mean they are not confusi
On Fri, Feb 28, 2014 at 03:01:53AM -0600, Stephen Leake wrote:
> Jonathan Nieder writes:
> > And for experienced users, this would be a bad regression.
>
> Backward incompatibility is a real concern.
>
> It might be best if "git reset" (with _no_ option) be made to error out,
> so all users have
the patches.
>
>> We could stop here and hope that the users would read the messages, but I
>> think
>> git could be a bit more user-friendly. The last patch might be a bit more
>> controversial. It changes the default behavior of "git reset" to default to
&
sers would read the messages, but I
> think
> git could be a bit more user-friendly. The last patch might be a bit more
> controversial. It changes the default behavior of "git reset" to default to
> "git reset --merge" during a merge conflict. I imagine that's w
Users may not be aware that they need to use "git merge --abort" or "git reset
--merge" to properly abort a merge conflict. They are likely to just use "git
reset", because that "usually" cleans up the repo. But in the case where the
user had local change
7;s say I have two identical branches: master and topic. In master I
>> remove some code, i.e. function bar(). In topic I do the same (commit)
>> and after some time I realize I need bar() and revert previous commit
>> with removal.
>> So I end with master with no bar()
I end with master with no bar() and topic with bar() in its
> original state. When I merge I get code without bar() and no merge
> conflict (recursive or resolve strategies). Is it possible to detect
> such situations as conflicts? When bar() is C++ virtual there is no
> possibility to ca
aster with no bar() and topic with bar() in its
original state. When I merge I get code without bar() and no merge
conflict (recursive or resolve strategies). Is it possible to detect
such situations as conflicts? When bar() is C++ virtual there is no
possibility to catch this with compiler.
You c
evious commit
> with removal.
> So I end with master with no bar() and topic with bar() in its
> original state. When I merge I get code without bar() and no merge
> conflict (recursive or resolve strategies). Is it possible to detect
> such situations as conflicts? When bar() is C++ v
n its
original state. When I merge I get code without bar() and no merge
conflict (recursive or resolve strategies). Is it possible to detect
such situations as conflicts? When bar() is C++ virtual there is no
possibility to catch this with compiler.
Please, CC me since I'm not subscribed.
Thanks
nother project also using it as a subtree, or directly with 'git
push' -- doesn't matter). When I go back to the initial project, 'git
subtree pull' has a merge conflict, and fails to merge the new
changes. The reported conflict is half-empty, so I can't see why ther
Zoltan Klinger writes:
> When a rebase is interrupted by a merge conflict it could be useful to
The command also stops when told to stop with "amend", etc. no? I
would phrase this way "When a rebase stops (e.g. interrupted ...),
it could be useful...".
> This
When a rebase is interrupted by a merge conflict it could be useful to
know how far a rebase has progressed and how many commits in total this
rebase will apply. Teach the __git_ps1() command to display the number
of commits so far applied and the total number of commits to be applied.
Below is a
On Tue, Apr 23, 2013 at 10:08 AM, Junio C Hamano wrote:
> Zoltan Klinger writes:
>
>> When a rebase is interrupted by a merge conflict it could be useful to
>> know how far a rebase has progressed and how many commits in total this
>> rebase will apply. Teach the __git_
On Tue, Apr 23, 2013 at 8:35 AM, Zoltan Klinger
wrote:
> When a rebase is interrupted by a merge conflict it could be useful to
> know how far a rebase has progressed and how many commits in total this
> rebase will apply. Teach the __git_ps1() command to display the number
> of co
Zoltan Klinger writes:
> When a rebase is interrupted by a merge conflict it could be useful to
> know how far a rebase has progressed and how many commits in total this
> rebase will apply. Teach the __git_ps1() command to display the number
> of commits so far applied and the tot
When a rebase is interrupted by a merge conflict it could be useful to
know how far a rebase has progressed and how many commits in total this
rebase will apply. Teach the __git_ps1() command to display the number
of commits so far applied and the total number of commits to be applied.
Below is a
On Wed, Mar 13, 2013 at 11:48 AM, Øystein Walle wrote:
> When a merge is ongoing and there are conflicts, 'git difftool' will
> output the exact same --cc-style diff output as 'git diff' will without
> further explanation. This has lead to some confusion: A couple of weeks
> ago a person asked on
Hi,
On Thu, Dec 13, 2012 at 01:46:43PM +0800, ?A???Y wrote:
> If there are merge conflict files, then changed submodules are not
> updated automatically.
> Why not submodules?
> Files do try to merge / update.
This is work in progress, currently you still have to use submodule
update
Hi,
If there are merge conflict files, then changed submodules are not
updated automatically.
Why not submodules?
Files do try to merge / update.
Regards,
ch3cooli
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kerne
On Mon, Oct 01, 2012 at 08:13:21PM -0500, Matt McClellan wrote:
> We had an issue at our organization where changes were reverted when a
> user was merging his local repo with the remote repo changes. The
> merge conflicted and he unstaged all the changes that were not a
> conflict, he then resol
Matt McClellan writes:
> I've done this using git add --interactive then reverting a files
> changes, though the actual crime was done using egit staging tool. It
> seems the command line won't let you unstage changes but gui tools and
> interactive tools seem to allow it.
I think you could do
Dear diary, on Sat, Aug 13, 2005 at 04:45:32PM CEST, I got a letter
where Kenneth Johansson <[EMAIL PROTECTED]> told me that...
> I used cogito to do a cg-update and got conflicts and the exact files are
> printed to the screen. But say I somehow lost that output is there anyway
> to list conflicti
99 matches
Mail list logo
