with git bash (even if bash could access them using what is
passed to it, which is a drive letter, and not the drive name).
Thank you
-Angelo
On 23 November 2012 16:31, Heiko Voigt hvo...@hvoigt.net wrote:
Hi,
On Thu, Nov 22, 2012 at 08:07:55AM +0100, Angelo Borsotti wrote:
I have attached
when the HEAD is not set ...).
-Angelo
On 14 November 2012 14:57, Junio C Hamano gits...@pobox.com wrote:
Angelo Borsotti angelo.borso...@gmail.com writes:
currently, there is no means to push a branch description to a remote
repository. It is possible to create a branch, but not to set its
Hi Junio,
actually, I proposed to add a key in config files, e.g.
pushTagsNoChange to be set in the remote repo do disallow changes to
tags, similar to pushNonFastForward that disallows non-fastforward
changes to branches. I still have the impression that this is simple
and clear, and allows the
be appropriate to
extent this a bit.
-Angelo
On 14 November 2012 18:32, Junio C Hamano gits...@pobox.com wrote:
Angelo Borsotti angelo.borso...@gmail.com writes:
actually, I proposed to add a key in config files, e.g.
pushTagsNoChange to be set in the remote repo do disallow changes to
tags
Hi Junio,
I am *not* convinced that the refs/tags/ is the only special
hierarchy whose contents should not move is a bad limitation we
should avoid, but if it indeed is a bad limitation, the above is one
possible way to think about avoiding it.
What other hierarchy besides branches and tags
Hi,
Pro Git, By Scott Chacon says:
2.6
Like most VCSs, Git has the ability to tag specific points in
history as being important.
Generally, people use this functionality to mark release points (v1.0,
and so on).
2.6.2:
A [lightweight] tag is very much like a branch that does not change
Hi Drew,
sure. That is a good starting point. I would suggest to block tag
updates of existing tags if a dedicated option is present in the
config of the remote repo, like, e.g. pushOverwriteTags.
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Jeff,
Then on top of that we can talk about what lightweight tags should do.
I'm not sure.
If tags (even the lightweight ones) do not behave differently from
branches, then they are of no use, and the main difference is that
they do not move. So, I would suggest not to move them either.
Hi Ben
This still wouldn't be an error condition though, especially in terms
of how git config should treat it.
The man page says:
This command will fail with non-zero status upon error.
Of course, one might claim that this does not mean the truth of the
reverse condition, i.e. that when
Hi Andreas,
Is grep not finding a match an error? Is cmp finding a difference an
error? It all depends on the context.
Manpage of grep, exit staus:
Normally, the exit status is 0 if selected lines are found and 1
otherwise. But the exit status is 2 if an error occurred, ...
cmp uses
Hi Drew,
Changing the tag in the local repository is a tag modification
operation. Pushing that change to a remote repository DOES NOT execute
git tag in the remote. Plain and simple the two are different
operations.
They are different for what concerns the implementation. They are not
Hi Drew,
git is an open source, community project, which means that it benefits
from all the contributions of many people, and they are not restricted
to patches.
If the only one suggestions that were taken into account were patches
sent by people that had the time to study the sources and
Hello
Drew,
I made some further tests on git-push to see if it handled branches
and tags in the same way, and have discovered the following
differences:
- git push origin --delete master
remote: error: By default, deleting the current branch is denied
- git push origin --delete
Hi Drew,
You specified -f (force) and it did exactly what you asked. That is
fully documented (git help tag).
Yes, it is, and I used it to show that there is a need to specify
explicitly the intent to change a tag, that without such an indication
would not be changed.
Tags have many uses.
Hi Jeff,
it would be worth to put your description as comments in the code for future
reference.
Thanks
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew,
one nice thing is to warn a developer that wants to modify a source
file, that there is somebody else changing it beforehand. It is nicer
than discovering that at push time.
Take into account that there are changes in files that may be
incompatible to each other, or that can be
Hi Marc,
correct, there will be no file overwriting because no files are
written on the work tree.
I tried to follow the actions of the program, but did not quite catch
the 6. you mention.
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Junio,
giving the user a better error message is certainly an improvement.
But would not be another improvement to describe better the command syntax
so as to help the user write the command right in the first place?
After all, what is the syntax section in commands for?
If I had seen in the
Hi Junio
It is not difficult. The discussion on this list is usually done
via patches, and without one, constant talking is buried in other
noise and often go unnoticed.
Could you accept for very small changes also the simple indication of
the change itself instead of a patch?
There is
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 RD team developing software using a workflow that is
similar to the integerator-manager one
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, the
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
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 time I
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 --orphan
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 page of
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,
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 documented.
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
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,
B.
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 has
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 ... leading to
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
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
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_
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
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
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 is
I have removed the Italian localization so as to make git gui use the
English one.
The result is the same as I have found before.
The message is: Not a Git repository: remote.git.
Thus, the misleading message is there.
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
Hi Ben,
I am running git gui on Windows 7. Are you running it on Linux?
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Ben,
I run the same test on Linux, and have got the same results as you did.
So the problem is only on Windows.
-Angelo
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi all,
consider this example:
$ mkdir gittest
$ cd gittest
$ git init
Initialized empty Git repository in d:/gittest/.git/
$ touch f1
$ git add f1
$ git commit commit -m first commit
[master (root-commit) e6f935e] first commit
0 files changed
create mode 100644 f1
$ touch f2
$ git checkout
Hi,
figuring out what the behavior is by guessing how a command is implemented and
what are its interactions with the shell is a bit hard for the user:
s/he should instead
get it from the documentation.
I tried to figure it out from the examples I have done, and as you
see, I did not get it
quite
43 matches
Mail list logo
