Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

larsi@gnus.org (Lars Ingebrigtsen) writes:

> branch: master
> commit bdda935a7d9519b71822270cf98328ae236b257d
> Merge: ada0b9b df2ae3f
> Author: Lars Ingebrigtsen <larsi@openbsd6.gnus.org>
> Commit: Lars Ingebrigtsen <larsi@openbsd6.gnus.org>
>
>     Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

Eep!  What did I do?

This was from my OpenBSD installation, and I forgot to install my
.gitconfig file there.

Did I mess anything up badly?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 16 Aug 2020 20:34:44 +0200
> 
> larsi@gnus.org (Lars Ingebrigtsen) writes:
> 
> > branch: master
> > commit bdda935a7d9519b71822270cf98328ae236b257d
> > Merge: ada0b9b df2ae3f
> > Author: Lars Ingebrigtsen <larsi@openbsd6.gnus.org>
> > Commit: Lars Ingebrigtsen <larsi@openbsd6.gnus.org>
> >
> >     Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs
> 
> Eep!  What did I do?

Probably "git pull" after committing, but before pushing that commit.

> This was from my OpenBSD installation, and I forgot to install my
> .gitconfig file there.
> 
> Did I mess anything up badly?

No, it happens all the time, and we don't bother noticing.  Look at
the result of "git log --graph", and you will see it's okay, looks
like a merge from a branch.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Did I mess anything up badly?
>
> No, it happens all the time, and we don't bother noticing.  Look at
> the result of "git log --graph", and you will see it's okay, looks
> like a merge from a branch.

*phew*  Thanks.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Robert Pluim]

>>>>> On Sun, 16 Aug 2020 20:34:44 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> larsi@gnus.org (Lars Ingebrigtsen) writes:
    >> branch: master
    >> commit bdda935a7d9519b71822270cf98328ae236b257d
    >> Merge: ada0b9b df2ae3f
    >> Author: Lars Ingebrigtsen <larsi@openbsd6.gnus.org>
    >> Commit: Lars Ingebrigtsen <larsi@openbsd6.gnus.org>
    >> 
    >> Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

    Lars> Eep!  What did I do?

    Lars> This was from my OpenBSD installation, and I forgot to install my
    Lars> .gitconfig file there.

You forgot to add '--rebase' to your 'git pull'.

    Lars> Did I mess anything up badly?

No. Although no doubt thereʼs somebody who's now offended by the
'non-clean' git history for emacs.

Robert

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Stefan Monnier]

> You forgot to add '--rebase' to your 'git pull'.

Doesn't Git offer some way to *merge* (not rebase) but with the branches swapped?
[ As if you merged HEAD into dest rather than the reverse ]


        Stefan

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Robert Pluim]

>>>>> On Mon, 17 Aug 2020 10:57:11 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> You forgot to add '--rebase' to your 'git pull'.
    Stefan> Doesn't Git offer some way to *merge* (not rebase) but with the branches swapped?
    Stefan> [ As if you merged HEAD into dest rather than the reverse ]

Probably, but I donʼt know how. I just set up git to auto-rebase, and
spare my limited brain cycles for other stuff :-)

Robert

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 17 Aug 2020 16:15:43 +0200
> Cc: emacs-devel@gnu.org
> 
> You forgot to add '--rebase' to your 'git pull'.

No, please try to avoid using "pull --rebase".  It can have bad
consequences in some corner cases.  Just "pull" is TRT, as it will
perform a merge, and the result is perfectly okay for Emacs, as we
decided long ago.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Andreas Schwab]

On Aug 17 2020, Stefan Monnier wrote:

> Doesn't Git offer some way to *merge* (not rebase) but with the branches swapped?

A merge always uses HEAD as the first parent, so if you want to swap,
swap HEAD.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Paul Eggert]

On 8/17/20 8:58 AM, Eli Zaretskii wrote:
> No, please try to avoid using "pull --rebase".  It can have bad
> consequences in some corner cases.  Just "pull" is TRT

Yes, "pull --rebase" causes more trouble than it cures.

I avoid the problem by never committing anything to my local copy of the master 
branch unless I immediately push the result. Very occasionally someone else is 
committing at the same time so my push fails; in that case I delete my master 
branch, re-create it from upstream, and start over. So when I do "git pull" I 
never need to rebase and I never need to merge. This is cleaner and simpler than 
the alternatives, at least for me.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Yes, "pull --rebase" causes more trouble than it cures.
>
> I avoid the problem by never committing anything to my local copy of
> the master branch unless I immediately push the result.

I always do a pull --rebase.  Or, that is, I have this in my
~/.gitconfig:

[pull]
	rebase = true

Which I didn't have in my OpenBSD vm, which caused the confusion.

> Very occasionally someone else is committing at the same time so my
> push fails; in that case I delete my master branch, re-create it from
> upstream, and start over. So when I do "git pull" I never need to
> rebase and I never need to merge. This is cleaner and simpler than the
> alternatives, at least for me.

I don't really see any problems with the commit/pull --rebase/push flow?
Nobody else even knows that I've done it, which is how it should be.

The number of times I've needed to do a merge with that flow is...  I
can count them on two fingers, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Paul Eggert]

On 8/17/20 9:26 AM, Lars Ingebrigtsen wrote:
> I don't really see any problems with the commit/pull --rebase/push flow?
> Nobody else even knows that I've done it, which is how it should be.

A problem is that sometimes *you* don't even know that you've done it. :-)

Don't you have issues with your commit IDs diverging from upstream? How do you 
refer to commits when you send email to others?

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 17 Aug 2020 17:37:33 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> I just set up git to auto-rebase

Please don't.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Don't you have issues with your commit IDs diverging from upstream?
> How do you refer to commits when you send email to others?

Oh, I don't.  :-)  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> Cc: larsi@gnus.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 17 Aug 2020 09:11:21 -0700
> 
> I avoid the problem by never committing anything to my local copy of the master 
> branch unless I immediately push the result. Very occasionally someone else is 
> committing at the same time so my push fails; in that case I delete my master 
> branch, re-create it from upstream, and start over. So when I do "git pull" I 
> never need to rebase and I never need to merge. This is cleaner and simpler than 
> the alternatives, at least for me.

Yes, avoiding the need for this is better, but we are only human...

We decided long ago that doing an automatic merge during "pull" is
okay, so these rare incidents are not serious enough to worry about.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Robert Pluim <rpluim@gmail.com>,
>   emacs-devel@gnu.org
> Date: Mon, 17 Aug 2020 18:26:30 +0200
> 
> I always do a pull --rebase.

Please don't.  It can cause subtle problems in some rare cases.  Or at
least that's how it was in the past.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Please don't.  It can cause subtle problems in some rare cases.  Or at
> least that's how it was in the past.

If so, it's changed.  There's nothing magical much about rebasing: It's
just removing any local check-ins that are newer than the remote,
fetching the remote, and then re-applying those removed check-ins as new
check-ins.

Like I said, I use rebasing all the time, and how many commits have I
made?

larsi@xo:~/src/emacs/trunk$ git log | grep Commit:.*Ingebrigtsen* | wc -l
3217

Well, OK, some of them are from before we moved to git, but...

Seems pretty safe to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 17 Aug 2020 20:03:58 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Please don't.  It can cause subtle problems in some rare cases.  Or at
> > least that's how it was in the past.
> 
> If so, it's changed.  There's nothing magical much about rebasing:

I didn't say it was magical, I said it can cause subtle problems.  I
forget the details, but rebasing after merging could bring the same
commit more than once.  Or something like that.

Why do you feel the need to rebase?  The default merge that pull does
is as "non-magical" as rebase.

> Seems pretty safe to me.

Until it isn't.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't say it was magical, I said it can cause subtle problems.  I
> forget the details, but rebasing after merging could bring the same
> commit more than once.  Or something like that.

I don't see how.  It's just three very simple operations in one: 1)
Remove your own recent commits.  (Can't fail.)  2) Pull from the
remote.  (Can't fail; there's no newer commits in the local tree.)  3)
Apply the removed commits as patches, and re-commit.  (Can fail if
there's a conflict -- which has to be handled the normal way.)

There's "philosophical" issues with rebasing (in that you're pretending
that your own changes are newer than the remote ones), but that's not
something we care about.  

> Why do you feel the need to rebase?  The default merge that pull does
> is as "non-magical" as rebase.

Well, as we saw here, we got the extra, useless "merge" commit email (of
interest to nobody), which started this whole thread.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Rebasing vs merging (was: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs)

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: eggert@cs.ucla.edu,  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Mon, 17 Aug 2020 20:03:58 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Please don't.  It can cause subtle problems in some rare cases.  Or at
>> > least that's how it was in the past.
>> 
>> If so, it's changed.  There's nothing magical much about rebasing:
>
> I didn't say it was magical, I said it can cause subtle problems.  I
> forget the details, but rebasing after merging could bring the same
> commit more than once.  Or something like that.
>
> Why do you feel the need to rebase?  The default merge that pull does
> is as "non-magical" as rebase.

Rebasing keeps your local changes well localized: on top of upstream
commits instead of mixed with the rest of the history. Plus, once you
send your changes upstream, the result is a linear history or a merge
point consisting of your changes on a side and the rest on the other
side, instead of a maze of changes. Plus+, it is far easier to
self-review and correct your local changes before you send them
upstream, so if your hipotetical "double commit" appears (I have never
seen that, but whatever) it would be immediately obvious.

>> Seems pretty safe to me.
>
> Until it isn't.

Many projects (including Git itself) use rebase as a routine. OTOH, for
the reasons mentioned above, I'll say that unwarranted merges are what
cause problems.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 17 Aug 2020 20:43:02 +0200
> 
> Well, as we saw here, we got the extra, useless "merge" commit email (of
> interest to nobody), which started this whole thread.  :-)

We have a gazillion of those already.  One more or one less don't
matter.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Stefan Monnier]

>> Doesn't Git offer some way to *merge* (not rebase) but with the branches swapped?
> A merge always uses HEAD as the first parent, so if you want to swap,
> swap HEAD.

How can I do that in a way that as seamless as `git merge`?


        Stefan

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Andreas Schwab]

On Aug 17 2020, Stefan Monnier wrote:

>>> Doesn't Git offer some way to *merge* (not rebase) but with the branches swapped?
>> A merge always uses HEAD as the first parent, so if you want to swap,
>> swap HEAD.
>
> How can I do that in a way that as seamless as `git merge`?

You just need to make sure HEAD points to the commit you want as the
first parent.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[David De La Harpe Golden]

maybe I'm paranoid but in general using git, I tend to only do "git pull 
--ff-only" (or rather, I default to it in my .gitconfig) and if that 
errors out I always just fall back to a git fetch / <inspect situation> 
/ git merge, see also e.g.

https://blog.sffc.xyz/post/185195398930/why-you-should-use-git-pull-ff-only

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Stefan Monnier]

>>>> Doesn't Git offer some way to *merge* (not rebase) but with the branches swapped?
>>> A merge always uses HEAD as the first parent, so if you want to swap,
>>> swap HEAD.
>> How can I do that in a way that as seamless as `git merge`?
> You just need to make sure HEAD points to the commit you want as the
> first parent.

No, I want the following:

- I'm in a Git worktree with HEAD pointing at some local change of mine.
- I do `git ..magical..merge..`
- Now I'm in a worktree where HEAD was merged with the upstream branch
  and the upstream branch (rather than HEAD) is the first branch.

Technically within Git it's a small matter of the order in which the
parents are listed in the commit.  The question is how to get Git to do
it using the available command line API.

I know several ways to do that, but none of them are as seamless as `git
merge` w.r.t things like execution time, treatment of non-committed changes,
or the set of files whose mtime is affected.


        Stefan

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Yuri Khan]

On Tue, 18 Aug 2020 at 03:32, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> No, I want the following:
>
> - I'm in a Git worktree with HEAD pointing at some local change of mine.
> - I do `git ..magical..merge..`
> - Now I'm in a worktree where HEAD was merged with the upstream branch
>   and the upstream branch (rather than HEAD) is the first branch.

The Emacs git porcelain that we Should Not Mention (Until Certain
Things Happen) has bindings both to merge another branch into current
*and* to merge current branch into another. By default, it suggests
the upstream branch as long as git knows about it.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Stefan Monnier]

> The Emacs git porcelain that we Should Not Mention (Until Certain
> Things Happen) has bindings both to merge another branch into current
> *and* to merge current branch into another. By default, it suggests
> the upstream branch as long as git knows about it.

The question then becomes: how does Magit do that?  (or does it come
with the same caveats that I mentioned regarding execution time,
treatment of non-committed changes, the set of files whose mtime is
affected, ...)


        Stefan

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Yuri Khan]

On Tue, 18 Aug 2020 at 23:48, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> The question then becomes: how does Magit do that?  (or does it come
> with the same caveats that I mentioned regarding execution time,
> treatment of non-committed changes, the set of files whose mtime is
> affected, ...)

I think it checks out the other branch, then merges the current
branch, then does whatever cleanup necessary. (That does not include
restoring mtimes and recovering spent time.)

Generally speaking, merging while the working copy is dirty is not
recommended, the reason being, if the merge results in conflicts,
you’d probably like to be able to use the working copy to resolve
them. Having uncommitted changes there makes things confusing,
especially if they themselves conflict with the changes in any of the
branches being merged.

Mtime probably changes for every file that changes during the
intermediate checkout and the subsequent merge.

Raymond Chen of Microsoft once described a technique to craft commits
in a Git repository without ever touching the working copy, because
that would change the mtimes of some files and subsequently trigger a
rebuild, and/or be slow due to updating the working copy:

1. [Building a commit manually out of a
tree](https://devblogs.microsoft.com/oldnewthing/20190506-00/?p=102478)
2. [Building a merge commit manually out of a
tree](https://devblogs.microsoft.com/oldnewthing/20190507-00/?p=102480)

That assumes that the hard part of the merge (i.e. actual merge and
conflict resolution) is already done and the result recorded in a tree
somewhere in Git, though.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Basil L. Contovounesios]

David De La Harpe Golden <david@harpegolden.net> writes:

> maybe I'm paranoid but in general using git, I tend to only do "git pull
> --ff-only" (or rather, I default to it in my .gitconfig) and if that errors out
> I always just fall back to a git fetch / <inspect situation> / git merge, see
> also e.g.
>
> https://blog.sffc.xyz/post/185195398930/why-you-should-use-git-pull-ff-only

Am I the only one who prefers doing separate 'git fetch' and 'git
merge/rebase' operations, and never uses 'git pull'? :)

This way I get to see exactly what's changed upstream, whether it
conflicts with my local changes, decide whether I want/need to
merge/rebase, etc. etc.

-- 
Basil

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Amin Bandali]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

Basil L. Contovounesios writes:

[...]
>
> Am I the only one who prefers doing separate 'git fetch' and 'git
> merge/rebase' operations, and never uses 'git pull'? :)
>
> This way I get to see exactly what's changed upstream, whether it
> conflicts with my local changes, decide whether I want/need to
> merge/rebase, etc. etc.

Not much substance to add, but same here.  I generally try to start at
the tip of the branch (i.e. its latest commit) I plan to commit to, in
order to avoid the need for rebasing or merging whenever possible.  Once
I'm done writing, I fetch and review upstream changes if any, carefully
rebase my own commit(s) on top of them, and push.  It's worked out very
well for my (admittedly mostly small-scoped) changes to various git
repositories thus far.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Madhu]

* Stefan Monnier <jwvsgcj6gve.fsf-monnier+emacs@gnu.org> :
Wrote on Tue, 18 Aug 2020 12:48:27 -0400:

> The question then becomes: how does Magit do that?  (or does it come
> with the same caveats that I mentioned regarding execution time,
> treatment of non-committed changes, the set of files whose mtime is
> affected, ...)

to preserve mtimes

git branch #=> mybranch
git-new-workdir.sh . /dev/shm/emacs
cd /dev/shm/emacs; git checkout master; git pull
git rebase master mybranch
cd -
git checkout -f mybranch  # touches only new files.
rm -rf /dev/shm/emacs

Rebasing vs. merging

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

* 2020-08-17 20:43:02+02, Lars Ingebrigtsen wrote:

> There's "philosophical" issues with rebasing (in that you're
> pretending that your own changes are newer than the remote ones), but
> that's not something we care about.

Another "philosophical" issue with rebasing is that the resulting code
is not necessarily tested anymore. I mean:

 1. Write new code based on upstream commit AAAA.
 2. Test the new code: OK, it's working.
 3. Want to push the code to the upstream.
 4. Upstream branch has advanced to commit BBBB.
 5. "git pull --rebase" so that the new code is now based on BBBB.
 6. "git push" pushes untested code to the upstream.

The new code is not tested because the code's base commit is not the
same. The committer may insist that everything was OK and really tested
but actually he didn't really test the resulting code. It's easy to fix
the procedure:

 6. Test the code again.
 7. "git push"

But it could be argued that it's nicer to show person's own and other
people's works in separate development branches and that is what merging
does. So it can be seen: "My branch really worked, just 'git checkout'
it and try, but it broke when I merged it with the upstream. Now let's
find out why these two branches together cause trouble." Maybe this kind
of recorded development history is useful in bug hunting too.

-- 
/// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: Rebasing vs. merging

[Kévin Le Gouguec]

Teemu Likonen <tlikonen@iki.fi> writes:

> Another "philosophical" issue with rebasing is that the resulting code
> is not necessarily tested anymore. I mean:
>
>  1. Write new code based on upstream commit AAAA.
>  2. Test the new code: OK, it's working.
>  3. Want to push the code to the upstream.
>  4. Upstream branch has advanced to commit BBBB.
>  5. "git pull --rebase" so that the new code is now based on BBBB.
>  6. "git push" pushes untested code to the upstream.

How is the --rebase flag responsible for the ultimate issue (untested
code pushed upstream)?  Step 6 could happen just as well with a merge
unless I'm missing something?

>       So it can be seen: "My branch really worked, just 'git checkout'
> it and try, but it broke when I merged it with the upstream. Now let's
> find out why these two branches together cause trouble." Maybe this kind
> of recorded development history is useful in bug hunting too.

Focusing on merge commits may be a good heuristic to find *when*
(i.e. at which recorded point in the VC history) things broke, but it's
not a big help to find *why* IMO.  No issue will show up on either
branch until the merge, so you're just left with an unintelligibly big
diff to make sense of.

When it comes to bug hunting, I find it more straightforward to bisect
on a linear history.  Eventually I'll find which rebased commit is
responsible for the breakage, and it will be easier to find the issue in
this individual commit's diff.


I don't have a strong opinion on rebasing vs. merging, although FWIW I
do find merge commits noisy, and as explained above they make it less
straightforward (for me) to bisect.

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Stephen Leake]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Am I the only one who prefers doing separate 'git fetch' and 'git
> merge/rebase' operations, and never uses 'git pull'? :)

I always use git fetch first.

-- 
-- Stephe

Re: master bdda935 2/2: Merge branch 'master' of git.savannah.gnu.org:/srv/git/emacs

[Stefan Monnier]

> to preserve mtimes
>
> git branch #=> mybranch
> git-new-workdir.sh . /dev/shm/emacs
> cd /dev/shm/emacs; git checkout master; git pull
> git rebase master mybranch
> cd -
> git checkout -f mybranch  # touches only new files.
> rm -rf /dev/shm/emacs

Right (modulo "rebase" => "merge" and the fact that nowadays I'd use
`git worktree` instead of `git-new-workdir`), but this option comes with
the other caveat that it requires extra disk space, can take
significantly longer (because of the need to create all those files),
and requires you to do the conflict resolution in another tree (which
can be problematic if you want/need to compile something during the
resolution since nothing's compiled there yet so it'll take extra time
to `./configure` and compile).

IOW it's pretty far from "as seamless as `git merge`".


        Stefan

Re: Rebasing vs. merging

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Cc: rpluim@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
> Date: Wed, 19 Aug 2020 12:13:08 +0300
> 
> * 2020-08-17 20:43:02+02, Lars Ingebrigtsen wrote:
> 
> > There's "philosophical" issues with rebasing (in that you're
> > pretending that your own changes are newer than the remote ones), but
> > that's not something we care about.
> 
> Another "philosophical" issue with rebasing is that the resulting code
> is not necessarily tested anymore.

Please note that I didn't want to start any "philosophical" arguments
wrt Git, nor have another "merge vs rebase" argument, of which we had
enough in the past, I think.  All I wanted to say was that we have
discussed this in the past, and decided to use a merge-based workflow
(bugfixes are pushed to the stable branch and then merged to master),
and to stop caring about the merge-commits created by Git when there's
a "push race".

At some point we considered to advise "pull --rebase" or its variants,
but a discussion in Dec 2014 revealed that mixing rebasing with
merge-based workflow can be dangerous, especially if one does local
merges from public branches.  If you have time and motivation, please
read the thread starting at

  https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01444.html

If someone wants to discuss this specific issue, feel free.  But let's
not have another "merge vs rebase" dispute.

Thanks.

Re: Rebasing vs. merging

[Paul Eggert]

On 8/19/20 7:51 AM, Eli Zaretskii wrote:
> If you have time and motivation, please read the thread starting at
> 
>    https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01444.html

I wasn't involved in that thread (though perhaps I should have been, as one of 
its topics was a botched rebase+merge that lost of one of my commits :-), so I 
just now read it. A few remarks:

* The botched rebase+merge there was due to our old practice of putting 
ChangeLog patches into each commit. We've stopped doing that (thank goodness), 
so that particular botch wouldn't happen under our current development practice. 
Of course similar problems could still occur in other files, though they're less 
likely.

* The thread's key bit of advice was David Engster's "Never rebase commits that 
are upstream." 
<https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg01468.html> This is 
indeed good advice. The git-rebase man page has more details on this for those 
interested.

* Rebasing local commits works just fine with a merge-based workflow, and I do 
it all the time in Emacs development. It's OK even if you have local branches 
and merges, so long as you consistently follow David's advice.

* That being said, I don't use local merges, as a primary role of merges is to 
support collaboration and I collaborate very poorly with myself (because I 
always get into arguments :-).

Re: Rebasing vs. merging

[John Wiegley]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:

EZ> Please note that I didn't want to start any "philosophical" arguments wrt
EZ> Git, nor have another "merge vs rebase" argument, of which we had enough
EZ> in the past, I think. All I wanted to say was that we have discussed this
EZ> in the past, and decided to use a merge-based workflow (bugfixes are
EZ> pushed to the stable branch and then merged to master), and to stop caring
EZ> about the merge-commits created by Git when there's a "push race".

Thanks Eli, I think this is a reasonable pattern to continue with.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2