* 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
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Bert Wesarg @ 2009-11-26 13:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Matthieu Moy, git, gitster
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>
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/. On the other
hand the --global option to git config specifies the .gitconfig in
your HOME.
Bert
>
> Michael
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Paolo Bonzini @ 2009-11-26 12:49 UTC (permalink / raw)
To: git
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>
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?
Paolo
^ permalink raw reply
* Re: Working on merged branches whilst seeing current master
From: Tim Mazid @ 2009-11-26 12:45 UTC (permalink / raw)
To: git
In-Reply-To: <1258044562803-3994102.post@n2.nabble.com>
rhlee wrote:
>
>
> Tim Mazid wrote:
>>
>> Actually, there's no reason you couldn't just 'git reset HEAD^' once you
>> realise that the branch isn't ready. If you want to see the changes from
>> master, you could just merge that into your branch. If you just want to
>> see the content in master, you could use gitk or gitg, which allows you
>> to view files at any commit.
>>
>> Personally, I merge master into my branches, test and check, and fix,
>> then merge the branch into master. This sometimes results in a
>> fast-forward, if you haven't made changes to master. If you don't like
>> that, you can always use the --no-ff option, though.
>>
>
> I don't think 'git reset HEAD^' would work in my case as that only goes
> back one commit. I may have made many other changes on the master branch
> that I want to keep.
>
> By merging from master into your branch, like you said, you get a nice
> graph view that shows what you've brought into your branch from master
> since you last left off. But doesn't this goes against the idea that
> branches should be independent, by bringing in changes from master?
>
Yup, you only need to 'git reset HEAD^' on the master branch to undo the
merge. Isn't that what you wanted?
And yeah, I suppose it kind of does. But once again, you can 'git reset
HEAD^'. And since you're merging master INTO the branches, you are keeping
the branches independent, anyway.
--
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p4070977.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Merge priority
From: Howard Miller @ 2009-11-26 12:44 UTC (permalink / raw)
To: git
I'm not sure this is even a sensible question....
I have a whole bunch of customer branches with all manner of local
tweaks and modifications. I also have a stable branch with all my
security patches and bug fixes. They do share common ancestry.
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. 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.
Cheers :-)
^ permalink raw reply
* [StGit] push/pull stacked patches
From: Kurt Harriman @ 2009-11-26 12:17 UTC (permalink / raw)
To: git
Suppose two developers are collaborating on a series of patches.
What is the best way to synchronize their repositories, including
the StGit state?
Even if both repositories are StGit-enabled, the patch metadata
and unapplied patches don't seem to be transferred by push/pull.
Applied patches are transferred as ordinary commits, losing
their patch names and their place in the patch stack.
It seems that a remote branch cannot have a patch stack.
Instead of using push/pull, a patch series can be transferred
using stg export/import, but this is error-prone, requiring
extra steps, and changes the commit timestamp and SHA1.
Stg export/import are good for distributing the final version
of a patch series; but ungitly for back-and-forth collaboration.
Is there a better way?
^ permalink raw reply
* Re: [PATCH] Give the hunk comment its own color
From: Bert Wesarg @ 2009-11-26 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vaayjebu5.fsf@alter.siamese.dyndns.org>
Junio,
may I kindly remind you of this patch. If it is only the nen-existing
consensus of the default color, than please use the die.
Kind regards,
Bert Wesarg
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Michael J Gruber @ 2009-11-26 12:00 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <1259231726-5218-1-git-send-email-Matthieu.Moy@imag.fr>
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.
Michael
^ permalink raw reply
* Re: [PATCH/RFC 02/11] strbuf: add non-variadic function strbuf_vaddf()
From: Paolo Bonzini @ 2009-11-26 11:13 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <40aa078e0911260238rd0c90cag126709d1de5f50de@mail.gmail.com>
On 11/26/2009 11:38 AM, Erik Faye-Lund wrote:
> In practice it seems that something like the following works
> portably-enough for many applications, dunno if it's something we'll
> be happy with:
> #ifndef va_copy
> #define va_copy(a,b) ((a) = (b))
> #endif
Yes, this is correct.
Paolo
^ 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