On Wed, Oct 3, 2012 at 1:34 AM, Jeremy Morton wrote:
> Junio C Hamano pobox.com> writes:
>
>>
>> Jeremy Morton 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 on
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Junio C Hamano 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
Nguyen Thai Ngoc Duy writes:
>> I am guessing that the only sensible definition is that "**"
>> requires anything that comes before it (if exists) is at a proper
>> hierarchy boundary, and anything matches it is also at a proper
>> hierarchy boundary, so "x**y" matches "x/a/y"
>
> and "x/y" too?
Nguyen Thai Ngoc Duy writes:
> On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano 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 to advise how to turn it
>>
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
On Thu, Oct 4, 2012 at 1:17 AM, Junio C Hamano 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 in the doc
Read grep.extendedregexp, grep.patterntype, etc. from the
configuration so that "log --grep=''" 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 passing
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.
Signed-off-b
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
The command line option parser for "git log -F -E --grep=''"
did not flip the "fixed" bit, violating the general "last option
wins" principle among conflicting options.
Signed-off-by: Junio C Hamano
---
revision.c | 4 ++--
t/t4202-log.sh | 6 ++
2 files changed, 8 insertions(+), 2 delet
Switching between -E/-G/-P/-F correctly needs a lot more than just
flipping opt->regflags bit these days, and we have a nice helper
function buried in builtin/grep.c for the sole use of "git grep".
Extract it so that "log --grep" family can also use it.
Signed-off-by: Junio C Hamano
---
builtin
As "git grep" will not stay to be the only command that will know
about the grep machinery, move these to a more appropriate place.
Signed-off-by: Junio C Hamano
---
builtin/grep.c | 67 --
grep.c | 67 ++
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
On Thu, Oct 4, 2012 at 1:15 AM, Jeff King 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
>> HEA
On Thu, Oct 4, 2012 at 1:21 AM, Jeff King 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 wrote:
>> > What version of git are you using? In the past year or so, I've made
>> > several tweaks to speed up large number
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 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:
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 r
On Wed, Oct 3, 2012 at 8:03 PM, Jeff King 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 if they ar
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,
On Wed, Oct 3, 2012 at 11:20 PM, Jeff King 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 numbers?
Junio C Hamano writes:
> Junio C Hamano 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".
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 m
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
---
git-send-email.perl | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-sen
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 resol
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 (current
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
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 th
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
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
Junio C Hamano 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 --grep="(int
On Wed, Oct 3, 2012 at 8:03 PM, Jeff King 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 remote.$name.fet
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.
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
On Wed, Oct 3, 2012 at 11:55 AM, Jeff King wrote:
> On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote:
>> Jeff King 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. I
On 03.10.12 00:21, Junio C Hamano wrote:
> I think this should suffice.
> [snip]
> - test_must_fail git fsck --tags 2>out &&
> - 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 unsubsc
Ævar Arnfjörð Bjarmason 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 pack which
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
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
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."
-
Junio C Hamano writes:
> Phil Hord 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.
Having said that,
On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote:
> Jeff King 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,
> >
Jeff King 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
> has n
Nguyen Thai Ngoc Duy writes:
> On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra
> 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
Phil Hord 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 repository from so
Nguyen Thai Ngoc Duy writes:
> On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra
> 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
Nguyen Thai Ngoc Duy 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, it is anc
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
- Original Message -
From: Nguyen Thai Ngoc Duy
Date: 10/3/2012 7:42 AM
On Wed, Oct 3, 2012 at 8:35 PM, Jens Lehmann 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
beginnin
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
Geoffrey De Smet writes:
> Suppose this case:
>
> git clone .../blessedRepo.git
> // do changes
> git commit -m"bad1"
> // do changes
> git commit -m"bad2"
> git reset --hard HEAD^4 // Why does it let me do this?
Because there is nothing wrong with that.
> // I just "broke" my local repository,
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
On Wed, Oct 3, 2012 at 10:49 AM, Geoffrey De Smet
wrote:
> Suppose this case:
>
> git clone .../blessedRepo.git
> // do changes
> git commit -m"bad1"
> // do changes
> git commit -m"bad2"
> git reset --hard HEAD^4 // Why does it let me do this?
>
> // I just "broke" my local repository, because if
On Tue, Dec 6, 2011 at 2:34 AM, Philippe Vaucher
wrote:
>> Think about why you need to use git-reset. Why do new users need to
>> use git-reset? What is it they are after?
>
> Ok, so let's forget about git reset and let's focus on the features
> instead. If I got it right you suggested the featu
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
Thanks a lot for trying this.
My hashes match. I just re-reproduced it on two flavors of Linux (64
and 32-bit), with two different Git versions (see below). What
platform are you using?
lesha@buryonka-ubuntu32:~$ mkdir GIT-AM-CRASH
lesha@buryonka-ubuntu32:~$ cd GIT-AM-CRASH
lesha@buryonka-ubuntu
On Wed, Oct 3, 2012 at 6:20 AM, Junio C Hamano wrote:
> * nd/wildmatch (2012-09-27) 5 commits
> - Support "**" in .gitignore and .gitattributes patterns using wildmatch()
> - Integrate wildmatch to git
> - compat/wildmatch: fix case-insensitive matching
> - compat/wildmatch: remove static vari
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 r
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 reset --hard^4
>
>
> Is there any way to mak
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
Suppose this case:
git clone .../blessedRepo.git
// do changes
git commit -m"bad1"
// do changes
git commit -m"bad2"
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 -m"good1"
git push origin master // f
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
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
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
Am 03.10.2012 15:42, schrieb Nguyen Thai Ngoc Duy:
> On Wed, Oct 3, 2012 at 8:35 PM, Jens Lehmann 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 popu
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
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
On Wed, Oct 3, 2012 at 8:35 PM, Jens Lehmann 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()
into strncmp(
Am 03.10.2012 13:35, schrieb Nguyen Thai Ngoc Duy:
> On Tue, Oct 2, 2012 at 3:24 PM, Ramkumar Ramachandra
> 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 st
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
On Wed, Oct 3, 2012 at 7:36 PM, Æ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" will sti
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
Am 30.09.2012 22:44 schrieb David Aguilar:
> On Sun, Sep 30, 2012 at 8:32 AM, Dirk Süsserott
> wrote:
>> Am 30.09.2012 17:24 schrieb Tomas Carnecky:
>>> On Sun, 30 Sep 2012 17:17:53 +0200, Dirk SÃŒsserott
>>> wrote:
Hi!
I have repo1 with ~4 years of history and another repo2 with
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
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 mom
On Wed, Oct 3, 2012 at 4:04 AM, Scott Batchelor
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 "--atime-preserve"
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 Tue, Oct 2, 2012 at 3:24 PM, Ramkumar Ramachandra 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 if
On Tue, Oct 2, 2012 at 1:33 AM, Alexey Spiridonov wrote:
> This reproduces in trunk, 1.7.8.4, and 1.7.9.5.
fwiw, I cannot reproduce it (git-apply does not crash). I tried both
versions and 1.8.0-rc1. Just in case the attached files are somehow
corrupted, this is sha1sum from my side:
3d4711cd15d
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
On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra 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 relevant varia
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
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>> [...]
>> --8<--
>
> FYI: the above is not a scissors line.
Excerpt from git-mailinfo[1]:
--scissors::
Remove everything in body before a scissors line. A line that
mainly consists of scissors (either ">8" or "8<") and perfo
[+CC: Junio, for comments]
Nguyen Thai Ngoc Duy wrote:
> On Wed, Oct 3, 2012 at 3:17 PM, Ramkumar Ramachandra
> 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 lis
Junio C Hamano pobox.com> writes:
>
> Jeremy Morton 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
> > nee
On Wed, Oct 3, 2012 at 3:17 PM, Ramkumar Ramachandra 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 similar to
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
On Tue, Oct 2, 2012 at 10:09 PM, Ramkumar Ramachandra
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 it
>> le
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
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 in
Junio C Hamano 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 http://vger.kernel.o
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
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
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.rc
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
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
100 matches
Mail list logo
