git commit/push and VC

git commit/push and VC

[Stephen Berman]

I'm still learning how to use git, and have two questions about `git
commit' and `git push'.  I've read the "GitForEmacsDevs" page at
emacswiki.org and Conversational Git (recommended on that page), and
unless I'm misunderstanding something (which is not unlikely), they
disagree about what's needed to export changes from one repository to
another, or from one branch to another within a single repository.
Conversational Git say to use `git commit' and then `git push'.
GitForEmacsDevs says this:

   If you are a committer, you can merge to the upstream master directly.

   First, update your repository:
   
         cd $DEVHOME/emacs
         git checkout master
         git pull
         git merge TASKNAME
         git push
   
   Run the tests:
   
         make check
   
   and then commit
   
         git status
         git commit -m "fixes debbugs:12345"
   
   which merges all your new commits to the upstream master.

I don't understand why `git commit' follows `git push' here (or why
there isn't another `git push' after `git commit').  Indeed, I've done
local tests of moving changes between branches and repositories, and
they appear to confirm what Conversational Git says: unless `git push'
follows `git commit', the changes are not available in the other branch
or repositories.  So is GitForEmacsDevs wrong or is there something else
going on here?

My second question is about using VC in Emacs.  With bzr, typing `C-c
C-c' in the *vc-log* buffer exported my local trunk changes to trunk at
Savannah, because my local trunk was a bound branch.  But according to
my local tests, with git typing `C-c C-c' in the *vc-log* buffer only
commits the changes to the checked out branch; they do not show up in
branch or repository the checked out branch was branched from (or its
repository was cloned from).  Is this correct?  I don't want to
accidentally push changes to master or another branch at Savannah.  And
if `C-c C-c' does only do commits on the checked out local branch, it is
possible to use VC to push changes to another branch or repository, and
if so, how?

Steve Berman

Re: git commit/push and VC

[Glenn Morris]

Stephen Berman wrote:

> possible to use VC to push changes to another branch or repository, and
> if so, how?

`vc-pull' exists, but nobody wrote (or nobody pushed, ha ha) `vc-push'.

Eg
http://debbugs.gnu.org/12415
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00267.html
http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00842.html

Re: git commit/push and VC

[Stephen Berman]

On Wed, 19 Nov 2014 21:07:08 -0500 Glenn Morris <rgm@gnu.org> wrote:

> Stephen Berman wrote:
>
>> possible to use VC to push changes to another branch or repository, and
>> if so, how?
>
> `vc-pull' exists, but nobody wrote (or nobody pushed, ha ha) `vc-push'.
>
> Eg
> http://debbugs.gnu.org/12415
> http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00267.html
> http://lists.gnu.org/archive/html/emacs-devel/2010-05/msg00842.html

On Thu, 20 Nov 2014 10:29:30 +0700 Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Thu, Nov 20, 2014 at 5:36 AM, Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> GitForEmacsDevs says this:
>>
>>    If you are a committer, you can merge to the upstream master directly.
>>
>>    First, update your repository:
>>
>>          cd $DEVHOME/emacs
>>          git checkout master
>>          git pull
>>          git merge TASKNAME
>>          git push
>>
>>    Run the tests:
>>
>>          make check
>>
>>    and then commit
>>
>>          git status
>>          git commit -m "fixes debbugs:12345"
>>
>>    which merges all your new commits to the upstream master.
>>
>> I don't understand why `git commit' follows `git push' here (or why
>> there isn't another `git push' after `git commit').
>
> Indeed, the instruction quoted above is strange.
[...]

Thanks to both of you for the replies.  I see that GitForEmacsDevs on
the Wiki has been updated in the mean time, so it's clearer (and
hopefully correct) now.

Steve Berman

Re: git commit/push and VC

[Yuri Khan]

On Thu, Nov 20, 2014 at 5:36 AM, Stephen Berman <stephen.berman@gmx.net> wrote:

> GitForEmacsDevs says this:
>
>    If you are a committer, you can merge to the upstream master directly.
>
>    First, update your repository:
>
>          cd $DEVHOME/emacs
>          git checkout master
>          git pull
>          git merge TASKNAME
>          git push
>
>    Run the tests:
>
>          make check
>
>    and then commit
>
>          git status
>          git commit -m "fixes debbugs:12345"
>
>    which merges all your new commits to the upstream master.
>
> I don't understand why `git commit' follows `git push' here (or why
> there isn't another `git push' after `git commit').

Indeed, the instruction quoted above is strange.

Strangeness 1: It assumes that your local master branch has not
diverged from remote master, so “git pull” is a fast-forward. (If this
assumption is incorrect, “git pull” will optionally require you to
resolve merge conflicts, and will introduce a superfluous merge
commit.)

There are two cases how your local master can diverge from remote master:

a. You have some local development going on in local master, unrelated
to TASKNAME. (In a feature-branch-oriented workflow, it should not
happen.)
b. Someone has rewritten the remote history. (By the talks about the
receive.denyNonFastForwards setting on the Emacs central repository
earlier on this list, it looks like the maintainers have decided to
disallow such rewriting.)

Strangeness 2: It suggests to push before running tests.

Presumably, tests exist so that you can check that your work has not
broken anything before sharing it with the world. In that case, you
want to run them before pushing.

Strangeness 3: It tells you to commit after you have just merged and pushed.

Assuming “make check” does not have any effect on the tracked files,
there are no changes that could be committed at this point.

The -m "fixes debbugs:12345" is supposed to go into the commit
message, but there won’t be any commit. Presumably, this line should
go into the message of the merge commit made by “git merge TASKNAME”.

If that merge generates conflicts, you can edit the merge commit
message when committing the merge after having resolved the conflicts.
However, if no conflicts arise, “git merge” will commit the merge
automatically.

To add to the merge commit message, you can either run git merge with
the --no-commit flag and commit manually afterwards, or, immediately
after git merge finishes, you can run git commit --amend.

Re: git commit/push and VC

[Eli Zaretskii]

> Date: Thu, 20 Nov 2014 10:29:30 +0700
> From: Yuri Khan <yuri.v.khan@gmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > GitForEmacsDevs says this:
> >
> >    If you are a committer, you can merge to the upstream master directly.
> >
> >    First, update your repository:
> >
> >          cd $DEVHOME/emacs
> >          git checkout master
> >          git pull
> >          git merge TASKNAME
> >          git push
> >
> >    Run the tests:
> >
> >          make check
> >
> >    and then commit
> >
> >          git status
> >          git commit -m "fixes debbugs:12345"
> >
> >    which merges all your new commits to the upstream master.
> >
> > I don't understand why `git commit' follows `git push' here (or why
> > there isn't another `git push' after `git commit').
> 
> Indeed, the instruction quoted above is strange.

These instructions were simply wrong.  You will see that I raised some
of these issues as early as last January:

  http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00790.html

but nothing was done about that.

I now fixed the instructions as best I could; please read and comment.

There are still issues that I'd like to be sure about before I fix
them.  Would people please comment on these:

  . the instructions say that a "git commit" is necessary even when
    the merge is without conflicts, which AFAIK is incorrect with Git

  . do we want to tell there that "pull --rebase" is recommended? that
    would solve some of the issues the instructions are forced to
    explain in so many words, which unnecessarily complicates them

  . do we want to explicitly recommend 2 different clones, one each
    for master and the release branch? there's nothing in the
    instructions about this, or about working with 2 divergent
    branches in general

  . GitQuickStartForEmacsDevs advises to use "git ci -a"; why not
    suggest the same in GitForEmacsDevs? it seems a simpler setup

  . there's a link to GitForEmacsCasualDevs, which doesn't exist.  Do
    we need yet another, 3rd set of instructions, in addition to the 2
    we already have?

Re: git commit/push and VC

[Achim Gratz]

Eli Zaretskii writes:
> There are still issues that I'd like to be sure about before I fix
> them.  Would people please comment on these:
>
>   . the instructions say that a "git commit" is necessary even when
>     the merge is without conflicts, which AFAIK is incorrect with Git

In standard configuration a non-conflicted merge will be auto-committed,
yes.  As always, that default can be configured to instead stop before
the commit.

>   . do we want to tell there that "pull --rebase" is recommended? that
>     would solve some of the issues the instructions are forced to
>     explain in so many words, which unnecessarily complicates them

I'm still in favor of configuring that preference, rather than asking
for options to be added to each command.

>   . do we want to explicitly recommend 2 different clones, one each
>     for master and the release branch? there's nothing in the
>     instructions about this, or about working with 2 divergent
>     branches in general

I've just got a new computer and it takes all of 0.6 seconds to switch
from master to emacs-24.  I've had a much slower one until two days ago
and I don't think it took longer than about 5 seconds even there.
Unless you're really working all the time in parallel on both branches
I'd say this setup is more trouble than it's worth.  Especially not for
the folks who expect Bzr semantics from this setup…

>   . GitQuickStartForEmacsDevs advises to use "git ci -a"; why not
>     suggest the same in GitForEmacsDevs? it seems a simpler setup

That is no git command.  Assuming that ci is an alias for commit, then
no, that is not a good recommendation in general.  If the only changes
you have belong to a single commit (a quick bugfix, say) then it saves a
bit of typing.  But if the changes should really be goign to different
commits for clarity, then this is ill-advised.  Again, if you use magit
you can even chose which hunk of a diff goes into each commit.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: git commit/push and VC

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 20 Nov 2014 19:17:43 +0100

Thanks for your comments.  A few responses below.

> >   . do we want to explicitly recommend 2 different clones, one each
> >     for master and the release branch? there's nothing in the
> >     instructions about this, or about working with 2 divergent
> >     branches in general
> 
> I've just got a new computer and it takes all of 0.6 seconds to switch
> from master to emacs-24.  I've had a much slower one until two days ago
> and I don't think it took longer than about 5 seconds even there.

You are missing the point.  Switching the branch is easy, but after
that, you'd almost always need a full bootstrap, which might become
annoying.

> Unless you're really working all the time in parallel on both branches
> I'd say this setup is more trouble than it's worth.

I personally am working on both branches in parallel, yes.  Many
others do, too.  Bugfixes go to one branch, new features to the other,
people report bugs on this or other, etc.  Bootstrapping each time,
which takes a couple of minutes, is annoying.  And then you sometimes
want to compare what the two binaries, one from master, the other from
the release branch, do in the same situation.

But that's me, and I already know how to solve this.  I'm asking what,
if anything, do we want to recommend.

> >   . GitQuickStartForEmacsDevs advises to use "git ci -a"; why not
> >     suggest the same in GitForEmacsDevs? it seems a simpler setup
> 
> That is no git command.  Assuming that ci is an alias for commit, then
> no, that is not a good recommendation in general.  If the only changes
> you have belong to a single commit (a quick bugfix, say) then it saves a
> bit of typing.  But if the changes should really be goign to different
> commits for clarity, then this is ill-advised.

We are talking about simplified instructions here, mind you.  Don't
take that as a general advice for advanced users: they don't need
these instructions.

Re: git commit/push and VC

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > >   . do we want to explicitly recommend 2 different clones, one each
 > > >     for master and the release branch? there's nothing in the
 > > >     instructions about this, or about working with 2 divergent
 > > >     branches in general

 > > Unless you're really working all the time in parallel on both branches
 > > I'd say this setup is more trouble than it's worth.

 > I personally am working on both branches in parallel, yes.  Many
 > others do, too.  Bugfixes go to one branch, new features to the other,
 > people report bugs on this or other, etc.  Bootstrapping each time,
 > which takes a couple of minutes, is annoying.  And then you sometimes
 > want to compare what the two binaries, one from master, the other from
 > the release branch, do in the same situation.
 > 
 > But that's me, and I already know how to solve this.  I'm asking what,
 > if anything, do we want to recommend.

I would say either go with *your* gut feeling, or if you prefer,
somebody else you trust. ;-)  You could also present several scenarios
with expected issues (people can probably judge the merits for
themselves, but the downside of messing up a personal repo is quite
large).  I can think of the following:

1) single clone, multiple out-of-tree build directories (this is what
   I use).  Disadvantages: IIRC Emacs uses the same "link lisp/ ->
   $srcdir/lisp" strategy that XEmacs does, so bootstrap takes a long
   time, and the first make after switching is likely to take a long
   time even if you don't bootstrap (because checked-out files all
   appear to have been touched).  There will be several emacs binaries
   associated with the clone, so there is potential for confusion
   between the running Emacs and the checked-out version.

2) single clone, in-tree build.  Disadvantages: as (1), but even more
   so, except that it's easier to keep emacs in synch with the sources
   as there's only one binary in existence.

3) multiple clones, build per clone (I don't think it much matters
   whether it is in-tree or not, and people who use out-of-tree builds
   probably have other reasons for doing that already, and they'll
   know what they are doing).  Disadvantages: one of the clones will
   be used for "stable" -> trunk merges and reverse cherry-picking,
   and you need to keep track of which one.  You also need a lot more
   VCS operations to keep them in synch.

4) single repo, multiple workspaces (use GITDIR variable, for
   example).  Disadvantages: not well-supported by git AFAIK, so the
   user has to keep track of the global branch.

Maybe you shouldn't mention (4).

Steve

Re: git commit/push and VC

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 21 Nov 2014 09:31:17 +0900
> Cc: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
> 
>  > But that's me, and I already know how to solve this.  I'm asking what,
>  > if anything, do we want to recommend.
> 
> I would say either go with *your* gut feeling, or if you prefer,
> somebody else you trust. ;-)

I don't yet trust my gut feeling with Git, except with features I
myself have enough experience with.  This particular one is not among
them, as all the other projects where I gained my Git experience don't
present problems with several branches in the same tree.

> 1) single clone, multiple out-of-tree build directories (this is what
>    I use).  Disadvantages: IIRC Emacs uses the same "link lisp/ ->
>    $srcdir/lisp" strategy that XEmacs does, so bootstrap takes a long
>    time, and the first make after switching is likely to take a long
>    time even if you don't bootstrap (because checked-out files all
>    appear to have been touched).  There will be several emacs binaries
>    associated with the clone, so there is potential for confusion
>    between the running Emacs and the checked-out version.
> 
> 2) single clone, in-tree build.  Disadvantages: as (1), but even more
>    so, except that it's easier to keep emacs in synch with the sources
>    as there's only one binary in existence.
> 
> 3) multiple clones, build per clone (I don't think it much matters
>    whether it is in-tree or not, and people who use out-of-tree builds
>    probably have other reasons for doing that already, and they'll
>    know what they are doing).  Disadvantages: one of the clones will
>    be used for "stable" -> trunk merges and reverse cherry-picking,
>    and you need to keep track of which one.  You also need a lot more
>    VCS operations to keep them in synch.
> 
> 4) single repo, multiple workspaces (use GITDIR variable, for
>    example).  Disadvantages: not well-supported by git AFAIK, so the
>    user has to keep track of the global branch.
> 
> Maybe you shouldn't mention (4).

I tend to recommend 3), but I don't understand the disadvantages; can
you elaborate?  I thought it was possible to merge between clones, are
you saying that's not a good idea?

Re: git commit/push and VC

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>

 > > 3) multiple clones, build per clone (I don't think it much matters
 > >    whether it is in-tree or not, and people who use out-of-tree builds
 > >    probably have other reasons for doing that already, and they'll
 > >    know what they are doing).  Disadvantages: one of the clones will
 > >    be used for "stable" -> trunk merges and reverse cherry-picking,
 > >    and you need to keep track of which one.  You also need a lot more
 > >    VCS operations to keep them in synch.

 > I tend to recommend 3), but I don't understand the disadvantages; can
 > you elaborate?  I thought it was possible to merge between clones, are
 > you saying that's not a good idea?

The disadvantages are relatively minor.  Technically speaking, it's
not possible in git to merge between clones, you have to fetch and
then merge (== pull).  But aside from this difference in terminology,
this should be familiar to bzr and Mercurial users who use multiple
workspaces.  (In fact Mercurial users also use "pull", but it doesn't
update and commit.)

Another issue is that I find it easy to do fixes to the "wrong" branch
in the current repo, and that gets confusing.  I also know how to
unwedge myself now, but I can remember getting confused about the
state of my repos occasionally.  That might just be me, since I was
experimenting with various workflows.

Finally, I just find it more efficient to work in a single clone.

Re: git commit/push and VC

[Yuri Khan]

On Sat, Nov 22, 2014 at 11:30 AM, Stephen J. Turnbull
<stephen@xemacs.org> wrote:

> Another issue is that I find it easy to do fixes to the "wrong" branch
> in the current repo, and that gets confusing.

You can customize your shell prompt to show you which branch you are
on, whether your working copy is dirty, and whether any interruptible
operation is currently in progress (merge, rebase, am, cherry-pick).
See the git-sh-prompt script in your git distribution.

Re: git commit/push and VC

[Stephen J. Turnbull]

Yuri Khan writes:

 > You can

You're missing the point.  This thread is not about teaching users to
change their global configuration.  It's about making minimal changes
to existing workflows to get them to work with git.  The question is
not how to deal with any given issue, but rather whether users will
run into it.

 > customize your shell prompt

And this just isn't sufficient, anyway.  I have had such a shell
prompt since 1988.  It doesn't help that much for reasons I don't
understand, and more important to my case, M-! doesn't show a shell
prompt.

Re: git commit/push and VC

[Ivan Shmakov]

>>>>> Stephen J Turnbull <stephen@xemacs.org> writes:

[…]

 > Technically speaking, it's not possible in git to merge between
 > clones, you have to fetch and then merge (== pull).

	Not necessarily, – you can just as well add the Git (or, rather,
	.git/objects) directory of your “other” clone to your current’s
	.git/objects/info/alternates, which will make the other clone’s
	commits available for any operation – including merge – on the
	current one.  Like, say:

$ cat < emacs-foo/.git/objects 
../../../emacs-bar/.git/objects
../../../emacs-qux/.git/objects
/read/only/archives/git/emacs.git/objects
$ 

	If you do not care about the warning, you can even do this is in
	a cyclic manner:

$ cat < emacs-bar/.git/objects 
../../../emacs-foo/.git/objects
../../../emacs-qux/.git/objects
/read/only/archives/git/emacs.git/objects
$ 

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: git commit/push and VC

[Stephen J. Turnbull]

Ivan Shmakov writes:
 > >>>>> Stephen J Turnbull <stephen@xemacs.org> writes:
 > 
 > […]
 > 
 >  > Technically speaking, it's not possible in git to merge between
 >  > clones, you have to fetch and then merge (== pull).
 > 
 > 	Not necessarily, – you can just as well add the Git (or, rather,
 > 	.git/objects) directory of your “other” clone to your current’s
 > 	.git/objects/info/alternates, which will make the other clone’s
 > 	commits available for any operation – including merge – on the
 > 	current one.

OK, it's possible to avoid the copy/linking operations of fetch, but
you still need to do the merge in the current repo (and typically pull
the ref from the other repo).  There are also reasons why using
alternates is not necessarily great (especially for new users) -- eg,
it means that rebase, commit --amend, filter-branch, and so on can
corrupt the dependent repo.

It's somewhat beside the point, but I don't consider the physical
location of objects in the DAG particularly interesting.  fetch is
usually very cheap even over the network -- one hardly notices it
unless one distrusts coworkers enough to insist on a fetch-review-
merge workflow instead of a pull workflow.

Re: git commit/push and VC

[Ivan Shmakov]

>>>>> Stephen J Turnbull <stephen@xemacs.org> writes:
>>>>> Ivan Shmakov writes:

[…]

 >> Not necessarily, – you can just as well add the Git (or, rather,
 >> .git/objects) directory of your “other” clone to your current’s
 >> .git/objects/info/alternates, which will make the other clone’s
 >> commits available for any operation – including merge – on the
 >> current one.

 > OK, it's possible to avoid the copy/linking operations of fetch, but
 > you still need to do the merge in the current repo

	My understanding was that it was the intent.

 > (and typically pull the ref from the other repo).

	Refs are just human-readable aliases to the commit identifiers.
	It’s perfectly possible to merge in a branch using the latter.

 > There are also reasons why using alternates is not necessarily great
 > (especially for new users) -- eg, it means that rebase, commit
 > --amend, filter-branch, and so on can corrupt the dependent repo.

	Only if the objects comprising the original commit get deleted
	in the process; I’m unsure on what are the conditions to that.

	Otherwise, the objects are immutable, and the likes of --amend
	just create a brand new commit based on the given one; the
	latter being left intact.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: git commit/push and VC

[Stephen J. Turnbull]

Ivan Shmakov writes:

 >  > (and typically pull the ref from the other repo).
 > 
 > 	Refs are just human-readable aliases to the commit identifiers.
 > 	It’s perfectly possible to merge in a branch using the latter.

How do you propose reliably identifying the *current* branch HEAD
without dereferencing that ref?  Even if it's possible, it's likely
beyond the capability of the new users this thread is about.

 >  > There are also reasons why using alternates is not necessarily
 >  > great (especially for new users) -- eg, it means that rebase,
 >  > commit --amend, filter-branch, and so on can corrupt the
 >  > dependent repo.
 > 
 > 	Only if the objects comprising the original commit get deleted
 > 	in the process; I’m unsure on what are the conditions to that.

GC will do it eventually.  Might take a couple months.

 > 	Otherwise, the objects are immutable, and the likes of --amend
 > 	just create a brand new commit based on the given one; the
 > 	latter being left intact.

Yes, I know that.

Re: git commit/push and VC

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Sat, 22 Nov 2014 06:50:51 +0000
> 
>  > Technically speaking, it's not possible in git to merge between
>  > clones, you have to fetch and then merge (== pull).
> 
> 	Not necessarily, – you can just as well add the Git (or, rather,
> 	.git/objects) directory of your “other” clone to your current’s
> 	.git/objects/info/alternates, which will make the other clone’s
> 	commits available for any operation – including merge – on the
> 	current one.  Like, say:
> 
> $ cat < emacs-foo/.git/objects 
> ../../../emacs-bar/.git/objects
> ../../../emacs-qux/.git/objects
> /read/only/archives/git/emacs.git/objects

I don't think it's a good idea to recommend anything like that to
people who use Git for a short time, who are the main audience for the
Wiki recommendations.

Re: git commit/push and VC

[Andreas Schwab]

Ivan Shmakov <ivan@siamics.net> writes:

> 	Not necessarily, – you can just as well add the Git (or, rather,
> 	.git/objects) directory of your “other” clone to your current’s
> 	.git/objects/info/alternates, which will make the other clone’s

You should never do that to link to repositories that are used for
development.  The originating repository doesn't know that others have
borrowed objects, and a garbage collection can remove them under their
feet.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git commit/push and VC

[Ivan Shmakov]

>>>>> Andreas Schwab <schwab@linux-m68k.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >> Not necessarily, – you can just as well add the Git (or, rather,
 >> .git/objects) directory of your “other” clone to your current’s
 >> .git/objects/info/alternates, which will make the other clone’s
 >> commits available for any operation

 > You should never do that to link to repositories that are used for
 > development.  The originating repository doesn't know that others
 > have borrowed objects, and a garbage collection can remove them under
 > their feet.

	Personally, I do not use garbage collection at all.  Instead,
	after I’m finished with the clone, and make sure all its worthy
	commits made it into a separate (--bare) repository, I’d remove
	one in its entirety.

	Sure, I’d unlink it from alternates first, and check if my other
	clones are still valid after that, before the actual removal.

-- 
FSF associate member #7257  np. Conclusion — Apocalyptica    … B6A0 230E 334A

Re: git commit/push and VC

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Stromeko@nexgo.de,
>     emacs-devel@gnu.org
> Date: Sat, 22 Nov 2014 14:30:15 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> 
>  > > 3) multiple clones, build per clone (I don't think it much matters
>  > >    whether it is in-tree or not, and people who use out-of-tree builds
>  > >    probably have other reasons for doing that already, and they'll
>  > >    know what they are doing).  Disadvantages: one of the clones will
>  > >    be used for "stable" -> trunk merges and reverse cherry-picking,
>  > >    and you need to keep track of which one.  You also need a lot more
>  > >    VCS operations to keep them in synch.
> 
>  > I tend to recommend 3), but I don't understand the disadvantages; can
>  > you elaborate?  I thought it was possible to merge between clones, are
>  > you saying that's not a good idea?
> 
> The disadvantages are relatively minor.  Technically speaking, it's
> not possible in git to merge between clones, you have to fetch and
> then merge (== pull).

So to do that inter-clone merge, one would need

  git fetch ../my-other-clone <probably some arguments here>
  git merge <more arguments here>
  # fix conflicts, if any
  git commit -a # only if there were conflicts
  git push

Is that right?  Sounds a bot complicated and error-prone, I agree.

How about the following alternative instead: we do NOT recommend
merging from the other clone.  The other clone is to be used only for
committing to the release branch and, rarely (probably never)
branching off that release branch for doing something that is not a
trivial one-off fix.  To merge to master, we recommend using the clone
that is normally used for working on master and on feature branches
(a.k.a. "master clone").  Specifically, when the time comes to merge
the changes on the release branch to master, we recommend this
sequence of commands in the "master clone":

  git pull
  git merge -m <commit-message> remotes/origin/emacs-24
  # fix conflicts, if any
  # run tests, fix bugs if any
  git commit -a # only if there were conflicts
  git push

Is this correct?  Because if it is, it's just like the "normal" merge
workflow, just with the name of the merge source branch slightly
special.  So it's easier to remember and less error-prone, I think.

The main point is to avoid "git checkout emacs-24" in the "master
clone" as much as possible, because once you switch back to master,
the build will most probably be annoyingly long.

> Another issue is that I find it easy to do fixes to the "wrong" branch
> in the current repo, and that gets confusing.

Does that happen with separate clones also?  I thought separate clones
make this less likely, since they allow you to seldom, if ever, switch
between master and the release branch in the same repo.

> Finally, I just find it more efficient to work in a single clone.

I agree, but I think the Emacs use case is special in this respect,
especially for people who are not proficient enough with Git.

Re: git commit/push and VC

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > So to do that inter-clone merge, one would need
 > 
 >   git fetch ../my-other-clone <probably some arguments here>
 >   git merge <more arguments here>
 >   # fix conflicts, if any
 >   git commit -a # only if there were conflicts
 >   git push
 > 
 > Is that right?  Sounds a bot complicated and error-prone, I agree.

Well, the first two commands can probably be reduced to "git pull
../my-other-clone".

But it seems reasonably likely that both branches exist in at least
one of the clones, because "git diff" requires that the commits being
compared be in the same repo, and referring to them via SHA1 is chancy
at best.  I *think* that the worst thing that is likely to happen is
that the user has emacs-24 checked out in this clone, does "git pull
../my-other-clone emacs-24", and gets a null update but think you've
actually merged into trunk.  The fix is trivial, check out trunk and
redo.

 > How about the following alternative instead: we do NOT recommend
 > merging from the other clone.  The other clone is to be used only for
 > committing to the release branch and, rarely (probably never)
 > branching off that release branch for doing something that is not a
 > trivial one-off fix.  To merge to master, we recommend using the clone
 > that is normally used for working on master and on feature branches
 > (a.k.a. "master clone").  Specifically, when the time comes to merge
 > the changes on the release branch to master, we recommend this
 > sequence of commands in the "master clone":
 > 
 >   git pull
 >   git merge -m <commit-message> remotes/origin/emacs-24
 >   # fix conflicts, if any
 >   # run tests, fix bugs if any
 >   git commit -a # only if there were conflicts
 >   git push
 > 
 > Is this correct?  Because if it is, it's just like the "normal" merge
 > workflow, just with the name of the merge source branch slightly
 > special.  So it's easier to remember and less error-prone, I think.

I think just "git pull -e ../emacs-24" and edit the commit message is
clearer, instead of pull and merging.  The "-e" is unnecessary in more
recent git.

 > The main point is to avoid "git checkout emacs-24" in the "master
 > clone" as much as possible, because once you switch back to master,
 > the build will most probably be annoyingly long.

With this workflow, the user should *never* need to do that.

 > > Another issue is that I find it easy to do fixes to the "wrong" branch
 > > in the current repo, and that gets confusing.
 > 
 > Does that happen with separate clones also?  I thought separate clones
 > make this less likely, since they allow you to seldom, if ever, switch
 > between master and the release branch in the same repo.

Yes -- as I say, it's possibly just me.  I often end up with buffers
from both workspaces open on the correponding files.

 > > Finally, I just find it more efficient to work in a single clone.
 > 
 > I agree, but I think the Emacs use case is special in this respect,
 > especially for people who are not proficient enough with Git.

I suppose so.

Re: git commit/push and VC

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Stromeko@nexgo.de,
>     emacs-devel@gnu.org
> Date: Sat, 22 Nov 2014 18:36:34 +0900
> 
>  >   git fetch ../my-other-clone <probably some arguments here>
>  >   git merge <more arguments here>
>  >   # fix conflicts, if any
>  >   git commit -a # only if there were conflicts
>  >   git push
>  > 
>  > Is that right?  Sounds a bot complicated and error-prone, I agree.
> 
> Well, the first two commands can probably be reduced to "git pull
> ../my-other-clone".
> 
> But it seems reasonably likely that both branches exist in at least
> one of the clones, because "git diff" requires that the commits being
> compared be in the same repo, and referring to them via SHA1 is chancy
> at best.

Yes, so I think merging from another clone is unnecessary.

>  >   git pull
>  >   git merge -m <commit-message> remotes/origin/emacs-24
>  >   # fix conflicts, if any
>  >   # run tests, fix bugs if any
>  >   git commit -a # only if there were conflicts
>  >   git push
>  > 
>  > Is this correct?  Because if it is, it's just like the "normal" merge
>  > workflow, just with the name of the merge source branch slightly
>  > special.  So it's easier to remember and less error-prone, I think.
> 
> I think just "git pull -e ../emacs-24" and edit the commit message is
> clearer, instead of pull and merging.

I don't think we need the "../" part, do we?  It's the same
repository, and emacs-24 is the name of a branch, not a directory.

I wonder if it's a good idea to tell people to pull from a different
branch, though.  It could cause errors down the road (not in this
scenario).  FWIW, I'd be nervous to do that.

Re: git commit/push and VC

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think just "git pull -e ../emacs-24" and edit the commit message is
>> clearer, instead of pull and merging.
>
> I don't think we need the "../" part, do we?  It's the same
> repository, and emacs-24 is the name of a branch, not a directory.

You don't pull from a branch, you pull from a repository.  That's the
operation that copies objects from one repository to another.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git commit/push and VC

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: "Stephen J. Turnbull" <stephen@xemacs.org>,  Stromeko@nexgo.de,  emacs-devel@gnu.org
> Date: Sat, 22 Nov 2014 12:31:41 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I think just "git pull -e ../emacs-24" and edit the commit message is
> >> clearer, instead of pull and merging.
> >
> > I don't think we need the "../" part, do we?  It's the same
> > repository, and emacs-24 is the name of a branch, not a directory.
> 
> You don't pull from a branch, you pull from a repository.  That's the
> operation that copies objects from one repository to another.

Ah, okay, thanks.

However, I was asking about merging from the release branch in the
same repository, just without checking out the release branch in that
repository, ever.  In that case, I think this will do (assuming
'master' is checked out):

  git pull
  git merge emacs-24
  # fix conflicts, if any
  # run tests, fix bugs
  git commit -a
  git push

Am I missing something in this sequence?

Re: git commit/push and VC

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> However, I was asking about merging from the release branch in the
> same repository, just without checking out the release branch in that
> repository, ever.  In that case, I think this will do (assuming
> 'master' is checked out):
>
>   git pull
>   git merge emacs-24

You want to merge the remote-tracking branch origin/emacs-24.  That's
what git pull (or rather git fetch) will update.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git commit/push and VC

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: stephen@xemacs.org,  Stromeko@nexgo.de,  emacs-devel@gnu.org
> Date: Sat, 22 Nov 2014 14:00:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > However, I was asking about merging from the release branch in the
> > same repository, just without checking out the release branch in that
> > repository, ever.  In that case, I think this will do (assuming
> > 'master' is checked out):
> >
> >   git pull
> >   git merge emacs-24
> 
> You want to merge the remote-tracking branch origin/emacs-24.  That's
> what git pull (or rather git fetch) will update.

Thanks.  Just to be sure, the correct merge command should be

  git merge remotes/origin/emacs-24

is that right?

Re: git commit/push and VC

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks.  Just to be sure, the correct merge command should be
>
>   git merge remotes/origin/emacs-24
>
> is that right?

You can abbreviate it to origin/emacs-24.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: git commit/push and VC

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: stephen@xemacs.org,  Stromeko@nexgo.de,  emacs-devel@gnu.org
> Date: Sat, 22 Nov 2014 15:12:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Thanks.  Just to be sure, the correct merge command should be
> >
> >   git merge remotes/origin/emacs-24
> >
> > is that right?
> 
> You can abbreviate it to origin/emacs-24.

Thanks.

Re: git commit/push and VC

[martin rudalics]

 > You are missing the point.  Switching the branch is easy, but after
 > that, you'd almost always need a full bootstrap, which might become
 > annoying.

A bootstrap takes more than half an hour on my machines.  Having touched
one C header file means that rebuilding takes almost 10 minutes here.
Calling that "annoying" would be an understatement.  Having multiple
clones is an essential prerequsite here.

 > I personally am working on both branches in parallel, yes.  Many
 > others do, too.  Bugfixes go to one branch, new features to the other,
 > people report bugs on this or other, etc.  Bootstrapping each time,
 > which takes a couple of minutes, is annoying.  And then you sometimes
 > want to compare what the two binaries, one from master, the other from
 > the release branch, do in the same situation.

This is my workflow as well.  Which doesn't exclude that git's branching
concept might be useful even here.  Sometimes, at least.

 > But that's me, and I already know how to solve this.  I'm asking what,
 > if anything, do we want to recommend.

Among others, the switch to MSYS has made building on Windows slow down
by a factor of two here (at least that's the impression I get).  And I
never gave bisecting a thought on my machine even before that change.
In addition, recent changes to C mode has made editing C files slower by
a factor of two here.  So I'm hardly going to tolerate further slowdowns
caused by switching branches.

Mine might be an exotic case and the only useful recommendation for me
is probably to get myself a new machine.  Nevertheless I doubt that all
Emacs users have suitable hardware that makes switching between master
and Emacs-24 a feasible operation in one and the same clone.

martin

Re: git commit/push and VC

[Eli Zaretskii]

> Date: Fri, 21 Nov 2014 09:23:55 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > You are missing the point.  Switching the branch is easy, but after
>  > that, you'd almost always need a full bootstrap, which might become
>  > annoying.
> 
> A bootstrap takes more than half an hour on my machines.

Are you using "make -jN"?  If not, I highly recommend trying that.  On
a Core i7 system, "make -j6" (if you have XP) or "make -j8" (Windows 7
and later) can work wonders on your build time.

> Having touched one C header file means that rebuilding takes almost
> 10 minutes here.

That's strange: compiling C sources is very fast, most of the
bootstrap time is spent compiling Lisp.  What kind of CPU do you have
there?

>  > I personally am working on both branches in parallel, yes.  Many
>  > others do, too.  Bugfixes go to one branch, new features to the other,
>  > people report bugs on this or other, etc.  Bootstrapping each time,
>  > which takes a couple of minutes, is annoying.  And then you sometimes
>  > want to compare what the two binaries, one from master, the other from
>  > the release branch, do in the same situation.
> 
> This is my workflow as well.  Which doesn't exclude that git's branching
> concept might be useful even here.  Sometimes, at least.

Of course, it's useful: for branches that don't diverge too much from
the branch you fork off, like feature branches, for example.

> Among others, the switch to MSYS has made building on Windows slow down
> by a factor of two here (at least that's the impression I get).

If "make -jN" is not speedy enough, consider replacing your work disk
with an SSD.  The build will fly.

> I doubt that all Emacs users have suitable hardware that makes
> switching between master and Emacs-24 a feasible operation in one
> and the same clone.

For those who need to do that frequently, I agree.

Re: git commit/push and VC

[Dani Moncayo]

>> Having touched one C header file means that rebuilding takes almost
>> 10 minutes here.
>
> That's strange: compiling C sources is very fast, most of the
> bootstrap time is spent compiling Lisp.

FWIW: I agree, and that, I think, is one reason why it would be great
to move large subsystems like GNUS or CEDET into GNU ELPA;
bootstrapping would be much faster.

-- 
Dani Moncayo

Re: git commit/push and VC

[martin rudalics]

 > Are you using "make -jN"?  If not, I highly recommend trying that.  On
 > a Core i7 system, "make -j6" (if you have XP) or "make -j8" (Windows 7
 > and later) can work wonders on your build time.

I can try that next time.  But my last bootstrap before the git switch
was a couple of months ago, so I doubt it would matter much.

 >> Having touched one C header file means that rebuilding takes almost
 >> 10 minutes here.
 >
 > That's strange: compiling C sources is very fast, most of the
 > bootstrap time is spent compiling Lisp.

Compiling Lisp files has never been an annoyance to me.  It's my
impression that I spend most of the time entering and leaving
directories, loading files, updating subdirectories, generating
autoloads, checking whether files have changed.  And configuring, if
necessary.

 > What kind of CPU do you have
 > there?

Windows XP here runs on a 1.80GHz Pentium Dual CPU.

 > Of course, it's useful: for branches that don't diverge too much from
 > the branch you fork off, like feature branches, for example.

I yet have to find out whether that's the case here.

 >> Among others, the switch to MSYS has made building on Windows slow down
 >> by a factor of two here (at least that's the impression I get).
 >
 > If "make -jN" is not speedy enough, consider replacing your work disk
 > with an SSD.  The build will fly.

;-)

martin

Re: git commit/push and VC

[Eli Zaretskii]

> Date: Fri, 21 Nov 2014 11:24:56 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Stromeko@nexgo.de, emacs-devel@gnu.org
> 
>  > Are you using "make -jN"?  If not, I highly recommend trying that.  On
>  > a Core i7 system, "make -j6" (if you have XP) or "make -j8" (Windows 7
>  > and later) can work wonders on your build time.
> 
> I can try that next time.  But my last bootstrap before the git switch
> was a couple of months ago, so I doubt it would matter much.

"make -j" speeds up normal builds as well.

>  > What kind of CPU do you have there?
> 
> Windows XP here runs on a 1.80GHz Pentium Dual CPU.

Then I'd suggest "make -j2", and expect that to slash the times by a
factor of 2.

Re: git commit/push and VC

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Thu, 20 Nov 2014 22:59:07 +0200

   Switching the branch is easy, but after that, you'd almost
   always need a full bootstrap, which might become annoying.

The pain point seems to be bootstrap, so might as well
address it directly in the instructions: "If hacking TOPIC
will require bootstrap, then probably you want a separate
working tree on branch TOPIC.  Otherwise, you can use the
same working tree and switch branches."

   We are talking about simplified instructions here, mind
   you.  Don't take that as a general advice for advanced
   users: they don't need these instructions.

I think it's okay to have a small conditional branch (argh,
another overloaded use of that word!) in these instructions.
Being explicit about intent puts the onus of choice on the
reader, which is where it belongs when it comes to managing
pain.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

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

Re: git commit/push and VC

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Fri, 21 Nov 2014 09:49:07 +0100
> 
>    Switching the branch is easy, but after that, you'd almost
>    always need a full bootstrap, which might become annoying.
> 
> The pain point seems to be bootstrap, so might as well
> address it directly in the instructions: "If hacking TOPIC
> will require bootstrap, then probably you want a separate
> working tree on branch TOPIC.

The main point here is not hacking TOPIC, it's working in parallel in
master and in release branch.  Those diverge very fast in Emacs, so
switching almost always will require a full bootstrap.  Most, if not
all, of the other use cases can use a single clone.

>    We are talking about simplified instructions here, mind
>    you.  Don't take that as a general advice for advanced
>    users: they don't need these instructions.
> 
> I think it's okay to have a small conditional branch (argh,
> another overloaded use of that word!) in these instructions.
> Being explicit about intent puts the onus of choice on the
> reader, which is where it belongs when it comes to managing
> pain.

If you mean that the instructions should explain the considerations
for and against using "commit -a", then I don't think that's the place
for that.  The text might say "we recommend using 'commit -a' because
it avoids the need to use 'git add', except when you add new files",
but that's about all.  The Wiki is not the place for describing these
choices in too much detail, or we will lose the reader's attention.
That page is already too long, IMO; I moved some of the stuff to the
end of it so it doesn't interfere with the workflow description.

Re: git commit/push and VC

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 20 Nov 2014 19:17:43 +0100
> 
> Eli Zaretskii writes:
> > There are still issues that I'd like to be sure about before I fix
> > them.  Would people please comment on these:
> >
> >   . the instructions say that a "git commit" is necessary even when
> >     the merge is without conflicts, which AFAIK is incorrect with Git
> 
> In standard configuration a non-conflicted merge will be auto-committed,
> yes.  As always, that default can be configured to instead stop before
> the commit.

OK, so if we are going to recommend to use "commit -a" (and actually
we already do, see the Wiki), then I guess "git add" after resolving
merge conflicts is also not necessary, right?  That is, instead of
this:

  git merge master
  # resolve conflicts
  git add file-you-changed
  git commit -m "Merge from mainline."

we should recommend this:

  git merge master
  # resolve conflicts
  git commit -a -m "Merge from mainline."

Is that correct?

> >   . do we want to tell there that "pull --rebase" is recommended? that
> >     would solve some of the issues the instructions are forced to
> >     explain in so many words, which unnecessarily complicates them
> 
> I'm still in favor of configuring that preference, rather than asking
> for options to be added to each command.

Yes, of course.

Thanks.

Re: git commit/push and VC

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Achim Gratz <Stromeko@nexgo.de>
>> Date: Thu, 20 Nov 2014 19:17:43 +0100
>> 
>> Eli Zaretskii writes:
>> > There are still issues that I'd like to be sure about before I fix
>> > them.  Would people please comment on these:
>> >
>> >   . the instructions say that a "git commit" is necessary even when
>> >     the merge is without conflicts, which AFAIK is incorrect with Git
>> 
>> In standard configuration a non-conflicted merge will be auto-committed,
>> yes.  As always, that default can be configured to instead stop before
>> the commit.
>
> OK, so if we are going to recommend to use "commit -a" (and actually
> we already do, see the Wiki), then I guess "git add" after resolving
> merge conflicts is also not necessary, right?  That is, instead of
> this:
>
>   git merge master
>   # resolve conflicts
>   git add file-you-changed
>   git commit -m "Merge from mainline."
>
> we should recommend this:
>
>   git merge master
>   # resolve conflicts
>   git commit -a -m "Merge from mainline."
>
> Is that correct?

I doubt that it works.  At any rate, Git does not distinguish between a
file with merge conflict markers and one without merge conflict markers
(which are valid file contents, after all).

It records unresolved conflicts in the index where they are overwritten
when doing git-add.  I haven't checked whether git commit -a will
actually overwrite a conflicted index.  If it does, we don't want to
recommend that error-prone workflow which is likely to record files with
unresolved conflicts as resolved.  If it doesn't, git commit -a will not
help.  smerge-mode, incidentally, adds the file in question
automatically anyway after all conflicts are resolved.  So if "# resolve
conflicts" implies use of smerge-mode, just git commit should be enough.

-- 
David Kastrup

Re: git commit/push and VC

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 22 Nov 2014 11:43:16 +0100
> 
> >   git merge master
> >   # resolve conflicts
> >   git commit -a -m "Merge from mainline."
> >
> > Is that correct?
> 
> I doubt that it works.  At any rate, Git does not distinguish between a
> file with merge conflict markers and one without merge conflict markers
> (which are valid file contents, after all).
> 
> It records unresolved conflicts in the index where they are overwritten
> when doing git-add.  I haven't checked whether git commit -a will
> actually overwrite a conflicted index.  If it does, we don't want to
> recommend that error-prone workflow which is likely to record files with
> unresolved conflicts as resolved.  If it doesn't, git commit -a will not
> help.  smerge-mode, incidentally, adds the file in question
> automatically anyway after all conflicts are resolved.  So if "# resolve
> conflicts" implies use of smerge-mode, just git commit should be enough.

Ah, okay, so we should mention smerge-mode there.  Thanks.

Re: git commit/push and VC

[Eli Zaretskii]

> Date: Sat, 22 Nov 2014 13:01:26 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: David Kastrup <dak@gnu.org>
> > Date: Sat, 22 Nov 2014 11:43:16 +0100
> > 
> > It records unresolved conflicts in the index where they are overwritten
> > when doing git-add.  I haven't checked whether git commit -a will
> > actually overwrite a conflicted index.  If it does, we don't want to
> > recommend that error-prone workflow which is likely to record files with
> > unresolved conflicts as resolved.  If it doesn't, git commit -a will not
> > help.  smerge-mode, incidentally, adds the file in question
> > automatically anyway after all conflicts are resolved.  So if "# resolve
> > conflicts" implies use of smerge-mode, just git commit should be enough.
> 
> Ah, okay, so we should mention smerge-mode there.  Thanks.

What about non-content conflicts, though?  AFAIK, smerge-mode doesn't
handle those, so "git add" might still be necessary?

Re: git commit/push and VC

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 22 Nov 2014 13:01:26 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: emacs-devel@gnu.org
>> 
>> > From: David Kastrup <dak@gnu.org>
>> > Date: Sat, 22 Nov 2014 11:43:16 +0100
>> > 
>> > It records unresolved conflicts in the index where they are overwritten
>> > when doing git-add.  I haven't checked whether git commit -a will
>> > actually overwrite a conflicted index.  If it does, we don't want to
>> > recommend that error-prone workflow which is likely to record files with
>> > unresolved conflicts as resolved.  If it doesn't, git commit -a will not
>> > help.  smerge-mode, incidentally, adds the file in question
>> > automatically anyway after all conflicts are resolved.  So if "# resolve
>> > conflicts" implies use of smerge-mode, just git commit should be enough.
>> 
>> Ah, okay, so we should mention smerge-mode there.  Thanks.
>
> What about non-content conflicts, though?  AFAIK, smerge-mode doesn't
> handle those, so "git add" might still be necessary?

"git add" is definitely the main way to add a resolution to the index
(though resolving a file changed in one branch and removed in another
might instead be done using "git rm").

That using smerge-mode will save you from manually doing that is worth
mentioning, but prescribing smerge-mode (and omitting mention of git
add) rather than recommending its use is definitely overdoing it.

-- 
David Kastrup

Re: git commit/push and VC

[Stephen Berman]

On Thu, 20 Nov 2014 17:45:36 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Thu, 20 Nov 2014 10:29:30 +0700
>> From: Yuri Khan <yuri.v.khan@gmail.com>
>> Cc: Emacs developers <emacs-devel@gnu.org>
>> 
>> > GitForEmacsDevs says this:
>> >
>> >    If you are a committer, you can merge to the upstream master directly.
>> >
>> >    First, update your repository:
>> >
>> >          cd $DEVHOME/emacs
>> >          git checkout master
>> >          git pull
>> >          git merge TASKNAME
>> >          git push
>> >
>> >    Run the tests:
>> >
>> >          make check
>> >
>> >    and then commit
>> >
>> >          git status
>> >          git commit -m "fixes debbugs:12345"
>> >
>> >    which merges all your new commits to the upstream master.
>> >
>> > I don't understand why `git commit' follows `git push' here (or why
>> > there isn't another `git push' after `git commit').
>> 
>> Indeed, the instruction quoted above is strange.
>
> These instructions were simply wrong.  You will see that I raised some
> of these issues as early as last January:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00790.html
>
> but nothing was done about that.
>
> I now fixed the instructions as best I could; please read and comment.

The only comment I'm qualified to make is: it's much clearer now, thanks.

Steve Berman