of added security by using TLS for
transport.
You can verify integrity after the fact, but not guarantee
confidentiality ... so it again depends on the definition of security.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Ryan Biesemeyer r...@yaauie.com writes:
+ test_when_finished git merge --abort
+ (
+ git checkout -B other HEAD@{1}
Weird indentation (space/tab mix).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Jonathan Nieder jrnie...@gmail.com writes:
Matthieu Moy wrote:
Jonathan's answer is an option. Another one is
[...]
So if the cleanup goes wrong, one can notice.
test_when_finished also makes the test fail if the cleanup failed.
Yes, I was mentionning it as opposed to throwing the code
.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
in the other direction: make /etc/foo
a symlink to $GIT_WORKTREE/foo and version the later.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
to it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
) and don't forget to Cc Junio if
you think your patch is ready for inclusion.
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
with students is that it's much better than a single (too)
big task, and I think that was the general feeling on this list when we
discussed it last year.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
to drop the stash:
git stash drop
or so (I couldn't find a concise yet accurate wording).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
Holger Hellmuth hellm...@ira.uka.de writes:
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use git reset HEAD file... to unstage)
modified: foo.txt
Maybe status should display a stash count if that count
problem. I'm not asking about dumbing git down
by any means.
Can you describe precisely what you would expect, e.g. what Git's output
should look like after such and such command?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git
on a git add operation would be really, really
weird...
(or the user (somehow) is notified to do that herself if desired),
because this means that the popping operation has succeeded.
But how would you expect to be notified?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
no
real harm, but droping one you actually needed is data loss.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
a dependency
order violation (stash is normally implemented on top of Git's basic
features, not the other way around). Does not seem serious from at first
from the user point of view, but this pushes the codebase one step in
the direction of an unmaintainable mess.
--
Matthieu Moy
http://www
to reset the index during a merge.
The other 2 patches look good to me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
the leaving conflicts in the working tree could be
dropped, as the message follows CONFLICT (content): Merge conflict in
foo.txt.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Andrew Wong andrew.k...@gmail.com writes:
On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
But this breaks backward compatibility.
I sometimes run git reset during a merge to only reset the index and
then examine the changes introduced by the merge
did we start using such or such feature in the code).
I wouldn't fight for it, but I think it makes sense.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
the default to upstream branch). Shouldn't the added
code be after the esac?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
had something
more precise in mind.
A case to be carefull about is if you're using the same git branch
command for multiple actions (trying --set-upstream in combination with
other options). But I do not see a case where this would be possible.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
, the last git add does not trigger a
commit silently. And a silent commit would be much less serious than a
silent data drop.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Stephen Leake stephen_le...@stephe-leake.org writes:
I was not aware that the git system could support more than one version
of a file in one branch.
The index only. The history itself does not.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line
object, but I don't think the implementation cost is
worth the benefit.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
: ...
Somehow, do for config variables what has been done for command-line
option parsing.
Migrating the whole code to such system would take time, but creating
the system and applying it to a few examples might be feasible as a GSoC
project.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
of the most destructive operation Git has).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
like 'git log' do when used with a -number option since ... in the
manpage).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
todo-list. Then I have to abort the commit
manually. With -N failing on merge commits, the rebase would abort
itself automatically.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Duy Nguyen pclo...@gmail.com writes:
On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy
This would actually be a feature for me: I often want to rebase recent
enough history, and when my @{upstream} isn't well positionned, I
randomly type HEAD~N without remembering what N should be. When N is too
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Michael Haggerty mhag...@alum.mit.edu writes:
Or perhaps -NUM should fail with an error message if any of the last
NUM commits are merges. In that restricted scenario (which probably
accounts for 99
executed by the subprocess won't work if gdb is running on the other
one).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
merge --abort, then why not advice.abortMerge ?
But mergeHints makes sense to me also, as it would potentially encompass
more cases.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
.) :
- _(Branch %s set up to track remote ref %s.),
- local, remote);
- else if (!remote_is_branch !origin)
+ else if (!remote_is_branch (origin || !origin))
Is it me, or is (origin || !origin) a tautology?
--
Matthieu Moy
http://www
.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
is
((!remote_is_branch origin) || (!remote_is_branch || !origin))
(The second || should be a in this sentence)
I'm not saying your rewrite is incorrect, but there's no reason to keep
(origin || !origin) in a logical formula.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe
, so parsing them multiple times isn't really
noticeable from the performance point of view.
OTOH, the extensibility is a real concern, and that should be the main
motivation for the project.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe
die(BUG: impossible combination of %d and %p,
remote_is_branch, origin);
I mean: obviously, it has to be dead code, but it seems a bit strange to
read
if (x)
...
else if (!x)
...
else
die(...)
--
Matthieu Moy
http://www
is
false, then you exit the loop because it's a while loop, and if the
condition is true, you exit the loop because of the break. Isn't that a
no-op?
+ string_list_insert(list, e-d_name);
+ }
Broken indentation (misplaced }).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
French eyes).
I am very interest in Open source.What can I do to increase my chance?
Interesting blog post to read:
http://softwareswirl.blogspot.fr/2014/03/my-secret-tip-for-gsoc-success.html
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line
the _() on verbose_rebasing, which isn't translatable
anymore after your patch.
I personnally think that the table-driven approach is wrong here, it
makes the code shorter but much harder to read.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git
/244210
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
is a static function, called twice. I don't
see any reason not to rename it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body
like this. Git's history
should be clean, and the patch that will eventually be applied should
not reflect the trial and error iterations that led to the result.
Read about git rebase -i and git commit --amend for more information
about this.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
insist on that.
Other than that, the patch looks good.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
the list in case of
user error.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
that.
I find the old code much clearer than the new one. This name[1] ==
'\0' looks weird to test if name is the string ..
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
../
git log
The call to git status creates a process, but the process dies before
you run cd. The call to git log is a different process. It can
re-use things that git status left on disk, but not in-memory data
structures.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
portability)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
, but that may be just because I'm
used to it. Also, disabling it is can only be done by adding
--max-depth=-1 to the command-line, which isn't very convenient. Perhaps
there should be a git ls -R shorthand for git ls --max-depth=-1.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe
.
Reported-by: Anarky ghostana...@gmail.com
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
The porcelain format of git status is described as not based on user
configuration.
But with --branch, behind/ahead are translated following the user's locale.
Is it normal that scripts need to take
.
This does not mean we can't add new features, both on the file parsing
side (add the ability to unset a key) and on the user API side (allow
getting the value of a key more easily).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git
the KISS way. I tend to prefer my
version for simplicity, but no strong opinion here.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
dies (this would
require an additional daemon, which would be really overkill in our
case).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
to become equal to 7, then write magic_num = 7 in code, not
in a comment.
Here, the reader has to spend time and energy to check the
correspondance between the code and the redundant comment ... and see
than they do not match!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
? If so, does it say anything about B
and B'?
What filesystem do you use on the server? Is there any kind of NFS, and
if so are you sure that there's only one machine accessing the
filesystem at the same time?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send
).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
implementation:
#
# Debian: ,einfaldar' og ,,tvöfaldar [GNU libintl]
-# FreeBSD: `einfaldar` og tvöfaldar [GNU libintl]
+# FreeBSD: $(einfaldar) og tvöfaldar [GNU libintl]
# Solaris: ?einfaldar? og ?tvöfaldar? [Solaris libintl]
I don't think you wanted this to be changed.
--
Matthieu
a reroll)
Did you do these 144 patches by hand, or did you use a script (e.g. perl
substitution or so) to do it? If the later, then you should include
explanations in your commit message.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git
-*J
The original version was more readable ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
ls -F
does.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
-42). I don't know if any -N option could make
sense.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
and
checking that each line is an ancestor of the previous should be easy.
I can't exclude the hypothesis of a bug in Git, but my feeling is that
there's an issue with your setup.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body
.
To be really sure, you also have to set receive.denyDeletes to true.
Otherwise, a workaround to perform a non-fast forward is to delete the
branch, and re-create it somewhere else in history.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git
to publish your branch somewhere than to
continue sending batches of 140 emails to the list for this kind of
topics.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
comments including `...` are code examples that we
want to fix too, except 3 instances (see my other message).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
with a letter I
guess, not sure exactly what happens when Git doesn't know the syntax).
But don't worry, these are juste hints for human, they are harmless.
Sometimes it's even in the wrong position, above the @@ numbers.
That is strange. Do you have a way to reproduce this?
--
Matthieu Moy
##*: })
fi
Don't access the filesystem. Ask Git.
GIT_FULL_BRANCH=$(git rev-parse --symbolic-full-name HEAD)
GIT_BRANCH=${GIT_FULL_BRANCH##*/}
GIT_HEAD=Git:$GIT_BRANCH-$(git rev-parse --short HEAD)
(Perhaps there's a simpler way without $GIT_FULL_BRANCH)
--
Matthieu Moy
http://www
splitting the series into batches of around 10 patches,
sending one per week, but that would make too many patches IMHO (14
weeks ...).
I'd suggest doing a first batch with only scripts that are not tests and
pushing this to git.git. Then the remaining series will be a bit less
scary.
--
Matthieu Moy
on these (in this thread or on the
wiki).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
remember exactly
what made him give up, but it was never completed and merged.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
.
Not sure it'll directly answer your question, but did you read the
History Simplification part of git log --help?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
what the licence of the logo is, the answer
is: Creative Commons Attribution 3.0 Unported
( http://git-scm.com/downloads/logos )
I support both points above.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
that it has happened again and I've got this data, I'm going to
upgrade git but let me know if this provides any insight in the mean
time.
If I were you, I'd keep a copy of the complete repo (including reflog
all) in case.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe
. That might work for the shells
you tested, but if the goal is to avoid using tricky features that may
trigger bugs on some shells, that seems backward.
IOW, why not move the whole run_specific_rebase_internal function to
git-rebase--$type?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
not consistant with @{upstream} corresponding
to branch.name.merge, but I do not consider it as a good reason to
introduce one more inconsistancy.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
)
with push.default=upstream and the current behavior of the patch.
Perhaps argumentless git push could warn when push.default=upstream
and branch.name.publish is configured, I'm not sure.
Sorry, more questions and I'm not sure than actual suggestion :-(.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy
- state_dir=$merge_dir
-else
- type=am
- state_dir=$apply_dir
-fi
-
if test -z $rebase_root
then
case $# in
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
the @{publish} shorthand too. Stg like
This branch can be refered to as @{publish} when specifying revision
(see linkgit:gitrevisions[7]).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Kyle J. McKay mack...@gmail.com writes:
On Apr 11, 2014, at 10:30, Matthieu Moy wrote:
Kyle J. McKay mack...@gmail.com writes:
There are already nested functions with file inclusion between both
levels of nesting in git-rebase--interactive.sh and git-rebase--
merge.sh now, so it's
at some future point.
Seems a good plan to me.
Needs-Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
From: Matthieu Moy matthieu@grenoble-inp.fr
Subject: [PATCH 4/3] rebase: stop using . within function
Move the whole
Elia Pinto gitter.spi...@gmail.com writes:
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.
For patches 1 to 14:
Reviewed-by: Matthieu Moy matthieu@imag.fr
(reviewed the patches in my mailer, and the diff --color-words
() is to be
understood as if STRBUF_OWNS_MEMORY is still set when strbuf_detach()
is called, then it must always call xstrcpy(), right?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Michael Haggerty mhag...@alum.mit.edu writes:
On 04/22/2014 09:07 AM, Matthieu Moy wrote:
The whole point of the change is to *allow* strbuf to be used in
performance-critical stuff.
OK. It should not make the current use of strbuf any harder anyway.
In your proposal, would
, there's no backward
compatibility issue, it can very well be a 2.1, or whatever number comes
after 2.0.
This is actually the perfect time to do it.
Junio has just tagged a -rc for 2.0, so it's clearly too late to start
discussing new features for this particular release.
--
Matthieu Moy
http://www
?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
Previously, the user had to launch a complete re-install after a lighttpd
stop (e.g. a reboot).
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
contrib/mw-to-git/t/install-wiki.sh | 10 ++
contrib/mw-to-git/t/test-gitmw-lib.sh | 2 +-
2 files changed, 11 insertions(+), 1 deletion
).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
Patches 01 to 14/14 are
Reviewed-by: Matthieu Moy matthieu@imag.fr
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
decoding linked to the
Content-Encoding: header, and return the content without attempting any
charset decoding.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 7 ++-
contrib/mw-to-git/t/t9363-mw-to-git-export-import.sh | 19
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Commit 26cd160 (rebase -i: use a better reflog message) tried to produce
a better reflog message, however, it seems a statement was introduced by
mistake
Felipe Contreras felipe.contre...@gmail.com writes:
Recently some code was changed to do 'test_must_fail env VAR=VAL command', why
can't we do the same?
I guess we can.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git
in release notes and in the manual would be sufficient IMHO.
GUI usually don't warn when the shape of a button is going to change in
the next version ...
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message
and Git had to guess your identity.
If you explicitly fill-in the config file with guessed values, then Git
will have no way to know if the config values are real or guessed.
OTOH, a prompt with a default value (i.e type 'return' to get the
default) would make sense.
--
Matthieu Moy
http://www
set so
the pager runs itself again as another pager. The end result is an
infinite loop of forking.
There's probably a solution, but you can't ignore the problem (or
someone else will later try to solve the infinite loop and revert your
commit, and so on ...).
--
Matthieu Moy
http://www
it should
be reverted.
Thanks for the explanation. I think we should just go with Jörn's patch
as-is, then.
Agreed. At best, the commit message could be improved to explain the
situation, but the patch itself is OK.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
) and an
example showing how to unset a flag set by Git.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
We agree here. So, does someone who actually wants this change want to
propose a patch? :)
Here you are.
Documentation/config.txt | 13 -
Makefile | 6
}
|
`
that I left intact. I can change them too if people prefer.
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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
David Kastrup d...@gnu.org writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
David Kastrup d...@gnu.org writes:
There seem to be a few more occurences (git-sh-setup.sh and pager.c):
Not since f82c3ffd862c7 (Wed Feb 5 2014, move LESS/LV pager environment
to Makefile).
The only
1 - 100 of 2040 matches
Mail list logo