* 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
* 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: 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: 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: 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: 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
* 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: [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
* 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 (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: Junio C Hamano @ 2009-11-26 18:18 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Matthieu Moy, git
In-Reply-To: <4B0E6DC9.3070105@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> I'm sorry to jump in so late, and this may sound like bike-shedding, but
> right now we have
>
> .git/info/exclude
> .gitignore
The current dir.c::setup_standard_excludes() implementation reads exclude
patterns from "$GIT_DIR/info/exclude".
As to the way forward regarding "info/exclude", my preference is to teach
the codepath to check if "info/ignore" exists, and read that after it
reads from "info/exclude" (to give the new file a slightly higher
precedence if both exist).
Document that we read from both info/ignore and info/exclude immediately
when this change happens. The updated documentation probably should say
that "info/exclude" is still read and will be read forever, and tell the
readers that there is no difference in functionality between the two,
other than that "info/ignore" is a name that is more consistent with the
".gitignore" (which is the name of in-tree exclude patterns file).
And stop there.
While there is no reason to encourage new repositories to use info/exclude
over info/ignore, we shouldn't stop mentioning info/exclude or declare
deprecation in the documentation, as doing so would:
(1) scare existing users that their info/exclude file may become invalid
some day; and
(2) puzzle new users (who inherited an already initialized repository
that has been maintained by somebody else from the era before this
change) what the info/exclude file in the repository is doing.
> 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 try not to get involved in bike-shedding (I removed myself from Cc), but
the events happened in the opposite order.
Originally we had the concept of "exclude patterns", in 9ff768e ([PATCH]
Give show-files the ability to process exclusion pattern., 2005-04-28).
This origin is still visible in the names of command line options to
"ls-files". It was just a flat text file that is not tied to any
particular directory in the work tree.
Then much later in f87f949 (git-ls-files: --exclude mechanism updates.,
2005-07-24) the mechanism was extended, so that we could add per-directory
exclude patterns. But that was just the _ability_; its actual use in the
Porcelains had to wait until ba966b9 (Teach git-status-script about
git-ls-files --others, 2005-08-26), and the commit finally established the
name ".gitignore" that is an in-tree, per-directory file that has exclude
patterns. The name was inconsistent with the established concept of
"excluding", but was chosen to be similar to .scmignore.
Hopefully that would clear your wondering.
^ permalink raw reply
* Re: [PATCH/RFC 02/11] strbuf: add non-variadic function strbuf_vaddf()
From: Junio C Hamano @ 2009-11-26 18:46 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs, Alex Riesen
In-Reply-To: <40aa078e0911260238rd0c90cag126709d1de5f50de@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
> On Thu, Nov 26, 2009 at 1:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Erik Faye-Lund <kusmabite@googlemail.com> writes:
>>
>>> +void strbuf_vaddf(struct strbuf *sb, const char *fmt, va_list ap)
>>> {
>>> int len;
>>>
>>> if (!strbuf_avail(sb))
>>> strbuf_grow(sb, 64);
>>> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
>>> if (len < 0)
>>> die("your vsnprintf is broken");
>>> if (len > strbuf_avail(sb)) {
>>> strbuf_grow(sb, len);
>>> len = vsnprintf(sb->buf + sb->len, sb->alloc - sb->len, fmt, ap);
>>> if (len > strbuf_avail(sb)) {
>>> die("this should not happen, your snprintf is broken");
>>> }
>>
>> Hmm, I would have expected to see va_copy() somewhere in the patch text.
>> Is it safe to reuse ap like this in two separate invocations of
>> vsnprintf()?
>
> I think your expectation is well justified, this seems to be a
> portability-bug waiting to happen. Sorry for missing this prior to
> sending out - on Windows this is known to work, and this function is
> currently only used from the Windows implementation of syslog.
>
> How kosher is it to use va_copy in the git-core, considering that it's
> C99? A quick grep reveals only one occurrence of va_copy in the
> source, and that's in compat/winansi.c. Searching the history of next
> reveals that Alex Riesen (CC'd) already removed one occurrence
> (4bf5383), so I'm starting to get slightly scared it might not be OK.
We tend to avoid C99 features and it saved us in a few occasions. Recent
MSVC port revealed that we still had a handful of decl-after-statments but
luckily the necessary fix-ups were minimal because I have been reasonably
careful to reject patches that add it long before MSVC port happened.
> 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
Since an obvious implementation of va_list would be to make it a pointer
into the stack frame, doing the above would work on many systems. On
esoteric systems that needs something different (e.g. where va_list is
implemented as a size-1 array of pointers, va_copy(a,b) needs to be an
assignment (*(a) = *(b))), people can add compatibility macro later.
Historically some systems that do have a suitable implementation had it
under the name __va_copy() instead, so it would have been better to define
it as something like:
#ifndef va_copy
# ifdef __va_copy
# define va_copy(a,b) __va_copy(a,b)
# else
# /* fallback for the most obvious implementation of va_list */
# define va_copy(a,b) ((a) = (b))
# endif
#endif
But I do not know it still matters in practice anymore.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] status -s: obey color.status
From: Junio C Hamano @ 2009-11-26 19:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael J Gruber, git, Junio C Hamano
In-Reply-To: <4B0EA06A.1050101@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> 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.
This msysgit-imposed restriction is something even I do not remember
offhand. Could you please document it somewhere in a file any developer
would get by checking out the 'master' branch of git.git?
^ permalink raw reply
* [PATCH] send-email: automatic envelope sender
From: Felipe Contreras @ 2009-11-26 19:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
This adds the option to specify the envelope sender as "auto" which
would pick the 'from' address. This is good because now we can specify
the address only in one place (and change it easily).
Comments by Junio C Hamano.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-send-email.txt | 7 ++++---
git-send-email.perl | 6 +++++-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index c85d7f4..8c482f4 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -108,9 +108,10 @@ Sending
--envelope-sender=<address>::
Specify the envelope sender used to send the emails.
This is useful if your default address is not the address that is
- subscribed to a list. If you use the sendmail binary, you must have
- suitable privileges for the -f parameter. Default is the value of
- the 'sendemail.envelopesender' configuration variable; if that is
+ subscribed to a list. In order to use the 'From' address, set the
+ value to "auto". If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter. Default is the value of the
+ 'sendemail.envelopesender' configuration variable; if that is
unspecified, choosing the envelope sender is left to your MTA.
--smtp-encryption=<encryption>::
diff --git a/git-send-email.perl b/git-send-email.perl
index 4f5da4e..da2e56e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -862,7 +862,11 @@ X-Mailer: git-send-email $gitversion
my @sendmail_parameters = ('-i', @recipients);
my $raw_from = $sanitized_sender;
- $raw_from = $envelope_sender if (defined $envelope_sender);
+ if (defined $envelope_sender) {
+ if (not $envelope_sender eq "auto") {
+ $raw_from = $envelope_sender;
+ }
+ }
$raw_from = extract_valid_address($raw_from);
unshift (@sendmail_parameters,
'-f', $raw_from) if(defined $envelope_sender);
--
1.6.6.rc0.61.geeb75
^ permalink raw reply related
* [PATCH 0/2] format-patch: fix dashdash
From: Felipe Contreras @ 2009-11-26 19:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
This doesn't work
git format-patch <committish> -- <path not in working dir>
So here are some fixes and a test.
Felipe Contreras (2):
format-patch: fix dashdash usage
format-patch: add test for dashdash
builtin-log.c | 3 ++-
t/t4014-format-patch.sh | 4 ++++
2 files changed, 6 insertions(+), 1 deletions(-)
^ permalink raw reply
* [PATCH 1/2] format-patch: fix dashdash usage
From: Felipe Contreras @ 2009-11-26 19:11 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1259262720-24077-1-git-send-email-felipe.contreras@gmail.com>
Otherwise 'git format-patch <committish> -- <non-existent-path>' doesn't
work.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin-log.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 33fa6ea..1766349 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -976,7 +976,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
*/
argc = parse_options(argc, argv, prefix, builtin_format_patch_options,
builtin_format_patch_usage,
- PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN);
+ PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN |
+ PARSE_OPT_KEEP_DASHDASH);
if (do_signoff) {
const char *committer;
--
1.6.6.rc0.61.geeb75
^ permalink raw reply related
* [PATCH 2/2] format-patch: add test for dashdash
From: Felipe Contreras @ 2009-11-26 19:12 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1259262720-24077-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
t/t4014-format-patch.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 7f267f9..d5b002d 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -536,6 +536,10 @@ test_expect_success 'format-patch --signoff' '
grep "^Signed-off-by: $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"
'
+test_expect_success 'format-patch -- <path>' '
+ git format-patch master..side -- file
+'
+
echo "fatal: --name-only does not make sense" > expect.name-only
echo "fatal: --name-status does not make sense" > expect.name-status
echo "fatal: --check does not make sense" > expect.check
--
1.6.6.rc0.61.geeb75
^ permalink raw reply related
* Re: [RFC/PATCHv8 08/10] fast-import: Proper notes tree manipulation using the notes API
From: Shawn O. Pearce @ 2009-11-26 19:33 UTC (permalink / raw)
To: Johan Herland; +Cc: git, gitster
In-Reply-To: <200911261210.48138.johan@herland.net>
Johan Herland <johan@herland.net> wrote:
> BTW, while we're on the topic, this whole code is only present because I
> assume it's not possible to edit the fast-import tree structure _while_
> traversing it. Is this assumption correct, or are there ways to get
> around maintaining a separate edit list that is applied to the tree
> structure afterwards?
IIRC you can actually edit the tree while you are walking through it.
You just have to watch out for the fact that a struct tree_content
can be reallocated (and thus moved in memory) if the entry_capacity
was too small for the new entry_count when inserting a new entry.
tree_content_set() handles this in its API by taking a struct
tree_entry* rather than a struct tree_content*. This way if the
tree has to expand during the set and gets reallocated we can return
the new tree pointer to the caller through the struct tree_entry
tree field.
--
Shawn.
^ permalink raw reply
* Re: Merge priority
From: Junio C Hamano @ 2009-11-26 19:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: Howard Miller, git
In-Reply-To: <81b0412b0911260742l4beb2305y87c01dd61d7c2b57@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> You can take a look at rerere, though. It should help resolving repeating
> conflicts by recording a resolution of your choice.
Use of rerere often helps but there is a caveat.
Even if two branches (e.g. 'master' and 'maint') currently has the same
tree, the desired outcome of merging the same commit into them could be
different depending on the purpose of these branches. You may want to
resolve a conflicted merge into 'maint' more conservatively than the way
you would resolve the exact same merge into 'master'.
Imagine a case where 'master' branch added a better helper functions in
other files, but they are not in 'maint' yet, and the conflicted part
could be resolved better if you made it call these newer helper functions
available only in 'master'.
Unfortunately the conflicts would look exactly the same to rerere, so if
you record the result of the merge to 'master', replaying that resolution
while merging the same commit to 'maint' would produce undesirable result.
As to "does the aggregated result make sense if you blindly add changes in
'stable' for only conflicted parts to an automerge result?", which was
your other point, you may refer your readers to Avery's recent updates to
resurrect -Xours option to "git merge".
^ permalink raw reply
* Re: [PATCH 1/2] format-patch: fix dashdash usage
From: Junio C Hamano @ 2009-11-26 19:57 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1259262720-24077-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Otherwise 'git format-patch <committish> -- <non-existent-path>' doesn't
> work.
Instead of "doesn't work", I really wished you wrote something like:
$ git format-patch <commit> -- <path>
complains that <path> does not exist in the current work tree and the
user needs to explicitly specify "--", even though the user _did_ give
a "--". This is because it incorrectly removes "--" from the command
line arguments that is later passed to setup_revisions().
Remember that you are trying to help somebody who has to write Release
Notes out of "git log" output.
I actually have a bigger question, though. Does it even make sense to
allow pathspecs to format-patch? We sure are currently loose and take
them, but I doubt it is by design.
The patch itself looks good and is a candidate 'maint' material, if the
answer to the above question is a convincing "yes, because ...".
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Shawn O. Pearce @ 2009-11-26 19:57 UTC (permalink / raw)
To: Thomas Singer; +Cc: Johannes Schindelin, Marc Strapetz, git
In-Reply-To: <4B0E9F69.9040502@syntevo.com>
Thomas Singer <thomas.singer@syntevo.com> wrote:
> > 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.
That's likely not going to fly. HFS+ has changed their decomposition
rules at least once, which means the byte sequence for the same
character sequence would differ, and a tree or commit hash would
come out different depending upon which rules you were following.
See [1] for details on what HFS+ does.
Also, Linus has previously stated HFS+ chose the worst possible
way to encode the names. Getting Linus to admit he was wrong is
impossible, getting Linus to accept the HFS+ encoding rules as the
standard format used in a Git repository is not likely to happen.
Fortunately Linus carries a slightly smaller stick in Git than he
used to, but he is quite vocal and people tend to listen.
[1] http://developer.apple.com/mac/library/technotes/tn/tn1150.html#UnicodeSubtleties
--
Shawn.
^ permalink raw reply
* Re: [egit-dev] Re: jgit problems for file paths with non-ASCII characters
From: Shawn O. Pearce @ 2009-11-26 20:03 UTC (permalink / raw)
To: Marc Strapetz; +Cc: EGit developer discussion, git, robin.rosenberg
In-Reply-To: <4B0E8FF2.8040206@syntevo.com>
Marc Strapetz <marc.strapetz@syntevo.com> wrote:
> > 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.
That's probably a good point, using the system encoding on a
repository may produce the file names in a more compatible way
with git-core. But we probably don't want the encoding to be a
single encoding constant in this JVM, we probably need to support
a per-repository configuration of the encoding for path names so
that we can eventually move to a non-platform specific encoding.
> 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.
Heh. Yea. There are a number of file name encoding sites. I think
everything in the treewalk package, as well as the GitIndex, Tree and
DirCache* classes. Also the Patch class and its FileHeader friend.
> 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 ;-)
Yes, it does. Because we eventually need to support encodings
other than the current UTF-8 we assume for file names, especially
if a repository is using the local filesystem encoding and that
isn't UTF-8.
--
Shawn.
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 00/11] daemon-win32
From: Johannes Sixt @ 2009-11-26 20:04 UTC (permalink / raw)
To: msysgit; +Cc: Erik Faye-Lund, git, dotzenlabs, Erik Faye-Lund
In-Reply-To: <1259196260-3064-1-git-send-email-kusmabite@gmail.com>
On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
> This is my stab at cleaning up Mike Pape's patches for git-daemon
> on Windows for submission, plus some of my own.
Please rebase the series on top of current master. I'd appreciate if you could
make it available to pull from somewhere. I've a version here:
git://repo.or.cz/git/mingw/j6t.git ef/mingw-daemon
(including Martin's getaddrinfo updates) but the resulting git-daemon crashes
immediately after there is a connection.
-- Hannes
^ permalink raw reply
* Re: [PATCH (resend)] Let core.excludesfile default to ~/.gitexcludes.
From: David Aguilar @ 2009-11-26 20:07 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Bert Wesarg, Matthieu Moy, git, gitster
In-Reply-To: <4B0E8529.3040609@drmicha.warpmail.net>
On Thu, Nov 26, 2009 at 02:39:53PM +0100, Michael J Gruber wrote:
>
> 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
If we're going to bikeshed then let's throw a standard in there:
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
~/.gitrc/ doesn't make sense (it's not a file) and ~/.gitglobal/
hurts my eyes.
"global"? Huh? Isn't it really user-specific?
Why not call it ~/.gituser/ then?
And what about the standard?
The silly standard says to use ~/.config/git/.
I'm quite happy with ~/.gitconfig and ~/.gitexclude if that's all
there is to git's per-user configuration abilities, especially
since ~/.gitexclude is less common. _Much_ less common from
what I've seen in practice.
Being that we cannot predict the future then there is some
appeal to a top-leve ~/.config/git/-like directory. But...
Like Junio said, I would stop only after adding support for
the new paths. We don't want to confuse old or new users
and we should never deprecate existing ~/.gitconfig.
So now the "user" config is not just tied to one file but
is instead multiple files? I dunno.. I kinda don't like
that but the only reason is because I'm going to have to
go and change code to take that into account.
When I have to change code for little added benefit
I ask questions.
What about:
$ git config --global foo.bar baz
What file does that touch?
~/.gitconfig or ~/.config/git/config?
What if ~/.gitconfig exists and ~/.config/git/config doesn't?
What about vice versa?
Okay, I also don't like it for that reason.
What if you jump between git versions? Now the previous
question is much more important -- it means that we *must*
write to ~/.gitconfig to keep backwards compatibility otherwise
someone will config something with git-vNew and be surprised
when git-vOld does not find it.
And if we must write to ~/.gitconfig then
why does ~/.config/git/config even exist?
I guess all I'm saying is that I'm quite happy with
~/.gitconfig and do not see a compelling reason as
to why we'd need to transition to a different path.
Yes, I'm being lazy. I don't feel like changing code
when stuff works just fine right now ;-)
And if we were to change it, then what about JGit,
Dulwich, GitSharp, etc? Who's going to change those?
To quote an old famous horse, "No sir, I don't like it."
--
David
^ permalink raw reply
* [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Jakub Narebski @ 2009-11-26 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <200911260159.48311.jnareb@gmail.com>
On Thu, 26 Nov 2009, Jakub Narebski wrote:
> On Thu, 26 Nov 2009, Junio C Hamano wrote:
> > A follow-up patch to add a gitweb configuration switch that disables the
> > non-working view by default but allows site owners to enable it in order
> > to help improving the feature would be a sensible thing to do. As long as
> > that patch is solidly done we can merge the whole thing to 'master' in the
> > upcoming release.
>
> But if it is already in 'next', then I'll try to come up with patch which
> makes JavaScript-ing links (replacing links with JavaScript to equivalent
> actions utilizing JavaScript, currently only 'blame' -> 'blame_incremental')
> configurable.
Here it is. I am a bit ambiguous about *naming* of this feature (and
whether it should be overridable), that's why it is marked as RFC.
Also the subject of this commit could have been better, I think...
-- >8 --
Let gitweb turn some links (like 'blame' links) into linking to
actions which require JavaScript (like 'blame_incremental' action)
only if 'javascript-actions' feature is enabled.
This means that links to such actions would be present only if both
JavaScript is enabled and 'javascript-actions' feature is enabled.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a80cbd3..0ab47e1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -432,6 +432,13 @@ our %feature = (
'timed' => {
'override' => 0,
'default' => [0]},
+
+ # Enable turning some links into links to actions which require
+ # JavaScript to run (like 'blame_incremental'). Enabled by default.
+ # Project specific override is currently not supported.
+ 'javascript-actions' => {
+ 'override' => 0,
+ 'default' => [1]},
);
sub gitweb_get_feature {
@@ -3326,7 +3333,7 @@ sub git_footer_html {
qq!startBlame("!. href(action=>"blame_data", -replay=>1) .qq!",\n!.
qq! "!. href() .qq!");\n!.
qq!</script>\n!;
- } else {
+ } elsif (gitweb_check_feature('javascript-actions')) {
print qq!<script type="text/javascript">\n!.
qq!window.onload = fixLinks;\n!.
qq!</script>\n!;
--
1.6.5.3
^ permalink raw reply related
* Re: [RFC/PATCH] gitweb: Make linking to actions requiring JavaScript a feature
From: Junio C Hamano @ 2009-11-26 20:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Stephen Boyd, git
In-Reply-To: <200911262112.16280.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Let gitweb turn some links (like 'blame' links) into linking to
> actions which require JavaScript (like 'blame_incremental' action)
> only if 'javascript-actions' feature is enabled.
Hmm, instead of "fixLinks" that actually munges existing links to working
action with some other action, can that be "addLinks" that _adds_ new
links to features available only when JS can be used?
^ 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