Re: [git-users] keeping #comments inside the commit message

2013-05-08 Thread Dale R. Worley
 From: Rodolfo rodolfo.bor...@gmail.com
 
 I'm not wrong, I know git is behaving as it was specified to behave.
 
 I just think the other way would be better, and suggesting the
 specification could be changed.

Be aware that there is a language difficulty here:  The particular
verb forms that you used in your original message imply that you
believed in the past that Git would remove just the lines starting
with # at the end of the file:

  I thought it should remove just the consecutive lines starting with #

I thought implies that you thought this in the past, but since then
you changed your belief.  This suggests that your belief was changed
by seeing that Git did not behave as you believed it would.  (In this
meaning, the should should be omitted, and appears to the reader
(i.e., me) to be a simple error.)

Your query

  Am I wrong?

suggests that you are discussing a matter of fact.

If you want to express an opinion as to how Git should behave, you
would use this verb form:

I think it should remove ...

In this case, a query asking if we agree or disagree with this opinion
would be

Do you agree?

(The meanings of the various English verb forms are quite complicated
and irregular.  But you are quite fluent in English, so we assumed
that you were using them in an exact manner.)

--

And I do agree that Git should only remove the lines starting with #
at the end of the file.  (Subversion uses a similar convention.)

 On Fri, May 3, 2013 at 3:20 PM, Konstantin Khomoutov
 flatw...@users.sourceforge.net wrote:
  On Fri, 3 May 2013 08:00:32 -0700 (PDT)
  bart9h rodolfo.bor...@gmail.com wrote:
 
  When you edit the commit message, it comes with a bunch of comments
  at the end of the file that will be removed automatically later.
 
  I thought it should remove just the consecutive lines starting with #
  at the end of the file, not lines starting with # inside the message,
  like:
 
  summary of the changes
 
  This is the longer explanation, and
  # this line here should not be removed.
  Am I wrong?
 
  As Dale pointed out, you're wrong.
  But it seems you could pass the --cleanup=whitespace command-line
  option to `git commit` to make it not touch the comment lines.
  You will have to manually remove them though.  Or play with
  the commit.template configuration option.  Or may be with a hook which
  is called to precompose the commit message (I can't recall its exact
  name at the moment).

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [git-users] keeping #comments inside the commit message

2013-05-08 Thread Konstantin Khomoutov
On Tue, 7 May 2013 15:19:22 -0300
Rodolfo rodolfo.bor...@gmail.com wrote:

  When you edit the commit message, it comes with a bunch of comments
  at the end of the file that will be removed automatically later.
 
  I thought it should remove just the consecutive lines starting
  with # at the end of the file, not lines starting with # inside
  the message, like:
 
  summary of the changes
 
  This is the longer explanation, and
  # this line here should not be removed.
  Am I wrong?
 
  As Dale pointed out, you're wrong.
  But it seems you could pass the --cleanup=whitespace command-line
  option to `git commit` to make it not touch the comment lines.
  You will have to manually remove them though.  Or play with
  the commit.template configuration option.  Or may be with a hook
  which is called to precompose the commit message (I can't recall
  its exact name at the moment).
 
 I'm not wrong, I know git is behaving as it was specified to behave.

Don't be offended, please.  You asked if you were wrong and I answered
that yes, you did.  That wasn't to underline your wrongness or
something like that, just answering the question.

 I just think the other way would be better, and suggesting the
 specification could be changed.

I, too, think that removing all the comment lines might be good for
scripts but is supposedly not so good for humans.

 In which use cases there are comment lines mixed with the commit
 message?

I, for one, do not know.  I can make a wild guess: in certain
situations a commit message might end up being composed out of several
templates, each inserting its own comments.  This is a pure
speculation, though.

Note that from following the main Git list for some time I gathered
that not every Git feature (or misfeature) is there for a reason --
quite some of them are there just because they got implemented in a way
which seemed reasonable at the moment and only extensive usage proved
the initial premises to be wrong.  In this venue I might recall the
--set-upstream command-line option to `git branch` (which no single
human being seemed to use correctly on the first try) and the default
value of the push.default configuration option (which is hardly
suitable for beginners).

So I think you might consider asking a question on the main Git list [1]
to hear the opinion of Git developers.

1. http://vger.kernel.org/vger-lists.html#git

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[git-users] Re: HELP! stash pop is failing and I can't get my work out

2013-05-08 Thread Yawar Amin
Hi,

On Friday, March 8, 2013 4:06:04 PM UTC-5, Piers H wrote:
 why does git require all these gymnastics just to do a simple merge?
 with SVN it was 1 command, and I never had any issues with it. i don't
 understand.

You'll need to adjust your workflow a little bit. Git has a different
philosophy from Subversion, you need to adapt mentally. It's not a great
hardship.

Do your local work and commit it. Don't leave any files out of the
commit(s) if you need them. Commit everything you can.

Then, do a git pull. If this causes a merge conflict, you can solve it
like any other merge conflict, in a sane way.

No need to stash your changes.

Regards,

Yawar

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.