[L10N] Kickoff of translation for Git 2.4.0 round 1

Hi, Git v2.4.0-rc0 is released, and it's time to start new round of git l10n. This time there are 99 updated messages need to be translated since last update for v2.3.0: l10n: git.pot: v2.4.0 round 1 (99 new, 92 removed) Generate po/git.pot from v2.4.0-rc0 for git v2.4.0 l10n round 1.

Re: [PATCH 0/2] git-p4: Small updates to test cases

On Fri, 27 Mar 2015 at 01:26 Junio C Hamano wrote: >As to 1/2 the lack of esac is clearly a bug---any self respecting >POSIX shell should have executed it without complaining. But >changing from ':' to true should not be necessary---after all, the >colon is a more traditional way to spell true to

Re: [PATCH 0/2] git-p4: Small updates to test cases

Junio C Hamano writes: > As to 1/2 the lack of esac is clearly a bug---any self respecting > POSIX shell should have executed it without complaining. But s/should/shouldn't/; sorry for a noise. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord.

Re: [PATCH 0/2] git-p4: Small updates to test cases

Vitor Antunes writes: > This patch set includes two small fixes to the rename test case. The fix to > support dash should be trivial, but in the fix to the copy detection test case > it isn't obvious to me what changed in diff-tree to result in a different file > being detected as the origin of a

[PATCH 2/2] git-p4: Fix copy detection test

File file11 is copied from file2 and diff-tree correctly reports this file as its the source, but the test expression was checking for file10 instead (which was a file that also originated from file2). It is possible that the diff-tree algorithm was updated in recent versions, which resulted in thi

[PATCH 1/2] git-p4: Make rename test case runnable under dash

Signed-off-by: Vitor Antunes --- t/t9814-git-p4-rename.sh |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh index 95f4421..24008ff 100755 --- a/t/t9814-git-p4-rename.sh +++ b/t/t9814-git-p4-rename.sh @@ -178,9 +178,

[PATCH 0/2] git-p4: Small updates to test cases

This patch set includes two small fixes to the rename test case. The fix to support dash should be trivial, but in the fix to the copy detection test case it isn't obvious to me what changed in diff-tree to result in a different file being detected as the origin of a copy. Vitor Antunes (2): git

Re: [PATCH 5/5] gitweb: make category headings into links when they are directories

> On 26 Mar 2015, at 19:49, Junio C Hamano wrote: > > Any comments from those who use or have their own code in Gitweb on > this topic? Thanks for chasing up my patches. I should have written a covering letter, to say that you can see these patches in action at https://git.csx.cam.ac.uk/x/ucs

Re: [PATCH V2/RFC][GSoC] diff-no-index: transform "$directory $file" args to "$directory/$file $file"

Yurii Shevtsov writes: > git diff --no-index refuses to compare if args are directory and file, > instead of usual diff. > > Now git diff --no-index modifies args, if they're directory and file, > and diffs files, as usual diff does. > > Changes are done in diff_no_index(). > > Helped-by: Junio C

Re: [PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree

On Thu, Mar 26, 2015 at 07:04:24PM +0700, Nguyễn Thái Ngọc Duy wrote: > When you define $GIT_DIR/info/config.worktree, which contains of > gitignore-style patterns (*), config variables that match these > patterns will be saved in $GIT_DIR/config.worktree instead of > $GIT_DIR/config. Should it ra

Re: [RFC] git submodule purge

Am 26.03.2015 um 14:30 schrieb Patrick Steinhardt: On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote: Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt: Optionally I could implement `git gc --purge-submodule=` as a second way to access the feature so that we have a way of purging the

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Am 26.03.2015 um 22:17 schrieb Sergey Organov: Junio C Hamano writes: There however were repeated wishes (or wishful misunderstandings ;-) that there were a mode to rebuild the trunk, considering only the commits on the first-parent chain as "commits to be rebased", recreating the history by re

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Junio C Hamano writes: [...] > I think the current preserve-merges considers everything between > and as "commits to be rebased", and recreate > merges across these rebased tips of branches that are merged. > > There however were repeated wishes (or wishful misunderstandings ;-) > that there w

[ANNOUNCE] Git v2.4.0-rc0

An early preview release Git v2.4.0-rc0 is now available for testing at the usual places. This cycle is turning out to be a "product excellence" release---majority of the changes are bugfixes, about one-third of which are also already in the v2.3.x maintenance track. The tarballs are found at:

What's cooking in git.git (Mar 2015, #09; Thu, 26)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Good news is that a few GSoC Microprojects have been merged already to 'master'; from my vague recollection of past years, perhaps this year's b

Dr Harry Thomas

Dr Harry Thomas Brondesbury, North West Londyn Anglia Drogi Przyjacielu.   Jestem dr Harry Thomas z Brondesbury, North West London, tutaj w Anglii. Pracuję dla UBS Investment Bank Londyn. Piszę wam o propozycji biznesowych, które będą z ogromną korzyścią dla nas obu. W moim departamencie, j

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Sebastian Schuberth writes: >> Instead of flattening the history by replaying each >> non-merge commit to be rebased, preserve the shape of the >> rebased history by recreating merge commits as well. >> >> or something along that line, perhaps? > > Hm, I'm not sure about the "as we

[PATCH V2/RFC][GSoC] diff-no-index: transform "$directory $file" args to "$directory/$file $file"

git diff --no-index refuses to compare if args are directory and file, instead of usual diff. Now git diff --no-index modifies args, if they're directory and file, and diffs files, as usual diff does. Changes are done in diff_no_index(). Helped-by: Junio C Hamano Signed-off-by: Yurii Shevtsov

[PATCH] Fix two typos

Signed-off-by: Thomas Ackermann --- Documentation/RelNotes/2.4.0.txt | 2 +- Documentation/technical/api-error-handling.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/RelNotes/2.4.0.txt b/Documentation/RelNotes/2.4.0.txt index 386c75d..cdfd

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

On 26.03.2015 19:18, Junio C Hamano wrote: Also, do not say that merge commits are *tried* to be recreated. Good point. "We will try but it might fail" is better left unsaid as that is true almost everywhere. Exactly. -p:: --preserve-merges:: -Instead of ignoring merges, try to re

Re: [PATCH] docs: Clarify "preserve" option wording for git-pull

Thanks; this time I do not see whitespace breakages ;-) Will queue with a minimum tweak of the log message. -- 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] docs: Clarify "preserve" option wording for git-pull

Before this path, the "also" sounded as if "preserve" was doing a rebase as additional work that "true" would not do. Clarify this by omitting the "also" and rewording the sentence a bit. Signed-off-by: Sebastian Schuberth --- Documentation/git-pull.txt | 5 ++--- 1 file changed, 2 insertions(+)

Re: [PATCH 5/5] gitweb: make category headings into links when they are directories

Any comments from those who use or have their own code in Gitweb on this topic? * tf/gitweb-project-listing (2015-03-19) 5 commits - gitweb: make category headings into links when they are directories - gitweb: optionally set project category from its pathname - gitweb: add a link under the sea

Re: [PATCH] git-push.txt: clean up force-with-lease wording

Phil Hord writes: > The help text for the --force-with-lease option to git-push > does not parse cleanly. Clean up the wording and syntax to > be more sensible. Also remove redundant information in the > "--force-with-lease alone" description. > > Signed-off-by: Phil Hord > --- Thanks. The u

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Sebastian Schuberth writes: > Also, do not say that merge commits are *tried* to be recreated. Good point. "We will try but it might fail" is better left unsaid as that is true almost everywhere. > Signed-off-by: Sebastian Schuberth > --- > Documentation/git-rebase.txt | 2 +- > 1 file chan

Re: [PATCH] docs: Clarify "preserve" option wording for git-pull

Sebastian Schuberth writes: > Before this path, the "also" sounded as if "preserve" was doing a rebase > as additional work that "true" would not do. Clarify this by saying > "still" instead of "also". I agree that the original "also" is confusing. I however wonder if we even want "still", thou

Re: [PATCH v2] gc: save log from daemonized gc --auto and print it next time

Nguyễn Thái Ngọc Duy writes: > While commit 9f673f9 (gc: config option for running --auto in > background - 2014-02-08) helps reduce some complaints about 'gc > --auto' hogging the terminal, it creates another set of problems. > > The latest in this set is, as the result of daemonizing, stderr i

Re: [PATCH] clone: Warn if clone lacks LICENSE or COPYING file

On Sat, Mar 21, 2015 at 02:06:33PM -0400, David A. Wheeler wrote: > Warn cloners if there is no LICENSE* or COPYING* file that makes > the license clear. This is a useful warning, because if there is > no license somewhere, then local copyright laws (which forbid many uses) > and terms of service

Re: [RFC/GSoC] Proposal Draft: Unifying git branch -l, git tag -l, and git for-each-ref

On Mon, Mar 23, 2015 at 06:39:20PM +0530, karthik nayak wrote: > All three commands select a subset of the repository’s refs and print the > result. There has been an attempt to unify these commands by Jeff King[3]. I > plan on continuing his work[4] and using his approach to tackle this > project

Re: About GSoc idea.

On Wed, Mar 25, 2015 at 08:36:41PM +0530, Shanti Swarup Tunga wrote: > Duy Nguyen and Stephen Robin , the two developers worked > on converting git-pull.sh to C code . But in the idea page it is > written that we should start with git-pull.sh. Should I worked on > "git-pull.sh" or othe

Re: What's cooking in git.git (Mar 2015, #08; Mon, 23)

On Tue, Mar 24, 2015 at 03:21:24PM -0700, Junio C Hamano wrote: > > * pw/remote-set-url-fetch (2014-11-26) 1 commit > > - remote: add --fetch and --both options to set-url > > This has not seen any activity for a few months since $gmane/261483; > is anybody still interested in resurrecting it?

Re: [RFH/PATCH] git-svn: adjust info to svn 1.7 and 1.8

Michael J Gruber venit, vidit, dixit 24.03.2015 16:10: > t9119 refuses to run with svn versions greater than 1.6 since "git svn > info" does not even try to match the output of "svn info" for later > versions. > > Adjust "git svn info" to match these versions and make t9119 run with > them. This r

[PATCH] git-push.txt: clean up force-with-lease wording

The help text for the --force-with-lease option to git-push does not parse cleanly. Clean up the wording and syntax to be more sensible. Also remove redundant information in the "--force-with-lease alone" description. Signed-off-by: Phil Hord --- Documentation/git-push.txt | 14 ++

Re: A good time to pull from your gitk tree?

On 15-03-24 07:06 PM, Paul Mackerras wrote: > On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote: >> >> Is it a good time for me to pull from you, or do you recommend me to >> wait for a bit, expecting more? We'll go in the pre-release freeze >> soon-ish, so I thought I should ping. >

Re: [PATCH] merge: deprecate 'git merge HEAD ' syntax

On Thu, Mar 26, 2015 at 12:58 AM, Junio C Hamano wrote: > We had this in "git merge" manual for eternity: > > 'git merge' HEAD ... > > [This] syntax ( `HEAD` ...) is supported for > historical reasons. Do not use it from the command line or in > new scripts. It is the same as `g

Re: What's cooking in git.git (Sep 2014, #01; Tue, 2)

That’s great dear, can you share link for those cooking videos too. Actually I am a new learner and I need detailed information to execute everything properly. Thanks in advance for your help. -- View this message in context: http://git.661346.n2.nabble.com/What

Re: [RFC] git submodule purge

On Wed, Mar 25, 2015 at 08:47:59PM +0100, Jens Lehmann wrote: > Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt: > > On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote: > >> Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt: [snip] > >> Hmm, cmd_deinit() seems to cope with submodules re

Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME

Paul Tan writes: > On Wed, Mar 25, 2015 at 01:25:07PM -0700, Junio C Hamano wrote: >> Junio C Hamano writes: >> I've already queued the following and merged it to 'next'. > > Thanks Matthieu and Eric for your reviews, and Johannes for following up > on this. > > Will keep in view XDG support for

Re: [PATCH] merge: deprecate 'git merge HEAD ' syntax

On Wed, Mar 25, 2015 at 09:58:45PM -0700, Junio C Hamano wrote: > We had this in "git merge" manual for eternity: > > 'git merge' HEAD ... > > [This] syntax ( `HEAD` ...) is supported for > historical reasons. Do not use it from the command line or in > new scripts. It is the

[PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Ignoring a merge sounds like ignoring the changes a merge commit introduces altogether, as if the merge commit was skipped or dropped from history. But that is not what happens if this options is not specified. Instead, what happens is that the separate commits a merge commit introduces are replaye

[PATCH v2] config.c: split some variables to $GIT_DIR/config.worktree

When you define $GIT_DIR/info/config.worktree, which contains of gitignore-style patterns (*), config variables that match these patterns will be saved in $GIT_DIR/config.worktree instead of $GIT_DIR/config. On the surface, they are just like any other variables. You can read or modify them with `

Re: very weird behaviour with

Kirill Marchuk <62mkv mail.ru> writes: > > Hi everyone > > I'm totally stuck with a following problem: (censor cut) ... > > But I believe that it might be due to my total misunderstanding of something > > Anyway, I totally appreciate your help ! > > Thanks a lot > > Kirill, frustr

[PATCH] docs: Clarify "preserve" option wording for git-pull

Before this path, the "also" sounded as if "preserve" was doing a rebase as additional work that "true" would not do. Clarify this by saying "still" instead of "also". Signed-off-by: Sebastian Schuberth --- Documentation/git-pull.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) dif

[PATCH v2] gc: save log from daemonized gc --auto and print it next time

While commit 9f673f9 (gc: config option for running --auto in background - 2014-02-08) helps reduce some complaints about 'gc --auto' hogging the terminal, it creates another set of problems. The latest in this set is, as the result of daemonizing, stderr is closed and all warnings are lost. This

Re: [BUG] [PATCH] infinite loop due to broken symlink

On 25.3.2015 23:53 Michael Haggerty wrote: On 03/23/2015 05:04 PM, Petr Stodulka wrote: git goes into an infinite loop due to broken symlink (minimal reproducer [0]). Affected code is in function "resolve_ref_unsafe" in file refs.c - notice 'stat_ref'. There is comment about problem with race