git push weird?

git push weird?

[Thien-Thi Nguyen]

I just did my first push to the savannah repo, and it did not go as i
expected: the web interface shows three commits instead of one.

The command used was:

  git push -v origin ttn/misc-maint:master

but that's apparently not correct.  What should i have used?
(The intent is to only add the commit titled "[maint] Add...".)

thi

Re: git push weird?

[Xiangfu Liu]

Hi

git is offline version control. so if you committed in local several times,
when you git push. it will push all of your committed to server.

hopt this can help.

On 06/15/2010 07:36 PM, Thien-Thi Nguyen wrote:
> I just did my first push to the savannah repo, and it did not go as i
> expected: the web interface shows three commits instead of one.
>
> The command used was:
>
>    git push -v origin ttn/misc-maint:master
>
> but that's apparently not correct.  What should i have used?
> (The intent is to only add the commit titled "[maint] Add...".)
>
> thi
>


-- 
Best Regards
Xiangfu Liu
http://www.openmobilefree.net

Re: git push weird?

[Thien-Thi Nguyen]

() Xiangfu Liu <xiangfu.z@gmail.com>
() Tue, 15 Jun 2010 22:41:35 +0800

   git is offline version control.
   so if you committed in local several times,
   when you git push. it will push all of your committed to server.

   hopt this can help.

Thanks.  I think i should have done a "git rebase" prior to "git push"
in order to isolate the one commit that i wanted to share.

In the meanwhile, i have also done:

  $ git push -v origin ttn/misc-maint
  Pushing to ssh://ttn@git.sv.gnu.org/srv/git/guile.git
  Enter passphrase for key '/home/ttn/.ssh/sv': 
  Total 0 (delta 0), reused 0 (delta 0)
  To ssh://ttn@git.sv.gnu.org/srv/git/guile.git
   * [new branch]      ttn/misc-maint -> ttn/misc-maint
  updating local tracking ref 'refs/remotes/origin/ttn/misc-maint'

I think it is ok for the branch ‘ttn/misc-maint’ to have many different
commits.  So now i would like to undo the damage on "master".  I think
only a project administrator is able to do that, however...

thi

Re: git push weird?

[Ludovic Courtès]

Hello,

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> I just did my first push to the savannah repo, and it did not go as i
> expected: the web interface shows three commits instead of one.

These are “merge commits”.  Please avoid pushing any merge commits as
they make the history non-linear for no reason in such situations.  See
‘git rebase’ and the like for how to avoid it.

Besides, did you mean to push to ‘master’?

Thanks,
Ludo’.

Re: git push weird?

[Thien-Thi Nguyen]

() ludo@gnu.org (Ludovic Courtès)
() Tue, 15 Jun 2010 20:56:19 +0200

   These are “merge commits”.  Please avoid pushing any merge commits as
   they make the history non-linear for no reason in such situations.
   See ‘git rebase’ and the like for how to avoid it.

OK.

   Besides, did you mean to push to ‘master’?

Yes, but now i believe that that was fuzzy thinking, not to mention
in disregard of my agreement to not do so made several months ago
(which i didn't remember until just after pressing RET -- sigh).  :-(
I will push only to ttn/* henceforth.

Could you please undo the damage on ‘master’?

FWIW, the commit edb3cfc37de8c216e3b1c06970ef39e3638560be,
aka "[maint] Add configure.ac abstraction: GUILE_CONFIG_SCRIPT",
is ready for review.

The other commit 0faca15c33cfbe1ef25fd6b4bbc7f92b57659345,
aka "Init shell var properly in git-version-gen", is functional,
and would also be ready for review, were it not my belief that the
change should actually be effected by import from upstream (gnulib).
Am i missing something?  That's the commit i wanted to omit.

thi

Re: git push weird?

[Ludovic Courtès]

Hi,

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> Yes, but now i believe that that was fuzzy thinking, not to mention
> in disregard of my agreement to not do so made several months ago
> (which i didn't remember until just after pressing RET -- sigh).  :-(

Heh, no problem.  ;-)

> I will push only to ttn/* henceforth.

OK.

> Could you please undo the damage on ‘master’?

I just removed your commits, reverting to
1772145c0222e4826e5113c14ee96fd95b263420.  Hopefully that won’t cause
any problem to others, as I haven’t seen any public activity in between.

I’ll comment on your commits in a separate message.

Thanks,
Ludo’.

Re: git push weird?

[Andy Wingo]

Greets,

On Tue 15 Jun 2010 21:39, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () ludo@gnu.org (Ludovic Courtès)
> () Tue, 15 Jun 2010 20:56:19 +0200
>
>    Besides, did you mean to push to ‘master’?
>
> Yes, but now i believe that that was fuzzy thinking, not to mention
> in disregard of my agreement to not do so made several months ago
> (which i didn't remember until just after pressing RET -- sigh).  :-(
> I will push only to ttn/* henceforth.

Cool, that would be great.

> Could you please undo the damage on ‘master’?

Just for readability I have rebased the commits. The gnulib commit will
get overwritten at the next gnulib import. GUILE_CONFIG_SCRIPT is fine.

It's good to have tmpfile, but I wonder about making the port-filename
not a string or #f. 'tmpfile seems too magical to me; if you're working
from scheme you can always associate a tmpfile object property on the
port, and I wouldn't want people to start asking if it's a tmpfile. So I
have changed it to return #f.

If you really think that 'tmpfile is the right thing, let's talk about
it :)

Cheers,

Andy
-- 
http://wingolog.org/

Re: git push weird?

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Tue, 15 Jun 2010 23:07:47 +0200

   Just for readability I have rebased the commits. The gnulib commit will
   get overwritten at the next gnulib import. GUILE_CONFIG_SCRIPT is fine.

OK, thanks for cleaning up my mess.

   It's good to have tmpfile, but I wonder about making the port-filename
   not a string or #f. 'tmpfile seems too magical to me; if you're working
   from scheme you can always associate a tmpfile object property on the
   port, and I wouldn't want people to start asking if it's a tmpfile. So I
   have changed it to return #f.

Why wouldn't you want people to start asking if it's a tmpfile?
People are curious.

   If you really think that 'tmpfile is the right thing, let's talk about
   it :)

One way to rationalize 'tmpfile is to consider #f to denote "invalid", in
which case #f for the ‘tmpfile’ (the port-returning proc) does not ring true.

On the other hand, until another file-port with non-string filename type
rears, i have no problem mentally keeping track of:

   (port-filename P) => 'tmpfile

         ===

   (and (file-port? P) (not (port-filename P)))

except that ‘file-port?’ does not exist in Guile 1.4.x (another reason to hoof
it over to official Guile :-).

The bigger question is (to touch upon a past discussion) the separation of
"file name" into "directory component + base name".  If that ever comes to
pass (fundamentally), i think ‘port-filename’ won't mind transparently
passing the (richer) information to the user, with rv type most likely in
the set {#f, string, location (d+b)}, with some distinguished locations
symbolic.  Then we can welcome the return of 'tmpfile.

thi

Re: git push weird?

[Andy Wingo]

Hi,

On Tue 15 Jun 2010 23:56, Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Andy Wingo <wingo@pobox.com>
> () Tue, 15 Jun 2010 23:07:47 +0200
>
>    Just for readability I have rebased the commits. The gnulib commit will
>    get overwritten at the next gnulib import. GUILE_CONFIG_SCRIPT is fine.
>
> OK, thanks for cleaning up my mess.

No prob. FWIW what happened was that Ludovic and I both responded and
reverted at the same time; amusing. We worked it out on IRC in the end.
His comments are still valid, of course.

>    If you really think that 'tmpfile is the right thing, let's talk about
>    it :)
>
> One way to rationalize 'tmpfile is to consider #f to denote "invalid", in
> which case #f for the ‘tmpfile’ (the port-returning proc) does not
> ring true.

I don't think that #f is invalid; it's simply "no file name available",
which is true in this case.

> On the other hand, until another file-port with non-string filename type
> rears, i have no problem mentally keeping track of:
>
>    (port-filename P) => 'tmpfile
>
>          ===
>
>    (and (file-port? P) (not (port-filename P)))

I'm definitely on the side of the curious peoples of the world, but I
also have to maintain this thing :P Can you give a use case for when you
want to know if a port is a tmpfile?

> The bigger question is (to touch upon a past discussion) the separation of
> "file name" into "directory component + base name".  If that ever comes to
> pass (fundamentally), i think ‘port-filename’ won't mind transparently
> passing the (richer) information to the user, with rv type most likely in
> the set {#f, string, location (d+b)}, with some distinguished locations
> symbolic.  Then we can welcome the return of 'tmpfile.

Perhaps. I don't think we really have filename handling right yet.
Definitely something to consider in that context :)

Cheers,

Andy
-- 
http://wingolog.org/

Re: git push weird?

[Thien-Thi Nguyen]

() Andy Wingo <wingo@pobox.com>
() Wed, 16 Jun 2010 00:15:47 +0200

   Can you give a use case for when you
   want to know if a port is a tmpfile?

Off the top of my head, nothing serious, only for general debugging
control freakery.  I think the last time i used it was when a child
process (of sizzweb, part of ttn-do) got stuck somewhere, and i used
that info plus lsof(8) to poke under the rock, so to speak...

That was over a year ago, and an exception-al condition; this low
usage is why i'm not particularly attached to the idea.

thi