On Fri, Apr 26, 2013 at 2:44 AM, Robert Zeh robert.allan@gmail.com wrote:
Can you just replace lstat/stat with cached_lstat/stat inside
git-compat-util.h and not touch all files at once? I think you may
need to deal with paths outside working directory. But because you're
using lookup
On Thu, Apr 25, 2013 at 3:36 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
But I do not care that much really. The patch is good either way, if
you don't like it, you go ahead and fix it, because I won't. I have
174 remote-helper related
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 3:30 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
But I do not care that much really. The patch is good either way, if
you don't like it, you go ahead and fix it,
On Thu, Apr 25, 2013 at 4:11 PM, Junio C Hamano gits...@pobox.com wrote:
Thomas Rast tr...@inf.ethz.ch writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Not just randomly synchronize the revisions with no checks at all. This
is the way bazaar's UI does it.
Also, add a non-ff
On Thu, Apr 25, 2013 at 4:37 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, Apr 25, 2013 at 3:30 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
But I do not care that much really. The patch
On Thu, Apr 25, 2013 at 4:41 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Apr 25, 2013 at 4:11 PM, Junio C Hamano gits...@pobox.com wrote:
Thomas Rast tr...@inf.ethz.ch writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Not just randomly synchronize the revisions
Felipe Contreras felipe.contre...@gmail.com writes:
Three random points.
* For this particular patch [1/9], especially because this would
land close to the corresponding remote-hg fixes (e.g. has_key is
deprecated), I think it is sufficient to say port fixes from
corresponding
Felipe Contreras felipe.contre...@gmail.com writes:
My gut feeling is that we should do it the way the Bazaar UI does it,
I don't have any evidence that there's anything wrong with the current
code, which Bazaar seems to but have, but for different purposes which
are hard to explain. I would
On Thu, Apr 25, 2013 at 5:01 PM, Junio C Hamano gits...@pobox.com wrote:
Having said that, I am more worried about wasting everybody's time
(and this includes your time) with the impedance mismatch between
you and the rest of us.
Our standard for explaining the change (either in the log or
Junio C Hamano gits...@pobox.com writes:
Applying Jonathan's idea on top of the early part that has graduated
to 'master', here is to add --ignore-removal (which is a more
natural way to say --no-all) and use it in the warning message.
Junio C Hamano (2):
git add: --ignore-removal is a
Junio C Hamano gits...@pobox.com writes:
One thing I noticed about Jonathan's warn_pathless_add() thing is
that even though it knows for which path we would behave differently
between the current version and Git 2.0, the warning message does
not say which path outside the current directory
Ramkumar Ramachandra wrote:
I thought ^@ was invented for scripting, but can't imagine a usecase for ^!.
I use git diff $commit^! from time to time to get the diff between a
merge and its first parent.
For comparison, I haven't found ^@ or git log $commit^! useful. The
commit introducing the
Junio C Hamano wrote:
At the point of calling warn_pathless_add(), it seems that we are
triggering this for paths that are not necessarily modified when run
with add -n -u.
Do you mean files that were touched but have no content change, or
something more subtle?
--
To unsubscribe from this
Jonathan Nieder jrnie...@gmail.com writes:
Ramkumar Ramachandra wrote:
I thought ^@ was invented for scripting, but can't imagine a usecase for ^!.
I use git diff $commit^! from time to time to get the diff between a
merge and its first parent.
For comparison, I haven't found ^@ or git
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
At the point of calling warn_pathless_add(), it seems that we are
triggering this for paths that are not necessarily modified when run
with add -n -u.
Do you mean files that were touched but have no content change, or
Junio C Hamano gits...@pobox.com writes:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
At the point of calling warn_pathless_add(), it seems that we are
triggering this for paths that are not necessarily modified when run
with add -n -u.
Do you mean files that were
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Do you mean files that were touched but have no content change, or
something more subtle?
[...]
Ahh, I haven't run anything under the debugger yet, but I think I
know what is going on.
Don't we limit our update-index
Hi,
Same as before, minus one fix. This time they are based on 'next' so there
shouldn't be any conflicts.
Here's a bunch of cleanups mostly to synchronize remote-bzr and remote-hg.
Felipe Contreras (9):
remote-helpers: trivial cleanups
remote-hg: remove extra check
remote-bzr: fix bad
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Do I have to say it? If code is removed, it's because it's not used.
contrib/remote-helpers/git-remote-bzr | 7 ---
contrib/remote-helpers/git-remote-hg | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git
Not needed since we use xrange ourselves.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4
1 file changed, 4 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index cfa96c1..80b3606
Carried from remote-hg.
The problem reportedly happened after doing a push that fails, the abort
causes the state of remote-hg to go bad, this happens because
remote-hg's marks are not stored, but 'git fast-export' marks are.
Ensure that the marks are _always_ stored.
Signed-off-by: Felipe
Just like in remote-hg.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index
To be in sync with remote-bzr.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index
Mercurial might convert the URL to something more appropriate, like an
absolute path. Lets store that instead of the original URL, which won't
work from a different working directory if it's relative.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Otherwise we get notification, progress bars, and what not.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
It's added by fast-export, the user didn't type it.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index
Do not just randomly synchronize the revisions with no checks at all.
I don't have any evidence that there's anything wrong with the current code,
which Bazaar seems to use, but for different purposes. Let's use the logic
Bazaar UI uses to avoid surprises.
Also, add a non-ff check.
Jonathan Nieder jrnie...@gmail.com writes:
Maybe the warning should happen after add_file_to_index() has run,
letting git compare the old and new index entries for that path?
Yeah, new and deleted cases we do not have to worry about, so a
no-op add_file_to_index() is the only case we have to
On Thu, Apr 25, 2013 at 8:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Mercurial might convert the URL to something more appropriate, like an
absolute path. Lets store that instead of the original URL, which won't
work from a different working directory if it's relative.
On Thu, Apr 25, 2013 at 8:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Otherwise we get notification, progress bars, and what not.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 3 +++
1 file changed, 3 insertions(+)
Hi,
After being contacted by the emacs developers and others who are stuck with
Bazaar, which at this point seems to be utterly abandoned, I realized the
current implementation is too crude.
Bazaar branches are very simplistic, and our support for them is the same; we
need to create one remote
This code was not used at all.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index
Might be more efficient, but the real reason to use the marks will be
revealed in upcoming patches.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
It doesn't seem to make any difference, but revision_tree() requires a
lock.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
And fail properly when we can't.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index
In order to do that, we need to store the marks of every file, so that
they can be fetched when needed. Unfortunately we can't tell bazaar that
nothing changed, we need to send the data so that it can figure it out
by itself.
And since it will be requesting a bunch of information by the file_id,
If the branches diverge we want to reset the pointer to where the remote
actually is. Since we can access remote branches just as easily as local
ones, let's do so.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 8 +++-
1 file changed,
If part of the merge was already pushed, we don't have the blob_marks
available, however, the commits are already stored in bazaar, so we can
use the revision_tree to fetch the contents.
We want to do this only when there's no other option.
There's no easy way to test this.
Signed-off-by:
There should be no functional changes. Basically we want to reserve the
'repo' variable.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git
In bazaar, a repository can contain multiple branches, and previously we
were supporting only one branch at a time. Now we fetch them all.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 158 ++
1 file
When branches have '/' in their name (aka. sub-branches), bazaar seems
to choke while creating the new directory.
Also, git cannot have both 'foo' and 'foo/bar'.
So let's replace slashes with a plus sign.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
This way all the remotes share the same data, so adding multiple
remotes, or renaming them doesn't create extra overhead.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 22 +++---
1 file changed, 15 insertions(+), 7
This way all the remotes can share the same git objects, and the same
marks. The information we want to store per remote is very small.
The code transparently converts from one organization of marks, to the
other. It's rather smooth and there shouldn't be any issues.
Signed-off-by: Felipe
So that we don't end up with 'None', and also synchronize it with the
one from remote-hg.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git
The official method is incredibly inefficient and slow.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
No need to manually count the revisions, and also, this would help to
iterate more properly.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git
This way we don't need to store the list of all the revisions, which
doesn't seem to be very memory efficient with bazaar's design, for
whatever reason.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 5 +++--
1 file changed, 3
So it doesn't time out.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index
Bazaar doesn't seem to be tested for multiple usage of branches, so
resources seem to be leaked all over. Let's try to minimize this by
accessing the Branch objects only when needed.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 28
It probably doesn't make any difference, since we usually fetch along
the 'master' branch, and when we don't probably the current
transport-helper code doesn't work correctly.
But if it did work correctly, this might be useful.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
On Thu, Apr 25, 2013 at 7:58 PM, John Szakmeister j...@szakmeister.net wrote:
On Thu, Apr 25, 2013 at 8:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Mercurial might convert the URL to something more appropriate, like an
absolute path. Lets store that instead of the original URL,
On Thu, Apr 25, 2013 at 6:11 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
You are missing my point, this is *ONE INSTANCE*. Show me another
instance where a reviewer complained about the lack of a descriptive
commit messages on
On Thu, Apr 25, 2013 at 8:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
I forgot to mention; these apply on top of the previous 'fixes and cleanups'.
Felipe Contreras (20):
remote-bzr: cleanup CustomTree
remote-bzr: delay blob fetching until the very end
remote-bzr: fix
101 - 153 of 153 matches
Mail list logo
