headers
Jiang Xin | 2 Jul 2012 03:43
Picon
Gravatar

Please pull git-po maint branch with Swedish update

Hi Junio,

Please merge the maint branch of git-l10n, and then merge back to the
master branch.

The following changes since commit 0ce2e396ee9fb0fa07e8381b338e49859dbf03db:

  Git 1.7.11 (2012-06-17 14:07:15 -0700)

are available in the git repository at:

  git://github.com/git-l10n/git-po maint

for you to fetch changes up to 16b183094e7c93e194bc2c471e95fe3386e6fb69:

  Update Swedish translation (1066t0f0u) (2012-07-01 23:04:09 +0100)

----------------------------------------------------------------
Peter Krefting (1):
      Update Swedish translation (1066t0f0u)

 po/sv.po | 3078 ++++++++++++++++++++++++++++++++++++++++++++++++--------------
 1 file changed, 2393 insertions(+), 685 deletions(-)

--
JIang Xin
Permalink | Reply | 1 comment |
headers
Junio C Hamano | 2 Jul 2012 09:10
Picon
Picon
Favicon
Gravatar

Re: MERGE_RR droppings

David Aguilar <davvid <at> gmail.com> writes:

> We can have a "default" unmerged files provider that does the
> `test -s .../MERGE_RR` check since that would probably deal with
> this ugly edge case.
>
> We can then teach this default thing to be smarter and skip text files
> with no merge markers. Junio, is this what you were thinking?
> This sounds like a nice way to me.

I am not sure what I were thinking ;-) so let me think aloud.

In any case, once the user says (either via directly using "git add"
or using the command via the mergetool) the path is resolved,
mergetool would no longer want to touch it, until the user says
"oops, the resolution was a mistake; pleae make it unresolved again"
with something like "git checkout -m".  So in this message, I'll
think only about the case where the index is still unmerged.

The working tree files may be in one of these states:

 1. It may still be the same as the conflicted state after the
    three-way merge proper gave the user, perhaps with conflict
    markers in the text.

 2. rerere or some other mechanism (this includes manual editing or
    previous run of "mergetool") may have resolved the conflict
    fully.

 3. Or such a mechanism may have only half-resolved the conflict.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Junio C Hamano | 2 Jul 2012 09:17
Picon
Picon
Favicon
Gravatar

Re: git blame gives an ambiguous short revision

Julia Lawall <julia.lawall <at> lip6.fr> writes:

> Using linux-next cloned today (July 1), I then checkout out the
> revision 60d5c9f5b.  The command
>
> git blame drivers/staging/brcm80211/brcmfmac/wl_iw.c -L3675,3675
>
> then gives:
>
> 60d5c9f5 (Julia Lawall 2011-04-01 16:23:42 +0200 3675)  if (!iscan->iscan_ex_params_p) {
>
> Then I try:
>
> git show 60d5c9f5
>
> which gives:
>
> error: short SHA1 60d5c9f5 is ambiguous.
> error: short SHA1 60d5c9f5 is ambiguous.
> fatal: ambiguous argument '60d5c9f5': unknown revision or path not in the
> working tree.
> Use '--' to separate paths from revisions
>
> If I give git blame the -l option, every thing is fine.

Or you can use --abbrev to explicitly set the width; as the length
necessary to make the abbreviated object names depends on the
project, there is no good default.

I think it should be an easy patch to add a post-processing phase
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kevin | 2 Jul 2012 09:17
Gravatar

Re: [bug report, possibly] Multiple pushes with passwords in URL

Hi,

First, this is the right place for reporting bugs.

I don't know why it's using the credentials for the first remote. But I know
that recent versions of git ship a credentials[1] helper that can ask a wallet
or keychain for credentials, so you don't have to store them in the git
config.

Kevin

[1]: http://git-scm.com/docs/gitcredentials

On Tue, Jun 26, 2012 at 8:43 PM, Left Right <olegsivokon <at> gmail.com> wrote:
> Hello list,
> I didn't find a bug tracker and some comments on StackOverflow
> suggested I should post to the mailing list... please excuse me if I
> followed the wrong info, it's not really easy to find your bug
> tracker, if there is one.
>
> I've came across this behavior trying to organize my repository to
> push updates to several remote repositories. Here's what I did:
>
> in .git/conf
>
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
(Continue reading)

Permalink | Reply | 1 comment |
headers
Junio C Hamano | 2 Jul 2012 09:28
Picon
Picon
Favicon
Gravatar

Re: git blame gives an ambiguous short revision

Junio C Hamano <gitster <at> pobox.com> writes:

> I think it should be an easy patch to add a post-processing phase
> after all lines are blamed to automatically compute an appropriate
> value of abbreviation to ensure the uniqueness, but the current
> blame output does not bother to do so.

Something like this, perhaps, but I didn't test the patch beyond "it
compiles".

 builtin/blame.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/builtin/blame.c b/builtin/blame.c
index 24d3dd5..960c58d 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
 <at>  <at>  -1837,6 +1837,16  <at>  <at>  static int read_ancestry(const char *graft_file)
 	return 0;
 }

+static int update_auto_abbrev(int auto_abbrev, struct origin *suspect)
+{
+	const char *uniq = find_unique_abbrev(suspect->commit->object.sha1,
+					      auto_abbrev);
+	int len = strlen(uniq);
+	if (auto_abbrev < len)
+		return len;
+	return auto_abbrev;
+}
(Continue reading)

Permalink | Reply | 1 comment |
headers
Junio C Hamano | 2 Jul 2012 09:54
Picon
Picon
Favicon
Gravatar

Re: git blame gives an ambiguous short revision

Junio C Hamano <gitster <at> pobox.com> writes:

> Something like this, perhaps, but I didn't test the patch beyond "it
> compiles".

OK, now I tested it ;-)  I'll queue this and eventually merge down
to older maintenance releases.

-- >8 --
Subject: [PATCH] blame: compute abbreviation width that ensures uniqueness

Julia Lawall noticed that in linux-next repository the commit object
60d5c9f5 (shown with the default abbreviation width baked into "git
blame") in output from

  $ git blame -L 3675,3675 60d5c9f5b -- \
      drivers/staging/brcm80211/brcmfmac/wl_iw.c

is no longer unique in the repository, which results in "short SHA1
60d5c9f5 is ambiguous".

Compute the minimum abbreviation width that ensures uniqueness when
the user did not specify the --abbrev option to avoid this.

Signed-off-by: Junio C Hamano <gitster <at> pobox.com>
---

Incidentally, "git show v2.6.39-rc4-181-g60d5c9f5" is resolved
correctly with the recent "prolong the shelf-life of decribed name"
topic that will hopefully be ready by the next release, and it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Junio C Hamano | 2 Jul 2012 10:22
Picon
Picon
Favicon
Gravatar

Re: git submodule vs GIT_WORK_TREE

Richard Hartmann <richih.mailinglist <at> gmail.com> writes:

> First of all, thanks for your detailed analysis; it cleared things up
> for me quite a bit.
>
> I am not sure if this would work in all cases, but let's assume there
> is a new GIT_WORK_ROOT which will always point to the top level of a
> given repository (it would stay the same for submodules, as well).

I do not think such a variable is necessary, and I do not think it
helps anything either.

As a submodule is an independent project and does not care if it is
embedded inside another project (i.e. superproject), when you are
working in $HOME/a/b repository (going back to the example in the
previous message), whether using b/.git or GIT_WORK_TREE=$HOME/a/b
as the clue to mark the root of the working tree of the project you
are working in, there is no reason for Git to figure out that there
is a containing superproject at $HOME/a, let alone that its
controlling repository is at $HOME/a/.git (or somewhere else).

The problem is going the other way around.

When you are working in the superproject, i.e. $HOME/a, there is a
need to know when you cross the project boundary at $HOME/a/b (and
if you know $HOME/a/b is the project boundary, that automatically
means $HOME/a/b is the root level of the working tree of the other
project, so Git with "--recursive" option _ought_ to be aboe to
export GIT_WORK_TREE one it goes into the working tree of the
submodule without anything else).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Left Right | 2 Jul 2012 11:09
Picon

Re: [bug report, possibly] Multiple pushes with passwords in URL

I have Git version 1.7.2.5 (this is what Debian repository provides), so

$ git help -a | grep credential-

doesn't find anything. But thanks, I've put that page into favorites.
Once there will be a newer version, I'll try that.

Best.

Oleg
Permalink | Reply | 0 comments |
headers
Jonathan Nieder | 2 Jul 2012 13:07
Picon

Re: [RFC 1/4 v2] Implement a basic remote helper for svn in C.

Hi,

Florian Achleitner wrote:

> Experimental implementation.

Ok, so this adds a new program named "remote-svn".  How do I build it?
What does it do?  Will it make my life better?

[...]
> diff: Use fifo instead of pipe: Retrieve the name of the pipe from env and open it
> for svndump.

I'd prefer to avoid this if possible, since it means having to decide
where the pipe goes on the filesystem.  Can you summarize the
discussion in the commit message so future readers understand why
we're doing it?

[...]
> --- /dev/null
> +++ b/contrib/svn-fe/remote-svn.c
>  <at>  <at>  -0,0 +1,207  <at>  <at> 
> +
> +#include <stdlib.h>
> +#include <string.h>
> +#include <stdio.h>

git-compat-util.h (or some header that includes it) must be the first
header included so the appropriate feature test macros can be defined.
See Documentation/CodingGuidelines for more on that.
(Continue reading)

Permalink | Reply | 22 comments |
headers
Torben Hohn | 2 Jul 2012 14:47
Picon

corner case with rename tracking and reverts


Hi...

i just came over some issue, where the rename tracking got confused.

I wanted to revert a commit to a moved file. But because it touched an
empty file, this seems to have confused the rename tracking.
(there were a few empty files there)

Attached is a shell script, that reproduces the issue.

The Problem is, that bla2 shows up in omg3, when "bla2 empty" is
reverted.

This was produced with git 1.7.10 from debian.

--

-- 
Mit freundlichen Grüßen
Torben Hohn

Linutronix GmbH

Standort: Bremen

Phone: +49 421 166 73 41 ; Fax.: +49 7556 919 886
mailto: torbenh <at> linutronix.de
Firmensitz / Registered Office: D-88690 Uhldingen, Auf dem Berg 3
Registergericht / Local District Court: Freiburg i. Br., HRB Nr. / Trade
register no.: 700 806;
(Continue reading)

Permalink | Reply | 1 comment |

Gmane