Hi,
I've seen recently some development with a special development flow that is the
source of my feature request.
Description of the feature:
For each treated file, in case of an empty ancestor (file created on both
branches or orphan branch), I found that usually the best way to help (or even
The example output of `git merge-index` has been enriched by a second
"column" of helpful comments. When Asciidoctor renders this, the cells
in that second column aren't aligned.
Fix this by marking the example shell session as a code listing by
wrapping it in "&quo
us some extra indentation, we can remove the one that
we have been carrying explicitly. That is, drop the first tab of
indentation on each line. With AsciiDoc, this results in identical
rendering before and after this commit, both for git-merge-base.1 and
git-merge-base.html.
A less intrusive change would
From: Michael J Gruber
git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.
Introduce a pre-merge-commit hook which is called for an automatic merge
commit just like pre-commit is called for a non-automatic merge
From: Michael J Gruber
git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.
Introduce a pre-merge-commit hook which is called for an automatic merge
commit just like pre-commit is called for a non-automatic merge
ion/githooks.txt
> > @@ -103,6 +103,13 @@ The default 'pre-commit' hook, when enabled--and with
> > the
> > `hooks.allownonascii` config option unset or set to false--prevents
> > the use of non-ASCII filenames.
> >
> > +pre-merge-commit
> &
' hook, when enabled--and with the
> `hooks.allownonascii` config option unset or set to false--prevents
> the use of non-ASCII filenames.
>
> +pre-merge-commit
> +~~~~~~~~
> +
> +This hook is invoked by 'git merge' when doing an automatic merge
> +c
git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.
Introduce a pre-merge-commit hook which is called for an automatic merge
commit just like pre-commit is called for a non-automatic merge commit
(or any other
On Fri, 19 Jul 2019 at 00:57, Josh Steadmon wrote:
> --- /dev/null
> +++ b/templates/hooks--pre-merge.sample
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +#
> +# An example hook script to verify what is about to be committed.
> +# Called by "git merge" with no arguments. The
From: Michael J Gruber
git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.
Introduce a pre-merge hook which is called for an automatic merge commit
just like pre-commit is called for a non-automatic merge commit
Hi Duy
On 01/05/2019 14:11, Nguyễn Thái Ngọc Duy wrote:
> nd/switch-and-restore suggests 'git merge --quit' to get out of a merge
> even though this option is not implemented [1]. It's a soft dependency, no
> actual functionality is broken by the lack of --quit, so I&#
nd/switch-and-restore suggests 'git merge --quit' to get out of a merge
even though this option is not implemented [1]. It's a soft dependency, no
actual functionality is broken by the lack of --quit, so I'm sending
it separately.
[1] https://public-inbox.org/git/78c7c281-82ec
pected that you can say this?
$ git merge +master:refs/remotes/origin/master
The "git merge" command takes one or more commit-ishes to be merged
to the current branch on its command line, and the above command
line is correct at the syntax level.
But because 'master:refs/re
> Junio C Hamano wrote:
> I do not know what "git fetch" uses semicolon for here. Care to
> elaborate?
Those were all typos, I meant colon, two dots. Sorry.
ron writes:
> ... And it may not be uncommon since it comes from the fact that
> git merge normally follows git fetch where semicolon is supported
> as per normal.
I do not know what "git fetch" uses semicolon for here. Care to
elaborate?
First time reporting a bug :) or at least what I think it may be.
There's a few similar cases I think I've seen in the past, but the one I'm sure
about is the semicolon instead of space between multiple branches, that should
be a syntax error if git merge can't accept th
Jonathan Nieder writes:
> John Passaro wrote:
>
>> I find myself fairly frequently doing something like "git log $(git
>> merge-base A B)..C".
>
> Hm. Can you tell me more about the workflow / higher-level operation
> where you do this?
Yes indeed, that
On Thu, Feb 21, 2019 at 9:24 AM Jeff King wrote:
>
> On Wed, Feb 20, 2019 at 11:59:04PM -0500, Jeff King wrote:
>
> > On Wed, Feb 20, 2019 at 02:03:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >
> > > > I wanted to point a colleague of mine to one of the talks.
> > > > Unfortunately I could not fi
Hi,
John Passaro wrote:
> I find myself fairly frequently doing something like "git log $(git
> merge-base A B)..C".
Hm. Can you tell me more about the workflow / higher-level operation
where you do this?
Curious,
Jonathan
I find myself fairly frequently doing something like "git log $(git
merge-base A B)..C". As far as I can tell, there is no shorthand for
the $() part of this, but it seems like something that could be pretty
naturally added, or documented better if there is some esoteric
combinat
Hi Ævar & Peff (and most importantly, Junio!),
On Thu, 14 Mar 2019, Jeff King wrote:
> > Maybe we can compromise on this whole ongoing NA v.s. Europe debate
> > and meet in Iceland :)
>
> Iceland Air is always trying to sell me that "Reykjavik stopover"...
Iceland!
I could be talked into that.
; This is going off-topic, but I'd be curious if splitting it up from Git
> Merge in general is an option. Presumably the hypothetical event this
> summer could be an experiment for that.
Yeah, it could be, if somebody wants to organize it. There was some
discussion on the list, I think
On Wed, Mar 13 2019, Jeff King wrote:
> I took an informal poll at the last contributor summit in Brussels, but
> that obviously has some bias. So I'll ask here: do you have a location
> preference for a Git Merge conference (and associated contributor
> summit) next March?
>
On Thu, 14 Mar 2019, Konstantin Ryabitsev wrote:
> On Wed, 13 Mar 2019 at 16:56, Jeff King wrote:
> > - preferences between Canada and US?
>
> If you're looking at Canada, East coast is generally more affordable
> than West Coast in terms of venues and accommodation. The three main
> tech hubs
On Wed, 13 Mar 2019 at 16:56, Jeff King wrote:
> - preferences between Canada and US?
If you're looking at Canada, East coast is generally more affordable
than West Coast in terms of venues and accommodation. The three main
tech hubs in the East are Toronto, Montreal and Halifax.
Toronto pros:
On 3/13/2019 4:55 PM, Jeff King wrote:
> We're looking at doing it in North America, but there are two specific
> questions:
>
> - is there preference between East Coast vs West Coast?
I have no preference here.
> - preferences between Canada and US?
There should be serious consideration fo
Hi,
On Thu, 14 Mar 2019, Elijah Newren wrote:
> On Wed, Mar 13, 2019 at 1:58 PM Jeff King wrote:
> >
> > I took an informal poll at the last contributor summit in Brussels, but
> > that obviously has some bias. So I'll ask here: do you have a location
> > prefe
On Wed, Mar 13, 2019 at 1:58 PM Jeff King wrote:
>
> I took an informal poll at the last contributor summit in Brussels, but
> that obviously has some bias. So I'll ask here: do you have a location
> preference for a Git Merge conference (and associated contributor
> summit) n
I took an informal poll at the last contributor summit in Brussels, but
that obviously has some bias. So I'll ask here: do you have a location
preference for a Git Merge conference (and associated contributor
summit) next March?
We're looking at doing it in North America, but the
reading, in various places, people asking how to globally set
options for merging, to which the standard answer is, no, you can't do
that *globally*, but you can do it on a per-branch basis with
branch..mergeOptions
the most common example being to squash into master:
git config branch.m
Am 21.02.2019 um 09:22 schrieb Jeff King:
> On Wed, Feb 20, 2019 at 11:59:04PM -0500, Jeff King wrote:
>
>> On Wed, Feb 20, 2019 at 02:03:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
I wanted to point a colleague of mine to one of the talks.
Unfortunately I could not find the recordings
On Wed, Feb 20, 2019 at 11:59:04PM -0500, Jeff King wrote:
> On Wed, Feb 20, 2019 at 02:03:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> > > I wanted to point a colleague of mine to one of the talks.
> > > Unfortunately I could not find the recordings of the talks anywhere.
> > >
> > > Are these
On Wed, Feb 20, 2019 at 02:03:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I wanted to point a colleague of mine to one of the talks.
> > Unfortunately I could not find the recordings of the talks anywhere.
> >
> > Are these available?
>
> I have no insider knowledge, but can tell you that in p
month delay has been more of the norm than 1-2.
So subscribe to their channel on YouTube, it'll be uploaded sometime
soon-ish.
1. https://www.youtube.com/user/github/videos
>> Jeff King hat am 9. November 2018 um 11:42 geschrieben:
>>
>>
>> Git Merge 2019 is happening
Hi Jeff,
I wanted to point a colleague of mine to one of the talks. Unfortunately I
could not find the recordings of the talks anywhere.
Are these available?
Thanks,
Thomas
> Jeff King hat am 9. November 2018 um 11:42 geschrieben:
>
>
> Git Merge 2019 is happening on Februar
Hi Team,
I've query for which we have no solutions from Stackoverflow. Or we
couldn't find one. Would be great if you have one or can provide
suggestions with.
SO Link:
https://stackoverflow.com/questions/53704320/git-merge-remote-repository-project-to-sub-directory-of-current-reposi
There were some merge conflicts since v5 so I've rebased the last few
patches on the latest master and fixed the conflicts.
Not related to this but while I was making my changes, I noticed that -F
and -m don't die properly in git-merge when they accept invalid
arguments. Instead, they
Andreas Hennings writes:
> I tried this option after upgrading my git.
> Unfortunately, no matter which variation I use, it still attempts to
> rebase most or all of the feature branches before merging them.
> Possibly depending on their ancestry.
Yes, I know that. But what I am hoping is that
I tried this option after upgrading my git.
Unfortunately, no matter which variation I use, it still attempts to
rebase most or all of the feature branches before merging them.
Possibly depending on their ancestry.
On Mon, 7 Jan 2019 at 22:12, Andreas Hennings wrote:
>
> It sounds good!
> I was
It sounds good!
I was using git version 2.7.4 all the time. I should have checked
before posting here :)
Now trying 2.20.1
>From "git help rebase":
By default, or when no-rebase-cousins was specified,
commits which do not have as direct ancestor will keep
their
original bra
Andreas Hennings writes:
> This means we need a rebase operation where:
> - The commits of the acceptance branch itself are being replaced.
> - The commits of the feature branches remain as they are.
>
> A "git rebase --preserve-merges" almost does this, but not really.
This wished-for feature s
sal
Add a new option for rebase, similar to --preserve-merges, where:
Instead of "git pick MERGE_COMMIT", we get this line in the rebase
editor (if using the -i option):
exec git merge MERGE_COMMIT^2 -m"Merge FEATURE_BRANCH into acceptance."
In --interactive / -i mode, the deve
Merry Christmas, everyone!
I've finally had some free time to throw together the changes I promised
a couple weeks ago, so now git-merge will support --cleanup just like
git-commit.
Not related to this but while I was making my changes, I noticed that -F
and -m don't die properly in
On Wed, Nov 14, 2018 at 12:31:22PM +, Luke Diamand wrote:
> On Fri, 9 Nov 2018 at 10:48, Jeff King wrote:
> >
> > On Fri, Nov 09, 2018 at 10:44:10AM +, Luca Milanesio wrote:
> >
> > > > On 9 Nov 2018, at 10:42, Jeff King wrote:
> > > >
> &
On Fri, 9 Nov 2018 at 10:48, Jeff King wrote:
>
> On Fri, Nov 09, 2018 at 10:44:10AM +, Luca Milanesio wrote:
>
> > > On 9 Nov 2018, at 10:42, Jeff King wrote:
> > >
> > > Git Merge 2019 is happening on February 1st. There will be a
> > > Cont
On Fri, Nov 09, 2018 at 10:44:10AM +, Luca Milanesio wrote:
> > On 9 Nov 2018, at 10:42, Jeff King wrote:
> >
> > Git Merge 2019 is happening on February 1st. There will be a
> > Contributor's Summit the day before. Here are the details:
> >
> > W
> On 9 Nov 2018, at 10:42, Jeff King wrote:
>
> Git Merge 2019 is happening on February 1st. There will be a
> Contributor's Summit the day before. Here are the details:
>
> When: Thursday, January 31, 2019. 10am-5pm.
> Where: The Egg[1], Brussels, Belgium
>
Git Merge 2019 is happening on February 1st. There will be a
Contributor's Summit the day before. Here are the details:
When: Thursday, January 31, 2019. 10am-5pm.
Where: The Egg[1], Brussels, Belgium
What: Round-table discussion about Git
Who: All contributors to Git or related pro
"Derrick Stolee via GitGitGadget" writes:
> As I was testing the release candidate, I stumbled across a regression in
> 'git merge-base' as a result of the switch to generation numbers. The commit
> message in [PATCH 1/1] describes the topology involved, but
Junio C Hamano writes:
> Well, reading builtin/merge-base.c::handle_fork_point(), I think the
> intended behaviour is:
>
> - die() when input is not well formed (e.g. bad commit object,
>ambigous ref name, etc.); there is an error worth reporting in
>this case.
>
> - show one that used
Eric Sunshine writes:
> On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills
> wrote:
>> The following command sequence exits with 1, and no stderr
>>
>> base='remotes/origin/dev';
>> fork_point="$(git merge-base --fork-point "$base")";
>
On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills
wrote:
> The following command sequence exits with 1, and no stderr
>
> base='remotes/origin/dev';
> fork_point="$(git merge-base --fork-point "$base")";
>
> I cannot figure out why it's exi
The following command sequence exits with 1, and no stderr
base='remotes/origin/dev';
fork_point="$(git merge-base --fork-point "$base")";
I cannot figure out why it's exiting with 1, but there is no stdout/stderr
-alex
--
Alexander D. Mills
¡¡¡ N
"Derrick Stolee via GitGitGadget" writes:
> As I was testing the release candidate, I stumbled across a regression in
> 'git merge-base' as a result of the switch to generation numbers. The commit
> message in [PATCH 1/1] describes the topology involved,...
I do not
As I was testing the release candidate, I stumbled across a regression in
'git merge-base' as a result of the switch to generation numbers. The commit
message in [PATCH 1/1] describes the topology involved, but you can test it
yourself by comparing 'git merge-base v4.8 v4.9'
t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh
index 3e692454a7..474a850de6 100755
--- a/t/t6029-merge-subtree.sh
+++ b/t/t6029-merge-subtree.sh
@@ -29,6 +29,34 @@ test_expect_success 'subtree available and works like
recursive' '
'
+test_expect_success 'setup
On Tue, Jul 31, 2018 at 02:06:12PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> > ...
> > So here it is fixed, and with a commit message. I'm not happy to omit a
> > regression test, but I actually couldn't come up with a min
Am 31.07.2018 um 17:50 schrieb Jeff King:
> On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote:
>
>> Bisecting around, this might be the commit that introduced the breakage.
>>
>> https://github.com/git/git/commit/d8febde
>>
>> I really hope that it hasn't been broken for 5 years and I
;
+ git checkout --orphan sub &&
+ git rm -rf . &&
+ test_commit foo
+'
+
+test_expect_success 'setup branch main' '
+ git checkout -b main master &&
+ git merge -s ours --no-commit --allow-unrelated-histories sub &&
+
Jeff King writes:
> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> ...
> So here it is fixed, and with a commit message. I'm not happy to omit a
> regression test, but I actually couldn't come up with a minimal one that
> tickled the problem, because we're playing around with heuris
On Tue, Jul 31, 2018 at 03:52:26PM -0400, George Shammas wrote:
> This is the fastest I ever seen an open source project respond to an issue
> I reported. Thanks for being awesome!
You're welcome. My speed is an inverse to how embarrassingly long we
carried the bug for. ;)
> > Signed-off-by: Jef
size directly to know if there's
> anything left to look at (which is what tree_entry() was
> doing under the hood)
>
> - rather than do an extra struct assignment to "e1" and
> "e2", we can just access the "entry" field of tree_
tree_desc
directly
That makes us a little more intimate with the tree_desc
code, but that's not uncommon for its callers.
There's no regression test here, as it's a little tricky to
trigger this with a minimal example. The user-visible effect
is that the heuristics fail to correlat
On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +...
> > + } else if (cmp > 0) {
> > /* path2 does not appear in one */
> > + score += score_missing(two.entry.mode, two.entry.path);
> > +
Jeff King writes:
> +...
> + } else if (cmp > 0) {
> /* path2 does not appear in one */
> + score += score_missing(two.entry.mode, two.entry.path);
> + update_tree_entry(&two);
> + continue;
> +
On Tue, Jul 31, 2018 at 08:53:23AM -0700, Junio C Hamano wrote:
> George Shammas writes:
>
> > Bisecting around, this might be the commit that introduced the breakage.
> >
> > https://github.com/git/git/commit/d8febde
>
> Interesting. I've never used the "-s subtree" strategy without
> "-Xsubt
Jeff King writes:
> The problem introduced in that commit is that each iteration through the
> loop advances the tree pointers.
Ah, indeed.
The original used tree_entry_extract() and update_tree_entry()
separately, but the update does tree_entry() on both sides.
> So the assertion in that co
While debugging this, I did try -X subtree=src/ however the effect was the
same.
On Tue, Jul 31, 2018 at 11:53 AM Junio C Hamano wrote:
> George Shammas writes:
>
> > Bisecting around, this might be the commit that introduced the breakage.
> >
> > https://github.com/git/git/commit/d8febde
>
> I
George Shammas writes:
> Bisecting around, this might be the commit that introduced the breakage.
>
> https://github.com/git/git/commit/d8febde
Interesting. I've never used the "-s subtree" strategy without
"-Xsubtree=..." to explicitly tell where the thing should go for a
long time, so I am no
t;
> > I have confirmed that it works correctly in 1.7.10. The 2.18 behavior is
> > clearly incorrect.
> >
> > git init
> > echo init > test
> > git add test
> > git commit -m init
> >
> > git remote add tig https://github.com/jonas/tig.git
&g
gt;
> git init
> echo init > test
> git add test
> git commit -m init
>
> git remote add tig https://github.com/jonas/tig.git
> git fetch tig
> git merge -s ours --no-commit --allow-unrelated-histories tig-2.3.0
> git read-tree --prefix=src/ -u tig-2.3.0
> git commit
.
git init
echo init > test
git add test
git commit -m init
git remote add tig https://github.com/jonas/tig.git
git fetch tig
git merge -s ours --no-commit --allow-unrelated-histories tig-2.3.0
git read-tree --prefix=src/ -u tig-2.3.0
git commit -m "Get upstream tig-2.3.0"
# Notice how th
The syntax "git merge HEAD " has been removed. The
order of the syntax should also be updated.
Signed-off-by: Meng-Sung Wu
---
Documentation/git-merge.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge
Meng-Sung Wu writes:
> The syntax "git merge HEAD " has been removed. The
> order of the syntax should also be updated.
> ---
> Documentation/git-merge.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
An obviously good change. Could you please sign-o
The syntax "git merge HEAD " has been removed. The
order of the syntax should also be updated.
---
Documentation/git-merge.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index d5dfd8430..6a5c00e2c 10
On 12/06/2018, Junio C Hamano wrote:
> Sam Kuper writes:
>> [...] It makes sense that `git am [--skip|--abort]` and `git rebase
>> [--skip|--abort]` would run `git rerere clear`.
>>
>> However, if they run it, then shouldn't `git merge --abort` run it, too?
>&
s sense that `git am [--skip|--abort]` and `git rebase
> [--skip|--abort]` would run `git rerere clear`.
>
> However, if they run it, then shouldn't `git merge --abort` run it, too?
>
> If not, then what is the reason why not, and might it be helpful for
> this reason to be
[--skip|--abort]` would run `git rerere clear`.
However, if they run it, then shouldn't `git merge --abort` run it, too?
If not, then what is the reason why not, and might it be helpful for
this reason to be mentioned at some appropriate place in the
documentation?
Thanks :)
On 15 May 2018 at 00:58, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, May 14 2018, demerphq wrote:
>
>> The first time I tried to use --no-ff I tried to do something like this:
>>
>> git checkout master
>> git commit -a -m'whatever'
>> git comm
On Mon, May 14 2018, demerphq wrote:
> The first time I tried to use --no-ff I tried to do something like this:
>
> git checkout master
> git commit -a -m'whatever'
> git commit -a -m'whatever2'
> git merge --no-ff origin/master
>
> and was dis
The first time I tried to use --no-ff I tried to do something like this:
git checkout master
git commit -a -m'whatever'
git commit -a -m'whatever2'
git merge --no-ff origin/master
and was disappointed when "it didn't work" and git told me there was
no
Hi,
Am Freitag, den 04.05.2018, 07:43 -0700 schrieb Elijah Newren:
> On Fri, May 4, 2018 at 3:18 AM, Heiko Voigt wrote:
> > Hi,
> >
> > On Fri, May 04, 2018 at 08:29:32AM +, Middelschulte, Leif wrote:
> > > Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
>
>
> > > > It seem
On Fri, May 4, 2018 at 3:18 AM, Heiko Voigt wrote:
> Hi,
>
> On Fri, May 04, 2018 at 08:29:32AM +, Middelschulte, Leif wrote:
>> Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
>> > It seems to me that you do not want to mix integration testing and
>> > testing of the feature
Hi,
On Fri, May 04, 2018 at 08:29:32AM +, Middelschulte, Leif wrote:
> Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
> > I still do not understand how the current behaviour is mismatching with
> > users expectations. Let's assume that you directly tracked the files of
> > L i
Hi,
Am Donnerstag, den 03.05.2018, 18:42 +0200 schrieb Heiko Voigt:
> Hi,
>
> On Wed, May 02, 2018 at 07:30:25AM +, Middelschulte, Leif wrote:
> > Am Montag, den 30.04.2018, 19:02 +0200 schrieb Heiko Voigt:
> > > On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote:
> > > > Stefan wro
Hi,
On Wed, May 02, 2018 at 07:30:25AM +, Middelschulte, Leif wrote:
> Am Montag, den 30.04.2018, 19:02 +0200 schrieb Heiko Voigt:
> > On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote:
> > > Stefan wrote:
> > > > See
> > > > https://github.com/git/git/commit/68d03e4a6e448aa557f52
Am Montag, den 30.04.2018, 19:02 +0200 schrieb Heiko Voigt:
> On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote:
> > Stefan wrote:
> > > See
> > > https://github.com/git/git/commit/68d03e4a6e448aa557f52adef92595ac4d6cd4bd
> > > (68d03e4a6e (Implement automatic fast-forward merge for su
On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote:
> Stefan wrote:
> > See
> > https://github.com/git/git/commit/68d03e4a6e448aa557f52adef92595ac4d6cd4bd
> > (68d03e4a6e (Implement automatic fast-forward merge for submodules,
> > 2010-07-07)
> > to explain the situation you encounter.
On Fri, Apr 27, 2018 at 5:24 PM, Elijah Newren wrote:
> I would expect that a different example involving non-linear history
> would behave the same, if both sides update the submodule in a fashion
> that is just fast-forwarding and one commit contains the other in its
> history. I'm curious if y
Hi,
On Fri, Apr 27, 2018 at 3:37 AM, Middelschulte, Leif
wrote:
> Am Donnerstag, den 26.04.2018, 17:19 -0700 schrieb Elijah Newren:
>> On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif
>> wrote:
>> > Problem case: Merge either branch into the other
>> >
>> > Expected behavior: Merge conflict
Hi,
firstofall: thank all of you for your feedback.
Am Donnerstag, den 26.04.2018, 17:19 -0700 schrieb Elijah Newren:
> On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif
> wrote:
> > Hi,
> >
> > we're using git-flow as a basic development workflow. However, doing so
> > revealed unexpected
On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif
wrote:
> Hi,
>
> we're using git-flow as a basic development workflow. However, doing so
> revealed unexpected merge-behavior by git.
>
> Assume the following setup:
>
> - Repository `S` is sourced by repository `p` as submodule `s`
> - Reposit
On Thu, Apr 26, 2018 at 2:46 PM, Jacob Keller wrote:
> On Thu, Apr 26, 2018 at 10:56 AM, Stefan Beller wrote:
>> We often treating a submodule as a file from the superproject, but not
>> always.
>> And in case of a merge, git seems to be a bit smarter than treating it
>> as a textfile
>> with tw
Stefan wrote:
> See https://github.com/git/git/commit/68d03e4a6e448aa557f52adef92595ac4d6cd4bd
> (68d03e4a6e (Implement automatic fast-forward merge for submodules,
> 2010-07-07)
> to explain the situation you encounter. (specifically merge_submodule
> at the end of the diff)
+cc Heiko, author of
On Thu, Apr 26, 2018 at 10:56 AM, Stefan Beller wrote:
> We often treating a submodule as a file from the superproject, but not always.
> And in case of a merge, git seems to be a bit smarter than treating it
> as a textfile
> with two different lines.
Sure, but a submodule is checked out "at a c
On Thu, Apr 26, 2018 at 3:49 AM, Middelschulte, Leif
wrote:
> Hi,
>
> we're using git-flow as a basic development workflow. However, doing so
> revealed unexpected merge-behavior by git.
>
> Assume the following setup:
>
> - Repository `S` is sourced by repository `p` as submodule `s`
> - Reposit
Hi,
we're using git-flow as a basic development workflow. However, doing so
revealed unexpected merge-behavior by git.
Assume the following setup:
- Repository `S` is sourced by repository `p` as submodule `s`
- Repository `p` has two branches: `feature_x` and `develop`
- The revisions sourced
Brandon Williams writes:
> On 03/26, Jeff Hostetler wrote:
[...]
>> All of these cases could be eliminated if the type/size were available
>> in the OID.
>>
>> Just a thought. While we are converting to a new hash it seems like
>> this would be a good time to at least discuss it.
>
> Echoing wh
mit --amend --author 'Author ' --no-edit # generate a new hash
> sed -i '/55/d' file
> git commit -a -m 'Removed 55'
> git checkout master
> git merge --no-edit other
> git diff other # Should be equal
This isn't a bug; it's the expected behavior
-m 'Initial'
sed -i "s/^5/5\n55/" file
git commit -a -m 'Added 55'
git checkout -b other HEAD^
git cherry-pick master
git commit --amend --author 'Author ' --no-edit # generate a new hash
sed -i '/55/d' file
git commit -a -m 'Removed 55
1 - 100 of 526 matches
Mail list logo
