Stash

Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

When people told me that my changes in Lisp files did not get pushed,
I did git pull again, and it told me there was a problem
lisp/ChangeLog again, but there was no conflict in it.
Then I did git commit again.

Then I did git push again, and got this.

    To rms@git.sv.gnu.org:/srv/git/emacs.git
     ! [rejected]        master -> master (non-fast-forward)
    error: failed to push some refs to 'rms@git.sv.gnu.org:/srv/git/emacs.git'
    To prevent you from losing history, non-fast-forward updates were rejected
    Merge the remote changes (e.g. 'git pull') before pushing again.  See the
    'Note about fast-forwards' section of 'git push --help' for details.

I have no idea what that means.

      > My guess would be that these are still stashed, and need to be
      > unstashed and then pushed.

How can I tell?

And if those changes are stashed, why did they show up in git diff?

Anyway, I did 'git stash pop' to see if they were stashed.

That seems to have changed dozens of files.
'git diff origin/master' gave me 5000 lines.

So I tried doing 'git stash' again, and it gave me an error,

    fatal: git-write-tree: error building trees
    Cannot save the current index state

I don't have all the output.  I had run git in a shell buffer a few
times, and it causes a lot of trouble about the terminal.  So I started
running it in an ordinary terminal.

Fortunately it seems that all my changes did make it into Savannah.
So it is just a matter of how to get a clean repository.

Is there any way I can fix this other than creating a new repository?
I should not do that here; it would cost my host too much money, I
fear.

How unreliable and error-prone Git is.  I will recommend
that people choose Bzr or CVS.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> When people told me that my changes in Lisp files did not get pushed,
> I did git pull again, and it told me there was a problem
> lisp/ChangeLog again, but there was no conflict in it.
> Then I did git commit again.

Hm... that may not have been enough? Did you stage lisp/ChangeLog before
before doing the commit? Ie.
 git add lisp/ChangeLog
 git commit

If you didn't and this was marked as a merge, the commit probably didn't
happen.

> Then I did git push again, and got this.

>     To rms@git.sv.gnu.org:/srv/git/emacs.git
>      ! [rejected]        master -> master (non-fast-forward)
>     error: failed to push some refs to 'rms@git.sv.gnu.org:/srv/git/emacs.git'
>     To prevent you from losing history, non-fast-forward updates were rejected
>     Merge the remote changes (e.g. 'git pull') before pushing again.  See the
>     'Note about fast-forwards' section of 'git push --help' for details.

> I have no idea what that means.

It means someone else pushed since your last pull.  Try doing a new
pull, followed by a push.
 git pull
 git push

>> My guess would be that these are still stashed, and need to be
>> unstashed and then pushed.

> How can I tell?

> And if those changes are stashed, why did they show up in git diff?

Don't have enough context to say anything here, sorry.

> Anyway, I did 'git stash pop' to see if they were stashed.

> That seems to have changed dozens of files.
> 'git diff origin/master' gave me 5000 lines.

> So I tried doing 'git stash' again, and it gave me an error,

>     fatal: git-write-tree: error building trees
>     Cannot save the current index state

Hm... that's a new one.

> I don't have all the output.  I had run git in a shell buffer a few
> times, and it causes a lot of trouble about the terminal.  So I started
> running it in an ordinary terminal.

> Fortunately it seems that all my changes did make it into Savannah.
> So it is just a matter of how to get a clean repository.

> Is there any way I can fix this other than creating a new repository?
> I should not do that here; it would cost my host too much money, I
> fear.

If you are sure that all of your changes are on savannah, then
 git reset --hard HEAD
should fix things.

Note that if you actually have local changes this is a command that will
lose those changes.

Re: Stash

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Sun, 05 Apr 2015 20:31:07 +0200
> 
> If you are sure that all of your changes are on savannah, then
>  git reset --hard HEAD
> should fix things.
> 
> Note that if you actually have local changes this is a command that will
> lose those changes.

They could be moved aside, as a precaution.

Re: Stash

[Paul Eggert]

Richard Stallman wrote:
> Is there any way I can fix this other than creating a new repository?
> I should not do that here; it would cost my host too much money, I
> fear.

There shouldn't be any need to fear.  It should be cheap to create a new 
repository that is suitable for pushing to Savannah.  You shouldn't need to 
re-copy everything from Savannah; instead, you should be able to clone what you 
have locally, fix the cloned repository so that its master branch exactly 
matches Savannah's, apply your fixes to the cloned repository, and push them.

If your working copy of the source is in /home/rms/src/emacs and it is in the 
master branch, you can do this:

   cd /home/rms/src
   git clone emacs emacs-new
   cd emacs-new
   git branch -m master master-old
   git branch --track master origin/master
   git checkout master
   git pull

At this point, /home/rms/src/emacs will contain the old copy of Emacs with 
whatever glitches are causing problems for you, and /home/rms/src/emacs-new will 
contain a fresh new copy with a master branch that matches what's in Savannah 
and with another branch 'master-old' containing the last things you installed in 
the old copy.

Only one step in the above recipe requires network access, the "git pull", and 
it should be pulling recent deltas so it should be cheap (and the deltas are 
necessary under any workflow).

Once you've built the fresh new copy, you should be able to edit it, commit 
changes, and then do a "git push" (which will be the 2nd step that requires 
network access).

Re: Stash

[Harald Hanche-Olsen]

Paul Eggert wrote:
> Richard Stallman wrote:
> If your working copy of the source is in /home/rms/src/emacs and it is
> in the master branch, you can do this:
>
> cd /home/rms/src
> git clone emacs emacs-new
> cd emacs-new
> git branch -m master master-old
> git branch --track master origin/master
> git checkout master
> git pull

Won't that make the new repository push to the old one?
Then he will need to push twice, in separate repositories, to get stuff 
back on Savannah.

– Harald

Re: Stash

[Steinar Bang]

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

> If your working copy of the source is in /home/rms/src/emacs and it is
> in the master branch, you can do this:

>   cd /home/rms/src
>   git clone emacs emacs-new
>   cd emacs-new
>   git branch -m master master-old
>   git branch --track master origin/master
>   git checkout master
>   git pull

Note that the remote for emacs-new will be the local git repo "emacs",
and not savannah, so I don't see what this buys you wrt. resolving
conflicts...?

Re: Stash

[Harald Hanche-Olsen]

Richard Stallman wrote:
> I don't have all the output.  I had run git in a shell buffer a few
> times, and it causes a lot of trouble about the terminal.  So I started
> running it in an ordinary terminal.

To fix that, arrange set the environment variable GIT_PAGER to the empty 
string in the shell buffer. Or create an alias to run “git --no-pager” 
instead of git.

> Fortunately it seems that all my changes did make it into Savannah.
> So it is just a matter of how to get a clean repository.

If “git status -s” produces no output, I see no reason not to run
git reset --hard origin/master

If it does produce output, you could do

git commit -a -m 'Commited just in case'
git branch badmaster HEAD
git reset --hard origin/master

Now everything in your repository should be just fine, except you might 
have some junk in the badmaster branch. (That was just in case there was 
important information there that you did not want to lose. If some time 
passes and you're confident you haven't lost anything, delete the 
badmaster branch.)

– Harald

Re: Stash

[Paul Eggert]

Harald Hanche-Olsen wrote:
> Won't that make the new repository push to the old one?

True, sorry, I left out a step, which is to change the remote with "git remote 
set-url".  Here's a revised step list:

   cd /home/rms/src
   git clone emacs emacs-new
   cd emacs-new
   git branch -m master master-old
   git remote set-url origin rms@git.sv.gnu.org:/srv/git/emacs.git
   git branch --track master origin/master
   git checkout master
   git pull

Re: Stash

[Stephen J. Turnbull]

Steinar Bang writes:

 > Note that the remote for emacs-new will be the local git repo "emacs",
 > and not savannah, so I don't see what this buys you wrt. resolving
 > conflicts...?

Adding

    git config branch.master.remote $URL_TO_SAVANNAH

to Paul's instructions should do the trick.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Hm... that may not have been enough? Did you stage lisp/ChangeLog before
  > before doing the commit? Ie.

I do not know the term "stage".

  >  git add lisp/ChangeLog
  >  git commit

I think I did this in one of the merges.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I did

   > git reset --hard HEAD

since I had installed all my changes.
Then I did 'git pull' and it reported a lot of things.
Then I did 'git status' which produced this:

    # On branch master
    # Your branch is ahead of 'origin/master' by 2 commits.
    #
    nothing to commit (working directory clean)

What does that second line "ahead of" mean?
Is it a problem?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

One superiority of CVS is 'cvs up' reports its actions in a clear and
concise way.  Once you know what the letters mean, it is all
straightforward.

If it updates a lot of files, I often do 'cvs up' a second time,
knowing it will show me only the files I have changed and might want
to install.

I have forgotten what Bzr's output looked like, but I recall that it
was easy for me to see what conflicts there were.  Then I used vc-dir
to see what files I might need to install.

Git outputs a mass of information.  As a Git beginner I don't
understand what part of it might indicate a problem.  This is a
serious concrete failing of Git.

I think Git ought to have an 'update' facility, for simple usage
scenarios, that would be just as easy to use as cvs update.  In more
complex scenarios, it could refuse to operate.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

>> Hm... that may not have been enough? Did you stage lisp/ChangeLog before
>> before doing the commit? Ie.

> I do not know the term "stage".

It's a magit term for files that are to be part of the commit.

"Staging" and "unstaging" always made more sense to me than adding a
file that's already under version control.

I don't know if "staging" and "unstaging" appear anywhere in the
official git documentation.

Re: Stash

[Steinar Bang]

>>>>> Richard Stallman <rms@gnu.org>:

> I did

>> git reset --hard HEAD

> since I had installed all my changes.
> Then I did 'git pull' and it reported a lot of things.
> Then I did 'git status' which produced this:

>     # On branch master
>     # Your branch is ahead of 'origin/master' by 2 commits.
>     #
>     nothing to commit (working directory clean)

> What does that second line "ahead of" mean?

It means that the branch master has two commits that aren't in
origin/master (which is your local copy of what's on savannah).

> Is it a problem?

I don't think so.  I think they are probably artifacts of two of the
pull commands done, so I think you probably won't need them.

The following is a way to remove the two commits from master in your git
repository, but at the same time put them in a local branch, where they
can be examined later:
 git checkout -b two-unexpected-commits-on-master
 git checkout master
 git fetch
 git reset --hard origin/master

If you decide ahead of time that you don't care about the two commits,
drop the first command ("git checkout -b two-unexpected-commits-on-master").

Note that the "git reset --hard origin/master" is a particularily
dangerous command, because it will make the branch you're currently on a
copy of the branch in the argument, overwriting any commits you may have
had (I've trashed my feature branch in this way at least once, this is
why I always checkout the branch I'm going to run the command on, even
if I'm already there).p

However, in this case "git reset --hard origin/master" does what you
want: make master a priestine copy of what's currently on savannah.

Re: Stash

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Mon, 06 Apr 2015 08:50:15 +0200
> 
> >>>>> Richard Stallman <rms@gnu.org>:
> 
> > I did
> 
> >> git reset --hard HEAD
> 
> > since I had installed all my changes.
> > Then I did 'git pull' and it reported a lot of things.
> > Then I did 'git status' which produced this:
> 
> >     # On branch master
> >     # Your branch is ahead of 'origin/master' by 2 commits.
> >     #
> >     nothing to commit (working directory clean)
> 
> > What does that second line "ahead of" mean?
> 
> It means that the branch master has two commits that aren't in
> origin/master (which is your local copy of what's on savannah).
> 
> > Is it a problem?
> 
> I don't think so.  I think they are probably artifacts of two of the
> pull commands done, so I think you probably won't need them.
> 
> The following is a way to remove the two commits from master in your git
> repository

Perhaps it would be better to look at those two commits first?  I
think the following command will accomplish that:

  git diff origin/master

Re: Stash

[Eli Zaretskii]

> From: Steinar Bang <sb@dod.no>
> Date: Mon, 06 Apr 2015 08:50:15 +0200
> 
> >>>>> Richard Stallman <rms@gnu.org>:
> 
> > I did
> 
> >> git reset --hard HEAD
> 
> > since I had installed all my changes.
> > Then I did 'git pull' and it reported a lot of things.
> > Then I did 'git status' which produced this:
> 
> >     # On branch master
> >     # Your branch is ahead of 'origin/master' by 2 commits.
> >     #
> >     nothing to commit (working directory clean)
> 
> > What does that second line "ahead of" mean?
> 
> It means that the branch master has two commits that aren't in
> origin/master (which is your local copy of what's on savannah).
> 
> > Is it a problem?
> 
> I don't think so.  I think they are probably artifacts of two of the
> pull commands done, so I think you probably won't need them.
> 
> The following is a way to remove the two commits from master in your git
> repository

Perhaps it would be better to look at those two commits first?  I
think the following command will accomplish that:

  git diff origin/master

Re: Stash

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 01:51:06 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> One superiority of CVS is 'cvs up' reports its actions in a clear and
> concise way.  Once you know what the letters mean, it is all
> straightforward.
> 
> If it updates a lot of files, I often do 'cvs up' a second time,
> knowing it will show me only the files I have changed and might want
> to install.

There's no alternative here but to learn to use a different command
for showing that:

  git status --short

It should produce approximately the same display as you are used to
with CVS:

   M modified-file1
   M modified-file2
  ?? unregistered-file1

etc.  You can see the entire set of two-letter status markers in the
man page of "git status".

> I have forgotten what Bzr's output looked like, but I recall that it
> was easy for me to see what conflicts there were.

Bzr would state the conflicted files at the end of the "status"
command.  It also had an explicit "bzr conflicts" command.

Git shows conflicts with two-letter codes; e.g., a file that was
modified both upstream and by you locally will be marked with "UU",
which means that both you and "them" Updated the file.

> Git outputs a mass of information.  As a Git beginner I don't
> understand what part of it might indicate a problem.  This is a
> serious concrete failing of Git.

Do you mean the information presented by "git pull", or do you mean
some other command?

"git pull" outputs roughly the same amount of information as CVS and
bzr would, just in slightly different format.  Here's an example:

  $ git pull
  remote: Counting objects: 215, done.
  remote: Compressing objects: 100% (98/98), done.
  remote: Total 98 (delta 88), reused 0 (delta 0)
  Unpacking objects: 100% (98/98), done.

This part is just status messages during "fetching" (i.e. bringing the
new stuff) from upstream.  It has no direct CVS equivalent; bzr had
something similar.

  From git.savannah.gnu.org:/srv/git/emacs
     ba0a6e9..b884ff3  master     -> origin/master
     21d4bf6..8272c1d  emacs-24   -> origin/emacs-24
   * [new tag]         emacs-24.5-rc3 -> emacs-24.5-rc3

This part describes repository-global events, like new branches, new
tags, etc.

  Updating ba0a6e9..b884ff3
  Fast-forward
   ChangeLog                      |   4 +-
   doc/misc/htmlfontify.texi      |  10 +--
   etc/NEWS                       |   6 ++
   lisp/ChangeLog                 |  17 ++++
   lisp/ChangeLog.16              |   2 +-
   lisp/gnus/ChangeLog            |   8 +-
   lisp/gnus/rtree.el             |   7 +-
   lisp/htmlfontify.el            |  11 +--
   lisp/org/ox-odt.el             |   7 +-
   lisp/progmodes/python.el       |  97 ++++++++++++++++-------
   test/ChangeLog                 |   9 +++
   test/automated/python-tests.el | 173 +++++++++++++++++++++++++++++++++++++++++
   12 files changed, 305 insertions(+), 46 deletions(-)

This is the main part that describes the "merge" step of "git pull":
it says it performed a "fast-forward" (see below), and then shows one
line for each updated file with "diffstat" form of statistics of
changes in each file.  The last line is a summary of the changes.

As you see, this is not very different from what CVS and bzr displayed
in these circumstances.

("Fast-forward" means the stuff fetched from upstream was pure
additions to what you had locally, i.e. your local branch did not
diverge from upstream since the last pull.  If you have local changes
that you committed, but didn't yet push upstream, you will generally
not see the fast-forward part.)

> I think Git ought to have an 'update' facility, for simple usage
> scenarios, that would be just as easy to use as cvs update.

The only major difference between "git pull" and "cvs/bzr update" is
that the latter didn't expose the "fetch" and the "merge" parts to the
user (CVS couldn't expose it because everything was done on the
server).  Git does expose that, so when pull fails due to conflicts,
it tells you about the failed merge.  You need to realize that the
merge in question is an integral part of pull, and simply deal with
the conflicts much in the same way as you'd do for CVS and bzr.

What other parts of "git pull" are "not simple", which you think need
to be simplified?

Re: Stash

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 01:50:37 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> 
>   > Hm... that may not have been enough? Did you stage lisp/ChangeLog before
>   > before doing the commit? Ie.
> 
> I do not know the term "stage".

Git requires to use 2 commands to commit a change in a file:

  git add FILE
  git commit FILE

For files already registered with Git, you can use a single command

  git commit -a FILE

to do that in one go.  ("git add" is still required to register new
files.)

Re: Stash

[Harald Hanche-Olsen]

Eli Zaretskii wrote:
> There's no alternative here but to learn to use a different command
> for showing that:
>
>    git status --short
>
> It should produce approximately the same display as you are used to
> with CVS:
>
>     M modified-file1
>     M modified-file2
>    ?? unregistered-file1

But note that there are *two* flag characters at the beginning of each 
line: One for what's in the index, and the second for the file in the 
work tree.

I find it useful to add --branch to the flags.

And I find it extremely useful to employ git's aliasing mechanism:


; git config --global alias.s 'status --short --branch'
; git help s
`git s' is aliased to `status --short --branch'
; git s
## master...origin/master
;

Make your own shortcuts to often used commands this way. It makes your 
life simpler, at the possible expense of making it harder to explain 
your actions to others. (Just include the necessary “git help” commands 
if you need to explain what you have been doing.)

– Harald

Re: Stash

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 10:35:06 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: sb@dod.no, emacs-devel@gnu.org
> 
> > Date: Mon, 06 Apr 2015 01:50:37 -0400
> > From: Richard Stallman <rms@gnu.org>
> > Cc: emacs-devel@gnu.org
> > 
> >   > Hm... that may not have been enough? Did you stage lisp/ChangeLog before
> >   > before doing the commit? Ie.
> > 
> > I do not know the term "stage".
> 
> Git requires to use 2 commands to commit a change in a file:
> 
>   git add FILE
>   git commit FILE

I failed to say that the 1st of these two is called "staging", since
it prepares the file for being committed.

Re: Stash

[Mathias Megyei]

On 04/06/15 08:55, Eli Zaretskii wrote:
>> From: Steinar Bang <sb@dod.no>
>> Date: Mon, 06 Apr 2015 08:50:15 +0200
>>
>>>>>>> Richard Stallman <rms@gnu.org>:
>>>>>>>
>>>>>>>
>>>>>>> Then I did 'git status' which produced this:
>>>>>>>
>>>      # On branch master
>>>      # Your branch is ahead of 'origin/master' by 2 commits.
>>>      #
>>>      nothing to commit (working directory clean)
>>> What does that second line "ahead of" mean?
> Perhaps it would be better to look at those two commits first?  I
> think the following command will accomplish that:
>
>    git diff origin/master
>
Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?
In this situation 'gitk' (or 'gitk --all') will give all the necessary 
information where
the two commits come from.

Mathias

Re: Stash

[Eli Zaretskii]

> Date: Mon, 06 Apr 2015 13:25:41 +0200
> From: Mathias Megyei <mathias@mnet-mail.de>
> CC: emacs-devel@gnu.org
> 
> > Perhaps it would be better to look at those two commits first?  I
> > think the following command will accomplish that:
> >
> >    git diff origin/master
> >
> Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?

I don't want to assume gitk is installed, nor that the Git commands
are invoked from a sufficiently capable terminal.

Re: Stash

[Yuri Khan]

On Mon, Apr 6, 2015 at 5:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?
>
> I don't want to assume gitk is installed, nor that the Git commands
> are invoked from a sufficiently capable terminal.

A git browser (especially a graphical, point-and-clicky one) is an
immensely useful tool in understanding and learning Git. And gitk is
the one that has the best chance of being installed, or easiest to
install. (Most other git browsers are platform-specific.)

Alternatively, Emacs could include a git browser. (Magit already does;
I don’t know about vc.)


A git browser is most useful if directed to show not only the current
branch but also the associated remote tracking branch, e.g. (assuming
a POSIX shell):

$ gitk HEAD $(git rev-parse --symbolic-full-name @{u}) &

Re: Stash

[João Távora]

On Mon, Apr 6, 2015 at 12:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?
> I don't want to assume gitk is installed, nor that the Git commands
> are invoked from a sufficiently capable terminal.

Fair enough, but perhaps what Mathias meant is that there should be mention
of the commit graph in those pages, and how somehow visualizing it could
clear so many doubts.

There is no mention of "graph" in both Git*ForEmacsDevs pages
and I don't think it's an implementation detail. So at least some ASCII art.

My two cents,
João Távora

Re: Stash

[João Távora]

On Mon, Apr 6, 2015 at 12:56 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> On Mon, Apr 6, 2015 at 5:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?
>>
>> I don't want to assume gitk is installed, nor that the Git commands
>> are invoked from a sufficiently capable terminal.
>
> A git browser (especially a graphical, point-and-clicky one) is an
> immensely useful tool in understanding and learning Git. And gitk is
> the one that has the best chance of being installed, or easiest to
> install. (Most other git browsers are platform-specific.)
>
> Alternatively, Emacs could include a git browser. (Magit already does;
> I don’t know about vc.)
>
>
> A git browser is most useful if directed to show not only the current
> branch but also the associated remote tracking branch, e.g. (assuming
> a POSIX shell):
>
> $ gitk HEAD $(git rev-parse --symbolic-full-name @{u}) &

A command like

git log --graph --pretty=format:'%Cred%h%Creset%n' \
     --abbrev-commit --date=relative --branches --all

or a more sophisticated variation thereof should be readily portable
and provides at least some visualization of the graph.

This particular one stolen from

    http://stackoverflow.com/questions/7007758/how-to-drawedit-an-ascii-git-tree

but I've seen other versions that name branches and labels

-- 
João Távora

Re: Stash

[Eli Zaretskii]

> From: Yuri Khan <yuri.v.khan@gmail.com>
> Date: Mon, 6 Apr 2015 17:56:47 +0600
> Cc: Mathias Megyei <mathias@mnet-mail.de>, Steinar Bang <sb@dod.no>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Mon, Apr 6, 2015 at 5:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?
> >
> > I don't want to assume gitk is installed, nor that the Git commands
> > are invoked from a sufficiently capable terminal.
> 
> A git browser (especially a graphical, point-and-clicky one) is an
> immensely useful tool in understanding and learning Git. And gitk is
> the one that has the best chance of being installed, or easiest to
> install. (Most other git browsers are platform-specific.)
> 
> Alternatively, Emacs could include a git browser. (Magit already does;
> I don’t know about vc.)

All true, but most of that needs user actions to actually show the
diffs; by default they only show the SHA1 values and the DAG, which is
not what is needed here.  And even the DAG itself might be confusing
at times to someone uninitiated.

The instructions, by contrast, aim at being as clear and unequivocal
as possible.  There's nothing more irritating than a recipe that
doesn't work or cannot be followed or understood, particularly when
you are trying to get yourself out of some trouble you don't fully
understand.

> A git browser is most useful if directed to show not only the current
> branch but also the associated remote tracking branch, e.g. (assuming
> a POSIX shell):
> 
> $ gitk HEAD $(git rev-parse --symbolic-full-name @{u}) &

Yes, but all this is almost useless to someone who doesn't yet know
what a "remote tracking branch" is.  It will take time for the
audience of GitQuickStartForEmacsDevs to get there.

Re: Stash

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 6 Apr 2015 12:59:10 +0100
> Cc: Mathias Megyei <mathias@mnet-mail.de>, sb@dod.no, emacs-devel <emacs-devel@gnu.org>
> 
> On Mon, Apr 6, 2015 at 12:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >
> >> Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?
> > I don't want to assume gitk is installed, nor that the Git commands
> > are invoked from a sufficiently capable terminal.
> 
> Fair enough, but perhaps what Mathias meant is that there should be mention
> of the commit graph in those pages, and how somehow visualizing it could
> clear so many doubts.
> 
> There is no mention of "graph" in both Git*ForEmacsDevs pages
> and I don't think it's an implementation detail. So at least some ASCII art.

Thanks.

The DAG is not mentioned there because I'm not sure what purpose that
would serve in the context of the instructions there.

In general, people who use vc-dir are already familiar with the
revision graph, because it's not something invented by Git.

Re: Stash

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 6 Apr 2015 13:06:49 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Mathias Megyei <mathias@mnet-mail.de>, Steinar Bang <sb@dod.no>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> A command like
> 
> git log --graph --pretty=format:'%Cred%h%Creset%n' \
>      --abbrev-commit --date=relative --branches --all
> 
> or a more sophisticated variation thereof should be readily portable
> and provides at least some visualization of the graph.

Do we really need that, given the log view that we already have in VC?

Re: Stash

[João Távora]

On Mon, Apr 6, 2015 at 1:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: João Távora <joaotavora@gmail.com>
>> Date: Mon, 6 Apr 2015 12:59:10 +0100
>> Cc: Mathias Megyei <mathias@mnet-mail.de>, sb@dod.no, emacs-devel <emacs-devel@gnu.org>
>>
>> On Mon, Apr 6, 2015 at 12:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> >
>> >> Is there a reason why you don't mention 'gitk' in GitQuickStartForEmacsDevs?
>> > I don't want to assume gitk is installed, nor that the Git commands
>> > are invoked from a sufficiently capable terminal.
>>
>> Fair enough, but perhaps what Mathias meant is that there should be mention
>> of the commit graph in those pages, and how somehow visualizing it could
>> clear so many doubts.
>>
>> There is no mention of "graph" in both Git*ForEmacsDevs pages
>> and I don't think it's an implementation detail. So at least some ASCII art.
>
> Thanks.
>
> The DAG is not mentioned there because I'm not sure what purpose that
> would serve in the context of the instructions there.
>
> In general, people who use vc-dir are already familiar with the
> revision graph, because it's not something invented by Git.

But Git forces you to understand it intimately.

Even when pushing/pulling linearly to a single branch, which is a
situation where many devs may think they don't have to care about it.
So it's not enough to mention "branches" and "merges" which many
devs might think is someone's elses jurisdiction.

This exposed complexity is fortunate/unfortunate depending on the
point of view. VC may try to hide it: I've seen many attempts to do so
but  never done well, so good luck :-)

-- 
João Távora

Re: Stash

[Steinar Bang]

>>>>> Steinar Bang <sb@dod.no>:

>>>>> Richard Stallman <rms@gnu.org>:
>> I did

>>> git reset --hard HEAD

>> since I had installed all my changes.
>> Then I did 'git pull' and it reported a lot of things.
>> Then I did 'git status' which produced this:

>> # On branch master
>> # Your branch is ahead of 'origin/master' by 2 commits.
>> #
>> nothing to commit (working directory clean)

>> What does that second line "ahead of" mean?

> It means that the branch master has two commits that aren't in
> origin/master (which is your local copy of what's on savannah).

Speficically, it's like this:

A git branch is a list of commits, each pointing to its ancestor
(except for merge commits, which have two ancestors).

Git branches can be (er...) branched, and from the fork of the branch
and backwards, the branches are the same.

Once you have hold of a commit, you actually have hold of a branch with
that commit at its head.

Branch names like "master" and "origin/master" are just symbolic names
pointing to a particular commit.

So what you have (this needs a fixed width font), is:

            origin/master
            |
            v
  --o<--o<--o<--o<--o
                    ^
                    |
                    master

Ie. there is a chain of commits in your local repository forming a
history.  The local branch "master" points to one commit, and the branch
"origin/master" (which is your local representation of the state on
savannah).

When you do
 git fetch
changes are fetched from savanna and added to the list pointed to by
origin/master (actually, the commits are just added, since they already
are pointing back to their ancestor, and origin/master is just changed
to point to the newest commit from savannah).

If you have no changes on your local branch "master", the master branch
can be moved in the same way, ie. "master" can be changed to point to
the newest commit from savannah (this is what's known as a "fast
forward" merge)

If you have commits on your "master", "origin/master" and "master" needs
to be merged, just like any branch.

What I proposed, was to first create a new branch holding the current
state of master, and then reset "master" to point to the same commit as
"origin/master":


            origin/master
            |
            v
  --o<--o<--o<--o<--o
            ^       ^
            |       |
            |       two-unexpected-commits-on-master
            master

"origin/master" and "master" are actually files:
 .git/refs/heads/master
 .git/refs/remotes/origin/master

Inside the files is a sha1 hash uniquely defining a commit.

Re: Stash

[Harald Hanche-Olsen]

Steinar Bang wrote:

Good explanation, but …
> "origin/master" and "master" are actually files:
>   .git/refs/heads/master
>   .git/refs/remotes/origin/master
>
> Inside the files is a sha1 hash uniquely defining a commit.

They are more than that. There is also behaviour associated with these 
branches found in the configuration:

; git config --get-regexp '^branch.master'
branch.master.remote origin
branch.master.merge refs/heads/master
; git config --get-regexp '^remote.origin'
remote.origin.url git://git.savannah.gnu.org/emacs.git
remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
;

(Or just look into .git/config.)

I suppose that you can argue that this is external to the branches 
themselves, but really, the merging and fetching behaviours are central 
to how these branches work.

– Harald

Re: Stash

[Steinar Bang]

>>>>> Harald Hanche-Olsen <hanche@math.ntnu.no>:

> I suppose that you can argue that this is external to the branches
> themselves, but really, the merging and fetching behaviours are
> central to how these branches work.

They are central to how these branches work, but not how commits hang
together, and not to how "origin/master" and "master" points to commits.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This is the main part that describes the "merge" step of "git pull":
  > it says it performed a "fast-forward" (see below), and then shows one
  > line for each updated file with "diffstat" form of statistics of
  > changes in each file.  The last line is a summary of the changes.

  > As you see, this is not very different from what CVS and bzr displayed
  > in these circumstances.

Here are some important differences:

* cvs up indicates in a very visible way which files I have local changes in.

  What's more, if it mentions many other files, I can do cvs up again
  immediately and see ONLY the files I have local changes in.

* cvs up will not "fail".  The worst that can happen is that some
  file has a conflict, and if I don't bother with it immediately,
  I will get reminded of it later.

* git pull outputs lots of unhelpful detail when nothing is wrong.  To
  READ all that would be a useless pain in the neck, so I only checked
  to see when it finished.  Thus, on the occasion when (we now
  suspect) it reported a real problem, I didn't notice.

  > The only major difference

It is a mistake to focus on "major" (i.e., fundamental) differences.
A superficial difference can have a big effect on reliability.
The three differences above may not be major, but they are very important.

			      between "git pull" and "cvs/bzr update" is
  > that the latter didn't expose the "fetch" and the "merge" parts to the
  > user (CVS couldn't expose it because everything was done on the
  > server).

People said that git merge can fail for another reason (I forget
what), not only because of conflicts.  It looked like that might be
what happened to me, which led me to edit an old lisp/ChangeLog file
even though I had just done a git pull.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Eli Zaretskii]

> Date: Tue, 07 Apr 2015 12:13:53 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: sb@dod.no, emacs-devel@gnu.org
> 
>   > This is the main part that describes the "merge" step of "git pull":
>   > it says it performed a "fast-forward" (see below), and then shows one
>   > line for each updated file with "diffstat" form of statistics of
>   > changes in each file.  The last line is a summary of the changes.
> 
>   > As you see, this is not very different from what CVS and bzr displayed
>   > in these circumstances.
> 
> Here are some important differences:
> 
> * cvs up indicates in a very visible way which files I have local changes in.

You mean, the "C" conflict marker?  Or do you mean something else?

>   What's more, if it mentions many other files, I can do cvs up again
>   immediately and see ONLY the files I have local changes in.

As I said, you need to use "git status" for that.  It will show the
same output if invoked repeatedly.

> * cvs up will not "fail".  The worst that can happen is that some
>   file has a conflict, and if I don't bother with it immediately,
>   I will get reminded of it later.

Right, but this is unrelated to the display during "pull".

> * git pull outputs lots of unhelpful detail when nothing is wrong.

Not sure what you allude to here.  Is that the diffstat display of the
amount of changes in each file?  You can turn that off, if you want;
try "git pull --no-stat" (if you like that, it can be made the default
in your .gitconfig).

> 			      between "git pull" and "cvs/bzr update" is
>   > that the latter didn't expose the "fetch" and the "merge" parts to the
>   > user (CVS couldn't expose it because everything was done on the
>   > server).
> 
> People said that git merge can fail for another reason (I forget
> what), not only because of conflicts.

I'm not aware of any, unless they meant uncommitted changes in the
same files that were changed upstream (which is covered on the Wiki
under "conflicts").

> It looked like that might be what happened to me, which led me to
> edit an old lisp/ChangeLog file even though I had just done a git
> pull.

Sorry for asking the obvious: did you revert lisp/ChangeLog's buffer
after pulling?

But anyway, let's not worry about unexplained things in the past that
we cannot explain.

Re: Stash

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> * cvs up will not "fail".  The worst that can happen is that some
>   file has a conflict,

This is a fail.  You have now effectively lost your own changes in a
subtle way.

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: Stash

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Git requires to use 2 commands to commit a change in a file:
 > 
 >   git add FILE
 >   git commit FILE
 > 
 > For files already registered with Git, you can use a single command
 > 
 >   git commit -a FILE

You don't need the "-a", just "git commit FILE" is enough.  ("git
commit -a" (with or without file names) will stage all registered
files that have been modified or deleted to the pending commit.)  If
you use "git add" to "stage" a file for committing, then you can
further abbreviate to "git commit".

Re: Stash

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > People said that git merge can fail for another reason (I forget
 > > what), not only because of conflicts.
 > 
 > I'm not aware of any, unless they meant uncommitted changes in the
 > same files that were changed upstream (which is covered on the Wiki
 > under "conflicts").

Assuming enough free disk and memory, etc, a requested merge that does
not terminate normally is always due to conflicts.

If the conflict is between the incoming branch and content committed
to the current branch, then the merge will be started and terminate
with files updated and conflict markers where needed.  In git, unlike
bzr and hg and "CVS update", normal termination of a merge will also
create a commit object and advance the branch's HEAD pointer.

If the conflict is between the incoming branch and uncommitted changes
in the workspace, the requested merge fails git's preconditions and
does not even start.  No files in the workspace are touched, no commit
objects are created, and the HEAD pointer is not moved.

Some people (who I believe are not native speakers) have called both
non-success modes "failure".

Re: Stash

[Stephen J. Turnbull]

Richard Stallman writes:

 > I think Git ought to have an 'update' facility, for simple usage
 > scenarios, that would be just as easy to use as cvs update.  In
 > more complex scenarios, it could refuse to operate.

Lack of a facility that only merges into the workspace and pays no
attention to the revision history is a deliberate design choice.  One
reason that git developers do not add such a mode is that it can and
does create future conflicts.  What can (and did) happen in CVS is
that developers who preferred to keep pending changes in their
workspaces would repeatedly cvs up and repeatedly resolve different
conflicts, which would end up all jammed together in a single commit.
In CVS, everybody worked on the mainline, and there was very little
branching or cherrypicking, so very little annoyance, since
essentially all workspaces were based on tip of trunk.

However, the resolutions would not be recorded individually in the
history.  In git, this causes headaches for third parties who were
cherrypicking or rebasing because they had only *some* of the
conflicting changes, and had to decide for themselves how to resolve
those conflicts that had resolutions but not conflicting changes.

Often they would decide differently, not knowing the history, and thus
end up reverting the original resolution.  So with git, the annoyance
to other developers became the dominant factor because of the
prevalence of multiple-branch development workflows.  I think it is
likely that a request for such a feature to the Git project would be
immediately closed WONTFIX, but you could try.

You could keep track of whether previous pulls had required conflict
resolution, and refuse to update if there would be conflicts again.  I
suspect that this would be a horrible workflow, requiring a pile of
git knowledge to reconstruct an appropriate state to commit.

Re: Stash

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: rms@gnu.org,
>     sb@dod.no,
>     emacs-devel@gnu.org
> Date: Wed, 08 Apr 2015 04:31:36 +0900
> 
> Eli Zaretskii writes:
> 
>  > Git requires to use 2 commands to commit a change in a file:
>  > 
>  >   git add FILE
>  >   git commit FILE
>  > 
>  > For files already registered with Git, you can use a single command
>  > 
>  >   git commit -a FILE
> 
> You don't need the "-a", just "git commit FILE" is enough.

Right, "git commit -a FILE" emits an error message.  So much for
consistency...

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If the conflict is between the incoming branch and uncommitted changes
  > in the workspace, the requested merge fails git's preconditions and
  > does not even start.  No files in the workspace are touched, no commit
  > objects are created, and the HEAD pointer is not moved.

  > Some people (who I believe are not native speakers) have called both
  > non-success modes "failure".

Both of them are failures, because in both cases the pull doesn't do
its intended job of bringing in the latest changes so you can commit
something correct.

I will not let the Git developers redefine one of these failure modes
as a kind of success.  I will continue to refer to them both as failures.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > * cvs up indicates in a very visible way which files I have local changes in.

  > You mean, the "C" conflict marker?  Or do you mean something else?

Usually M because there are no conflicts.  Occasionally there is a
conflict so it says C.

  > >   What's more, if it mentions many other files, I can do cvs up again
  > >   immediately and see ONLY the files I have local changes in.

  > As I said, you need to use "git status" for that.  It will show the
  > same output if invoked repeatedly.

One more hassle of using Git.

  > > * cvs up will not "fail".  The worst that can happen is that some
  > >   file has a conflict, and if I don't bother with it immediately,
  > >   I will get reminded of it later.

  > Right, but this is unrelated to the display during "pull".

The point is that the output from pull is long and mostly meaningless,
so I didn't look at it at all.

  > Not sure what you allude to here.  Is that the diffstat display of the
  > amount of changes in each file?

That, and all the rest of the output.  It is verbose and doesn't tell
me anything useful, so I don't look at it.

  > > People said that git merge can fail for another reason (I forget
  > > what), not only because of conflicts.

  > I'm not aware of any, unless they meant uncommitted changes in the
  > same files that were changed upstream (which is covered on the Wiki
  > under "conflicts").

Yes, that was it.





-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > * cvs up indicates in a very visible way which files I have local changes in.

  > You mean, the "C" conflict marker?  Or do you mean something else?

Usually M because there are no conflicts.  Occasionally there is a
conflict so it says C.

  > >   What's more, if it mentions many other files, I can do cvs up again
  > >   immediately and see ONLY the files I have local changes in.

  > As I said, you need to use "git status" for that.  It will show the
  > same output if invoked repeatedly.

One more hassle of using Git.

  > > * cvs up will not "fail".  The worst that can happen is that some
  > >   file has a conflict, and if I don't bother with it immediately,
  > >   I will get reminded of it later.

  > Right, but this is unrelated to the display during "pull".

The point is that the output from pull is long and mostly meaningless,
so I didn't look at it at all.

  > Not sure what you allude to here.  Is that the diffstat display of the
  > amount of changes in each file?

That, and all the rest of the output.  It is verbose and doesn't tell
me anything useful, so I don't look at it.

  > Sorry for asking the obvious: did you revert lisp/ChangeLog's buffer
  > after pulling?

I could not have omitted that.   Emacs would have warned me when I tried
to save the file.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > * cvs up will not "fail".  The worst that can happen is that some
  > >   file has a conflict,

  > This is a fail.  You have now effectively lost your own changes in a
  > subtle way.

I've done it hundreds of times.  I don't lose my changes; they are still
there.  It is not a fail, it is normal use.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Eli Zaretskii]

> Date: Wed, 08 Apr 2015 14:21:36 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: sb@dod.no, emacs-devel@gnu.org
> 
>   > As I said, you need to use "git status" for that.  It will show the
>   > same output if invoked repeatedly.
> 
> One more hassle of using Git.

That hassle is common to all modern VCSes, including Bazaar,
Mercurial, and AFAIR also Subversion.  (CVS also has the status
command, btw.)

> The point is that the output from pull is long and mostly meaningless,
> so I didn't look at it at all.
> 
>   > Not sure what you allude to here.  Is that the diffstat display of the
>   > amount of changes in each file?
> 
> That, and all the rest of the output.  It is verbose and doesn't tell
> me anything useful, so I don't look at it.

As I said, please try "pull --no-stat", maybe that is what you want.
You can customize Git to do that by default, if you want.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Lack of a facility that only merges into the workspace and pays no
  > attention to the revision history is a deliberate design choice.  One
  > reason that git developers do not add such a mode is that it can and
  > does create future conflicts.

I prefer future conflicts.  Conflicts are normal, and no problem.

  >   What can (and did) happen in CVS is
  > that developers who preferred to keep pending changes in their
  > workspaces would repeatedly cvs up and repeatedly resolve different
  > conflicts,

I've done this.  It is not a great problem.

	       which would end up all jammed together in a single commit.

The commit I ultimately make contains only my own change.
All the changes from the repository, that conflicted with my change,
I will have merged in.

  > However, the resolutions would not be recorded individually in the
  > history.

As long as I resolve the conflicts myself, which is like unofficial
rebasing, why should that be recorded anywhere?  No one needs to know
it.

Imagine if I had written all my changes just a minute before
installing them.  That would not bother anyone.  This sort of updating
would produce the same results, so it should not bother anyone either.

	      In git, this causes headaches for third parties who were
  > cherrypicking or rebasing because they had only *some* of the
  > conflicting changes, and had to decide for themselves how to resolve
  > those conflicts that had resolutions but not conflicting changes.

I can't understand that, because it involves things about Git that I
don't know and probably never will know.

However, I am skeptical of the claim that installing a simple
localized change, all at once, could cause complexities like that.  If
I push just one commit that changes a file, Savannah will contain zero
changes from me before I push it, and one change from me after I push
it.

  > You could keep track of whether previous pulls had required conflict
  > resolution, and refuse to update if there would be conflicts again.

I could, but I wouldn't.  I'd make it work in all cases, as CVS does.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > That, and all the rest of the output.  It is verbose and doesn't tell
  > > me anything useful, so I don't look at it.

  > As I said, please try "pull --no-stat", maybe that is what you want.

From what you said before, that option would elimate part of the
useless output.  However, the remaining output would still be useless,
so my eyes would still glaze over if I tried to read it.

Thus I concluded that --no-stat would not change much.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Eli Zaretskii]

> Date: Thu, 09 Apr 2015 09:16:28 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: sb@dod.no, emacs-devel@gnu.org
> 
>   > > That, and all the rest of the output.  It is verbose and doesn't tell
>   > > me anything useful, so I don't look at it.
> 
>   > As I said, please try "pull --no-stat", maybe that is what you want.
> 
> From what you said before, that option would elimate part of the
> useless output.  However, the remaining output would still be useless,
> so my eyes would still glaze over if I tried to read it.
> 
> Thus I concluded that --no-stat would not change much.

Please try it.  It eliminates almost everything.

Re: Stash

[Stephen J. Turnbull]

Richard Stallman writes:

 >   > However, the resolutions would not be recorded individually in the
 >   > history.
 > 
 > As long as I resolve the conflicts myself, which is like unofficial
 > rebasing, why should that be recorded anywhere?  No one needs to know
 > it.

That's true in CVS, because in practice nobody branched, and in
practice "cvs update" was all or nothing; people rarely branched to a
tag earlier than HEAD.  In git, however, people *frequently* have
branches that are not up to date, and if your changes involve
conflicts before and after their branch tip, *they* get "screwed" by
spurious conflicts if and when they cherry pick or rebase.

 > Imagine if I had written all my changes just a minute before
 > installing them.  That would not bother anyone.

True.

 > This sort of updating would produce the same results,

I believe that to be true of CVS in practice, but false for git in
practice, for the reasons already given.

 >. so it should not bother anyone either.

 > 	      In git, this causes headaches for third parties who were
 >   > cherrypicking or rebasing because they had only *some* of the
 >   > conflicting changes, and had to decide for themselves how to resolve
 >   > those conflicts that had resolutions but not conflicting changes.
 > 
 > I can't understand that, because it involves things about Git that I
 > don't know and probably never will know.

Then you have a lot of nerve making the claims you make above!

 > However, I am skeptical of the clairm that installing a simple
 > localized change, all at once, could cause complexities like that.

If you really never make changes to more than one file (plus
ChangeLog) at a time, you're probably right.  On the other hand, in
that case I think your solution is simply to remember to push.

Which is where you started AIUI (ie, wanting an automated push).  If
you'd started with the position that you wanted that only for yourself
and asked somebody to do it for you, you'd have it already, and the
rest of us would have been saved a pile of aggravation.

Re: Stash

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> I've done it hundreds of times.  I don't lose my changes; they are still
> there.

It's very easy to fail to notice, and impossible to find out after the
fact.  With git, you can recover the previous state.

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: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Thus I concluded that --no-stat would not change much.

  > Please try it.  It eliminates almost everything.

Ok, I will try it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >  > As long as I resolve the conflicts myself, which is like unofficial
  >  > rebasing, why should that be recorded anywhere?  No one needs to know
  >  > it.

  > That's true in CVS, because in practice nobody branched, and in
  > practice "cvs update" was all or nothing; people rarely branched to a
  > tag earlier than HEAD.  In git, however, people *frequently* have
  > branches that are not up to date, and if your changes involve
  > conflicts before and after their branch tip, *they* get "screwed" by
  > spurious conflicts if and when they cherry pick or rebase.

I can't fully really understand this, but I think we are
miscommunicating and that what you say is not applicable to what I
actually want to do.

If I find a way to pull in changes in files I have edited, as was
normal with CVS and Bzr, eventually I will install one commit
containing my changes to the version current at that time.  The effect
on Savannah will be equivalent to editing in all my changes at that
time and installing them immediately.

In fact, that is what I am thinking of doing: working in a non-Git
copy of the sources, and putting changes them into the Git-managed
directory only to install them immediately on Savannah.

If that does cause a problem, you're going to have the problem -- it
is up to you to convince me not to use that method.

But I think you must be mistaken, that it can't cause any problem, and
therefore the local merging I'd like to do with Git also could not
cause any problem.

  >  > I can't understand that, because it involves things about Git that I
  >  > don't know and probably never will know.

  > Then you have a lot of nerve making the claims you make above!

I have something better than nerve: a mental proof that the two
scenarios (see above) are equivalent for everyone other than me.  If
you claim that one causes problems and admit the other does not, you
must be mistaken somewhere.  To be charitable, I suppose you do
understand Git and you misunderstood what I'd like to do.

  > If you really never make changes to more than one file (plus
  > ChangeLog) at a time, you're probably right.

Forget that tangent.  I've already told you that I develop various
changes, over time, in parallel, in various different files.

In order to test them all in real use, I must have them all in the
sources of the Emacs I am actually using.

I must be able to install one change in Savannah when it is ready,
without installing the others that are not ready.

The methods that others have proposed seem to involve using lots of
branches which I'd have to merge in order to test it all.  That seems
error-prone as well as lots of work.

I will discuss my ideas for this with others, off the list.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I've done it hundreds of times.  I don't lose my changes; they are still
  > > there.

  > It's very easy to fail to notice, and impossible to find out after the
  > fact.

Your statements do not accord with my experience -- and I have lots
of experience maintaining Emacs with cvs.  Sometimes I did cvs up
many times with some of my changes remaining in the working files.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! See stallman.org/skype.html.

Re: Stash

[Eli Zaretskii]

> Date: Fri, 10 Apr 2015 06:58:11 -0400
> From: Richard Stallman <rms@gnu.org>
> Cc: sb@dod.no, emacs-devel@gnu.org
> 
> In fact, that is what I am thinking of doing: working in a non-Git
> copy of the sources, and putting changes them into the Git-managed
> directory only to install them immediately on Savannah.
> 
> If that does cause a problem, you're going to have the problem -- it
> is up to you to convince me not to use that method.

It could still cause the push to be rejected, if someone pushes
between your pull and your push.  But if you commit your
to-be-installed changes locally after putting those changes into the
Git-managed tree, such rejects can be easily handled by another pull
and potentially conflict resolution, similar to what you were used to
with CVS.

Re: Stash

[Stephen J. Turnbull]

Richard Stallman writes:

 > I will discuss my ideas for this with others, off the list.

Great!