l2 HEAD server HEAD
> -'
So what's wrong with the tests? Do they fail to test what they claim
(how?), test something that wasn't reasonable to begin with, or
something entirely different?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
r parameters...
Also note that the pager is automatically disabled if you redirect
stdout, so --no-pager is only required in some fringe cases, notably
when attempting to run git under GDB.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "uns
Felipe Contreras writes:
> On Thu, Apr 18, 2013 at 2:28 AM, Thomas Rast wrote:
>> Felipe Contreras writes:
>>
>>> The *:* refspec doesn't work, and never has, clarify the code and
>>> documentation to reflect that. This in effect reverts commit 9e76
break how options work (for fear of breaking scripts).
You could come up with a patch series that first starts emitting
warnings whenever the user asks for behavior that will change, and later
flips the default and removes the warning (the latter would be merged
for 2.0 or so).
--
Thomas Rast
trast@
ll involved repos (including devs' workstations!)
and then having the devs re-push what they had locally seems like a good
strategy to me.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord
already,
but mainly for other curious readers):
git://github.com/trast/git.git tr/gitk-line-log
has a version of gitk that supports -L. I hacked it up yesterday, and
while it seems to work, I want to play with it a little until I'm
satisfied that I didn't break gitk for other uses.
g a merge and comparing the result with what the merge
gave you. But it's not something that you would want to run by default.
[1] some things like --simplify-merges are actually another pass, but
the default is to generate everything -- including diffs -- as we go.
--
Thomas Rast
trast@{in
ted. Sigh. We should
remove it.
-- >8 --
Subject: [PATCH] git-log(1): remove --full-line-diff description
This option is a remnant of an earlier log -L version, and not
currently implemented. Remove it until (if at all) it is implemented
again.
Signed-off-by: Thomas Rast
---
Documentation/git
Thomas Rast writes:
> -- >8 --
> Subject: [PATCH] git-log(1): remove --full-line-diff description
BTW, I generated this with your jc/format-patch, but it stopped working
after fc/send-email-annotate made it into next; I need this on top. Am
I missing something?
-- >8 --
Subject: [
both to use them.
It still fails to match some commits, so consider this WIP, but I think
it's quite useful already.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
t merge of the subtree has the
files only on one side.
You can see this by comparing
git log --oneline --follow gitk-git/gitk
with
git log --oneline -- gitk gitk-git/gitk
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
-p $subtree_h) &&
> + git reset --hard $new_h &&
> + (
> + cd bar &&
> + git log --oneline ichi >../actual
You need to use --follow, as otherwise the pathspec filtering is
considered fixed.
Note that as discussed in the rest o
Thomas Rast writes:
>> +test_expect_failure 'log pathspec in tree read into prefix' '
>> +git checkout --orphan subtree &&
>> +git rm -rf . &&
>> +echo foodle >ichi &&
>
> 'ichi' also exists in M^1 beca
Ramkumar Ramachandra writes:
> Thomas Rast wrote:
>> [...]
>
> I think you've misunderstood the whole thing. The histories of M^1
> and M^2 are completely unrelated: they're from different projects
> altogether. Considering the /ichi in M^2 a "rename"
t trees.
That should then help subtree users to get better logs.
[1] the quoted example shows that you can't just go looking for
identical trees in the general case, so it is really a heuristic
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
't need to run off and implement
this, but I'm curious how hard you think it would be.)
At least in the git@vger world with a lot of etiquette surrounding the
use of Ccs, NNTP mode isn't very useful if you can't also send Ccs. But
maybe you have another use-case where that is
l.stelm...@samsung.com (Łukasz Stelmach) writes:
> It was <2013-04-24 śro 09:38>, when Thomas Rast wrote:
>> Łukasz Stelmach writes:
>>> + if ($email_protocol eq 'nntp') {
>>> + $header = "Newsgroups: $to\n" . $header;
>>&
Today I botched a cut&paste and ran
git remote add git remote add origin
only to notice, several commands later, that while it had succeeded,
it had in fact added a remote called 'git' with an url of 'remote'.
Some investigation yielded these fixes.
Thomas Rast (3):
The 'git remote add' subcommand did not check for superfluous command
line arguments. Make it so.
Signed-off-by: Thomas Rast
---
builtin/remote.c | 2 +-
t/t5505-remote.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
ind
ests readable while still
ensuring they pass as a whole, and will be removed in the final patch.
Signed-off-by: Thomas Rast
---
t/t5505-remote.sh | 27 +++
1 file changed, 27 insertions(+)
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 6579a86..764ee97 100755
---
, we also remove the code
supporting it.
Signed-off-by: Thomas Rast
---
Documentation/git-remote.txt | 4 ++--
t/t5505-remote.sh| 11 +++
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index e8c
can both be a SHA1 and a number of generations to go back.
I personally think we have enough magic revision syntax to last at least
another decade. If you propose to add some, please make a patch that we
can cook in next for a few release cycles and then conduct a straw poll
if people actually use it.
Junio C Hamano writes:
> Thomas Rast writes:
>
>> +test_extra_arg () {
>> +expect="success"
>> +if test "z$1" = "z-f"; then
>> +expect=failure
>> +shift
>> +fi
>> +te
Ramkumar Ramachandra writes:
> Thomas Rast wrote:
>> I personally think we have enough magic revision syntax to last at least
>> another decade. If you propose to add some, please make a patch that we
>> can cook in next for a few release cycles and then conduct a st
one is just based on my personal experience with messing with
inotify; renaming directories is the "hard" case for that API. We may
already cover this in the test suite, or we may not; but it must be
tested.
Other than that last point, focus your tests not on small tests but on
the tes
he results of pushing the way we
> currently push are not really understood. Perhaps it's similar to a 'git push
> --force', or perhaps it can potentially screw the repository.
>
> It's better to be safe and just do what bazaar does.
Other than "this patch should pro
-
0001.1: rev-list --all 3.31(3.19+0.12) 3.21(3.09+0.11) -2.9%**
0001.2: rev-list --all --objects 27.99(27.70+0.26) 25.99(25.71+0.25)
-7.1%***
-----
Signed-off-by: Thomas Ra
Robert Zeh writes:
> On Thu, Apr 25, 2013 at 3:18 AM, Thomas Rast wrote:
>>
>> I don't get this bit. The lstat() are run over all files listed in the
>> index. So shouldn't your daemon watch exactly those (or rather, all
>> dirnames of such files)?
> I
spond well to reviews and criticism. Even the
constructive fine-let's-do-the-work-for-him kind that Peff offered.
And on top of that, remote helpers are written against an interface that
was designed to allow working with external programs.
So why is this in git.git?
Why should we take any more
Junio C Hamano writes:
> Thomas Rast writes:
>
>> So we take a slightly different approach, and trade some memory for
>> better cache locality.
>
> Interesting. It feels somewhat bait-and-switch to reveal that the
> above "some" turns out to be "double
an' with the '--force/-f' option.
But if that's the real problem, wouldn't it be better to introduce
something like clean.requireForce=interactive (or 'ask', or whatever you
make up) which will be like clean.requireForce=true except that when on
a TTY, we ask the u
remove all of the smoke testing section in the makefile.
>
> Signed-off-by: John Keeping
Indeed. I must have mis-rebased this commit or some such.
Acked-by: Thomas Rast
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git&quo
sted things on a 2x6-core Xeon OS X machine and there the
performance (for the hot-cache, worktree case, which should parallelize
nicely) flatlines at 5 threads for no apparent reason.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git&
Thomas Rast writes:
> Robert Zeh writes:
>
>> On Thu, Apr 25, 2013 at 3:18 AM, Thomas Rast wrote:
>>>
>>> I don't get this bit. The lstat() are run over all files listed in the
>>> index. So shouldn't your daemon watch exactly those (or rath
baz/
> svn add baz/
> svn commit -mx
>
> echo x > fil.txt
> svn add fil.txt
> svn commit -mx
>
> cd ../..
>
> git svn clone --stdlayout --preserve-empty-dirs "$url" testrepo.gitsvn
Please add an actual regression test, probably
kout next; git diff-files
> Already on 'next'
> :100644 100644 bd774cccaa14e061c3c26996567ee28f4f77ec80
> Mmagit.el
> Already on 'next'
> $
git-diff-files doesn't refresh the index. Why are you using it? It's
the plumbing version of '
"$0" "$@" 2>&1;
>echo $? > $BASE.exit) | tee $BASE.out
> test "$(cat $BASE.exit)" = 0
Hmm, I initially was too lazy to review this change, and now it's biting
me. The above is Makefile-quoted, which to the shell reads like a
command su
ave the patches in jk/test-output (without those
> patches the individual tests work but the reporting of aggregate results
> doesn't).
But that's been possible for quite some time now, using --root, or am I
missing something?
(Not that the fix as such is a bad idea, but ot
e delta cache yet. (Observe that we pop from the cache in
phase 1, so this is also true for the very first base.) So we make no
further attempts to look up the bases in the cache, and just call
add_delta_base_cache() on every base object we have assembled.
But the !delta_data error path remained
database_contaminated to 1 by default and ran
> the test suite. It passed :)
How does this interact with alternates set up by the user? It's not
immediately obvious from the commit messages (hint hint) or the comments
near ODB_LOCAL etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubs
d_delta_base_cache() on every base object we have assembled.
But the !delta_data error path remained unchanged, and now calls
free() on a base that has already been entered in the cache. This
means that there is a use-after-free if we later use the same base
again.
So remove that free().
Reported-by: N
e's no way to say
git symbolic-ref U @{u}
so that I can avoid that -- it's really clumsy to type on a Swiss German
keyboard. We'd need some sort of ref-alias feature for that to work.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "
oking at *just* the alias, and resolving that to a
SHA1, and going from there. So assuming U = @{u} and H = HEAD, you'd be
allowed to say U^ or U..H but not HU or H@U or whatever contortionate
syntax that would need.
As for the collisions, not sure which one is better. Probably having
the s
2) 2.74(2.59+0.12) +0.7%
2.72(2.57+0.13) +0.2% 2.74(2.59+0.13) +0.8%.
-------
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the lin
git update-ref refs/tags/$REF $VAL &&
> + test `git rev-parse $REF 2>err` = $VAL &&
> + grep "refname.*ambiguous" err
> +'
Shouldn't these say s/20-hex/40-hex/?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t;>>> git diff A/long-branch-name
>>>> git reset --hard A/long-branch-name
>>>
>>> Perhaps
>>>
>>> git checkout long-bra
>>> git diff A/!$
>>> git reset --hard !$
>
> "diff" does not have to follow
strace log we could see exactly where it gives weird
answers (or that it doesn't, and thus get clues to any possible git
bugs).
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
f fast-import? Your
comment isn't very reassuring:
> the vast majority of them will never be used again
So what's with the minority?
In any case, if this does go in, please update the documentation to
match, probably by copying the sentence from git-fast-export(1).
--
Thomas Ras
or another, they both claim that it fails even with HOME unset(!)
and even with a completely empty environment. I cannot reproduce this,
but there might be another issue lurking?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git&quo
afer anyway, since it doesn't lose the formerly-staged state
so easily (you have the reflog in case of any mistakes).
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mor
d AFAICS never got
a reply)?
} If it's a race condition between the write and the subsequent read in
} the same process, then it would be solved by looking at the object
} later. Does "git cat-file -p 6838761d549cf76033d2e9faf5954e62839eb25d"
} work, or is the object forever inaccessible?
nt (PowerShell) is arguably broken. All the while, there are
several existing solutions that we consider more natural, and that
generalize to other use-cases.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
Jonathan Nieder writes:
> Thomas Rast wrote:
>> Junio C Hamano writes:
>
>>> * jn/config-ignore-inaccessible (2013-04-15) 1 commit
>>> - config: allow inaccessible configuration under $HOME
>>>
>>> When $HOME is misconfigured to point at an un
< 0)
+ return error("access(%s, R_OK) failed immediately after
rename(): %s",
+filename, strerror(errno));
+
out:
if (adjust_shared_perm(filename))
return error("unable to set permission to '%s'", filename);
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Michael Haggerty writes:
> On 05/03/2013 08:23 PM, Felipe Contreras wrote:
>> On Fri, May 3, 2013 at 12:56 PM, Thomas Rast wrote:
>>> Felipe Contreras writes:
>>
>>> How do we know that this doesn't break any users of fast-import? Your
>>> c
it
doesn't have a wiki entry -- using "Beschränkung" in the same sentence
is just confusing.
How about
Pfadspezifikationen ignorieren Einstellungen zum partiellen Auschecken
All the ones I didn't quote here: Acked-by: Thomas Rast
Thanks for your work!
--
Thomas R
this,
but git-grep's --or etc. caught another case.
Signed-off-by: Thomas Rast
---
parse-options.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index c1c66bd..f95bbb2 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -562,7 +
Junio C Hamano writes:
> Thomas Rast writes:
>
>> The gettext .po files have a header, but it looks like the translation
>> specification for an empty string. This results in _("") actually
>> returning that header.
>
> Thanks; this is a tricky bit to c
it ;-).
>
> He, we need to update the log message a bit, too.
Thanks! But now it's your patch :-)
> -- >8 --
> From: Thomas Rast
> Subject: [PATCH] gettext: do not translate empty string
>
> The gettext .po files have a header, but it looks like the translatio
sting that the change occurred in the call_me()
> function, rather than in main()
I think that's intentional, and matches what 'diff -p' does. It gives
you the context before the hunk. After all, if a new function starts in
the leading context lines, you can see that in the usua
;t see any
> real argument in favor of disambiguating towards the revision.
I don't think that ".." is really a no-op. It is true that HEAD..HEAD
does not itself result in any revisions, but it *could* be used as a
silly shorthand to introduce ^HEAD into the objects being walk
ags);
+
for (b = bases; b; b = b->next) {
if (!hashcmp(commit->object.sha1, b->item->object.sha1)) {
ret = 1;
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
only commits
that ended up having exactly one of them. At least the counting case
should be easy, rev-list is slightly harder to fix.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Thomas Rast writes:
>>
>>> At the very least it should be possible to change in_merge_bases() to
>>> not do any of the post-filtering; perhaps like the patch below.
>>
>> I do not recall th
Junio C Hamano writes:
> Thomas Rast writes:
>
>> diff --git i/commit.c w/commit.c
>> index 65a8485..70427ab 100644
>> --- i/commit.c
>> +++ w/commit.c
>> @@ -837,10 +837,13 @@ int in_merge_bases(struct commit *commit, struct
>> commit **reference,
.11 eingeführt. Benutze den
> gleichartigen"
> +" Modus 'current' anstatt 'simple', falls du gelegentlich ältere Versionen
> von"
> +" Git benutzt)"
You translate "similar" as "gleichartig", which sounds too much li
In fact, it went through review here
http://thread.gmane.org/gmane.comp.version-control.git/202784
where I too (sorry) missed this, even as I pointed out several other
things. Then it went into the pull request
http://thread.gmane.org/gmane.comp.version-control.git/203153
So for me the m
filter. However:
> * fix charater sets and indentions of source files
That last step is rather crazy. At the very least you will want to only
operate on files that were changed since the parent commit, so as to
avoid scanning the whole tree. If you do this right, it should also fit
in
uot;Padding space on right border"
> -msgstr ""
> +msgstr "Abstand zur rechten Grenze"
border here means "Rand"!
> #: builtin/commit.c:1399
> msgid "the commit is authored by me now (used with -C/-c/--amend)"
> -msgstr ""
>
builtin (git.c:306)
==27841==by 0x40548E: main (git.c:467)
==27841== Address 0x0 is not stack'd, malloc'd or (recently) free'd
around here:
> @@ -379,13 +382,20 @@ int cmd_config(int argc, const char **argv, const char
> *prefix)
[...]
> + char *user_config = NU
test them for
> NULL-ness before.
>
> Signed-off-by: Matthieu Moy
> ---
>> This patch causes valgrind warnings in t1300.81 (get --path copes with
>> unset $HOME) about passing NULL to access():
>
> Indeed. The following patch should fix it.
Thanks!
Tested-by: Thomas
Yes, and this is still the case for _reading_. But the current case is
> about deciding which file to use when _writing_. Git was already dying
> when writing with an unset $HOME.
Umm, are you sure? I may be somewhat confused about this, but the tests
I used to trigger the access(NULL) were
the .git/index is different
> between Linux and Mac OS X.
>
> Is there a good way to debug the index file?
You can run 'git ls-files --debug' which should give you all the data in
the index, and then perhaps run diff over that to determine the
differences...
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
not caught
earlier, saving the unresolved state would be correct.
So we can unconditionally record REUC deeper in the call chain.
(git-mv calls remove_index_entry_at() through rename_index_entry_at();
however, it refuses to work on unresolved files. So that's okay too.)
Signed-off-by
Thomas Rast writes:
> Thomas and me discovered this while hacking on index-v5. It would be
> a bit tricky to handle there: the index is structured according to the
> directory layout of the files it contains, and the REUC data is the
> same as the conflict (stages) data plus a f
ot to recognize me:
http://www.cadmo.ethz.ch/as/people/members/trast
Cheers,
Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kerne
on't know" value would
indeed be a good idea. But I don't see how what Robin said constitutes
an argument in favor of splitting stat_crc into its fields again?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
t
John Bartholomew writes:
> I find the output of `git branch' to be quite bare, and would like to
> see more information; most importantly, what the state of the branch
> is in relation to its upstream.
That is already present: just run git branch -vv.
--
Thomas Rast
tras
Robin Rosenberg writes:
> Junio C Hamano skrev 2012-07-22 23.08:
>> Thomas Rast writes:
>>
>>> What is the status quo? I take it JGit does not have any of ctime, dev,
>>> ino etc., and either leaves the existing value or puts a 0
>>> an argume
particular one as well.
Yes. The original plan was to free up -b, but since we don't need
--binary any more either, it's better if we can get rid of it the same
way.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Junio's index-v4 was a speed boost mainly because it cuts down on the
>> size of the index. Do we want to throw that out?
>
> That's pretty much orthogonal, isn't it?
>
> The index-v4 is mere
n we managed in 2010, but I realize that this is not possible
if we just meet for 2-3 days. Perhaps one option would be to plan for
1-2 days of hacking after the discussion rounds, so that the interested
people can stay a bit longer?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe fr
within the block being compared, since an aligned
load can never partially fault (it must all be within the same page).
Valgrind normally substitutes its own routines for memcmp etc. to
correctly handle this, but this does not seem to happen in your case for
some reason.
Then again I am not e
my $e = $2;
+ $e =~ s/_/ /g;
+ $e =~ s/=([0-9A-F]{2})/chr(hex($1))/eg;
+ $e;
+ }eg;
return wantarray ? ($_, $encoding) : $_;
}
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thomas Badie writes:
> The idea is to have a perl module which run through
> the log history and print 10 shortlog associated with a number
> from 0 to 9, and a message below "Select commit [| 0, 9 |] or
> next row ?" or this kind of message with several options.
>
> So I ask to the community if
e first two by doing a more careful decoding of the
=AB outer quoting. Fixing the fundamental issues is left for a
future, more intrusive, patch.
Noticed-by: Christoph Miebach
Helped-by: Junio C Hamano
Signed-off-by: Thomas Rast
---
This is the easy part, fixed as per Junio's comme
Junio C Hamano writes:
> Thomas Rast writes:
>
>> This patch fixes the first two by doing a more careful decoding of the
>> =AB outer quoting. Fixing the fundamental issues is left for a
>> future, more intrusive, patch.
>
> What is this =AB thing?
The two-hex-
test "$(test-index-version < .git/index)" = 2 ||
> + test "$(test-index-version < .git/index)" = 5
> '
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
read safe. Use strtok_r() if this matters to you.
I don't think the last point will be a problem, but what about modifying
the argument?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ren" but I'm probably bikeshedding.
> +"Wenn du das Problem aufgelöst hast, führe \"git rebase --continue\" aus.\n"
Not what you are actually changing, but "resolve" (a merge conflict) is
not in the glossary. For me
Wenn du das Problem _gelöst_ hast...
sounds nicer. "aufgelöst" sounds like "resolve a domain name" or such.
> msgid "fatal: no such branch: $branch_name"
> -msgstr ""
> +msgstr "fatal: kein solcher Zweig: $branch_name"
kein Zweig $branch_name gefunden?
> #: git-rebase.sh:474
> msgid "Please commit or stash them."
> -msgstr ""
> +msgstr "Bitte trage die Änderungen ein oder benutze \"stash\"."
I really like this way of dodging the "stash" translation :-)
Footnotes:
[1] https://github.com/ralfth/git-po-de/wiki/Glossary
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ome with a From (and my S-o-b). (I'm not
going to be anal about any of the work we did in Zurich, let's just
classify that as "help" like above.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
e problem. Thanks
Well, it's a bit confusing. AFAICS the verb (rename/modify) goes into
the parens at the start, and the participle (renamed/modified) goes into
the fourth %s. So if you decided to *not* translate the
"(rename/delete)" conflict description, you would have to trans
happen: it returns this value only if count=0, but flush_buffer()
will never call write_in_full() in this case.
Remove it.
Signed-off-by: Thomas Rast
---
Much easier than worrying about the "disk full?" message.
merge-recursive.c | 19 +--
1 file changed, 1 insert
, and patch all callers to take this into account.
This conveniently also gets rid of a handful of different(!) error
messages that could never be triggered anyway.
Note that the function can still die().
Signed-off-by: Thomas Rast
---
> On Fri, Aug 3, 2012 at 10:59 AM, Thomas Rast wr
Thomas Rast writes:
> diff --git a/line.c b/line.c
> index a008c2c..fe7ace7 100644
> --- a/line.c
> +++ b/line.c
> @@ -1177,6 +1177,9 @@ static int process_diff_filepair(struct rev_info *rev,
> return 0;
> if (rg->ranges.nr == 0)
>
. For example, for v5 it
would be far better if conflicted and resolve-undo entries were a
property of the normal index entry, instead of something that so happens
to be consecutive entries and in a completely different place,
respectively.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscr
Junio C Hamano writes:
> Thomas Rast writes:
>
>> I like the general idea, too, but I think there is a long way ahead, and
>> we shouldn't hold up v5 on this.
>
> We shouldn't rush, only to keep some deadline, and regret it later
> that we butchered the
e too far in DB land. Most updates will be
of the "update the stat and/or sha1 of a file" kind, anyway.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ould produce the above, but
perhaps you could just look at
git config --get-regexp '.*diff.*'
grep diff .gitattributes .git/info/attributes
etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bernd Jendrissek writes:
> On Mon, Aug 13, 2012 at 5:02 PM, Thomas Rast wrote:
>> Can you share this repository?
>
> This weird behaviour doesn't even survive making a copy (cp -a) of the
> whole repository, so I very much doubt making it available would be
> illumina
501 - 600 of 694 matches
Mail list logo
