* 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: 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: 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: 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] [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: [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: 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: 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
* 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: 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
* 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: 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: 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: [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: [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: 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: 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
* [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: 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
* 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: commit log encoding [Was: [PATCH 1/2] tree-wide: fix typos "offest" -> "offset"]
From: Uwe Kleine-König @ 2009-11-11 14:13 UTC (permalink / raw)
To: Jiri Kosina; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0911111318260.15039@wotan.suse.de>
On Wed, Nov 11, 2009 at 01:19:32PM +0100, Jiri Kosina wrote:
> On Wed, 11 Nov 2009, Uwe Kleine-König wrote:
>
> > > Thanks for noticing, I had a bug in my git charset config for quite some
> > > time. Fixed it now.
> > Now my name is latin1 encoded. It should be utf-8, doesn't it?
>
> It's not latin1, it's iso-8859-2
For my name it makes no difference.
> which is what I use on my terminals.
> And git can handle that fine too (it stores the encoding together with the
> commit).
Ah, OK, that's news to me, but you're right. I have here:
~/gsrc/linux-2.6$ git cat-file commit 30ff0743f88a70f52a4de5ea5bcb1fd29bcfab2d
tree 6121d35bb2606878be636e897fa77cd51804d724
parent 916b7c73db593510d5c38706be2f2888981747ee
author Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de> 1256757064 +0100
committer Jiri Kosina <jkosina@suse.cz> 1257780224 +0100
encoding ISO-8859-2
tree-wide: fix typos "couter" -> "counter"
This patch was generated by
git grep -E -i -l 'couter' | xargs -r perl -p -i -e 's/couter/counter/'
Signed-off-by: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
So the remaining question is: Does the encoding specified in the
encoding "header" also apply to the other headers?
If yes[1] then there's a bug in git-shortlog
~/gsrc/linux-2.6$ git shortlog linus/master..trivial/for-next | grep Uwe
Uwe Kleine-K�nig (5):
(with linus/master = 799dd75b1a8380a967c929a4551895788c374b31,
trivial/for-next = 4030ec040a0e21fe9953da70eaa59ee7b4f2297b).
Best regards
Uwe
[1] git log linus/master..trivial/for-next looks OK, so I suspect it
does apply.
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: Unhelpful "branch.master.remote = <nickname>" advice?
From: Tomas Carnecky @ 2009-11-11 14:08 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1257945756.26362.79.camel@heerbeest>
On Nov 11, 2009, at 2:22 PM, Jan Nieuwenhuizen wrote:
> Hi,
>
> git pull -r*) URL says:
>
> If you often merge with the same branch, you may want to
> configure the following variables in your configuration
> file:
>
> branch.master.remote = <nickname>
> branch.master.merge = <remote-ref>
> remote.<nickname>.url = <url>
> remote.<nickname>.fetch = <refspec>
These are meant to be used with git-config(1):
git config branch.master.remote <nickname>
Or if you want to manually edit the config file, add this:
[branch "master"]
remote = <nickname>
etc.
>
> and after cut-and-pasting that into .git/config, replacing
> <foo> with values, I get
>
> $ git pull -r http://github.com/../../master
> fatal: bad config file line 17 in .git/config
>
> where line 17 is [without any indentation]
>
> branch.master.remote = eddy
>
> This is with git version version 1.6.3.3
>
> Greetings,
> Jan. -- who just finds out the uninstall target is missing?!?
> See attached.
Next time please send patches inline, it's easier to review them that
way.
>
> *) I've been wondering why GIT lacks a "update", ie
> pull-without-merge command. You almost never want
> to git pull /without/ -r?
As 'pull == fetch + merge' (pull -r == fetch + rebase), pull without
merge would be fetch.
tom
^ permalink raw reply
* Re: P4 Sync problem
From: Tor Arvid Lund @ 2009-11-11 13:54 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091111T131837-901@post.gmane.org>
On Wed, Nov 11, 2009 at 1:39 PM, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Tor Arvid Lund <torarvid <at> gmail.com> writes:
>
>
>> Well, I see what you're trying to do, but I would not want to see that
>> patch in the official script, because some (most?) people (myself, at
>> least) use git-p4 to clone single projects out of a perforce depot
>> that may contain many projects. I do this myself by doing:
>>
>> git p4 clone //depot/path/to/projectX <at> all
>>
>> I usually use one clientspec in perforce, and I do not want to change
>> that... With your patch, I would be in trouble since my clientspec
>> contains "//depot/..." (followed by a lot of lines starting with '-')
>
> Well, does this mean that if you try to sync the client in perforce (visual or
> command line), you will sync all the projects?
Yes, but I generally try to not use perforce, but git instead :-)
> In that case, git p4 will require significant effort to satisfy both of us :-)
> Unfortunatly, it seems I'm in minory group of git-p4 users...
I don't know, but if I were to guess, then yes, you probably are... If
you have a complex perforce client spec setup, then there may of
course be problems that git-p4 might not solve for you. Since nobody
has volunteered to implement the features you describe yet, I believe
that most of us git-p4 users have fairly simple client spec setups.
For me, most projects in p4 are such that I can give one root
directory to "git p4 sync", and it works for me. I of course have
several git projects that sync from the same p4 server (only with
different root dirs). In cases where you have dependencies between
such projects, you should maybe read about git submodules - or maybe
googles "repo" script (search for "google repo git"). I don't know
much about any of these, other than 'they exist, and seemingly try to
solve such issues' :-/
> i would propose to use both command-line arguments and a client spec
> to create a correct filter of what should be synced/cloned.
> BTW, it looks this script does not honor neither the order of paths
> in the spec (which can be important) nor mapping of the files to a local tree.
When you have a client spec like:
//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?
And no, git-p4 does not care about the local mappings, it reads only
the server part.
-Tor Arvid-
>> If you want to fix it, you might want to rename clientSpecDirs to
>> clientSpecEntries or something like that.
>
> For now, I just commented out two lines in the run() procedure:
> #if not p.endswith("/"):
> # p += "/"
>
>> Btw... Am I understanding correctly what it is you wish to accomplish?
>> I'm guessing that you have a perforce server with a client spec set
>> up, and you want to sync everything on the entire server according to
>> that client spec?
>
> yes. Client spec completely defines the project layout for me.
> It contains paths to some components that are mapped to the
> client working tree.
> Just if your CS contain
>
> //depot/path/to/projectX/... //CLIENT/...
>
>
>
> --
> 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
* Unhelpful "branch.master.remote = <nickname>" advice?
From: Jan Nieuwenhuizen @ 2009-11-11 13:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
Hi,
git pull -r*) URL says:
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch.master.remote = <nickname>
branch.master.merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
and after cut-and-pasting that into .git/config, replacing
<foo> with values, I get
$ git pull -r http://github.com/../../master
fatal: bad config file line 17 in .git/config
where line 17 is [without any indentation]
branch.master.remote = eddy
This is with git version version 1.6.3.3
Greetings,
Jan. -- who just finds out the uninstall target is missing?!?
See attached.
*) I've been wondering why GIT lacks a "update", ie
pull-without-merge command. You almost never want
to git pull /without/ -r?
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
[-- Attachment #2: 0001-Makefile-add-uninstall-target.-Fixes-elementary-good.patch --]
[-- Type: text/x-patch, Size: 3234 bytes --]
>From 5b5107e2887b11cab3a391bd550d30c7df68242f Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen <janneke@gnu.org>
Date: Wed, 11 Nov 2009 14:19:00 +0100
Subject: [PATCH] Makefile: add uninstall target. Fixes elementary good cleaning manners.
* Modified Makefile
* Modified gitk-git/Makefile
* Modified perl/Makefile
* Modified templates/Makefile
---
Makefile | 18 +++++++++++++++++-
gitk-git/Makefile | 2 ++
perl/Makefile | 2 +-
templates/Makefile | 5 +++++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 5d5976f..135c3ac 100644
--- a/Makefile
+++ b/Makefile
@@ -1781,7 +1781,23 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
+uninstall:
+ifndef NO_TCLTK
+ $(MAKE) -C gitk-git uninstall
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
### Maintainer's dist rules
@@ -1857,7 +1873,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
clean::
$(RM) gitk-wish po/*.msg
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
QUIET = @
endif
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
$(QUIET)$(MAKE) -f $(makfile) $@
clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+ -(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+ -(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+ -rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
--
1.6.3.3
^ permalink raw reply related
* Move repository from OS X to Windows
From: Thomas Singer @ 2009-11-11 13:32 UTC (permalink / raw)
To: git
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.")?
Thanks in advance,
Tom
^ 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