Am 28.07.2012 20:46, schrieb Ramsay Jones:
Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh.
I tried, among other things, to provoke a failure thus:
$ for i in $(seq 100); do
> if ! ./t7810-grep.sh -i -v; then
> break;
> fi
> done
$
b
On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson wrote:
> Hi,
> sometimes git communicates with something that's not git on the other
> side (gitolite and github for example).
>
> Sometimes the server wants to communicate directly to the git user.
>
> git isn't really designed for this. gitolit
Dear Sir,
I would like to enhance git-tag documentation
--Unless -f is given, the tag to be created must not yet exist in the
.git/refs/tags/ directory.
++Unless -f is given, the tag to be created must not yet exist in the
.git/refs/tags/ directory or inside .git/packed-refs file.
Regards,
ch3co
On Sun, Jul 29, 2012 at 04:07:13PM +0530, Sitaram Chamarty wrote:
> On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson wrote:
> > Hi,
> > sometimes git communicates with something that's not git on the other
> > side (gitolite and github for example).
> >
> > Sometimes the server wants to communi
On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:
> Fredrik Gustafsson writes:
>
> > Sometimes the server wants to communicate directly to the git user.
> > ...
> > For example:
> > gitolite has something called wild repos[1]. The management is
> > cumbersome and if you misspell whe
On Sun, Jul 29, 2012 at 7:43 PM, Fredrik Gustafsson wrote:
> On Sun, Jul 29, 2012 at 04:07:13PM +0530, Sitaram Chamarty wrote:
>> On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson wrote:
>> > Hi,
>> > sometimes git communicates with something that's not git on the other
>> > side (gitolite and
On Sun, Jul 29, 2012 at 7:54 PM, Fredrik Gustafsson wrote:
> On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:
>> Fredrik Gustafsson writes:
>>
>> > Sometimes the server wants to communicate directly to the git user.
>> > ...
>> > For example:
>> > gitolite has something called wild
On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote:
> > Thanks, however I think auto-creation is a great feature for some cases
> > and I think there can be even more useable functions if we could get
> > user interaction.
>
> For the record, I don't think I agree. There's a place t
On Sun, Jul 29, 2012 at 8:35 PM, Fredrik Gustafsson wrote:
> On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote:
>> > Thanks, however I think auto-creation is a great feature for some cases
>> > and I think there can be even more useable functions if we could get
>> > user interactio
Am 29.07.2012 08:22, schrieb Junio C Hamano:
> Heiko Voigt writes:
>
>> Note: This is a code cleanup and does not fix any bugs. As a side effect
>> the variables containing the parsed flags to "git submodule status" are
>> passed down recursively. So everything was already behaving as expected.
>
Am 27.07.2012 20:37, schrieb Stefan Zager:
> The --jobs parameter may be used to set the degree of per-submodule
> parallel execution.
I think this is a sound idea, but it would be good to see some
actual measurements. What are the performance numbers with and
without this change? Which cases do b
On Sun, Jul 29, 2012 at 08:45:39PM +0530, Sitaram Chamarty wrote:
> I think you misunderstood how gitolite works. Gitolite does not have
> *any* user interaction other than sending some extra messages back via
> STDERR if you're using a normal git client to do normal git operations
> (clone/fetch/
Am 27.07.2012 13:45, schrieb Thomas Rast:
> Scott Chacon writes:
>
>> GitHub would like to volunteer to organize and pay for these events
>> this year. I would like to hold the developer-centric one in Berlin
>> in early October
>
> Yay, Berlin! I would be glad to join there; I would probably
On Sun, Jul 29, 2012 at 9:11 PM, Fredrik Gustafsson wrote:
> On Sun, Jul 29, 2012 at 08:45:39PM +0530, Sitaram Chamarty wrote:
>> I think you misunderstood how gitolite works. Gitolite does not have
>> *any* user interaction other than sending some extra messages back via
>> STDERR if you're usin
On Tue, Jul 24, 2012 at 4:33 PM, Justin Spahr-Summers
wrote:
> On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote:
>> Jens Lehmann http://web.de)> writes:
>>
>> > Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:
>> > > This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33)
On Mon, Jul 23, 2012 at 12:23 AM, Sitaram Chamarty wrote:
> On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano wrote:
>> mer...@stonehenge.com (Randal L. Schwartz) writes:
>>
"Darek" == Darek Bridges writes:
>>>
>>> Darek> I use git for many things, but I am trying to work out the
>>> Dare
I'm setting up a git server with git-http-backend and Smart HTTP but I'm
getting PROPFIND Error 405 with git push.
Here's my config:
ServerName localhost
DocumentRoot /opt/local/apache2/htdocs/repo
SetEnv GIT_PROJECT_ROOT /opt/local/apache2/htdocs/repo
SetEnv GIT_HTT
On Sunday, 29. July 2012 at 11:31, Phil Hord wrote:
> On Tue, Jul 24, 2012 at 4:33 PM, Justin Spahr-Summers
> mailto:justin.spahrsumm...@gmail.com)> wrote:
> > On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote:
> > > Jens Lehmann http://web.de)> writes:
> > >
> > > > Am 24.07.2012 21:01, sc
René Scharfe writes:
> Am 28.07.2012 20:46, schrieb Ramsay Jones:
>> Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh.
>> I tried, among other things, to provoke a failure thus:
>>
>> $ for i in $(seq 100); do
>> > if ! ./t7810-grep.sh -i -v; then
>> >
Junio C Hamano writes:
> I personally think that the documentation unnecessarily exposes the
> useless value assignment of the exit codes (the use of different
> exit codes was done merely to aid debugging the git-config command
> itself) by describing the then-current set of conditions, and shou
Sitaram Chamarty writes:
> Uggh, no. Client-git should only talk to server-git. It shouldn't be
> talking first to some *other* program (in this case gitolite), and
> then to to server-git. That doesn't sound sane to me.
>
> You should wrap this whole thing around something else that does it i
On Sun, Jul 29, 2012 at 3:30 PM, Justin Spahr-Summers
wrote:
> Hmm, you're right. After further investigation, this actually looks like a
> weird issue with soft links. Here's some exact output (with spacing only for
> clarity), using a public test repository at
> https://github.com/jspahrsumme
On Sunday, 29. July 2012 at 14:10, Phil Hord wrote:
> On Sun, Jul 29, 2012 at 3:30 PM, Justin Spahr-Summers
> mailto:justin.spahrsumm...@gmail.com)> wrote:
> > Hmm, you're right. After further investigation, this actually looks like a
> > weird issue with soft links. Here's some exact output (with
Sorry I missed this thread earlier. I'll drop this if it's not something
that's wanted.
On Sun, Jul 29, 2012 at 01:51:34PM -0700, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
> > Uggh, no. Client-git should only talk to server-git. It shouldn't be
> > talking first to some *other* progra
Junio C Hamano writes:
> Sitaram Chamarty writes:
>
>> Uggh, no. Client-git should only talk to server-git. It shouldn't be
>> talking first to some *other* program (in this case gitolite), and
>> then to to server-git. That doesn't sound sane to me.
>>
>> You should wrap this whole thing aro
On Sat, Jul 28, 2012 at 11:38:10PM -0700, Junio C Hamano wrote:
> > Then the following patch may be better because it leaves other cases
> > untouched (I'm not saying that we should or should not do it though)
>
> I personally think that the documentation unnecessarily exposes the
> useless value
On Sun, Jul 29, 2012 at 01:43:21PM -0700, Junio C Hamano wrote:
> > But if we really want to follow that "documented" subset of possible
> > conditions, I agree that your version to return "1" in this case,
> > together with a change to initialize "ret" to "7" and document it as
> > "all other err
Jens Lehmann writes:
> I tried today. Before this change no arguments got passed down and
> afterwards they are (but just the arguments, no submodule paths
> were passed on in either case; which is what Kevin fixed in the
> commit Heiko referenced). Three arguments are allowed for "git
> submodul
Heiko Voigt writes:
> On Fri, Jul 27, 2012 at 04:25:58PM -0700, Junio C Hamano wrote:
> ...
>> Of course, any set of rules have exceptions ;-) There are a few
>> things to which we say "Even though it is not in POSIX, everybody
>> who matters supports it, and without taking advantage of it, what
All looked reasonable, even though I'd want to read the
surrounding codepath over for 2/3 a few more times.
Will queue; thanks.
--
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/ma
Ever since cherry was built-in in e827633 (Built-in cherry,
2006-10-24), it has set a bunch of options on the the rev_info that
are only used while outputting a patch. But since the built-in cherry
command never needs to output any patch (it uses add_commit_patch_id
and has_commit_patch_id instead)
get_patch_ids() takes an already initialized rev_info and a
prefix. The prefix is used when initalizing a second rev_info. Since
the initialized rev_info already has a prefix and the prefix never
changes, we can used the prefix from the initialized rev_info to
initialize the second rev_info.
Signe
Separated out the removal of the unused diff options into patch 2/3
and added the necessary max_parents=1 in patch 3/3.
Martin von Zweigbergk (3):
remove unnecessary parameter from get_patch_ids()
cherry: don't set ignored rev_info options
log: remove redundant check for merge commit
built
While walking the revision list in get_patch_ids and cmd_cherry, we
check for each commit if there is more than one parent and ignore the
commit if that is the case. Instead, set rev_info.max_parents to 1 and
let the revision traversal code handle it for us.
Signed-off-by: Martin von Zweigbergk
-
On Mon, Jul 30, 2012 at 2:56 AM, Fredrik Gustafsson wrote:
> Sorry I missed this thread earlier. I'll drop this if it's not something
> that's wanted.
>
> On Sun, Jul 29, 2012 at 01:51:34PM -0700, Junio C Hamano wrote:
>> Sitaram Chamarty writes:
>>
>> > Uggh, no. Client-git should only talk to
Heiko Voigt writes:
> pfxlen can be longer than the path in objdir when relative_base contains
> the path to gits object directory.
s/gits// perhaps "Git's", but I am not sure.
> Signed-off-by: Heiko Voigt
> ---
> sha1_file.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
On Sun, Jul 29, 2012 at 11:52 AM, Bo98 wrote:
> I'm setting up a git server with git-http-backend and Smart HTTP but I'm
> getting PROPFIND Error 405 with git push.
This suggests the client didn't see the server as one supporting smart HTTP.
...
>
> And here's a snip from my access_log:
>
> :
Junio C Hamano writes:
> Heiko Voigt writes:
>
>> pfxlen can be longer than the path in objdir when relative_base contains
>> the path to gits object directory.
>
> s/gits// perhaps "Git's", but I am not sure.
>
>> Signed-off-by: Heiko Voigt
>> ---
>> sha1_file.c | 5 +++--
>> 1 file chang
On Mon, Jul 30, 2012 at 3:08 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Sitaram Chamarty writes:
>>
>>> Uggh, no. Client-git should only talk to server-git. It shouldn't be
>>> talking first to some *other* program (in this case gitolite), and
>>> then to to server-git. That does
乙酸鋰 writes:
> I would like to enhance git-tag documentation
>
> --Unless -f is given, the tag to be created must not yet exist in the
> .git/refs/tags/ directory.
> ++Unless -f is given, the tag to be created must not yet exist in the
> .git/refs/tags/ directory or inside .git/packed-refs file.
On Sun, Jul 29, 2012 at 6:04 PM, Sitaram Chamarty wrote:
> Of course this will only work with ssh. None of what Fredrik has so
> far suggested would possibly work on smart http without even more
> hacks, I think.
Now that we have smart HTTP, and its somewhat popular for sites to
deploy with, we
Sitaram Chamarty writes:
> As I may have said earlier, this interaction is far too site-specific
> to be rolled into git itself.
>
> How about a new hook instead? A pre-pack-protocol hook that acts as
> if it was called by the remote user as a command, and if it exit's
> with 0, then the real pa
On Mon, Jul 30, 2012 at 6:51 AM, Shawn Pearce wrote:
> On Sun, Jul 29, 2012 at 6:04 PM, Sitaram Chamarty wrote:
>> Of course this will only work with ssh. None of what Fredrik has so
>> far suggested would possibly work on smart http without even more
>> hacks, I think.
>
> Now that we have smar
On Mon, Jul 30, 2012 at 6:58 AM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> As I may have said earlier, this interaction is far too site-specific
>> to be rolled into git itself.
>>
>> How about a new hook instead? A pre-pack-protocol hook that acts as
>> if it was called by the remot
Shawn Pearce writes:
> We sort of want this in Gerrit Code Review to pass reviewer names on
> the command line of git push, making it easier for users to upload a
> code review. The idea is similar to what happens with gcc accepting
> linker flags that are just passed onto the linker.
For review
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
We are getting closer to 1.7.12-rc1; I do not see any topic in
'next' (let alnoe 'pu') right now that is so urgent that cannot wait
until the ne
L10n teams:
New "git.pot" is generated from git v1.7.12-rc0. L10n teams can get it
from the usual place and start translation.
* https://github.com/git-l10n/git-po/commits/master
This update is quite small:
l10n: Update git.pot (4 new, 3 removed messages)
Generate po/git.pot from v1.7
On Sun, Jul 29, 2012 at 7:38 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> We sort of want this in Gerrit Code Review to pass reviewer names on
>> the command line of git push, making it easier for users to upload a
>> code review. The idea is similar to what happens with gcc accepting
>>
Shawn Pearce writes:
>> The way to expose the extra information parsed by Git to the server
>> side could be made into calling out to hooks, and at that point,
>> gitolite would not even have to know about the pack protocol.
>
> Good point. The case that spawned this thread however still has a
>
49 matches
Mail list logo
