Re: gitweb on Godaddy

On Thu, Jul 04, 2013 at 11:56:40AM +0530, RR wrote: > HI > > Can someone share procedure to setup gitweb on a Godaddy hosting > server ? Any pointers to tutorials would be helpful > Hi, I suggest that you contact godaddy and check with them what options you have. Gitweb is a cgi program and you

gitweb on Godaddy

HI Can someone share procedure to setup gitweb on a Godaddy hosting server ? Any pointers to tutorials would be helpful Cheers -- 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/maj

Re: [RFD] Making "git push [--force/--delete]" safer?

Johannes Sixt writes: > Am 7/3/2013 21:53, schrieb Junio C Hamano: >> Johannes Sixt writes: >> >>> I don't think that is necessary. We already have *two* options to >>> force-push a ref: the + in front of refspec, and --force. >> >> They mean exactly the same thing; the only difference being t

Re: [RFD] Making "git push [--force/--delete]" safer?

Am 7/3/2013 21:53, schrieb Junio C Hamano: > Johannes Sixt writes: > >> I don't think that is necessary. We already have *two* options to >> force-push a ref: the + in front of refspec, and --force. > > They mean exactly the same thing; the only difference being that "+" > prefix is per target r

Re: [PATCH 1/2] commit: reject invalid UTF-8 codepoints

"brian m. carlson" writes: > git format-patch --binary seems to produce the exact same output as > without the --binary option. Is there a different way I should be > selecting the binary option? These days --binary is a no-op option for format-patch (we used to default to showing "binary files

Re: [PATCH 1/2] commit: reject invalid UTF-8 codepoints

On Sat, Jun 29, 2013 at 07:13:40PM -0700, Junio C Hamano wrote: > "brian m. carlson" writes: > > diff --git a/t/t3900/UTF-8-invalid.txt b/t/t3900/UTF-8-invalid.txt > > new file mode 100644 > > index 000..343684d > > --- /dev/null > > +++ b/t/t3900/UTF-8-invalid.txt > > @@ -0,0 +1,3 @@ > > +Com

Re: Feature request: "author branch" in commit object

On 4 July 2013 09:46, Jakub Narebski wrote: > Junio C Hamano pobox.com> writes: >> It is not just misleading but is actively wrong to recording the >> name of the original branch in commits and carrying them forward via >> rebase. If you want a record of what a group of commits were about, >> the

Re: Feature request:

lol, confusion abound. this message was intended to be in response to "Re: Feature request: prevent push -f from pushing all branches at once" On Jul 3, 2013, at 4:52 PM, Dany wrote: > Hey Jonathan, > > Thanks for the quick reply. I think that's a great message; I do have to say > that I woul

Re: Feature request:

Hey Jonathan, Thanks for the quick reply. I think that's a great message; I do have to say that I wouldn't have known what the `matching` and `simple` modes are without that message; I just had to look it up is all. It may be helpful to tell users that `simple` is probably what they want :) @D

Re: Feature request:

[I'm sorry about breaking Cc: chain - responding via GMane web interface] Junio C Hamano pobox.com> writes: > Ed Hutchins demeterr.com> writes: > > > I'm not trying to change the way git does things (which works perfectly > > well), I'm asking for some extra information to be added to the commi

Re: Feature request: prevent push -f from pushing all branches at once

Hi Dany, Dany wrote: > I had a pretty sucky thing happen to me today: while remote tracking > a non-master branch, I force pushed. This had the intended effect of > force pushing the branch I was working on, but also the unintended > function of force pushing all branches I wasn't on. Yeah, I ag

Feature request: prevent push -f from pushing all branches at once

Hi, I had a pretty sucky thing happen to me today: while remote tracking a non-master branch, I force pushed. This had the intended effect of force pushing the branch I was working on, but also the unintended function of force pushing all branches I wasn't on. I'm open to anyone's thoughts abo

Re: unexpected file deletion after using git rebase --abort

Jonathan Nieder writes: > Paul A. Kennedy wrote: > >> If we don't expect this, should we update the documentation for the >> --abort heading in the git rebase man page to indicate that newly >> staged content will be lost after a git rebase --abort? > > How about something along these lines? > >

Re: unexpected file deletion after using git rebase --abort

Paul A. Kennedy wrote: > If we don't expect this, should we update the documentation for the > --abort heading in the git rebase man page to indicate that newly > staged content will be lost after a git rebase --abort? How about something along these lines? diff --git i/Documentation/git-rebase.

unexpected file deletion after using git rebase --abort

Hello! I lost a previously untracked file that I added to the index in the middle of a git rebase --interactive session after a git rebase --abort. This was unexpected. $ ls forgotten_file forgotten_file $ git rebase --interactive HEAD~3 [change first rebase command from pick t

Re: [PATCH] Change "remote tracking" to "remote-tracking"

gits...@pobox.com wrote on Wed, 03 Jul 2013 13:33 -0700: > Jonathan Nieder writes: > > > Michael Schubert wrote: > > > >> --- a/Documentation/git-p4.txt > >> +++ b/Documentation/git-p4.txt > >> @@ -180,7 +180,7 @@ subsequent 'sync' operations. > >>Import changes into given branch. If the bra

Re: [PATCH] t4205: don't rely on en_US.UTF-8 locale existing

On Wed, Jul 03, 2013 at 10:53:03PM +0100, John Keeping wrote: > On Wed, Jul 03, 2013 at 02:41:06PM -0700, Junio C Hamano wrote: > > John Keeping writes: > > > > > My system doesn't have the en_US.UTF-8 locale (or plain en_US), which > > > causes t4205 to fail by counting bytes instead of UTF-8 co

Re: [PATCH] t4205: don't rely on en_US.UTF-8 locale existing

On Wed, Jul 03, 2013 at 02:41:06PM -0700, Junio C Hamano wrote: > John Keeping writes: > > > My system doesn't have the en_US.UTF-8 locale (or plain en_US), which > > causes t4205 to fail by counting bytes instead of UTF-8 codepoints. > > > > Instead of using sed for this, use Perl which behaves

Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail

On Wed, Jul 3, 2013 at 11:59 PM, Jonathan Nieder wrote: > Tony Finch wrote: >> +@extra_breadcrumbs:: >> + Additional links to be added to the start of the breadcrumb trail, >> + that are logically "above" the gitweb projects list. For example, >> + links to the organization and depart

Re: [PATCH] gitweb: allow extra breadcrumbs to prefix the trail

(cc-ing Jakub, gitweb wrangler) Tony Finch wrote: > There are often parent pages logically above the gitweb projects > list, e.g. home pages of the organization and department that host > the gitweb server. This change allows you to include links to those > pages in gitweb's breadcrumb trail. Ne

Re: [PATCH] t4205: don't rely on en_US.UTF-8 locale existing

On Wed, Jul 03, 2013 at 02:41:06PM -0700, Junio C Hamano wrote: > John Keeping writes: > > > My system doesn't have the en_US.UTF-8 locale (or plain en_US), which > > causes t4205 to fail by counting bytes instead of UTF-8 codepoints. > > > > Instead of using sed for this, use Perl which behaves

Re: [PATCH v7 2/7] wrap-for-bin: Make bin-wrappers chainable

Matthieu Moy writes: > I don't get it. It Git Mediawiki's tests, the tests scripts source > test-lib.sh, that unsets GITPERLLIB. Then, it calls the > mw-to-git/bin-wrapper/git that sets it properly, and calls the > toplevel's bin-wrapper. Ah, OK. I somehow was assuming that a wrapper sets GITPE

Re: [PATCH] t4205: don't rely on en_US.UTF-8 locale existing

John Keeping writes: > My system doesn't have the en_US.UTF-8 locale (or plain en_US), which > causes t4205 to fail by counting bytes instead of UTF-8 codepoints. > > Instead of using sed for this, use Perl which behaves predictably > whatever locale is in use. > > Signed-off-by: John Keeping >

Re: Review of git multimail

Ramkumar Ramachandra writes: > Yeah, this is good reasoning. And yes, I'm on Arch: python points to > python3, and python2 points to python2. I'm also on Arch and it has been this way since October 2010 [1]. Ubuntu plans to remove python2 from the desktop CD images in 14.04 [2], so having cod

[PATCH v2 0/3] Perl rewrite of Ruby git-related

This is v2 of the Perl rewrite of Felipe Contreras' git-related v9 patch series[1] which was written in Ruby. v2 addresses (hopefully all of) Junio's v1[2] review points. [1]: http://thread.gmane.org/gmane.comp.version-control.git/226065/ [2]: http://thread.gmane.org/gmane.comp.version-control.git

[PATCH v2 2/3] contrib: contacts: add ability to parse from committish

For example: % git contacts master..feature Committishes and patch files can be mentioned in the same invocation: % git contacts master..feature extra/*.patch Signed-off-by: Eric Sunshine --- contrib/contacts/git-contacts | 38 -- 1 file changed, 32 ins

[PATCH v2 1/3] contrib: add git-contacts helper

This script lists people that might be interested in a patch by going back through the history for each patch hunk, and finding people that reviewed, acknowledge, signed, authored, or were Cc:'d on the code the patch is modifying. It does this by running git-blame incrementally on each hunk and th

[PATCH v2 3/3] contrib: contacts: interpret committish akin to format-patch

As a convenience, accept the same style committish as accepted by git-format-patch. For example: % git contacts master will consider commits in the current branch built atop 'master', just as "git format-patch master" will format commits built atop 'master'. Signed-off-by: Eric Sunshine ---

Re: [PATCH] t4205: don't rely on en_US.UTF-8 locale existing

http://thread.gmane.org/gmane.comp.version-control.git/229291 this is why CCed > CC this to Johannes Sixt > > On Wed, Jul 03, 2013 at 09:18:08PM +0100, John Keeping wrote: > > My system doesn't have the en_US.UTF-8 locale (or plain en_US), which > > causes t4205 to fail by counting bytes instead

Re: [PATCH] t4205: don't rely on en_US.UTF-8 locale existing

CC this to Johannes Sixt On Wed, Jul 03, 2013 at 09:18:08PM +0100, John Keeping wrote: > My system doesn't have the en_US.UTF-8 locale (or plain en_US), which > causes t4205 to fail by counting bytes instead of UTF-8 codepoints. > > Instead of using sed for this, use Perl which behaves predictabl

Re: [PATCH v7 2/7] wrap-for-bin: Make bin-wrappers chainable

Junio C Hamano writes: > Matthieu Moy writes: > >> benoit.per...@ensimag.fr writes: >> >>> diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh >>> index 53a8dd0..dbebe49 100644 >>> --- a/wrap-for-bin.sh >>> +++ b/wrap-for-bin.sh >>> @@ -14,7 +14,7 @@ else >>> GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templ

Re: [PATCH] Change "remote tracking" to "remote-tracking"

Jonathan Nieder writes: > Michael Schubert wrote: > >> --- a/Documentation/git-p4.txt >> +++ b/Documentation/git-p4.txt >> @@ -180,7 +180,7 @@ subsequent 'sync' operations. >> Import changes into given branch. If the branch starts with >> 'refs/', it will be used as is. Otherwise if i

Re: [PATCH v7 2/7] wrap-for-bin: Make bin-wrappers chainable

Matthieu Moy writes: > benoit.per...@ensimag.fr writes: > >> diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh >> index 53a8dd0..dbebe49 100644 >> --- a/wrap-for-bin.sh >> +++ b/wrap-for-bin.sh >> @@ -14,7 +14,7 @@ else >> GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templates/blt' >> export GIT_TEMPLA

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

Brandon Casey writes: >> ... by penalizing the common case by how much? If it is not too >> much, then this obviously would be a good change. > > For something the size of the git repo, 5 branches, and pushing with > matching refspecs, I can't measure any difference. The fastest time I > record

Re: [PATCH v7 4/5] pretty: Add failing tests: --format output should honor logOutputEncoding

On Tue, Jul 02, 2013 at 09:22:09AM +0200, Johannes Sixt wrote: > Am 7/2/2013 0:50, schrieb Alexey Shumkin: > > On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote: > >> Am 6/26/2013 12:19, schrieb Alexey Shumkin: > >>> test_expect_success 'setup complex body' ' > >>> git config i18n.co

[PATCH] t4205: don't rely on en_US.UTF-8 locale existing

My system doesn't have the en_US.UTF-8 locale (or plain en_US), which causes t4205 to fail by counting bytes instead of UTF-8 codepoints. Instead of using sed for this, use Perl which behaves predictably whatever locale is in use. Signed-off-by: John Keeping --- This patch is on top of 'as/log-o

Re: [RFD] Making "git push [--force/--delete]" safer?

Junio C Hamano writes: > Jonathan del Strother writes: > >> I'm struggling to think of instances where I wouldn't want this >> CAS-like behaviour. Wouldn't it be better to make it the default when >> pushing, and allowing the current behaviour with "git push >> --blind-force" or something? > >

Re: [PATCH v8 0/5] Reroll patches against Git v1.8.3.2

Alexey Shumkin writes: > On Tue, Jul 02, 2013 at 12:41:03PM -0700, Junio C Hamano wrote: >> Alexey Shumkin writes: >> >> > v8 of this patch series includes the following changes against v7: >> >> Oops, isn't this already in 'next'? In that case, please feed >> incremental updates on top of th

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

On 7/3/2013 12:00 PM, Jeff King wrote: > On Wed, Jul 03, 2013 at 11:40:12AM -0700, Junio C Hamano wrote: > >> Brandon Casey writes: >> >>> Right. For repos with few refs on either side, I don't think there >>> will be any measurable difference. When pushing a single ref to a >>> repo with a ver

Re: [PATCH v8 0/5] Reroll patches against Git v1.8.3.2

On Tue, Jul 02, 2013 at 12:41:03PM -0700, Junio C Hamano wrote: > Alexey Shumkin writes: > > > v8 of this patch series includes the following changes against v7: > > Oops, isn't this already in 'next'? In that case, please feed > incremental updates on top of the patches that are already queued

git subtree push-all and pull-all

Hello, I see over the last year (on the web and in this mailing list) there was some activity to extend subtree with a .gittrees file and push-all/pull-all commands. Perhaps I missed it, but looking through the latest git code on the github mirror I can't find any reference to the .gittrees file

Re: [RFD] Making "git push [--force/--delete]" safer?

Johannes Sixt writes: > I don't think that is necessary. We already have *two* options to > force-push a ref: the + in front of refspec, and --force. They mean exactly the same thing; the only difference being that "+" prefix is per target ref, while "--force" covers everything, acting as a mere

Re: [RFD] Making "git push [--force/--delete]" safer?

Jonathan del Strother writes: > I'm struggling to think of instances where I wouldn't want this > CAS-like behaviour. Wouldn't it be better to make it the default when > pushing, and allowing the current behaviour with "git push > --blind-force" or something? Not until we run this in the wild f

Re: [RFD] Making "git push [--force/--delete]" safer?

Johan Herland writes: >> I'll leave the name open but tentatively use this name in the >> following, primarily to see how well it sits on the command line >> examples. > > I agree that neither --expect nor --validate are very good. I also > don't like --lockref, mostly because there is no locking

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

On 7/3/2013 11:40 AM, Junio C Hamano wrote: > Brandon Casey writes: > >> Right. For repos with few refs on either side, I don't think there >> will be any measurable difference. When pushing a single ref to a >> repo with a very large number of refs, we will see a very small net >> loss for the

Re: [PATCH] git-remote-mediawiki: un-brace file handles in binmode calls

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/majordomo-info.html

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

On Wed, Jul 03, 2013 at 11:40:12AM -0700, Junio C Hamano wrote: > Brandon Casey writes: > > > Right. For repos with few refs on either side, I don't think there > > will be any measurable difference. When pushing a single ref to a > > repo with a very large number of refs, we will see a very s

Re: [PATCH] git-config: update doc for --get with multiple values

John Keeping writes: > Since commit 00b347d (git-config: do not complain about duplicate > entries, 2012-10-23), "git config --get" does not exit with an error if > there are multiple values for the specified key but instead returns the > last value. Update the documentation to reflect this. > >

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

Brandon Casey writes: > Right. For repos with few refs on either side, I don't think there > will be any measurable difference. When pushing a single ref to a > repo with a very large number of refs, we will see a very small net > loss for the time required to prepare the string list (which gro

Re: [PATCH] Change "remote tracking" to "remote-tracking"

Michael Schubert wrote: > --- a/Documentation/git-p4.txt > +++ b/Documentation/git-p4.txt > @@ -180,7 +180,7 @@ subsequent 'sync' operations. > Import changes into given branch. If the branch starts with > 'refs/', it will be used as is. Otherwise if it does not start > with 'p

Re: [PATCH] git-config: update doc for --get with multiple values

On Wed, Jul 03, 2013 at 07:27:39PM +0100, John Keeping wrote: > Since commit 00b347d (git-config: do not complain about duplicate > entries, 2012-10-23), "git config --get" does not exit with an error if > there are multiple values for the specified key but instead returns the > last value. Updat

Re: [PATCH] clone: Skip pack-*.keep files when cloning locally

On Wed, Jul 3, 2013 at 7:26 PM, Junio C Hamano wrote: > Jens Lindström writes: > >> Not always. The Linux kernel can at least be configured not to allow >> it. It seems this is enabled by default in at least Debian. > > You learn a new thing every day, I guess. I am on Debian, I do not > think

[PATCH] git-config: update doc for --get with multiple values

Since commit 00b347d (git-config: do not complain about duplicate entries, 2012-10-23), "git config --get" does not exit with an error if there are multiple values for the specified key but instead returns the last value. Update the documentation to reflect this. Signed-off-by: John Keeping ---

Re: Feature request: "author branch" in commit object

Ed Hutchins writes: > I might be able to switch our corporate workflow to adding non-ff merge > commits, but the reason we moved away from using github's big red button > in the first place was to avoid the extra noise of merge-only commits. > > Actually you've pointed out an inconsistency: why i

Re: [PATCH] remote.c: avoid O(n^2) behavior in match_push_refs by using string_list

On Tue, Jul 2, 2013 at 11:23 PM, Jeff King wrote: > On Tue, Jul 02, 2013 at 04:53:48PM -0700, Brandon Casey wrote: > >> From: Brandon Casey >> >> When pushing, each ref in the local repository must be paired with a >> ref advertised by the remote server. Currently, this is performed by >> first

Re: Feature request: "author branch" in commit object

Ed Hutchins writes: > I'm not trying to change the way git does things (which works perfectly > well), I'm asking for some extra information to be added to the commit > so that analysis of the ancestry graph can be tied to the branch topics > that the original author was working from. Currently i

Re: [PATCH v5] [submodule] Add --depth to submodule update/add

Jens Lehmann writes: > The only minor problem is that this patch still does not apply cleanly > to master, next or pu (I wonder what you based this on ;-). Older iteration of the topic has been queued directly on top of v1.8.3. When I replace a topic with its new version, I try to rebuild on th

Re: Feature request: "author branch" in commit object

I might be able to switch our corporate workflow to adding non-ff merge commits, but the reason we moved away from using github's big red button in the first place was to avoid the extra noise of merge-only commits. Actually you've pointed out an inconsistency: why is it okay for merge commits to

Re: [PATCH] clone: Skip pack-*.keep files when cloning locally

Jens Lindström writes: > On Mon, Jul 1, 2013 at 6:20 PM, Junio C Hamano wrote: >> I am not sure if we should care that deeply about them in the first >> place. > > Fine by me; I don't really have a strong opinion on the matter. > >> Besides, I think you can make a hardlink to a file that you can

Re: [RFC/PATCHv4] submodule update: allow custom update command

Chris Packham writes: > Users can set submodule.$name.update to '!command' which will cause > 'command' to be run instead of checkout/merge/rebase. This allows the > user some finer grained control over how the update is done. The primary > motivation for this was interoperability with stgit how

Re: [RFC/PATCHv3] submodule update: allow custom update command

Chris Packham writes: > On 03/07/13 19:54, Chris Packham wrote: >> On a related note should I be updating Documentation/config.txt as well? >> Even if it's a statement that this feature exists refer to >> git-submodule(1) for details. >> > > Answering my own question. While 'update' is mentioned

Re: Feature request: "author branch" in commit object

On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins wrote: > On the other hand > trying to figure > out the history of events from a large directed graph of commits > without any clue about > what topics first spawned each commit is actively harmful in many > cases (trying to display > a clear history of

Re: Feature request: "author branch" in commit object

I'm not trying to change the way git does things (which works perfectly well), I'm asking for some extra information to be added to the commit so that analysis of the ancestry graph can be tied to the branch topics that the original author was working from. Currently if you have a rebase-branch/ff-

Re: [RFD] Making "git push [--force/--delete]" safer?

Am 7/3/2013 12:50, schrieb Michael Haggerty: > On 07/03/2013 12:11 PM, Johan Herland wrote: >> On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother >> wrote: >>> I'm struggling to think of instances where I wouldn't want this >>> CAS-like behaviour. Wouldn't it be better to make it the default

Re: [RFD] Making "git push [--force/--delete]" safer?

On 3 July 2013 11:00, Johan Herland wrote: > On Wed, Jul 3, 2013 at 10:49 AM, Junio C Hamano wrote: >> Johan Herland writes: >>> Overnight, it occured to me that --force-if-expected could be >>> simplified by leveraging the existing --force option; for the above >>> two examples, respectively: >

Re: Review of git multimail

On 07/03/2013 12:23 PM, Ramkumar Ramachandra wrote: > Michael Haggerty wrote: >> On 07/02/2013 09:23 PM, Ramkumar Ramachandra wrote: >>> git_multimail.py wrote: #! /usr/bin/env python2 >>> >>> Do all distributions ship it as python2 now? >> >> No, but nor is "python" always Python version 2.x

Re: Review of git multimail

Ramkumar Ramachandra wrote: >>> New-style class. I wonder why you suddenly switched. >> >> ? All of the classes are new-style classes. > > When you say class Foo:, aren't you declaring an old-style class by > default in python2? New-style classes are those that explicitly > inherit from object (

Re: [PATCH v7 2/7] wrap-for-bin: Make bin-wrappers chainable

benoit.per...@ensimag.fr writes: > diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh > index 53a8dd0..dbebe49 100644 > --- a/wrap-for-bin.sh > +++ b/wrap-for-bin.sh > @@ -14,7 +14,7 @@ else > GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templates/blt' > export GIT_TEMPLATE_DIR > fi > -GITPERLLIB='@@B

Re: [RFD] Making "git push [--force/--delete]" safer?

On 07/03/2013 12:11 PM, Johan Herland wrote: > On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother > wrote: >> I'm struggling to think of instances where I wouldn't want this >> CAS-like behaviour. Wouldn't it be better to make it the default when >> pushing, and allowing the current behaviour

nike free 5.0 herren

Innerhalb von IT den nächsten und zusätzlich 3. Stufe Ballungsräumen, die kleinen Kunden von einem lokalen nike free 5.0 herren Marke um zusätzliche Personen identifiziert werden sich bestimmt, aber das Wagnis der Individualität sein we

Re: [PATCH v7 2/7] wrap-for-bin: Make bin-wrappers chainable

On 07/03/2013 12:39 AM, benoit.per...@ensimag.fr wrote: > From: Benoit Person > > For now, bin-wrappers (based on wrap-for-bin.sh) redefine some > environnement variables (like $GITPERLLIB). If we want to chain to > those scripts and define one of those variables before, our changes > will be ove

Re: [PATCH 3/4] completion: add completer for rev-parse

Junio C Hamano wrote: > For --short and --symbolic-full-name, I have a feeling that we > should make "describe" a front-end for these. > [...] All very good. If and when someone does write that functionality (I personally find the task boring), we can remove this completer. Until such a time, th

Re: [PATCH] fixup-builtins: remove unused cruft

Junio C Hamano wrote: > It is not "nobody is working on", but "it has already been used to > help the transision and served its purpose, and is no longer is very > useful for follow-up work because the majority of remaining matches > it finds are false positives." Please amend the commit message a

Re: Review of git multimail

Michael Haggerty wrote: > On 07/02/2013 09:23 PM, Ramkumar Ramachandra wrote: >> git_multimail.py wrote: >>> #! /usr/bin/env python2 >> >> Do all distributions ship it as python2 now? > > No, but nor is "python" always Python version 2.x (I believe that Arch > Linux now installs Python 3 as "python

Re: [RFD] Making "git push [--force/--delete]" safer?

On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother wrote: > I'm struggling to think of instances where I wouldn't want this > CAS-like behaviour. Wouldn't it be better to make it the default when > pushing, and allowing the current behaviour with "git push > --blind-force" or something? I be

Re: [PATCH] clone: Skip pack-*.keep files when cloning locally

On Mon, Jul 1, 2013 at 6:20 PM, Junio C Hamano wrote: > I am not sure if we should care that deeply about them in the first > place. Fine by me; I don't really have a strong opinion on the matter. > Besides, I think you can make a hardlink to a file that you cannot > read. Not always. The Linu

Re: [PATCH] Change "remote tracking" to "remote-tracking"

On Wed, Jul 3, 2013 at 11:12 AM, Michael Schubert wrote: > Fix a typo ("remote remote-tracking") going back to the big cleanup > in 2010 (8b3f3f84 etc). Also, remove some more occurrences of > "tracking" and "remote tracking" in favor of "remote-tracking". > > Signed-off-by: Michael Schubert Rev

Re: git clone -b

On Mon, Jul 01, 2013 at 01:49:37PM -0400, Phil Hord wrote: > It would be nice to support more generic specs for the --branch > switch. But it is complicated because the refs have not been fetched > yet during the clone, and so normal refs operations -- which expect to > work on a local repository

Re: [RFD] Making "git push [--force/--delete]" safer?

On Wed, Jul 3, 2013 at 10:49 AM, Junio C Hamano wrote: > Johan Herland writes: >> Overnight, it occured to me that --force-if-expected could be >> simplified by leveraging the existing --force option; for the above >> two examples, respectively: >> >> $ git push --force --expect >> # validate

Re: [PATCH v7 2/7] wrap-for-bin: Make bin-wrappers chainable

>> For now, GITPERLLIB is only used in that kind of statements: >> use lib (split(/:/, $ENV{GITPERLLIB} || ... )); >> >> The trailing ':' does not really matter, split will ignore it. > > That may be true with the current use, but "For now" leaves funny > taste, doesn't it? definitely. For me, the

[PATCH] Change "remote tracking" to "remote-tracking"

Fix a typo ("remote remote-tracking") going back to the big cleanup in 2010 (8b3f3f84 etc). Also, remove some more occurrences of "tracking" and "remote tracking" in favor of "remote-tracking". Signed-off-by: Michael Schubert --- Documentation/git-p4.txt | 2 +- Documentation/git-submo

Re: Feature request: "author branch" in commit object

Ed Hutchins writes: > I realize that branch names are ephemeral repo-specific things, but it > would be really useful to be able to determine what branch a commit > was authored from (as a hint to ancestry graph layout tools, for > example). Is there any way to do this currently, is it planned, o

Re: [PATCH v7 4/7] git-remote-mediawiki: Update tests to run with the new bin-wrapper

benoit.per...@ensimag.fr writes: > --- a/contrib/mw-to-git/t/test-gitmw-lib.sh > +++ b/contrib/mw-to-git/t/test-gitmw-lib.sh > @@ -62,12 +62,8 @@ test_check_precond () { > test_done > fi > > - if [ ! -f "$GIT_BUILD_DIR"/git-remote-mediawiki ]; > - then > -

[PATCH] git-remote-mediawiki: un-brace file handles in binmode calls

Commit e83d36b66fc turned "print STDOUT" into "print {*STDOUT}", as suggested by perlcritic. Unfortunately, it also changed two "binmode STDOUT" calls the same way, which does not work and yield a "Not a GLOB reference" error. Signed-off-by: Matthieu Moy --- contrib/mw-to-git/git-remote-mediawik

Re: [PATCH 0/2] format-patch handling in-body From headers

On Wed, Jul 03, 2013 at 01:58:22AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > However, doing it right is kind of tricky due to rfc822 quoting, rfc2047 > > encoding, and handling non-ascii names correctly. Instead, this patch > > series takes a different approach: it teaches format-pa

[RFC/PATCHv4] submodule update: allow custom update command

Users can set submodule.$name.update to '!command' which will cause 'command' to be run instead of checkout/merge/rebase. This allows the user some finer grained control over how the update is done. The primary motivation for this was interoperability with stgit however being able to intercept the

Re: [PATCH 0/2] format-patch handling in-body From headers

Jeff King writes: > However, doing it right is kind of tricky due to rfc822 quoting, rfc2047 > encoding, and handling non-ascii names correctly. Instead, this patch > series takes a different approach: it teaches format-patch to do the > transformation itself, so that it can be used by my script

Re: [PATCH v7 2/7] wrap-for-bin: Make bin-wrappers chainable

Benoît Person writes: >> Do we want to add that ':' unconditionally? Could GITPERLLIB be >> empty? > > For now, GITPERLLIB is only used in that kind of statements: > use lib (split(/:/, $ENV{GITPERLLIB} || ... )); > > The trailing ':' does not really matter, split will ignore it. That may be tr

Re: [RFD] Making "git push [--force/--delete]" safer?

Johan Herland writes: > Overnight, it occured to me that --force-if-expected could be > simplified by leveraging the existing --force option; for the above > two examples, respectively: > > $ git push --force --expect > # validate foo @ origin == @{upstream} before pushing > > and > > $ git

Re: [RFC/PATCHv3] submodule update: allow custom update command

On 03/07/13 19:54, Chris Packham wrote: > On a related note should I be updating Documentation/config.txt as well? > Even if it's a statement that this feature exists refer to > git-submodule(1) for details. > Answering my own question. While 'update' is mentioned it's possible values are not. -

Re: [PATCH v5] [submodule] Add --depth to submodule update/add

On Wed, Jul 03, 2013 at 01:13:12AM -0700, Junio C Hamano wrote: > Jens Lehmann writes: > > The only minor problem is that this patch still does not apply cleanly > > to master, next or pu (I wonder what you based this on ;-). > > Thanks; will replace what I queued on 'pu'. I based it on master,

Re: Review of git multimail

On Wed, Jul 03, 2013 at 09:29:02AM +0100, John Keeping wrote: > Doesn't "git config --get" return an error if there are multiple values? > The answer is apparently "no" - I wrote the text below from > git-config(1) and then checked the behaviour. This seems to be a > regression in git-config (bise

Re: Review of git multimail

On Wed, Jul 03, 2013 at 10:02:34AM +0200, Michael Haggerty wrote: > On 07/03/2013 12:21 AM, Junio C Hamano wrote: > > Ramkumar Ramachandra writes: > > > >>> def get(self, name, default=''): > >>> try: > >>> values = self._split(read_git_output( > >>> ['

Re: Review of git multimail

Michael Haggerty writes: > I would be happy to add the checking that you described, but I didn't > have the impression that it is the usual convention. Does code that > wants a single value from the config usually verify that there is > one-and-only-one value, or does it typically just do the eq

Re: [PATCH v5] [submodule] Add --depth to submodule update/add

Jens Lehmann writes: > Am 02.07.2013 23:42, schrieb Fredrik Gustafsson: >> Add the --depth option to the add and update commands of "git submodule", >> which is then passed on to the clone command. This is useful when the >> submodule(s) are huge and you're not really interested in anything but >

Re: Review of git multimail

On 07/03/2013 12:21 AM, Junio C Hamano wrote: > Ramkumar Ramachandra writes: > >>> def get(self, name, default=''): >>> try: >>> values = self._split(read_git_output( >>> ['config', '--get', '--null', '%s.%s' % (self.section, >>> name)], >>>

Re: [RFC/PATCHv3] submodule update: allow custom update command

On 03/07/13 18:55, Jens Lehmann wrote: > Am 03.07.2013 01:26, schrieb Chris Packham: >> On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann wrote: >>> Am 02.07.2013 12:12, schrieb Chris Packham: --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -159,7 +159,9 @@

Re: [PATCH v5] [submodule] Add --depth to submodule update/add

Am 02.07.2013 23:42, schrieb Fredrik Gustafsson: > Add the --depth option to the add and update commands of "git submodule", > which is then passed on to the clone command. This is useful when the > submodule(s) are huge and you're not really interested in anything but > the latest commit. > > Tes

Re: [PATCH 2/2] teach format-patch to place other authors into in-body "From"

On Wed, Jul 3, 2013 at 3:08 AM, Jeff King wrote: > Format-patch generates emails with the "From" address set to > the author of each patch. If you are going to send the > emails, however, you would want to replace the author > identity with yours (if they are not the same), and bump the > author i

[PATCH 1/2] pretty.c: drop const-ness from pretty_print_context

In the current code, callers are expected to fill in the pretty_print_context, and then the pretty.c functions simply read from it. This leaves no room for the pretty.c functions to communicate with each other by manipulating the context (e.g., data seen while printing the header may impact how we

  1   2   >