* Re: how to use git merge -s subtree?
From: Junio C Hamano @ 2008-01-07 21:04 UTC (permalink / raw)
To: Sean; +Cc: David Soria Parra, git
In-Reply-To: <BAYC1-PASMTP1079A31936B4563801537DAE4E0@CEZ.ICE>
Sean <seanlkml@sympatico.ca> writes:
> ... Asking for the history of a file does make
> sense. Through path limiting you can ask to see just the subset of history that
> touched a certain file or directory etc..
That's asking for the history of a _path_ (or subset defined by
paths, as in "what changes were made to paths under 'arch/'"),
which is very different from asking "I have B/foo.c -- show me
the history of that _file_".
Remember, David stated:
>> ... So you cannot do git-log B/foo.c as git doesnot know where
>> to search it as it thinks it is in /foo.c not in B/foo.c ...
Notice "as git does not know where to search it" part?
Think --- what does that "it" refer to in that sentence?
The statement is not about paths. If it were about paths, then
the output of "git log B/foo.c" does show what he wants. The
question "git log B/foo.c" asks is "what change were made to the
path at B/foo.c". The changes made to B/foo.c (i.e. what's
shown with the diff headers that begin with "--- a/B/foo.c") are
shown. The changes made to foo.c are not shown.
But that is different from what David is asking. He wants to
know what changes were made to B/foo.c or to foo.c, and wants to
make the choice between the two depend on commit. The reason
you think you can pick between foo.c and B/foo.c is because
there is an illusion that somehow there is an i-node like file
identity that is kept track of, and it is preserved across
renames and merges.
That's keeping track of the history of a _file_.
And as you know, git doesn't do that.
What git does is to keep track of the history of the whole tree,
but prune the parts that are not interesting away when you view
the history. And the pruning can be specified by _PATH_.
See the difference?
^ permalink raw reply
* [PATCH] slightly better auto gc message
From: Nicolas Pitre @ 2008-01-07 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-gc.c b/builtin-gc.c
index 799c263..ac34788 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -205,7 +205,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
prune = 0;
if (!need_to_gc())
return 0;
- fprintf(stderr, "Packing your repository for optimum "
+ fprintf(stderr, "Auto packing your repository for optimum "
"performance. You may also\n"
"run \"git gc\" manually. See "
"\"git help gc\" for more information.\n");
Nicolas
^ permalink raw reply related
* Re: RFC/RFH submodule handling in big setups
From: Finn Arne Gangstad @ 2008-01-07 21:07 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Junio C Hamano, git
In-Reply-To: <320075ff0801071208u1900bf76q2f0dc9cb0dc4318b@mail.gmail.com>
On Mon, Jan 07, 2008 at 08:08:38PM +0000, Nigel Magnay wrote:
> Do you currently use svn?
Currently we use CVS. It hurts a bit.
> This feels like the common technique of using svn:externals, where
> product1 has
> foo repo/foo/trunk
> os-abstraction-lib repo/os-abstraction-lib/trunk
>
> product2 has
> os-abstraction-lib repo/os-abstraction-lib/trunk
> log-merger repos/log-merger/trunk
>
> Where git (if I understand submodules correctly) can't do the above,
> because the links are to SHA1s rather than tags or names, so in svn
> terms it'd be something like
> os-abstraction-lib repo/os-abstraction-lib/trunk@xxx
> log-merger repos/log-merger/trunk@yyy
>
> At first I thought the option (4) you suggest (Manually push all
> sub-modules to some new branch before pushing the super-module) was
> going to be a pain - but actually I came to the conclusion it was
> actually better. In our svn world, commits to shared libraries (can)
> cause all hell to break loose - it'd actually be an advantage to have
> to promote changes into the supermodules (the products in our case).
With the way we envision using git, I don't think this is a
problem. Each supermodule decides what version of the shared library
it wants to use, and since git does not point to tags/branches in
submodules but to sha1s, there is nothing you can do to a submodule
that will cause any problems in a supermodule unless the supermodule
decides to use a new version.
I think we'd be perfectly happy to use detached HEADs in all
submodules, but there is no way to get that to work currently with
push and fetch, so I'm looking for some alternative.
- Finn Arne
^ permalink raw reply
* [PATCH] git-gui: Update glossary; update German translation
From: Christian Stimming @ 2008-01-07 21:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]
---
po/glossary/git-gui-glossary.pot | 6 +++++-
po/glossary/git-gui-glossary.txt | 1 +
2 files changed, 6 insertions(+), 1 deletions(-)
Additionally, I've updated the German translation, but due to fear of whitespace
mangling I'm just adding that patch and this one in the attached tarball. Hope that's ok.
Thanks a lot! - Christian
diff --git a/po/glossary/git-gui-glossary.pot b/po/glossary/git-gui-glossary.pot
index 48af803..40eb3e9 100644
--- a/po/glossary/git-gui-glossary.pot
+++ b/po/glossary/git-gui-glossary.pot
@@ -6,7 +6,7 @@
msgid ""
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2007-10-19 21:43+0200\n"
+"POT-Creation-Date: 2008-01-07 21:20+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
@@ -70,6 +70,10 @@ msgstr ""
msgid "fetch"
msgstr ""
+#. "One context of consecutive lines in a whole patch, which consists of many such hunks"
+msgid "hunk"
+msgstr ""
+
#. "A collection of files. The index is a stored version of your working tree."
msgid "index (in git-gui: staging area)"
msgstr ""
diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
index 500d0a0..9b31f69 100644
--- a/po/glossary/git-gui-glossary.txt
+++ b/po/glossary/git-gui-glossary.txt
@@ -12,6 +12,7 @@
"diff [verb]" ""
"fast forward merge" "A fast-forward is a special type of merge where you have a revision and you are merging another branch's changes that happen to be a descendant of what you have."
"fetch" "Fetching a branch means to get the branch's head from a remote repository, to find out which objects are missing from the local object database, and to get them, too."
+"hunk" "One context of consecutive lines in a whole patch, which consists of many such hunks"
"index (in git-gui: staging area)" "A collection of files. The index is a stored version of your working tree."
"merge [noun]" "A successful merge results in the creation of a new commit representing the result of the merge."
"merge [verb]" "To bring the contents of another branch into the current branch."
--
1.5.3.4.206.g58ba4
[-- Attachment #2: git-gui-Update-German-translation.tgz --]
[-- Type: application/x-tgz, Size: 2884 bytes --]
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Johannes Schindelin @ 2008-01-07 21:18 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Jeff King, Steffen Prohaska, Peter Karlsson, Git Mailing List,
msysgit
In-Reply-To: <200801072203.23938.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 777 bytes --]
Hi,
[msysGit Cc'ed, since it is massively concerned by this thread]
On Mon, 7 Jan 2008, Robin Rosenberg wrote:
> måndagen den 7 januari 2008 skrev du:
> > Problem. There is not a single "right". It really depends on the
> > project.
>
> Indeed, but the most common SCM's detect binary files automatically,
> either by suffix or content analysis, so I think that is what user's
> expect. It will be right for more projects that the current behaviour.
Steffen also fought for turning this on by default, but so far I resisted.
For a good reason: the primary user of msysGit for the moment is...
msysGit. And this project does not need CR for obvious reasons.
But I imagine that it makes sense for the Git installers. Colour me
no-longer-resisting.
Ciao,
Dscho
^ permalink raw reply
* Re: gitk dev branch: F5 gives error after commit
From: Paul Mackerras @ 2008-01-07 21:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <478258B6.20006@viscovery.net>
Johannes Sixt writes:
> I use the dev branch of gitk (on Windows), commit 476ca63 (gitk: Index
> [fnvr]highlights by id rather than row).
>
> 1. Start it with:
>
> gitk --all -300
>
> 2. Make a commit.
> 3. Hit F5. Here I see the error message:
>
> Error reading commits:
> fatal: bad revision '^-300'
This happens because I naively thought 'git rev-parse --revs-only'
would only give me SHA1 IDs. But in any case gitk (on the dev branch)
doesn't really do anything much to handle commit selection flags that
can't be turned into SHA1 IDs (possibly negated).
Thanks for testing. I'll fix it.
Paul.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-07 21:36 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Johannes Schindelin, Jeff King, Steffen Prohaska, Peter Karlsson,
Git Mailing List
In-Reply-To: <200801072203.23938.robin.rosenberg.lists@dewire.com>
On Mon, 7 Jan 2008, Robin Rosenberg wrote:
>
> Indeed, but the most common SCM's detect binary files automatically,
> either by suffix or content analysis, so I think that is what user's expect.
> It will be right for more projects that the current behaviour.
Yeah, I suspect it's not only the "expected" behavior, but people have had
years of getting used to the whole binary issue, and are much more likely
to expect binary corruption than to expect to have to worry about CRLF.
And while it's true that it probably doesn't matter at all as long as you
stay windows-only (and everything is CRLF), it's also true that (a) maybe
you don't necessarily even know that some day you might want to cast off
the shackles of MS and (b) even under Windows you do end up having some
strange tools end up using LF (ie you may be using some tools that were
just straight ports from Unix, and that write just LF).
So defaulting to (or asking) "autocrlf" at install time is probably the
safest thing, and then people can edit their global .gitconfig to turn it
off.
Linus
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-07 21:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Robin Rosenberg, Jeff King, Peter Karlsson, Git Mailing List,
msysgit
In-Reply-To: <alpine.LSU.1.00.0801072115120.10101@racer.site>
On Jan 7, 2008, at 10:18 PM, Johannes Schindelin wrote:
> Hi,
>
> [msysGit Cc'ed, since it is massively concerned by this thread]
>
> On Mon, 7 Jan 2008, Robin Rosenberg wrote:
>
>> måndagen den 7 januari 2008 skrev du:
>>> Problem. There is not a single "right". It really depends on the
>>> project.
>>
>> Indeed, but the most common SCM's detect binary files automatically,
>> either by suffix or content analysis, so I think that is what user's
>> expect. It will be right for more projects than the current
>> behaviour.
>
> Steffen also fought for turning this on by default, but so far I
> resisted.
> For a good reason: the primary user of msysGit for the moment is...
> msysGit. And this project does not need CR for obvious reasons.
>
> But I imagine that it makes sense for the Git installers. Colour me
> no-longer-resisting.
Eventually I gave in and even voted for "Git does not modify
content unless explicitly requested otherwise".
Here's the full discussion:
http://code.google.com/p/msysgit/issues/detail?id=21
I believe the main question is which type of projects we would like
to support by our default. For real cross-platform projects that will
be checked out on Windows and Unix we should choose
"core.autocrlf true" as our default. But if our default are native
Windows projects that will never be checked out on Unix, then we
should not set core.autocrlf by default.
I once fought for "real cross-platform", because this is what I need
in my daily work. Note, however, that this setting bears the slight
chance of git failing to correctly detect a binary file. In this case
git would corrupt the file. So there is a tiny chance of data loss
with "core.autocrlf true". The safest choice is to leave core.autocrlf
unset.
Steffen
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Thomas Neumann @ 2008-01-07 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <200801072203.23938.robin.rosenberg.lists@dewire.com>
> Indeed, but the most common SCM's detect binary files automatically,
> either by suffix or content analysis, so I think that is what user's
> expect. It will be right for more projects that the current behaviour.
as a user, I expect a SCM to only modify a file when I have explicitly
asked it to do so. Automatically conversion by guessing file types are
evil, as they _will_ go wrong, and then mess some files.
This "intelligent" file handling is a pain to use. You end up in
situations were builds work on some platforms but not on others, which
gets even more confusion with NFS home directories.
So, please do not enable core.autocrlf by default on Windows. It might
be reasonable for some projects, but not for all of them, and it will
break some projects. Perhaps a project should be able to enable (or
"suggest" it) in a repo-wide setting somehow, which would avoid the git
clone problem.
Thomas
^ permalink raw reply
* [PATCH] Fix some typos.
From: Ralf Wildenhues @ 2008-01-07 21:43 UTC (permalink / raw)
To: git
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
Documentation/gitcli.txt | 2 +-
Documentation/technical/api-diff.txt | 6 +++---
Documentation/technical/pack-format.txt | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index b7dcf9c..07899ec 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
@@ -95,7 +95,7 @@ $ git foo -oArg
$ git foo -o Arg
----------------------------
-However, this is *NOT* allowed for switches with an optionnal value, where the
+However, this is *NOT* allowed for switches with an optional value, where the
'sticked' form must be used:
----------------------------
$ git describe --abbrev HEAD # correct
diff --git a/Documentation/technical/api-diff.txt b/Documentation/technical/api-diff.txt
index 822609b..83b007e 100644
--- a/Documentation/technical/api-diff.txt
+++ b/Documentation/technical/api-diff.txt
@@ -102,13 +102,13 @@ Notable members are:
and copies.
`abbrev`::
- Number of hexdigits to abbrevate raw format output to.
+ Number of hexdigits to abbreviate raw format output to.
`pickaxe`::
A constant string (can and typically does contain newlines to
look for a block of text, not just a single line) to filter out
the filepairs that do not change the number of strings contained
- in its preimage and postmage of the diff_queue.
+ in its preimage and postimage of the diff_queue.
`flags`::
This is mostly a collection of boolean options that affects the
@@ -149,7 +149,7 @@ REVERSE_DIFF;;
EXIT_WITH_STATUS;;
For communication between the calling program and the options
- parser; tell the calling program to signal the presense of
+ parser; tell the calling program to signal the presence of
difference using program exit code.
HAS_CHANGES;;
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
index a80baa4..aa87756 100644
--- a/Documentation/technical/pack-format.txt
+++ b/Documentation/technical/pack-format.txt
@@ -125,7 +125,7 @@ Pack file entry: <+
- A table of 4-byte CRC32 values of the packed object data.
This is new in v2 so compressed data can be copied directly
- from pack to pack during repacking withough undetected
+ from pack to pack during repacking without undetected
data corruption.
- A table of 4-byte offset values (in network byte order).
--
1.5.4.rc2.17.g257f
^ permalink raw reply related
* Re: RFC/RFH submodule handling in big setups
From: Junio C Hamano @ 2008-01-07 21:51 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20080107204922.GA19728@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
> I'll try to explain a bit better, in different ways:
>
> Way 1: Think of product2 as a big repository
>
> I want to use git as if product2 was a single repository containing
> all its submodules as directories.
>
> I want to be able to send email patches agains product2 that affect
> any number of the submodules. I want to apply these in any order, and
> to let them live as topic branches in product2.
>
> Way 2: Changes to several submodules must be "globally atomic"
>
> If I change submodule 1 and submodule 2, I want to be able to commit
> both those changes as one atomic change in the supermodule - in a
> topic branch. When merging that topic branch in the supermodule, both
> changes in the submodules are merged. But NOT BEFORE. The submodules
> cannot be pre-merged (hence the need to push them "somewhere")
>
> Way 3: The submodules are not released on their own
>
> Only the products are released, each product has different release
> criteria, code freezes, whatever. Syncing of submodules between
> products happens rarely (a few times a year maybe). Modifications to
> submodules must fit each product's release criteria.
>
> There is usually no one who is responsible for each submodule, they
> live their life as part of the supermodule. Anyone can modify a
> submodule, but each product has a maintainer who decides what
> modifications to the submodules are allowed in that product.
>
> Does this make things clearer in any way?
Yes, I think my guess was not too far off the mark.
To achieve #1, when you create a topic for product2, you can
create a corresponding topic in its submodules. Because os-lib
is shared between product1 and product2 groups, you may want to
have a namespace rule agreed upon between the groups involved.
It could be something as simple as "in os-lib, topics from
product2 group are named with product2/ prefix".
Then a topic to add a fancy coloring to log-merger program in
product2 can be called "fancy-color". When you create that
topic branch, you also create product2/fancy-color in os-lib
submodule and switch both to it (currently there is no
single-step Porcelain for this, so you would do something like
"git checkout -b fancy-color; cd os-lib; git checkout -b
product2/fancy-color; cd ..". There is a beginning of
discussion regarding recursive git-submodule behaviour, which
would be a good place to polich the idea further). The topic
branch product2/fancy-color in os-lib project would be the one
I discussed in my previous message. That can be pushed out
first if it needs further futzing by people other than the
original developer.
I am not sure if you are stating what you really want correctly
about #2. git submodule is designed to be usable as a
standalone project. A commit in a submodule is an atomic event
in that submodule. Another commit that updates the containing
project to point at that commit in the submodule will be the
atomic event that updates both the containing project and the
contained submodule at the same time from the containing
project's point of view, in the sense that before that commit
the containing project does not see that change in the
submodule, and after that commit it does.
So a possible workflow would be:
- The original developer creates fancy-color topic in product2
and product2/fancy-color topic in os-lib and log-merge;
- He hacks away, creates commits to advance the topic branches
in the submodules involved and at the toplevel project as he
sees fit;
- He pushes out product2/fancy-color topic of os-lib project.
This can be done even before pushing out the toplevel or
log-merge project if your process requires for managers of
product2 group to approve and update the change to os-lib
project made by the group (that is, topic branches under
product2/ namespace).
- If the manager updated product2/fancy-color topic in os-lib,
the original developer can pull to update his copy of os-lib,
update his copy of the toplevel product2 project and commit
the integration results. In his repository, that commit in
the toplevel is the single atomic event that finishes the
fancy-color topic (eh, the initial round of it, anyway).
- That toplevel commit to fancy-color topic is pushed out. The
appearance of that commit could be the single atomic event
that makes the fancy-color topic global. Alternatively,
merging that whole topic (both "fancy-color" in the toplevel
and "product2/fancy-color" in submodules) to the mainline
branch of the product2 group (perhaps that branch is called
'master' in the product2 project and 'product2/master' in
os-lib project) could be the single atomic event that makes
the changes "official", from product2 group's point of view.
I do not think #3 matters in the discussion at all. If os-lib
does not get released, that's your code and that's your choice.
It does not change the project and history management aspect of
anything.
Although it is unclear how you plan to avoid reinventing
potentially conflicting wheels across groups without _any_
coordination, once your product groups start to have diverging
needs, but if your product groups never talk with each other and
never share their improvements and enhancements to the shared
part of the codebase, that's also your choice. It does not
change the history management aspect of anything.
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Paul Mackerras @ 2008-01-07 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, stimming
In-Reply-To: <7vhchq11n2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano writes:
> Subsystem people (except Shawn, whose git-gui 0.9.1 is already
> in) are requested to tell me to pull from them, if they have
> accumulated changes that should be in the final release. I am
> hoping that I can tag -rc3 in a few days (say by the end of my
> Wednesday).
I'd like you to do a pull from the gitk.git master branch, but it
looks to me like there will be a conflict on the Makefile.
Unfortunately the Makefile that Christian Stimming gave me along with
the i18n changes is quite different from the one you currently have in
the gitk-git subdirectory. I'm not quite sure what to suggest since
it isn't clear to me exactly what Christian's Makefile (which doesn't
actually work) is trying to do. I guess the best thing would be to
copy your Makefile over and then add the i18n stuff.
Apart from the i18n changes, there is one more commit (b039f0a6) that
improves the appearance slightly when running under Tk8.5.
Paul.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-07 22:06 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <3B08AC4C-A807-4155-8AD7-DC6A6D0FE134-wjoc1KHpMeg@public.gmane.org>
Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
> I believe the main question is which type of projects we would like
> to support by our default. For real cross-platform projects that will
> be checked out on Windows and Unix we should choose
> "core.autocrlf true" as our default. But if our default are native
> Windows projects that will never be checked out on Unix, then we
> should not set core.autocrlf by default.
If the primary target is native Windows projects that wants CRLF
in the work tree, you could still set core.autocrlf. Your
checkouts will be with CRLF. And someday perhaps somebody may
offer porting that to UNIX and his checkout will be without CR.
So wouldn't the categorization be more like this?
- "real cross-platform" would want core.autocrlf = true;
- "native Windows" can work either way;
- "originated from UNIX" would be helped with core.autocrlf = true;
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Christian Stimming @ 2008-01-07 22:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <18306.41093.376963.228802@cargo.ozlabs.ibm.com>
Am Montag, 7. Januar 2008 22:58 schrieb Paul Mackerras:
> I'd like you to do a pull from the gitk.git master branch, but it
> looks to me like there will be a conflict on the Makefile.
> Unfortunately the Makefile that Christian Stimming gave me along with
> the i18n changes is quite different from the one you currently have in
> the gitk-git subdirectory. I'm not quite sure what to suggest since
> it isn't clear to me exactly what Christian's Makefile (which doesn't
> actually work) is trying to do.
The Makefile from me was merely a placeholder where the i18n programs should
work, but it was clear that the installation rules need to be defined
differently anyway.
> I guess the best thing would be to
> copy your Makefile over and then add the i18n stuff.
Yes. I've just sent you a patch that does exactly this - that was what I
thought, too.
> Apart from the i18n changes, there is one more commit (b039f0a6) that
> improves the appearance slightly when running under Tk8.5.
Are you going to release a i18n-enabled gitk sometime soon? If yes, you should
consider notifying the translator(s) a few days in advance so that they can
finalize their translations, in case they want to avoid a half-translated
program to be shipped. Thanks a lot.
Christian
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Junio C Hamano @ 2008-01-07 22:14 UTC (permalink / raw)
To: Christian Stimming; +Cc: Paul Mackerras, git
In-Reply-To: <200801072305.59425.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> writes:
> Am Montag, 7. Januar 2008 22:58 schrieb Paul Mackerras:
>> I'd like you to do a pull from the gitk.git master branch, but it
>> looks to me like there will be a conflict on the Makefile.
>> Unfortunately the Makefile that Christian Stimming gave me along with
>> the i18n changes is quite different from the one you currently have in
>> the gitk-git subdirectory. I'm not quite sure what to suggest since
>> it isn't clear to me exactly what Christian's Makefile (which doesn't
>> actually work) is trying to do.
>
> The Makefile from me was merely a placeholder where the i18n programs should
> work, but it was clear that the installation rules need to be defined
> differently anyway.
>
>> I guess the best thing would be to
>> copy your Makefile over and then add the i18n stuff.
>
> Yes. I've just sent you a patch that does exactly this - that was what I
> thought, too.
Thanks both of you.
>> Apart from the i18n changes, there is one more commit (b039f0a6) that
>> improves the appearance slightly when running under Tk8.5.
>
> Are you going to release a i18n-enabled gitk sometime soon? If yes, you should
> consider notifying the translator(s) a few days in advance so that they can
> finalize their translations, in case they want to avoid a half-translated
> program to be shipped. Thanks a lot.
If I understand correctly, what Paul told me to pull contains
the i18n stuff, so assuming your adjustment to gitk Makefile
makes things cleanly merge and build inside git.git repository,
upcoming 1.5.4-rc3 will ship with the infrastructure and
existing translations, and updates to po/ files can be made
between -rc3 and the final (I do not mean there won't be -rc4.
That is also "between -rc3 and final").
^ permalink raw reply
* StGIT loses Git commit using "stg repair"; I miss "stg assimilate"
From: Jakub Narebski @ 2008-01-07 22:45 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas
I have StGIT branch with no patches applied: all patches are on stack.
I have accidentally added git commit on top of StGIT branch head.
I tried to use "stg assimilate" to turn this commit into StGIT commit,
applied, but new version of StGIT has only "stg repair". And the
sequence
# stg repair
# stg rebase origin
made me lose this git commit (well, up to reflog of course). This should
not happen! Why assimilate got removed?
4206:[gitweb/web@git]# stg --version
Stacked GIT 0.14.1
git version 1.5.3.7
Python version 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-07 22:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steffen Prohaska, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <7vzlvhxpda.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Mon, 7 Jan 2008, Junio C Hamano wrote:
>
> So wouldn't the categorization be more like this?
Well, one thng we could do is to add a new concept, namely
core.autocrlf = warn
and make *that* the default.
It would do the check, but not actually convert anything, just warn about
it.
Then, it's up to the user to set it explicitly to "true" or "false",
unless they just like seeing that warning a million times ;)
That might be acceptable to most people.
Linus
^ permalink raw reply
* Re: StGIT loses Git commit using "stg repair"; I miss "stg assimilate"
From: David Kågedal @ 2008-01-07 23:11 UTC (permalink / raw)
To: git
In-Reply-To: <200801072345.21585.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I have StGIT branch with no patches applied: all patches are on stack.
> I have accidentally added git commit on top of StGIT branch head.
> I tried to use "stg assimilate" to turn this commit into StGIT commit,
> applied, but new version of StGIT has only "stg repair". And the
> sequence
If you have no patches, there is nothing to assimilate or repair. Your
patch stack is considered to be on top of your new commit, so if you
push a patch it will appear on top of the commit you just created.
To turn your new commit into a patch, use "stg uncommit".
> # stg repair
> # stg rebase origin
>
> made me lose this git commit (well, up to reflog of course). This should
> not happen! Why assimilate got removed?
repair does exactly what assimilate did in this case, so it would not
have helped you.
--
David Kågedal
^ permalink raw reply
* Re: StGIT loses Git commit using "stg repair"; I miss "stg assimilate"
From: David Kågedal @ 2008-01-07 23:15 UTC (permalink / raw)
To: git
In-Reply-To: <873at9z0w2.fsf@lysator.liu.se>
David Kågedal <davidk@lysator.liu.se> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> I have StGIT branch with no patches applied: all patches are on stack.
>> I have accidentally added git commit on top of StGIT branch head.
>> I tried to use "stg assimilate" to turn this commit into StGIT commit,
>> applied, but new version of StGIT has only "stg repair". And the
>> sequence
>
> If you have no patches, there is nothing to assimilate or repair. Your
That should have been "if you have no patches *applied* ..."
> patch stack is considered to be on top of your new commit, so if you
> push a patch it will appear on top of the commit you just created.
>
> To turn your new commit into a patch, use "stg uncommit".
>
>> # stg repair
>> # stg rebase origin
>>
>> made me lose this git commit (well, up to reflog of course). This should
>> not happen! Why assimilate got removed?
>
> repair does exactly what assimilate did in this case, so it would not
> have helped you.
--
David Kågedal
^ permalink raw reply
* Re: git-svn doesn't like !! in the url
From: Junio C Hamano @ 2008-01-07 23:22 UTC (permalink / raw)
To: Eric Wong; +Cc: Michael J. Cohen, Git Mailing List
In-Reply-To: <20080107103040.GA28557@soma>
Eric Wong <normalperson@yhbt.net> writes:
> I just dug up cfbe7ab333d68790eb37341e30f040f99cef6af7 and that
> should've escaped everything that needs to be urlencoded for HTTP(S).
> (you were also the one that noticed the need for that one, too :).
>
> I also just noticed that changeset didn't make it into 1.5.3.7 nor
> maint, however...
>
> Junio: if there are plans for 1.5.3.8, could you please add
> cfbe7ab333d68790eb37341e30f040f99cef6af7 to it? Thanks.
Surely I can cherry pick that commit. Are you sure the test in
it (t9118) does not depend on any other new features that appear
on 'master'?
^ permalink raw reply
* git-rev-parse incorrectly uses --default parameter when invalid revision is supplied
From: Brandon Casey @ 2008-01-07 23:38 UTC (permalink / raw)
To: git
When rev-parse is called with an invalid revision parameter and
--default has been used to set a default revision, the output
will be based on the parameter to --default.
For example:
This likely fails:
$ git rev-parse --verify foobar
fatal: Needed a single revision
This likely succeeds but probably should fail:
$ git rev-parse --verify --default refs/heads/master foobar
b2e62a7dc6ba20a354d7590bf6a1d9264de7efe3
The documentation for rev-parse says:
--default <arg>::
If there is no parameter given by the user, use `<arg>`
instead.
git-stash uses this command, so a typo could cause the wrong stash
to be applied.
git stash apply stsh@{1}
If stash@{0} exists, it will be applied which is definitely not
what the user would want.
It is not straight forward to me how to modify builtin-rev-parse.c
to fix this.
-brandon
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-07 23:46 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano
Cc: Steffen Prohaska, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <alpine.LFD.1.00.0801071457040.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
On 7/1/08 22:58, "Linus Torvalds" <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> Well, one thng we could do is to add a new concept, namely
>
> core.autocrlf = warn
>
> and make *that* the default.
>
> It would do the check, but not actually convert anything, just warn about
> it.
>
I think this is the best option so far. Since this doesn't exist I was just
writing a hook for myself which fails rather than warns when CRLFs are
detected. Not modifying content by default is a good mantra. But getting a
couple of CRLF files into the repository and then noticing n commits down
the line and having to run a filter-branch session is a pain. So +1 for the
default being a warning (that includes appropriate instructions) when
committing a file that looks like text but has CRLF. And having a "fail"
option might be nice while you(?)'re at it:
core.autocrlf = fail # refuse to commit text files containing CRLF
Greg.
PS Of course none of this would have helped me with those old mac CR files
that got into another repository ...
^ permalink raw reply
* Re: git-rev-parse incorrectly uses --default parameter when invalid revision is supplied
From: Junio C Hamano @ 2008-01-08 0:21 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0801071653460.31161@torch.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> When rev-parse is called with an invalid revision parameter and
> --default has been used to set a default revision, the output
> will be based on the parameter to --default.
>
> For example:
>
> This likely fails:
> $ git rev-parse --verify foobar
> fatal: Needed a single revision
>
> This likely succeeds but probably should fail:
> $ git rev-parse --verify --default refs/heads/master foobar
> b2e62a7dc6ba20a354d7590bf6a1d9264de7efe3
>
>
> The documentation for rev-parse says:
> --default <arg>::
> If there is no parameter given by the user, use `<arg>`
> instead.
>
>
> git-stash uses this command, so a typo could cause the wrong stash
> to be applied.
>
> git stash apply stsh@{1}
>
> If stash@{0} exists, it will be applied which is definitely not
> what the user would want.
>
> It is not straight forward to me how to modify builtin-rev-parse.c
> to fix this.
Two points.
* The description for --default you quoted says "no parameter",
but it should read "no non-flag rev parameter".
* --verify needs to be whole lot more special cased in the
codepath;
Currently, --verify just runs the command as if it was not
specified at all, but dies (1) as soon as it sees a second
non-flag rev arg (worse --- it dies *after* emitting it!), or
(2) at the end if it notices it did not emit any. It does not
even barf if you say "git rev-parse --verify ^HEAD", which I
think is a misdesign.
^ permalink raw reply
* Re: [PATCH] git-svn: clarify the "Ignoring error from SVN" piece
From: Junio C Hamano @ 2008-01-08 0:28 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List, Michael J. Cohen
In-Reply-To: <20080107104040.GA1594@soma>
Will apply to 'maint' ;-)
^ permalink raw reply
* [EGIT PATCH] Showing abbreviated commit hash of the versions in Compare editor.
From: Roger C. Soares @ 2008-01-08 1:15 UTC (permalink / raw)
To: git
Signed-off-by: Roger C. Soares <rogersoares@intelinet.com.br>
---
Some more patches, please evaluate.
Don't know what others are working on,
but right now I'm missing a search functionality so
this will probably be my next egit little feature.
cheers
.../GitCompareFileRevisionEditorInput.java | 12 ++++++++++++
.../spearce/egit/ui/internal/GitResourceNode.java | 5 +++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java
index eaba1fa..403fdc1 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java
@@ -152,6 +152,18 @@ public class GitCompareFileRevisionEditorInput extends CompareEditorInput {
private void initLabels(ICompareInput input) {
CompareConfiguration cc = getCompareConfiguration();
+ if(left != null && left instanceof GitResourceNode) {
+ String ci = ((GitResourceNode)left).getContentIdentifier();
+ if(ci != null) {
+ cc.setLeftLabel(ci.substring(0, 7) + "..");
+ }
+ }
+ if(right != null && right instanceof GitResourceNode) {
+ String ci = ((GitResourceNode)right).getContentIdentifier();
+ if(ci != null) {
+ cc.setRightLabel(ci.substring(0, 7) + "..");
+ }
+ }
if (getLeftRevision() != null) {
String leftLabel = getFileRevisionLabel(getLeftRevision());
cc.setLeftLabel(leftLabel);
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitResourceNode.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitResourceNode.java
index e19cef5..f25855a 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitResourceNode.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitResourceNode.java
@@ -21,6 +21,7 @@ import org.spearce.jgit.lib.TreeEntry;
public class GitResourceNode extends BufferedContent implements IStructureComparator, ITypedElement {
TreeEntry entry;
GitResourceNode[] children;
+ String contentIdentifier;
public GitResourceNode(TreeEntry e) {
entry = e;
@@ -28,6 +29,7 @@ public class GitResourceNode extends BufferedContent implements IStructureCompar
public GitResourceNode(IFileRevision file) {
this(file instanceof GitCommitFileRevision ? ((GitCommitFileRevision)file).getTreeEntry() : null);
+ contentIdentifier = ((GitCommitFileRevision)file).getContentIdentifier();
}
public Object[] getChildren() {
@@ -100,5 +102,8 @@ public class GitResourceNode extends BufferedContent implements IStructureCompar
}
}
+ public String getContentIdentifier() {
+ return contentIdentifier;
+ }
}
--
1.5.3.7
^ permalink raw reply related
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