date:20140826

Re: Re: Re: Relative submodule URLs

2014-08-26 Thread Heiko Voigt

On Mon, Aug 25, 2014 at 09:29:07AM -0500, Robert Dailey wrote:
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt hvo...@hvoigt.net wrote:
New --with--remote parameter for 'git submodule'

While having said all that about submodule settings I think a much
much simpler start is to go ahead with a commandline setting, like
Robert proposed here[2].

For that we do not have to worry about how it can be stored,
transported, defined per submodule or on a branch, since answers to this
are given at the commandline (and current repository state).

There are still open questions about this though:

* Should the name in the submodule be 'origin' even though you
specified --with-remote=somewhere? For me its always confusing to
have the same/similar remotes named differently in different
repositories. That why I try to keep the names the same in all my
clones of repositories (i.e. for my private, github, upstream
remotes).

* When you do a 'git submodule sync --with-remote=somewhere' should
the remote be added or replaced.

My opinion on these are:

The remote should be named as in the superproject so
--with-remote=somewhere adds/replaces the remote 'somewhere' in the
submodules named on the commandline (or all in case no submodule is
specified). In case of a fresh clone of the submodule, there would be no
origin but only a remote under the new name.

Would the --with-remote feature I describe be a feasible start for you
Robert? What do others think? Is the naming of the parameter
'--with-remote' alright?

Cheers Heiko

[1] http://article.gmane.org/gmane.comp.version-control.git/255512
[2] http://article.gmane.org/gmane.comp.version-control.git/255512
[3]
https://github.com/jlehmann/git-submod-enhancements/wiki#special-ref-overriding-gitmodules-values

Hi Heiko,

My last email response was in violation of your request to keep the
two topics separate, sorry about that. I started typing it this
weekend and completed the draft this morning, without having read this
response from you first.

Thats fine, no problem.

Here is what I think would make the feature most usable. I think you
went over some of these ideas but I just want to clarify, to make sure
we're on the same page. Please correct me as needed.

1. Running `git submodule update --with-remote name` shall fail the
command unconditionally.

I am not sure but I think you mean

git submodule update --with-remote=name

With the equals sign, without it you would name the submodule paths to
update. No I think that should just add the remote name to all
submodules that would be updated and do the normal update operation on
them (with the new remote of course).

2. Using the `--with-remote` option on submodule `update` or `sync`
will fail if it detects absolute submodule URLs in .gitmodule

Yes, almost. Since you can have a mixture I suggest to only fail if the
submodules that would be processed have an absolute url in them. If
processed submodules are all relative it can go ahead.

3. Running `git submodule update --init --with-remote name` shall
fail the command ONLY if a submodule is being processed that is NOT
also being initialized.

No since the --init flag just tells update to initialize submodules
on-demand. It should just go ahead the same way as without
--with-remote.

4. The behavior of git submodule's `update` or `sync` commands
combined with `--with-remote` will REPLACE or CREATE the 'origin'
remote in each submodule it is run in. We will not allow the user to
configure what the submodule remote name will end up being (I think
this is current behavior and forces good practice; I consider `origin`
an adopted standard for git, and actually wish it was more enforced
for super projects as well!)

No please carefully read my email again. I specifically was describing
the opposite. --with-remote=name creates/replaces the remote name in
the submodule. I do not see a benefit in restricting the user from
creating different remote names in the submodule. I think it would be
more confusing if the remote 'origin' in the superproject does not point
to the same location as 'origin' in the submodule.

Let me know if I've missed anything. Once we clarify requirements I'll
attempt to start work on this during my free time. I'll start by
testing this through msysgit, since I do not have linux installed, but
I have Linux Mint running in a Virtual Machine so I can test on both
platforms as needed (I don't have a lot of experience on Linux
though).

I think it does not matter which development environment you use. In my
experience though Linux is around 30x faster when it comes to the
typical operations you do when developing git. Especially for running
the testsuite that makes a difference between a few hours and minutes.

I hope you won't mind me reaching out for questions as needed, however
I

Bug report: Author/Commit date in ISO 8601 format

2014-08-26 Thread Oliver Busch


Dear git community,

I encountered the following problem: When using the date formatting 
option ISO (either by setting --date=iso or using format:%ci for the 
committer date), the output is formatted like this:


2014-08-25 17:49:43 +0200

But according to ISO 8601, should be formatted like this (see 
http://www.w3.org/TR/NOTE-datetime):


2014-08-25T17:49:43+02:00

This difference makes it impossible to use automated string conversion 
(in my case, I tried to use Delphi's XSBuildIns 
(http://wiert.me/2011/07/19/iso-8601-delphi-way-to-convert-xml-date-and-time-to-tdatetime-and-back-via-stack-overflow/), 
which converted git's output 2014-08-25 17:49:43 +0200 to a TDateTime 
of 2014-08-25 02:00:00; conversion worked correctly when using 
2014-08-25T17:49:43+02:00 as input).


I therefore suggest to adapt the output when using --date=iso or 
format:%ci to comply 100% with the ISO 8601 specs, or at least change 
documentation to say the output is only ISO-like.


Kind regards,

Oliver Busch

--

Oliver Busch, M.Eng.

Airport Research Center GmbH
Bismarckstraße 61
52066 Aachen
Germany

Phone: +49 241 16843-161
Fax: +49 241 16843-19
e-mail: oliver.bu...@arc-aachen.de
Website: http://www.airport-consultants.com

Register Court: Amtsgericht Aachen HRB 7313
Ust-Id-No.: DE196450052

Managing Directors:
Dipl.-Ing. Tom Alexander Heuer

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bisect: save heap memory. allocate only the required amount

2014-08-26 Thread Arjun Sreedharan

On 26 August 2014 02:44, Junio C Hamano gits...@pobox.com wrote:
 Arjun Sreedharan arjun...@gmail.com writes:

 Find and allocate the required amount instead of allocating extra
 100 bytes

 Signed-off-by: Arjun Sreedharan arjun...@gmail.com
 ---

 Interesting.  How much memory do we typically waste (in other words,
 how big did cnt grew in your repository where you noticed this)?


I did not try to make an observation of that. I was thinking we're
anyway better off
not using a magic number to allot memory on the heap for each item in
the commit list.

  bisect.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

 diff --git a/bisect.c b/bisect.c
 index d6e851d..c96aab0 100644
 --- a/bisect.c
 +++ b/bisect.c
 @@ -215,10 +215,13 @@ static struct commit_list 
 *best_bisection_sorted(struct commit_list *list, int n
   }
   qsort(array, cnt, sizeof(*array), compare_commit_dist);
   for (p = list, i = 0; i  cnt; i++) {
 - struct name_decoration *r = xmalloc(sizeof(*r) + 100);
 + char name[100];
 + sprintf(name, dist=%d, array[i].distance);
 + int name_len = strlen(name);

 Decl-after-stmt.

 You do not have to run a separate strlen() for this.  The return
 value from sprintf() should tell you how much you need to allocate,
 I think.


Yes. yes.

 + struct name_decoration *r = xmalloc(sizeof(*r) + name_len);
   struct object *obj = (array[i].commit-object);

 - sprintf(r-name, dist=%d, array[i].distance);
 + memcpy(r-name, name, name_len + 1);
   r-next = add_decoration(name_decoration, obj, r);
   p-item = array[i].commit;
   p = p-next;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Improving the git remote command

2014-08-26 Thread Rémy Hubscher

Hi,

I'd like to add a list parameter to the `git remote` command.

We already have:
 
 - `git remote add`
 - `git remote rename`
 - `git remote delete`

I often write `git remote list` before finaly using `git remote -v` but
it isn't intuitive.

I am proposing to add `git remote list` as a shortcut for `git remote -v`

What do you think?

Rémy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Improving the git remote command

2014-08-26 Thread Philippe Vaucher

 I often write `git remote list` before finaly using `git remote -v` but
 it isn't intuitive.

 I am proposing to add `git remote list` as a shortcut for `git remote -v`

I suffer from the same problem. I think your proposal is a logical and
nice idea.

Philippe
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

1 2 >

1 - 100 of 102 matches

Mail list logo