* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Jan Krüger @ 2009-11-11 14:13 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1257945756.26362.79.camel@heerbeest>
Hi,
> git pull -r*) URL says: [...]
> branch.master.remote = <nickname>
> and after cut-and-pasting that into .git/config, replacing
> <foo> with values, I get [...]
> fatal: bad config file line 17 in .git/config
> where line 17 is [without any indentation]
> branch.master.remote = eddy
The confusion is that while you can set values with this syntax if
you're using git config (git config branch.master.remote <some value>),
they're written differently in actual config files:
[branch "master"]
remote = <nickname>
merge = <remote-ref>
[remote "<nickname>"]
url = <url>
fetch = <refspec>
I can't think of a message of comparable length that would make this
clearer, though.
> Jan. -- who just finds out the uninstall target is missing?!?
> See attached.
I have no comments about the patch contents themselves, but please read
Documentation/SubmittingPatches. Most importantly, patches are
usually sent inline here, and without a signoff line they can't be
accepted for inclusion in the official repository.
> *) I've been wondering why GIT lacks a "update", ie
> pull-without-merge command. You almost never want
> to git pull /without/ -r?
-r stands for "rebase", i.e. it makes git pull use rebase instead of
merge. Rebase has certain problematic implications for decentralized
development, which is why it should only really be used in specific
circumstances (for rebasing commits that haven't been published in any
way yet).
"You" may almost never want to use git pull without rebase, but "many
others" do, and very often. Personally, I donn't recall a single
occasion where I have used git pull --rebase (not counting git-svn
stuff).
Anyway, look at config options branch.autosetuprebase and
branch.<nickname>.rebase to see how you can make pull use rebase by
default.
-Jan
^ permalink raw reply
* Re: gitk : french translation
From: Thomas Moulard @ 2009-11-11 14:15 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Emmanuel Trillaud, Maximilien Noal, Matthieu Moy, Nicolas Pitre,
Guy Brand, Git Mailing List
In-Reply-To: <20091111001050.GC27518@vidovic>
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
2009/11/11 Nicolas Sebrecht <nicolas.s.dev@gmx.fr>:
> The 10/11/09, Emmanuel Trillaud wrote:
> [snip...]
>
>> +#: gitk:1793 gitk:1817 gitk:3916 gitk:8786 gitk:10322 gitk:10498
>> +msgid "OK"
>> +msgstr "OK"
>
> This one should not be required.
In that case, how do you differentiate untranslated sentences from
translated sentences which have identical translations?
>> +#: gitk:2713
>> +msgid "/\t\tFocus the search box"
>> +msgstr "/"
>
> No idea?
Wikipedia suggests "cible de saisie"[1] for focus but it seems quite verbose,
therefore I propose:
msgid "/\t\tDonner le focus à la boîte de recherche"
Alternative translations:
msgid "/\t\tActiver la boîte de recherche"
msgid "/\t\tCibler la boîte de recherche"
Otherwise everything's ok for me.
[1] http://fr.wikipedia.org/wiki/Focus_%28informatique%29
--
Thomas Moulard
http://www.linkedin.com/in/moulard
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 272 bytes --]
^ permalink raw reply
* [PATCH] Clarify documentation on the "ours" merge strategy.
From: Peter Krefting @ 2009-11-11 14:03 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, Thomas Rast, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0911031047510.4985@pacific.mpi-cbg.de>
Make it clear that the merge strategy will discard all changes made to
the branch being merged, and not just avoid creating merge conflicts.
---
Documentation/merge-strategies.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
> If you want to use any merge strategy, you must understand what it does
> first.
Indeed. Perhaps this clarification will help the next poor soul that tries
doing what I tried?
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 4365b7e..a340dc9 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -30,7 +30,8 @@ octopus::
ours::
This resolves any number of heads, but the result of the
- merge is always the current branch head. It is meant to
+ merge is always the current branch head, discarding any
+ changes on the merged branch. It is meant to
be used to supersede old development history of side
branches.
--
1.6.4
^ permalink raw reply related
* Re: P4 Sync problem
From: Dmitry Smirnov @ 2009-11-11 14:57 UTC (permalink / raw)
To: git
In-Reply-To: <1a6be5fa0911110554u7c3a04c8hf50100b784b63c7a@mail.gmail.com>
Tor Arvid Lund <torarvid <at> gmail.com> writes:
> //depot/A/...
> -//depot/A/B/...
> //depot/A/B/C/...
>
> ... git-p4 sorts these paths by length. For a given filename, it finds
> the longest path that matches that files directory, and if that path
> starts with a '-', the file is not synced (for a file
> "//depot/A/B/myfile.c" it gets a match on "-//depot/A/B/...", and
> myfile.c is not synced, but the file "//depot/A/B/C/myotherfile.c" it
> matches "//depot/A/B/C/...")
>
> Do you have an example that shows how it might fail?
According to the P4 User's Guide
(http://www.perforce.com/perforce/doc.091/manuals/p4guide/02_config.html#1066090)
Perforce prefer later mapping if there is a conflict.
So, if you switch paths:
-//depot/A/B/...
//depot/A/...
perforce will sync all the the files. Of course, this is not a very
useful case.
I suppose the order is not important until mapping are implemented...
^ permalink raw reply
* Re: Consensus on "Git"
From: Teemu Likonen @ 2009-11-11 14:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Symonds, git
In-Reply-To: <alpine.DEB.1.00.0911111028040.19111@intel-tinevez-2-302>
On 2009-11-11 10:33 (+0100), Johannes Schindelin wrote:
> Yes, in Open Source, we are used to crude, geeky humor, some of us
> even accept blunt mails, but we are embedded in a world that is called
> "reality".
>
> In my experience, in this world it is much easier to tell people that
> your program is called "Git" ("could have been John, either") and be
> done with the questions.
Yes, that’s how the language works. Proper nouns are capitalized, so in
plain text the name of this program should always be written “Git”. Only
in command examples it is “git”.
Sometimes people mix proper nouns and logos/brands. Proper nouns are
under the rules of the language. For example, I can’t go telling people
that my name must be written “teEMu” because I don’t own Finnish.
In logos the brands’ owner can try to be funny and cool and different
and write anything they want (like “gɨT” or “GīT”).
^ permalink raw reply
* Re: [PATCH] Clarify documentation on the "ours" merge strategy.
From: Baz @ 2009-11-11 15:13 UTC (permalink / raw)
To: Peter Krefting
Cc: Git Mailing List, Johannes Schindelin, Thomas Rast,
Björn Steinbrink
In-Reply-To: <200911111411.nABEBfox031023@ds9.cixit.se>
2009/11/11 Peter Krefting <peter@softwolves.pp.se>:
> Make it clear that the merge strategy will discard all changes made to
> the branch being merged, and not just avoid creating merge conflicts.
> ---
> Documentation/merge-strategies.txt | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
>> If you want to use any merge strategy, you must understand what it does
>> first.
>
> Indeed. Perhaps this clarification will help the next poor soul that tries
> doing what I tried?
>
> diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
> index 4365b7e..a340dc9 100644
> --- a/Documentation/merge-strategies.txt
> +++ b/Documentation/merge-strategies.txt
> @@ -30,7 +30,8 @@ octopus::
>
> ours::
> This resolves any number of heads, but the result of the
> - merge is always the current branch head. It is meant to
> + merge is always the current branch head, discarding any
> + changes on the merged branch. It is meant to
I think part of the problem is that it is unclear what the "current
branch head" means when used in a rebase, and hence when this text is
included in the help for git-rebase and git-pull. This flipped
behaviour is surprising given the natural meaning of 'ours', or
'current branch', particularly for git pull:
git pull -s ours - discards changes in remote branch, keeps changes
in current branch
git pull --rebase -s ours - discards changes in current branch, keeps
changes in remote branch
Perhaps something more in the way of an explicit warning?
ours::
This resolves any number of heads, but the result of the
merge is always the current branch head, discarding any
changes on the merged branch. It is meant to
be used to supersede old development history of side
branches. Note that when rebasing, the branch you are
rebasing onto is the "current branch head", and using this
strategy will lose all of your changes - unlikely to be what
you wanted to do.
-Baz
> be used to supersede old development history of side
> branches.
>
> --
> 1.6.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2] Update gitworkflows man page to include release workflow
From: Raman Gupta @ 2009-11-11 15:23 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00911110505m2f21a787sfb3e0d6c130b0b4d@mail.gmail.com>
Thiago Farina wrote:
> Hi,
>
> On Tue, Nov 10, 2009 at 2:08 PM, <rocketraman@fastmail.fm> wrote:
>> From: Raman Gupta <raman@rocketraman.com>
>>
>> The gitworkflows man page currently provides an overview of the workflows
>> used by git.git itself to serve as inspiration for people to use when
>> designing their own workflows. The current man page does a reasonable
>> job at describing the development process, but it does not contain any
>> guidance as to the workflow used for releases. Now add a basic
>> introduction to the branch management required for a release, so that a
>> reader may understand how the maint, master, next, and topic branches are
>> affected.
> Here
> http://git.kernel.org/?p=git/git.git;a=blob;f=Checklist.txt;h=37745f39487537117fb7f3a9a6f5b8e7d989a884;hb=refs/heads/todo
> there is a release checklist, maybe you could extend your patch to
> include more information from this?
Most of the checklist is specific to the git infrastructure rather
than git branch management. The latter is the focus of the
gitworkflows man page. The relevant items from checklist.txt (e.g.
merge 'maint' to 'master') are already included in the patch.
Cheers,
Raman
^ permalink raw reply
* Re: Consensus on "Git"
From: Michael J Gruber @ 2009-11-11 15:37 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Johannes Schindelin, David Symonds, git, Junio C Hamano
In-Reply-To: <87y6mdyuoo.fsf@iki.fi>
Teemu Likonen venit, vidit, dixit 11.11.2009 15:58:
> On 2009-11-11 10:33 (+0100), Johannes Schindelin wrote:
>
>> Yes, in Open Source, we are used to crude, geeky humor, some of us
>> even accept blunt mails, but we are embedded in a world that is called
>> "reality".
>>
>> In my experience, in this world it is much easier to tell people that
>> your program is called "Git" ("could have been John, either") and be
>> done with the questions.
>
> Yes, that’s how the language works.
And why Dick Cheney was allowed to keep his name ;)
> Proper nouns are capitalized, so in
> plain text the name of this program should always be written “Git”. Only
> in command examples it is “git”.
>
> Sometimes people mix proper nouns and logos/brands. Proper nouns are
> under the rules of the language. For example, I can’t go telling people
> that my name must be written “teEMu” because I don’t own Finnish.
Given that reasoning, we should really use "Git" whenever the program or
project name is meant. Is that something we can reach concensus on?
> In logos the brands’ owner can try to be funny and cool and different
> and write anything they want (like “gɨT” or “GīT”).
Nice!
Michael
^ permalink raw reply
* Re: t5541-http-push hanging
From: Tay Ray Chuan @ 2009-11-11 15:47 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <B17AB159-E217-4E1F-BEA3-97E5892C13F4@gernhardtsoftware.com>
Hi,
On Wed, Nov 11, 2009 at 2:28 PM, Brian Gernhardt
<brian@gernhardtsoftware.com> wrote:
> error: RPC failed; result=22, HTTP code = 500
> ^CFATAL: Unexpected exit with code 130
looks like an apache/http-backend issue. What version of apache are you running?
Also, are you running out of the 'next' branch?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: t5541-http-push hanging
From: Shawn O. Pearce @ 2009-11-11 15:50 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <B17AB159-E217-4E1F-BEA3-97E5892C13F4@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
> brian@hermes httpd (master)$ cat error.log
> [Wed Nov 11 06:19:39 2009] [notice] Apache/2.2.13 (Unix) configured -- resuming normal operations
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] git-http-backend(59490) malloc: *** error for object 0x100200340: incorrect checksum for freed object - object was probably modified after being freed.
> [Wed Nov 11 06:19:39 2009] [error] [client 127.0.0.1] *** set a breakpoint in malloc_error_break to debug
> [Wed Nov 11 06:19:40 2009] [error] [client 127.0.0.1] Premature end of script headers: git-http-backend
> [Wed Nov 11 06:24:23 2009] [notice] caught SIGTERM, shutting down--
Yikes, looks like git-http-backend corrupted its heap.
Is this by any chance Mac OS X ?
--
Shawn.
^ permalink raw reply
* Re: Move repository from OS X to Windows
From: Pascal Obry @ 2009-11-11 15:53 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4AFABCF8.9060601@syntevo.com>
Thomas,
> I've cloned a very large repository on OS X and want to move that to Windows
> (trying to avoid to clone the repository a second time). What steps should I
> do to make it working (currently, I'm getting an error on pull/merge that
> "Entry 'foo' is not uptodate. Cannot merge.")?
Is that a git-svn clone?
Otherwise I do not see why you avoid a second clone. Cloning from your
windows machine the OSX repo won't be slower than cloning from the
original repo? Or I missed something...
If you are speaking about a git-svn clone, I understand. In this case I
generally I just rsync the .git directory from one machine to the other:
$ mkdir project
$ cd project
$ rsync -a machine:/path/to/project/.git .
$ git reset --hard HEAD
And you are done.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* excerpts from tomorrow's "What's cooking" draft
From: Junio C Hamano @ 2009-11-11 9:34 UTC (permalink / raw)
To: git
I'll do the full-list at the end of my git Wednesday, but here are the
current highlights I am sending out to hear opinions from people.
Please note that I haven't caught up with the patches from past 12 hours
or so.
----------------------------------------------------------------
[New Topics]
* jn/help-everywhere (2009-11-09) 21 commits
- diff --no-index: make the usage string less scary
- ...
- Show usage string for 'git grep -h'
(this branch uses jn/maint-http-fetch-mingw and jn/remove-fetch--tool.)
There were unrelated but still worthy fixes, so I reordered some of them;
also the "usage()" change is different from the one that was posted (see
my comment in $gmane/132592).
* jn/maint-http-fetch-mingw (2009-11-09) 1 commit.
- http-fetch: add missing initialization of argv0_path
(this branch is used by jn/help-everywhere.)
* jn/remove-fetch--tool (2009-11-09) 1 commit
- Retire fetch--tool helper to contrib/examples
(this branch is used by jn/help-everywhere.)
These two were originally part of the "help-everywhere" topic but
they can stand on their own.
* jc/log-stdin (2009-11-03) 1 commit
- Teach --stdin option to "log" family
This is not signed-off (see $gmane/131971 for list of things you can do to
help advancing this topic).
--------------------------------------------------
[Stalled]
* sc/protocol-doc (2009-10-29) 1 commit
- Update packfile transfer protocol documentation
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
Any objections against merging this to 'next'?
* jc/fix-tree-walk (2009-10-22) 11 commits.
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ ...
+ diff-lib.c: fix misleading comments on oneway_diff()
This has some stupid bugs and temporarily reverted from 'next' until I can
fix it, but the "temporarily" turned out to be very loooong. Sigh...
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- ...
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
(merged to 'next' on 2009-11-01 at 948327a)
+ Add selftests verifying concatenation of multiple notes for the same commit
+ ...
+ Introduce commit notes
I somehow thought that the later API part was waiting for updates but
nothing seems to be happening.
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ ...
Ajax-y blame. Any progress or RFH?
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- ...
- fast-import: put option parsing code in separate functions
It seemed to be moving again soon, but nothing has happened yet...
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
--------------------------------------------------
[Cooking]
* bw/autoconf-more (2009-11-04) 2 commits
- configure: add settings for gitconfig, editor and pager
- configure: add macro to set arbitrary make variables
Looked sensible. Any comments?
* bg/format-patch-doc-update (2009-11-07) 4 commits
- format-patch: Add "--no-stat" as a synonym for "-p"
- format-patch documentation: Fix formatting
- format-patch documentation: Remove diff options that are not useful
- format-patch: Always generate a patch
Looked sensible, even though this may want to wait for 1.7.0. We'll see
when we merge this to 'next'.
* rj/maint-simplify-cygwin-makefile (2009-10-27) 1 commit.
- Makefile: merge two Cygwin configuration sections into one
(this branch is used by rj/cygwin-msvc.)
This is one of the most obviously correct bit from "Compiling on Cygwin
using MSVC fails" topic.
* rj/cygwin-msvc (2009-11-09) 3 commits.
- Add explicit Cygwin check to guard WIN32 header inclusion
- MSVC: Add support for building with NO_MMAP
- Makefile: keep MSVC and Cygwin configuration separate
(this branch uses rj/maint-simplify-cygwin-makefile.)
I think J6t was not happy with the tip one.
* cc/bisect-doc (2009-11-08) 1 commit
- Documentation: add "Fighting regressions with git bisect" article
Any comments? Should it go to Documentation/technical instead?
* jn/editor-pager (2009-10-30) 8 commits
- Provide a build time default-pager setting
- Provide a build time default-editor setting
- am -i, git-svn: use "git var GIT_PAGER"
- add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
- Teach git var about GIT_PAGER
- Teach git var about GIT_EDITOR
- Do not use VISUAL editor on dumb terminals
- Handle more shell metacharacters in editor names
Any comments?
* sc/difftool-p4merge (2009-10-28) 1 commit
(merged to 'next' on 2009-10-31 at 194b5c5)
+ mergetool--lib: add p4merge as a pre-configured mergetool option
I do not do p4 nor use difftool, so it's much easier for me to merge this
to 'master' and wait for anybody to scream if there is breakage. I'll do
so, unless I hear objections in a few days.
* sr/vcs-helper (2009-11-06) 12 commits
- Add Python support library for remote helpers
- ...
- Fix memory leak in helper method for disconnect
Re-rolled series that contains Daniel's and Johan's.
Any comments? Is everybody happy?
* fc/doc-fast-forward (2009-10-24) 1 commit.
(merged to 'next' on 2009-11-01 at faaad90)
+ Use 'fast-forward' all over the place
Soon in 'master'; carrying this in 'next' for too long is turning out to
be quite painful.
* ks/precompute-completion (2009-10-26) 3 commits.
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
What's the status of this thing? Last time I polled the list I had an
impression that it was not quite ready...
* sp/smart-http (2009-11-09) 34 commits
- t5551-http-fetch: Work around broken Accept header in libcurl
- t5551-http-fetch: Work around some libcurl versions
- http-backend: Protect GIT_PROJECT_ROOT from /../ requests
- Git-aware CGI to provide dumb HTTP transport
(merged to 'next' on 2009-11-06 at 666837c)
+ http-backend: Test configuration options
+ ...
+ http-push: fix check condition on http.c::finish_http_pack_request()
The tip ones are workarounds to the issues identified by somebody without
a real name (I do not remember---I am bad at people's names even when they
are real).
* ef/msys-imap (2009-10-22) 9 commits.
(merged to 'next' on 2009-10-31 at 8630603)
+ Windows: use BLK_SHA1 again
+ MSVC: Enable OpenSSL, and translate -lcrypto
+ mingw: enable OpenSSL
+ mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
+ imap-send: build imap-send on Windows
+ imap-send: fix compilation-error on Windows
+ imap-send: use run-command API for tunneling
+ imap-send: use separate read and write fds
+ imap-send: remove useless uid code
Soon in 'master', unless I hear objections from msys folks or imap-send
users.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- ...
- update-index: refactor mark_valid() in preparation for new options
The latest update I didn't look at very closely but I had an impression
that it was touching very generic codepath that would affect non sparse
cases, iow the patch looked very scary (the entire series already is).
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: Junio C Hamano @ 2009-11-11 4:42 UTC (permalink / raw)
To: David Aguilar; +Cc: Sam Vilain, paulus, git
In-Reply-To: <20091111040715.GA44672@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> That said, if there's a consensus that the path doesn't matter
> much than we could change the behavior. I was just trying to be
> careful.
If we are not honoring GITK_TMPDIR and suddenly start paying attention to
it, that already is a change in behaviour. Why is it better than paying
attention to TMPDIR?
But why does gitk, which is primarily a read-only history browsing tool
(yes, I know it can do "checkout" and stuff), needs to write anything to
anywhere in the first place?
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Ben Walton @ 2009-11-11 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpj9s8vk.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
Excerpts from Junio C Hamano's message of Wed Nov 11 04:34:07 -0500 2009:
> * bw/autoconf-more (2009-11-04) 2 commits
> - configure: add settings for gitconfig, editor and pager
> - configure: add macro to set arbitrary make variables
The only note here is that these patches are dependent on the ones in
jn/editor-pager, so if that doesn't get merged, this shouldn't
either. From my POV, jn/editor-pager does what I was after, so I'm
happy.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitk: Add ability to define an alternate temporary directory
From: David Aguilar @ 2009-11-11 16:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, paulus, git
In-Reply-To: <7vr5s5y8n8.fsf@alter.siamese.dyndns.org>
On Tue, Nov 10, 2009 at 08:42:35PM -0800, Junio C Hamano wrote:
> David Aguilar <davvid@gmail.com> writes:
>
> > That said, if there's a consensus that the path doesn't matter
> > much than we could change the behavior. I was just trying to be
> > careful.
>
> If we are not honoring GITK_TMPDIR and suddenly start paying attention to
> it, that already is a change in behaviour. Why is it better than paying
> attention to TMPDIR?
True.
> But why does gitk, which is primarily a read-only history browsing tool
> (yes, I know it can do "checkout" and stuff), needs to write anything to
> anywhere in the first place?
It happens when you click on a commit, right-click on a file
and then choose "external diff".
gitk writes file@commit and file@commit^ to temporary files
and diffs them using an external diff tool.
Shall I reroll with s/GITK_TMPDIR/TMPDIR/ ?
gitk was written before git-difftool existed.
A higher impact change would be to change gitk to use
git-difftool instead of managing its own temporary files.
If we're looking for the ideal solution than that is
probably it. The only downside is that gitk would stop
working with git versions < 1.6.3. That doesn't seem like
a real issue, though, because gitk is bundled with git.
Thoughts?
--
David
^ permalink raw reply
* Re: [gitk] [PATCH] 0/2 Merging master into dev
From: Johannes Schindelin @ 2009-11-11 16:52 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Paul Mackerras, git
In-Reply-To: <871vkbw7x2.fsf@users.sourceforge.net>
Hi (especially "Hi Paul"),
On Sat, 6 Nov 2009, Pat Thoyts wrote:
> I've merged the current changes for gitk master onto the dev branch and
> fixed some conflicts and then modified the default colour assignments
> for windows to use the system colours so that it will pick up the stock
> colours defined via the windows property pages.
>
> However, I'm not too certain how to post such a merge commit. Usually I
> do 'git format-patch -M' but in this case that emits all the commits
> that were merged. It looks like 'git show -p' is producing a merge patch
> so I am posting that for 1/2 and a normal patch for 2/2. If there is
> better way let me know and I will redo.
>
> Note: these patches are for the gitk dev branch.
>
> Hopefully this themed tk version is suitable for merging up to master
> soon as this will significantly improve the look of the application in
> msysGit.
I have no illusions about the priority of msysGit-related patches for
gitk, but it would be nice to get this going again. (And I want to avoid
forking gitk just for msysGit.)
Paul?
Ciao,
Dscho
^ permalink raw reply
* Re: t5541-http-push hanging
From: Brian Gernhardt @ 2009-11-11 16:53 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git List
In-Reply-To: <be6fef0d0911110747k219e1fe0l7bd19bbc58b5ea3e@mail.gmail.com>
On Nov 11, 2009, at 10:47 AM, Tay Ray Chuan wrote:
> On Wed, Nov 11, 2009 at 2:28 PM, Brian Gernhardt
> <brian@gernhardtsoftware.com> wrote:
>> error: RPC failed; result=22, HTTP code = 500
>> ^CFATAL: Unexpected exit with code 130
>
> looks like an apache/http-backend issue. What version of apache are you running?
It's Apache 2.2.13 on Mac OS X 10.6.2
> Also, are you running out of the 'next' branch?
Yes. That particular build was v1.6.5.2-372-gc05027d
However I've been seeing it for a couple days.
~~ Brian
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-11 16:59 UTC (permalink / raw)
To: Thomas Moulard
Cc: Nicolas Sebrecht, Emmanuel Trillaud, Maximilien Noal,
Matthieu Moy, Nicolas Pitre, Guy Brand, Git Mailing List
In-Reply-To: <g1w6apsyubgonjhsvjUYAxe124vaj_firegpg@mail.gmail.com>
The 11/11/09, Thomas Moulard wrote:
> 2009/11/11 Nicolas Sebrecht <nicolas.s.dev@gmx.fr>:
> > The 10/11/09, Emmanuel Trillaud wrote:
> >
> >> +#: gitk:1793 gitk:1817 gitk:3916 gitk:8786 gitk:10322 gitk:10498
> >> +msgid "OK"
> >> +msgstr "OK"
> >
> > This one should not be required.
>
> In that case, how do you differentiate untranslated sentences from
> translated sentences which have identical translations?
I don't try because I don't need to. If a sentence is not translated,
translators understand it doesn't need a translation if the translation
is identical.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Johan Herland @ 2009-11-11 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpj9s8vk.fsf@alter.siamese.dyndns.org>
On Wednesday 11 November 2009, Junio C Hamano wrote:
> * jh/notes (2009-10-09) 22 commits.
> - fast-import: Proper notes tree manipulation using the notes API
> - ...
> - Notes API: get_commit_notes() -> format_note() + remove the commit
> restriction (merged to 'next' on 2009-11-01 at 948327a)
> + Add selftests verifying concatenation of multiple notes for the
> same commit + ...
> + Introduce commit notes
>
> I somehow thought that the later API part was waiting for updates but
> nothing seems to be happening.
Sorry for the silence, I've been out with the flu, and been caught up
with meatspace issues in general. Will try to send another iteration of
the later API part in a few days.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Move repository from OS X to Windows
From: David Aguilar @ 2009-11-11 17:08 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4AFABCF8.9060601@syntevo.com>
On Wed, Nov 11, 2009 at 02:32:40PM +0100, Thomas Singer wrote:
> Hi,
>
> I've cloned a very large repository on OS X and want to move that to Windows
> (trying to avoid to clone the repository a second time). What steps should I
> do to make it working (currently, I'm getting an error on pull/merge that
> "Entry 'foo' is not uptodate. Cannot merge.")?
Check the git documentation for "core.filemode" and "core.autocrlf".
My guess is that you need to set core.filemode false.
If it's not that then look into core.autocrlf.
Good luck,
--
David
^ permalink raw reply
* Re: gitk : french translation
From: Emmanuel Trillaud @ 2009-11-11 17:10 UTC (permalink / raw)
To: Thomas Moulard
Cc: Nicolas Sebrecht, Maximilien Noal, Matthieu Moy, Nicolas Pitre,
Guy Brand, Git Mailing List
In-Reply-To: <g1w6apsyubgonjhsvjUYAxe124vaj_firegpg@mail.gmail.com>
Thank you, Nicolas & Thomas for your reviews and suggestions. I will
submit a new version of the translation tonight or tomorow depending
on the time I have.
Best Regards
Emmanuel T
^ permalink raw reply
* Working on merged branches whilst seeing current master
From: rhlee @ 2009-11-11 17:16 UTC (permalink / raw)
To: git
Hi again gits,
I think my current query is somewhat related to my previous issue of
"Preserving branches after merging on ancestor" that you help me with last
time (many thanks).
I use branches for features. I have a branch and I merged it into my master
branch as I thought it was finished. But it turns out I wasn't and so I need
to work on it again.
I have made some more changes (branches and merges) on master. So what I
should do is checkout that branch, work on it committing along the way and
then merge it again onto my master branch.
However I though I am working on a feature branch I want to be also working
from the master branch as reference. Yes I know I probably should not be
working like this. My branches should be wholly independent. But I doing web
development not kernel development so there is much less modularity and
branches/features have a tendency to creep into one another. If you want to
get and idea of my workflow see my thread last week "Preserving branches
after merging on ancestor".
So how do I work again on a branch that has been preiously merged whilst
"seeing" the current changes on the master or another branch?
Is this a bad idea first of all. Should I change my workflow instead?
If I do try to do this I guess I got several ways.
I think I could pull(?) or merge the changes so far from the master branch
into the feature branch. But this seems like an uneccesary duplication.
Or should I just create a new branch? But if I do this there is no link
between the old and new branch.
Richard
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3987667.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: BUG: git rebase -i -p silently looses commits
From: Johannes Schindelin @ 2009-11-11 17:32 UTC (permalink / raw)
To: Greg Price; +Cc: Constantine Plotnikov, git
In-Reply-To: <20091104214611.GL9139@dr-wily.mit.edu>
Hi,
On Wed, 4 Nov 2009, Greg Price wrote:
> On Mon, 2 Nov 2009, Johannes Schindelin wrote:
> > Having said that, I worked for some time on fixing this issue, and I
> > actually run a version of rebase -i -p here that allows reordering
> > commits, but it is far from stable (and due to GSoC and day-job
> > obligations, I had no time to work on it in months).
>
> I'm interested in this topic too. Some weeks ago I took your
> rebase-i-p branch from January and rebased it onto the latest release;
> it's at
> git://repo.or.cz/git/price.git rebase-i-p
> and now based on v1.6.5.2. I fixed a few bugs and added a feature,
> and it's the version I run day to day.
That is very interesting!
However, for rebase-i-p to have a chance to be accepted, I think a few
things are necessary still (this is all from memory, so please take
everything with a grain of salt):
- reorder the series to have the -i fixes first, the new commands next,
and then the changes to the actual -p mode
- rework the mark stuff so that 'todo' works properly, and then change the
system to use ':<name>' style bookmarks.
- fix that nasty bug which makes one revision not pass the tests (I forgot
which one, but it should be in the TODOs)
- add proper handling for the case when a patch has been applied in
upstream already, but was not correctly identified as that by
--cherry-pick (well, this TODO is actually not really related to rebase
-i -p, but something I deeply care about)
Unfortunately, I am getting more and more deprived of Git time budget
these days, so that I cannot seem to find a few hours to at least restart
my efforts.
Ciao,
Dscho
^ permalink raw reply
* Re: excerpts from tomorrow's "What's cooking" draft
From: Sverre Rabbelier @ 2009-11-11 17:57 UTC (permalink / raw)
To: Junio C Hamano, Daniel Barkalow; +Cc: git
In-Reply-To: <7vbpj9s8vk.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Nov 11, 2009 at 10:34, Junio C Hamano <junio@pobox.com> wrote:
> * sr/gfi-options (2009-09-06) 6 commits.
> - fast-import: test the new option command
> - ...
> - fast-import: put option parsing code in separate functions
>
> It seemed to be moving again soon, but nothing has happened yet...
I ran out of git time due to the start of my uni's next quarter, this
is next on my to-do list though, as my remote helper depends on it.
> * sr/vcs-helper (2009-11-06) 12 commits
> - Add Python support library for remote helpers
> - ...
> - Fix memory leak in helper method for disconnect
>
> Re-rolled series that contains Daniel's and Johan's.
> Any comments? Is everybody happy?
Daniel, are you going to send a follow-up to the memory-leaking patch?
If not, this needs to stay out of next until I have time to do so. My
gitdir patch might need to be evicted as it is connected to
sr/gfi-options which is not yet done. Also, we need to update the
documentation, but I think we can at least start cooking it in next
without these documentation updates?
> * ks/precompute-completion (2009-10-26) 3 commits.
> (merged to 'next' on 2009-10-28 at cd5177f)
> + completion: ignore custom merge strategies when pre-generating
> (merged to 'next' on 2009-10-22 at f46a28a)
> + bug: precomputed completion includes scripts sources
> (merged to 'next' on 2009-10-14 at adf722a)
> + Speedup bash completion loading
>
> What's the status of this thing? Last time I polled the list I had an
> impression that it was not quite ready...
Does the current version require me to 'cd contrib/completion && make'
each time we update completion? If so, that's a (very annoying)
regression that needs to be fixed before it's merged to master IMHO.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v4 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Junio C Hamano @ 2009-11-11 18:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Thomas Rast, git, Junio C Hamano
In-Reply-To: <4AFA7624.5040400@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> In the snippet above, dashdash will always be set to "--" because a mere
> '+' in the variable expansion only tests whether the variable ('nonrevs')
> is unset, but it is always set. Even ${nonrevs:+"--"} is wrong, and your
> earlier 'test -z' invocation was the correct way to set dashdash.
I do not mind "test -z", so this is just for information, but you could
use variable substitution with a colon, i.e. ${nonrevs:+"--"}.
IIRC, the colon-form ("do this if unset or empty") wasn't understood by
ancient BSDs but these days it is safe to use.
^ permalink raw reply
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