Eric Sunshine sunsh...@sunshineco.com writes:
The pattern [y] will match file named 'y'. It probably is unusual for
files named 'y', 'n', etc. to exist in the top-level directory, but
the gitignore patterns already provide an escape hatch for these
unusual cases.
But how does the user know
The last error I encountered is:
r7009 = 39805bb078983e34f2fc8d2c8c02d695d00d11c0 (refs/remotes/DMC4_Basic)
Too many open files: Can't open file
'/home/il/builds/sicap/gitsvn/prd_dmc4.svn/db/revs/0/786': Too many open
files at
Hi Eric. I'm out of spare time and I still unable to import my repo.
The code of SVN.pm is too complex. Please help me.
Here's the list of my issues:
* I think git-svn doesn't handle the case, when a tag is deleted.
I expected it to rename the ref from tags/tagname to
tags/tagname@rev, but
Hi Matthieu,
On Mon, May 6, 2013 at 3:58 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
The pattern [y] will match file named 'y'. It probably is unusual for
files named 'y', 'n', etc. to exist in the top-level directory, but
the gitignore
David Goldfarb d...@degel.com writes:
Git works correctly under Linux (Ubuntu 12.04; git 1.7.9.5). I've attached
the strace outputs. (Note: for reasons that are probably irrelevant, I needed
to run the commands sudo'd. Shout back if this is an issue).
Under Windows 7, Cygwin git 1.7.9,
Dimitar Bonev dsbo...@gmail.com writes:
One more argument against the suggestion of doing a commit ahead of
time is that I like to think in separation to reduce complexity - in
particular I like to think only for the working dir and index states,
commits - I treat them as finished work. If I
Looks like it works.
From the windows machine:
U:\foogit cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856
100644 blob b02e7c87fe376a353ea4f014bdb3f5200a946b37foo1
100644 blob 2cbf64f759a62392ad9dfe1fb9c2cdb175876014foo2
U:\foo
Double-checking that nothing was fixed
Jonathan Nieder jrnie...@gmail.com writes:
Thomas Rast wrote:
Junio C Hamano gits...@pobox.com writes:
* jn/config-ignore-inaccessible (2013-04-15) 1 commit
- config: allow inaccessible configuration under $HOME
When $HOME is misconfigured to point at an unreadable directory, we
used
David Goldfarb d...@degel.com writes:
Looks like it works.
From the windows machine:
U:\foogit cat-file -p 0b89efdeef245ed6a0a7eacc5c578629a141f856
100644 blob b02e7c87fe376a353ea4f014bdb3f5200a946b37foo1
100644 blob 2cbf64f759a62392ad9dfe1fb9c2cdb175876014foo2
Ok. Continuing in the same shell:
U:\foogit status
# On branch master
# Changes to be committed:
# (use git reset HEAD file... to unstage)
#
# new file: trace1
#
# Untracked files:
# (use git add file... to include in what will be committed)
#
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
On Fri, May 3, 2013 at 12:56 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
How do we know that this doesn't break any users of fast-import? Your
comment isn't very reassuring:
the vast majority
Michael Haggerty mhag...@alum.mit.edu writes:
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
On Fri, May 3, 2013 at 12:56 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
How do we know that this doesn't break any users of fast-import? Your
On 05/06/2013 12:32 PM, Thomas Rast wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
On Fri, May 3, 2013 at 12:56 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
How do we know that this
Oops, I earlier missed the second half of your message, where you suggested
that I patch move_temp_to_file().
Sorry, I don't have the tool-chain or knowledge to recompile git into this
win/Cygwin environment.
What I can do, realistically, is:
- Follow exact instructions.
- (with some obvious
On 05/03/2013 10:38 AM, Jeff King wrote:
I found another race related to the packed-refs code. Consider for a
moment what happens when we are looking at refs and another process does
a simultaneous git pack-refs --all --prune, updating packed-refs and
deleting the loose refs.
If we are
On 05/03/2013 07:28 PM, Jeff King wrote:
On Fri, May 03, 2013 at 11:26:11AM +0200, Johan Herland wrote:
You don't really need to be sure that packed-refs is up-to-date. You
only need to make sure that don't rely on lazily loading loose refs
_after_ you have loaded packed-refs.
True. As
Hi Thomas,
On Mon, 6 May 2013, Thomas Rast wrote:
The proposed patch wants to stop writing marks (in --export-marks) for
anything but commits.
Then it should not go in.
Ciao,
Dscho
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
We don't care about blobs, or any object other than commits, but in
order to find the type of object, we are parsing the whole thing, which
is slow, specially in big repositories with lots of big files.
I did a double-take on
Hi,
I'm getting a segfault in git merge-tree using v1.8.2.2 on MacOS
10.8.3. I can't share the repo, but I can build patches and check if
they fix the problem :)
Here's a bt:
(gdb) run
Starting program:
/usr/local/Cellar/git/1.8.2.2/libexec/git-core/git-merge-tree
-Original Message-
From: Thomas Rast
Sent: Monday, May 06, 2013 5:42 AM
David Goldfarb d...@degel.com writes:
Git works correctly under Linux (Ubuntu 12.04; git 1.7.9.5). I've
attached the strace outputs. (Note: for reasons that are probably
irrelevant, I needed to run the
On Mon, May 06, 2013 at 03:02:10PM +0200, Andreas Jacobsen wrote:
I'm getting a segfault in git merge-tree using v1.8.2.2 on MacOS
10.8.3. I can't share the repo, but I can build patches and check if
they fix the problem :)
Can you rebuild with debugging information and try the backtrace
Jonathan Nieder jrnie...@gmail.com writes:
I ran into this message for the first time today.
$ git fetch --all
Fetching origin
remote: Counting objects: 368, done.
[...]
Fetching gitk
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
Hello,
The included patch attempts to improve post-receive-email. It's a
trivial change, but one that helps us Gitolite users. Comments are
welcome, and this is my first attempt at contributing to the Git
project. Please keep me on CC as I'm not on the list.
From
Sure, here you go, this time built from the HEAD I found on github
(7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
NO_GETTEXT=1 make prefix=/usr/local/Cellar/git/HEAD CC=cc CFLAGS='-O0
-g' install (this is homebrew's setup, but I built it manually rather
than using the recipe.)
And the gdb
On Mon, May 06, 2013 at 04:13:28PM +0200, Andreas Jacobsen wrote:
Sure, here you go, this time built from the HEAD I found on github
(7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
NO_GETTEXT=1 make prefix=/usr/local/Cellar/git/HEAD CC=cc CFLAGS='-O0
-g' install (this is homebrew's setup,
On Mon, May 06, 2013 at 03:29:23PM +0100, John Keeping wrote:
On Mon, May 06, 2013 at 04:13:28PM +0200, Andreas Jacobsen wrote:
Sure, here you go, this time built from the HEAD I found on github
(7d3ccdffb5d28970dd7a4d177cfcca690ccd0c22) with:
NO_GETTEXT=1 make
Dimitar Bonev dsbo...@gmail.com writes:
[administrivia: please do not drop people out of Cc list]
Actually this is not the case as I tried to explain with the 'git
commit' followed by 'git checkout HEAD~1 -- targetfile' followed by
'git commit --amend' example. The index and the working dir
Jeff King p...@peff.net writes:
On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
We don't care about blobs, or any object other than commits, but in
order to find the type of object, we are parsing the whole thing, which
is slow, specially in big repositories with lots of
Michael Haggerty mhag...@alum.mit.edu writes:
Yes, it can be handy to start loading the first blobfile in parallel
with the later stages of the conversion, before the second dumpfile is
ready. In that case the user needs to pass --export-marks to the first
fast-import process to export marks
git-merge-tree causes a null pointer dereference when a directory
entry exists in only one or two of the three trees being compared with
no corresponding entry in the other tree(s).
When this happens, we want to handle the entry as a directory and not
attempt to mark it as a file merge. Do this
Trond Hasle Amundsen t.h.amund...@usit.uio.no writes:
The included patch attempts to improve post-receive-email. It's a
trivial change, but one that helps us Gitolite users. Comments are
welcome, and this is my first attempt at contributing to the Git
project. Please keep me on CC as I'm not
[ Unashamedly offtopic... asking here because I like git design and
coding style, and ppg is drawing plenty of inspiration from the old
git shell scripts. Please kindly flame me privately... ]
ppg is a wrapper around git to maintain and distribute Puppet configs,
adding a few niceties.
Now, ppg
Trond Hasle Amundsen t.h.amund...@usit.uio.no writes:
Hello,
The included patch attempts to improve post-receive-email. It's a
Please don't ;-)
Eh, actually, thanks for the patch.
But when you send a patch the next time around, please have the
above and the next three lines (i.e.
Junio C Hamano gits...@pobox.com writes:
Trond Hasle Amundsen t.h.amund...@usit.uio.no writes:
Hello,
The included patch attempts to improve post-receive-email. It's a
Please don't ;-)
More precisely: you should have a look at git-multimail (in directory
contrib/, in branch for now pu/,
Junio C Hamano gits...@pobox.com writes:
By discarding marks on blobs, we may be robbing some optimization
possibilities, and by discarding marks on tags, we may be robbing
some features, from users of fast-export; we might want to add an
option --use-object-marks={blob,commit,tag} or
On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote:
I'm also not sure why your claim we don't care about blobs is true,
because naively we would want future runs of fast-export to avoid having
to write out the whole blob content when mentioning the blob again.
The existing
Junio C Hamano gits...@pobox.com writes:
But when you send a patch the next time around, please have the
above and the next three lines (i.e. introductory text) _below_
the three-dash line.
Allright, noted.
From 878a7af9088e2bcc3afc9b09b9023f1f188c844b Mon Sep 17 00:00:00 2001
From: Trond
Matthieu Moy matthieu@grenoble-inp.fr writes:
The included patch attempts to improve post-receive-email. It's a
Please don't ;-)
More precisely: you should have a look at git-multimail (in directory
contrib/, in branch for now pu/, or from
https://github.com/mhagger/git-multimail)
Jeff King p...@peff.net writes:
On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote:
I'm also not sure why your claim we don't care about blobs is true,
because naively we would want future runs of fast-export to avoid having
to write out the whole blob content when mentioning
On Mon, May 06, 2013 at 09:32:41AM -0700, Junio C Hamano wrote:
OK. If the argument is we do not write them, so do not bother reading
them back in, I think that is reasonable.
The way I read builtin/fast-export.c::import_marks() is that it is
more like we do not write them, and we do not
Translate 44 new messages came from git.pot update in
c6bc7d4 (l10n: git.pot: v1.8.3 round 2 (44 new, 12 removed)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 139 +++
1 file changed, 77 insertions(+), 62
Johan Herland jo...@herland.net writes:
Let me try to summarize my views on how refnames should work in Git, to
see if we can identify where we differ on the principles (or if we, in
fact, differ at all):
Thanks; I think I already said where I think we differ in a separate
message, but a
Santi Béjar sa...@agolina.net writes:
The next question could be: why not make it work with $url too? As in:
$ git merge git://git.kernel.org/pub/scm/git/git.git//master
You need to remember merge is a local operation, working in your
local repository. Like it or not, the UI of Git makes
Jeff King p...@peff.net writes:
So yes, I think this is an obviously correct optimization. Thanks for
clarifying, and sorry to be so slow.
No need to be sorry. It just shows that the log message could have
been more helpful.
Here is what I tentatively queued.
commit
On Mon, May 06, 2013 at 10:17:41AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So yes, I think this is an obviously correct optimization. Thanks for
clarifying, and sorry to be so slow.
No need to be sorry. It just shows that the log message could have
been more
Junio C Hamano gits...@pobox.com writes:
Just a few typofixes...
Johan Herland jo...@herland.net writes:
Let me try to summarize my views on how refnames should work in Git, to
see if we can identify where we differ on the principles (or if we, in
fact, differ at all):
Thanks; I think I
On Mon, May 06, 2013 at 01:19:35PM -0400, Jeff King wrote:
Here is what I tentatively queued.
[...]
Yeah, that is much for to understand (to me, at least).
Ugh. That was supposed to be much easier to understand. Perhaps I will
learn to type one day.
-Peff
--
To unsubscribe from this
Johan Herland jo...@herland.net writes:
... there is AFAICS _no_ way for sscanf() - having
already done one or more format extractions - to indicate to its caller
that the input fails to match the trailing part of the format string.
Yeah, we can detect when we did not have enough, but we
I've observed that the p4 command that git-p4 delegates to occasionally
outputs Windows-style line endings even on the OS X platform. When this
happens, git-p4 gets very confused and crashes out.
I've attached a patch which seems to fix the issue in my case. Now this
patch is a pretty bad
On Mon, May 06, 2013 at 02:03:40PM +0200, Michael Haggerty wrote:
We could fix this by making sure our packed-refs file is up to date
s/file/cache/
Yeah, I meant our view of the packed-refs file, but I think cache
says that more succinctly. I'll be sure to make it clear when I start
writing
On Mon, May 06, 2013 at 02:12:29PM +0200, Michael Haggerty wrote:
I think that would be correct (modulo that step 1 cannot happen for
enumeration). But we would like to avoid loading all loose refs if we
can. Especially on a cold cache, it can be quite slow, and you may not
even care
On Mon, May 6, 2013 at 7:31 AM, Jeff King p...@peff.net wrote:
On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
We don't care about blobs, or any object other than commits, but in
order to find the type of object, we are parsing the whole thing, which
is slow, specially in
On Mon, May 6, 2013 at 10:08 AM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
On Sun, May 05, 2013 at 05:38:53PM -0500, Felipe Contreras wrote:
We don't care about blobs, or any object other than commits, but in
order to find the type of object, we are parsing the
On Mon, May 06, 2013 at 02:02:13PM -0500, Felipe Contreras wrote:
I did a double-take on reading this subject line and first paragraph,
thinking surely fast-export needs to actually output blobs?.
If you think that, then you are not familiar with the code.
--export-marks=file::
[...]
On Mon, May 6, 2013 at 11:20 AM, Jeff King p...@peff.net wrote:
On Mon, May 06, 2013 at 08:08:45AM -0700, Junio C Hamano wrote:
I'm also not sure why your claim we don't care about blobs is true,
because naively we would want future runs of fast-export to avoid having
to write out the
On Mon, May 6, 2013 at 2:11 PM, Jeff King p...@peff.net wrote:
On Mon, May 06, 2013 at 02:02:13PM -0500, Felipe Contreras wrote:
I did a double-take on reading this subject line and first paragraph,
thinking surely fast-export needs to actually output blobs?.
If you think that, then you
Am 06.05.2013 02:19, schrieb Chris Packham:
This did get me thinking. Why does an uninitialized submodule need to
have an empty directory? If it didn't the maintainer in question
probably would have realized that he needed to run git submodule
update --init when his cd submodule command
El 06/05/2013 19:11, Junio C Hamano gits...@pobox.com va escriure:
Santi Béjar sa...@agolina.net writes:
The next question could be: why not make it work with $url too? As in:
$ git merge git://git.kernel.org/pub/scm/git/git.git//master
You need to remember merge is a local operation,
Implement a 'git add --interactive' style of interactive git-clean.
It will show what would be done before start to clean. See
``Interactive mode`` for details.
Interactive mode
When the command enters the interactive mode, it shows the
files and directories to be cleaned, and
Show what would be done and the user must confirm before actually
cleaning. In the confirmation dialog, the user has three choices:
* y/yes: Start to do cleaning.
* n/no: Nothing will be deleted.
* e/edit: Exclude items from deletion using ignore patterns.
When the user chooses the edit
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns instead of in one column will solve
this problem.
Since no longer show items to be cleaned using the Would remove ...
format (only plain filenames) in interactive mode, we add instructions
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables for other git commands, such as
git-add--interactive and git-stash:
* color.interactive: When set to always, always use colors for
interactive prompts and displays. When false (or
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We can reused this method later for
more actions.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated memory of the array.
* The
The documentation assures users that A...B is defined as 'r1 r2 --not
$(git merge-base --all r1 r2)'. This isn't in fact quite true, because
the calculated merge bases are not sent to add_rev_cmdline().
Previously, the effect was pretty minor - all that I can think of is
that git rev-list
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and
Add a rm -i style interactive cleaning method. User must confirm one
by one before starting to delete.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
builtin/clean.c | 36
1 file changed, 36 insertions(+)
diff --git a/builtin/clean.c b/builtin/clean.c
Signed-off-by: Jiang Xin worldhello@gmail.com
---
Documentation/git-clean.txt | 70 -
1 file changed, 63 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index f5572..56d60 100644
---
Ralf Thielow ralf.thie...@gmail.com writes:
#: branch.c:275
-#, fuzzy, c-format
+#, c-format
msgid Not a valid branch point: '%s'.
-msgstr Ungültiger Zweig-Name: '%s'
+msgstr Ungültige Zweig-Version: '%s'
That's a bit strange and calls for a proper translation of branch
point.
Kevin Bracey ke...@bracey.fi writes:
Some side branching and odd merging to illustrate various flaws in
revision list scans, particularly when limiting the list.
Many expected failures, which will be gone by the end of the history
traversal refinements series.
Signed-off-by: Kevin Bracey
On 04/30/13 15:47, René Scharfe wrote:
Am 30.04.2013 02:11, schrieb Stephen Boyd:
(resending since the attachment seems to make vger sad)
Hi,
I'm running git rev-list | git cherry-pick --stdin on a range of about
300 commits. Eventually the chery-pick dies with:
error: cannot fork()
Kevin Bracey ke...@bracey.fi writes:
+#,---E--. *H--. * marks !TREESAME parent paths
+# /\ / \*
+# *A--*B---D--*F-*G-K-*L-*M
+# \ /* \ /
+#`-C-' `-*I-*J
+#
+# A creates file, B and F change it.
Kevin Bracey ke...@bracey.fi writes:
diff --git a/revision.c b/revision.c
index a67b615..c88ded8 100644
--- a/revision.c
+++ b/revision.c
@@ -429,10 +429,100 @@ static int rev_same_tree_as_empty(struct rev_info
*revs, struct commit *commit)
return retval = 0 (tree_difference ==
Felipe Contreras felipe.contre...@gmail.com writes:
The story is different on the fast-import side, where we do say we
dump the full table and a later run can depend on these marks.
Yes, and gaining nothing but increased disk-space.
I thought that the gaining nothing has already been refuted
On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/06/2013 12:32 PM, Thomas Rast wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
On Fri, May 3, 2013 at 12:56 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe
On Mon, May 6, 2013 at 7:20 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi Thomas,
On Mon, 6 May 2013, Thomas Rast wrote:
The proposed patch wants to stop writing marks (in --export-marks) for
anything but commits.
Then it should not go in.
If that rationale was valid, no
On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Yes, it can be handy to start loading the first blobfile in parallel
with the later stages of the conversion, before the second dumpfile is
ready. In that case the user
Kevin Bracey ke...@bracey.fi writes:
The documentation assures users that A...B is defined as 'r1 r2 --not
$(git merge-base --all r1 r2)'. This isn't in fact quite true, because
the calculated merge bases are not sent to add_rev_cmdline().
We want the commands to be able to tell which ones in
On Mon, May 6, 2013 at 4:19 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Yes, it can be handy to start loading the first blobfile in parallel
with the later stages
On Mon, May 06, 2013 at 02:41:22PM -0400, Jeff King wrote:
That is a weaker guarantee, and I think we can provide it with:
1. Load all loose refs into cache for a particular enumeration.
2. Make sure the packed-refs cache is up-to-date (by checking its
stat() information and
On Tue, Jan 22, 2013 at 08:49:22AM +0100, Robin Rosenberg wrote:
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Other implementations, eg. Git in cygwin are allegedly also
somewhat incompatible with Git For Windows and on *nix platforms
the resolution of the
On Mon, May 6, 2013 at 7:06 PM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
Let me try to summarize my views on how refnames should work in Git, to
see if we can identify where we differ on the principles (or if we, in
fact, differ at all):
Thanks; I think
Kevin Bracey ke...@bracey.fi writes:
On 04/05/2013 20:25, Ramsay Jones wrote:
Sparse issues an 'sole_interesting' not declared. Should it be static?
warning. In order to suppress the warning, since this symbol does not
need more than file visibility, we simply add the static modifier to
its
Johan Herland jo...@herland.net writes:
+test_expect_success 'work-around clone with namespaced remote refs' '
+ rm -rf client
+ git init client
+ (
+ cd client
+ git remote add origin ../server
+ git config --unset-all
Johan Herland jo...@herland.net writes:
This test verifies that the following expressions all evaluate to the
full refname refs/remotes/origin/heads/master:
As I've aleady said, I am not convinced that local refname
resolution should pay attention to refspec mapping, so I won't look
at this
Johan Herland jo...@herland.net writes:
diff --git a/refs.c b/refs.c
index 7231f54..8b02140 100644
--- a/refs.c
+++ b/refs.c
@@ -1724,7 +1724,24 @@ const char *prettify_refname(const char *name)
0);
}
-const char *ref_rev_parse_rules[] = {
+static void
Johan Herland jo...@herland.net writes:
This patch removes the only remaining user of ref_rev_parse_rules.
It has now been fully replaced by ref_expand_rules. Hence this patch
also removes ref_rev_parse_rules.
Yeah, I was wondering when you would do this while reading [4/7], as
removing the
Johan Herland jo...@herland.net writes:
refname_match() is used to check whether a given shorthand name matches a
given full refname, but that full refname does not always belong in the
local repo, rather it is sometimes taken from list of refs sent over from
a remote repo.
That local vs
Felipe Contreras felipe.contre...@gmail.com writes:
How?
* if we teach fast-import to optionally not write marks for blobs
and trees out, your remote-bzr can take advantage of it,
I already said remote-bzr is irrelevant. *Everybody* benefits.
Everybody who does _not_ need to look at
I'd love for git apply to have an equivalent to git add -p. (I'm
guessing it would be called --interactive since git apply -p is
taken and --patch would be confusing.) Has anyone thought about this?
After taking a quick look at git-add--interactive.perl, it seems like
the main steps would be:
Johan Herland jo...@herland.net writes:
Ok, so whereas I consider the refspec to be king, and that the expansion
from convenient shorthands to full remote-tracking refnames should be
derived from the chosen refspec, you would (if I understand you correctly)
rather have a constant (i.e.
This fixes the races I brought up in the surrounding thread:
http://thread.gmane.org/gmane.comp.version-control.git/223299
The individual races are describe in more detail in each commit, but for
reference, here is the complete reproduction recipe (which I posted
already in several parts
When we attempt to resolve a ref, the first thing we do is
call lstat() to see if it is a symlink or a real ref. If we
find that the ref is missing, we fall back to looking it up
in the packed-refs file. If we find the loose ref does exist
(and is a regular file), we continue with trying to open
Once we read the packed-refs file into memory, we cache it
to save work on future ref lookups. However, our cache may
be out of date with respect to what is on disk if another
process is simultaneously packing the refs. Normally it
is acceptable for us to be a little out of date, since there
is no
If we are iterating through the refs using for_each_ref (or
any of its sister functions), we can get into a race
condition with a simultaneous pack-refs --prune that looks
like this:
0. We have a large number of loose refs, and a few packed
refs. refs/heads/z/foo is loose, with no matching
On Mon, May 06, 2013 at 10:43:13PM -0400, Jeff King wrote:
I hooked the refreshing into get_packed_refs, since then all callers get
it for free. It makes me a little nervous, though, just in case some
caller really cares about calling get_packed_refs but not having the
list of packed-refs
The sha1 argument of peel_ref is meant to hold the peeled
object name for output. Let's call it peeled which makes
it more clear that it is not an input sha1 (especially as we
will be adding such an input sha1 in the next patch).
Signed-off-by: Jeff King p...@peff.net
---
Simple cleanup for the
On 05/06/2013 11:19 PM, Felipe Contreras wrote:
On Mon, May 6, 2013 at 10:18 AM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Yes, it can be handy to start loading the first blobfile in parallel
with the later stages of the conversion, before the
The peel_ref function lets a caller peel an object, taking
advantage of the fact that we may have the peeled value
cached for a packed ref. However, this function is not
necessarily safe in the face of simultaneous ref updates.
The caller has typically already loaded the ref from disk
(e.g., as
On 05/06/2013 11:36 PM, Felipe Contreras wrote:
This would simplify the documentation, and obliterate the need to use
mark files at all:
As explained in my other email, this documentation change does not
remove all of the reasons that users might want to use mark files. I
would still like to
On 05/06/2013 11:04 PM, Felipe Contreras wrote:
On Mon, May 6, 2013 at 5:45 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 05/06/2013 12:32 PM, Thomas Rast wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On 05/03/2013 08:23 PM, Felipe Contreras wrote:
On Fri, May 3, 2013 at 12:56
1 - 100 of 114 matches
Mail list logo
