A simple git workflow for the rest of us

A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

I have committed the text below to admin/notes.  I expect all git
experts to be all horrified and stuff, but if you don't care about git
kremlinology, but just want to fix bugs and stuff in Emacs, I don't
think you really need to know.

Feel free to fix the recipes in admin/notes.  But please refrain from
using the words "ref", "staging", "stash" or "local".

--------------

(This is a draft.  The method here won't actually work yet, because
neither git-new-workdir nor merge-changelog are in the Emacs
distribution yet.)

Setting up and using git for normal, simple bugfixing
=====================================================

If you haven't configured git before you should first do:

git config --global user.name "Frank Chu"
git config --global user.email "fchu@example.com"

Initial setup
=============

Then we want to clone the repository.  We normally want to have both
the current trunk and the emacs-24 branch.

mkdir ~/emacs
cd ~/emacs
git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
mv emacs trunk
./trunk/admin/git-new-workdir trunk emacs-24
cd emacs-24
git checkout emacs-24

You now have both branches conveniently accessible, and you can do
"git pull" in them once in a while to keep updated.


Fixing bugs
===========

You edit the files in either branch, `M-x vc-dir', and check in your
changes.  Then you need to push the data to the main repository.  This
will usually fail, since somebody else has pushed other changes in the
meantime.  To fix this, say

git pull --rebase

which will update your repository, and then re-apply your changes on
top of that.  Then say

git push


Backporting to emacs-24
=======================

If you have applied a fix to the trunk, but then decide that it should
be applied to the emacs-24 branch, too, then

cd ~/emacs/trunk
git log

and find the commit you're looking for.  Then find the commit ID,
which will look like

commit 958b768a6534ae6e77a8547a56fc31b46b63710b

cd ~/emacs/emacs-24
git cherry-pick 958b768a6534ae6e77a8547a56fc31b46b63710b
git commit --amend

and add "Backport:" to the commit string.  Then

git push


Merging emacs-24 to trunk
=========================

This has yet to be written.


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

Re: A simple git workflow for the rest of us

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 15 Nov 2014 17:09:59 +0100
> 
> Setting up and using git for normal, simple bugfixing
> =====================================================
> 
> If you haven't configured git before you should first do:
> 
> git config --global user.name "Frank Chu"
> git config --global user.email "fchu@example.com"
> 
> Initial setup
> =============
> 
> Then we want to clone the repository.  We normally want to have both
> the current trunk and the emacs-24 branch.
> 
> mkdir ~/emacs
> cd ~/emacs
> git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
> mv emacs trunk
> ./trunk/admin/git-new-workdir trunk emacs-24
> cd emacs-24
> git checkout emacs-24

I don't think these 2 sections should be in the document.  If you
like, we can add a reference to the Wiki here, which explains this in
more detail.

> cd ~/emacs/emacs-24
> git cherry-pick 958b768a6534ae6e77a8547a56fc31b46b63710b

I think we should decide whether we want to use -x here.

> git commit --amend
> 
> and add "Backport:" to the commit string.

Why not use "cherry-pick -e" instead?

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Setting up and using git for normal, simple bugfixing
>> =====================================================
>> 
>> If you haven't configured git before you should first do:
>> 
>> git config --global user.name "Frank Chu"
>> git config --global user.email "fchu@example.com"
>> 
>> Initial setup
>> =============
>> 
>> Then we want to clone the repository.  We normally want to have both
>> the current trunk and the emacs-24 branch.
>> 
>> mkdir ~/emacs
>> cd ~/emacs
>> git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
>> mv emacs trunk
>> ./trunk/admin/git-new-workdir trunk emacs-24
>> cd emacs-24
>> git checkout emacs-24
>
> I don't think these 2 sections should be in the document.  If you
> like, we can add a reference to the Wiki here, which explains this in
> more detail.

I just wanted a single, simple thing somebody who's unfamiliar with git,
and who doesn't care about git, could cut and paste.  I always like it
when projects have instructions, starting from scratch, in one single
place.

>> cd ~/emacs/emacs-24
>> git cherry-pick 958b768a6534ae6e77a8547a56fc31b46b63710b
>
> I think we should decide whether we want to use -x here.

   -x
           When recording the commit, append a line that says "(cherry picked
           from commit ...)" to the original commit message in order to
           indicate which commit this change was cherry-picked from.

Oh, yeah, that seems nice.

>> git commit --amend
>> 
>> and add "Backport:" to the commit string.
>
> Why not use "cherry-pick -e" instead?

Yes, that's probably easier.  I thought it may confuse the user less if
it's done in two steps (first cherry-pick the change, which may or may
not work), and then do the commit amendment.  But it may be less
confusing to do both things in one step...

Feel free to amend the document.  >"?

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

Re: A simple git workflow for the rest of us

[Achim Gratz]

Lars Magne Ingebrigtsen writes:
> Then we want to clone the repository.  We normally want to have both
> the current trunk and the emacs-24 branch.

Trunk is now known as master.

> git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git

Better to do the clone either with git: or http: public access and leave
the ssh credentials strictly for pushing to upstream.  You do this by
adding a section like this to your global git config (you could add it
to the repo config, but that doesn#t make much sense if you're having
multiple clones around):

[url "git+ssh://<membername>@git.sv.gnu.org/srv/git/emacs.git"]
        pushInsteadOf = git://git.sv.gnu.org/emacs.git

That should help the server load a bit.

> mv emacs trunk

If you're going to rename the directory, you'd be better off just
telling git clone what you want it to be named:

git clone -b master git://git.sv.gnu.org/emacs.git master

> ./trunk/admin/git-new-workdir

This doesn't exist and whether or not git-workdir or even separate
working trees is what you'll want is debatable.  Personally I just
switch branches and build out-of-tree, but for something as large as
Emac I can see the utility of having separate workdirs.  If the
directories are side-by side anyway, then

git clone -b emacs-24 --reference emacs git://git.sv.gnu.org/emacs.git emacs-24

is just as good.

> You edit the files in either branch, `M-x vc-dir', and check in your
> changes.  Then you need to push the data to the main repository.  This
> will usually fail, since somebody else has pushed other changes in the
> meantime.  To fix this, say
>
> git pull --rebase

When working with upstream this is good practrice, but if you're going
to do that anyway, just configure your branch with "rebase = true".  Or
configure "autosetuprebase = true" on a repo-wide or global basis so Git
will do that by default (you can always change that later of course).

> cd ~/emacs/emacs-24
> git cherry-pick 958b768a6534ae6e77a8547a56fc31b46b63710b
> git commit --amend

Oh please, use the --edit / -e option and save yourself the trouble of
having to amend.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: A simple git workflow for the rest of us

[Achim Gratz]

Eli Zaretskii writes:
> I think we should decide whether we want to use -x here.

That would help, and even might make the "Backport:" tag obsolete
(though it's appended to the commit message, so you don't see it in a
shortlog).  But this should strictly be used for cherry-picks from
published history only, not local branches.

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

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Achim Gratz <Stromeko@nexgo.de> writes:

> Lars Magne Ingebrigtsen writes:
>> Then we want to clone the repository.  We normally want to have both
>> the current trunk and the emacs-24 branch.
>
> Trunk is now known as master.

We can call the trunk the trunk if we want to.

>> git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
>
> Better to do the clone either with git: or http: public access and leave
> the ssh credentials strictly for pushing to upstream.  You do this by
> adding a section like this to your global git config (you could add it
> to the repo config, but that doesn#t make much sense if you're having
> multiple clones around):
>
> [url "git+ssh://<membername>@git.sv.gnu.org/srv/git/emacs.git"]
>         pushInsteadOf = git://git.sv.gnu.org/emacs.git
>
> That should help the server load a bit.

TLS is not a major CPU hog these days.  And we're not 10K developers
accessing the repository, so this just seems like make-work.

>> mv emacs trunk
>
> If you're going to rename the directory, you'd be better off just
> telling git clone what you want it to be named:
>
> git clone -b master git://git.sv.gnu.org/emacs.git master

I don't see how that's shorter or easier to remember.

>> ./trunk/admin/git-new-workdir
>
> This doesn't exist and whether or not git-workdir or even separate
> working trees is what you'll want is debatable.

If this is the work flow we're going with, it will exist.

> Personally I just switch branches and build out-of-tree, but for
> something as large as Emac I can see the utility of having separate
> workdirs.

Well, that's nice for you, but that's not how many of us prefer to
work.  We want both branches at the same time.

> If the directories are side-by side anyway, then
>
> git clone -b emacs-24 --reference emacs git://git.sv.gnu.org/emacs.git emacs-24
>
> is just as good.

Somebody else will have to weigh in on that.  I have no idea.

>> git pull --rebase
>
> When working with upstream this is good practrice, but if you're going
> to do that anyway, just configure your branch with "rebase = true".  Or
> configure "autosetuprebase = true" on a repo-wide or global basis so Git
> will do that by default (you can always change that later of course).

Ditto.

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

Re: A simple git workflow for the rest of us

[Eli Zaretskii]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sat, 15 Nov 2014 18:43:09 +0100
> 
> Eli Zaretskii writes:
> > I think we should decide whether we want to use -x here.
> 
> That would help, and even might make the "Backport:" tag obsolete
> (though it's appended to the commit message, so you don't see it in a
> shortlog).  But this should strictly be used for cherry-picks from
> published history only, not local branches.

The issue at hand is merging between 2 public branches of the Emacs
repository, so that's granted.

Re: A simple git workflow for the rest of us

[Andreas Schwab]

Achim Gratz <Stromeko@nexgo.de> writes:

> Lars Magne Ingebrigtsen writes:
>> ./trunk/admin/git-new-workdir
>
> This doesn't exist and whether or not git-workdir or even separate
> working trees is what you'll want is debatable.  Personally I just
> switch branches and build out-of-tree, but for something as large as
> Emac I can see the utility of having separate workdirs.

For Emacs it is a bit tedious to switch between branches of differing
versions, due to the way the lisp libraries are handled (compiled files
being places next to the sources).  That often requires a rebootstrap to
get things working again, even if building out-of-tree.

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: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> ./trunk/admin/git-new-workdir trunk emacs-24

I had problems pushing to trunk now after doing a "git pull" on the main
branch.  The error message was, as usual, pretty obscure.  But I went to
the emacs-24 directory and did a "git pull" there, too.  After that I
could push to the main branch.

Is this how new-workdir is supposed to work?  If so, using a totally
separate clone might be a better idea, because that's just too annoying.

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

Re: A simple git workflow for the rest of us

[Andreas Schwab]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> ./trunk/admin/git-new-workdir trunk emacs-24
>
> I had problems pushing to trunk now after doing a "git pull" on the main
> branch.  The error message was, as usual, pretty obscure.

And it was?

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: A simple git workflow for the rest of us

[Karl Fogel]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Trunk is now known as master.
>We can call the trunk the trunk if we want to.

We could, but it is a nearly universal convention among git projects to
name that branch 'master'.  I sure hope Emacs won't be gratuitously
different in matters like this :-).

Re: A simple git workflow for the rest of us

[Kelvin White]

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

Achim Gratz <Stromeko@nexgo.de> wrote:
> Lars Magne Ingebrigtsen writes:
>> Then we want to clone the repository.  We normally want to have both
>> the current trunk and the emacs-24 branch.
>
> Trunk is now known as master.
>
>> git clone <membername>@git.sv.gnu.org:/srv/git/emacs.git
>
> Better to do the clone either with git: or http: public access and leave
> the ssh credentials strictly for pushing to upstream.  You do this by
> adding a section like this to your global git config (you could add it
> to the repo config, but that doesn#t make much sense if you're having
> multiple clones around):
>
> [url "git+ssh://<membername>@git.sv.gnu.org/srv/git/emacs.git"]
>         pushInsteadOf = git://git.sv.gnu.org/emacs.git
>
> That should help the server load a bit.
>
>> mv emacs trunk
>
> If you're going to rename the directory, you'd be better off just
> telling git clone what you want it to be named:
>
> git clone -b master git://git.sv.gnu.org/emacs.git master

why not just...

git clone <membername>@git.sv.gnu.org/emacs.git trunk

that's if you still want to refer to it as trunk and not master
without renaming the branch to... wait, why are you proposing to
rename the branch to master with -b when it's master by default?

>> ./trunk/admin/git-new-workdir
>
> This doesn't exist and whether or not git-workdir or even separate
> working trees is what you'll want is debatable.  Personally I just
> switch branches and build out-of-tree, but for something as large as
> Emac I can see the utility of having separate workdirs.  If the
> directories are side-by side anyway, then

git-new-workdir is part of git/contrib which falls under the same GPL,
correct?
If so, no harm in copying it for distribution AFAIK.

> git clone -b emacs-24 --reference emacs git://git.sv.gnu.org/emacs.git
emacs-24
>
> is just as good.
>
>> You edit the files in either branch, `M-x vc-dir', and check in your
>> changes.  Then you need to push the data to the main repository.  This
>> will usually fail, since somebody else has pushed other changes in the
>> meantime.  To fix this, say
>>
>> git pull --rebase
> When working with upstream this is good practrice, but if you're going
> to do that anyway, just configure your branch with "rebase = true".  Or
> configure "autosetuprebase = true" on a repo-wide or global basis so Git
> will do that by default (you can always change that later of course).

This does no good in feature branches, so you should always `bzr update'
 first
...or in this case `git pull --rebase'. am I missing something here?

[-- Attachment #2: Type: text/html, Size: 3439 bytes --]

Re: A simple git workflow for the rest of us

[Kelvin White]

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

Kelvin White <kwhite@gnu.org> wrote:
> git-new-workdir is part of git/contrib which falls under the same GPL,
correct?
> If so, no harm in copying it for distribution AFAIK.

Let me reword this more appropriately since it won't be distributed

git-new-workdir is part of git/contrib which falls under the same GPL,
correct?
If so, no harm in copying it for our use AFAIK.

> This does no good in feature branches, so you should always `bzr update'
 first
> ...or in this case `git pull --rebase'. am I missing something here

More clarification: I meant local branches are not upstream, and wont need
updating

[-- Attachment #2: Type: text/html, Size: 1167 bytes --]

Re: A simple git workflow for the rest of us

[Glenn Morris]

Nice; thank you.

Re: A simple git workflow for the rest of us

[Ted Zlatanov]

On Sat, 15 Nov 2014 18:08:12 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

>>> cd ~/emacs/emacs-24
>>> git cherry-pick 958b768a6534ae6e77a8547a56fc31b46b63710b
>> 
>> I think we should decide whether we want to use -x here.

LMI>    -x
LMI>            When recording the commit, append a line that says "(cherry picked
LMI>            from commit ...)" to the original commit message in order to
LMI>            indicate which commit this change was cherry-picked from.

LMI> Oh, yeah, that seems nice.

Seconded, -x is really helpful.

Ted

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

>> I had problems pushing to trunk now after doing a "git pull" on the main
>> branch.  The error message was, as usual, pretty obscure.
>
> And it was?

It was lost in the mists of old xterms, but I did a new one.  First the
normal, expected push failure:

[larsi@stories ~/src/emacs/trunk]$ git push
To larsi@git.sv.gnu.org:/srv/git/emacs.git
 ! [rejected]        emacs-24 -> emacs-24 (non-fast-forward)
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'larsi@git.sv.gnu.org:/srv/git/emacs.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Then a pull that looks pretty normal:

[larsi@stories ~/src/emacs/trunk]$ git pull --rebase
remote: Counting objects: 203, done.
remote: Compressing objects: 100% (126/126), done.
remote: Total 126 (delta 109), reused 0 (delta 0)
Receiving objects: 100% (126/126), 17.80 KiB, done.
Resolving deltas: 100% (109/109), completed with 54 local objects.
From git.sv.gnu.org:/srv/git/emacs
   e68a171..6f167f9  master     -> origin/master
   a6b4278..c613f4d  emacs-24   -> origin/emacs-24
First, rewinding head to replay your work on top of it...
Applying: Add faces for the VC modeline state indicator.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging lisp/ChangeLog

And now the push.  I see that I was mistaken last time -- it did
actually push my trunk change, but it's complaining about the emacs-24
branch, where I have no changes and that I didn't want to push.

So...  is the hint it's giving the correct thing to do, or is there some
further configuration I should have done on the trunk to avoid these
messages?

[larsi@stories ~/src/emacs/trunk]$ git push
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 698 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Sending notification emails to: emacs-diffs@gnu.org
To larsi@git.sv.gnu.org:/srv/git/emacs.git
   6f167f9..48b2b32  master -> master
 ! [rejected]        emacs-24 -> emacs-24 (non-fast-forward)
error: failed to push some refs to 'larsi@git.sv.gnu.org:/srv/git/emacs.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. If you did not intend to push that branch, you may want to
hint: specify branches to push or set the 'push.default' configuration
hint: variable to 'current' or 'upstream' to push only the current branch.

Anyway, if I then say:

[larsi@stories ~/src/emacs/trunk]$ cd ../emacs-24/
[larsi@stories ~/src/emacs/emacs-24]$ git pull
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (6/6), done.
Unpacking objects: 100% (6/6), done.
remote: Total 6 (delta 5), reused 0 (delta 0)
From git.sv.gnu.org:/srv/git/emacs
   c613f4d..cf100f6  emacs-24   -> origin/emacs-24
Updating a6b4278..cf100f6
Fast-forward
 .gitignore                     |    2 +-
 ChangeLog                      |    4 ++
 admin/ChangeLog                |    6 ++
 admin/update_autogen           |   28 ++++++++--
 doc/emacs/ChangeLog            |    6 ++
 doc/emacs/misc.texi            |    8 ++-
 lisp/ChangeLog                 |   32 +++++++++++
 lisp/progmodes/js.el           |    4 +-
 lisp/progmodes/python.el       |   61 ++++++++++++--------
 lisp/version.el                |    4 +-
 lisp/window.el                 |    2 +-
 src/ChangeLog                  |    4 ++
 src/frame.c                    |    2 +-
 test/ChangeLog                 |   11 ++++
 test/automated/python-tests.el |  119 ++++++++++++++++++++++++++++++++++++++++
 test/indent/js.js              |    8 +++
 16 files changed, 263 insertions(+), 38 deletions(-)
[larsi@stories ~/src/emacs/emacs-24]$ cd ../trunk/
[larsi@stories ~/src/emacs/trunk]$ git push
Everything up-to-date

So "git pull" on the "new-workdir"'ed branch made pushing on the trunk
stop giving error messages.  Which is kinda fun.

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

Re: A simple git workflow for the rest of us

[David Engster]

Lars Magne Ingebrigtsen writes:
> And now the push.  I see that I was mistaken last time -- it did
> actually push my trunk change, but it's complaining about the emacs-24
> branch, where I have no changes and that I didn't want to push.

That's the (horrible) default behavior of 'git push': it tries to update
all matching branches. This makes it incredibly easy to update branches
by accident, which in your case didn't work because your emacs-24 branch
was behind.

I strongly suggest to change the default to something like 'simple',
which will only update the current branch to the corresponding upstream
branch with the same name. This was also made the new default in Git
2.x (way too late, but at least they changed it).

You can set this globally by doing

  git config --global push.default simple

Note that 'simple' is only available since Git 1.7.11, and Debian stable
still has 1.7.10. On older versions you can use 'upstream' or maybe
'current' (see 'git help config' to see the available options for
'push.default'), but I'd rather suggest to update Git from
wheezy-backports.

-David

Re: A simple git workflow for the rest of us

[Achim Gratz]

Lars Magne Ingebrigtsen writes:
[…]
> And now the push.  I see that I was mistaken last time -- it did
> actually push my trunk change, but it's complaining about the emacs-24
> branch, where I have no changes and that I didn't want to push.
>
> So...  is the hint it's giving the correct thing to do, or is there some
> further configuration I should have done on the trunk to avoid these
> messages?

Consult the documentation on the push.default configuration (git help
config), you don't want "matching" in a configuration that has permanent
new-workdirs attached.

> So "git pull" on the "new-workdir"'ed branch made pushing on the trunk
> stop giving error messages.  Which is kinda fun.

The same would have happened if you had updated the emacs-24 branch in
the master repository.  Remember that the "new-workdir" really is
working on your base repository.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

> I strongly suggest to change the default to something like 'simple',
> which will only update the current branch to the corresponding upstream
> branch with the same name. This was also made the new default in Git
> 2.x (way too late, but at least they changed it).
>
> You can set this globally by doing
>
>   git config --global push.default simple

I see; thanks.  Is there a way to set this for the Emacs repository
only, so that the simple git Emacs instructions doesn't affect what the
developer might otherwise be working on?  Or, since the default has
changed now, is this something that basically everybody wants, so it
really should be global?

> Note that 'simple' is only available since Git 1.7.11, and Debian stable
> still has 1.7.10. On older versions you can use 'upstream' or maybe
> 'current' (see 'git help config' to see the available options for
> 'push.default'), but I'd rather suggest to update Git from
> wheezy-backports.

For the instructions, I'd rather have a recipe that works for everybody
without installing newer git versions.  My git version has "upstream"
and "current" as possibilities...

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

Re: A simple git workflow for the rest of us

[David Engster]

Lars Magne Ingebrigtsen writes:
> David Engster <deng@randomsample.de> writes:
>
>> I strongly suggest to change the default to something like 'simple',
>> which will only update the current branch to the corresponding upstream
>> branch with the same name. This was also made the new default in Git
>> 2.x (way too late, but at least they changed it).
>>
>> You can set this globally by doing
>>
>>   git config --global push.default simple
>
> I see; thanks.  Is there a way to set this for the Emacs repository
> only, so that the simple git Emacs instructions doesn't affect what the
> developer might otherwise be working on?

Simply omit the '--global' and do it in the Emacs repo.

> Or, since the default has changed now, is this something that
> basically everybody wants, so it really should be global?

The experts who happen to like 'matching' won't read your instructions
anyway. ;-) But yes, I guess doing it local is better.

-David

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

David Engster <deng@randomsample.de> writes:

>> I see; thanks.  Is there a way to set this for the Emacs repository
>> only, so that the simple git Emacs instructions doesn't affect what the
>> developer might otherwise be working on?
>
> Simply omit the '--global' and do it in the Emacs repo.

Thanks; I've now updated the recipe.

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

Re: A simple git workflow for the rest of us

[David Kastrup]

David Engster <deng@randomsample.de> writes:

> The experts who happen to like 'matching' won't read your instructions
> anyway. ;-)

I think that the experts who happen to like 'matching' are mythical
beasts.  Any "expert" has learnt the hard way long ago to never ever use
"git push" without explicit arguments.

It's a setting that manages at the same time to be spectacularly useless
for almost anything while being really dangerous at the same time.  Of
course, that made it a prime contender for the default setting of Git,
the version control system for real programmers.

It's almost a miracle it has been changed for 2.0.

-- 
David Kastrup

Re: A simple git workflow for the rest of us

[Bill Wohler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Lars Magne Ingebrigtsen writes:
>>> Then we want to clone the repository.  We normally want to have both
>>> the current trunk and the emacs-24 branch.
>>
>> Trunk is now known as master.
>
> We can call the trunk the trunk if we want to.

I don't want to :-).

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: A simple git workflow for the rest of us

[Bill Wohler]

Achim Gratz <Stromeko@nexgo.de> writes:

> Lars Magne Ingebrigtsen writes:
>> You edit the files in either branch, `M-x vc-dir', and check in your
>> changes.  Then you need to push the data to the main repository.  This
>> will usually fail, since somebody else has pushed other changes in the
>> meantime.  To fix this, say
>>
>> git pull --rebase
>
> When working with upstream this is good practrice, but if you're going
> to do that anyway, just configure your branch with "rebase = true".  Or
> configure "autosetuprebase = true" on a repo-wide or global basis so Git
> will do that by default (you can always change that later of course).

That's pull.rebase = true.

Also, do you mean branch.autosetuprebase = always?

I'd second setting it globally to ensure that it happens universally to
avoid the spurious merge commits that otherwise ensue.

Specifically, how does one make a configuration setting that applies to
everyone who clones the repository? Would that setting appear in
emacs/.git/config or elsewhere?

The git config man page says this:

           NOTE: this is a possibly dangerous operation; do not use it unless you
           understand the implications (see git-rebase(1) for details).

Does our global setting of pushNonFastForward mitigate these concerns?

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Bill Wohler <wohler@newt.com> writes:

> I'd second setting it globally to ensure that it happens universally to
> avoid the spurious merge commits that otherwise ensue.
>
> Specifically, how does one make a configuration setting that applies to
> everyone who clones the repository?

Putting "push.default current" in there would be nice, too.  (If this is
possible.)

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

Re: A simple git workflow for the rest of us

[Ted Zlatanov]

On Sun, 16 Nov 2014 20:43:10 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Bill Wohler <wohler@newt.com> writes:
>> I'd second setting it globally to ensure that it happens universally to
>> avoid the spurious merge commits that otherwise ensue.
>> 
>> Specifically, how does one make a configuration setting that applies to
>> everyone who clones the repository?

LMI> Putting "push.default current" in there would be nice, too.  (If this is
LMI> possible.)

It's not.  Make a config file with the right settings and ask users to
copy or merge it to `$checkout_path/.git/config' when they clone.

For completeness, here's my .gitconfig that may be useful, though it
doesn't have the pull.rebase=true that was mentioned or the
git-merge-changelog driver.

Ted

#+begin_src text
[core]
        whitespace = trailing-space,space-before-tab

[diff]
        renames = copies
	algorithm = patience

[merge]
        stat = true

[grep]
        fullname = true

[push]
        default = current
#+end_src

Re: A simple git workflow for the rest of us

[Eli Zaretskii]

> From: Bill Wohler <wohler@newt.com>
> Date: Sun, 16 Nov 2014 11:33:37 -0800
> 
> The git config man page says this:
> 
>            NOTE: this is a possibly dangerous operation; do not use it unless you
>            understand the implications (see git-rebase(1) for details).

AFAIK, this is a general warning about rebasing, it's unrelated to the
issue at hand.

Re: A simple git workflow for the rest of us

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

>>> mv emacs trunk

>> If you're going to rename the directory, you'd be better off just
>> telling git clone what you want it to be named:

>> git clone -b master git://git.sv.gnu.org/emacs.git master

> I don't see how that's shorter or easier to remember.

Wasn't this document so that one didn't have to remember: Ie. a single
place to copy-paste command line commands from?

If so, this would give one less line to copy-paste.

>>> ./trunk/admin/git-new-workdir

>> This doesn't exist and whether or not git-workdir or even separate
>> working trees is what you'll want is debatable.

> If this is the work flow we're going with, it will exist.

[snip!]
>> If the directories are side-by side anyway, then
>> 
>> git clone -b emacs-24 --reference emacs git://git.sv.gnu.org/emacs.git emacs-24
>> 
>> is just as good.

> Somebody else will have to weigh in on that.  I have no idea.

For the purposes of a robust list of copy-paste commands, using just
what's in git itself is better than using a script that may, or may not,
be present.

Re: A simple git workflow for the rest of us

[Steinar Bang]

>>>>> Bill Wohler <wohler@newt.com>:

> I'd second setting it globally to ensure that it happens universally
> to avoid the spurious merge commits that otherwise ensue.

(I've never understood why "spurious merge commits" bother people so
much. Personally I'm much more concerned with what might happen to my
individual commits if I'm hitting a conflict during rebase: the commit's
diff may no longer be the clear and meaningful diff I indented it to be)

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> Wasn't this document so that one didn't have to remember: Ie. a single
> place to copy-paste command line commands from?
>
> If so, this would give one less line to copy-paste.

A long, complicated git command isn't better than one simple git command
and then a "mv".

>>> If the directories are side-by side anyway, then
>>> 
>>> git clone -b emacs-24 --reference emacs
>>> git://git.sv.gnu.org/emacs.git emacs-24
>>> 
>>> is just as good.
>
>> Somebody else will have to weigh in on that.  I have no idea.
>
> For the purposes of a robust list of copy-paste commands, using just
> what's in git itself is better than using a script that may, or may not,
> be present.

And is that command as good as what new-workdir does?

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

Re: A simple git workflow for the rest of us

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> A long, complicated git command isn't better than one simple git
> command and then a "mv".

I like to copy-paste ready-to-use commands from HOWTOs.  

And the fewer copy-pastes I have to do, the better: less work, less that
can go wrong.

The length, and complicated-ness of the copy-pasted command line doesn't
really matter (as long as it works...).

Note: I think the document is a great idea. I really like HOWTOs with
canned commands that can be copy-pasted and will do the right thing,
without me having to think too much.

>> For the purposes of a robust list of copy-paste commands, using just
>> what's in git itself is better than using a script that may, or may
>> not, be present.

> And is that command as good as what new-workdir does?

My guess is that the git clone command would be better, ie. a 4-6 old
contributed script vs. something that is standard functionality of
git-clone.

My understanding is that they currently pretty much will do the same
thing (symlink the individual files of the .git directory of the
original), but the git built-in functionality will move away from the
reliance on symlinks i the future.

Re: A simple git workflow for the rest of us

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> My guess is that the git clone command would be better, ie. a 4-6 old
> contributed script vs. something that is standard functionality of
> git-clone.

This is git we're talking about.  C'mon.  

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

Re: A simple git workflow for the rest of us

[Bill Wohler]

Steinar Bang <sb@dod.no> writes:

>>>>>> Bill Wohler <wohler@newt.com>:
>
>> I'd second setting it globally to ensure that it happens universally
>> to avoid the spurious merge commits that otherwise ensue.
>
> (I've never understood why "spurious merge commits" bother people so
> much. Personally I'm much more concerned with what might happen to my
> individual commits if I'm hitting a conflict during rebase: the commit's
> diff may no longer be the clear and meaningful diff I indented it to be)

Like many things, it depends.

If a merge in either direction doesn't add any information, it's
spurious. If it's useful, it's not spurious. For me, a merge commit from
a pull breaks up the flow of my unpushed commits and usually doesn't add
anything. I can imagine that folks used to Subversion would prefer
pull --rebase as well as that mimics svn update. Sort of.

If it's vital to capture that merge in the middle of your own commits,
then the pull should be merged. I've just never encountered this
situation. In the situation you presented, could you use git rebase
--abort and then run git merge origin/master to recover?

In any event, there is no right or wrong answer. It all depends.

p.s. Hey Steiner, long time no "see"!

-- 
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/
GnuPG ID:610BD9AD

Re: A simple git workflow for the rest of us

[Sergey Organov]

Bill Wohler <wohler@newt.com> writes:

> Steinar Bang <sb@dod.no> writes:
>
>>>>>>> Bill Wohler <wohler@newt.com>:
>>
>>> I'd second setting it globally to ensure that it happens universally
>>> to avoid the spurious merge commits that otherwise ensue.
>>
>> (I've never understood why "spurious merge commits" bother people so
>> much. Personally I'm much more concerned with what might happen to my
>> individual commits if I'm hitting a conflict during rebase: the commit's
>> diff may no longer be the clear and meaningful diff I indented it to be)
>
> Like many things, it depends.
>
> If a merge in either direction doesn't add any information, it's
> spurious. If it's useful, it's not spurious. For me, a merge commit from
> a pull breaks up the flow of my unpushed commits and usually doesn't add
> anything. I can imagine that folks used to Subversion would prefer
> pull --rebase as well as that mimics svn update. Sort of.
>
> If it's vital to capture that merge in the middle of your own commits,
> then the pull should be merged. I've just never encountered this
> situation. In the situation you presented, could you use git rebase
> --abort and then run git merge origin/master to recover?
>
> In any event, there is no right or wrong answer. It all depends.

AFAIK, one can pull with merge, then finally, before pushing, call "git
rebase" by hand, and Git will get rid of all those intermediate merges
while rebasing. This doesn't play nicely with intended local merges. The
latter is unlikely to make any difference for simple workflows though.

One probably needs to enable "rerere" to avoid repeating the same merge
resolution.

-- 
Sergey.