* [PATCH] builtin/branch.c: Use ALLOC_GROW instead of alloc_nr and xrealloc.
From: Thiago Farina @ 2010-12-14 1:59 UTC (permalink / raw)
To: git
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin/branch.c | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 807355a..7f34fad 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -314,11 +314,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
}
/* Resize buffer */
- if (ref_list->index >= ref_list->alloc) {
- ref_list->alloc = alloc_nr(ref_list->alloc);
- ref_list->list = xrealloc(ref_list->list,
- ref_list->alloc * sizeof(struct ref_item));
- }
+ ALLOC_GROW(ref_list->list, ref_list->index + 1, ref_list->alloc);
/* Record the new item */
newitem = &(ref_list->list[ref_list->index++]);
--
1.7.3.2.343.g7d43d
^ permalink raw reply related
* Re: [PATCH] builtin/rm.c: Use ALLOG_GROW instead of alloc_nr and xrealloc.
From: Thiago Farina @ 2010-12-14 1:56 UTC (permalink / raw)
To: git
In-Reply-To: <a09428c75202974dc69b613ae3c2096d82e5a0ca.1292290546.git.tfransosi@gmail.com>
On Mon, Dec 13, 2010 at 11:37 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
> ---
> builtin/rm.c | 5 +----
> 1 files changed, 1 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/rm.c b/builtin/rm.c
> index c7b7bb3..faeedfc 100644
> --- a/builtin/rm.c
> +++ b/builtin/rm.c
> @@ -22,10 +22,7 @@ static struct {
>
> static void add_list(const char *name)
> {
> - if (list.nr >= list.alloc) {
> - list.alloc = alloc_nr(list.alloc);
> - list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
> - }
> + ALLOC_GROW(list.name, list.nr + 1, list.alloc);
> list.name[list.nr++] = name;
> }
>
Disregard this, as I made a typo in the subject. Sent another patch
with the subject typo fixed. Thanks.
^ permalink raw reply
* [PATCH] builtin/rm.c: Use ALLOC_GROW instead of alloc_nr and xrealloc.
From: Thiago Farina @ 2010-12-14 1:48 UTC (permalink / raw)
To: git
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin/rm.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index c7b7bb3..faeedfc 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -22,10 +22,7 @@ static struct {
static void add_list(const char *name)
{
- if (list.nr >= list.alloc) {
- list.alloc = alloc_nr(list.alloc);
- list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
- }
+ ALLOC_GROW(list.name, list.nr + 1, list.alloc);
list.name[list.nr++] = name;
}
--
1.7.3.2.343.g7d43d
^ permalink raw reply related
* [PATCH] builtin/rm.c: Use ALLOG_GROW instead of alloc_nr and xrealloc.
From: Thiago Farina @ 2010-12-14 1:37 UTC (permalink / raw)
To: git
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
---
builtin/rm.c | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index c7b7bb3..faeedfc 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -22,10 +22,7 @@ static struct {
static void add_list(const char *name)
{
- if (list.nr >= list.alloc) {
- list.alloc = alloc_nr(list.alloc);
- list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
- }
+ ALLOC_GROW(list.name, list.nr + 1, list.alloc);
list.name[list.nr++] = name;
}
--
1.7.3.2.343.g7d43d
^ permalink raw reply related
* Referring to other repositories
From: Maaartin @ 2010-12-14 1:03 UTC (permalink / raw)
To: git
I'm using multiple repositories corresponding to different projects. Currently,
all the projects reside in different subdirectories of the same directory, like
work/A
work/B
work/C
There are some dependencies like B and C depending on A. Until now, my git
knows nothing about it and it works fine, since most changes of A are
unimportant for B and C (as A is my general purpose code which doesn't change
much). There are three kinds of changes in A:
- unrelated changes completely irrelevant to the other projects (vast majority)
- changes made because of either B or C (sometimes)
- unrelated changes forcing updating B and/or C (very seldom)
Not keeping track about A in the other projects would be a problem if I was to
use git bisect. Having to checkout the corresponding version of A when checking
out an old version of B or C manually, is just an inconvenience, no real
problem.
I know about git submodule, however IIUIC it needs the other project to become
a subdirectory of the master, but I can hardly make A to subdirectory of both B
and C (I'm a poor Windows user, so no symlinks). I could make copies of A as
subdirectories, but having A thrice would be very impractical:
- I'd have to avoid modifying the copies instead of the master.
- All three versions would show up in my IDE.
- I'd have to keep them in sync.
So it looks like using submodules is no option, but I hope you tell me that I'm
wrong.
What other possibilities are there? For the normal use, I'd be happy with git
tracking the commit id of A somehow. I think I could do it by saving the output
of
GIT_DIR=/e/work/A git log --max-count=1 --format=format:%H
in a file using a pre-commit hook. Or is there a better way?
For git bisect (which I haven't used yet but I'm going to), I'd need a way to
check out the right version of A automatically, this could be done as part of
the command given to git bisect run, right?
^ permalink raw reply
* how to create a diff in old file new file format (for code reviews)
From: aerosmith @ 2010-12-14 0:07 UTC (permalink / raw)
To: git
Hi,
I am trying to create a diff such that the original file (entire file) is
saved something like file1.h.old and the new modified file as file1.h.new. I
have read the various options for git-diff* tools but could not find one
such utility. All I get is the removals and additions as a diff. Does anyone
know how to create one with the help the available git utils? The only
method that I can think of is to do everything manually. Any help w.r.t.
this is really appreciated. Thanks in advance.
--
View this message in context: http://git.661346.n2.nabble.com/how-to-create-a-diff-in-old-file-new-file-format-for-code-reviews-tp5832810p5832810.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Revert-style merge/Working tree-only checkout?
From: Yuriy Romanenko @ 2010-12-13 23:30 UTC (permalink / raw)
To: Git Mailing List
Hello,
I am somewhat new to Git and I keep running into having to accomplish
a certain task and reading through the documentation I can't seem to
find any way of doing this easily.
The problem is when branches diverge and I want to sync a branch to
another branch with full overwrite, but maintain history and maintain
separate branches.
For example, say there is a branch "master" and I create a branch "b1"
from master at some point. After this, there are 5 commits
(C1,C2,C3,C4,C5) to master and
17 commits to b1 (let's call them cb1, cb2, cb3, ..., cb17). Say I
want to create an 18-th commit to "b1" that makes it identical to the
C5 (current) state of master. Essentially a single commit wipe of
changes cb1 -> cb17 as well as application of C1->C5. So far I have
found one way of accomplishing this, but it is difficult, error prone,
slow and I just plain don't like it. I feel like there should be an
easier way.
What I currently do:
$ rm -rf *
$ git checkout -f master
$ tar -cvzf /tmp/master.tar.gz *
$ git checkout b1
$ rm -rf *
$ tar -xvzf /tmp/master.tar.gz
$ git add
$ git commit -a
$ git merge master
I've considered doing something like the following
$ git checkout b1
$ git revert b1~17..b1
$ git merge master
but it also seems wrong, and requires me to count the submits by hand,
which seems silly --> I'm not actually reverting anything. I don't
know if this would even work.
Any suggestions on how to accomplish this easier? Some sort of a
force-checkout that affects working tree only but not the index?
Thank you,
Yuriy
^ permalink raw reply
* Re: Splitting a repository but sharing the common parts of the object database
From: Jonathan Nieder @ 2010-12-13 23:25 UTC (permalink / raw)
To: Phillip Susi; +Cc: git, Stephen Bash
In-Reply-To: <4D06A98B.1060408@cfl.rr.com>
Phillip Susi wrote:
> Yes, -l looks like exactly what I need. Now I don't suppose there
> is a way to make it sticky so I don't have to remember to use it
> when repacking every time? :)
Maybe
[alias "repackfork"]
repack -a -d -f -l ...whatever other options are wanted...
^ permalink raw reply
* Re: Splitting a repository but sharing the common parts of the object database
From: Phillip Susi @ 2010-12-13 23:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20101213192053.GA30315@burratino>
On 12/13/2010 02:20 PM, Jonathan Nieder wrote:
> You might be interested in girocco's fork support. See
> http://repo.or.cz/w/girocco.git/blob/HEAD:/jobd/gc.sh for starters.
>
> (Yes, the short answer is "-l" but showing where I got that answer
> from seems a little easier. :))
Yes, -l looks like exactly what I need. Now I don't suppose there is a
way to make it sticky so I don't have to remember to use it when
repacking every time? :)
I checked the man page for git-config and it doesn't show an option that
sounds like it.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Yaroslav Halchenko @ 2010-12-13 22:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlj3txqsz.fsf@alter.siamese.dyndns.org>
On Mon, 13 Dec 2010, Junio C Hamano wrote:
> > hm -- read-tree sounded like yet another unknown to me feature of GIT I
> > was trying desperately to discover ;) unfortunately it doesn't produce a merge
> > for me
> Didn't I already say it makes sense only with --no-commit? IOW to shape
> the tree.
rright -- in my case --no-commit so I could remove the content before
committing.
> And in your use case I do not think you would even want to have a merge.
> Even if you run "git rm" to remove non-free stuff from the merge result,
> if you merged the history of 0.2 that contains non-free stuff you are not
> allowed to distribute (forbidden either by upstream or self-imposed dfsg,
> the reason does not matter), people who gets the merge commit can follow
> its second parent to grab the non-free stuff, no?
I see your point better now -- so it is yet another dimension of
"the feature".
as for non-free -- I probably should have been more precise --
non-DFSG (debian free software guidelines)-free ;) i.e.:
* free compiled,rendered materials, often binary blobs, without
sources (e.g. .dll's, pdfs etc)
* material under free but not DFSG-free licenses, etc
* if upstream repository already provides that 'non-free' material it
would not be much of my misdemeanor to keep them as well buried in the
repository history. What I care is to have a cleaned branch from
which I could git archive, and also which I could inspect in regards to
changes between releases without visually filtering all changes in
non-sources (e.g. those binary blobs) or irrelevant content.
if ever legal situation causes upstream to rewrite history to remove
them -- I will have to do that as well anyways :-/
Having an actual merge would be useful for making the explicit "bridge"
from upstream branch, thus '--no-commit -s theirs' with consecutive
cleaning before commit looks the way to go IMHO. But I see now
that I could possibly use read-tree at times if a real necessity comes
to prune non-distributable content, and then obviously I do not want to
drag upstream's illegal stuff along.
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Yaroslav Halchenko @ 2010-12-13 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbp4pz9hf.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]
On Mon, 13 Dec 2010, Junio C Hamano wrote:
> would make sense only if used with --no-commit.
> But for such a use case, "git read-tree -m -u 0.2" would work just as
> well, and discussion ended there ;-)
hm -- read-tree sounded like yet another unknown to me feature of GIT I
was trying desperately to discover ;) unfortunately it doesn't produce a merge
for me :-/ -- just a simple commit with the state taken from the other tree:
$> git read-tree -m -u origin/master
cached/staged changes: 179 changes
$> git commit -m 'blunt merge for -s theirs: -m -u origin/master '
[maint/0.5 b246251] blunt merge for -s theirs: -m -u origin/master
175 files changed, 9589 insertions(+), 4914 deletions(-)
create mode 100644 doc/pics/ex_curvefitting_bold.svg
create mode 100644 doc/pics/ex_curvefitting_searchlight.svg
...
$> git show HEAD^2
fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the working tree.
I am using git (Debian amd64): 1:1.7.2.3-2.1 (so it is 1.7.2.3)
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2010-12-13 22:15 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git
In-Reply-To: <20101213214628.GA13447@onerussian.com>
Yaroslav Halchenko <debian@onerussian.com> writes:
> On Mon, 13 Dec 2010, Junio C Hamano wrote:
>> would make sense only if used with --no-commit.
>
>> But for such a use case, "git read-tree -m -u 0.2" would work just as
>> well, and discussion ended there ;-)
>
> hm -- read-tree sounded like yet another unknown to me feature of GIT I
> was trying desperately to discover ;) unfortunately it doesn't produce a merge
> for me
Didn't I already say it makes sense only with --no-commit? IOW to shape
the tree.
And in your use case I do not think you would even want to have a merge.
Even if you run "git rm" to remove non-free stuff from the merge result,
if you merged the history of 0.2 that contains non-free stuff you are not
allowed to distribute (forbidden either by upstream or self-imposed dfsg,
the reason does not matter), people who gets the merge commit can follow
its second parent to grab the non-free stuff, no?
^ permalink raw reply
* Re: Re: [PATCH] git_getpass: fix ssh-askpass behaviour
From: hvoigt @ 2010-12-13 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Sulfrian, git
In-Reply-To: <7voc8q7bdv.fsf@alter.siamese.dyndns.org>
Hi,
On Sun, Dec 12, 2010 at 04:41:00PM -0800, Junio C Hamano wrote:
> Alexander Sulfrian <alexander@sulfrian.net> writes:
>
> > call ssh-askpass only if the display environment variable is also set
> > ---
>
> I do not use it at all so I don't know for sure, but doesn't this break
> OSX?
>
> 20f3490 (web--browse: fix Mac OS X GUI detection for 10.6, 2009-09-14)
>
> is an example that you can be fully graphical without having DISPLAY set
> in some environment. MinGW folks may want to chime in as well.
I am not sure about OSX because I just checked and there seems to be a
DISPLAY variable set which seems to be used to start a X session on
demand. But MinGW definitely has no DISPLAY variable set by default.
Additionally GIT_ASKPASS/SSH_ASKPASS does not have to be a graphical
tool does it? It could also be some program that looks up the password
from some secure database.
Cheers Heiko
^ permalink raw reply
* [PATCH v3] gitk: add menuitem for file checkout from this or parent commit
From: hvoigt @ 2010-12-13 21:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <20101211232324.GB3788@brick.ozlabs.ibm.com>
This is useful if a user wants to checkout a file from a certain
commit. This is equivalent to
git checkout $commit $file
and
git checkout $commit^ $file
Checkout of the first parent is useful in situations where you want to
checkout a file before some modification. In the patch view only the
modified filenames are shown. It is much quicker to select the commit
which modified the file and then choose the file from the patch view
compared to select the parent commit and then browse through the whole
tree to choose the file.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
On Sun, Dec 12, 2010 at 10:23:24AM +1100, Paul Mackerras wrote:
> Thanks for the patch. However, the commit message doesn't mention
> that the patch also adds the 'checkout from parent' menu item or why
> that's a useful thing to have. I like the 'checkout from this commit'
> thing but I don't immediately see why checking out from the first
> parent is so useful that we have to have it as a menu item, but
> checking out from other parents of a merge isn't.
Here is a new version of the patch with some added explanation why this
is useful in day to day use. I choose the first parent because in my
usecase I checkout single files by typically using non-merge commits.
Do you think there are usecases for second or other parent commits on
merge commits?
Cheers Heiko
gitk | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
index e82c6bf..e0dd94d 100755
--- a/gitk
+++ b/gitk
@@ -2522,6 +2522,8 @@ proc makewindow {} {
{mc "Highlight this only" command {flist_hl 1}}
{mc "External diff" command {external_diff}}
{mc "Blame parent commit" command {external_blame 1}}
+ {mc "Checkout from this commit" command {external_checkout}}
+ {mc "Checkout from parent commit" command {external_checkout 1}}
}
$flist_menu configure -tearoff 0
@@ -3558,6 +3560,20 @@ proc make_relative {f} {
}
proc external_blame {parent_idx {line {}}} {
+
+ set cmdline [list git gui blame]
+ if {$line ne {} && $line > 1} {
+ lappend cmdline "--line=$line"
+ }
+ run_command_on_selected_file $cmdline $parent_idx
+}
+
+proc external_checkout {{parent_idx 0}} {
+ set cmdline [list git checkout]
+ run_command_on_selected_file $cmdline $parent_idx
+}
+
+proc run_command_on_selected_file {cmdline parent_idx} {
global flist_menu_file gitdir
global nullid nullid2
global parentlist selectedline currentid
@@ -3573,17 +3589,13 @@ proc external_blame {parent_idx {line {}}} {
return
}
- set cmdline [list git gui blame]
- if {$line ne {} && $line > 1} {
- lappend cmdline "--line=$line"
- }
set f [file join [file dirname $gitdir] $flist_menu_file]
- # Unfortunately it seems git gui blame doesn't like
+ # Unfortunately some commands do not like
# being given an absolute path...
set f [make_relative $f]
lappend cmdline $base_commit $f
if {[catch {eval exec $cmdline &} err]} {
- error_popup "[mc "git gui blame: command failed:"] $err"
+ error_popup "[mc "$cmdline: command failed:"] $err"
}
}
--
1.7.2.3.msysgit.0.1.g5a65e
^ permalink raw reply related
* Re: git-send-email: add some short options and update documentation
From: Junio C Hamano @ 2010-12-13 21:47 UTC (permalink / raw)
To: Alejandro R. Sedeño; +Cc: git, Thomas Rast, Junio C Hamano
In-Reply-To: <4D067E19.1060904@mit.edu>
"Alejandro R. Sedeño" <asedeno@mit.edu> writes:
>> [PATCH 2/2] git-send-email: Add some short options
>
> Any more comments on this?
Not from me, other than that I am not overly interested myself.
^ permalink raw reply
* Re: Please pull gitk.git master branch
From: Junio C Hamano @ 2010-12-13 21:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alexandre Erwin Ittner, git
In-Reply-To: <20101213210317.GA10027@brick.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Sorry about the glitch. The renaming seems like the best idea, since
> all the other .po files have lowercase names.
Usually people spell language in lower and region in upper, e.g. ja_JP, so
to eyes trained in i18n renaming doesn't look very nice. I just wanted to
know that Tcl folks do not care about that ;-)
> If I apply this patch in my repo, is that going to cause problems in
> yours? Or, since the commit that adds this file is the head commit, I
> could just rewind it and reapply with the lowercase name. Do you see
> problems with that?
Either way is fine by me, as the merge I pushed out last night is only on
'pu' that is advertised as unstable.
Thanks.
^ permalink raw reply
* Re: Git SVN non-standard branch/tag/trunk layout
From: Stephen Bash @ 2010-12-13 21:23 UTC (permalink / raw)
To: Albert Krawczyk; +Cc: git
In-Reply-To: <002301cb9b09$e4eb2de0$aec189a0$@optusnet.com.au>
----- Original Message -----
> From: "Albert Krawczyk" <pro-logic@optusnet.com.au>
> To: "Stephen Bash" <bash@genarts.com>
> Cc: git@vger.kernel.org
> Sent: Monday, December 13, 2010 4:08:28 PM
> Subject: RE: Git SVN non-standard branch/tag/trunk layout
>
> >Project 2 is an interesting one because it looks like the trunk is at
> >the same level as branches/tags. If that's the case, the 'branches'
> >line above will work (it will treat >the trunk like any other branch
> >-- a very Git-like approach). Also note that those projects that
> >didn't have a 'trunk' directory in SVN I added a 'trunk' on the Git
> >side to keep things consistent -- this is completely optional.
> >
> >Once you get comfortable with the rules governing the config lines,
> >you can pretty much untangle any SVN layout.
>
> Thanks a lot! I thought this is what I had to do, and had through
> trial and (a lot of) error got to be very close. As far as I can see
> the only 'downside' of this approach is that you can't have the 'root'
> of the SVN repo checked out, you can only have the root of each
> project checked out, as they are all on their own ref.
I hadn't thought about it until now, but you could probably specify fetch=/:refs/remotes/svnroot to have a ref that is the root of the SVN repository... Might be worth a shot...
Stephen
^ permalink raw reply
* RE: Git SVN non-standard branch/tag/trunk layout
From: Albert Krawczyk @ 2010-12-13 21:08 UTC (permalink / raw)
To: 'Stephen Bash'; +Cc: git
In-Reply-To: <13731475.185564.1292250200171.JavaMail.root@mail.hq.genarts.com>
>Project 2 is an interesting one because it looks like the trunk is at the same level as branches/tags. If that's the case, the 'branches' line above will work (it will treat >the trunk like any other branch -- a very Git-like approach). Also note that those projects that didn't have a 'trunk' directory in SVN I added a 'trunk' on the Git side to >keep things consistent -- this is completely optional.
>
>Once you get comfortable with the rules governing the config lines, you can pretty much untangle any SVN layout.
>
>HTH,
>Stephen
Hi Stephen,
Thanks a lot! I thought this is what I had to do, and had through trial and (a lot of) error got to be very close. As far as I can see the only 'downside' of this approach is that you can't have the 'root' of the SVN repo checked out, you can only have the root of each project checked out, as they are all on their own ref.
Thanks again for clarifying that,
Albert
^ permalink raw reply
* Re: Please pull gitk.git master branch
From: Paul Mackerras @ 2010-12-13 21:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexandre Erwin Ittner, git
In-Reply-To: <7vbp4q5ddo.fsf@alter.siamese.dyndns.org>
On Sun, Dec 12, 2010 at 11:40:51PM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> -- >8 --
> From: Junio C Hamano <gitster@pobox.com>
> Date: Sun, 12 Dec 2010 23:27:21 -0800
> Subject: [PATCH] Rename po/pt_BR.po to po/pt_br.po
>
> The "msgfmt --tcl pt_BR.po" (at least on my box, GNU gettext 0.17) command
> generates pt_BR.msg, i.e. the country part gets downcased. The resulting
> runtime (i.e. Tcl i18n) happily reads from pt_br.msg when run with the
> runtime locale set with LANG=pt_BR and/or LC_ALL=pt_BR so it seems to be
> the expected behaviour.
>
> However, we seem to expect that the resulting file to be named pt_BR.msg,
> and try to generate and install it.
>
> Currently our Makefile uses $(wildcard po/*.po) to grab the source PO
> files, expects them to produce $(subst .po,.msg,$(ALL_POFILES)), and its
> dependency rule is set to use "%.msg : %.po" pattern, all of which need
> to be adjusted with downcasing from po to msg files; the poor-man's msgfmt
> script also needs to learn the same downcasing.
>
> Compared to that, renaming the input file to use lowercase countryname
> throughout the toolchain seems to be a lot cleaner solution to this
> glitch.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> po/{pt_BR.po => pt_br.po} | 0
> 1 files changed, 0 insertions(+), 0 deletions(-)
> rename po/{pt_BR.po => pt_br.po} (100%)
>
> diff --git a/po/pt_BR.po b/po/pt_br.po
> similarity index 100%
> rename from po/pt_BR.po
> rename to po/pt_br.po
Sorry about the glitch. The renaming seems like the best idea, since
all the other .po files have lowercase names. I was hoping to hear
Alexandre Erwin Ittner's opinion, though.
If I apply this patch in my repo, is that going to cause problems in
yours? Or, since the commit that adds this file is the head commit, I
could just rewind it and reapply with the lowercase name. Do you see
problems with that?
Paul.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2010-12-13 20:46 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git
In-Reply-To: <loom.20101213T194818-377@post.gmane.org>
Yaroslav Halchenko <debian@onerussian.com> writes:
> git checkout dfsg
> git merge --no-commit -s theirs 0.2
> # after all I do not, and must not have my modifications
> git rm -rf non-free-1 ... # probably would be scripted
> git commit
The other day I was talking with Shawn Pearce and said that "-s theirs"
would make sense only if used with --no-commit.
But for such a use case, "git read-tree -m -u 0.2" would work just as
well, and discussion ended there ;-)
^ permalink raw reply
* Re: git-send-email: add some short options and update documentation
From: "Alejandro R. Sedeño" @ 2010-12-13 20:12 UTC (permalink / raw)
To: "Alejandro R. Sedeño"; +Cc: git, Thomas Rast, Junio C Hamano
In-Reply-To: <1292006656-1264-1-git-send-email-asedeno@mit.edu>
On 12/10/2010 01:44 PM, Alejandro R. Sedeño wrote:
> Add short options that were mentioned in the thread to git-send-email,
> specifically:
>
> -n for --dry-run
> -f for --force
> -q for --quiet
>
> Since --force didn't have documentation in
> Documentation/git-send-email.txt, a separate commit adds some
> first.
>
> [PATCH 1/2] Add --force to git-send-email documentation
I see this has been pulled into master. Thanks, Junio.
> [PATCH 2/2] git-send-email: Add some short options
Any more comments on this?
-Alejandro
^ permalink raw reply
* Re: [PATCH/RFC] t800?-blame.sh: retitle uniquely
From: Jeff King @ 2010-12-13 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, git, Johannes Sixt
In-Reply-To: <7vfwu1zc0x.fsf@alter.siamese.dyndns.org>
On Mon, Dec 13, 2010 at 11:51:58AM -0800, Junio C Hamano wrote:
> > t7500-commit.sh
> > t7501-commit.sh
> > t7502-commit.sh
> > t7509-commit.sh
>
> t7509 seems to be about the authorship, so it is easy to rename it to
> t7509-commit-authorship or something, but unfortunately I do not see
> unifying theme in any of t750[012]. They test random things and there
> seem to be overlaps.
I read through them and came to the same conclusion.
> Perhaps somebody wants to consolidate these three into one?
I think this falls into my "would be nice if it had been written cleaner
in the first place, but is not worth the time to clean up" category. But
if somebody else is willing to work on it, I have no objection. :)
-Peff
^ permalink raw reply
* Re: Please pull gitk.git master branch
From: Andreas Schwab @ 2010-12-13 19:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Paul Mackerras, Alexandre Erwin Ittner, git
In-Reply-To: <AANLkTinPqDbvdG9r4UFcKq9BJSw4by4_hJdEN+0oUaJZ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Pardon my ignorance, what is BCP? None of the definitions I could find
> seemed likely.
http://en.wikipedia.org/wiki/Best_Current_Practice
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH/RFC] t800?-blame.sh: retitle uniquely
From: Junio C Hamano @ 2010-12-13 19:51 UTC (permalink / raw)
To: Michael J Gruber, Jeff King; +Cc: git, Johannes Sixt
In-Reply-To: <20101213170734.GA24736@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 13, 2010 at 05:12:29PM +0100, Michael J Gruber wrote:
>
>> On a related note to J6t's patch, how's the stance on unique titles?
>> Unique numbers are important for partial test runs, of course,
>> but unique titles help finding you way through the test.
>> There are more than the blame.sh ones.
>
> I don't think it is a big deal, but I did just 5 minutes ago get annoyed
> at:
>
> t7500-commit.sh
> t7501-commit.sh
> t7502-commit.sh
> t7509-commit.sh
t7509 seems to be about the authorship, so it is easy to rename it to
t7509-commit-authorship or something, but unfortunately I do not see
unifying theme in any of t750[012]. They test random things and there
seem to be overlaps.
Perhaps somebody wants to consolidate these three into one?
^ permalink raw reply
* Re: Splitting a repository but sharing the common parts of the object database
From: Stephen Bash @ 2010-12-13 19:50 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Phillip Susi
In-Reply-To: <20101213192053.GA30315@burratino>
----- Original Message -----
> From: "Jonathan Nieder" <jrnieder@gmail.com>
> To: "Phillip Susi" <psusi@cfl.rr.com>
> Cc: git@vger.kernel.org
> Sent: Monday, December 13, 2010 2:20:53 PM
> Subject: Re: Splitting a repository but sharing the common parts of the object database
> Hi Phillip,
>
> Phillip Susi wrote:
>
> > If I run a repack -a, then the new project has everything copied out
> > of the archive and into its new main pack, rather than continuing to
> > use the archive repository for old history, and just pack everything
> > since then. I guess I am looking for is somewhere between a full repack
> > and an incremental; a way to make repack -a discard existing local
> > packs, but to respect the alternate packs and omit objects they contain
> > from the new local pack.
>
> You might be interested in girocco's fork support. See
> http://repo.or.cz/w/girocco.git/blob/HEAD:/jobd/gc.sh for starters.
You might also be interested in Pro Git's entry on git-replace:
http://progit.org/2010/03/17/replace.html
It's a completely different approach than what you're suggesting, but might open up new and interesting avenues.
Stephen
^ 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