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

On Wed, Oct 3, 2012 at 9:35 AM, Angelo Borsotti
<angelo.borsotti@gmail.com> wrote:
> 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 true only if the root commit also has binaries.  Otherwise it
is fine to push a branch with the common ancestor.

Suppose A does not have binaries but B and C do.

A---B---C

Now we need to make a new branch ending at C' which has no binaries:
A---B---C
 \
  ---B'---C'

A already has no binaries, so we did not need to make an A'.  Now we
can push C' to the server and no binaries will be pushed.  That is
because the server will receive only these commits:

A---B'---C'


> 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.

Every commit is time-dependent.  You tried to make a _unique_ empty
commit, and this is where you ran into trouble.  I think your
uniqueness constraint is overkill.


>> 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).

You need not be concerned with the time on the commit, nor the
uniqueness of the SHA1.


>> 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.

Doesn't this force git always to push new commits even though the
contents match commits already on the server?

>> 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.

It seems to me that you are creating unnecessary work for the server
and for your scripts.  But perhaps I do not fully understand your use
case.

> 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.

You may suggest improvements to the documentation.  But be careful to
understand the existing documentation completely before you do.

Thanks for helping.

Phil

  reply	other threads:[~2012-10-03 14:16 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
2012-10-03 14:15                           ` Phil Hord [this message]
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=CABURp0okOXpZGGawAUfUEUq3ahSHic-80qsfr5oJ4jX5ZFUh4g@mail.gmail.com \
    --to=phil.hord@gmail.com \
    --cc=angelo.borsotti@gmail.com \
    --cc=git@vger.kernel.org \
    /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).