Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> commit 7f4f16b3ae6fdb59d83cfc01017668f2a564309f
> Merge: 1a369fc be2d23e
> Author: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Commit: Lars Magne Ingebrigtsen <larsi@gnus.org>
>
>     Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
> ---
>  ChangeLog                          |   14 +
>  INSTALL.REPO                       |    2 +
>  autogen.sh                         |    1 +
>  doc/emacs/ChangeLog                |    5 +
>  doc/emacs/files.texi               |    7 +
>  etc/ChangeLog                      |    8 +

Err.  I didn't mean for that to happen.

I had created a new branch with git-new-workdir, and just meant to push
the changes there.  But somehow the stuff from "git pull" on the trunk
was also pushed?  I think?

I hope that didn't ... destroy anything.

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

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Err.  I didn't mean for that to happen.

My ~/.gitconfig on this laptop had

[push]
	default = matching

Perhaps that's the cause.  I've now changed it to "current".

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

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Paul Eggert]

Lars Ingebrigtsen wrote:
> I hope that didn't ... destroy anything.

This is git, so nothing is ever destroyed, it's just ... mutated.

I repaired the problems I found in master commit 
39c2fa3f4e5bf332cc30266d36d5410c4ffeaac4.  Your commit merged from emacs-24, 
which is generally a good thing to do, so I left that part alone.

I didn't fix the dates in the ChangeLogs; you can take a look at those.  The 
convention is that the dates are supposed to be as of the merge, not as of the 
original checkin.  Which reminds me, we need to get the ball rolling again on 
having ChangeLogs generated automatically, to avoid that part of the merge 
hassle in the future.

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

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

> This is git, so nothing is ever destroyed, it's just ... mutated.
>
> I repaired the problems I found in master commit
> 39c2fa3f4e5bf332cc30266d36d5410c4ffeaac4.  Your commit merged from
> emacs-24, which is generally a good thing to do, so I left that part
> alone.

Oops, sorry.

How did that happen?  I thought I was in either the master branch, or
the shr-fontified branch.  I didn't try to do anything with the emacs-24
branch...

git branch seems to agree:

[larsi@building trunk]$ git branch
* master
  shr-fontified
[larsi@building trunk]$ cd ..
[larsi@building emacs]$ cd shr-fontified/
[larsi@building shr-fontified]$ git branch
  master
* shr-fontified

Hm...

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

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Paul Eggert]

Lars Ingebrigtsen wrote:
> How did that happen?  I thought I was in either the master branch, or
> the shr-fontified branch.  I didn't try to do anything with the emacs-24
> branch...

Oh, sorry, I guess I misinterpreted the logs and Fabián did the merges 
(actually, merges) at about the same time?  But your name is on one of the 
master-installed merges as the committer, so I'm puzzled.  Whatever.  Anyway, 
the merges had quite a few conflicts that were resolved incorrectly.

Did anything leak into the master that you didn't want?  The nnimap `never' 
expiration fix, say?  (Commit 0cdd599c54aeda36e7e0696b2f90d2c286153a1d.)  Or the 
shr-make-table-1 patches (commits 1a369fc7f1ccec6954344ec1ee0211a4d24c312d and 
776705f49c5cb4e66c7dcb316fe499aa6a183888)?  If so, now might be a good time to 
revert these.

As a general rule, by the way, I almost never do anything other than "git pull" 
when I'm in my working copy of the Emacs master.  To do any real work, I clone 
that copy and work in some temporary branch in that clone.  Eventually when I 
have a patch I'm happy with, I use "git format-patch" to create a patch file, 
review the patch file, and then finally go to my copy of the master and publish 
the patch via "git am PATCHFILE; git push".  This lessens the likelihood of my 
inadvertently pushing something to savannah's master.

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

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

> Oh, sorry, I guess I misinterpreted the logs and Fabián did the merges
> (actually, merges) at about the same time?

*phew*  For a while there I thought my comprehension of git was even
lesser than it is.  :-)

> But your name is on one of
> the master-installed merges as the committer, so I'm puzzled.
> Whatever.  Anyway, the merges had quite a few conflicts that were
> resolved incorrectly.
>
> Did anything leak into the master that you didn't want?  The nnimap
> `never' expiration fix, say?  (Commit
> 0cdd599c54aeda36e7e0696b2f90d2c286153a1d.)  Or the shr-make-table-1
> patches (commits 1a369fc7f1ccec6954344ec1ee0211a4d24c312d and
> 776705f49c5cb4e66c7dcb316fe499aa6a183888)?  If so, now might be a good
> time to revert these.

Those two look OK, I think.

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

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> *phew*  For a while there I thought my comprehension of git was even
> lesser than it is.  :-)

I think I'm going to start using "git push -n" the next time I'm pushing
on a branch...

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

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 28 Jan 2015 18:31:02 +1100
> Cc: Fabián Ezequiel Gallina <fgallina@gnu.org>,
> 	emacs-devel@gnu.org
> 
> I think I'm going to start using "git push -n" the next time I'm pushing
> on a branch...

Why not "git show"?  That's what I do before each push, be it from
master or branch.

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Wed, 28 Jan 2015 18:31:02 +1100
>> Cc: Fabián Ezequiel Gallina <fgallina@gnu.org>,
>> 	emacs-devel@gnu.org
>> 
>> I think I'm going to start using "git push -n" the next time I'm pushing
>> on a branch...
>
> Why not "git show"?

Because that doesn't tell you what will be pushed.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Yuri Khan]

On Wed, Jan 28, 2015 at 9:45 PM, Andreas Schwab <schwab@suse.de> wrote:

>>> I think I'm going to start using "git push -n" the next time I'm pushing
>>> on a branch...
>>
>> Why not "git show"?
>
> Because that doesn't tell you what will be pushed.

A good thing to do before pushing is to actually see the commit graph,
in gitk or gitg or gitx or in a pinch “git log --graph --decorate
--oneline”, with both the current local and remote branches displayed.
And always be explicit about what you are pushing — always “git push
origin master”, never “git push”. (“git config push.default simple”
helps but is not everybody’s default.)

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Wed, 28 Jan 2015 23:32:34 +0700
> Cc: Eli Zaretskii <eliz@gnu.org>, fgallina@gnu.org, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	Paul Eggert <eggert@cs.ucla.edu>, Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, Jan 28, 2015 at 9:45 PM, Andreas Schwab <schwab@suse.de> wrote:
> 
> A good thing to do before pushing is to actually see the commit graph,
> in gitk or gitg or gitx or in a pinch “git log --graph --decorate
> --oneline”, with both the current local and remote branches displayed.
> And always be explicit about what you are pushing — always “git push
> origin master”, never “git push”. (“git config push.default simple”
> helps but is not everybody’s default.)

Please don't over-complicate things, people are evidently making silly
mistakes even with simple workflows that need 3 commands.

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Yuri Khan]

On Wed, Jan 28, 2015 at 11:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Please don't over-complicate things, people are evidently making silly
> mistakes even with simple workflows that need 3 commands.

Performing actions on objects that you don’t see, that’s what I call
over-complication.

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 29 Jan 2015 00:39:58 +0700
> Cc: schwab@suse.de, fgallina@gnu.org, Lars Ingebrigtsen <larsi@gnus.org>, 
> 	Paul Eggert <eggert@cs.ucla.edu>, Emacs developers <emacs-devel@gnu.org>
> 
> On Wed, Jan 28, 2015 at 11:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Please don't over-complicate things, people are evidently making silly
> > mistakes even with simple workflows that need 3 commands.
> 
> Performing actions on objects that you don’t see, that’s what I call
> over-complication.

I agree, but there are umpteen different ways to see them in Git, and
we should advertise the simplest of them, IMO.

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Yuri Khan]

On Wed, Jan 28, 2015 at 11:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I agree, but there are umpteen different ways to see them in Git, and
> we should advertise the simplest of them, IMO.

There isn’t One. I’d name gitk because it comes with Git, but it won’t
work in Linux tty. “git log --oneline --decorate --graph” works
everywhere, but is a nuisance to type (until you make it an alias),
and is not as convenient. Gitg and Gitx are GNOME- and Mac-specific.

git push precautions

[Ivan Shmakov]

>>>>> Yuri Khan <yuri.v.khan@gmail.com> writes:

[…]

 > A good thing to do before pushing is to actually see the commit
 > graph, in gitk or gitg or gitx or in a pinch “git log --graph
 > --decorate --oneline”, with both the current local and remote
 > branches displayed.

	If the intent is to push just a sequence of changes to a branch
	(that is: with no merges involved), something like
	$ git log origin/branch..branch should suffice.  Personally, I
	also add ‘-p’ there and re-visit the changes.  With this option,
	git-log(1) produces output similar (AIUI) to git-show(1), for
	which I had no use so far.

 > And always be explicit about what you are pushing — always “git push
 > origin master”, never “git push”.  (“git config push.default simple”
 > helps but is not everybody’s default.)

	My preference is rather ‘push.default nothing’, so that
	git-push(1) fails loudly should I fail to specify what to push.

	And using $ git push -n does no harm, sure.

-- 
FSF associate member #7257  np. En akvo de la klara fonto — Jacques Yvart

Re: git push precautions

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Wed, 28 Jan 2015 18:30:57 +0000
> 
> 	My preference is rather ‘push.default nothing’, so that
> 	git-push(1) fails loudly should I fail to specify what to push.

IMO (and IME) that's a nuisance that isn't justified.

Re: git push precautions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ivan Shmakov <ivan@siamics.net>
>> Date: Wed, 28 Jan 2015 18:30:57 +0000
>> 
>> 	My preference is rather ‘push.default nothing’, so that
>> 	git-push(1) fails loudly should I fail to specify what to push.
>
> IMO (and IME) that's a nuisance that isn't justified.

git's defaults have historically been so unreasonable that I never push
without explicit mention of both local as well as target reference.  It
decidedly is less of a nuisance than having to clean up after Git goes
overboard.

Nowadays the defaults may be saner (and the setting configurable in the
first place).  Still, the "nuisance" is comparatively small, and in
exchange you know just what _any_ version of Git will do.  And if you
quote your process, nobody will get double-crossed by following your
example.

-- 
David Kastrup

Re: git push precautions

[Kelvin White]

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

I just use `git diff' before every push to see exactly what I'm pushing,
and I always specify the remote repo i.e. `git push origin master'

On Wed, Jan 28, 2015, 1:52 PM David Kastrup <dak@gnu.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Ivan Shmakov <ivan@siamics.net>
> >> Date: Wed, 28 Jan 2015 18:30:57 +0000
> >>
> >>      My preference is rather ‘push.default nothing’, so that
> >>      git-push(1) fails loudly should I fail to specify what to push.
> >
> > IMO (and IME) that's a nuisance that isn't justified.
>
> git's defaults have historically been so unreasonable that I never push
> without explicit mention of both local as well as target reference.  It
> decidedly is less of a nuisance than having to clean up after Git goes
> overboard.
>
> Nowadays the defaults may be saner (and the setting configurable in the
> first place).  Still, the "nuisance" is comparatively small, and in
> exchange you know just what _any_ version of Git will do.  And if you
> quote your process, nobody will get double-crossed by following your
> example.
>
> --
> David Kastrup
>
>
>

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

Re: git push precautions

[Ivan Shmakov]

>>>>> Kelvin White <kwhite@gnu.org> writes:
>>>>> On Wed, Jan 28, 2015, 1:52 PM David Kastrup <dak@gnu.org> wrote:
>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Wed, 28 Jan 2015 18:30:57 +0000

 >>>> My preference is rather ‘push.default nothing’, so that
 >>>> git-push(1) fails loudly should I fail to specify what to push.

 >>> IMO (and IME) that's a nuisance that isn't justified.

 >> git's defaults have historically been so unreasonable that I never
 >> push without explicit mention of both local as well as target
 >> reference.  It decidedly is less of a nuisance than having to clean
 >> up after Git goes overboard.

 > I just use `git diff' before every push to see exactly what I'm
 > pushing,

	I’d generally use $ git log -p origin/branch branch instead, so
	that I can review the individual changes, – as well as the
	commit messages.

 > and I always specify the remote repo i. e. `git push origin master'

	So do I.  And when one does, I’d say that that preference /is/
	justified.

[…]

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

Re: git push precautions

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Ivan Shmakov <ivan@siamics.net>,  emacs-devel@gnu.org
> Date: Wed, 28 Jan 2015 19:52:21 +0100
> 
> git's defaults have historically been so unreasonable that I never push
> without explicit mention of both local as well as target reference.

But that problem no longer exists in current versions of Git.  Why
should I punish myself on behalf of Git versions I never used and
never will be?  It sounds perverse.

Re: git push precautions

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Ivan Shmakov <ivan@siamics.net>,  emacs-devel@gnu.org
>> Date: Wed, 28 Jan 2015 19:52:21 +0100
>> 
>> git's defaults have historically been so unreasonable that I never push
>> without explicit mention of both local as well as target reference.
>
> But that problem no longer exists in current versions of Git.  Why
> should I punish myself on behalf of Git versions I never used and
> never will be?  It sounds perverse.

I gave an answer that in the same posting you replied to.  It's probably
safe to assume that once a thread has reached the state of quoting
games, everything that may cause anybody to change his mind has already
been said.

-- 
David Kastrup

Re: git push precautions

[Yuri Khan]

On Thu, Jan 29, 2015 at 1:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> But that problem no longer exists in current versions of Git.  Why
> should I punish myself on behalf of Git versions I never used and
> never will be?  It sounds perverse.

You cannot assume current Git on all systems, yet. The current Ubuntu
LTS (14.04 Trusty Tahr) has 1.9.1, and in corporate environments that
will be used until 16.04.

You personally can use whatever practice you deem safe and convenient,
but if we’re talking about generic recommendations, we have to account
for old Git versions.

Re: git push precautions

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Thu, 29 Jan 2015 12:39:24 +0700
> Cc: David Kastrup <dak@gnu.org>, ivan@siamics.net, Emacs developers <emacs-devel@gnu.org>
> 
> > But that problem no longer exists in current versions of Git.  Why
> > should I punish myself on behalf of Git versions I never used and
> > never will be?  It sounds perverse.
> 
> You cannot assume current Git on all systems, yet.

We are not talking about general population here.  We are talking
about contributors who are actively tracking the Emacs development and
committing changes to the repository.  Those contributors are already
required to use relatively recent versions of the development tools.
There's nothing wrong in assuming a recent enough Git and in
recommending that contributors upgrade to such a recent version.

> You personally can use whatever practice you deem safe and convenient,
> but if we’re talking about generic recommendations, we have to account
> for old Git versions.

The vast majority here has Git that is recent enough.  It is okay to
say in addition "but if you have Git older than X.Y.Z, do this like so
instead".  But giving _only_ such recipes, that are unduly complicated
because they work with the lowest common denominator, means punishing
the majority for the benefit of a tiny, perhaps non-existent minority,
when applied to people for which the issue at hand (pushing to the
Emacs repo) is relevant.  It strikes the wrong balance, IMO.

Re: git push precautions

[Paul Eggert]

On 01/29/2015 08:03 AM, Eli Zaretskii wrote:
> There's nothing wrong in assuming a recent enough Git and in
> recommending that contributors upgrade to such a recent version.

Quite right, and we already say git 1.7.1 or later is needed; please see 
INSTALL.REPO.

Re: git push precautions

[Eli Zaretskii]

> Date: Thu, 29 Jan 2015 09:47:12 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: emacs-devel@gnu.org
> 
> On 01/29/2015 08:03 AM, Eli Zaretskii wrote:
> > There's nothing wrong in assuming a recent enough Git and in
> > recommending that contributors upgrade to such a recent version.
> 
> Quite right, and we already say git 1.7.1 or later is needed; please see 
> INSTALL.REPO.

So maybe we should upgrade our requirements to 1.9.2.

Re: git push precautions

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> Date: Thu, 29 Jan 2015 09:47:12 -0800  From: Paul Eggert
>>>>> On 01/29/2015 08:03 AM, Eli Zaretskii wrote:

 >>> There's nothing wrong in assuming a recent enough Git and in
 >>> recommending that contributors upgrade to such a recent version.

 >> Quite right, and we already say git 1.7.1 or later is needed; please
 >> see INSTALL.REPO.

 > So maybe we should upgrade our requirements to 1.9.2.

	JFTR, Debian stable has 1.7.10 [1].  Could we please wait with
	that until Debian Jessie becomes stable (probably just some
	months from now)?

[1] https://packages.debian.org/wheezy/git

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

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  fgallina@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 28 Jan 2015 16:45:59 +0100
> 
> > Why not "git show"?
> 
> Because that doesn't tell you what will be pushed.

I think it does, if I'm careful to push each commit.

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@suse.de>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  fgallina@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
>> Date: Wed, 28 Jan 2015 16:45:59 +0100
>> 
>> > Why not "git show"?
>> 
>> Because that doesn't tell you what will be pushed.
>
> I think it does, if I'm careful to push each commit.

Why taking chances when it's easy to avoid?

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: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Cc: fgallina@gnu.org,  larsi@gnus.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Wed, 28 Jan 2015 18:46:36 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@suse.de>
> >> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  fgallina@gnu.org,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> >> Date: Wed, 28 Jan 2015 16:45:59 +0100
> >> 
> >> > Why not "git show"?
> >> 
> >> Because that doesn't tell you what will be pushed.
> >
> > I think it does, if I'm careful to push each commit.
> 
> Why taking chances when it's easy to avoid?

OK, but is "push -n" really the best alternative?  How about
"git diff origin/master" (resp. origin/emacs-24)?

git push precautions

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

[…]

 > OK, but is "push -n" really the best alternative?

	I wouldn’t call it “an alternative,” – to either git-log(1) or
	git-diff(1).

 > How about "git diff origin/master" (resp. origin/emacs-24)?

	There’s a difference, – $ git diff shows the “cumulative” diff,
	while $ git log -p shows the individual (per-commit) diffs.
	Depending on the circumstances, either (or /both/) of these
	commands may be of value.

	As a “generic” advice, I’d rather recommend running $ git log -p
	before pushing the changes.

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

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> OK, but is "push -n" really the best alternative?

It gives you the most accurate information.

> How about "git diff origin/master" (resp. origin/emacs-24)?

You can use that in addition once you are sure what will be pushed.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: master 7f4f16b: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs

[Nicolas Richard]

Andreas Schwab <schwab@suse.de> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>>> From: Lars Ingebrigtsen <larsi@gnus.org>
>>> I think I'm going to start using "git push -n" the next time I'm pushing
>>> on a branch...
>>
>> Why not "git show"?
>
> Because that doesn't tell you what will be pushed.

FWIW, I misread "show" as "status" and it made sense to me.

-- 
Nicolas