Ramkumar Ramachandra wrote:
> After some discussion, I hope to be able to finalize a list of fields
> that will suffice for (nearly) everything.
The task is actually much easier than this. All we have to do is
finalize the list of fields that will mandatorily be written to the
link object. As I
Jed Brown wrote:
Felipe Contreras writes:
On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown wrote:
...
We have
to assume that every Git (remote-hg) User is dealing with Hg Team
No, we don't.
Really? If there is no Hg Team, why bother with an Hg upstream?
Huh? the counterpart of "every user"
On Thu, Apr 04, 2013 at 10:43:14PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I notice that you are stuck factoring out not just the setup, but also
> > the cleanup, and I wondered if things could be made even simpler by just
> > encapsulating the checking logic in a callback; then t
On Thu, Apr 04, 2013 at 10:34:49PM -0700, Junio C Hamano wrote:
> > +static void get_head(char *arg)
> > +{
> > + struct strbuf buf = STRBUF_INIT;
> > + head_ref_namespaced(show_text_ref, &buf);
> > + send_strbuf("text/plain", &buf);
> > + strbuf_release(&buf);
> > +}
>
> You identified t
Jeff King writes:
> I notice that you are stuck factoring out not just the setup, but also
> the cleanup, and I wondered if things could be made even simpler by just
> encapsulating the checking logic in a callback; then the setup and
> cleanup flow more naturally, as they are in a single functio
Jeff King writes:
> Yeah, that makes sense. I think we'd want something like the (totally
> untested) patch below. And the tests I provided for t5551 should be
> amended to set up a HEAD within the namespace, should make the resulting
> clone non-bare, and should confirm that we check out the cor
On Thu, Apr 04, 2013 at 09:45:26PM -0700, Junio C Hamano wrote:
> The logic to decide early to do nothing and prepare the data to be
> inspected are the same between has_changes() and diff_grep().
> Introduce pickaxe_setup() helper to share the same code.
>
> Similarly, introduce pickaxe_finish_f
On Fri, Apr 5, 2013 at 3:53 PM, Junio C Hamano wrote:
>> A brief summary or outcome from these links in the comment would
>> be nice.
>
> A summary of what to consider in Documentation/technical/ somewhere
> may be a very welcome addition. Thanks for volunteering ;-).
No thanks :-) I did not rea
On Thu, Apr 04, 2013 at 09:59:49PM -0700, Junio C Hamano wrote:
> > That means the worst case is not the accidental loss of content,
> > but rather confusion by the user when a copy of a file another
> > part of the tree is removed.
>
> A copy of a file that is on the filesystem that may not be r
Jeff King writes:
> Here's a replacement for patch 3, then. I wasn't sure if the
> editorializing in the last 2 paragraphs should go in the commit message
> or the cover letter; feel free to tweak as you see fit.
They look fine as they are.
> That means the worst case is not the accidental loss
Duy Nguyen writes:
> Should someone add these links to the source code (maybe as a comment
> in submodule.c, or above the definition of S_IFGITLINK in cache.h)?
They were given in response to a request for reading material to
learn background. Most of the straw-man outlines raised in these old
d
The diff_grep() and has_changes() functions had early return
codepaths for unmerged filepairs, which simply returned 0. When we
taught textconv filter to them, one was ignored and continued to
return early without freeing the result filtered by textconv, and
the other had a failed attempt to fix,
The logic to decide early to do nothing and prepare the data to be
inspected are the same between has_changes() and diff_grep().
Introduce pickaxe_setup() helper to share the same code.
Similarly, introduce pickaxe_finish_filepair() to clean up after
these two functions are done with a filepair.
These two functions are called in the same codeflow to implement
"log -S" and "log -G", respectively, but the latter
lacked two obvious optimizations the former implemented, namely:
- When a pickaxe limit is not given at all, they should return
without wasting any cycle;
- When both sides of
Jeff King writes:
> Thanks. The whole series looks good to me. I think Junio's proposed
> cleanup is a good direction, too, but I don't mind if that comes on top.
I'll send out a three-patch follow-up shortly.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mes
On Thu, Apr 04, 2013 at 07:35:16PM -0700, Josh Triplett wrote:
> > Including the HEAD ref in the advertisement from /info/refs ends up
> > duplicating it, since the dumb client unconditionally fetches the file
> > /HEAD to use as the that ref. I think the right thing to do is
> > generate the corr
On Thu, Apr 4, 2013 at 5:40 PM, Junio C Hamano wrote:
>> Not on the current design but the discussion before that round that
>> influenced the outcome greatly was this:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/14486/focus=14492
>>
>> where we discussed a separate "gitlink" ty
On Thu, Apr 04, 2013 at 06:22:08PM -0700, John Koleszar wrote:
> On Thu, Apr 4, 2013 at 10:25 AM, Junio C Hamano wrote:
> > John Koleszar writes:
> >
> >> @@ -402,7 +404,8 @@ static void get_info_refs(char *arg)
> >>
> >> } else {
> >> select_getanyfile();
> >> - f
On Tue, Apr 2, 2013 at 5:26 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This is not simply convenient over %C(auto,xxx). Some placeholders
>> (actually only one, %d) do multi coloring and we can't emit a multiple
>> colors with %C(auto,xxx).
>>
>> Signed-off-by: Nguyễn Thái Ngọ
On Tue, Apr 2, 2013 at 1:53 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> index-pack --strict looks up and follows parent commits. If shallow
>> information is not ready by the time index-pack is run, index-pack may
>> be lead to non-existent objects. Make fetch-pack save shallow
On Sat, Mar 30, 2013 at 8:45 PM, Jan Larres wrote:
> I would expect the last command to also report 'set'. I've also tried
> other patterns like 'foo/' and 'foo*', but it didn't make any
> difference.
Try "foo/**". You need 1.8.2 though.
--
Duy
--
To unsubscribe from this list: send the line "uns
On Thu, Apr 4, 2013 at 10:25 AM, Junio C Hamano wrote:
> John Koleszar writes:
>
>> @@ -402,7 +404,8 @@ static void get_info_refs(char *arg)
>>
>> } else {
>> select_getanyfile();
>> - for_each_ref(show_text_ref, &buf);
>> + head_ref_namespaced(show_tex
On Thu, Apr 04, 2013 at 10:21:08PM +0200, Simon Ruderich wrote:
> From: Jeff King
>
> fill_one is _almost_ identical to just calling fill_textconv; the
> exception is that for the !DIFF_FILE_VALID case, fill_textconv gives us
> an empty buffer rather than a NULL one.
>
> Signed-off-by: Simon Ru
On Thu, Apr 04, 2013 at 04:33:39PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So let's drop patch 3. Do we want instead to have an expect_failure
> > documenting the correct behavior?
>
> I think that is very much preferred.
Here's a replacement for patch 3, then. I wasn't sure if
Jeff King writes:
> So let's drop patch 3. Do we want instead to have an expect_failure
> documenting the correct behavior?
I think that is very much preferred.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Thu, Apr 04, 2013 at 04:12:01PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Deleting across symlinks inside the repo can be brushed aside with "eh,
> > well, it is just another way to mention the same name in the
> > filesystem". But deleting anything outside of the repo seems acti
Junio C Hamano wrote:
> "git log -p .gitmodules" would be a way to review what changed in
> the information about submodules. Don't you need "git log-link" for
> exactly the same reason why you need "git diff-link" in the first
> place?
>
> So you may not have suggested it, but I suspect that was
Jeff King writes:
> Deleting across symlinks inside the repo can be brushed aside with "eh,
> well, it is just another way to mention the same name in the
> filesystem". But deleting anything outside of the repo seems actively
> wrong.
Yup, you finally caught up ;-) IIRC, such an outside reposit
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Sounds like you are saying that you can pile a new command on top of
>> new command to solve what the existing tools people are familar with
>> can already solve in a consistent way without adding anything new.
>> Are you going to dupliate v
On Thu, Apr 4, 2013 at 4:27 PM, Jed Brown wrote:
> Felipe Contreras writes:
>
>> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown wrote:
>>>
>>> Then perhaps we have different goals [1]. I don't know any Git User that
>>> would prefer to have an Hg upstream accessed through remote-hg.
>>
>> Who cares?
Jeff King writes:
> But I do not think fill_one is the right interface for it. The reason
> has_changes calls get_textconv separately is that we do not want to fill
> the buffer (which may be expensive) if we can avoid it. So the correct
> sequence is: ...
> If you turned fill_one into "fill_both
Junio C Hamano wrote:
> Sounds like you are saying that you can pile a new command on top of
> new command to solve what the existing tools people are familar with
> can already solve in a consistent way without adding anything new.
> Are you going to dupliate various options to "git diff" and "git
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> When you are changing information _about_ submodules (e.g. you may
>> be updating the recommended URL to fetch it from), you can use the
>> usual tools like "git diff" to see how it changed, just like changes
>> to any other file. If the in
Felipe Contreras writes:
> On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown wrote:
>>
>> Then perhaps we have different goals [1]. I don't know any Git User that
>> would prefer to have an Hg upstream accessed through remote-hg.
>
> Who cares? If you don't know somebody, does that mean such person
> d
Thiago Farina writes:
> When I want to revert a change to a file that is already committed
> what is the best way?
>
> The way I found was:
>
> $ git checkout HEAD /path/to/my/file
> $ git reset HEAD /path/to/my/file
>
> Is this the canonical/best way or there other (easier-faster) ways?
If the
Junio C Hamano wrote:
> When you are changing information _about_ submodules (e.g. you may
> be updating the recommended URL to fetch it from), you can use the
> usual tools like "git diff" to see how it changed, just like changes
> to any other file. If the information _about_ a submodule A is
>
Jens Lehmann writes:
> While starting to grok submodules I was wondering myself if the data
> stored in .gitmodules would better be stored in an extended gitlink
> object, but I learned soon that the scope of the data that has to be
> stored there was not clear at that time (and still isn't). So
On Thu, 4 Apr 2013, Junio C Hamano wrote:
I do not want to write an awk/sed script to remove all the submodules
from .git/config ...
Don't do it then ;-)
I think "git config" was added exactly because people wanted to
customize their configuration from their scripts.
OK, I didn't know about
Hi,
When I want to revert a change to a file that is already committed
what is the best way?
The way I found was:
$ git checkout HEAD /path/to/my/file
$ git reset HEAD /path/to/my/file
Is this the canonical/best way or there other (easier-faster) ways?
Thanks,
--
To unsubscribe from this list:
Jens Lehmann wrote:
> Exactly. The flexibility of the .gitmodules file will really help us
> when it comes to the next feature that submodules are going to learn
> after recursive update:
That's like saying that the flexibility of a blob is invaluable: let's
throw out all the other objects, and ma
On Thu, Apr 4, 2013 at 2:48 PM, Jed Brown wrote:
> Felipe Contreras writes:
>
>
> [...]
>
>>> will need to play by those rules.
>>
>> No, we don't. The fact that you say so doesn't make it so.
>
> Then perhaps we have different goals [1]. I don't know any Git User that
> would prefer to have an
Am 04.04.2013 21:04, schrieb Linus Torvalds:
> My gut feel is that yes, .gitmodules was always a bit of a hack, but
> it's a *working* hack, and it does have advantages exactly because
> it's more fluid than an actual git object (which by definition has to
> be set 100% in stone).
Exactly. The fle
Jeff King writes:
> On Thu, Apr 04, 2013 at 10:49:44PM +0200, Uwe Kleine-König wrote:
>
>> On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote:
>> > [...]
>> > So I do think zdiff3 is useful, and I plan to continue using it.
>> Thanks for your description. I'm using and liking zdiff3, too.
Thomas Rast wrote:
> As pointed out by Eric Wong (thanks), the initial close needs to go:
> die() would again write nowhere if we close STDERR beforehand.
>
> Signed-off-by: Thomas Rast
Acked-by: Eric Wong
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
Thomas Rast wrote:
> --- a/t/t9700/test.pl
> +++ b/t/t9700/test.pl
> @@ -45,7 +45,8 @@ is($r->get_color("color.test.slot1", "red"), $ansi_green,
> "get_color");
> # Failure cases for config:
> # Save and restore STDERR; we will probably extract this into a
> # "dies_ok" method and possibly mov
On Thu, Apr 04, 2013 at 01:48:52PM -0700, Junio C Hamano wrote:
> If I am reading the code correctly, it is has_changes(), which is
> used for "log -S" (not "log -G" that uses diff_grep()), that does
> the unnecessary get_textconv() unconditionally. The way diff_grep()
> divides the work to make
Junio C Hamano writes:
> Perhaps...
>
> The fill_one() function is responsible for finding and
> filling the textconv filter as necessary, and is called by
> diff_grep() function that implements "git log -G".
>
> The has_changes() function calls get_textconv() for two
>
Chris Wilson writes:
> I do not want to write an
> awk/sed script to remove all the submodules from .git/config ...
Don't do it then ;-)
I think "git config" was added exactly because people wanted to
customize their configuration from their scripts.
> I do, it seems bizarre that git submodul
On Thu, Apr 04, 2013 at 01:31:43PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> If you do this:
> >>
> >>rm -fr d e
> >> mkdir e
> >> >e/f
> >> ln -s e d
> >> git add d/f
> >>
> >> we do complain that d/f is beyond a symlink (meaning that all you
On Thu, Apr 04, 2013 at 10:49:44PM +0200, Uwe Kleine-König wrote:
> On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote:
> > [...]
> > So I do think zdiff3 is useful, and I plan to continue using it.
> Thanks for your description. I'm using and liking zdiff3, too. So I'd
> really like seeing
Hi Jeff,
On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote:
> [...]
> So I do think zdiff3 is useful, and I plan to continue using it.
Thanks for your description. I'm using and liking zdiff3, too. So I'd
really like seeing it in vanilla git.
Thanks
Uwe
--
Pengutronix e.K.
Simon Ruderich writes:
> get_textconv() is called in diff_grep() to determine the textconv driver
> before calling fill_one() and then again in fill_one(). Remove this
> unnecessary call by determining the textconv driver before calling
> fill_one().
If I am reading the code correctly, it is has
Felipe Contreras writes:
[...]
>> will need to play by those rules.
>
> No, we don't. The fact that you say so doesn't make it so.
Then perhaps we have different goals [1]. I don't know any Git User that
would prefer to have an Hg upstream accessed through remote-hg. We have
to assume that e
Much like the previous patch, this triggered an unrelated bug.
Closing STDERR is not worth it anyway, as we risk writing die() and
such to random files that happen to be subsequently opened on FD 2.
Don't do it.
Signed-off-by: Thomas Rast
---
t/t9700/test.pl | 3 ++-
1 file changed, 2 insertions
On my system, t9100.1 triggers the following warning:
==352== Syscall param write(buf) points to uninitialised byte(s)
==352==at 0x57119C0: __write_nocancel (in /lib64/libc-2.17.so)
==352==by 0x56AC1D2: _IO_file_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352==by 0x56AC0B1: n
Hi Junio,
On Thu, 4 Apr 2013, Junio C Hamano wrote:
This state is broken (wrong URLs in .git/config), and AFAIK there's
nothing you can do to check out these submodules without either:
(a) manually hacking them out of .git/config, or
I do not think updating the config is "hacking", but is a
On Thu, Apr 4, 2013 at 2:14 PM, Jed Brown wrote:
> Felipe Contreras writes:
>
>> If that's the case, they should disable in the server, just like some
>> people disable non-fast-forward pushes in git.
>
> I don't know how to make Hg allow new branches and bookmarks, but not
> new anonymous heads.
On Thu, Mar 07, 2013 at 01:50:46PM -0500, Jeff King wrote:
> On Thu, Mar 07, 2013 at 10:40:46AM -0800, Junio C Hamano wrote:
>
> > Where we differ is if such information loss is a good thing to have.
> >
> > We could say "both sides added, identically" is auto-resolved when
> > you use the zealou
Jeff King writes:
>> If you do this:
>>
>> rm -fr d e
>> mkdir e
>> >e/f
>> ln -s e d
>> git add d/f
>>
>> we do complain that d/f is beyond a symlink (meaning that all you
>> can add is the symlink d that may happen to point at something).
>
> Right, but th
Am 04.04.2013 21:17, schrieb Junio C Hamano:
> Linus Torvalds writes:
>
>> ... The features you seem to be after (ie that whole
>> floating/refname thing) don't seem fundamentally antithetical to the
>> current model (a "commit" SHA1 of all zeroes for floating, with a new
>> refname field in .sub
git log -S doesn't respect --no-textconv:
$ echo '*.txt diff=wrong' > .gitattributes
$ git -c diff.wrong.textconv='xxx' log --no-textconv -Sfoo
error: cannot run xxx: No such file or directory
fatal: unable to read files to diff
Reported-by: Matthieu Moy
Signed-off-by: Simon Rude
From: Jeff King
fill_one is _almost_ identical to just calling fill_textconv; the
exception is that for the !DIFF_FILE_VALID case, fill_textconv gives us
an empty buffer rather than a NULL one.
Signed-off-by: Simon Ruderich
---
On Thu, Apr 04, 2013 at 01:49:42PM -0400, Jeff King wrote:
> [snip]
get_textconv() is called in diff_grep() to determine the textconv driver
before calling fill_one() and then again in fill_one(). Remove this
unnecessary call by determining the textconv driver before calling
fill_one().
With this change it's also no longer necessary for fill_one() to
modify the te
Felipe Contreras writes:
> If that's the case, they should disable in the server, just like some
> people disable non-fast-forward pushes in git.
I don't know how to make Hg allow new branches and bookmarks, but not
new anonymous heads. Vanishly few Hg projects use a workflow anything
like topi
Ramkumar Ramachandra wrote:
> Just take the link's buffer with you everywhere. All you have to do
> is git edit-link and paste the file's contents there, instead
> of opening .gitmodules directly in your editor.
On this. The buffer doesn't have to conform to a tight spec: we can
just expose a .
Linus Torvalds wrote:
> Or you could also just edit and carry a dirty .gitmodules around for
> your personal use-case.
I'm sorry, but a dirty worktree is unnecessarily painful to work with.
I don't think anyone objects to committing, if they can understand
basic rebase.
--
To unsubscribe from thi
Junio C Hamano wrote:
> I think Heiko and Jens's (by the way, why aren't they on the Cc:
> list when this topic is clearly discussing submodules? Don't we
> want to learn how the current submodule subsystem is used to solve
> what real-world problems?) .gitmodules updates is exactly going in
> tha
Am 04.04.2013 19:10, schrieb Chris Wilson:
> If your git repo's .gitmodules contains a URL that you don't have access to
> (for example you download someone else's code and it references a submodule
> using their writable g...@github.com URL) then:
>
> * git submodule init will add them to .git/
On Thu, Apr 04, 2013 at 12:42:54PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +test_expect_success SYMLINKS 'replace dir with symlink to dir (same
> > content)' '
> > + git reset --hard &&
> > + rm -rf d e &&
> > + mkdir e &&
> > + echo content >e/f &&
> > + ln -s e d &&
>
Linus Torvalds wrote:
> On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra
> wrote:
>>
>> Let's compare the two alternatives: .gitmodules versus link object.
>> If I want my fork of .gitmodules, I create a commit on top.
>
> Or you could also just edit and carry a dirty .gitmodules around for
>
On Thu, Apr 4, 2013 at 1:23 PM, Jed Brown wrote:
> Junio C Hamano writes:
>
>> So,... is there a concrete proposal for _me_ to act on? Do you want
>> to see contrib/remtote-hg out of my tree, and have it compete with
>> the other one (which also shouldn't be in my tree) in the open?
>
> Three mo
On Thu, Apr 4, 2013 at 12:36 PM, Ramkumar Ramachandra
wrote:
>
> Let's compare the two alternatives: .gitmodules versus link object.
> If I want my fork of .gitmodules, I create a commit on top.
Or you could also just edit and carry a dirty .gitmodules around for
your personal use-case.
I don't
Jeff King writes:
> +test_expect_success SYMLINKS 'replace dir with symlink to dir (same
> content)' '
> + git reset --hard &&
> + rm -rf d e &&
> + mkdir e &&
> + echo content >e/f &&
> + ln -s e d &&
> + git rm d/f &&
> + test_must_fail git rev-parse --verify :d/f &
Linus Torvalds wrote:
> don't seem fundamentally antithetical to the
> current model
I don't think it's fundamentally antithetical either. This basically
makes the life of git-submodule much simpler, and eventually obsolete
it away completely.
--
To unsubscribe from this list: send the line
Linus Torvalds wrote:
> So the thing is (and this was pretty much the original basis for
> .gitmodules) that pretty much *all* of the above fields are quite
> possibly site-specific, rather than globally stable.
>
> So I actually conceptually like (and liked) the notion of a link
> object, but I j
Junio C Hamano writes:
> So,... is there a concrete proposal for _me_ to act on? Do you want
> to see contrib/remtote-hg out of my tree, and have it compete with
> the other one (which also shouldn't be in my tree) in the open?
Three months ago, I would have said yes. Now I don't know. It loo
Linus Torvalds writes:
> ... The features you seem to be after (ie that whole
> floating/refname thing) don't seem fundamentally antithetical to the
> current model (a "commit" SHA1 of all zeroes for floating, with a new
> refname field in .submodules? I dunno)..
Just on this part.
I think Heik
On Thu, Apr 4, 2013 at 12:17 PM, Jed Brown wrote:
> Felipe Contreras writes:
>> Ideally we shouldn't do this, as it's not recommended in mercurial
>> documentation, but there's no other way to push multiple bookmarks (on
>> the same branch), which would be the behavior most similar to git.
>
> Th
Felipe Contreras writes:
> On Thu, Apr 4, 2013 at 10:44 AM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Ideally we shouldn't do this, as it's not recommended in mercurial
>>> documentation, but there's no other way to push multiple bookmarks (on
>>> the same branch), which would be
If we have a path "d/f" but replace "d" with a symlink to a
new directory "e", how should we handle "git rm d/f"?
It may seem at first like we need new protections to make
sure that we do not delete random content from "e/f".
However, we are already covered by git-rm's existing
protections: it is
On Thu, Apr 4, 2013 at 11:52 AM, Ramkumar Ramachandra
wrote:
>
> 1. upstream_url: this records the upstream URL. No need to keep a
> .gitmodules.
>
> 2. checkout_rev: this records the ref to check out the submodule to.
> As opposed to a concrete SHA-1, this allows for more flexibility; you
> can
The previous commit taught "rm" that it is safe to consider
"d/f" removed when "d" has become a non-directory. This
patch adds a test for the opposite: a file "d" that becomes
a directory.
In this case, "git rm" does need to complain, because we
should not be removing arbitrary content under "d".
If we used to have an index entry "d/f", but "d" has been
replaced by a non-directory entry, the user may still want
to run "git rm" to delete the stale index entry. They could
use "git rm --cached" to just touch the index, but "git rm"
should also work: we explicitly try to handle the case that
th
On Wed, Apr 03, 2013 at 10:35:52AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Of the two situations, I think the first one is less likely to be
> > destructive (noticing that a file is already gone via ENOTDIR), as we
> > are only proceeding with the index deletion, and we end up not
Felipe Contreras writes:
> Where is the evidence? You say remote-hg doesn't work, I say it does,
> the difference is that I have evidence to prove it.
There are many projects that don't do what they claim. I gave remote-hg
a few minutes and moved on since (at the time) it didn't seem
interestin
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>> The purpose of this series is to convince you that we've made a lot of
>> fundamental mistakes while designing submodules, and
[...]
> Shouldn't it be possible to explain the same thing using a test
> script illustrating intended UI?
Sorry,
On Thu, Apr 4, 2013 at 10:44 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Ideally we shouldn't do this, as it's not recommended in mercurial
>> documentation, but there's no other way to push multiple bookmarks (on
>> the same branch), which would be the behavior most similar to git.
Ramkumar Ramachandra wrote:
> 1. 'git add' should not go past submodule boundaries. I should not be
>able to 'git add clayoven/' or 'git add clayoven/LICENSE'. In
>addition, the shell completion also needs to be fixed.
Yep. This is a bug.
> 2. An empty directory containing a .git file
Linus Torvalds wrote:
> I don't dispute that a new link object might be a good idea, but
> there's no explanation of the actual format of this thing anywhere,
> and what the real advantages would be. A clearer "this is the design,
> this is the format of the link object, and this is what it buys us
Ramkumar Ramachandra wrote:
> The purpose of this series is to convince you that we've made a lot of
> fundamental mistakes while designing submodules, and that we should
> fix them now. [1/7] argues for a new object type, and this is the
> core of the idea.
Oh, dear.
Shouldn't it be possible t
The loop that fills in the buffers that are later passed to the merge
driver exits early when not all stages of a path are present in the index.
But since the buffer pointers are not initialized in advance, the
subsequent accesses are undefined.
Initialize buffer pointers in advance to avoid undef
On Thu, Apr 4, 2013 at 12:11 PM, Jed Brown wrote:
> Felipe Contreras writes:
>
>> I still don't see any good reason why a user might prefer gitifyhg,
>> even more importantly, why gitifyhg developers don't contribute to
>> remote-hg.
>
> Felipe, I read your blog announcement [1] and got the impre
On Thu, Apr 4, 2013 at 11:30 AM, Ramkumar Ramachandra
wrote:
>
> The purpose of this series is to convince you that we've made a lot of
> fundamental mistakes while designing submodules, and that we should
> fix them now. [1/7] argues for a new object type, and this is the
> core of the idea.
I
Jed Brown writes:
> ... I felt that it was wildly oversold and that putting it into
> git.git was premature.
>
> I tried gitifyhg later and it basically worked out of the box. All
> known problems were marked by 'xfail' test cases. At that time,
> remote-hg failed almost all the gitifyhg tests
Chris Wilson writes:
> If your git repo's .gitmodules contains a URL that you don't have
> access to (for example you download someone else's code and it
> references a submodule using their writable g...@github.com URL) then:
>
> * git submodule init will add them to .git/config, with the wrong
Great. Now, we just have to write refs/modules//* at
commit-time.
Signed-off-by: Ramkumar Ramachandra
---
sha1_file.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/sha1_file.c b/sha1_file.c
index a8a6d72..2ea101a 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2874,6 +2874,7 @@
This is a WIP.
Signed-off-by: Ramkumar Ramachandra
---
git-edit-link.sh | 87
1 file changed, 87 insertions(+)
create mode 100644 git-edit-link.sh
diff --git a/git-edit-link.sh b/git-edit-link.sh
new file mode 100644
index 000..3ff0e
This configuration variable comes into effect when 'git clone' is
invoked in an existing git repository. Instead of cloning the
repository as-is, it relocates the gitdir of the repository to the
path specified by this variable. Arguably, it does the right thing
when working with submodules.
Sign
This simply requires parsing out the checkout_rev from the link
object, and comparing its SHA-1 with that of HEAD.
Signed-off-by: Ramkumar Ramachandra
---
read-cache.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/read-cache.c b/read-cach
'git show' now works with link objects.
Signed-off-by: Ramkumar Ramachandra
---
builtin/log.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index 0f31810..a170df9 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -411,6 +411,20 @@ static int
1 - 100 of 159 matches
Mail list logo
