y are a problem
also 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 wrote:
> Hi,
>
> On Thu, Nov 22, 2012 at 08:07:55AM +0100, Angelo Borsotti wrote:
&
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
ght it could be appropriate to
extent this a bit.
-Angelo
On 14 November 2012 18:32, Junio C Hamano wrote:
> Angelo Borsotti 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,
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 o
ate a branch in a
bare repository when the HEAD is not set ...).
-Angelo
On 14 November 2012 14:57, Junio C Hamano wrote:
> Angelo Borsotti 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 s
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.
-Ang
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 t
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 chang
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 u
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
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 vx
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 propose
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
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 u
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 amenable
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.htm
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 majord
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 i
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 synta
Hi Andreas,
>
> -b requires an argument , which you specify as --no-track
> here. is topic, and the rest is interpreted as .
>
The man page describes --track and --no-track as "options". This is why a
reader thinks that they can be specified in any order.
It is also very counter-intuitive to thi
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
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,
\>
> 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 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
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
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
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 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
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 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 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,
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 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 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
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
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
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
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
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
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 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 http://vger.kernel.org/majordo
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
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,
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
Hi Duy,
the semantics of "git checkout -- '*'" is quite clear because there is
no expansion done by the shell. The wildcard is passed to git checkout,
that interprets is properly.
That of "git checkout -- *" is the problem when the directory is empty.
Note that this happens with the shell that is
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 e
46 matches
Mail list logo
