* Re: core.whitespace space-in-indent feature request
From: Junio C Hamano @ 2011-01-18 20:31 UTC (permalink / raw)
To: Drew Northup; +Cc: Victor Engmark, git
In-Reply-To: <1295380297.3778.47.camel@drew-northup.unet.maine.edu>
Drew Northup <drew.northup@maine.edu> writes:
> On Fri, 2011-01-14 at 13:40 +0100, Victor Engmark wrote:
>> Hi all,
>>
>> I couldn't find this mentioned anywhere, but it would be useful for
>> languages where you typically want only tab characters in indentation,
>> like makefiles. Would be equivalent or similar to indent-with-non-tab
>> and tabwidth=1.
>
> Victor,
> What would the point of this be? Git doesn't change the layout of the
> code when storing it--that's up to the thing between the chair and the
> keyboard.
True, but I think Victor wants to be able to ask "diff --check" to
complain and diff --color to highlight when it sees a line that begins
with a SP (or a HT then SP) by setting:
* whitespace=space-in-indent
or something in the attributes file.
As "equivalence" exists, not very much interested in coding it myself,
though ;-)
^ permalink raw reply
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Thomas Rast @ 2011-01-18 20:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Sebastian Hahn
In-Reply-To: <20110118185027.GA10562@sigill.intra.peff.net>
Jeff King wrote:
> commit() {
> echo $1 >file && git add file && git commit -m $1
> }
> mkdir repo && cd repo && git init
> commit base
> commit master
> git checkout -b other HEAD^
> commit other
> git merge master
> commit resolved
Indeed, my history looks just like that.
> > git log -Squux -c -p # shows merge, but no diff
>
> Weird. Here I get a nice combined diff, which is what I expect.
True, I managed to confuse myself between looking for the resolution and
looking for one of the (deleted) merge sides.
So indeed
git log -Squux -c -p
gives a combined diff. But OTOH
git log -Sbar -c -p
doesn't; it only gives a diff for the commit that introduced 'bar'. I
guess this makes sense: -S notices that the number of 'bar's is
actually the same as in *one* merge parent, hence the merge cannot be
all that interesting. OTOH it still shows the merge commit in the
history, which is a bit strange. --pickaxe-all does not make a
difference either;
git log -Sbar --cc -p --pickaxe-all
still shows the merge commit but no diff.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Jeff King @ 2011-01-18 20:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Sebastian Hahn
In-Reply-To: <201101182139.28808.trast@student.ethz.ch>
On Tue, Jan 18, 2011 at 09:39:28PM +0100, Thomas Rast wrote:
> So indeed
>
> git log -Squux -c -p
>
> gives a combined diff. But OTOH
>
> git log -Sbar -c -p
>
> doesn't; it only gives a diff for the commit that introduced 'bar'. I
> guess this makes sense: -S notices that the number of 'bar's is
> actually the same as in *one* merge parent, hence the merge cannot be
> all that interesting. OTOH it still shows the merge commit in the
> history, which is a bit strange. --pickaxe-all does not make a
> difference either;
Hrm. What I expected[1] to happen would be for the diff machinery to
look at each filepair individually, one of them to trigger -S, which
shows the commit, and then to fail to produce a combined diff because we
threw away the other uninteresting filepair. But in that case,
--pickaxe-all _should_ show something, as its point is to keep all of
the filepairs. And that's clearly not happening.
So now I don't know what's going on. I'll try to trace through the diff
machinery and see if that gives a clue.
-Peff
[1] That's what I expect, but not necessarily what I want. I think what
I would want is for it to do a token count of the merge commit, and if
it fails to match _every_ parent, then it it interesting. Otherwise, the
content presumably came from that parent.
^ permalink raw reply
* Re: [PATCH] gitk: Take only numeric version components when computing $git_version
From: Paul Mackerras @ 2011-01-18 10:47 UTC (permalink / raw)
To: Mathias Lafeldt; +Cc: Jonathan Nieder, Anders Kaseorg, Junio C Hamano, git
In-Reply-To: <4D355966.7090707@debugon.org>
On Tue, Jan 18, 2011 at 10:12:06AM +0100, Mathias Lafeldt wrote:
> Jonathan Nieder wrote:
> > [...]
> > So after building from a tarball generated with "git archive", "git version"
> > produces v1.7.4-rc1, producing errors from gitk, but after building
> > from the git repo or a tarball generated with "make dist", the version
> > is v1.7.4.rc1 (which gitk accepts).
> >
> > Anders's fix looks good to me for robustness reasons anyway, so
> >
> > Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
> >
>
> OK then. Junio? :)
I'll pick it up.
Paul.
^ permalink raw reply
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Thomas Rast @ 2011-01-18 21:16 UTC (permalink / raw)
To: Jeff King; +Cc: git, Sebastian Hahn, Junio C Hamano
In-Reply-To: <201101182139.28808.trast@student.ethz.ch>
Thomas Rast wrote:
> So indeed
>
> git log -Squux -c -p
>
> gives a combined diff. But OTOH
>
> git log -Sbar -c -p
>
> doesn't; it only gives a diff for the commit that introduced 'bar'.
It's actually even stranger. -S does not seem to filter merges at
all. For example, in git.git
$ git log | grep -c ^Merge
4677
$ git log -Sthis_string_never_existed_anywhere -c | grep -c ^Merge
4677
I think it should just filter all history, shouldn't it? After all
$ git log -- this_file_never_existed
also comes up empty.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Documentation/fast-import: put explanation of M 040000 <dataref> "" in context
From: Jonathan Nieder @ 2011-01-18 21:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Barr, Git Mailing List, Ramkumar Ramachandra,
Sverre Rabbelier, Gabriel Filion, Johannes Sixt
In-Reply-To: <7v1v4amex6.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> +++ b/Documentation/git-fast-import.txt
>> @@ -545,6 +542,9 @@ The value of `<path>` must be in canonical form. That is it must not:
>> * contain the special component `.` or `..` (e.g. `foo/./bar` and
>> `foo/../bar` are invalid).
>>
>> +In `040000` mode, `<path>` can be the empty string (`""`)
>> +to specify the root of the tree.
>> +
>
> Thanks, but is "In x mode" an appropriate wording here in the first place?
Good point. No, it isn't.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
For squashing.
Documentation/git-fast-import.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 43d2174..7068de3 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -542,7 +542,7 @@ The value of `<path>` must be in canonical form. That is it must not:
* contain the special component `.` or `..` (e.g. `foo/./bar` and
`foo/../bar` are invalid).
-In `040000` mode, `<path>` can be the empty string (`""`)
+If `<mode>` is `040000`, `<path>` can be the empty string (`""`)
to specify the root of the tree.
It is recommended that `<path>` always be encoded using UTF-8.
--
1.7.4.rc2
^ permalink raw reply related
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Junio C Hamano @ 2011-01-18 21:26 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, git, Sebastian Hahn
In-Reply-To: <20110118205040.GA20970@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [1] That's what I expect, but not necessarily what I want. I think what
> I would want is for it to do a token count of the merge commit, and if
> it fails to match _every_ parent, then it it interesting. Otherwise, the
> content presumably came from that parent.
Honestly, my guess is that the interaction of -S with a merge commit is
"whatever the code happens to do", as I didn't think nor design how they
should interact with each other when I wrote -c/--cc nor when I wrote -S.
If I recall correctly -S codepath predates -c/--cc by a wide margin, and I
wouldn't be surprised at all if pickaxe doesn't work as expected (by
anybody's definition of "expectation"), unless you are looking at "-p -m"
output, not a combined one.
Having said that, I tend to agree with your latter expectation ("what I
want").
By the way, you guys should really not be looking at the disused
plumbing-helper -S but instead be advocating its newer and more human
friendly cousin -G. 1.7.4 is coming ;-).
^ permalink raw reply
* Re: [PATCH] gitk: Take only numeric version components when computing $git_version
From: Junio C Hamano @ 2011-01-18 21:26 UTC (permalink / raw)
To: Paul Mackerras
Cc: Mathias Lafeldt, Jonathan Nieder, Anders Kaseorg, Junio C Hamano,
git
In-Reply-To: <20110118104742.GA3279@brick.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
>> OK then. Junio? :)
>
> I'll pick it up.
Thanks.
^ permalink raw reply
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Jeff King @ 2011-01-18 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Sebastian Hahn
In-Reply-To: <7vsjwpkio8.fsf@alter.siamese.dyndns.org>
On Tue, Jan 18, 2011 at 01:26:15PM -0800, Junio C Hamano wrote:
> Honestly, my guess is that the interaction of -S with a merge commit is
> "whatever the code happens to do", as I didn't think nor design how they
> should interact with each other when I wrote -c/--cc nor when I wrote -S.
That's kind of what I figured.
> Having said that, I tend to agree with your latter expectation ("what I
> want").
I'll take a look and see how painful it will be to do that. I'm not even
sure how the merge filepairs are represented by the diff code (since
they are not even pairs, but rather one child with many parents).
> By the way, you guys should really not be looking at the disused
> plumbing-helper -S but instead be advocating its newer and more human
> friendly cousin -G. 1.7.4 is coming ;-).
It's _way_ slower for simple things:
$ time git log -Sfoo >/dev/null
real 0m11.550s
user 0m11.409s
sys 0m0.116s
$ time git log -Gfoo >/dev/null
real 0m25.722s
user 0m25.442s
sys 0m0.220s
I for one really like the -S behavior, anyway, but I expect I am in the
minority.
-Peff
^ permalink raw reply
* [PATCH 1/3] t/t5400-send-pack.sh: use the canonical test_expect_success syntax
From: Ævar Arnfjörð Bjarmason @ 2011-01-18 21:41 UTC (permalink / raw)
To: git; +Cc: gitster, Ævar Arnfjörð Bjarmason
Change t/t5400-send-pack.sh to use the usual test_expect_success
syntax, i.e. change:
test_expect_success \
'description'
To:
test_expect_success 'description'
Like the rest of the tests in t/t5400-send-pack.sh do.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t5400-send-pack.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index b0b2684..656ab1a 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -76,8 +76,7 @@ test_expect_success 'refuse pushing rewound head without --force' '
test "$victim_head" = "$pushed_head"
'
-test_expect_success \
- 'push can be used to delete a ref' '
+test_expect_success 'push can be used to delete a ref' '
( cd victim && git branch extra master ) &&
git send-pack ./victim :extra master &&
( cd victim &&
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] t/t5400-send-pack.sh: add test_when_finished commands
From: Ævar Arnfjörð Bjarmason @ 2011-01-18 21:41 UTC (permalink / raw)
To: git; +Cc: gitster, Ævar Arnfjörð Bjarmason
In-Reply-To: <1295386896-21828-1-git-send-email-avarab@gmail.com>
Change the tests in t/t5400-send-pack.sh to use test_when_finished to
unset git config variables that were set in the tests, e.g.:
git config --unset $variable_they_set
This doesn't change the test behavior, but makes each test more
self-contained.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t5400-send-pack.sh | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 656ab1a..0357610 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -90,7 +90,8 @@ test_expect_success 'refuse deleting push with denyDeletes' '
git config receive.denyDeletes true &&
git branch extra master
) &&
- test_must_fail git send-pack ./victim :extra master
+ test_must_fail git send-pack ./victim :extra master &&
+ test_when_finished "(cd victim && git config --unset receive.denyDeletes)"
'
test_expect_success 'cannot override denyDeletes with git -c send-pack' '
@@ -101,7 +102,8 @@ test_expect_success 'cannot override denyDeletes with git -c send-pack' '
git branch extra master
) &&
test_must_fail git -c receive.denyDeletes=false \
- send-pack ./victim :extra master
+ send-pack ./victim :extra master &&
+ test_when_finished "(cd victim && git config --unset receive.denyDeletes)"
'
test_expect_success 'override denyDeletes with git -c receive-pack' '
@@ -125,7 +127,8 @@ test_expect_success 'denyNonFastforwards trumps --force' '
victim_orig=$(cd victim && git rev-parse --verify master) &&
test_must_fail git send-pack --force ./victim master^:master &&
victim_head=$(cd victim && git rev-parse --verify master) &&
- test "$victim_orig" = "$victim_head"
+ test "$victim_orig" = "$victim_head" &&
+ test_when_finished "(cd victim && git config --unset receive.denyNonFastforwards)"
'
test_expect_success 'push --all excludes remote-tracking hierarchy' '
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] t/t5400-send-pack.sh: re-indent subshell invocation
From: Ævar Arnfjörð Bjarmason @ 2011-01-18 21:41 UTC (permalink / raw)
To: git; +Cc: gitster, Ævar Arnfjörð Bjarmason
In-Reply-To: <1295386896-21828-1-git-send-email-avarab@gmail.com>
Change a subshell invocation in t/t5400-send-pack.sh to use one line
per command in the subshell, that's the usual syntax we use for tests.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
t/t5400-send-pack.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 0357610..d4db5ac 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -32,7 +32,11 @@ test_expect_success setup '
done &&
git update-ref HEAD "$commit" &&
git clone ./. victim &&
- ( cd victim && git config receive.denyCurrentBranch warn && git log ) &&
+ (
+ cd victim &&
+ git config receive.denyCurrentBranch warn &&
+ git log
+ ) &&
git update-ref HEAD "$zero" &&
parent=$zero &&
i=0 &&
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] Documentation/fast-import: put explanation of M 040000 <dataref> "" in context
From: Junio C Hamano @ 2011-01-18 21:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, David Barr, Git Mailing List,
Ramkumar Ramachandra, Sverre Rabbelier, Gabriel Filion,
Johannes Sixt
In-Reply-To: <20110118211654.GA22763@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index 43d2174..7068de3 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -542,7 +542,7 @@ The value of `<path>` must be in canonical form. That is it must not:
> * contain the special component `.` or `..` (e.g. `foo/./bar` and
> `foo/../bar` are invalid).
>
> -In `040000` mode, `<path>` can be the empty string (`""`)
> +If `<mode>` is `040000`, `<path>` can be the empty string (`""`)
> to specify the root of the tree.
For whom is this paragraph written? People who produce g-f-i streams, or
people who interpret somebody else's g-f-i streams?
I am wondering if it is easier to read if we consistently target the
former, something like this:
The root of the tree can be represented by `<mode> 040000` with an
empty string as `<path>`.
because all the surrounding description seems to describe rules
(e.g. "quoting should be used", "The value of `<path>` must be ...").
^ permalink raw reply
* Re: [PATCH] Documentation/fast-import: put explanation of M 040000 <dataref> "" in context
From: Jonathan Nieder @ 2011-01-18 22:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Barr, Git Mailing List, Ramkumar Ramachandra,
Sverre Rabbelier, Gabriel Filion, Johannes Sixt
In-Reply-To: <7vk4i1khvp.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> +++ b/Documentation/git-fast-import.txt
>> @@ -542,7 +542,7 @@ The value of `<path>` must be in canonical form. That is it must not:
>> * contain the special component `.` or `..` (e.g. `foo/./bar` and
>> `foo/../bar` are invalid).
>>
>> -In `040000` mode, `<path>` can be the empty string (`""`)
>> +If `<mode>` is `040000`, `<path>` can be the empty string (`""`)
>> to specify the root of the tree.
>
> For whom is this paragraph written? People who produce g-f-i streams, or
> people who interpret somebody else's g-f-i streams?
>
> I am wondering if it is easier to read if we consistently target the
> former, something like this:
>
> The root of the tree can be represented by `<mode> 040000` with an
> empty string as `<path>`.
Sounds good to me. I suppose the clause "by <mode> 040000" should just
be left out --- we already explained that directories must have mode
S_IFDIR a few lines earlier.
^ permalink raw reply
* Manually turning a --bare local repository to a real mirror repository (--bare --mirror)
From: Ilyes Gouta @ 2011-01-18 21:59 UTC (permalink / raw)
To: git
Hi,
I'm setting up a local git repo which should mirrors the branches of
the original repo and at the same time hosts the local private
developement branches of the team.
At first step I did create a local copy by issuing:
git clone --bare <original_git_repository>
I found out later that fetching the various refs lead the local master
ref not automatically following the remote/master ref, after every git
fetch --all. I found that I have to use:
git clone --bare --mirror <original_git_repository>
instead to get that effect. Now please keep in mind that I intend to
also create local private branches where developers will push their
custom code.
My question: given that I don't have enough bandwidth and constant
Internet connectivity, I'd like to ask if it's possible to manually
turn a pure --bare local repository into a --bare --mirror one? If
yes, how to do that?
Please CC me when replying, because I'm not registered to the mailing list.
Thanks,
-Ilyes
^ permalink raw reply
* Re: Manually turning a --bare local repository to a real mirror repository (--bare --mirror)
From: Andreas Schwab @ 2011-01-18 22:35 UTC (permalink / raw)
To: Ilyes Gouta; +Cc: git
In-Reply-To: <AANLkTikE-sDhzw8=ybKhYhHtTH84V8EEOptMaq8xxRHc@mail.gmail.com>
> My question: given that I don't have enough bandwidth and constant
> Internet connectivity, I'd like to ask if it's possible to manually
> turn a pure --bare local repository into a --bare --mirror one? If
> yes, how to do that?
An ordinary bare clone has no fetch configuration. To turn the repo
into a mirror you just have to add one:
$ git config remote.origin.fetch "+refs/*:refs/*"
and set the mirror flag:
$ git config remote.origin.mirror true
Then do a git fetch to fetch any missing refs.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [RFC] Per-branch receive.* settings
From: Ævar Arnfjörð Bjarmason @ 2011-01-18 23:07 UTC (permalink / raw)
To: Git Mailing List
Currently you can do in your server's git config:
[receive]
denyDeletes = true
denyNonFastForwards = true
But for most servers that's not what you want, you actually want to
deny those things to the master branch, but allow people to have their
private topic branches that they can reset. So how about allowing:
[receive]
denyDeletes = false
denyNonFastForwards = false
[branch "master"]
denyDeletes = true
denyNonFastForwards = true
I.e. have a per-branch setting that overrides the global setting?
(Of course ideally this would be:
"branch.master.receive.{denyDeletes,denyNonFastForwards}"
But the *.ini format can only have a depth of three, so it has to be:
"branch.master.{denyDeletes,denyNonFastForwards}"
Or perhaps:
"branch.master.receive-{denyDeletes,denyNonFastForwards}"
Anyway, I can code this up if there's interest in it. This could also
be done with a .git/hooks/update hook, but IMO it's better to have
this as a documented setting for the most common things you want to
deny/allow.
^ permalink raw reply
* Re: [PATCH 2/3] t/t5400-send-pack.sh: add test_when_finished commands
From: Junio C Hamano @ 2011-01-18 23:10 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
In-Reply-To: <1295386896-21828-2-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
> index 656ab1a..0357610 100755
> --- a/t/t5400-send-pack.sh
> +++ b/t/t5400-send-pack.sh
> @@ -90,7 +90,8 @@ test_expect_success 'refuse deleting push with denyDeletes' '
> git config receive.denyDeletes true &&
> git branch extra master
> ) &&
> - test_must_fail git send-pack ./victim :extra master
> + test_must_fail git send-pack ./victim :extra master &&
> + test_when_finished "(cd victim && git config --unset receive.denyDeletes)"
> '
I agree that you are trying to do a good thing, but does this
implementation work in practice? If somebody breaks send-pack in such a
way that this push succeeds, doesn't the &&-chain will prevent your
"when-finished" hook to be registered to begin with? IOW, wouldn't you
want to have when-finished as _early_ as possible, before any test that
might fail to help us identify a new breakage?
The same comment applies to other two hunks in the patch.
^ permalink raw reply
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Dmitry Potapov @ 2011-01-19 0:07 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Alex Riesen
In-Reply-To: <loom.20110118T083048-91@post.gmane.org>
On Tue, Jan 18, 2011 at 07:40:05AM +0000, Alexey Shumkin wrote:
> change this
> > #, tcl-format
> > msgid "File %s seems to have unresolved conflicts, still stage?"
> > msgstr ""
> +"Файл %s кажется содержит необработанные конфликты.
> Продолжить подготовку к "
> "сохранению?"
> to
> +"Файл %s, кажется, содержит необработанные конфликты.
> Продолжить подготовку к "
> "сохранению?"
>
> "Кажется" - вводное слово, обособляется запятыми
In the above sentence, 'кажется' is not an introductory word, and thus
no comma is required. For details, see #2 at
http://ru.wiktionary.org/wiki/%D0%BA%D0%B0%D0%B6%D0%B5%D1%82%D1%81%D1%8F
However, such use of 'кажется' is more appropriate for colloquial speech
than for documentation or even computer messages. Also, I have never seen
'unresolved conflicts' being translated as 'необработанные конфликты'.
IMHO, the standard term is 'неразрешенные конфликты'. So my suggestion is:
Файл %s может содержать неразрешенные конфликты.
Dmitry
^ permalink raw reply
* Re: [RFC] Per-branch receive.* settings
From: Junio C Hamano @ 2011-01-19 0:12 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
In-Reply-To: <AANLkTimt8BPKsiyVEO+7i+so8337LaUu4A4jpywvJ-Ar@mail.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Currently you can do in your server's git config:
>
> [receive]
> denyDeletes = true
> denyNonFastForwards = true
>
> But for most servers that's not what you want, you actually want to
> deny those things to the master branch, but allow people to have their
> private topic branches that they can reset. So how about allowing:
>
> [receive]
> denyDeletes = false
> denyNonFastForwards = false
>
> [branch "master"]
> denyDeletes = true
> denyNonFastForwards = true
While this would not be better than having no such feature, if you are
talking about allow(ing) "people", I doubt this would scale very well.
I wonder some globbing with site-specific naming convention would be more
scalable:
[receive]
denyDeletes = refs/heads/* && !refs/heads/*/*
denyNonFastForwards = refs/heads/* && !refs/heads/*/*
And in the meantime, of course you can use your update hook, mimicking
various examples, ranging from contrib/hooks/update-paranoid,
Documentation/howto/update-hook-example.txt, and hooks/update.sample.
^ permalink raw reply
* Re: [PATCH 3/3] git-gui: update russian translation
From: Dmitry Potapov @ 2011-01-19 0:16 UTC (permalink / raw)
To: Alex Riesen
Cc: git, Shawn O. Pearce, Pat Thoyts, Serge Ziryukin,
Alexander Gavrilov
In-Reply-To: <20110117210855.GD27029@blimp.localdomain>
On Mon, Jan 17, 2011 at 10:08:55PM +0100, Alex Riesen wrote:
> -#: git-gui.sh:1367
> +#: git-gui.sh:1454
> msgid "Calling prepare-commit-msg hook..."
> msgstr "Вызов программы поддержки репозитория prepare-commit-msg..."
'hook' is usually translated as 'программа перехвата'
Dmitry
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Jay Soffian @ 2011-01-19 1:33 UTC (permalink / raw)
To: Jeff King
Cc: JT Olds, Junio C Hamano, Erik Faye-Lund, Linus Torvalds,
Tor Arntsen, git
In-Reply-To: <20110117222128.GA30869@sigill.intra.peff.net>
On Mon, Jan 17, 2011 at 5:21 PM, Jeff King <peff@peff.net> wrote:
> I bisected to 43c2325 (am: use get_author_ident_from_commit instead of
> mailinfo when rebasing, 2010-06-16), which was written to handle exactly
> this sort of thing.
Wow. Well, I apologize for not short-circuiting this thread much
sooner, but believe it or not, I didn't even remember writing that
till you just pointed it out. I'm too young to be losing my memory.
:-(
j.
^ permalink raw reply
* Re: [PATCH 39/47] setup: limit get_git_work_tree()'s to explicit setup case only
From: Nguyen Thai Ngoc Duy @ 2011-01-19 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <7v1v4aknij.fsf@alter.siamese.dyndns.org>
2011/1/19 Junio C Hamano <gitster@pobox.com>:
> This is for people who do "cd .git && GIT_WORK_TREE=.. git cmd". I have to
> wonder what happens to the pathspec given to the cmd---you are clearly
> outside of your working tree.
pathspecs are relative to worktree's root because prefix is NULL in
this case. Not very intuitive. And pathspecs that are supposed to take
files relative to user's cwd simply fail.
> Do we make sure that whatever GIT_WORK_TREE we end up with using is an
> ancestor directory of the $CWD when we require us to be inside the working
> tree?
We don't for most of commands (i.e. blindly chdir(worktree) in
setup_work_tree()). Only two commands (ls-files and rev-parse) seem to
do that.
> I think we should, as I don't think of a sane use case otherwise
> (unless you call "cd ../neigh; GIT_WORK_TREE=../work git diff ../work/foo"
> a sane way to futz with the file "foo" in the working tree "work" from a
> directory "neigh" that is unrelated to the repository).
But we don't strictly need that for whole tree operations. If
pathspecs are not given, wherever worktree is compared to cwd does not
matter much. The tricky thing is, when setup code does not know in
advance whether pathspecs are given. Perhaps something (untested) like
this for a start? Some commands like commit can also have
WHOLE_WORK_TREE, but it needs to check for is_inside_work_tree() by
itself it pathspec is given.
diff --git a/git.c b/git.c
index 68334f6..28abbdd 100644
--- a/git.c
+++ b/git.c
@@ -248,6 +248,10 @@ const char git_version_string[] = GIT_VERSION;
* RUN_SETUP for reading from the configuration file.
*/
#define NEED_WORK_TREE (1<<3)
+/*
+ * This command only works on work tree as a whole
+ */
+#define WHOLE_WORK_TREE (1<<4)
struct cmd_struct {
const char *cmd;
@@ -283,7 +287,7 @@ static int run_builtin(struct cmd_struct *p, int
argc, const char **argv)
commit_pager_choice();
if (!help && p->option & NEED_WORK_TREE)
- setup_work_tree();
+ setup_work_tree(p->option & WHOLE_WORK_TREE);
trace_argv_printf(argv, "trace: built-in: git");
@@ -328,7 +332,7 @@ static void handle_internal_command(int argc,
const char **argv)
{ "check-ref-format", cmd_check_ref_format },
{ "check-attr", cmd_check_attr, RUN_SETUP },
{ "cherry", cmd_cherry, RUN_SETUP },
- { "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },
+ { "cherry-pick", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE |
WHOLE_WORK_TREE },
{ "clone", cmd_clone },
{ "clean", cmd_clean, RUN_SETUP | NEED_WORK_TREE },
{ "commit", cmd_commit, RUN_SETUP | NEED_WORK_TREE },
@@ -362,7 +366,7 @@ static void handle_internal_command(int argc,
const char **argv)
{ "ls-remote", cmd_ls_remote, RUN_SETUP_GENTLY },
{ "mailinfo", cmd_mailinfo },
{ "mailsplit", cmd_mailsplit },
- { "merge", cmd_merge, RUN_SETUP | NEED_WORK_TREE },
+ { "merge", cmd_merge, RUN_SETUP | NEED_WORK_TREE | WHOLE_WORK_TREE },
{ "merge-base", cmd_merge_base, RUN_SETUP },
{ "merge-file", cmd_merge_file, RUN_SETUP_GENTLY },
{ "merge-index", cmd_merge_index, RUN_SETUP },
@@ -397,13 +401,13 @@ static void handle_internal_command(int argc,
const char **argv)
{ "reset", cmd_reset, RUN_SETUP },
{ "rev-list", cmd_rev_list, RUN_SETUP },
{ "rev-parse", cmd_rev_parse },
- { "revert", cmd_revert, RUN_SETUP | NEED_WORK_TREE },
+ { "revert", cmd_revert, RUN_SETUP | NEED_WORK_TREE | WHOLE_WORK_TREE },
{ "rm", cmd_rm, RUN_SETUP },
{ "send-pack", cmd_send_pack, RUN_SETUP },
{ "shortlog", cmd_shortlog, RUN_SETUP_GENTLY | USE_PAGER },
{ "show-branch", cmd_show_branch, RUN_SETUP },
{ "show", cmd_show, RUN_SETUP },
- { "status", cmd_status, RUN_SETUP | NEED_WORK_TREE },
+ { "status", cmd_status, RUN_SETUP | NEED_WORK_TREE | WHOLE_WORK_TREE },
{ "stripspace", cmd_stripspace },
{ "symbolic-ref", cmd_symbolic_ref, RUN_SETUP },
{ "tag", cmd_tag, RUN_SETUP },
diff --git a/setup.c b/setup.c
index 3d73269..c14e55c 100644
--- a/setup.c
+++ b/setup.c
@@ -208,7 +208,7 @@ int is_inside_work_tree(void)
return inside_work_tree;
}
-void setup_work_tree(void)
+void setup_work_tree(int gently)
{
const char *work_tree, *git_dir;
static int initialized = 0;
@@ -219,7 +219,11 @@ void setup_work_tree(void)
git_dir = get_git_dir();
if (!is_absolute_path(git_dir))
git_dir = make_absolute_path(git_dir);
- if (!work_tree || chdir(work_tree))
+ if (work_tree && (gently || is_inside_work_tree()))
+ ; /* Good */
+ else
+ die("This operation must be run in a work tree");
+ if (chdir(work_tree))
die("This operation must be run in a work tree");
/*
--
Duy
^ permalink raw reply related
* [RFC PATCH v2 0/5] Towards a Git-to-SVN bridge
From: Ramkumar Ramachandra @ 2011-01-19 5:44 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder, David Barr, Sverre Rabbelier
Hi,
There are two major changes this time around:
1. I've managed to inline the blobs in the fast-export stream. This
completely eliminates the need for persisting blobs.
2. I've also managed to produce relevant directory nodes, keeping
directory state in a new dir_cache interface. I followed Jonathan's
suggestion to keep it as a string_list for the moment. This is highly
inefficient and should improve soon- perhaps ressurect the treap we
had? Or perhaps find a simple trie implementation somewhere?
Suggestions are welcome.
Unfortunately, I've still not had the time to clean up- there's a
probably a lot of cruft, and everything "just works" for now. Next
time, I'll also try to write some tests, so we don't have to test it
by hand.
Thanks for reading.
Ramkumar Ramachandra (5):
date: Expose the time_to_tm function
vcs-svn: Start working on the dumpfile producer
Build an svn-fi target in contrib/svn-fe
fast-export: Introduce --inline-blobs
vcs-svn: Add dir_cache for svnload
Documentation/git-fast-export.txt | 5 +
Makefile | 4 +-
builtin/fast-export.c | 23 +++-
cache.h | 1 +
contrib/svn-fe/Makefile | 23 +++-
contrib/svn-fe/svn-fi.c | 16 ++
contrib/svn-fe/svn-fi.txt | 28 ++++
date.c | 2 +-
vcs-svn/dir_cache.c | 40 +++++
vcs-svn/dir_cache.h | 12 ++
vcs-svn/dump_export.c | 141 ++++++++++++++++++
vcs-svn/dump_export.h | 33 +++++
vcs-svn/svnload.c | 286 +++++++++++++++++++++++++++++++++++++
vcs-svn/svnload.h | 10 ++
14 files changed, 617 insertions(+), 7 deletions(-)
create mode 100644 contrib/svn-fe/svn-fi.c
create mode 100644 contrib/svn-fe/svn-fi.txt
create mode 100644 vcs-svn/dir_cache.c
create mode 100644 vcs-svn/dir_cache.h
create mode 100644 vcs-svn/dump_export.c
create mode 100644 vcs-svn/dump_export.h
create mode 100644 vcs-svn/svnload.c
create mode 100644 vcs-svn/svnload.h
--
1.7.4.rc1.7.g2cf08.dirty
^ permalink raw reply
* [PATCH 1/5] date: Expose the time_to_tm function
From: Ramkumar Ramachandra @ 2011-01-19 5:44 UTC (permalink / raw)
To: Git List; +Cc: Jonathan Nieder, David Barr, Sverre Rabbelier
In-Reply-To: <1295415899-1192-1-git-send-email-artagnon@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
cache.h | 1 +
date.c | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/cache.h b/cache.h
index d83d68c..95fea31 100644
--- a/cache.h
+++ b/cache.h
@@ -816,6 +816,7 @@ enum date_mode {
DATE_RAW
};
+struct tm *time_to_tm(unsigned long time, int tz);
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
const char *show_date_relative(unsigned long time, int tz,
const struct timeval *now,
diff --git a/date.c b/date.c
index 00f9eb5..e601a50 100644
--- a/date.c
+++ b/date.c
@@ -54,7 +54,7 @@ static time_t gm_time_t(unsigned long time, int tz)
* thing, which means that tz -0100 is passed in as the integer -100,
* even though it means "sixty minutes off"
*/
-static struct tm *time_to_tm(unsigned long time, int tz)
+struct tm *time_to_tm(unsigned long time, int tz)
{
time_t t = gm_time_t(time, tz);
return gmtime(&t);
--
1.7.4.rc1.7.g2cf08.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox