* Re: [PATCH] utf8: add utf8_strwidth()
From: Geoffrey Thomas @ 2009-01-31 8:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090131071711.GA3710@coredump.intra.peff.net>
On Sat, 31 Jan 2009, Jeff King wrote:
> I know next to nothing about our encoding functions, but this seems
> suspiciously similar to utf8_width in utf8.c. There is also a
> git_wcwidth, but I don't know how they relate.
git_wcwidth determines the screen columns of a single ucs_char_t.
utf8_width returns the git_wcwidth of the first character in a string.
utf8_strwidth (the function added by this patch) is a simple loop around
utf8_width, because writing the loop every time would be silly.
On that note, there are probably more cases in the code that ought to use
something like utf8_strwidth. I only noticed this one case because I'm
working on a project with someone with an accented letter in his last
name.
--
Geoffrey Thomas
geofft@mit.edu
^ permalink raw reply
* Re: [PATCH] utf8: add utf8_strwidth()
From: Jeff King @ 2009-01-31 8:56 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0901310348000.3373@vinegar-pot.mit.edu>
On Sat, Jan 31, 2009 at 03:51:48AM -0500, Geoffrey Thomas wrote:
> On Sat, 31 Jan 2009, Jeff King wrote:
>> I know next to nothing about our encoding functions, but this seems
>> suspiciously similar to utf8_width in utf8.c. There is also a
>> git_wcwidth, but I don't know how they relate.
>
> git_wcwidth determines the screen columns of a single ucs_char_t.
> utf8_width returns the git_wcwidth of the first character in a string.
> utf8_strwidth (the function added by this patch) is a simple loop around
> utf8_width, because writing the loop every time would be silly.
Urgh. Sorry. If I had taken 3 seconds to actually _look_ at your patch,
I would have seen that (instead I thought "don't we already have
something that does this" and went straight to the existing code).
But no, it looks like we don't already have this, so your patch is fine.
Sorry for the noise.
-Peff
^ permalink raw reply
* Re: [PATCH] contrib/difftool: add support for Kompare
From: Markus Heidelberg @ 2009-01-31 10:41 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, git
In-Reply-To: <20090131063714.GA29621@gmail.com>
David Aguilar, 31.01.2009:
> On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
> >
> > Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
> > ---
> > contrib/difftool/git-difftool-helper | 16 ++++++++++------
> > contrib/difftool/git-difftool.txt | 3 ++-
> > 2 files changed, 12 insertions(+), 7 deletions(-)
>
>
> Good stuff =)
> Should we patch mergetool with the same change?
> Kompare's pretty popular in KDE land.
But Kompare cannot merge. It is kind of a diff/patch frontend, it takes
only one or two files (or directories) as arguments.
> BTW git.git's next branch has:
>
> commit fb700cb0679e22900f0d1435641e6cf7c652968b
> Author: Johannes Gilger <heipei@hackvalue.de>
> Date: Sat Jan 24 00:12:45 2009 +0100
>
> mergetool: Don't repeat merge tool candidates
>
> git mergetool listed some candidates for mergetools twice, depending on
> the environment.
>
> This slightly changes the behavior when both KDE_FULL_SESSION and
> GNOME_DESKTOP_SESSION_ID are set at the same time; in such a case
> meld is used in favor of kdiff3 (the old code favored kdiff3 in such a
> case), but it should not matter in practice.
>
> Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
>
> difftool probably needs a similar patch.
> I'll see if I can get to that this weekend if no one beats
> me to it.
Yes, the change would make sense here, too.
Markus
^ permalink raw reply
* understanding index
From: Nicolas Sebrecht @ 2009-01-31 11:10 UTC (permalink / raw)
To: git
Hey list.
I'm having some understanding trouble with git index. As I understand,
'git rm --cached' is not strictly the opposite of 'git add'. It's a
little embarrassing in this particular case : what if you want to
commit and did a wrong 'git add -u' command ?
Here's a minimalist sample :
% ls
foo bar
[ hack, hack, hack on both files ]
% git status
[...]
modified: foo
modified: bar
[...]
% git add -u foo bar
[ optional hack on foo ]
[ damn, you realize you don't want to commit changes on foo at all ]
% git rm --cached foo
% git status
[...]
deleted: foo
modified: bar
[...]
If committed as is, foo will be marked as deleted (in 'git log
--name-status' at least, which is not wanted).
How to retrieve the state before the wrong 'git add -u' command _and_
keep the working tree as well (including last hacks) ? Is there any
command which is the exact opposite of 'git add -u' ?
Cheers,
--
Nicolas Sebrecht
^ permalink raw reply
* Re: understanding index
From: Santi Béjar @ 2009-01-31 12:09 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: git
In-Reply-To: <20090131111011.GA29748@ultras>
2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:
>
> Hey list.
>
> I'm having some understanding trouble with git index. As I understand,
> 'git rm --cached' is not strictly the opposite of 'git add'. It's a
> little embarrassing in this particular case : what if you want to
> commit and did a wrong 'git add -u' command ?
>
> Here's a minimalist sample :
>
> % ls
> foo bar
>
> [ hack, hack, hack on both files ]
>
> % git status
> [...]
> modified: foo
> modified: bar
> [...]
> % git add -u foo bar
>
> [ optional hack on foo ]
> [ damn, you realize you don't want to commit changes on foo at all ]
>
You omitted the help message of git status, where it says how to unstage:
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
So to not commit foo at all:
git reset HEAD foo
HTH,
Santi
> % git rm --cached foo
> % git status
> [...]
> deleted: foo
> modified: bar
> [...]
>
> If committed as is, foo will be marked as deleted (in 'git log
> --name-status' at least, which is not wanted).
>
> How to retrieve the state before the wrong 'git add -u' command _and_
> keep the working tree as well (including last hacks) ? Is there any
> command which is the exact opposite of 'git add -u' ?
>
> Cheers,
>
> --
> Nicolas Sebrecht
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* How to move subdirectories from one svn repos to another.
From: Josef Wolf @ 2009-01-31 12:33 UTC (permalink / raw)
To: git
Hello,
I would like to move a complete subdirectory with all its history from
one svn repository to another.
For this, I have created a git repository with the two subversion
repositories as remotes:
REPOSROOT=https://foo.bar.com/repos
mkdir -p migrate
cd migrate
git svn init --stdlayout $REPOSROOT/my-repos
for i in my-repos their-repos; do
git config svn-remote.$i.url $REPOSROOT/$i
git config svn-remote.$i.fetch trunk:refs/remotes/$i/trunk
git config svn-remote.$i.branches branches/*:refs/remotes/$i/*
git config svn-remote.$i.tags tags/*:refs/remotes/$i/tags/*
git svn fetch -R $i
git checkout -b $i $i/trunk
done
git gc
Now I would like to move one directory (call it bar) from my-repos
to their-repos. Problem is: there are thousands of changesets in
this directory. So I got somewhat stuck (I am new to git). Do I
have to cherry-pick every changeset separately? Or is there some
way to merge all the changesets touching this specific directory?
Any hints?
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Raimund Berger @ 2009-01-31 13:14 UTC (permalink / raw)
To: git
In-Reply-To: <20090131095724.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting "Raimund Berger" <raimund.berger@gmail.com>:
>
>> The question is whether a (3way) merge is commutative, purely in terms
>> of content (i.e. disregarding commit history for now). Iow if no matter
>> in which order I merge A and B, i.e. A into B or B into A, I'd be
>> guaranteed to arrive at the same content.
>
> I think three-way merge of A into B and B into A will produce the same
> result when the merge doesn't conflict (when it does, you will get the
> conflict markers and text from A and B in a different order depending on
> the direction of the merge).
>
>> The reason I ask is obvious I guess. What basically interests me is if I
>> gave a bunch of topic branches exposure on a test branch and, after
>> resolving issues, applied them to stable, that I could be 100% sure to
>> not introduce new issues content wise just by applying merges in a
>> different order or form (rebase, patch set).
>
> I don't think you can make a blanket conclusion like that by only knowing
> that merging A into B and merging B into A would produce the same result.
>
> If you merge topics A, B, and C in this order into your current state O,
> there may not be any conflict, but if you merge the same topics to the
> same current state in different order, C, B and then A for example, you
> may get conflicts that breaks the merge. The commutativeness only says
> that merge of A into O will produce the same result as merge of O into A.
> It doesn't say anything about what would happen when you merge B to O.
That's correct. Strictly speaking one would also have to verify
associativity. I.e. whether merge(merge(A,B),C) == merge(A,merge(B,C))
for all A,B,C.
Thanks for making an implicit point explicit. So a followup question
would be: is git's 3way merge associative?
>From my pov people seem to assume it.
^ permalink raw reply
* "git svn fetch" slow
From: Markus Heidelberg @ 2009-01-31 13:14 UTC (permalink / raw)
To: git, Eric Wong
Hi,
since several days "git svn fetch" didn't seem to work any more. I
bisected it down to
commit dbc6c74d0858d77e61e092a48d467e725211f8e9
git-svn: handle empty files marked as symlinks in SVN
2009-01-11
In the new function _mark_empty_symlinks() there is a loop that takes
about 36 seconds for me. That means each svn revision takes 36+x seconds
for downloading. So it still works, but I aborted it before waiting so
much time, so I thought, it didn't work any more.
The loop loops over each blob ("git ls-tree -r git-svn | wc -l" times).
The project I'm using git-svn with is Buildroot and it has currently
3074 blobs in the tree. Printing a loop counter every time the loop is
executed, I can see that it mostly goes really fast, but there are
files, where it needs much time then.
Could there be a way to avoid this time consuming step?
Markus
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Raimund Berger @ 2009-01-31 13:26 UTC (permalink / raw)
To: git
In-Reply-To: <slrngo771p.b1i.sitaramc@sitaramc.homelinux.net>
Sitaram Chamarty <sitaramc@gmail.com> writes:
[snip] ...
> Rebase *does* do an implicit merge by default (as far as the
> tree that results is concerned, which you mentioned right at
> the start), I'm pretty sure of it.
I'm myself, especially since a conflicting rebase leaves the index in an
"unmerged" state. Much like a regular merge does. It's still all
assumptions though, or maybe I'm missing documentation .... (?)
> Perhaps someone with more git smarts will chip in with
> something more concrete.
That'd really be awesome. I mean, it's ok for me to dig through source
code and find answers myself, but it would really save time if somebody
who knows for sure dropped a word or two.
^ permalink raw reply
* [PATCH JGIT] Little performance optimization - replace the previous one
From: Yann Simon @ 2009-01-31 14:19 UTC (permalink / raw)
To: Shawn O.Pearce, Robin Rosenberg; +Cc: git
- avoid one if
- avoid to calculate 2 times the same value
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/GitIndex.java | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
index 454b540..6eeccff 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
@@ -411,11 +411,9 @@ Entry(ByteBuffer b) {
* @throws IOException
*/
public boolean update(File f) throws IOException {
- boolean modified = false;
long lm = f.lastModified() * 1000000L;
- if (mtime != lm)
- modified = true;
- mtime = f.lastModified() * 1000000L;
+ boolean modified = mtime != lm;
+ mtime = lm;
if (size != f.length())
modified = true;
if (config_filemode()) {
--
1.6.0.6
^ permalink raw reply related
* [PATCH JGIT] use java 5 like for loops
From: Yann Simon @ 2009-01-31 14:19 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git
in for loops that use an iterator or an index (int i), use instead a
loop like: for (Element e : elements)
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/GitIndex.java | 6 ++----
.../src/org/spearce/jgit/lib/Repository.java | 4 ++--
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
index 6eeccff..920a9c9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
@@ -754,8 +754,7 @@ public Entry addEntry(TreeEntry te) throws
IOException {
* @throws IOException
*/
public void checkout(File wd) throws IOException {
- for (Iterator i = entries.values().iterator(); i.hasNext();) {
- Entry e = (Entry) i.next();
+ for (Entry e : entries.values()) {
if (e.getStage() != 0)
continue;
checkoutEntry(wd, e);
@@ -808,8 +807,7 @@ public ObjectId writeTree() throws IOException {
Stack<Tree> trees = new Stack<Tree>();
trees.push(current);
String[] prevName = new String[0];
- for (Iterator i = entries.values().iterator(); i.hasNext();) {
- Entry e = (Entry) i.next();
+ for (Entry e : entries.values()) {
if (e.getStage() != 0)
continue;
String[] newName = splitDirPath(e.getName());
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index e1c4049..038a869 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -231,8 +231,8 @@ public File toFile(final AnyObjectId objectId) {
String d=n.substring(0, 2);
String f=n.substring(2);
final File[] objectsDirs = objectsDirs();
- for (int i=0; i<objectsDirs.length; ++i) {
- File ret = new File(new File(objectsDirs[i], d), f);
+ for (File objectsDir : objectsDirs) {
+ File ret = new File(new File(objectsDir, d), f);
if (ret.exists())
return ret;
}
--
1.6.0.6
^ permalink raw reply related
* [PATCH JGIT] simplify loop with if and do while
From: Yann Simon @ 2009-01-31 14:25 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git
replace if(condition) { do { } while (condition) } by while (condition)
{ }
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/Repository.java | 18
+++++++-----------
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 038a869..b6efac1 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -247,11 +247,9 @@ public File toFile(final AnyObjectId objectId) {
public boolean hasObject(final AnyObjectId objectId) {
final PackFile[] packs = packs();
int k = packs.length;
- if (k > 0) {
- do {
- if (packs[--k].hasObject(objectId))
- return true;
- } while (k > 0);
+ while (k > 0) {
+ if (packs[--k].hasObject(objectId))
+ return true;
}
return toFile(objectId).isFile();
}
@@ -288,12 +286,10 @@ public ObjectLoader openObject(final WindowCursor
curs, final AnyObjectId id)
throws IOException {
final PackFile[] packs = packs();
int k = packs.length;
- if (k > 0) {
- do {
- final ObjectLoader ol = packs[--k].get(curs, id);
- if (ol != null)
- return ol;
- } while (k > 0);
+ while (k > 0) {
+ final ObjectLoader ol = packs[--k].get(curs, id);
+ if (ol != null)
+ return ol;
}
try {
return new UnpackedObjectLoader(this, id);
--
1.6.0.6
^ permalink raw reply related
* [PATCH JGIT] use switch to avoid multiple ifs
From: Yann Simon @ 2009-01-31 14:25 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git
instead of using multiple ifs that will evaluate an expression x times,
use a switch with cases to evaluate the
expression only one time.
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/Repository.java | 29
+++++++++++++------
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index b6efac1..f42bae5 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -389,16 +389,23 @@ public Object mapObject(final ObjectId id, final
String refName) throws IOExcept
if (or == null)
return null;
final byte[] raw = or.getBytes();
- if (or.getType() == Constants.OBJ_TREE)
+ switch (or.getType()) {
+ case Constants.OBJ_TREE:
return makeTree(id, raw);
- if (or.getType() == Constants.OBJ_COMMIT)
+
+ case Constants.OBJ_COMMIT:
return makeCommit(id, raw);
- if (or.getType() == Constants.OBJ_TAG)
+
+ case Constants.OBJ_TAG:
return makeTag(id, refName, raw);
- if (or.getType() == Constants.OBJ_BLOB)
+
+ case Constants.OBJ_BLOB:
return raw;
- throw new IncorrectObjectTypeException(id,
+
+ default:
+ throw new IncorrectObjectTypeException(id,
"COMMIT nor TREE nor BLOB nor TAG");
+ }
}
/**
@@ -449,12 +456,16 @@ public Tree mapTree(final ObjectId id) throws
IOException {
if (or == null)
return null;
final byte[] raw = or.getBytes();
- if (Constants.OBJ_TREE == or.getType()) {
+ switch (or.getType()) {
+ case Constants.OBJ_TREE:
return new Tree(this, id, raw);
- }
- if (Constants.OBJ_COMMIT == or.getType())
+
+ case Constants.OBJ_COMMIT:
return mapTree(ObjectId.fromString(raw, 5));
- throw new IncorrectObjectTypeException(id, Constants.TYPE_TREE);
+
+ default:
+ throw new IncorrectObjectTypeException(id, Constants.TYPE_TREE);
+ }
}
private Tree makeTree(final ObjectId id, final byte[] raw) throws
IOException {
--
1.6.0.6
^ permalink raw reply related
* [PATCH JGIT] fix typo
From: Yann Simon @ 2009-01-31 14:26 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: git
fix a little typo
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/WindowedFile.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowedFile.java
b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowedFile.java
index 5eb8465..1ff8caa 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/WindowedFile.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/WindowedFile.java
@@ -61,7 +61,7 @@
* before any single byte can be accessed.
* </p>
* <p>
- * Using a specific MapMode will avoid the complete copy by mmaping in
the
+ * Using a specific MapMode will avoid the complete copy by mapping in
the
* operating system's file buffers, however this may cause problems if
a large
* number of windows are being heavily accessed as the Java garbage
collector
* may not be able to unmap old windows fast enough to permit new
windows to be
--
1.6.0.6
^ permalink raw reply related
* [PATCH] merge: fix out-of-bounds memory access
From: René Scharfe @ 2009-01-31 14:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: Junio C Hamano, H. Peter Anvin, Git Mailing List, Daniel Barkalow
In-Reply-To: <20090129120539.GA26975@elte.hu>
The following on top of master lets git finish the merge without segfault
(reporting a merge conflict) and valgrind doesn't find an more memory
errors here. Can you confirm that, Ingo?
-- 8< --
The parameter n of unpack_callback() can have a value of up to
MAX_UNPACK_TREES. The check at the top of unpack_trees() (its only
(indirect) caller) makes sure it cannot exceed this limit.
unpack_callback() passes it and the array src to unpack_nondirectories(),
which has this loop:
for (i = 0; i < n; i++) {
/* ... */
src[i + o->merge] = o->df_conflict_entry;
o->merge can be 0 or 1, so unpack_nondirectories() potentially accesses
the array src at index MAX_UNPACK_TREES. This patch makes it big enough.
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
unpack-trees.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 16bc2ca..e547282 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -240,8 +240,11 @@ static struct cache_entry *create_ce_entry(const struct traverse_info *info, con
return ce;
}
-static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmask, struct cache_entry *src[5],
- const struct name_entry *names, const struct traverse_info *info)
+static int unpack_nondirectories(int n, unsigned long mask,
+ unsigned long dirmask,
+ struct cache_entry **src,
+ const struct name_entry *names,
+ const struct traverse_info *info)
{
int i;
struct unpack_trees_options *o = info->data;
@@ -291,7 +294,7 @@ static int unpack_nondirectories(int n, unsigned long mask, unsigned long dirmas
static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, struct name_entry *names, struct traverse_info *info)
{
- struct cache_entry *src[5] = { NULL, };
+ struct cache_entry *src[MAX_UNPACK_TREES + 1] = { NULL, };
struct unpack_trees_options *o = info->data;
const struct name_entry *p = names;
--
1.6.1
^ permalink raw reply related
* Re: understanding index
From: Alex Riesen @ 2009-01-31 14:45 UTC (permalink / raw)
To: Santi Béjar; +Cc: Nicolas Sebrecht, git
In-Reply-To: <adf1fd3d0901310409y28dc493ak358749e0c29154cc@mail.gmail.com>
2009/1/31 Santi Béjar <santi@agolina.net>:
> 2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:
>> I'm having some understanding trouble with git index. As I understand,
>> 'git rm --cached' is not strictly the opposite of 'git add'. It's a
>> little embarrassing in this particular case : what if you want to
>> commit and did a wrong 'git add -u' command ?
>>
> So to not commit foo at all:
>
> git reset HEAD foo
>
Or look at git gui, which allows you to select the not-to-commit parts visually
^ permalink raw reply
* Re: "git svn fetch" slow
From: Sverre Rabbelier @ 2009-01-31 16:23 UTC (permalink / raw)
To: Eric Wong; +Cc: git, markus.heidelberg
In-Reply-To: <200901311414.58205.markus.heidelberg@web.de>
On Sat, Jan 31, 2009 at 14:14, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> since several days "git svn fetch" didn't seem to work any more. I
> bisected it down to
I noticed it too, it's horribly slow; I can't really revert the patch
since it conflicts, and I'm not familiar with the code, so I don't
know how to resolve the conflict :(.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH JGIT] fix typo
From: Robin Rosenberg @ 2009-01-31 16:45 UTC (permalink / raw)
To: Yann Simon; +Cc: Shawn O. Pearce, git
In-Reply-To: <1233411967.8213.4.camel@localhost>
lördag 31 januari 2009 15:26:07 skrev Yann Simon:
> fix a little typo
> Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
> ---
> .../src/org/spearce/jgit/lib/WindowedFile.java | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Cleanups are nice too, but please try to follow the existing
style when it comes to comments. I don't think we have
stated these implicit rules anywhere.
- New sentences start with a capital letter.
- Don't repeat yourself You do not need a body in the comment
if the first line says it all, except the SOB line which technically
is part of the body.
- Make sure there is an empty line before the SOB line.
Cheers,
-- robin
^ permalink raw reply
* Re: "git svn fetch" slow
From: Markus Heidelberg @ 2009-01-31 17:01 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Eric Wong, git
In-Reply-To: <bd6139dc0901310823lcced62frd61445cb80d56fca@mail.gmail.com>
Sverre Rabbelier, 31.01.2009:
> On Sat, Jan 31, 2009 at 14:14, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > since several days "git svn fetch" didn't seem to work any more. I
> > bisected it down to
>
> I noticed it too, it's horribly slow; I can't really revert the patch
> since it conflicts, and I'm not familiar with the code, so I don't
> know how to resolve the conflict :(.
The following should work around it:
diff --git a/git-svn.perl b/git-svn.perl
index 79888a0..bc7bd21 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3255,7 +3255,6 @@ sub new {
bless $self, $class;
if (exists $git_svn->{last_commit}) {
$self->{c} = $git_svn->{last_commit};
- $self->{empty_symlinks} = _mark_empty_symlinks($git_svn);
}
$self->{empty} = {};
$self->{dir_prop} = {};
^ permalink raw reply related
* Re: "git svn fetch" slow
From: Sverre Rabbelier @ 2009-01-31 17:31 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Eric Wong, git
In-Reply-To: <200901311801.56130.markus.heidelberg@web.de>
On Sat, Jan 31, 2009 at 18:01, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> The following should work around it:
Awesome! I tested it and it does indeed work around the issue for me, thanks!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: diff settings
From: Ted Pavlic @ 2009-01-31 19:47 UTC (permalink / raw)
To: Keith Cascio; +Cc: git, Junio C Hamano, Johannes Schindelin, Nanako Shiraishi
In-Reply-To: <alpine.GSO.2.00.0901310750470.5437@kiwi.cs.ucla.edu>
> Thank you for alerting us to the Hg design. I can appreciate the elegance of
> it, and I'm always in favor of the most general possible implementation. But
> there is a subtle difference between diff.primer and primer.diff.
As I already discussed, Mercurial has both "diff.primer" and
"primer.diff" precisely because "diff" settings affects so many Hg commands.
In particular, in my .hgrc, I have:
[diff]
git = 1
which causes all Mercurial commands that need to generate a diff to use
gitdiff rather than truediff. However, if I *wanted* to apply a set of
flags to a particular command, I could (using the equivalent "git"
commands)...
[defaults]
pull = --rebase
commit = -a
format-patch = -M
So I see a purpose for both *.defaults and defaults.*. Of course,
aliases are also nice (IIRC, Mercurial doesn't have "aliases", but I
could be wrong). Mercurial users are very happy with having both
available. I imagine git people would be too.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: 'git clone' doesn't use alternates automatically?
From: James Pickens @ 2009-01-31 20:08 UTC (permalink / raw)
To: Git ML; +Cc: Jeff King
In-Reply-To: <20090131071238.GC3033@coredump.intra.peff.net>
On Sat, Jan 31, 2009 at 12:12 AM, Jeff King <peff@peff.net> wrote:
> but presumably in your example the second clone is _not_ on the NFS
> mount, and therefore can't hardlink.
That's correct.
> So you can try "git clone -s" to specify that you definitely want
> alternates.
Well, the clone gets the alternates either way. It just doesn't
use them to avoid copying the data unless I give -s. More
importantly, if 'git clone' worked the way I thought, then when I
clone a remote repository for which I have a local mirror, I
could avoid typing '--reference <path to local mirror>' by adding
<path to local mirror>/objects to the alternates file in the
remote repository.
> I don't recall clone ever being that clever, but I could be wrong (it is
> not an area of the code that I am too familiar with).
>
> Can you try a test with a few different versions to see if it ever
> behaved as you expected (and if it does, bisect to find the breakage)?
Damn. I was hoping the response would be "it's a regression, and
here's a patch to fix it". I went ahead and tested a few old
versions and they all behave the same way.
So, is there any reason 'git clone' shouldn't automatically use
the alternates that it copied into the new repository? I might
look into writing a patch if nobody objects.
James
^ permalink raw reply
* Re: understanding index
From: Nicolas Sebrecht @ 2009-01-31 20:19 UTC (permalink / raw)
To: git
In-Reply-To: <adf1fd3d0901310409y28dc493ak358749e0c29154cc@mail.gmail.com>
On Sat, Jan 31, 2009 at 01:09:49PM +0100, Santi Béjar wrote:
> You omitted the help message of git status, where it says how to unstage:
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
>
> So to not commit foo at all:
>
> git reset HEAD foo
Thanks. I didn't omitted the help message of git status. The "unstage"
action is what I was looking for but I was wrongly presuming (and I've
read git docs !) that 'HEAD' is a kind of shortcut to the last commit of
the current branch (not to the last state of the working tree).
Working on branch master for example, we have in .git/HEAD :
ref: refs/heads/master
And in .git/refs/heads/master, the hash of the last commit of branch
master.
I'm missing something here. But what ?
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH] contrib/difftool: Don't repeat merge tool candidates
From: David Aguilar @ 2009-01-31 20:27 UTC (permalink / raw)
To: git; +Cc: gitster, Markus Heidelberg, Johannes Gilger, David Aguilar
git difftool listed some candidates for mergetools twice, depending on
the environment.
This slightly changes the behavior when both KDE_FULL_SESSION and
GNOME_DESKTOP_SESSION_ID are set at the same time; in such a case
meld is used in favor of kdiff3 (the old code favored kdiff3 in such a
case), but it should not matter in practice.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Hi Junio
This is based on top of Markus's kompare patch:
"contrib/difftool: add support for Kompare"
http://article.gmane.org/gmane.comp.version-control.git/107883
This syncs difftool up with the mergetool patch that's in 'next':
"git mergetool: Don't repeat merge tool candidates"
http://article.gmane.org/gmane.comp.version-control.git/106669
contrib/difftool/git-difftool-helper | 31 ++++++++++++-------------------
1 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
index 10632a3..db3af6a 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/contrib/difftool/git-difftool-helper
@@ -181,31 +181,24 @@ fi
# Try to guess an appropriate merge tool if no tool has been set.
if test -z "$merge_tool"; then
-
# We have a $DISPLAY so try some common UNIX merge tools
if test -n "$DISPLAY"; then
- merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff"
- # If gnome then prefer meld
- if test -n "$GNOME_DESKTOP_SESSION_ID"; then
- merge_tool_candidates="meld $merge_tool_candidates"
- fi
- # If KDE then prefer kdiff3 or kompare
- if test "$KDE_FULL_SESSION" = "true"; then
- merge_tool_candidates="kdiff3 kompare $merge_tool_candidates"
+ # If gnome then prefer meld, otherwise, prefer kdiff3 or kompare
+ if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
+ merge_tool_candidates="meld kdiff3 kompare tkdiff xxdiff gvimdiff"
+ else
+ merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff"
fi
fi
-
- # $EDITOR is emacs so add emerge as a candidate
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates emerge"
+ # $EDITOR is emacs so add emerge as a candidate
+ merge_tool_candidates="$merge_tool_candidates emerge opendiff vimdiff"
+ elif echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
+ # $EDITOR is vim so add vimdiff as a candidate
+ merge_tool_candidates="$merge_tool_candidates vimdiff opendiff emerge"
+ else
+ merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
fi
-
- # $EDITOR is vim so add vimdiff as a candidate
- if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates vimdiff"
- fi
-
- merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
# Loop over each candidate and stop when a valid merge tool is found.
--
1.6.1.2.253.ga34a
^ permalink raw reply related
* Re: understanding index
From: Santi Béjar @ 2009-01-31 20:57 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: git
In-Reply-To: <20090131201920.GC29748@ultras>
2009/1/31 Nicolas Sebrecht <nicolas.s-dev@laposte.net>:
>
> On Sat, Jan 31, 2009 at 01:09:49PM +0100, Santi Béjar wrote:
>
>> You omitted the help message of git status, where it says how to unstage:
>> # Changes to be committed:
>> # (use "git reset HEAD <file>..." to unstage)
>>
>> So to not commit foo at all:
>>
>> git reset HEAD foo
>
> Thanks. I didn't omitted the help message of git status.
These help messages (helpful messages?) were not in old version, but
in current git you get this indications when you execute "git status",
and it was what you put as "[...]".
$ git status
# On branch next
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: Makefile
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: Makefile
#
> The "unstage"
> action is what I was looking for but I was wrongly presuming (and I've
> read git docs !) that 'HEAD' is a kind of shortcut to the last commit of
> the current branch (not to the last state of the working tree).
By default git reset only acts on the head of the branch and the index, so with:
git reset HEAD foo
what you are saying is, use the HEAD as the head of the branch (don't
change my branch), but put in the index the state of foo in HEAD, so
in brief reset the index state of foo.
>
> Working on branch master for example, we have in .git/HEAD :
> ref: refs/heads/master
> And in .git/refs/heads/master, the hash of the last commit of branch
> master.
Right.
HTH,
Santi
^ 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