On Wed, Sep 01, 2010 at 06:37:08PM +0100, Julian Foad wrote:
Daniel Näslund wrote:
The question is: Do we want 'svn patch to be able to add empty files.
If add an empty file is a well defined operation in Git-diff syntax,
then yes, it would be good to support it. As well as delete
On 04.09.2010 02:44, Augie Fackler wrote:
On Sep 3, 2010, at 7:10 AM, Daniel Näslund wrote:
On Fri, Sep 03, 2010 at 12:18:37PM +0200, Branko Čibej wrote:
On 02.09.2010 10:50, Branko Čibej wrote:
Hmm, this is interesting. :) Git faithfully (blindly?) interprets Unix
permission bits, whiles
On 04.09.2010 02:46, Augie Fackler wrote:
On Sep 2, 2010, at 4:03 AM, Daniel Näslund wrote:
$ svn diff --git
Index: empty
===
diff --git a/trunk/empty b/trunk/empty
new directory mode 10644
I'd recommend testing this
On 02.09.2010 10:50, Branko Čibej wrote:
On 02.09.2010 10:27, Daniel Shahaf wrote:
Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:13:00 +0200:
On Wed, Sep 01, 2010 at 06:37:08PM +0100, Julian Foad wrote:
This may be off topic, but I'm wondering whether Git has defined such
operations on
On Fri, Sep 03, 2010 at 12:18:37PM +0200, Branko Čibej wrote:
On 02.09.2010 10:50, Branko Čibej wrote:
Hmm, this is interesting. :) Git faithfully (blindly?) interprets Unix
permission bits, whiles SVN faithfully (blindly?) interprets the
contents of special files ... I wonder if svn patch
On Sep 3, 2010, at 7:10 AM, Daniel Näslund wrote:
On Fri, Sep 03, 2010 at 12:18:37PM +0200, Branko Čibej wrote:
On 02.09.2010 10:50, Branko Čibej wrote:
Hmm, this is interesting. :) Git faithfully (blindly?) interprets
Unix
permission bits, whiles SVN faithfully (blindly?) interprets the
(Thanks for the examples. I suppose next time I should try to run
'touch foo; $svn add foo; $svn diff --git' myself...)
Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:05:41 +0200:
On Wed, Sep 01, 2010 at 10:54:08PM +0300, Daniel Shahaf wrote:
Daniel Näslund wrote on Wed, Sep 01, 2010 at
Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:13:00 +0200:
On Wed, Sep 01, 2010 at 06:37:08PM +0100, Julian Foad wrote:
This may be off topic, but I'm wondering whether Git has defined such
operations on directories fully or at all, since it doesn't version them
explicitly. I mean, can
On 02.09.2010 10:27, Daniel Shahaf wrote:
Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:13:00 +0200:
On Wed, Sep 01, 2010 at 06:37:08PM +0100, Julian Foad wrote:
This may be off topic, but I'm wondering whether Git has defined such
operations on directories fully or at all, since it doesn't
On Thu, Sep 02, 2010 at 11:27:07AM +0300, Daniel Shahaf wrote:
Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:13:00 +0200:
On Wed, Sep 01, 2010 at 06:37:08PM +0100, Julian Foad wrote:
This may be off topic, but I'm wondering whether Git has defined such
operations on directories fully or
On Thu, Sep 02, 2010 at 11:14:27AM +0300, Daniel Shahaf wrote:
(Thanks for the examples. I suppose next time I should try to run
'touch foo; $svn add foo; $svn diff --git' myself...)
Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:05:41 +0200:
On Wed, Sep 01, 2010 at 10:54:08PM +0300,
On 02.09.2010 11:10, Daniel Näslund wrote:
So this implicitly creates the file if it doesn't exist already; in
other words, we do not distinguish setting a property on an existing
file (without content changes) from adding a file with properties.
Would it be better to make a distinction ---
On Thu, Sep 02, 2010 at 12:04:15PM +0200, Branko Čibej wrote:
On 02.09.2010 11:03, Daniel Näslund wrote:
Note that we don't yet perform any symlink operation when applying a
path with svn:special set.
If that isn't fixed for 1.7, then it rates a big warning!! in the
release notes.
Filed
On Thu, Sep 02, 2010 at 11:03:36AM +0200, Daniel Näslund wrote:
We have two goals I think:
i) Implement a format that is interoperable with git and mercurial and
possible other vcs tools that choose to implement the git extensions
to the unidiff format.
ii) Adjust the format dictated
On Thu, Sep 02, 2010 at 11:27:07AM +0300, Daniel Shahaf wrote:
Daniel Näslund wrote on Thu, Sep 02, 2010 at 07:13:00 +0200:
On Wed, Sep 01, 2010 at 06:37:08PM +0100, Julian Foad wrote:
This may be off topic, but I'm wondering whether Git has defined such
operations on directories fully or
On 02.09.2010 13:25, Stefan Sperling wrote:
For now, an svn symlink will show up as an empty file when the patch is
applied with git. I don't think that's a huge problem. Nice to have, but
not release critical for Subversion.
That's not how I read the patch ... I believe git will create a
On Thu, Sep 02, 2010 at 02:09:03PM +0200, Branko Čibej wrote:
On 02.09.2010 13:25, Stefan Sperling wrote:
For now, an svn symlink will show up as an empty file when the patch is
applied with git. I don't think that's a huge problem. Nice to have, but
not release critical for Subversion.
On Thu, 2010-09-02 at 14:03 +0200, Stefan Sperling wrote:
On Thu, Sep 02, 2010 at 01:57:49PM +0200, Stefan Sperling wrote:
Right now, svn patch will always add an empty file if something is added
that only has props. But the patch might want to create a directory instead.
Is there a 1:1
).
If anyone has any other cases, please let me know.)
The question is: Do we want 'svn patch to be able to add empty files.
+ It's consistent with the idea of a git diff dealing with tree changes.
- It adds an extra special case to the code. I've seen GNU patch with
its gigantic if-spaghetti's. Just
(it has no unidiff headers).
If anyone has any other cases, please let me know.)
The question is: Do we want 'svn patch to be able to add empty files.
+ It's consistent with the idea of a git diff dealing with tree changes.
- It adds an extra special case to the code. I've seen GNU patch
was adding an empty file (it has no unidiff headers).
If anyone has any other cases, please let me know.)
How does a diff adding an empty file look?
The question is: Do we want 'svn patch to be able to add empty files.
+ It's consistent with the idea of a git diff dealing with tree changes
===
Property changes on: empty
___
Added: foo
## -0,0 +1 ##
+value
The question is: Do we want 'svn patch to be able to add empty files.
+ It's consistent with the idea of a git diff dealing with tree
22 matches
Mail list logo
