On 12/19/2013 02:11 AM, Johan Herland wrote:
On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
A correct incremental converter could be done (as long as the CVS users
don't literally change history retroactively) but it would be a lot of work.
Although I agree
On 12/19/2013 05:06 AM, Eric S. Raymond wrote:
Michael Haggerty mhag...@alum.mit.edu:
If you haven't tried cvs2git yet, please start it up somewhere in the
background. It might take a while but it should have no trouble with
your repos, and then you can compare the tools based on experience
On Wed, Dec 18, 2013 at 07:48:59PM -0600, Tom Miller wrote:
I did not intend to introduce new lingo. I did some searching through
history to see if something like this had been worked on before and
I found a commit by Jeff King that introduced me the the idea of
DF conflicts
I take all the
I've got a better version [1] that fixes everything I can think of
(there's still some room for improvements). I'm going to use it a bit
longer before reposting again. But here's its basic design without
going down to code
New .git file format includes two lines:
-- 8 --
gitid: id
gitdir: path
--
Hi all,
If I launch gitk, switch the lower right pane from Patch view mode to
Tree view, expand a few directories, and then changing to viewing a
different commit, the tree automatically collapses again. This is
really annoying when trying to view changes to the tree structure over
time; is
On Thu, Dec 19, 2013 at 10:31 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 12/19/2013 02:11 AM, Johan Herland wrote:
On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
A correct incremental converter could be done (as long as the CVS users
don't literally
On 12/19/2013 04:26 PM, Johan Herland wrote:
On Thu, Dec 19, 2013 at 10:31 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
On 12/19/2013 02:11 AM, Johan Herland wrote:
On Thu, Dec 19, 2013 at 12:44 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
A correct incremental converter could be
On Wed, Dec 18, 2013 at 6:37 PM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder christian.cou...@gmail.com writes:
On Wed, Dec 18, 2013 at 1:37 PM, Karsten Blees karsten.bl...@gmail.com
wrote:
Am 11.12.2013 08:46, schrieb Christian Couder:
+enum repl_fmt { SHORT, MEDIUM, FULL };
On 12/19/2013 01:04 AM, Jeff King wrote:
On Wed, Dec 18, 2013 at 11:44:58PM +0100, Michael Haggerty wrote:
[While doing so, I got sidetracked by the question: what happens if a
prune process deletes the objects/XX directory just the same moment
that another process is trying to write an
On 2013-12-19 01.15, Jeff King wrote:
On Wed, Dec 18, 2013 at 02:59:12PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Yes, that is locally OK, but depending on how the caller behaves, we
might need to have an extra saved_errno dance here, which I didn't
want to get into...
Torsten Bögershausen tbo...@web.de writes:
Thanks for an interesting reading,
please allow a side question:
Could it be, that -1 == unlimited is Linux specific?
And therefore not 100% portable ?
And doesn't unlimited number of files call for trouble,
having the risk to starve the machine ?
On Wed, Dec 18, 2013 at 7:18 PM, Tom Miller jacker...@gmail.com wrote:
On Wed, Dec 18, 2013 at 3:47 PM, Junio C Hamano gits...@pobox.com wrote:
Tom Miller jacker...@gmail.com writes:
In order to fix branchname DF conflicts during `fetch --prune`, the way
the header is output to the screen
I wanted to be able to experiment with the TREESAME example given in
the git-log(1) man page, so I built this script which recreates it:
- 8 - 8 - 8 - 8 - 8 -
#!/bin/bash
mkdir git-log-example
cd git-log-example
git init
# I
echo asdf foo; echo
brian m. carlson sand...@crustytoothpaste.net writes:
On Tue, Dec 17, 2013 at 04:36:06PM -0800, Junio C Hamano wrote:
I think all we need to do, in addition to what the existing code
does, is to make sure that we _parse_ the object that the tag points
at, to avoid this problem. Something
On 13-12-19 10:15 AM, Adam Spiers wrote:
Hi all,
If I launch gitk, switch the lower right pane from Patch view mode to
Tree view, expand a few directories, and then changing to viewing a
different commit, the tree automatically collapses again. This is
really annoying when trying to view
Christian Couder christian.cou...@gmail.com writes:
I think this last one might be useful for people replacing objects
with objects that have another type.
... which IIUC is strongly discouraged---didn't you have to tighten
it recently?
And that makes it useful primarily for debugging unusual
On Thu, Dec 19, 2013 at 01:57:43PM -0500, Marc Branchaud wrote:
On 13-12-19 10:15 AM, Adam Spiers wrote:
If I launch gitk, switch the lower right pane from Patch view mode to
Tree view, expand a few directories, and then changing to viewing a
different commit, the tree automatically
On Thu, Dec 19, 2013 at 06:36:45PM +, Adam Spiers wrote:
I wanted to be able to experiment with the TREESAME example given in
the git-log(1) man page, so I built this script which recreates it:
[snipped]
Would it be worth including this in (say) contrib/, and then referring
to it from
Adam Spiers wrote:
Hmm, another related option would be to add a new test case which
tests that git log behaves in the way the man page says it does, in
this case.
Yes, please! If you have a rough patch in that direction, that
would be welcome.
Thanks,
Jonathan
--
To unsubscribe from this
Tom Miller jacker...@gmail.com writes:
But what should happen when we do not give --prune to git fetch in
such a situation? Should it fail, because we still have frotz/nitfol
and we cannot create frotz without losing it?
You talk about this to some extent in an email from 2009. I have
Raphaël Hertzog wrote[1]:
Here's an example of the problematic output:
[...]
# modifié des deux côtés :debian/control
Thanks for the ping, and sorry to leave this hanging before.
[...]
--- a/wt-status.c
+++ b/wt-status.c
@@ -255,7 +255,7 @@ static void
Adam Spiers g...@adamspiers.org writes:
2. What difference does --dense ever make?
It is set by default, and --sparse is its opposite option, i.e. it
turns revs-dense off.
When revs-dense is turned off, the usual treesame logic does not
kick in to rewrite parents in a single strand of pearls
On Thu, Dec 19, 2013 at 11:10:44AM -0800, Jonathan Nieder wrote:
Adam Spiers wrote:
Hmm, another related option would be to add a new test case which
tests that git log behaves in the way the man page says it does, in
this case.
Yes, please! If you have a rough patch in that
Adam Spiers g...@adamspiers.org writes:
Ah OK, that makes sense now, but not the most intuitive choice of name
IMHO. I would have gone for something like --all-commits, but I guess
it's way too late to change now.
Besides, it is not --all-commits, is it? We do cull irrelevant side
branches
Jonathan Nieder jrnie...@gmail.com writes:
This includes the colon in the translated string, to make it easier to
remember to keep the non-breaking space before it.
Hmph, recent 3651e45c (wt-status: take the alignment burden off
translators, 2013-11-05) seems to have gone in the different
On Thu, Dec 19, 2013 at 12:39:05PM -0800, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
Ah OK, that makes sense now, but not the most intuitive choice of name
IMHO. I would have gone for something like --all-commits, but I guess
it's way too late to change now.
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
This includes the colon in the translated string, to make it easier to
remember to keep the non-breaking space before it.
Hmph, recent 3651e45c (wt-status: take the alignment burden off
translators, 2013-11-05) seems to have
On Thu, Dec 19, 2013 at 12:37:53PM -0800, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
On Thu, Dec 19, 2013 at 06:36:45PM +, Adam Spiers wrote:
I wanted to be able to experiment with the TREESAME example given in
the git-log(1) man page, so I built this script which
On Thu, Dec 19, 2013 at 07:03:33PM +, Adam Spiers wrote:
I still don't understand a few things about history simplification:
1. The --full-history without parent rewriting correctly asserts
that commit Q will be shown. But AFAICS this contradicts the
documented behaviour Commits
Hi,
I'm thinking about using Git for web application deployment and thought that I
wouldn't even need to checkout a worktree if I could access the bare git repo
via fuse.
What would be the performance impact? Once the files are in the filesystem
cache
it shouldn't matter anymore, how fast
Git is smart enough to realize when you make a spelling error and
enter a non-existent git command. Since you probably do mean what it
suggests, it follows that the user would want to immediately say “yes,
I did want to do that,” rather than return to the command line to
enter the command again.
If fetch --prune is run with no new refs to fetch, but it has refs
to prune. Then, the header url is not printed as it would if there were
new refs to fetch.
Output before this patch:
$ git fetch --prune remote-with-no-new-refs
x [deleted] (none) - origin/world
When we have a remote-tracking branch named frotz/nitfol from a
previous fetch, and the upstream now has a branch named frotz. Prior
to this patch fetch would fail to remove frotz/nitfol with a git
fetch --prune from the upstream. git would inform the user to use git
remote prune to fix the
Am 18.12.2013 15:53, schrieb Nguyễn Thái Ngọc Duy:
I reimplemented skip_prefix() again just to realize this function
already exists. Which reminds me there are a bunch of places that
could benefit from this function, the same reason that I wanted to
reimplement it.
So this is series to make
On Thu, Dec 19, 2013 at 10:44:22AM -0800, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
Yeah, that's the clean fix I was looking for, but couldn't quite come up
with. I'm going to re-roll with your fix instead of mine and my tests.
Any objections to adding
On Fri, Dec 20, 2013 at 6:32 AM, René Scharfe l@web.de wrote:
Seeing that skip_prefix_defval is mostly used in the form
skip_prefix_defval(foo, prefix, foo) I wonder if it makes sense to
first change skip_prefix to return the full string instead of NULL
if the prefix is not matched. Would
Hi,
Samuel Bronson wrote:
Markus Heidelberg wrote:
In the buildroot project (it consists of Makefiles) there a lots of
those workarounds. There was a patch on the list to replace all
$(strip $(subst ,,$(FOO))) with $(call strip_dquotes, $(FOO)), but
$(call) is not allowed in git for
On Fri, Dec 20, 2013 at 3:50 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
This includes the colon in the translated string, to make it easier to
remember to keep the non-breaking space before it.
Hmph, recent 3651e45c
Am 20.12.2013 00:50, schrieb Duy Nguyen:
On Fri, Dec 20, 2013 at 6:32 AM, René Scharfe l@web.de wrote:
Seeing that skip_prefix_defval is mostly used in the form
skip_prefix_defval(foo, prefix, foo) I wonder if it makes sense to
first change skip_prefix to return the full string instead of
On Fri, Dec 20, 2013 at 8:06 AM, René Scharfe l@web.de wrote:
Am 20.12.2013 00:50, schrieb Duy Nguyen:
On Fri, Dec 20, 2013 at 6:32 AM, René Scharfe l@web.de wrote:
Seeing that skip_prefix_defval is mostly used in the form
skip_prefix_defval(foo, prefix, foo) I wonder if it makes sense
Am 12/18/2013 15:53, schrieb Nguyễn Thái Ngọc Duy:
The code that's not converted to use parse_options() often does
if (!starts_with(arg, foo=)) {
value = atoi(arg + 4);
}
This patch removes those magic numbers with skip_prefix()
Signed-off-by: Nguyễn Thái Ngọc Duy
On Fri, Dec 20, 2013 at 07:51:00AM +0100, Johannes Sixt wrote:
for (i = 1; i argc *argv[i] == '-'; i++) {
const char *arg = argv[i];
+ const char *optarg;
- if (starts_with(arg, --upload-pack=)) {
- args.uploadpack = arg + 14;
42 matches
Mail list logo
