On Tuesday 2012-10-02 10:26, Johannes Sixt wrote:
>
>Note that git commit -m A --allow-empty *DID* create a commit. Only, that
>it received the same name (SHA1) as the commit you created before it
>because it had the exact same contents (files, parents, author, committer,
>and timestamps). Obvious
Jan Engelhardt wrote:
On Tuesday 2012-10-02 10:26, Johannes Sixt wrote:
Note that git commit -m A --allow-empty *DID* create a commit. Only,
that it received the same name (SHA1) as the commit you created
before it because it had the exact same contents (files, parents,
author, committer, and t
Am 10/2/2012 9:51, schrieb Angelo Borsotti:
> This is the log of the second execution:
>
> $ emptycommit
> + rm -rf local
> + mkdir local
> + cd local
> + git init
> Initialized empty Git repository in d:/gtest/local/.git/
> + echo aaa
> + git add f1
> warning: LF will be replaced by CRLF in f1.
>
Hi
having such a time-dependent behavior is not nice. It means that the user must
know it, and wait patiently before issuing the command, or in a script
add a sleep
before the command.
The choice is then between adding a warning in the man page ("please
wait at least
a second before executing the
Johannes Sixt writes:
> Note that git commit -m A --allow-empty *DID* create a commit. Only, that
> it received the same name (SHA1) as the commit you created before it
> because it had the exact same contents (files, parents, author, committer,
> and timestamps). Obviously, your script was execu
Hi Junio,
if I put on my head the implementor's hat, I would agree with you: that command
after all behaves as implemented.
However, if I put the user's hat I would reason differently. What I
need are predictable
commands, and that by all means is not. This because the time at which a command
is e
Angelo Borsotti writes:
> "Usually recording a commit that has the exact same tree as its sole
> parent commit is a mistake, and the command prevents you from making
> such a commit. This option bypasses the safety, and is primarily for
> use by foreign SCM interface scripts."
>
> I cannot find a
Hi Junio,
> It does create one; it just is the same one you already happen to have,
> when you record the same state on top of the same history as the
> same person at the same time.
>
No, it does not create one: as you can see from the trace of the execution
of my script, the sha of the commit i
On Tue, Oct 2, 2012 at 2:56 PM, Angelo Borsotti
wrote:
> Hi Junio,
>
>> It does create one; it just is the same one you already happen to have,
>> when you record the same state on top of the same history as the
>> same person at the same time.
>>
>
> No, it does not create one: as you can see fro
Am 10/2/2012 23:56, schrieb Angelo Borsotti:
> The problem I am trying to solve is to push to a remote server the
> source files only,
> while keeping in the local repo both sources and binaries. To do it, I
> keep an orphan
> branch, [...]
>
> # this is the commit on the master branch
> git init
Hi PJ and Hannes,
try to run the last script that I posted, with and without a sleep 1
before the last commit:
git init
echo "aaa" >f1
git add f1
git commit -m A
git checkout --orphan sources
git commit -m A --allow-empty
and
git init
echo "aaa" >f1
git add f1
git commit -m A
git checkout --orp
Not answering questions does not help anyone.
My question was: What is the point in insisting that there is a *really*
new commit when the one commit that already existed has exactly the
content that you wanted?
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
Cc restored; please reply to all.
Am 10/3/2012 8:32, schrieb Angelo Borsotti:
> Hi Hannes,
>
> well, I thought I replied to your question:
>
>"What is the point in insisting that there is a *really*
>new commit when the one commit that already existed has exactly the
>content that yo
From: "Angelo Borsotti"
Hi Junio,
It does create one; it just is the same one you already happen to
have,
when you record the same state on top of the same history as the
same person at the same time.
No, it does not create one:
Angelo
This is a semantics problem. It is like the confusio
Hi Hannes,
>
> Perhaps you are confused by the fact that the commit you made first does
> not have a parent, either. But that is just a "side effect" that it
> happened to be the very first commit that you made after 'git init'.
Well, I know that, and this is why I added --allow-empty. The man pa
In reply to Philip,
I understand what the implementation does, but I am stating that it is
not what the
user (by reading the man page) expects.
The user adds --allow-empty to have a different & unique commit, such seems to
be the purpose of the option.
Unfortunately, it gets that only sometimes, d
Angelo Borsotti writes:
> I think that you would agree with me that this is not a nice
> behaviour.
This is fundamentally how Git works. You probably didn't notice it, but
if you do
echo 'some content' > file1.txt
git add file1.txt
git commit -m "file1"
echo 'some content' > file2.txt
git add
Hi Matthiew,
> Then the second commit does not "create" a new blob object for
> file2.txt, because it has the same content as an existing one. But the
> point is: you really don't care, or indeed, you care about sharing the
> blob objects to save disk space.
That is fine, and it is well documente
Angelo Borsotti writes:
> The user adds --allow-empty to have a different & unique commit
Where does the manual say that --allow-empty implies a different and
unique commit?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4
Angelo Borsotti writes:
>> You still didn't tell us where the problem was.
>
> I described it few mails above. I wanted to create an orphan branch.
And you did. The branch happens to point to the same commit as another
existing commit, but this is a very common situation. Try this:
# do arbitra
Hi Andreas,
>
> Where does the manual say that --allow-empty implies a different and
> unique commit?
>
In the git commit man page:
"--allow-empty
Usually recording a commit that has the exact same tree as its
sole parent commit is a mistake, and the command prevents you from
making such a
On Wed, 03 Oct 2012 10:24:00 +0200, Angelo Borsotti
wrote:
> create a new one. To force it to create a brand new one I added
> --allow-empty to it
> because the man page stated that it would bypass the check that prevents to
> make
> a new one. The I discovered that sometimes --allow-empty does
On Tue, Oct 2, 2012 at 3:34 PM, Angelo Borsotti
wrote:
>
> "Usually recording a commit that has the exact same tree as its sole
> parent commit is a mistake, and the command prevents you from making
> such a commit. This option bypasses the safety, and is primarily for
> use by foreign SCM interfa
Hi Thomas,
> The documentation only states that it will skip the 'same tree as parent'
> check, not that it will *always* create a new commit.
Ok, understood: you believe that the documentation is clear, and I
that it is somehow not.
I would prefer to have it more plain.
But that is not all the
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,
Angelo Borsotti writes:
> By reading: "the command prevents" I understand that a new commit is
> not created, and "This option bypasses" that it is instead created.
But where does it say "different and unique"?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7
Angelo Borsotti writes:
> [...] making then the orphan branch point to the master one, i.e.
> becoming a non-orphan one.
I understand both parts of the sentense, but not the "i.e.".
And I still don't see a concrete problem. "two branches point to the
same commit" is not a problem, it's an obser
On Wed, Oct 3, 2012 at 9:35 AM, Angelo Borsotti
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
Hi Phil,
> Perhaps the confusion arises from the the meaning of "the safety". In
> this case, the safety mechanism in place is to prevent you from
> creating a child commit which has the same "tree" contents (working
> directory) as the parent commit. It will not be the same commit
> because it
Hi Andreas,
> But where does it say "different and unique"?
It does not, but it says: "Usually recording a commit that has the
exact same tree as its sole parent commit is a mistake, and the
command prevents you from making such a commit.", followed by "This
option bypasses the safety ..." leadin
Hi Matthiew,
>
> You don't understand what an orphan branch is.
I do not think so. I wanted to create a branch with a commit that has no parent,
and I think that this is called "orphan branch".
I wanted also to have another branch, pointing to a different commit,
the difference
being that this c
Angelo Borsotti writes:
> Hi Matthiew,
>
>>
>> You don't understand what an orphan branch is.
>
> I do not think so. I wanted to create a branch with a commit that has no
> parent,
> and I think that this is called "orphan branch".
Yes, and this is what you did.
> I wanted also to have another
On Wed, Oct 3, 2012 at 7:25 AM, Angelo Borsotti
wrote:
> Hi Phil,
>
>> Perhaps the confusion arises from the the meaning of "the safety". In
>> this case, the safety mechanism in place is to prevent you from
>> creating a child commit which has the same "tree" contents (working
>> directory) as t
Angelo Borsotti writes:
> it does not state plainly that no commit object is created.
But the commit object _is_ created, it just doesn't have a unique name.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for
HI PJ,
take a git commit without --allow-empty: if the trees are equal, it
creates no commit,
and if the trees are different it creates one.
Take then a git commit --allow-empty: if the trees are equal it may
create a commit or
not depending on the parent, message, author and date; if the trees
ar
Hi Andreas,
> But the commit object _is_ created, it just doesn't have a unique name.
The command may internally create the commit object, compute its sha and then
seeing that there is already one in the repo with the same sha, throw it away.
But this is an implementation detail. The net result f
Angelo Borsotti writes:
> that after the command there are no new objects.
That is an uninteresting implementation detail.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
Angelo Borsotti writes:
> Take then a git commit --allow-empty: if the trees are equal it may
> create a commit or not depending on the parent, message, author and
> date; if the trees are different it creates a commit.
The commit is _always_ created, with a name depending on the parent,
message
Hi Andreas,
as a user, and owner of a repository I do care about the objects that are in it.
I do not care about the way they are names, be it numbers or sha's, but for
sure about their existence.
So, for me it is important if a command creates a new commit or not.
> The commit is _always_ create
On Wed, Oct 3, 2012 at 10:34 AM, Angelo Borsotti
wrote:
> HI PJ,
>
> take a git commit without --allow-empty: if the trees are equal, it
> creates no commit,
> and if the trees are different it creates one.
> Take then a git commit --allow-empty: if the trees are equal it may
> create a commit or
Angelo Borsotti writes:
> as a user, and owner of a repository I do care about the objects that are in
> it.
There is no need to care.
> I do not understand this: I have produced several examples that show that
> it is not created, i.e. that the very same objects are present in the
> reposito
Johannes Sixt writes:
> Why don't you use a different commit message to ensure that there is a
> difference between the commits?
That sounds like a workaround, and unnecessary one at that, as it is
entirely unclear why there _needs_ to be a different commit.
Perhaps OP fears that the orphan bra
From: "Angelo Borsotti"
Sent: Wednesday, October 03, 2012 12:52 PM
Hi
You still didn't tell us where the problem was.
I've split up the explanation of your problem you have seen, to see if I
can understand where the 'missing' aspect is within the extended
dicussions.
I thought I did,
Hi Philip and all,
let me explain in full what is the problem that I tried to solve, and
how along the way I stumbled in something that seems to me a git bug
(at least a documentation one).
There is an R&D team developing software using a workflow that is
similar to the integerator-manager one (t
On Thu, Oct 4, 2012 at 3:07 AM, Angelo Borsotti
wrote:
...
> The operation that caused problems was nr. 4. In all the cases
> enlisted above, a git commit creates a brand new and unique commit
> because either it has a parent that is different from that of any
> other commit, or because its tree i
Hi Phil,
\>
> And why is this a problem?
>
> Is there a process or person watching the server for a new commit?
>
> Is it not enough to notice that the pushed-to branch has a new HEAD?
>
Yes, the developers use the git gui to see the graph of branches and commits.
The simpler and uniform it is, t
Hi Philip,
> This has the developers having a full copy/history of the integrators
> relevant branches, so that when the pull of the developers branch occurs
> there is a proper link to the integrators history.
True.
>
> There are other ways to create a branch which has all the developers feature
From: "Angelo Borsotti"
Sent: Thursday, October 04, 2012 8:07 AM
Hi Philip and all,
let me explain in full what is the problem that I tried to solve, and
how along the way I stumbled in something that seems to me a git bug
(at least a documentation one).
There is an R&D team developing softwar
From: "Angelo Borsotti"
Sent: Thursday, October 04, 2012 11:09 PM
A reasonable solution. You can also create a sentinel (--root) commit
for
any time that you need to create the source branch, just so it (the
real
source code commit) has a different parent when on source branch to
that on
the b
Hi Phil,
>
> Another technique could be to simply switch to the sources branch, and then
> use a 'git clean -x' with an updated .gitignore ('reset' the file from the
> source branch)[or use the exclude file] to remove those now ignored
> binaries, before doing the commit.
>
Actually, the first ti
Angelo Borsotti gmail.com> writes:
> take a git commit without --allow-empty: if the trees are equal, it
> creates no commit,
> and if the trees are different it creates one.
> Take then a git commit --allow-empty: if the trees are equal it may
> create a commit or
> not depending on the parent, m
51 matches
Mail list logo
