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
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
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 you
This patch updates the Swedish translation for gitk. To avoid the
UTF-8 encoding of the file to be mangled by my email software, the
patch is attached gzip'ed.
--
\\// Peter - http://www.softwolves.pp.se/
0001-gitk-Update-Swedish-translation-296t.patch.gz
Description: Binary data
Junio C Hamano:
I do not think there is any issue with conflicting patch or merge
caused by applying this to maint, but I CC'ed Jiang to let him know
what is going on.
You might get a conflict in the header (in the PO-Revision-Date
line). The fixed message itself is already in the 1.8.0.rc0
From: Angelo Borsotti angelo.borso...@gmail.com
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.
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,
Junio C Hamano gits...@pobox.com writes:
I'll queue this instead. Thanks.
Even better, perfect!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
Many thanks to all who have responded to my question.
I have found that something is, indeed, modifying the inodes for all
the files in my repository. Our systems administrator executes a
backup using tar with the --atime-preserve flag. It is this flag
that modifies the changed time in the inode,
Angelo Borsotti angelo.borso...@gmail.com 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'
On Tue, Oct 2, 2012 at 10:09 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
David Glasser wrote:
Is the newish push.default documented in the git push manpage
anywhere? I don't see it mentioned (and there are several references
to the default behavior), but maybe I'm missing something. Is
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.
On Wed, Oct 3, 2012 at 3:17 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Hi Duy,
Nguyen Thai Ngoc Duy wrote:
Your patch is fine. I'm just thinking whether it's a good idea to add
a section in the end of each command's man page to list all relevant
config keys to that command, somewhat
Junio C Hamano gitster at pobox.com writes:
Jeremy Morton admin at game-point.net writes:
I've noticed that the p4merge shell script could do with some
improvement when it comes to merging. Because p4merge throws up an
error when one of the files it's given to diff is /dev/null, git
Angelo Borsotti angelo.borso...@gmail.com 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
On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
On second thought, it might not be such a good idea. There are *lots*
of variables that control the operation of each command, and it's hard
to decide which ones to list and which ones to omit. I've listed all
the
Angelo Borsotti angelo.borso...@gmail.com 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.
On Tue, Oct 2, 2012 at 3:24 PM, Ramkumar Ramachandra artag...@gmail.com wrote:
Stefano Lattarini wrote:
On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
Hi,
I've often found the '**' (extended) shell glob useful for matching
any string crossing directory boundaries: it's especially useful
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, Oct 3, 2012 at 4:04 AM, Scott Batchelor
scott.batche...@gmail.com wrote:
Many thanks to all who have responded to my question.
I have found that something is, indeed, modifying the inodes for all
the files in my repository. Our systems administrator executes a
backup using tar with the
Nguyen Thai Ngoc Duy:
I'm just thinking whether it's a good idea to add a section in the
end of each command's man page to list all relevant config keys to
that command, somewhat similar to see also section.
Yes, please. Discoverability of configuration settings is not very
good at the
On Wed, 03 Oct 2012 10:24:00 +0200, Angelo Borsotti angelo.borso...@gmail.com
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
Am 30.09.2012 22:44 schrieb David Aguilar:
On Sun, Sep 30, 2012 at 8:32 AM, Dirk Süsserott newslet...@dirk.my1.cc
wrote:
Am 30.09.2012 17:24 schrieb Tomas Carnecky:
On Sun, 30 Sep 2012 17:17:53 +0200, Dirk SÃŒsserott
newslet...@dirk.my1.cc wrote:
Hi!
I have repo1 with ~4 years of history
On Tue, Oct 2, 2012 at 3:34 PM, Angelo Borsotti
angelo.borso...@gmail.com 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
On Wed, Oct 3, 2012 at 7:36 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
I'm creating a system where a lot of remotes constantly fetch from a
central repository for deployment purposes, but I've noticed that even
with a remote.$name.fetch configuration to only get certain refs a
git
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.
Am 03.10.2012 13:35, schrieb Nguyen Thai Ngoc Duy:
On Tue, Oct 2, 2012 at 3:24 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
Stefano Lattarini wrote:
On 10/02/2012 09:21 AM, Ramkumar Ramachandra wrote:
Hi,
I've often found the '**' (extended) shell glob useful for matching
any string
On Wed, Oct 3, 2012 at 8:35 PM, Jens Lehmann jens.lehm...@web.de wrote:
*/foo/bar
*/*/foo/bar
*/*/*/foo/bar
Using **/foo/bar instead would be a great improvement
If this **/foo/bar (i.e. no wildcards except one ** at the
beginning) is popular, we could optimize this case, turning fmatch()
Angelo Borsotti angelo.borso...@gmail.com 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
Am 02.10.2012 21:44, schrieb Jens Lehmann:
Am 02.10.2012 18:51, schrieb Ramkumar Ramachandra:
Introduce a diff.submoduleFormat configuration variable corresponding
to the '--submodule' command-line option of 'git diff'.
Nice. Maybe a better name would be diff.submodule, as this sets the
Angelo Borsotti angelo.borso...@gmail.com 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
On Wed, Oct 3, 2012 at 9:35 AM, Angelo Borsotti
angelo.borso...@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.
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
Suppose this case:
git clone .../blessedRepo.git
// do changes
git commit -mbad1
// do changes
git commit -mbad2
git reset --hard HEAD^4 // Why does it let me do this?
// I just broke my local repository, because if I continue
// do changes
git commit -mgood1
git push origin master // fails
Angelo Borsotti angelo.borso...@gmail.com 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
Op 03-10-12 16:59, Ramkumar Ramachandra schreef:
Hi Geoffrey,
Geoffrey De Smet wrote:
[...]
The following commands are ok to do (because I have 2 unpushed commits):
git reset --hard^1
git reset --hard^2
but these are not and should be prevented (unless forced):
git reset --hard^3
git
On Wed, Oct 3, 2012 at 10:49 AM, Geoffrey De Smet
ge0ffrey.s...@gmail.com wrote:
Suppose this case:
git clone .../blessedRepo.git
// do changes
git commit -mbad1
// do changes
git commit -mbad2
git reset --hard HEAD^4 // Why does it let me do this?
// I just broke my local repository,
Angelo Borsotti angelo.borso...@gmail.com 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
Geoffrey De Smet ge0ffrey.s...@gmail.com writes:
Suppose this case:
git clone .../blessedRepo.git
// do changes
git commit -mbad1
// do changes
git commit -mbad2
git reset --hard HEAD^4 // Why does it let me do this?
Because there is nothing wrong with that.
// I just broke my local
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
On Wed, Oct 03, 2012 at 02:36:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
I'm creating a system where a lot of remotes constantly fetch from a
central repository for deployment purposes, but I've noticed that even
with a remote.$name.fetch configuration to only get certain refs a
git fetch
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
There's an interesting case: **foo. According to our rules, that
pattern does not contain slashes therefore is basename match. But some
might find that confusing because ** can match slashes,...
By our rules, if you mean if a pattern has slash,
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
On second thought, it might not be such a good idea. There are *lots*
of variables that control the operation of each command, and it's hard
to decide which ones to
Phil Hord phil.h...@gmail.com writes:
I flagged this for followup in my MUA, but I failed to follow-up after
the holidays. I apologize for that, and I really regret it because I
liked where this was going.
I really regret to see you remembered it, actually.
1) Newbie user clones/pulls a
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra artag...@gmail.com
wrote:
On second thought, it might not be such a good idea. There are *lots*
of variables that control the operation of each command, and it's hard
to decide which ones to
Jeff King p...@peff.net writes:
Has there been any work on extending the protocol so that the client
tells the server what refs it's interested in?
I don't think so. It would be hard to do in a backwards-compatible way,
because the advertisement is the first thing the server says, before it
On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Has there been any work on extending the protocol so that the client
tells the server what refs it's interested in?
I don't think so. It would be hard to do in a backwards-compatible way,
Junio C Hamano gits...@pobox.com writes:
Phil Hord phil.h...@gmail.com writes:
I flagged this for followup in my MUA, but I failed to follow-up after
the holidays. I apologize for that, and I really regret it because I
liked where this was going.
I really regret to see you remembered it,
Angelo Borsotti angelo.borso...@gmail.com 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
Angelo Borsotti angelo.borso...@gmail.com 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
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_
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
I'm creating a system where a lot of remotes constantly fetch from a
central repository for deployment purposes, but I've noticed that even
with a remote.$name.fetch configuration to only get certain refs a
git fetch will still call git-upload
On 03.10.12 00:21, Junio C Hamano wrote:
I think this should suffice.
[snip]
- test_must_fail git fsck --tags 2out
- cat out
- grep error in tag.*broken links out
+ test_must_fail git fsck --tags
[snip]
Thanks, and all TC passed in pu.
/Torsten
--
To unsubscribe from
On Wed, Oct 3, 2012 at 11:55 AM, Jeff King p...@peff.net wrote:
On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Has there been any work on extending the protocol so that the client
tells the server what refs it's interested in?
I don't
On Wed, Oct 3, 2012 at 10:34 AM, Angelo Borsotti
angelo.borso...@gmail.com 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
On Wed, Oct 03, 2012 at 12:41:38PM -0700, Shawn O. Pearce wrote:
Out of curiosity, how are you thinking about triggering such a new
behavior in a backwards-compatible way? Invoke git-upload-pack2, and
fall back to reconnecting to start git-upload-pack if it fails?
Basically, yes. New
On Wed, Oct 3, 2012 at 8:03 PM, Jeff King p...@peff.net wrote:
On Wed, Oct 03, 2012 at 02:36:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
I'm creating a system where a lot of remotes constantly fetch from a
central repository for deployment purposes, but I've noticed that even
with a
Junio C Hamano gits...@pobox.com writes:
* git grep learned to use a non-standard pattern type by default if
a configuration variable tells it to.
This addition makes
git grep -e (integer|buffer)
work as expected, when grep.patternType is set to extended.
Should this
git log
Angelo Borsotti angelo.borso...@gmail.com 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
Johannes Sixt j.s...@viscovery.net 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
On Wed, Oct 03, 2012 at 10:16:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
I can't provide all the details now (not with access to that machine
now), but briefly:
* The git client/server version is 1.7.8
* The repository has around 50k refs, they're real refs, almost all
of them (say
On Wed, Oct 03, 2012 at 11:26:55AM -0700, Junio C Hamano wrote:
Please do not label the list as These variables affect this
command to give a false impression that it is the complete list if
it isn't.
Unless somebody promises to keep an up-to-date complete list there
(or even better, come
On 10/03/2012 03:47 PM, Alexander Kostikov wrote:
Expected behaviour:
- restore branch to pre-rebase location on out of memory exception
- not to fall with out of memory in the first place. But for our
repository that could be fixed only after either:
--- a) msysgit would have x64 binary
On Mon, Oct 01, 2012 at 08:13:21PM -0500, Matt McClellan wrote:
We had an issue at our organization where changes were reverted when a
user was merging his local repo with the remote repo changes. The
merge conflicted and he unstaged all the changes that were not a
conflict, he then resolved
The introduction email (--compose option) use UTF-8 as default encoding.
The current locale encoding is much better default value.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
git-send-email.perl | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
The introduction email (--compose option) have encoding hardcoded to
UTF-8, but invoked editor may not use UTF-8 encoding.
The encoding used by patches can be changed by the 8bit-encoding
option, but this option does not have effect on introduction email
and equivalent for introduction email is
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
* git grep learned to use a non-standard pattern type by default if
a configuration variable tells it to.
This addition makes
git grep -e (integer|buffer)
work as expected, when grep.patternType is
On Wed, Oct 3, 2012 at 11:20 PM, Jeff King p...@peff.net wrote:
Thanks for all that info, it's really useful.
* A co-worker who was working on this today tried it on 1.7.12 and
claimed that it had the same performance characteristics.
That's surprising to me. Can you try to verify those
From: Angelo Borsotti angelo.borso...@gmail.com
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
On Wed, Oct 3, 2012 at 8:03 PM, Jeff King p...@peff.net wrote:
What version of git are you using? In the past year or so, I've made
several tweaks to speed up large numbers of refs, including:
- cff38a5 (receive-pack: eliminate duplicate .have refs, v1.7.6); note
that this only helps
On Thu, Oct 04, 2012 at 12:15:47AM +0200, Ævar Arnfjörð Bjarmason wrote:
I think he was wrong, I tested this on git.git by first creating a lot
of tags:
parallel --eta git tag -a -m{} test-again-{} ::: $(git rev-list HEAD)
Then doing:
git pack-refs --all
git repack -A -d
On Thu, Oct 04, 2012 at 12:32:35AM +0200, Ævar Arnfjörð Bjarmason wrote:
On Wed, Oct 3, 2012 at 8:03 PM, Jeff King p...@peff.net wrote:
What version of git are you using? In the past year or so, I've made
several tweaks to speed up large numbers of refs, including:
- cff38a5
On Thu, Oct 4, 2012 at 1:21 AM, Jeff King p...@peff.net wrote:
On Thu, Oct 04, 2012 at 12:32:35AM +0200, Ævar Arnfjörð Bjarmason wrote:
On Wed, Oct 3, 2012 at 8:03 PM, Jeff King p...@peff.net wrote:
What version of git are you using? In the past year or so, I've made
several tweaks to
On Thu, Oct 4, 2012 at 1:15 AM, Jeff King p...@peff.net wrote:
On Thu, Oct 04, 2012 at 12:15:47AM +0200, Ævar Arnfjörð Bjarmason wrote:
I think he was wrong, I tested this on git.git by first creating a lot
of tags:
parallel --eta git tag -a -m{} test-again-{} ::: $(git rev-list
HEAD)
Over time we have added a few things to our git grep front-end,
such as
- grep.extendedregexp configuration (v1.7.5)
- use of pcre (v1.7.6)
- grep.patterntype configuration (v1.8.0)
But all the time, we forgot that git log --grep would need to
honor them.
The first three patches should be
When we added the --perl-regexp option (or -P) to git grep, we
should have done the same for the commands in the git log family,
but somehow we forgot to do so. This corrects it.
Also introduce the --basic-regexp option for completeness, so that
the last one wins principle can be used to defeat
Call init_revisions() first to prepare the revision traversal
parameters and pass it to git_log_config(), so that necessary bits
in the traversal parameters can be tweaked before we call the
command line parsing infrastructure setup_revisions() from
the cmd_log_init_finish() function.
Read grep.extendedregexp, grep.patterntype, etc. from the
configuration so that log --grep='pcre' honors the user
preference without an explicit -P from the command line.
Now that the callback parameter, which was so far unused, to
git_log_config() has to be of type struct rev_info *, stop
On Thu, Oct 4, 2012 at 1:17 AM, Junio C Hamano gits...@pobox.com wrote:
For the double-star at the beginning, you should just turn it into **/
if it is not followed by a slash internally, I think.
What is the semantics of ** in the first place? Is it described to
a reasonable level of detail
Hi all!
I just ran into a problem that I'm pretty sure is a bug in git. Just
read and run this (fairly trivial) shell script to replicate.
Thanks!
---John Whitney
git_failure.sh
Description: Bourne shell script
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano gits...@pobox.com wrote:
I would recommend against listing any advice.* in the command manual
pages. They are meant to give an advice in cases that are often
confusing to new people and are supposed
85 matches
Mail list logo
