* Re: [PATCH] grep: --full-tree
From: James Pickens @ 2009-11-26 18:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, Jeff King, git
In-Reply-To: <7vd436p339.fsf@alter.siamese.dyndns.org>
On Wed, Nov 25, 2009 at 5:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> - git does not accept paths (it lets you specify patterns that match,
> e.g. t/ to name ptahs under t/ directory).
That's not entirely true, unfortunately:
$ echo >> unpack-trees.c
$ git diff --name-status unpack-trees.c
M unpack-trees.c
$ git diff --name-status $PWD/unpack-trees.c
M unpack-trees.c
$ git diff --name-status $PWD/../git/unpack-trees.c
M unpack-trees.c
$ git diff --name-status ../git/unpack-trees.c
fatal: '../git/unpack-trees.c' is outside repository
So it seems that 'git diff' accepts absolute paths as long as they end up
in the repository, but oddly enough, doesn't do so for relative paths.
It's possible that some users have scripts that use absolute paths, and
changing the interpretation would break those scripts. Such scripts
*should* be rare, so maybe it's ok to break them, but it needs to be
considered.
James
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: James Pickens @ 2009-11-26 17:56 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091125222037.GA2861@coredump.intra.peff.net>
On Wed, Nov 25, 2009 at 3:20 PM, Jeff King <peff@peff.net> wrote:
> Sure, there are all those downsides. But what is the other option?
> Making me use the command line option (or pathspec magic) every single
> time I invoke git grep?
Yes, but only when you want non-default behavior, not every single time.
> That is a huge downside to me.
Is it *really*? Does it also bother you that you have to tell standalone
unix commands like diff and grep what you want them to diff or grep every
single time you invoke them?
> I started to try to write an argument against this, but I really don't
> know how to. You don't think this particular option gets over the bar.
> Probably because it is not something that has been annoying you
> personally. But is _is_ something that has been annoying me. Now we are
> both making claims from our gut. How do we proceed with a rational
> analysis?
I really think that this config option wouldn't even help you, because
you'll have to remember what that option is set to in each working repo,
and type the right command based on the setting. That seems worse than
having to use the same options over and over again, which you probably use
the shell's history for anyways and don't actually type the same stuff over
and over. Oh and you also have to remember to set the option in each new
repo you create.
If you can get the behavior you want using an alias or a script, then I
suggest you do that. I don't think this config option should be considered
unless *many* people want it, and so far I count only 1.
James
^ permalink raw reply
* Strange behavior of gitweb
From: Alan Stern @ 2009-11-26 17:32 UTC (permalink / raw)
To: git
If this isn't the right place to post this, could somebody please let
me know where would be better?
I recently ran across this strange behavior in the gitweb server at
git.kernel.org. The following URL:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commit;h=2d93148ab6988cad872e65d694c95e8944e1b62
brings up a page containing commit 2d93148[...]. But that commit isn't
part of the 2.6.27.y tree! It belongs to Linus's main tree, and it was
added long after 2.6.27.y was forked off. The actual commit applied to
2.6.27.y was 070bb0f3b6df167554f0ecdeb17a5bcdb1cd7b83.
So what's going on here? Shouldn't the correct behavior be to report
an error, since the requested commit isn't in the history of the
specified tree?
Thanks,
Alan Stern
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Jay Soffian @ 2009-11-26 17:27 UTC (permalink / raw)
To: Thomas Singer; +Cc: Daniel Barkalow, git
In-Reply-To: <4B0CEFCA.5020605@syntevo.com>
On Wed, Nov 25, 2009 at 3:50 AM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
> I've did following:
>
> toms-mac-mini:git-umlauts tom$ ls
> Überlänge.txt
> toms-mac-mini:git-umlauts tom$ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: "U\314\210berla\314\210nge.txt"
> #
Wait, what's the problem here? It's staged according to the above,
just commit it.
j.
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Jay Soffian @ 2009-11-26 17:23 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4B0ABA42.1060103@syntevo.com>
On Mon, Nov 23, 2009 at 11:37 AM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
> I'm on an English OS X 10.6.2 and I created a sample file with umlauts in
> its name (Überlänge.txt). When I try to stage the file in the terminal, I
> can't complete the file name by typing the Ü and hitting the tab key, but I
> can complete it by typing an U and hitting the tab key. Unfortunately, after
> executing
>
> git stage Überlänge.txt
>
> I invoked
>
> git status
>
> and it still shows the file as new file. Should I set some environment
> variable to be able to work with files containing umlauts in the name?
Works for me on 10.6.2:
kore:~/foo (master)$ echo Überlänge.txt > Überlänge.txt
kore:~/foo (master)$ git stage Überlänge.txt
kore:~/foo (master)$ git st
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: "U\314\210berla\314\210nge.txt"
#
kore:~/foo (master)$ git commit -m initial
[master (root-commit) f23e23f] initial
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 "U\314\210berla\314\210nge.txt"
kore:~/foo (master)$ git st
# On branch master
nothing to commit (working directory clean)
Doesn't matter whether LANG and/or LC_* are set or not for me.
j.
^ permalink raw reply
* Re: What should a user expect from git log -M -- file
From: Jakub Narebski @ 2009-11-26 17:14 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20091126163654.GA14509@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> I recently reorganized a project of mine, and the result is that a lot of
> files moved from the top directory to a sub directory.
>
> Now, I innocently tried to 'git log -M' some of these files in the
> subdirectories, and well, the history just stops when the file was
> created. Obviously, if I put both the old and the new location it works,
> but shouldn't users expect 'git log -M -- file' to try to find the
> previous path and continue from there ?
What you want is not
git log -M -- file
but
git log --follow file
"git log -M -- file" IIRC first applies path limiting, simplifying
history, *then* does rename detection, and finally filters output
(unless --full-diff is used).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Octopus merge
From: Michael J Gruber @ 2009-11-26 16:52 UTC (permalink / raw)
To: Claudia.Ignat; +Cc: git
In-Reply-To: <4B0EA512.1050001@loria.fr>
Claudia.Ignat@loria.fr venit, vidit, dixit 26.11.2009 16:56:
> # !/bin/bash
> TEST_NAME="TP1" # name of the working directory
> rm -rf ${TEST_NAME} # cleaning working directory
> mkdir -p ${TEST_NAME}
> cd ${TEST_NAME}
>
> # initialising initial git workspace
> mkdir ws1
> cd ws1
> git init
>
> # adding a file to ws1
> # commit changes
> echo -e -n "1\n2\n3\n4\n5\n" > file.txt
> git add file.txt
> git commit -m "ws1 | add 12345"
> cd ..
>
> # cloning three times ws1 (as ws2, ws3 and ws4)
> git clone ws1 ws2
> git clone ws1 ws3
> git clone ws1 ws4
> git clone ws1 ws5
>
> # updating file.txt in ws2 (insert X at line 3, then write and quit 'ed')
> # commit changes
> cd ws2
> echo -e "3i\nX\n.\nw\nq\n" | ed file.txt
> git add file.txt
> git commit -m "ws2 | insert 12X345"
> cd ..
>
>
> # updating file.txt in ws3 (insert Y at line 3, then write and quit 'ed')
> # commit changes
> cd ws3
> echo -e "3i\nY\n.\nw\nq\n" | ed file.txt
> git add file.txt
> git commit -m "ws3 | insert 12Y345"
> cd ..
>
> cd ws4
> echo -e -n "U1\n2\n3\n4\n5\n" > u.txt
> git add u.txt
> git commit -m "ws4 | add u.txt"
> cd ..
>
> cd ws5
> echo -e -n "W1\n2\n3\n4\n5\n" > w.txt
> git add w.txt
> git commit -m "ws5 | add w.txt"
> cd ..
>
> # ws3 pull from ws2 ws4 ws5
> cd ws3
> git remote add bws2 ../ws2
> git remote add bws4 ../ws4
> git remote add bws5 ../ws5
> git fetch bws2
> git fetch bws4
> git fetch bws5
> git merge bws4/master bws2/master bws5/master
> cd ..
>
> # resolve conflict in ws3
> cd ws3
First of all, thanks for the clear description and test case!
The octopus strategy cannot do merges which need manual resolution. Or
so the doc says. After trying the merge with 4 2 5, Git tells you:
Trying simple merge with 7ff9b5bd514cb600bac935ebd40eae366bba7d19
Trying simple merge with 6872cd350154743d59cb4d313cbdb122ac43e537
Simple merge did not work, trying automatic merge.
Auto-merging file.txt
ERROR: content conflict in file.txt
fatal: merge program failed
Automated merge did not work.
Should not be doing an Octopus.
Merge with strategy octopus failed.
That is, it aborts the merge completely. If you "resolve" it and commit
it's simply a commit that you make.
If, instead, you merge 4 5 2, Git tells you:
Trying simple merge with e4f78f6905bed39bcd96790a4f63e138a455a445
Trying simple merge with 14c1f2a70767334df5d6d3120631752564094699
Trying simple merge with 8540a039d3fc964d097d4f037357668441d1d4f5
Simple merge did not work, trying automatic merge.
Auto-merging file.txt
ERROR: content conflict in file.txt
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.
Admittedly this looks fatal also, but the last line tells you that the
actual merge process is not aborted yet. If you resolve the conflict and
commit without -m you even see the prepared commit message.
So, octopus can deal with manual conflict resolution if the conflicts
appear in the last step only. That is the difference between the two cases.
Now, in the first case the aborted merge leaves some traces in the index
as well as in the worktree. I'm not sure that is how it's supposed to be.
Cheers,
Michael
^ permalink raw reply
* Re: Octopus merge
From: Thomas Rast @ 2009-11-26 16:44 UTC (permalink / raw)
To: Claudia.Ignat; +Cc: git
In-Reply-To: <4B0EA512.1050001@loria.fr>
Claudia.Ignat@loria.fr wrote:
>
> While I am in the current workspace ws3 I perform the merge
>
> git merge ws4 ws2 ws5
>
> Obviously I obtain conflicts between changes in ws3 and ws2 which I fix
> manually and afterwards I commit the new version of ws3.
In doing that last step, you ignored the crucial bit of advice printed
by the octopus merge:
Automated merge did not work.
Should not be doing an Octopus. # <<--
Merge with strategy octopus failed.
You should simply merge and resolve them separately, not least of all
because in doing so, 'git show $merge' will display your merge
resolutions. An octopus would tangle all resolutions into a single
commit.
AFAIK the only thing that can be considered a bug here is that the
octopus strategy leaves your worktree in need of 'reset --hard'.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Robin Rosenberg @ 2009-11-26 16:44 UTC (permalink / raw)
To: Thomas Singer
Cc: Shawn O. Pearce, EGit developer discussion, Marc Strapetz, git
In-Reply-To: <4B0E7DF5.9040007@syntevo.com>
torsdag 26 november 2009 14:09:09 skrev Thomas Singer:
> > But as you said, this still doesn't make the Apple normal form
> > any easier. Though if we know we are on such a strange filesystem
> > we might be able to assume the paths in the repository are equally
> > damaged. Or not.
>
> Well, if the git-core folks could standardize on, e.g., composed UTF-8
> (rather then just UTF-8), for storing file names in the repository, then
> everything should be clear, isn't it?
Hey, we're trying to enforce composed characters...
-- robin
^ permalink raw reply
* What should a user expect from git log -M -- file
From: Mike Hommey @ 2009-11-26 16:36 UTC (permalink / raw)
To: git
Hi,
I recently reorganized a project of mine, and the result is that a lot of
files moved from the top directory to a sub directory.
Now, I innocently tried to 'git log -M' some of these files in the
subdirectories, and well, the history just stops when the file was
created. Obviously, if I put both the old and the new location it works,
but shouldn't users expect 'git log -M -- file' to try to find the
previous path and continue from there ?
Mike
^ permalink raw reply
* Re: Merge priority
From: Martin Langhoff @ 2009-11-26 16:22 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0911260444j45437a92r47d7f2e8b292829e@mail.gmail.com>
On Thu, Nov 26, 2009 at 1:44 PM, Howard Miller
<howard@e-learndesign.co.uk> wrote:
> I now want to update all my customer branches with the latest fixes
> and patches. Naively, I would just check out each branch and merge the
> stable branch - job done.
Yep, that's what I'd do.
> However, is it sensible to ask if there is a
> way to say that the stable branch is more important if there are
> conflicts.
Not really. The git approach is to assume that... when there is a
conflict, you must look into it. A human needs to take a decision...
> Or should I be using rebase instead (which I still don't
> really understand). I'm trying to reduce my workload as there are
> loads of branches to do.
No, rebase will increase the load and complexity.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Octopus merge
From: Claudia.Ignat @ 2009-11-26 15:56 UTC (permalink / raw)
To: git
Hello,
I have problems on understanding the results of octopus merge in the
following scenario.
Workspaces ws2, ws3, ws4 and ws5 are clones of the workspace ws1.
Suppose the current workspace is ws3 and some changes are done in
parallel in all these 4 workspaces. Further suppose that changes of ws2
and ws3 are conflicting, while the changes in ws4 and ws5 are neither
conflicting between them nor with ws2 and ws3.
While I am in the current workspace ws3 I perform the merge
git merge ws4 ws2 ws5
Obviously I obtain conflicts between changes in ws3 and ws2 which I fix
manually and afterwards I commit the new version of ws3. It seems
strange that the commit object has only one parent, while including the
changes of ws4.
If instead I perform
git merge ws4 ws5 ws2
and fix manually the conflicts and performing the commit, the commit
object has 4 parents (ws3,ws4,ws5 and ws2).
I provide below the script illustrating the first scenario:
# !/bin/bash
TEST_NAME="TP1" # name of the working directory
rm -rf ${TEST_NAME} # cleaning working directory
mkdir -p ${TEST_NAME}
cd ${TEST_NAME}
# initialising initial git workspace
mkdir ws1
cd ws1
git init
# adding a file to ws1
# commit changes
echo -e -n "1\n2\n3\n4\n5\n" > file.txt
git add file.txt
git commit -m "ws1 | add 12345"
cd ..
# cloning three times ws1 (as ws2, ws3 and ws4)
git clone ws1 ws2
git clone ws1 ws3
git clone ws1 ws4
git clone ws1 ws5
# updating file.txt in ws2 (insert X at line 3, then write and quit 'ed')
# commit changes
cd ws2
echo -e "3i\nX\n.\nw\nq\n" | ed file.txt
git add file.txt
git commit -m "ws2 | insert 12X345"
cd ..
# updating file.txt in ws3 (insert Y at line 3, then write and quit 'ed')
# commit changes
cd ws3
echo -e "3i\nY\n.\nw\nq\n" | ed file.txt
git add file.txt
git commit -m "ws3 | insert 12Y345"
cd ..
cd ws4
echo -e -n "U1\n2\n3\n4\n5\n" > u.txt
git add u.txt
git commit -m "ws4 | add u.txt"
cd ..
cd ws5
echo -e -n "W1\n2\n3\n4\n5\n" > w.txt
git add w.txt
git commit -m "ws5 | add w.txt"
cd ..
# ws3 pull from ws2 ws4 ws5
cd ws3
git remote add bws2 ../ws2
git remote add bws4 ../ws4
git remote add bws5 ../ws5
git fetch bws2
git fetch bws4
git fetch bws5
git merge bws4/master bws2/master bws5/master
cd ..
# resolve conflict in ws3
cd ws3
echo -e '7d\n5d\n3d\n.\nw\nq\n' | ed file.txt
git add file.txt
git commit -m "ws3| in file.txt solve conflict (kept XY) "
cd ..
Could somebody please explain me these results? I suspect a bug in
octopus merge. I am using version 1.6.3.3 of git.
Thank you in advance.
Best regards,
Claudia Ignat
^ permalink raw reply
* Re: [RFC/PATCH 2/2] status -s: obey color.status
From: Michael J Gruber @ 2009-11-26 16:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4B0EA06A.1050101@viscovery.net>
Johannes Sixt venit, vidit, dixit 26.11.2009 16:36:
> Michael J Gruber schrieb:
>> * Is there any policy regarding use of putchar/puts vs. printf?
>
> If the printed string contains color escapes that should be obeyed, you
> can use only fputs, printf, and fprintf. You should not use puts or putchar.
Oh, I don't use them with colors. I use only color_fprintf for that. I
was wondering whether there's a preference of printf("%c", c) over
putchar(c), for example.
>> * Even if I were to write tests for status -s: How do I test colors?
>
> See t4034-diff-words.sh.
Thanks, I'll keep that in mind for the case that I do have to write test ;)
Michael
^ permalink raw reply
* Re: Merge priority
From: Alex Riesen @ 2009-11-26 15:42 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0911260444j45437a92r47d7f2e8b292829e@mail.gmail.com>
On Thu, Nov 26, 2009 at 13:44, Howard Miller <howard@e-learndesign.co.uk> wrote:
> I now want to update all my customer branches with the latest fixes
> and patches. Naively, I would just check out each branch and merge the
> stable branch - job done. However, is it sensible to ask if there is a
> way to say that the stable branch is more important if there are
> conflicts.
No, all branches are equal. Besides, are you sure it is safe to just take
your stable version of the code in a conflict? Maybe the stable code uses
something a customer branch renamed or removed?
You can take a look at rerere, though. It should help resolving repeating
conflicts by recording a resolution of your choice.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] status -s: obey color.status
From: Johannes Sixt @ 2009-11-26 15:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <26d0a2022638ad7b75268ca291b8d02a22f1f66c.1259248243.git.git@drmicha.warpmail.net>
Michael J Gruber schrieb:
> * Is there any policy regarding use of putchar/puts vs. printf?
If the printed string contains color escapes that should be obeyed, you
can use only fputs, printf, and fprintf. You should not use puts or putchar.
> * Even if I were to write tests for status -s: How do I test colors?
See t4034-diff-words.sh.
-- Hannes
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Thomas Singer @ 2009-11-26 15:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, Marc Strapetz, git
In-Reply-To: <alpine.DEB.1.00.0911261546350.7500@intel-tinevez-2-302>
> You mean we should do the same thing as Apple with HFS? Are you serious?
Yes, I'm serious. IMHO there should be a defined clear encoding used for
files names in the repository. Otherwise you don't know what you can expect
by reading it - it could mean anything. File names are in fact strings which
are based on characters. To convert characters to bytes (or visa versa) you
need to know the encoding.
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 26 Nov 2009, Thomas Singer wrote:
>
>> [someone said, Thomas did not say who]
>>
>>> But as you said, this still doesn't make the Apple normal form any
>>> easier. Though if we know we are on such a strange filesystem we
>>> might be able to assume the paths in the repository are equally
>>> damaged. Or not.
>> Well, if the git-core folks could standardize on, e.g., composed UTF-8
>> (rather then just UTF-8), for storing file names in the repository, then
>> everything should be clear, isn't it?
>
> You mean we should do the same thing as Apple with HFS? Are you serious?
>
> Ciao,
> Dscho
^ permalink raw reply
* [RFC/PATCH 2/2] status -s: obey color.status
From: Michael J Gruber @ 2009-11-26 15:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1259248243.git.git@drmicha.warpmail.net>
Make the short version of status obey the color.status boolean. We color
the status letters only, because they carry the state information and are
potentially colored differently, such as for a file with staged changes
as well as changes in the worktree against the index.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
This is RFC for several reasons:
* Should I rename wt-status.c's color() into something more unique when
I export it?
* Is there any policy regarding use of putchar/puts vs. printf?
* The way it is done now I "color" a space, otherwise one would need to
break down the print statements even more. Since we always color the
foreground only it is no problem, is it?
* Even if I were to write tests for status -s: How do I test colors?
builtin-commit.c | 20 +++++++++++++++-----
wt-status.c | 2 +-
wt-status.h | 1 +
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index c103beb..c38fc96 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -999,7 +999,7 @@ static void short_unmerged(int null_termination, struct string_list_item *it,
case 6: how = "AA"; break; /* both added */
case 7: how = "UU"; break; /* both modified */
}
- printf("%s ", how);
+ color_fprintf(s->fp, color(WT_STATUS_UNMERGED, s), "%s ", how);
if (null_termination) {
fprintf(stdout, "%s%c", it->string, 0);
} else {
@@ -1016,9 +1016,14 @@ static void short_status(int null_termination, struct string_list_item *it,
{
struct wt_status_change_data *d = it->util;
- printf("%c%c ",
- !d->index_status ? ' ' : d->index_status,
- !d->worktree_status ? ' ' : d->worktree_status);
+ if (d->index_status)
+ color_fprintf(s->fp, color(WT_STATUS_UPDATED, s), "%c", d->index_status);
+ else
+ putchar(' ');
+ if (d->worktree_status)
+ color_fprintf(s->fp, color(WT_STATUS_CHANGED, s), "%c ", d->worktree_status);
+ else
+ printf(" ");
if (null_termination) {
fprintf(stdout, "%s%c", it->string, 0);
if (d->head_path)
@@ -1046,7 +1051,8 @@ static void short_untracked(int null_termination, struct string_list_item *it,
struct strbuf onebuf = STRBUF_INIT;
const char *one;
one = quote_path(it->string, -1, &onebuf, s->prefix);
- printf("?? %s\n", one);
+ color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "?? ");
+ puts(one);
strbuf_release(&onebuf);
}
}
@@ -1115,6 +1121,10 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_SHORT:
if (s.relative_paths)
s.prefix = prefix;
+ if (s.use_color == -1)
+ s.use_color = git_use_color_default;
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
short_print(&s, null_termination);
break;
case STATUS_FORMAT_PORCELAIN:
diff --git a/wt-status.c b/wt-status.c
index 3c2f580..c779b7c 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -19,7 +19,7 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {
GIT_COLOR_RED, /* WT_STATUS_UNMERGED */
};
-static const char *color(int slot, struct wt_status *s)
+const char *color(int slot, struct wt_status *s)
{
return s->use_color > 0 ? s->color_palette[slot] : "";
}
diff --git a/wt-status.h b/wt-status.h
index 09fd9f1..22b15b0 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -55,5 +55,6 @@ struct wt_status {
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
+const char *color(int slot, struct wt_status *s);
#endif /* STATUS_H */
--
1.6.6.rc0.274.g71380
^ permalink raw reply related
* [RFC/PATCH 1/2] status -s: respect the status.relativePaths option
From: Michael J Gruber @ 2009-11-26 15:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1259248243.git.git@drmicha.warpmail.net>
so that 'status' and 'status -s' in a subdir produce the same file
names.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Anything else would be highly surprising. Note that the porcelain case
is unchanged, of course.
builtin-commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7f888fe..c103beb 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1113,6 +1113,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
switch (status_format) {
case STATUS_FORMAT_SHORT:
+ if (s.relative_paths)
+ s.prefix = prefix;
short_print(&s, null_termination);
break;
case STATUS_FORMAT_PORCELAIN:
--
1.6.6.rc0.274.g71380
^ permalink raw reply related
* [RFC/PATCH 0/2] status -s: Use the same config as status
From: Michael J Gruber @ 2009-11-26 15:24 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This mini series is an RFC for bringing the short version of status in line
with the longer one. They already both obey status.showUntrackedFiles.
Currently, status -s does not obey status.relativePaths nor
color.status.
I think status should follow the priniciple of least surprise here in
the sense that -s should not change other aspects of the output
(although it is very different internally).
I think we don't have any tests for status -s yet, which is one reason
why this is an RFC: I don't expect to get through with it, like the
introducer of status -s did ;) Another reason is mentioned in 2/2.
Michael J Gruber (2):
status -s: respect the status.relativePaths option
status -s: obey color.status
builtin-commit.c | 22 +++++++++++++++++-----
wt-status.c | 2 +-
wt-status.h | 1 +
3 files changed, 19 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Johannes Schindelin @ 2009-11-26 14:47 UTC (permalink / raw)
To: Thomas Singer
Cc: Shawn O. Pearce, EGit developer discussion, Marc Strapetz, git
In-Reply-To: <4B0E7DF5.9040007@syntevo.com>
Hi,
On Thu, 26 Nov 2009, Thomas Singer wrote:
> [someone said, Thomas did not say who]
>
> > But as you said, this still doesn't make the Apple normal form any
> > easier. Though if we know we are on such a strange filesystem we
> > might be able to assume the paths in the repository are equally
> > damaged. Or not.
>
> Well, if the git-core folks could standardize on, e.g., composed UTF-8
> (rather then just UTF-8), for storing file names in the repository, then
> everything should be clear, isn't it?
You mean we should do the same thing as Apple with HFS? Are you serious?
Ciao,
Dscho
^ permalink raw reply
* Re: [egit] Git repository with multiple eclipse projects ?
From: Yann Dirson @ 2009-11-26 14:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091126004817.GL11919@spearce.org>
On Wed, Nov 25, 2009 at 04:48:17PM -0800, Shawn O. Pearce wrote:
> > When importing a git repo into eclipse, we get a list of projects to
> > import, but that list is empty. What is expected by egit to get this
> > list filled ?
>
> There should be .project files in the repository. I think we scan
> the entire checkout tree for .project files, but maybe we are doing
> something stupid and only looking at the top level directory of
> the checkout.
Right, we could make it work - the devs just did not have the habbit
of commiting .project files.
> > It also does not look like it would be possible to use the "share"
> > functionnality to setup such a repository from multiple projects (or
> > from a project set), right ?
>
> Nope, I don't think this is supported right now. You need to
> initialize the git repository by hand in the higher level directory
> that holds the projects.
Yes, we did that by git-add'ing the initial projects manually and
pushing them, and we can now "import" that.
That makes me wonder if it should work to add a new project afterwards
from within Eclipse. If we create a new project under the git tree,
and try to use "share", then we get presented a folded list containing
the project we want to add, which when unfolded reveals "..\.git"
(yes, this test done on windows) as repository, which is promising.
But then the field below near the "Create" button (the one with
"\.git" text on the right) gets polulated with the full project path
when we click on the project in the list, and we could not unlock the
"next" or "finish" button. Are we just trying things the way they
should work but hit functionnality that is just not finished, or are
we completely off-track ?
Thanks much,
--
Yann
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Marc Strapetz @ 2009-11-26 14:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: EGit developer discussion, git, robin.rosenberg
In-Reply-To: <20091126005423.GM11919@spearce.org>
> We should try to work harder with the git-core folks to get character
> set encoding for file names worked out. We might be able to use a
> configuration setting in the repository to tell us what the proper
> encoding should be, and if not set, assume UTF-8.
I agree that this should be the ultimate goal, though the default should
better be "system encoding" for compatibility with current git
repositories and instead have newer git versions always set encoding to
UTF-8. Thus, for our jgit clone I've introduced a system property to
configure Constants.PATH_ENCODING set to system encoding. It's used by
PathFilter and this resolves my original problem.
I have tried to switch more usages from Constants.CHARACTER_ENCODING to
Constants.PATH_ENCODING, but ended up in confusion due to my lack of
understanding: primarily because I couldn't tell anymore whether encoded
strings were file names or not. Does it make sense to explicitly
distinguish encoding usages in that way? We could try to contribute here
(and hopefully cause less review effort to jgit developers than the
changes itself are worth ;-)
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Shawn O. Pearce wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
>> onsdag 25 november 2009 14:47:25 skrev Marc Strapetz:
>>> I have noticed that jgit converts file paths to UTF-8 when querying the
>>> repository.
> ...
>>> Is this a bug or a misconfiguration of my repository? I'm using jgit
>>> (commit e16af839e8a0cc01c52d3648d2d28e4cb915f80f) on Windows.
>> A bug.
>>
>> The problem here is that we need to allow multiple encodings since there
>> is no reliable encoding specified anywhere.
>
> This is a design fault of both Linux and git. git gets a byte
> sequence from readdir and stores that as-is into the repository.
> We have no way of knowing what that encoding is. So now everyone
> touching a Git repository is screwed.
>
>> The approach I advocate is
>> the one we use for handling encoding in general. I.e. if it looks like UTF-8,
>> treat it like that else fallback. This is expensive however
>
> We should try to work harder with the git-core folks to get character
> set encoding for file names worked out. We might be able to use a
> configuration setting in the repository to tell us what the proper
> encoding should be, and if not set, assume UTF-8.
>
>> and then we have
>> all the other issues with case insensitive name and the funny property that
>> unicode has when it allows characters to be encoding using multiple sequences
>> of code points as empoloyed by Apple.
>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
>
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Michael J Gruber @ 2009-11-26 13:39 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Matthieu Moy, git, gitster
In-Reply-To: <36ca99e90911260501q571929e5l114cb0af9f374a98@mail.gmail.com>
Bert Wesarg venit, vidit, dixit 26.11.2009 14:01:
> On Thu, Nov 26, 2009 at 13:00, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Matthieu Moy venit, vidit, dixit 26.11.2009 11:35:
>>> Most users will set it to ~/.gitsomething. ~/.gitignore would conflict
>>> with per-directory ignore file if ~/ is managed by Git, so ~/.gitexcludes
>>> is a sane default.
>>
>> I'm sorry to jump in so late, and this may sound like bike-shedding, but
>> right now we have
>>
>> .git/info/exclude
>> .gitignore
>>
>> and this would add
>>
>> ~/.gitexcludes
>>
>> That is, three terms, or two, where one comes in two variations
>> (exclude/exludes). I always wondered why we have two.
>>
>> The reason for .gitignore is most probably the similarity to
>> .${othervcs}ignore, and that is a valid reason.
>>
>> I know we have ~/.gitconfig for the global version of .git/config, and
>> maybe that was just no good idea either. But I don't even dare
>> suggesting to rename it ~/.gitglobalconfig.
>>
>> So, in line at least with our term "global" (per user) config, I would
>> suggest to use "~/.gitglobalignore" for the global ignore file. Maybe,
>> eventually, we'll manage to rename .git/info/excludes to .git/info/ignore.
>>
>> On a somewhat larger scale, a good alternative strategy would be to have
>> a directory "~/.gitglobal/" in which Git would look for
>> ~/.gitglobal/config and
>> ~/.gitglobal/info/ignore or
>> ~/.gitglobal/ignore
>>
>> i.e. mirroring the repo structure or at least bundling everything in a
>> single dir, which would also be a good place for a global svnauthors
>> file and such, and for other global configuration files we don't think
>> of right now.
> I would vote for that too. Its more future-proof than a single new
> file. Also I would suggest to name this dir ~/.gitrc/.
Now, that is bike shedding ;)
It seems to me that all ~/.*rc that I have are config files (.bashrc,
.xinitrc...), and all condif subdirs ~/.* are named by the
program/subsystem (.qt, .kde, .gnupg), which we cannot do any more, and
which is why I suggested .gitglobal. But I'd be fine with .gitrc.
> On the other
> hand the --global option to git config specifies the .gitconfig in
> your HOME.
That would have to change (ouch, ducking). Transition plan would be:
~/.gitconfig, ~/.gitrc/config::
User-specific configuration file. Also called "global"
configuration file. Git looks in these locations in the
specified order and uses the first one it finds.
$(prefix)/etc/gitconfig, $(prefix)/etc/gitrc/config::
System-wide configuration file. Git looks in these locations
in the specified order and uses the first one it finds.
This would mean no surprises for users with existing config, one could
teach the new preferred locations exclusively, and at some future point
one could phase out the old paths.
Michael
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Michael J Gruber @ 2009-11-26 13:27 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git
In-Reply-To: <helthi$8k5$1@ger.gmane.org>
Paolo Bonzini venit, vidit, dixit 26.11.2009 13:49:
> On 11/26/2009 01:00 PM, Michael J Gruber wrote:
>> I'm sorry to jump in so late, and this may sound like bike-shedding, but
>> right now we have
>>
>> .git/info/exclude
>> .gitignore
>>
>> and this would add
>>
>> ~/.gitexcludes
>>
>> That is, three terms, or two, where one comes in two variations
>> (exclude/exludes). I always wondered why we have two.
>
> Would you be fine with ~/.gitexclude?
Not really. You see, a user tracking his $HOME will have a ~/.gitignore
and a ~/.gitexclude then. I think we should distinguish local and global
"config" files more systematically. Which is why I suggested the subdir,
or having global in the name.
Michael
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Thomas Singer @ 2009-11-26 13:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: EGit developer discussion, Marc Strapetz, git
In-Reply-To: <20091126005423.GM11919@spearce.org>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
Well, if the git-core folks could standardize on, e.g., composed UTF-8
(rather then just UTF-8), for storing file names in the repository, then
everything should be clear, isn't it?
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Shawn O. Pearce wrote:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
>> onsdag 25 november 2009 14:47:25 skrev Marc Strapetz:
>>> I have noticed that jgit converts file paths to UTF-8 when querying the
>>> repository.
> ...
>>> Is this a bug or a misconfiguration of my repository? I'm using jgit
>>> (commit e16af839e8a0cc01c52d3648d2d28e4cb915f80f) on Windows.
>> A bug.
>>
>> The problem here is that we need to allow multiple encodings since there
>> is no reliable encoding specified anywhere.
>
> This is a design fault of both Linux and git. git gets a byte
> sequence from readdir and stores that as-is into the repository.
> We have no way of knowing what that encoding is. So now everyone
> touching a Git repository is screwed.
>
>> The approach I advocate is
>> the one we use for handling encoding in general. I.e. if it looks like UTF-8,
>> treat it like that else fallback. This is expensive however
>
> We should try to work harder with the git-core folks to get character
> set encoding for file names worked out. We might be able to use a
> configuration setting in the repository to tell us what the proper
> encoding should be, and if not set, assume UTF-8.
>
>> and then we have
>> all the other issues with case insensitive name and the funny property that
>> unicode has when it allows characters to be encoding using multiple sequences
>> of code points as empoloyed by Apple.
>
> But as you said, this still doesn't make the Apple normal form
> any easier. Though if we know we are on such a strange filesystem
> we might be able to assume the paths in the repository are equally
> damaged. Or not.
>
^ 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