Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch 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, int num)
struct
Reroll includes fixups by Ramsey. Thanks!
Diff:
- Add missing dependency to rule in Makefile.
- improve compatibility of integer types.
- t9020-*.sh: remove excess slash in urls that makes python on windows
interpret it as a network path.
- t9020-*.sh: skip if python isn't available.
- replace
Enable basic fetching from subversion repositories. When processing
remote URLs starting with testsvn::, git invokes this remote-helper.
It starts svnrdump to extract revisions from the subversion repository
in the 'dump file format', and converts them to a git-fast-import stream
using the
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-remote-helpers.txt | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-remote-helpers.txt
For testing as well as for importing large, already available dumps,
it's useful to bypass svnrdump and replay the svndump from a file
directly.
Add support for file:// urls in the remote url, e.g.
svn::file:///path/to/dump
When the remote helper finds an url starting with file:// it tries to
The reference to update by the fast-import stream is hard-coded. When
fetching from a remote the remote-helper shall update refs in a
private namespace, i.e. a private subdir of refs/. This namespace is
defined by the 'refspec' capability, that the remote-helper advertises
as a reply to the
On Tuesday 28 August 2012 10:49:34 Florian Achleitner wrote:
Reroll includes fixups by Ramsey. Thanks!
Diff:
[..]
- improve compatibility of integer types.
[..]
This line is wrong in this series. Just delete it. Sorry.
--
To unsubscribe from this list: send the line unsubscribe git in
the
Split the decision of what to do and actually doing it in
handle_node() to allow for detection of branches from svn nodes.
Split it into handle_node() and apply_node().
svn dumps are structured in revisions, which contain multiple nodes.
Nodes represent operations on data. Currently the function
On Tue, Aug 28, 2012 at 10:55 AM, Junio C Hamano gits...@pobox.com wrote:
The surrounding code is somewhat tricky and the code structure is
brittle; there are places that update the opts.new_branch so the new
location of this check has to be after them, and there is one
codepath that having a
This struct contains various switches to change checkout behavior and
it feels somewhat safer to have the compiler reassure us that nowhere
else changes it.
One field that is changed, writeout_error, is split out and passed as
another argument.
Signed-off-by: Nguyễn Thái Ngọc Duy
checkout operates in three different modes. On top of that it tries to
be smart by guessing the branch name for switching. This results in
messy option handling code. This patch reorders it so:
- easy option handling comes first
- the big chunk of branch name guessing comes next
- mode
This makes cmd_checkout() shorter, therefore easier to get the big
picture.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
In general I like it, except that parse_branchname_arg() pulls so many
options from cmd_checkout(). I would rather have update_new_branch()
that only takes
Hello,
I was looking for a french speaking place to discuss about Git, Hg, SVN
and all other SCM in use and did not find.
This is then an attempt to create one.
I created a Google group:
https://groups.google.com/forum/?fromgroups#!forum/sgcs-fr
I invite french sepaking people to join.
The
Thomas Rast tr...@inf.ethz.ch writes:
I'm also mildly surprised that it ended up being correct, albeit with
some extra work from you :-)
I actually am not all that surprised. It just shows that the
original code was layered in more or less the right way. At the the
bottom layer we would want
Hi folks,
I'm looking for a diff / merge tool that treats lines with
only whitespace changes (trailing or leading whitespaces,
linefeeds, etc) as equal.
The goal is to make reviews as well as merging or rebasing
easier when things like indentions often change.
Does anybody know an solution for
Florian Achleitner florian.achleitner.2.6...@gmail.com writes:
The link-rule is a copy of the standard git$X rule but adds VCSSVN_LIB.
Signed-off-by: Florian Achleitner florian.achleitner.2.6...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Makefile |5 +
1 file
- Original Message -
From: Enrico Weigelt enrico.weig...@vnc.biz
Sent: Tuesday, August 28, 2012 12:26:39 PM
Subject: diff/merge tool that ignores whitespace changes
I'm looking for a diff / merge tool that treats lines with
only whitespace changes (trailing or leading whitespaces,
On 08/28/2012 01:40 PM, Stephen Bash wrote:
- Original Message -
From: Enrico Weigelt enrico.weig...@vnc.biz
Sent: Tuesday, August 28, 2012 12:26:39 PM
Subject: diff/merge tool that ignores whitespace changes
I'm looking for a diff / merge tool that treats lines with
only whitespace
(otherwise, there was a very strange change made to its functionality,
which the documentation does not reflect)
Old, working git:
===
$ git --version
git version 1.7.0.4
$ git show --quiet --abbrev-commit --pretty=oneline
47a7aee54553fb718c376cfa9d7de4389a391e33
47a7aee Fix hyperlinks for
On 08/28/2012 01:38 PM, Matthew Caron wrote:
(otherwise, there was a very strange change made to its functionality,
which the documentation does not reflect)
Never mind.
I was looking in the wrong spot. The issue is not with --pretty=oneline,
it's with --quiet. In 1.7.0.4, --quiet worked
Nicolas Sebrecht nicolas.s@gmx.fr writes:
Do you expect one big merge of a very stable libgit2 at some point?
I don't think there's any need to merge libgit2 into the git project
source. As a library, it should be perfectly usable as a project of its
own, just like libcurl and libz.
Florian Achleitner florian.achleitner.2.6...@gmail.com writes:
Enable basic fetching from subversion repositories. When processing
remote URLs starting with testsvn::, git invokes this remote-helper.
It starts svnrdump to extract revisions from the subversion repository
in the 'dump file
Florian Achleitner florian.achleitner.2.6...@gmail.com writes:
Search for a note attached to the ref to update and read it's
'Revision-number:'-line. Start import from the next svn revision.
If there is no next revision in the svn repo, svnrdump terminates with
a message on stderr an
Florian Achleitner florian.achleitner.2.6...@gmail.com writes:
fast-import mark files are stored outside the object database and are
therefore not fetched and can be lost somehow else. marks provide a
svn revision -- git sha1 mapping, while the notes that are attached
to each commit when it
Florian Achleitner florian.achleitner.2.6...@gmail.com writes:
The reference to update by the fast-import stream is hard-coded. When
fetching from a remote the remote-helper shall update refs in a
private namespace, i.e. a private subdir of refs/. This namespace is
defined by the 'refspec'
Florian Achleitner florian.achleitner.2.6...@gmail.com writes:
Use svnrdump_sim.py to emulate svnrdump without an svn server.
Tests fetching, incremental fetching, fetching from file://,
and the regeneration of fast-import's marks file.
Signed-off-by: Florian Achleitner
Jeff King p...@peff.net writes:
Most of our http requests go through the http_request()
interface, which does some nice post-processing on the
results. In particular, it handles prompting for missing
credentials as well as approving and rejecting valid or
invalid credentials. Unfortunately,
- Original Message -
From: Matthew Caron matt.ca...@redlion.net
Sent: Tuesday, August 28, 2012 1:41:51 PM
Subject: Re: diff/merge tool that ignores whitespace changes
I'm looking for a diff / merge tool that treats lines with only
whitespace changes (trailing or leading
Am 27.08.2012 22:59, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
+{
+int i;
+int errs = 0;
+
+for (i = 0; i list.nr; i++) {
+const char *name = list.entry[i].name;
+int pos;
+struct cache_entry *ce;
+struct
d...@cray.com writes:
Nicolas Sebrecht nicolas.s@gmx.fr writes:
Do you expect one big merge of a very stable libgit2 at some point?
I don't think there's any need to merge libgit2 into the git project
source. As a library, it should be perfectly usable as a project of its
own, just
Oswald Buddenhagen wrote:
(...)so the second approach is the bare aggregator repo which adds
all other repos as remotes, and the other repos link back via
alternates. problems:
- to actually share objects, one always needs to push to the aggregator
Run a cron job which frequently does that?
From: Junio C Hamano gits...@pobox.com
Sent: Tuesday, August 28, 2012 12:22 AM
Philip Oakley philipoak...@iee.org writes:
I searched for all occurrences of '[[' which would indicate a double
optional argument within the synopsis and only found git-read-tree.
Double-optional? That is not an
Joachim Schmitz j...@schmitz-digital.de writes:
Implementation includes getitimer(), but for now it is static.
Supports ITIMER_REAL only.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
May need a header file for ITIMER_*, struct itimerval and the prototypes,
But for now, and
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
checkout operates in three different modes. On top of that it tries to
be smart by guessing the branch name for switching. This results in
messy option handling code. This patch reorders it so:
- easy option handling comes first
- the big
When git is used to track only a subset of a directory, or
there is no sure way to divide files to ignore from files to track,
git user have to live with large number of untracked files. These files
present in file list, and should always be scrolled through
to handle real changes. Situation can
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
for (i = 0; i cnt; i++) {
-if (rslt[i])
+/*
+ * Is rslt[i] an ancestor of any of the others?
+ * then it is not interesting to us.
+ */
+
Hi,
In one of my workflows, I constantly rebase topic branches on top of new
upstream imports. As there are several upstream import branches, I have
similar topic branches on top of different imports.
When rebasing the topic branches, I can hit conflict resolution that I
already had to do for
Jeff King p...@peff.net writes:
Yes, that is what's going on. But it's still a regression. There was
some discussion of what --quiet should do here:
http://thread.gmane.org/gmane.comp.version-control.git/171357
which resulted in a patch that took away --quiet. But then this thread:
On Tue, Aug 28, 2012 at 03:36:26PM -0700, Junio C Hamano wrote:
As a result, the flag would have no effect in git log -p
--quiet or git show --quiet. Fix it by setting the
format flag before the call to setup_revisions.
This also means that
git show --name-status --quiet
Mike Hommey m...@glandium.org writes:
When rebasing the topic branches, I can hit conflict resolution that I
already had to do for other topic branches on another upstream import
branch. Here, git rerere is very helpful. But sometimes, the conflict
resolution is just to skip the patch,
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
for (i = 0; i cnt; i++) {
- if (rslt[i])
+ /*
+* Is rslt[i] an ancestor of any of the others?
+* then it is not
On 08/27/2012 06:15 PM, Junio C Hamano wrote:
Jiang Xin worldhello@gmail.com writes:
Some testcases will fail if current work directory is on a symlink.
symlink$ sh ./t4035-diff-quiet.sh
$ sh ./t4035-diff-quiet.sh --root=/symlink
$ TEST_OUTPUT_DIRECTORY=/symlink sh
Hi,
In the Linux kernel tree, commit 0136db586c028f71e7cc21cc183064ff0d5919
is a bit odd.
If I go to look to see what release it was in, I normally do:
$ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919
v3.6-rc1~59^2~56^2~76
However, it really showed up first in
Greg KH gre...@linuxfoundation.org writes:
In the Linux kernel tree, commit 0136db586c028f71e7cc21cc183064ff0d5919
is a bit odd.
If I go to look to see what release it was in, I normally do:
$ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919
v3.6-rc1~59^2~56^2~76
44 matches
Mail list logo
