git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Angelo Borsotti <angelo.borsotti@gmail.com>
To: Phil Hord <phil.hord@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: erratic behavior commit --allow-empty
Date: Wed, 3 Oct 2012 15:35:31 +0200	[thread overview]
Message-ID: <CAB9Jk9DmFQcgd2jT4c1eMx91mikchVcKfNVLsmfjxaZL_G3vTQ@mail.gmail.com> (raw)
In-Reply-To: <CABURp0oHez6j8+FPG8Zm52TGVyC1XwWhE55TBDrXRGFrW6kWww@mail.gmail.com>

Hi Phil

>
> I think what you are missing here is that the script does _not_ have
> to take care for this special case.  The script can do the same thing
> it does for all the other cases and it will work just fine.  This is
> because your goal, as I understand it, is this:
>
> A. Take this branch,
> B. Copy it but remove the binaries,
> C. Push it to the remote (with no binaries)
>
> If the branch has no binaries to begin with, then B is a no-op.  Your
> insistence that the new commits get unique SHA1's is unnecessary and
> is what is causing your trouble.

Suppose the branch has binaries. Then the only way to avoid to push
them is to create an orphan branch (one that has no parents),
otherwise git push will upload also the parent with its binaries.
This is why there is a need to make the script perform different
actions depending on the presence of the binaries. In the attempt to
make the script handle both cases in a simple way I tried to make an
empty commit, and discovered the time-dependent behavior of it.

>
> Consider this analogous operation:
>
> A. Take this file,
> B. Remove every line that does not contain foo,
> C. Cat the result to the console (with only foo lines)
>

This example differs from the commit one in that the user has to cope
with data that s/he can fully control (the contents of files), while
in the other s/he has to cope with the passing of time, which s/he
cannot control. So, taking the files I can predict the result, but
taking the commits, I cannot because I do not know exactly when they
will actually be run. Time is a sort of independent variable that I
know only approximately (or very approximately when the commands are
embedded in scripts).

>
> It seems to those more familiar with git that you are saying that this
> is "the problem", that the operation did not work because the results
> are not unique each time.

Exactly.

>
> But if you ignore the SHA1 of the commits and just rely on the branch
> names, I think you will be happier.  This is because two branches can
> refer to the same SHA1 commit without causing any problem.  You may
> find that sometimes when you push there is no update applied to the
> server.  But this is not a mistake.  It is simply that the server
> already has the same contents as you are pushing, even though your
> local branch name is different than it was before.

Actually I ignore the SHA1 of the commits, and rely on the branch
names I have topic branches and /src/topic branches. Developers push
when they have something new. Of course the scripts must take care of
when they are called and there is nothing to push, but that is not a
big problem.
I eventually found a workaround, which is to change the commit
message, forcing then git commit to create a brand new commit.

> I think when you say "orphan" you mean it has a different SHA1 than
> any other commit.  But this is not what "orphan" means.

No, I mean that it has no parents.

Actually, in the special case in which there are no binaries, I could
create a branch that points to the same commit as the branch that it
is mirroring, and push it. However, this has two disadvantages: 1.
that it will not be an orphan while in the more general case it is,
and 2, that the history of commits will be pushed to the remote
server, while in the general case (with an orphan) it will not. I
preferred to have a unique branch topology so as to make the picture
as simple as possible for the developers.

Note that eventually I solved the problem with a tweak. I still
believe that the git commit command does not behave properly, and that
changing nothing (implementation or documentation) leaves a drifting
mine on which someone (or even myself) will stumble sooner or later. I
am spending time to write all this because I care for git and I would
really see it improving over time removing weak spots, and believe
that you do the same.

-Angelo
>
> Phil

  parent reply	other threads:[~2012-10-03 13:35 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02  7:51 erratic behavior commit --allow-empty Angelo Borsotti
2012-10-02  8:26 ` Johannes Sixt
2012-10-02  8:49   ` Angelo Borsotti
2012-10-02 17:27   ` Junio C Hamano
2012-10-02 19:34     ` Angelo Borsotti
2012-10-02 19:56       ` Junio C Hamano
2012-10-02 21:56         ` Angelo Borsotti
2012-10-03  2:10           ` PJ Weisberg
2012-10-03  5:37           ` Johannes Sixt
2012-10-03  6:22             ` Angelo Borsotti
2012-10-03  6:27               ` Johannes Sixt
     [not found]                 ` <CAB9Jk9AgtNQfWDr31CWbXf2ag=11du-aruu-0+nOZ3KaaG9=og@mail.gmail.com>
2012-10-03  7:12                   ` Johannes Sixt
2012-10-03  7:35                     ` Angelo Borsotti
2012-10-03 20:49                     ` Junio C Hamano
2012-10-03  7:29           ` Philip Oakley
2012-10-03  7:45             ` Angelo Borsotti
2012-10-03  8:04               ` Matthieu Moy
2012-10-03  8:24                 ` Angelo Borsotti
2012-10-03 11:07                   ` Matthieu Moy
2012-10-03 11:52                     ` Angelo Borsotti
     [not found]                       ` <CABURp0oHez6j8+FPG8Zm52TGVyC1XwWhE55TBDrXRGFrW6kWww@mail.gmail.com>
2012-10-03 13:35                         ` Angelo Borsotti [this message]
2012-10-03 14:15                           ` Phil Hord
2012-10-03 13:57                       ` Matthieu Moy
2012-10-03 14:46                         ` Angelo Borsotti
2012-10-03 14:52                           ` Matthieu Moy
2012-10-03 22:32                       ` Philip Oakley
2012-10-04  7:07                         ` Angelo Borsotti
2012-10-04 13:24                           ` Phil Hord
2012-10-04 19:00                             ` Angelo Borsotti
2012-10-04 21:17                           ` Philip Oakley
2012-10-04 22:09                             ` Angelo Borsotti
2012-10-04 22:42                               ` Philip Oakley
2012-10-04 23:10                                 ` Angelo Borsotti
2012-10-03 12:25                   ` Tomas Carnecky
2012-10-03 13:08                     ` Angelo Borsotti
2012-10-03 10:12               ` Andreas Schwab
2012-10-03 11:37                 ` Angelo Borsotti
2012-10-03 13:44                   ` Andreas Schwab
2012-10-03 14:37                     ` Angelo Borsotti
2012-10-03 16:44                       ` Andreas Schwab
2012-10-03 17:37                         ` Angelo Borsotti
2012-10-03 19:03                           ` Andreas Schwab
2012-10-03 19:11                             ` Angelo Borsotti
2012-10-03 20:30                               ` Andreas Schwab
2012-10-03 12:59       ` Phil Hord
2012-10-03 14:25         ` Angelo Borsotti
2012-10-03 16:06           ` PJ Weisberg
2012-10-03 17:34             ` Angelo Borsotti
2012-10-03 19:05               ` Andreas Schwab
2012-10-03 19:43               ` PJ Weisberg
2012-10-05  8:15               ` Lars Noschinski
2013-01-12 18:30   ` Jan Engelhardt
2013-01-16 12:26     ` Joachim Schmitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAB9Jk9DmFQcgd2jT4c1eMx91mikchVcKfNVLsmfjxaZL_G3vTQ@mail.gmail.com \
    --to=angelo.borsotti@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=phil.hord@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).