Re: [PATCH] fetch: Print full url in header
On Thu, Jan 09, 2014 at 12:07:38PM -0800, Junio C Hamano wrote:
>
> Having said all that, the difference between the full URL shown by
> "remote --verbose" (which is used to interact with the remote in
> this repository) and the abbreviated URL (which is shown by "fetch"
> and is designed to be sharable with others with a simple cut&paste)
> matters only when there are a pair of ambiguously configured
> repositories (e.g. there are two repositories "git://host/a.git/"
> and "git://host/a/.git") that serve different things and you are
> debugging the situation. And to me, "remote --verbose" looks more
> or less a debugging aid, nothing more. So another alternative that
> may be to leave everything as-is.
>
> Thanks.
I like the alterantive option of "leave everything as-is", especially
after the arguments you've presented. There is still the problem of the
logic that has been duplicated. I think it should be put in a function,
but if you are ok with leaving it duplicated that is fine by me.
if (raw_url)
url = transport_anonymize_url(raw_url);
else
url = xstrdup("foreign");
url_len = strlen(url);
for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)
;
url_len = i + 1;
if (4 < i && !strncmp(".git", url + i - 3, 4))
url_len = i - 3;
Thanks,
Tom Miller
--
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 0/6] Make 'git help everyday' work
I think we already use a nicer way to set up a page alias to keep old links working than making a copy in Documentation/; please mimic that if possible. It may be overdue to refresh the suggested set of "top 20" commands, as things have vastly changed over the past 8 years. Perhaps we should do that after reorganizing with something like this series. -- 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
[PATCH 5/6] add 'everyday' to the help --guides list
Signed-off-by: Philip Oakley
---
builtin/help.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/help.c b/builtin/help.c
index cc17e67..45509ce 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -418,6 +418,7 @@ static struct {
const char *help;
} common_guides[] = {
{ "attributes", N_("Defining attributes per path") },
+ { "everyday", N_("Everyday Git With 20 Commands Or So") },
{ "glossary", N_("A Git glossary") },
{ "ignore", N_("Specifies intentionally untracked files to ignore") },
{ "modules", N_("Defining submodule properties") },
--
1.8.3.msysgit.0
--
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
[PATCH 0/6] Make 'git help everyday' work
The "Everyday GIT With 20 Commands Or So" guide is not accessible via the git help system. Fix that. The git everyday file does not use the appropriate filenaming convention for help files, and is not suitably formatted for display as a man page. First copy everyday.txt to giteveryday.txt Second modify giteveryday to fit man page formatting. Include the standard Git footer. Third add giteveryday to the manpages make list. Fourth add deprecation note to older everday.txt. Include link to new man page. Fifth add 'everyday' to the help --guides list. Finally, update the git(1) link. The series could be squashed together once any foible have been eliminated. Philip Oakley (6): copy everyday.txt to giteveryday.txt Update giteveryday.txt to fit man page formatting add giteveryday to the manpages make list Add deprecation note to old everyday.txt add 'everyday' to the help --guides list Update git(1) link to giteveryday Documentation/Makefile| 1 + Documentation/everyday.txt| 4 + Documentation/git.txt | 2 +- Documentation/giteveryday.txt | 428 ++ builtin/help.c| 1 + 5 files changed, 435 insertions(+), 1 deletion(-) create mode 100644 Documentation/giteveryday.txt -- 1.8.3.msysgit.0 -- 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
[PATCH 6/6] Update git(1) link to giteveryday
Signed-off-by: Philip Oakley --- Documentation/git.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index aec3726..0e4875d 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,7 +22,7 @@ unusually rich command set that provides both high-level operations and full access to internals. See linkgit:gittutorial[7] to get started, then see -link:everyday.html[Everyday Git] for a useful minimum set of +linkgit:giteveryday[7] for a useful minimum set of commands. The link:user-manual.html[Git User's Manual] has a more in-depth introduction. -- 1.8.3.msysgit.0 -- 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
[PATCH 2/6] Update giteveryday.txt to fit man page formatting
Add standard man page section titles. Also adjust anchor text markup for man page format. Signed-off-by: Philip Oakley --- Documentation/giteveryday.txt | 39 +++ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt index 2a18c1f..2939458 100644 --- a/Documentation/giteveryday.txt +++ b/Documentation/giteveryday.txt @@ -1,22 +1,33 @@ +giteveryday(7) +=== + +NAME + +giteveryday - A useful minimum set of commands for Everyday Git + +SYNOPSIS + + Everyday Git With 20 Commands Or So -=== -<> commands are essential for +DESCRIPTION +--- +<> commands are essential for anybody who makes a commit, even for somebody who works alone. If you work with other people, you will need commands listed in -the <> section as well. +the <> section as well. -People who play the <> role need to learn some more +People who play the <> role need to learn some more commands in addition to the above. -<> commands are for system +<> commands are for system administrators who are responsible for the care and feeding of Git repositories. -Individual Developer (Standalone)[[Individual Developer (Standalone)]] --- +Individual Developer (Standalone)[[STANDALONE]] +--- A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the @@ -104,8 +115,8 @@ combined and include `--max-count=10` (show 10 commits), directory, since `v2.43` tag. -Individual Developer (Participant)[[Individual Developer (Participant)]] - +Individual Developer (Participant)[[PARTICIPANT]] +- A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in @@ -205,7 +216,7 @@ tag. without a formal "merging". -Integrator[[Integrator]] +Integrator[[INTEGRATOR]] A fairly central person acting as the integrator in a group @@ -292,8 +303,8 @@ everything `ko-next` has. <13> push the tag out, too. -Repository Administration[[Repository Administration]] --- +Repository Administration[[ADMINISTRATION]] +--- A repository administrator uses the following tools to set up and maintain access to the repository by developers. @@ -411,3 +422,7 @@ ftp> cp -r .git /home/user/myproject.git + <1> make sure your info/refs and objects/info/packs are up-to-date <2> upload to public HTTP server hosted by your ISP. + +GIT +--- +Part of the linkgit:git[1] suite \ No newline at end of file -- 1.8.3.msysgit.0 -- 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
[PATCH 3/6] add giteveryday to the manpages make list
Signed-off-by: Philip Oakley --- Documentation/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/Makefile b/Documentation/Makefile index 91a12c7..7b745d0 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -23,6 +23,7 @@ MAN7_TXT += gitcore-tutorial.txt MAN7_TXT += gitcredentials.txt MAN7_TXT += gitcvs-migration.txt MAN7_TXT += gitdiffcore.txt +MAN7_TXT += giteveryday.txt MAN7_TXT += gitglossary.txt MAN7_TXT += gitnamespaces.txt MAN7_TXT += gitrevisions.txt -- 1.8.3.msysgit.0 -- 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
[PATCH 4/6] Add deprecation note to old everyday.txt
Also include link to new man page. Signed-off-by: Philip Oakley --- Documentation/everyday.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 2a18c1f..9de6347 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -1,6 +1,10 @@ Everyday Git With 20 Commands Or So === +Note, the Everyday Git guidance is now available via `git help everyday` +linkgit:giteveryday[7]. +This version is deprecated and may be removed in later releases. + <> commands are essential for anybody who makes a commit, even for somebody who works alone. -- 1.8.3.msysgit.0 -- 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
[PATCH 1/6] copy everyday.txt to giteveryday.txt
Signed-off-by: Philip Oakley --- Documentation/giteveryday.txt | 413 ++ 1 file changed, 413 insertions(+) create mode 100644 Documentation/giteveryday.txt diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt new file mode 100644 index 000..2a18c1f --- /dev/null +++ b/Documentation/giteveryday.txt @@ -0,0 +1,413 @@ +Everyday Git With 20 Commands Or So +=== + +<> commands are essential for +anybody who makes a commit, even for somebody who works alone. + +If you work with other people, you will need commands listed in +the <> section as well. + +People who play the <> role need to learn some more +commands in addition to the above. + +<> commands are for system +administrators who are responsible for the care and feeding +of Git repositories. + + +Individual Developer (Standalone)[[Individual Developer (Standalone)]] +-- + +A standalone individual developer does not exchange patches with +other people, and works alone in a single repository, using the +following commands. + + * linkgit:git-init[1] to create a new repository. + + * linkgit:git-show-branch[1] to see where you are. + + * linkgit:git-log[1] to see what happened. + + * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch +branches. + + * linkgit:git-add[1] to manage the index file. + + * linkgit:git-diff[1] and linkgit:git-status[1] to see what +you are in the middle of doing. + + * linkgit:git-commit[1] to advance the current branch. + + * linkgit:git-reset[1] and linkgit:git-checkout[1] (with +pathname parameters) to undo changes. + + * linkgit:git-merge[1] to merge between local branches. + + * linkgit:git-rebase[1] to maintain topic branches. + + * linkgit:git-tag[1] to mark known point. + +Examples + + +Use a tarball as a starting point for a new repository.:: ++ + +$ tar zxf frotz.tar.gz +$ cd frotz +$ git init +$ git add . <1> +$ git commit -m "import of frotz source tree." +$ git tag v2.43 <2> + ++ +<1> add everything under the current directory. +<2> make a lightweight, unannotated tag. + +Create a topic branch and develop.:: ++ + +$ git checkout -b alsa-audio <1> +$ edit/compile/test +$ git checkout -- curses/ux_audio_oss.c <2> +$ git add curses/ux_audio_alsa.c <3> +$ edit/compile/test +$ git diff HEAD <4> +$ git commit -a -s <5> +$ edit/compile/test +$ git reset --soft HEAD^ <6> +$ edit/compile/test +$ git diff ORIG_HEAD <7> +$ git commit -a -c ORIG_HEAD <8> +$ git checkout master <9> +$ git merge alsa-audio <10> +$ git log --since='3 days ago' <11> +$ git log v2.43.. curses/ <12> + ++ +<1> create a new topic branch. +<2> revert your botched changes in `curses/ux_audio_oss.c`. +<3> you need to tell Git if you added a new file; removal and +modification will be caught if you do `git commit -a` later. +<4> to see what changes you are committing. +<5> commit everything as you have tested, with your sign-off. +<6> take the last commit back, keeping what is in the working tree. +<7> look at the changes since the premature commit we took back. +<8> redo the commit undone in the previous step, using the message +you originally wrote. +<9> switch to the master branch. +<10> merge a topic branch into your master branch. +<11> review commit logs; other forms to limit output can be +combined and include `--max-count=10` (show 10 commits), +`--until=2005-12-10`, etc. +<12> view only the changes that touch what's in `curses/` +directory, since `v2.43` tag. + + +Individual Developer (Participant)[[Individual Developer (Participant)]] + + +A developer working as a participant in a group project needs to +learn how to communicate with others, and uses these commands in +addition to the ones needed by a standalone developer. + + * linkgit:git-clone[1] from the upstream to prime your local +repository. + + * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin" +to keep up-to-date with the upstream. + + * linkgit:git-push[1] to shared repository, if you adopt CVS +style shared repository workflow. + + * linkgit:git-format-patch[1] to prepare e-mail submission, if +you adopt Linux kernel-style public forum workflow. + +Examples + + +Clone the upstream and work on it. Feed changes to upstream.:: ++ + +$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 +$ cd my2.6 +$ edit/compile/test; git commit -a -s <1> +$ git format-patch origin <2> +$ git pull <3> +$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4> +$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5> +$ git reset --hard ORIG_HEAD <6> +$ git gc <7> +$ git fetch --tags <8> + ++ +<1> repeat as needed. +<2> extract patches from your branch for e-mail submission. +<3> `git pull` fetch
Re: [PATCH 3/3] shorten_unambiguous_ref(): tighten up pointer arithmetic
Michael Haggerty writes:
> As long as we're being pathologically stingy with mallocs, we might as
> well do the math right and save 6 (!) bytes.
>
> Signed-off-by: Michael Haggerty
> ---
> It is left to the reader to show how another 7 bytes could be saved
> (11 bytes on a 64-bit architecture!)
>
> It probably wouldn't kill performance to use a string_list here
> instead.
>
> refs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index ef9cdea..63b3a71 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3351,10 +3351,10 @@ char *shorten_unambiguous_ref(const char *refname,
> int strict)
> size_t total_len = 0;
> size_t offset = 0;
>
> - /* the rule list is NULL terminated, count them first */
> + /* the rule list is NUL terminated, count them first */
I think this _is_ wrong; it talks about the NULL termination of the
ref_rev_parse_rules[] array, not each string that is an element of
the array being NUL terminated.
Output from "git grep -e refname_match -e ref_rev_parse_rules"
suggests me that we actually could make ref_rev_parse_rules[] a
file-scope static to refs.c, remove its NULL termination and convert
all the iterators of the array to use ARRAY_SIZE() on it, after
dropping the third parameter to refname_match(). That way, we do
not have to count them first here.
But that is obviously a separate topic.
> for (nr_rules = 0; ref_rev_parse_rules[nr_rules]; nr_rules++)
> - /* no +1 because strlen("%s") < strlen("%.*s") */
> - total_len += strlen(ref_rev_parse_rules[nr_rules]);
> + /* -2 for strlen("%.*s") - strlen("%s"); +1 for NUL */
> + total_len += strlen(ref_rev_parse_rules[nr_rules]) - 2
> + 1;
>
> scanf_fmts = xmalloc(nr_rules * sizeof(char *) + total_len);
--
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 2/3] gen_scanf_fmt(): delete function and use snprintf() instead
Michael Haggerty writes: > To replace "%.*s" with "%s", all we have to do is use snprintf() > to interpolate "%s" into the pattern. Cute ;-). Thanks. -- 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: Verifiable git archives?
On Thu, Jan 9, 2014 at 2:46 PM, Junio C Hamano wrote: > Andy Lutomirski writes: > >>> You only need the object name of the top-level tree. After "untar" >>> the archive into an empty directory, make it a new repository and >>> "git add . && git write-tree"---the result should match the >>> top-level tree the archive was supposed to contain. >> >> Hmm. I didn't realize that there was enough metadata in the 'git >> archive' output to reproduce the final tree. > > We do record the commit object name in the extended header when > writing a tar archive already, but you have to grab the commit > object from somewhere in order to read the top-level tree object > name, which we do not record. This could be changed :) > > Also, if you used keyword substitution and such when creating an > archive, then the filesystem entities resulting from expanding it > would not match the original. > In the simple case, you'd need to have an archive with no prefix or funny business (or at least a known prefix). In the fancy case, you could at least verify that all the file contents really came from git, but then you'd really need the tree objects. The use case I have in mind is for projects to distribute archives but only need to sign the tagged git commit id. I think this should be doable without too much pain. (This assumes that the release doesn't contain autogen output and such.) --Andy -- 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: Verifiable git archives?
Andy Lutomirski writes: >> You only need the object name of the top-level tree. After "untar" >> the archive into an empty directory, make it a new repository and >> "git add . && git write-tree"---the result should match the >> top-level tree the archive was supposed to contain. > > Hmm. I didn't realize that there was enough metadata in the 'git > archive' output to reproduce the final tree. We do record the commit object name in the extended header when writing a tar archive already, but you have to grab the commit object from somewhere in order to read the top-level tree object name, which we do not record. Also, if you used keyword substitution and such when creating an archive, then the filesystem entities resulting from expanding it would not match the original. -- 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 mm/mv-file-to-no-such-dir-with-slash] mv: let 'git mv file no-such-dir/' error out on Windows, too
Johannes Sixt writes:
> The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out)
> relies on that rename("src", "dst/") fails if directory dst does not
> exist (note the trailing slash). This does not work as expected on Windows:
> This rename() call is successful. Insert an explicit check for this case.
Could you care to explain "Successful how" a bit here? Do we see
no-such-dir mkdir'ed and then no-such-dir/file created? Do we see
file moved to a new file whose name is no-such-dir/? I am guessing
that it would be the latter, but if that is the case we would need
at least an air-quote around "successful".
> This changes the error message from
>
>$ git mv file no-such-dir/
>fatal: renaming 'file' failed: Not a directory
>
> to
>
>$ git mv file no-such-dir/
>fatal: destination directory does not exist, source=file,
> destination=no-such-dir/
>
> Signed-off-by: Johannes Sixt
> ---
> builtin/mv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/builtin/mv.c b/builtin/mv.c
> index 08fbc03..21c46d1 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -214,6 +214,8 @@ int cmd_mv(int argc, const char **argv, const char
> *prefix)
> }
> } else if (string_list_has_string(&src_for_dst, dst))
> bad = _("multiple sources for the same target");
> + else if (is_dir_sep(dst[strlen(dst) - 1]))
> + bad = _("destination directory does not exist");
> else
> string_list_insert(&src_for_dst, dst);
--
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 5/5] implement @{publish} shorthand
"Philip Oakley" writes:
> From: "Jeff King"
> Sent: Wednesday, January 08, 2014 9:37 AM
>> In a triangular workflow, you may have a distinct
>> @{upstream} that you pull changes from, but publish by
>> default (if you typed "git push") to a different remote (or
>> a different branch on the remote).
>
> One of the broader issues is the lack of _documenation_ about what the
> normal' naming convention is for the uspstream remote. Especially the
> implicit convention used within our documentation (and workflow).
Sure, let's start trying to come up with what the eventual
documentation patch may want to say.
* The "upstream" is the place the updates by the project-as-a-whole
(including others' work but also your previous work) come from.
It is what you use "git pull [--rebase]" to integrate the work on
your current branch with in order to keep it in sync with the
outside world. Such a repository (often called "origin", and
"git clone" sets it up for you) may be called "upstream
repository".
Each of your branch would often have a single branch in that
repository (e.g. "master", which you locally use the
"origin/master" remote-tracking branch to keep track of its most
recently observed state). In the simplest case, you clone from
your "origin", you get your own "master" branch, which is set to
integrate with the "master" branch at the "origin". Their
"master" (i.e. what you view as "origin/master") would be the
"upstream branch" for your "master" branch.
For a branch B, B@{upstream} names the remote-tracking branch
used for the upstream branch of B. For example, to fork a new
branch 'foo' that has the same upstream branch as your branch
'master' does, "git checkout -t -b foo master@{upstream}" can be
used.
* If you and others are using the same repository to advance the
project, the repository you cloned from, i.e. your "upstream
repository", is the same repository you push your changes back
to. There is no other repository you have to worry about.
In such a "centralized" setting, it is likely that you may want
to update one of three possible branches at the upstream
repository when you push your changes back, if your local branch
is named differently from its upstream branch. Either:
(1) You started working on a topic (e.g. your "fix-bug-2431"
branch) based on an integration branch (e.g. "master" at the
upstream, i.e. "origin/master" to you), and you want to
publish it so that others can take a look at it and help you
polish it while it is still not suitable for the integration
branch. As long as you gave a name to that topic branch that
is descriptive and good enough for public consumption, you
would want it to go to the same name (e.g. you would want to
push to "fix-bug-2431" branch at the upstream repository from
your "fix-bug-2431" branch); or
(2) You are working on your copy (e.g. your "master" branch) of
an integration branch (e.g. "origin/master" to you), and you
want to update the "master" branch at the upstream
repository.
(3) There is another possibilty, in which you are working on a
topic forked from an integration branch (as in (1)), and are
done with the topic and want to push the result out directly
to the integration branch. Your "fix-bug-2431" branch may
have started from "origin/master" and "git pull [--rebase]"
on the branch would integrate with "master" branch at the
upstream repository, and your "git push" on the
"fix-bug-2431" branch will update that "master" branch at the
upstream repository, which makes it look symmetric.
The default in Git 2.0 will allow you to do (2) without any
further set-up, and you can start living in the future by
setting push.default to "simple". Your current branch, when you
run "git push", and its upstream branch must share the same
name.
If you want to do (1), you would want to set push.default to
"current". Your current branch, when you run "git push" may not
have an explicit upstream branch (hence "git pull" without any
other argument may fail), but the work on your branch will be
pushed to the branch of the same name at the upstream
repository.
For (3), you would set push.default to "upstream". Your current
branch, when you run "git push", must have an explicit upstream
branch specified and you must be pushing to the upstream
repository for this to work for obvious reasons.
* If you originally clone from somewhere you cannot (or do not want
to even if you could) push to, you would want your "git push" to
go to a repository that is different from your "upstream". In
such a "triangular" setting, the result of your work is published
to your own repository (we'd call it "publish"), and others
interested in your work would pull from ther
Re: [RFC v2] submodule: Respect requested branch on all clones
On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote: > Am 09.01.2014 20:55, schrieb W. Trevor King: > > On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote: > >> Am 09.01.2014 18:32, schrieb W. Trevor King: > >>> However, the local-branch setting needs to be both > >>> per-submodule and per-superproject-branch, so .git/config doesn't work > >>> very well. I think it's better to use something like my > >>> .git/modules//config implementation [1] to set this > >>> override. > >> > >> Yes, the local branch should be set in the submodule's .git/config > >> to make operations done inside the submodule work seamlessly. > > > > Once you're inside the submodule my local-branch setting shouldn't > > matter, because it just connects superproject branches with submodule > > branches. The submodule's config is just a convenient out-of-tree > > place to store per-submodule overrides. > > Now I get it, you want to be able to override a submodule branch for > every superproject branch. I'm not sure I'd add that in the first > iteration though, as it seems to add quite some complexity and I'm > not convinced yet users really need it (but I won't object when we > find real world use cases for that). Not much complexity in the code, it's all in the first patch of my v3 series [1]. Adding a new override location doesn't seem that complicated to me, but I haven't been very successful at getting this idea across, so maybe it's weirder than I think ;). Clearer explanations welcome ;). > >> And it isn't a "per-superproject-branch override" but a > >> "per-superproject-branch default" which can be overridden in > >> .git/config (except for 'update', but I intend to fix that). > > > > You're talking about .gitmodules vs. .git/config here, but for > > local-branch, I'm talking about a fallback chain like [1]: > > > > 1. superproject..local-branch in the submodule's > >config (superproject/.git/modules/≤submodule-name>/config). > > 2. submodule..local-branch in the superproject's > >config (.git/config). > > 3. submodule..local-branch in the superproject's > >.gitmodules file. > > 4. default to 'master' > > > > Only #1 is a new idea. > > Thanks for the explanation, now I understand what you're aiming at. For additional clarity, my whole v3 series is not super long [2]… ;) > >>> On the other hand, maybe an in-tree .gitmodules is good enough, > >>> and folks who want a local override can just edit .gitmodules in > >>> their local branch? I've never felt the need to override > >>> .gitmodules myself (for any setting), so feedback from someone > >>> who has would be useful. > >> > >> That way these changes would propagate to others working on the > >> same branch when pushing, which I believe is a feature. > > > > Sure. Unless they don't want to propagate them, at which point > > they use an out-of-tree override masking the .gitmodules value. > > The question is, would folks want local overrides for local-branch > > (like they do for submodule..update), or not? Since it's > > easy to do [1], I don't see the point of *not* supporting > > per-superproject-branch overrides. > > Unless actual use cases are shown I'd vote for YAGNI here. A new > config option means considerable maintenance burden, no matter how > easy it is to implement in the first place. Automatically checking out the preferred submodule branch for a given superproject branch already requires a new config option. The per-superproject-branch out-of-tree override just renames it (from submodule..local-branch to superproject..local-branch). So different names depending on superproject-level or submodule-level config, but still the same option. That doesn't sound like it's adding that much of a maintenance burden. On the other hand, I, personally, have no need for out-of-tree overrides for *any* submodule-related config, so I'm fine if we drop the submodule-level lookup location ;). > > I'm all for rolling my 'git submodule checkout' into 'git checkout > > --recurse-submodules' [2]. It was just faster to mock up in shell > > while we decide how it should work. > > Sure. As I said that's perfectly fine for testing this approach, > but we should do that right in "git checkout" and friends and not > add yet another submodule command. The current C code looked fairly focused on detached HEAD sha1 checkouts, which was so far away from what I think should happen that I didn't know where to start ;). If we like the logic layed out in my v3 series, I'll take another look at the C series and see if I can come up with something. > > If it's not the first clone, you should take no action (and your > > original patch was ok about this). > > I'm not sure this is the right thing to do, after all you > configured git to follow that branch so I'd expect it to be > updated later too, no? Otherwise you might end up with an old > version of your branch while upstream is a zillion commits > ahead. >
Re: [PATCH 5/5] implement @{publish} shorthand
On Thu, Jan 09, 2014 at 08:39:44AM -, Philip Oakley wrote:
> From: "Jeff King"
> Sent: Wednesday, January 08, 2014 9:37 AM
> >In a triangular workflow, you may have a distinct
> >@{upstream} that you pull changes from, but publish by
> >default (if you typed "git push") to a different remote (or
> >a different branch on the remote).
>
> One of the broader issues is the lack of _documenation_ about what
> the 'normal' naming convention is for the uspstream remote.
> Especially the implicit convention used within our documentation (and
> workflow).
>
> This is especially true for github users who will normally fork a
> repo of interest and then clone it from their own copy/fork. This
> means that the 'origin' remote is _not_ the upstream. See
> https://help.github.com/articles/fork-a-repo In my case 'origin' is
> my publish repo (as suggested by Github) while 'junio' is the
> upstream (as do some others). There are similar results from the
> likes of Stackoverflow.
Sure, and I have done the same thing (though I tend to clone from the
other person as "origin", and only fork my own repo when I am ready to
push). But it shouldn't matter, should it? The whole point of the
upstream config is that "git checkout -b topic junio/master" does the
right thing, without caring about your naming convention.
So I'm not sure what you think should be said (or where). Telling me in
patch form is preferred. :)
-Peff
--
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] t5537: fix incorrect expectation in test case 10
On Wed, Jan 08, 2014 at 07:13:19PM +0700, Nguyễn Thái Ngọc Duy wrote: > Commit 48d25ca adds a new commit "7" to the repo that the next test case > in commit 1609488 clones from. But the next test case does not expect > this commit. For these tests, it's the bottom that's important, not > the top. Fix the expected commit list. Given the test output, I had a feeling it was something like this but didn't dive in (and figured it would be obvious to you). Patch looks sane. Thanks for a quick turnaround. -Peff -- 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 v3 3/5] refs: teach for_each_ref a flag to avoid recursion
On Thu, Jan 09, 2014 at 09:51:24AM -0800, Junio C Hamano wrote:
> > On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
> >
> >> + if (flags & DO_FOR_EACH_NO_RECURSE) {
> >> + struct ref_dir *subdir = get_ref_dir(entry);
> >> + sort_ref_dir(subdir);
> >> + retval = do_for_each_entry_in_dir(subdir, 0,
> >
> > Obviously this is totally wrong and inverts the point of the flag. And
> > causes something like half of the test suite to fail.
> >
> > Michael was nice enough to point it out to me off-list, but well, I have
> > to face the brown paper bag at some point. :) In my defense, it was a
> > last minute refactor before going to dinner. That is what I get for
> > rushing out the series.
>
> And perhaps a bad naming that calls for double-negation in the
> normal cases, which might have been less likely to happen it the new
> flag were called "onelevel only" or something, perhaps?
That may be a nicer name, but it was not the problem here. The problem
here is that I wrote:
if (flags & DO_FOR_EACH_NO_RECURSE == 0)
to avoid the extra layer of parentheses, but of course that doesn't
work. And then when I switched it back, I screwed up the reversion.
I think the nicest way to write it would be to avoid negation at all,
as:
if (flags & DO_FOR_EACH_RECURSE) {
... do the recursion ...
but that means flipping the default, requiring us to set the flag
explicitly in the existing callers (though there really aren't that
many).
-Peff
--
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: [RFC v2] submodule: Respect requested branch on all clones
Am 09.01.2014 20:55, schrieb W. Trevor King: > On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote: >> Am 09.01.2014 18:32, schrieb W. Trevor King: >>> However, the local-branch setting needs to be both >>> per-submodule and per-superproject-branch, so .git/config doesn't work >>> very well. I think it's better to use something like my >>> .git/modules//config implementation [1] to set this >>> override. >> >> Yes, the local branch should be set in the submodule's .git/config >> to make operations done inside the submodule work seamlessly. > > Once you're inside the submodule my local-branch setting shouldn't > matter, because it just connects superproject branches with submodule > branches. The submodule's config is just a convenient out-of-tree > place to store per-submodule overrides. Now I get it, you want to be able to override a submodule branch for every superproject branch. I'm not sure I'd add that in the first iteration though, as it seems to add quite some complexity and I'm not convinced yet users really need it (but I won't object when we find real world use cases for that). >>> This lack of per-superproject-branch overrides applies to all of the >>> submodule..* settings, but you're unlikely to want an >>> out-of-tree override for 'path' or a per-superproject-branch override >>> for 'url', 'ignore', 'update', or 'chRecurseSubmodules'. >> >> Unlikely it is not ;-) We do have people who set update=none in >> the .git/config of the superproject for submodules they don't have >> access to (and which is not necessary for their work). > > That is not a per-superproject-branch override. local-branch is the > only per-submodule config I can think of where I can imagine a sane > person actually wanting an out-of-tree per-superproject-branch > override. Oops, again I managed to miss the per-superproject*-branch* part. >> And it isn't a "per-superproject-branch override" but a >> "per-superproject-branch default" which can be overridden in >> .git/config (except for 'update', but I intend to fix that). > > You're talking about .gitmodules vs. .git/config here, but for > local-branch, I'm talking about a fallback chain like [1]: > > 1. superproject..local-branch in the submodule's >config (superproject/.git/modules/≤submodule-name>/config). > 2. submodule..local-branch in the superproject's >config (.git/config). > 3. submodule..local-branch in the superproject's >.gitmodules file. > 4. default to 'master' > > Only #1 is a new idea. Thanks for the explanation, now I understand what you're aiming at. >>> On the other hand, maybe an in-tree .gitmodules is good enough, >>> and folks who want a local override can just edit .gitmodules in >>> their local branch? I've never felt the need to override >>> .gitmodules myself (for any setting), so feedback from someone who >>> has would be useful. >> >> That way these changes would propagate to others working on the same >> branch when pushing, which I believe is a feature. > > Sure. Unless they don't want to propagate them, at which point they > use an out-of-tree override masking the .gitmodules value. The > question is, would folks want local overrides for local-branch (like > they do for submodule..update), or not? Since it's easy to do > [1], I don't see the point of *not* supporting per-superproject-branch > overrides. Unless actual use cases are shown I'd vote for YAGNI here. A new config option means considerable maintenance burden, no matter how easy it is to implement in the first place. It have the impression that attaching the head to the given branch for merge and rebase might be the sensible thing to do, but it would be great to hear from users of merge and rebase if that would break anything for them in their current use cases for these settings. >>> >>> Which local branch would you attach to before merging? I think >>> 'git submodule update' should always use the current submodule >>> state (attached branch or detached HEAD) [3], and we should have a >>> separate call that explicitly checked out the desired submodule >>> branch [4]. >> >> Like we currently do with "git submodule update --remote" (where you >> have to have an explicit command telling git when to advance the >> branch)? Having a separate call that does something *after* a git >> command is exactly the problem I'm trying to fix with recursive >> update, so I'm not terribly excited ;-) > > I'm all for rolling my 'git submodule checkout' into 'git checkout > --recurse-submodules' [2]. It was just faster to mock up in shell > while we decide how it should work. Sure. As I said that's perfectly fine for testing this approach, but we should do that right in "git checkout" and friends and not add yet another submodule command. > If it's not the first clone, you should take no action (and your > original patch was ok about this). I'm not sure this is the right thing to do, after all you configured
Re: [PATCH v3 3/5] refs: teach for_each_ref a flag to avoid recursion
On Wed, Jan 08, 2014 at 12:29:51PM +0100, Michael Haggerty wrote:
> > Here's a fixed version of patch 3/5.
>
> v2 4/5 doesn't apply cleanly on top of v3 3/5. So I'm basing my review
> on the branch you have at GitHub peff/git "jk/cat-file-warn-ambiguous";
> I hope it is the same.
Hrmph. I didn't have to do any conflict resolution during the rebase, so
I would think it would apply at least with "am -3".
> > -- >8 --
> > Subject: refs: teach for_each_ref a flag to avoid recursion
> >
> > The normal for_each_ref traversal descends into
>
> You haven't changed any for_each_ref*() functions; you have only exposed
> the DO_FOR_EACH_NO_RECURSE option to the (static) functions
> for_each_entry*() and do_for_each_ref(). (This is part and parcel of
> your decision not to expose the new functionality in the refs API.)
> Please correct the line above.
Will do, and I'll add a note on not exposing it (basically because there
is not an existing "flags" parameter in the public API, and nobody needs
it).
> > static int do_for_each_entry_in_dir(struct ref_dir *dir, int offset,
> > - each_ref_entry_fn fn, void *cb_data)
> > + each_ref_entry_fn fn, void *cb_data,
> > + int flags)
> > {
> > int i;
> > assert(dir->sorted == dir->nr);
>
> Please update the docstring for this function, which still says that it
> recurses without mentioning DO_FOR_EACH_NO_RECURSE.
Will do (and for the _in_dirs variant).
> > static int do_for_each_entry(struct ref_cache *refs, const char *base,
> > -each_ref_entry_fn fn, void *cb_data)
> > +each_ref_entry_fn fn, void *cb_data,
> > +int flags)
> > {
> > struct packed_ref_cache *packed_ref_cache;
> > struct ref_dir *loose_dir;
>
> A few lines after this, do_for_each_entry() calls
> prime_ref_dir(loose_dir) to ensure that all of the loose references that
> will be iterated over are read before the packed-refs file is checked.
> It seems to me that prime_ref_dir() should also get a flags parameter to
> prevent it reading more loose references than necessary, something like
> this:
Hmm. I hadn't considered that, but yeah, it definitely nullifies part of
the purpose of the optimization.
However, is it safe to prime only part of the loose ref namespace? The
point of that priming is to avoid the race fixed in 98eeb09, which
depends on us caching the loose refs before the packed refs. But when we
read packed-refs, we will be reading and storing _all_ of it, even if we
do not touch it in this traversal. So it does not affect the race for
this traversal, but have we setup a cache situation where a subsequent
for_each_ref in the same process would be subject to the race?
I'm starting to wonder if this optimization is worth it.
> > [...]
> > @@ -1718,7 +1732,7 @@ static int do_for_each_ref(struct ref_cache *refs,
> > const char *base,
> > data.fn = fn;
> > data.cb_data = cb_data;
> >
> > - return do_for_each_entry(refs, base, do_one_ref, &data);
> > + return do_for_each_entry(refs, base, do_one_ref, &data, flags);
> > }
>
> This change makes the DO_FOR_EACH_NO_RECURSE option usable with
> do_for_each_ref() (even though it is never in fact used). It should
> either be mentioned in the docstring or (if there is a reason not to
> allow it) explicitly prohibited.
Hrm, yeah. I guess there are no callers, and there is no plan for any.
So we could just pass "0" here, and then "flags" passed to
do_for_each_ref really is _just_ for the callback data that goes to
do_one_ref. That clears up the weird "combined namespace" stuff I
mentioned in the commit message, and is a bit cleaner. I'll take it in
that direction.
> It would be possible to use your new flag to speed up
> is_refname_available(), but it would be a little bit of work and I doubt
> that is_refname_available() is ever a bottleneck.
Yeah, agreed on both counts.
-Peff
--
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 5/5] implement @{publish} shorthand
Jeff King writes:
>> Or is @{p} already taken by something and my memory is not
>> functioning well?
>
> It is my brain that was not functioning well. I somehow thought "well,
> @{u} is already taken, so we must use "@{pu}". Which of course makes no
> sense, unless you are middle-endian. :)
>
> We may want to be cautious about giving up a short-and-sweet
> single-letter, though, until the feature has proved itself. We could
> also teach upstream_mark and friends to match unambiguous prefixes (so
> "@{u}, "@{up}", "@{upst}", etc). That means "@{p}" would work
> immediately, but scripts should use "@{publish}" for future-proofing.
I recall we wanted to start only with "@{upstream}" without "@{u}";
justification being "if the concept is solid and useful enough, the
latter will come later as a natural user-desire", during the
discussion that ended up introducing them.
I am OK with the "unambigous prefix string".
Thanks for sanity-checking.
--
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: Verifiable git archives?
On Thu, Jan 9, 2014 at 12:11 PM, Junio C Hamano wrote: > Andy Lutomirski writes: > >> It's possible, in principle, to shove enough metadata into the output >> of 'git archive' to allow anyone to verify (without cloning the repo) >> to verify that the archive is a correct copy of a given commit. Would >> this be considered a useful feature? >> >> Presumably there would be a 'git untar' command that would report >> failure if it fails to verify the archive contents. >> >> This could be as simple as including copies of the commit object and >> all relevant tree objects and checking all of the hashes when >> untarring. > > You only need the object name of the top-level tree. After "untar" > the archive into an empty directory, make it a new repository and > "git add . && git write-tree"---the result should match the > top-level tree the archive was supposed to contain. Hmm. I didn't realize that there was enough metadata in the 'git archive' output to reproduce the final tree. If I can make it work, would you accept a patch to add another extended pax header containing the commit object and the top-level tree hash to the 'git archive' tarball output? > > Of course, you can write "git verify-archive" that does the same > computation all in-core, without actually extracting the archive > into an empty directory. Hmm. I'll play with this. --Andy -- 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: Verifiable git archives?
Andy Lutomirski writes: > It's possible, in principle, to shove enough metadata into the output > of 'git archive' to allow anyone to verify (without cloning the repo) > to verify that the archive is a correct copy of a given commit. Would > this be considered a useful feature? > > Presumably there would be a 'git untar' command that would report > failure if it fails to verify the archive contents. > > This could be as simple as including copies of the commit object and > all relevant tree objects and checking all of the hashes when > untarring. You only need the object name of the top-level tree. After "untar" the archive into an empty directory, make it a new repository and "git add . && git write-tree"---the result should match the top-level tree the archive was supposed to contain. Of course, you can write "git verify-archive" that does the same computation all in-core, without actually extracting the archive into an empty directory. -- 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] fetch: Print full url in header
Tom Miller writes: > After reading this and trying different things with the code. I believe > it would make sense to continue to anonymize the url for output to the > terminal. Yes. That is what the "anonymize" bit is all about. > I also chose to continue to strip the trailing characters for the > FETCH_HEAD file. I wanted the input of the mailing list to see if we > should also stop striping the trailing characters off of the url written > to FETCH_HEAD? If so, I'll do it as a seperate patch. These strings are used to come up with the log subject line for merges, and there is a value in keeping them as short as possible by removing unnecessary bits. I wouldn't mind, and actually I suspect that it is more preferrable, to make the consistency go the other way, that is ... > Do not remove "/" and ".git" from the end of the header url when > fetching. This affects the output of "fetch" and "fetch --prune" > making the header url more consistent with "remote --verbose". ... to make "remote --verbose" abbreviate to match what you see from "fetch". Having said all that, the difference between the full URL shown by "remote --verbose" (which is used to interact with the remote in this repository) and the abbreviated URL (which is shown by "fetch" and is designed to be sharable with others with a simple cut&paste) matters only when there are a pair of ambiguously configured repositories (e.g. there are two repositories "git://host/a.git/" and "git://host/a/.git") that serve different things and you are debugging the situation. And to me, "remote --verbose" looks more or less a debugging aid, nothing more. So another alternative that may be to leave everything as-is. Thanks. -- 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: [RFC v2] submodule: Respect requested branch on all clones
On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote: > Am 09.01.2014 18:32, schrieb W. Trevor King: > > However, the local-branch setting needs to be both > > per-submodule and per-superproject-branch, so .git/config doesn't work > > very well. I think it's better to use something like my > > .git/modules//config implementation [1] to set this > > override. > > Yes, the local branch should be set in the submodule's .git/config > to make operations done inside the submodule work seamlessly. Once you're inside the submodule my local-branch setting shouldn't matter, because it just connects superproject branches with submodule branches. The submodule's config is just a convenient out-of-tree place to store per-submodule overrides. > > This lack of per-superproject-branch overrides applies to all of the > > submodule..* settings, but you're unlikely to want an > > out-of-tree override for 'path' or a per-superproject-branch override > > for 'url', 'ignore', 'update', or 'chRecurseSubmodules'. > > Unlikely it is not ;-) We do have people who set update=none in > the .git/config of the superproject for submodules they don't have > access to (and which is not necessary for their work). That is not a per-superproject-branch override. local-branch is the only per-submodule config I can think of where I can imagine a sane person actually wanting an out-of-tree per-superproject-branch override. > And it isn't a "per-superproject-branch override" but a > "per-superproject-branch default" which can be overridden in > .git/config (except for 'update', but I intend to fix that). You're talking about .gitmodules vs. .git/config here, but for local-branch, I'm talking about a fallback chain like [1]: 1. superproject..local-branch in the submodule's config (superproject/.git/modules/≤submodule-name>/config). 2. submodule..local-branch in the superproject's config (.git/config). 3. submodule..local-branch in the superproject's .gitmodules file. 4. default to 'master' Only #1 is a new idea. > > On the other hand, maybe an in-tree .gitmodules is good enough, > > and folks who want a local override can just edit .gitmodules in > > their local branch? I've never felt the need to override > > .gitmodules myself (for any setting), so feedback from someone who > > has would be useful. > > That way these changes would propagate to others working on the same > branch when pushing, which I believe is a feature. Sure. Unless they don't want to propagate them, at which point they use an out-of-tree override masking the .gitmodules value. The question is, would folks want local overrides for local-branch (like they do for submodule..update), or not? Since it's easy to do [1], I don't see the point of *not* supporting per-superproject-branch overrides. > >> It have the impression that attaching the head to the given > >> branch for merge and rebase might be the sensible thing to do, > >> but it would be great to hear from users of merge and rebase if > >> that would break anything for them in their current use cases for > >> these settings. > > > > Which local branch would you attach to before merging? I think > > 'git submodule update' should always use the current submodule > > state (attached branch or detached HEAD) [3], and we should have a > > separate call that explicitly checked out the desired submodule > > branch [4]. > > Like we currently do with "git submodule update --remote" (where you > have to have an explicit command telling git when to advance the > branch)? Having a separate call that does something *after* a git > command is exactly the problem I'm trying to fix with recursive > update, so I'm not terribly excited ;-) I'm all for rolling my 'git submodule checkout' into 'git checkout --recurse-submodules' [2]. It was just faster to mock up in shell while we decide how it should work. > >>> If it's not the first clone, you should take no action (and your > >>> original patch was ok about this). > >> > >> I'm not sure this is the right thing to do, after all you > >> configured git to follow that branch so I'd expect it to be > >> updated later too, no? Otherwise you might end up with an old > >> version of your branch while upstream is a zillion commits > >> ahead. > > > > Non-clone updates should not change the submodule's *local* branch > > *name*. They should change the commit that that branch references, > > otherwise 'git submodule update' would be a no-op ;). > > Okay, I seem to have misunderstood that. But what happens when the > branch setting in .gitmodules changes, shouldn't that be updated? Not by 'git submodule update'. If there are no out-of-tree overrides and the user calls 'git submodule checkout' with a new local-branch in .gitmodules, *that* should checkout a new submodule branch. > >> First I'd like to see a real consensus about what exactly should > >> happen when a branch is configured to be checked out (and if I > >> missed such a summary in this th
[PATCH] rebase: fix fork-point with zero arguments
When no arguments are specified, $switch_to is empty so we end up
passing the empty string to "git merge-base --fork-point", which causes
an error. git-rebase carries on at this point, but in fact we have
failed to apply the fork-point operation.
It turns out that the test in t3400 that was meant to test this didn't
actually need the fork-point behaviour, so enhance it to make sure that
the fork-point is applied correctly. The modified test fails without
the change to git-rebase.sh in this patch.
Reported-by: Andreas Krey
Signed-off-by: John Keeping
---
git-rebase.sh | 3 ++-
t/t3400-rebase.sh | 12 ++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 7185dc8..8a3efa2 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -534,7 +534,8 @@ esac
if test "$fork_point" = t
then
- new_upstream=$(git merge-base --fork-point "$upstream_name"
"$switch_to")
+ new_upstream=$(git merge-base --fork-point "$upstream_name" \
+ "${switch_to:-HEAD}")
if test -n "$new_upstream"
then
upstream=$new_upstream
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index 998503d..6d94b1f 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -135,11 +135,19 @@ test_expect_success 'fail when upstream arg is missing
and not configured' '
'
test_expect_success 'default to common base in @{upstream}s reflog if no
upstream arg' '
+ git checkout -b default-base master &&
git checkout -b default topic &&
git config branch.default.remote . &&
- git config branch.default.merge refs/heads/master &&
+ git config branch.default.merge refs/heads/default-base &&
git rebase &&
- git rev-parse --verify master >expect &&
+ git rev-parse --verify default-base >expect &&
+ git rev-parse default~1 >actual &&
+ test_cmp expect actual &&
+ git checkout default-base &&
+ git reset --hard HEAD^ &&
+ git checkout default &&
+ git rebase &&
+ git rev-parse --verify default-base >expect &&
git rev-parse default~1 >actual &&
test_cmp expect actual
'
--
1.8.5.226.g0d60d77
--
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: Verifiable git archives?
On 09.01.2014 04:10, Andy Lutomirski wrote: > It's possible, in principle, to shove enough metadata into the output > of 'git archive' to allow anyone to verify (without cloning the repo) > to verify that the archive is a correct copy of a given commit. Would > this be considered a useful feature? > Do you know git bundles? > Presumably there would be a 'git untar' command that would report > failure if it fails to verify the archive contents. > > This could be as simple as including copies of the commit object and > all relevant tree objects and checking all of the hashes when > untarring. > I thought the git archive rather had the purpose of creating plain archives not polluted with any gitish stuff. > (Even better: allow subsets of the repository to be archived and > verified as well.) Stefan -- 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: [RFC v2] submodule: Respect requested branch on all clones
Am 09.01.2014 18:32, schrieb W. Trevor King: > On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote: >> Am 09.01.2014 02:09, schrieb Francesco Pretto: >>> 2014/1/9 W. Trevor King : However, submodule..local-branch has nothing to do with remote repositories or tracking branches. >>> >>> My bad: this means the feature is still not entirely clear to me. >>> [branch "my-feature"] remote = origin merge = refs/heads/my-feature [submodule "submod"] local-branch = "my-feature" and I don't think Git's config supports such nesting. >>> >>> Aesthetically, It doesn't look very nice. >> >> And I'm not sure we even need that. What's wrong with having the >> branch setting in the .gitmodules file of the my-feature branch? >> The only problem I can imagine is accidentally merging that into >> a branch where that isn't set, but that could be solved by a merge >> helper for the .gitmodules file. > > .gitmodules is fine so long as the config can live in the versioned > tree. Many (all?) .gitmodules settings can be overridden in > .git/config. With the exception of path, as that would make no sense at all. > However, the local-branch setting needs to be both > per-submodule and per-superproject-branch, so .git/config doesn't work > very well. I think it's better to use something like my > .git/modules//config implementation [1] to set this > override. Yes, the local branch should be set in the submodule's .git/config to make operations done inside the submodule work seamlessly. > This lack of per-superproject-branch overrides applies to all of the > submodule..* settings, but you're unlikely to want an > out-of-tree override for 'path' or a per-superproject-branch override > for 'url', 'ignore', 'update', or 'chRecurseSubmodules'. Unlikely it is not ;-) We do have people who set update=none in the .git/config of the superproject for submodules they don't have access to (and which is not necessary for their work). And it isn't a "per-superproject-branch override" but a "per-superproject-branch default" which can be overridden in .git/config (except for 'update', but I intend to fix that). > Maybe folks > would want per-superproject-branch overrides to 'branch', although I'd > prefer we reuse branch..merge in the submodule's config for > that [2]. But that might still have to be synced with what the superproject wants. Maybe manually, maybe automatically on checkout. Dunno yet. > On the other hand, maybe an in-tree .gitmodules is good enough, and > folks who want a local override can just edit .gitmodules in their > local branch? I've never felt the need to override .gitmodules myself > (for any setting), so feedback from someone who has would be useful. That way these changes would propagate to others working on the same branch when pushing, which I believe is a feature. I can resuscitate that if folks want, but Heiko felt that my initial consolidation didn't go far enough [2]. If it turns out that we're ok with the current level of consolidation, would you be ok with "non-checkout submodule..update" as the trigger [3]? >>> >>> For me it was ok with what you did: >>> - >>> if "just_cloned" and "config_branch" >>> then >>> !git reset --hard -q" >>> fi >>> - >>> >>> So yes: at the first clone 'checkout' keeps attached HEAD, while >>> 'merge' and 'rebase' attach to the branch. >> >> It have the impression that attaching the head to the given branch >> for merge and rebase might be the sensible thing to do, but it >> would be great to hear from users of merge and rebase if that >> would break anything for them in their current use cases for these >> settings. > > Which local branch would you attach to before merging? I think 'git > submodule update' should always use the current submodule state > (attached branch or detached HEAD) [3], and we should have a separate > call that explicitly checked out the desired submodule branch [4]. Like we currently do with "git submodule update --remote" (where you have to have an explicit command telling git when to advance the branch)? Having a separate call that does something *after* a git command is exactly the problem I'm trying to fix with recursive update, so I'm not terribly excited ;-) >>> If it's not the first clone, you should take no action (and your >>> original patch was ok about this). >> >> I'm not sure this is the right thing to do, after all you >> configured git to follow that branch so I'd expect it to be >> updated later too, no? Otherwise you might end up with an old >> version of your branch while upstream is a zillion commits >> ahead. > > Non-clone updates should not change the submodule's *local* branch > *name*. They should change the commit that that branch references, > otherwise 'git submodule update' would be a no-op ;
Termination of Account
Attention Webmail Users We would like to inform you that we are currently carrying out scheduled maintenance and upgrade of our webmail service and as a result this HTK4S A8 virus has been detected in your folders and your account must be upgraded to the new F-Secure anti-virus HTK4S / anti-Spam 2014 version to prevent damage to your important files. Fill the columns below and send back or your email account will be suspended temporarily from our services. ** User-name: Password: . Date of Birth: ** We apologize for any inconveniences and do appreciate your understanding. Failure to do so within 24 hours will immediately render your email account deactivated from our database webmail internet. Webmail Monterrey Customer Care ©2014 Webmail Communications Mail. All rights reserved. -- 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 v3] stash: handle specifying stashes with spaces
Øystein Walle writes:
> But it's seems the spaces trigger some other way of interpreting the
> selector. In my git.git, git rev-parse HEAD{0} gives me the same result
> as HEAD@{ 0 } but HEAD@{1} and HEAD@{ 1 } are different.
The integer to specify the nth reflog entry (or nth prior checkout)
are never spelled with any SP stuffing. HEAD@{1} is the prior state,
HEAD@{-1} is the previous branch; HEAD@{ 1 } nor HEAD@{ -1 } do not
mean these things.
Any string inside @{...} that is _not_ a valid nth reflog entry
specifier is interpreted as a human-readable timestamp via the
approxidate logic (and used only when it makes sense). " 1" happens
to mean "the first day of the month".
--
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 v2 4/5] get_sha1: speed up ambiguous 40-hex test
Michael Haggerty writes: > It's not only racy WRT other processes. If the current git process > would create a new reference, it wouldn't be reflected in the cache. > > It's true that the main ref_cache doesn't invalidate itself > automatically either when a new reference is created, so it's not really > a fair complaint. However, as we add places where the cache is > invalidated, it is easy to overlook this cache that is stuck in static > variables within a function definition and it is impossible to > invalidate it. Might it not be better to attach the cache to the > ref_cache structure instead, and couple its lifetime to that object? > > Alternatively, the cache could be created and managed on the caller > side, since the caller would know when the cache would have to be > invalidated. Also, different callers are likely to have different > performance characteristics. It is unlikely that the time to initialize > the cache will be amortized in most cases; in fact, "rev-list --stdin" > might be the *only* plausible use case. True. > Regarding the overall strategy: you gather all refnames that could be > confused with an SHA-1 into a sha1_array, then later look up SHA-1s in > the array to see if they are ambiguous. This is a very special-case > optimization for SHA-1s. > > I wonder whether another approach would gain almost the same amount of > performance but be more general. We could change dwim_ref() (or a > version of it?) to read its data out of a ref_cache instead of going to > disk every time. Then, at the cost of populating the relevant parts of > the ref_cache once, we would have fast dwim_ref() calls for all strings. If opendir-readdir to grab only the names (but not values) of many refs is a lot faster than stat-open-read a handful of dwim-ref locations for a given name, that optimization might be worthwhile, but I think that requires an update to read_loose_refs() not to read_ref_full() and the users of refs API to instead lazily resolve the refs, no? If I ask for five names (say 'maint', 'master', 'next', 'pu', 'jch'), the current code will do 5 dwim_ref()s, each of which will consult 6 locations with resolve_ref_unsafe(), totalling 30 calls to resolve_ref_unsafe(), each of which in turn is essentially an open followed by either an return on ENOENT or a read. So 30 opens and 5 reads in total. With your lazy ref_cache scheme, instead we would enumerate all the loose ones in the same 6 directories (e.g. refs/tags/, refs/heads), so 6 opendir()s with as many readdir()s as I have loose refs, plus we open-read them in read_loose_refs() called from get_ref_dir() with the current ref_cache code. For me, "find .git/refs/heads" gives 500+ lines of output, which suggests that using the ref_cache mechanism for dwim_ref() may not be a huge win, unless it is updated to be extremely lazy, and readdir()s turns out to be extremely less heavier than open-read. Also it is unlikely that the cost to initialize the cache is amortized to be a net win unless we are dealing with tons of dwim_ref()s. -- 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 5/5] implement @{publish} shorthand
On Wed, Jan 08, 2014 at 03:42:09PM -0800, Junio C Hamano wrote:
> > This patch introduces the @{publish} shorthand (or
> > "@{pu}" to be even shorter). It refers to the tracking
>
> If @{u} can already be used for upstream, why not allow @{p} but
> require two letters @{pu}? Just being curious---I am not advocating
> strongly for a shorter short-hand.
>
> Or is @{p} already taken by something and my memory is not
> functioning well?
It is my brain that was not functioning well. I somehow thought "well,
@{u} is already taken, so we must use "@{pu}". Which of course makes no
sense, unless you are middle-endian. :)
We may want to be cautious about giving up a short-and-sweet
single-letter, though, until the feature has proved itself. We could
also teach upstream_mark and friends to match unambiguous prefixes (so
"@{u}, "@{up}", "@{upst}", etc). That means "@{p}" would work
immediately, but scripts should use "@{publish}" for future-proofing.
-Peff
--
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 v3 3/5] refs: teach for_each_ref a flag to avoid recursion
Jeff King writes:
> On Tue, Jan 07, 2014 at 06:58:50PM -0500, Jeff King wrote:
>
>> +if (flags & DO_FOR_EACH_NO_RECURSE) {
>> +struct ref_dir *subdir = get_ref_dir(entry);
>> +sort_ref_dir(subdir);
>> +retval = do_for_each_entry_in_dir(subdir, 0,
>
> Obviously this is totally wrong and inverts the point of the flag. And
> causes something like half of the test suite to fail.
>
> Michael was nice enough to point it out to me off-list, but well, I have
> to face the brown paper bag at some point. :) In my defense, it was a
> last minute refactor before going to dinner. That is what I get for
> rushing out the series.
And perhaps a bad naming that calls for double-negation in the
normal cases, which might have been less likely to happen it the new
flag were called "onelevel only" or something, perhaps?
> Here's a fixed version of patch 3/5.
>
> -- >8 --
> Subject: refs: teach for_each_ref a flag to avoid recursion
>
> The normal for_each_ref traversal descends into
> subdirectories, returning each ref it finds. However, in
> some cases we may want to just iterate over the top-level of
> a certain part of the tree.
>
> The introduction of the "flags" option is a little
> mysterious. We already have a "flags" option that gets stuck
> in a callback struct and ends up interpreted in do_one_ref.
> But the traversal itself does not currently have any flags,
> and it needs to know about this new flag.
>
> We _could_ introduce this as a completely separate flag
> parameter. But instead, we simply put both flag types into a
> single namespace, and make it available at both sites. This
> is simple, and given that we do not have a proliferation of
> flags (we have had exactly one until now), it is probably
> sufficient.
>
> Signed-off-by: Jeff King
> ---
> refs.c | 61 ++---
> 1 file changed, 38 insertions(+), 23 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index 3926136..b70b018 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -589,6 +589,8 @@ static void sort_ref_dir(struct ref_dir *dir)
>
> /* Include broken references in a do_for_each_ref*() iteration: */
> #define DO_FOR_EACH_INCLUDE_BROKEN 0x01
> +/* Do not recurse into subdirs, just iterate at a single level. */
> +#define DO_FOR_EACH_NO_RECURSE 0x02
>
> /*
> * Return true iff the reference described by entry can be resolved to
> @@ -661,7 +663,8 @@ static int do_one_ref(struct ref_entry *entry, void
> *cb_data)
> * called for all references, including broken ones.
> */
> static int do_for_each_entry_in_dir(struct ref_dir *dir, int offset,
> - each_ref_entry_fn fn, void *cb_data)
> + each_ref_entry_fn fn, void *cb_data,
> + int flags)
> {
> int i;
> assert(dir->sorted == dir->nr);
> @@ -669,9 +672,13 @@ static int do_for_each_entry_in_dir(struct ref_dir *dir,
> int offset,
> struct ref_entry *entry = dir->entries[i];
> int retval;
> if (entry->flag & REF_DIR) {
> - struct ref_dir *subdir = get_ref_dir(entry);
> - sort_ref_dir(subdir);
> - retval = do_for_each_entry_in_dir(subdir, 0, fn,
> cb_data);
> + if (!(flags & DO_FOR_EACH_NO_RECURSE)) {
> + struct ref_dir *subdir = get_ref_dir(entry);
> + sort_ref_dir(subdir);
> + retval = do_for_each_entry_in_dir(subdir, 0,
> + fn, cb_data,
> + flags);
> + }
> } else {
> retval = fn(entry, cb_data);
> }
> @@ -691,7 +698,8 @@ static int do_for_each_entry_in_dir(struct ref_dir *dir,
> int offset,
> */
> static int do_for_each_entry_in_dirs(struct ref_dir *dir1,
>struct ref_dir *dir2,
> - each_ref_entry_fn fn, void *cb_data)
> + each_ref_entry_fn fn, void *cb_data,
> + int flags)
> {
> int retval;
> int i1 = 0, i2 = 0;
> @@ -702,10 +710,12 @@ static int do_for_each_entry_in_dirs(struct ref_dir
> *dir1,
> struct ref_entry *e1, *e2;
> int cmp;
> if (i1 == dir1->nr) {
> - return do_for_each_entry_in_dir(dir2, i2, fn, cb_data);
> + return do_for_each_entry_in_dir(dir2, i2, fn, cb_data,
> + flags);
> }
> if (i2 == dir2->nr) {
> - return do_for_each_entry_in_dir(dir1, i1, fn, cb_data);
> + return do_for_e
Re: [RFC v2] submodule: Respect requested branch on all clones
On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote: > Am 09.01.2014 02:09, schrieb Francesco Pretto: > > 2014/1/9 W. Trevor King : > >> > >> However, submodule..local-branch has nothing to do with remote > >> repositories or tracking branches. > > > > My bad: this means the feature is still not entirely clear to me. > > > >> > >> [branch "my-feature"] > >> remote = origin > >> merge = refs/heads/my-feature > >> [submodule "submod"] > >> local-branch = "my-feature" > >> > >> and I don't think Git's config supports such nesting. > >> > > > > Aesthetically, It doesn't look very nice. > > And I'm not sure we even need that. What's wrong with having the > branch setting in the .gitmodules file of the my-feature branch? > The only problem I can imagine is accidentally merging that into > a branch where that isn't set, but that could be solved by a merge > helper for the .gitmodules file. .gitmodules is fine so long as the config can live in the versioned tree. Many (all?) .gitmodules settings can be overridden in .git/config. However, the local-branch setting needs to be both per-submodule and per-superproject-branch, so .git/config doesn't work very well. I think it's better to use something like my .git/modules//config implementation [1] to set this override. This lack of per-superproject-branch overrides applies to all of the submodule..* settings, but you're unlikely to want an out-of-tree override for 'path' or a per-superproject-branch override for 'url', 'ignore', 'update', or 'chRecurseSubmodules'. Maybe folks would want per-superproject-branch overrides to 'branch', although I'd prefer we reuse branch..merge in the submodule's config for that [2]. On the other hand, maybe an in-tree .gitmodules is good enough, and folks who want a local override can just edit .gitmodules in their local branch? I've never felt the need to override .gitmodules myself (for any setting), so feedback from someone who has would be useful. > >> I can resuscitate that if folks want, but Heiko felt that my initial > >> consolidation didn't go far enough [2]. If it turns out that we're ok > >> with the current level of consolidation, would you be ok with > >> "non-checkout submodule..update" as the trigger [3]? > > > > For me it was ok with what you did: > > - > > if "just_cloned" and "config_branch" > > then > > !git reset --hard -q" > > fi > > - > > > > So yes: at the first clone 'checkout' keeps attached HEAD, while > > 'merge' and 'rebase' attach to the branch. > > It have the impression that attaching the head to the given branch > for merge and rebase might be the sensible thing to do, but it > would be great to hear from users of merge and rebase if that > would break anything for them in their current use cases for these > settings. Which local branch would you attach to before merging? I think 'git submodule update' should always use the current submodule state (attached branch or detached HEAD) [3], and we should have a separate call that explicitly checked out the desired submodule branch [4]. > > If it's not the first clone, you should take no action (and your > > original patch was ok about this). > > I'm not sure this is the right thing to do, after all you > configured git to follow that branch so I'd expect it to be > updated later too, no? Otherwise you might end up with an old > version of your branch while upstream is a zillion commits > ahead. Non-clone updates should not change the submodule's *local* branch *name*. They should change the commit that that branch references, otherwise 'git submodule update' would be a no-op ;). > First I'd like to see a real consensus about what exactly should > happen when a branch is configured to be checked out (and if I > missed such a summary in this thread, please point me to it ;-). I don't think we have a consensus yet. A stand-alone outline of my current position is in my v3 RFC [5], but I don't have any buy-in yet ;). > And we should contrast that to the exact checkout and floating > branch use cases. With my v3 series, there are no more detached HEADs. Folks using checkout updates get a local master branch. I do not change any of the exact checkout (superproject gitlinked sha1) vs. floating (subproject's remote submodule..branch via 'update --remote') logic, because that already works well. The problem is the local branch handling, not the update/integration logic. > So what should happen on initial clone, For 'add', clone the command line URL and create a new branch 'master' pointing at the commit referenced by the remote's HEAD (or other branch with --branch). For 'update', do the same, except use a local-branch setting to determine the name for the local branch, falling back to 'master' if it is not set. > later updates, The same thing that currently happens, with the exception tha
Re: [BUG] "git rebase": fatal: Not a valid object name: ''
On Thu, 09 Jan 2014 15:56:21 +, John Keeping wrote:
...
> I think the correct fix is to change the "$switch_to" in the call to
> "git merge-base --fork-point" to "${switch_to:-HEAD}", but I'm not at a
> machine where I can test that or work up a patch at the moment...
Thanks, looks plausible and works. Need to catch train myself now.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
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: [BUG] "git rebase": fatal: Not a valid object name: ''
On Thu, Jan 09, 2014 at 04:36:18PM +0100, Andreas Krey wrote:
> since ad8261d (rebase: use reflog to find common base with upstream)
> a rebase without arguments says "fatal: Not a valid object name: ''",
> caused by trying to determine the fork point with an empty $switch_to.
>
> I don't really see what the appropriate fix would be. :-(
I think the correct fix is to change the "$switch_to" in the call to
"git merge-base --fork-point" to "${switch_to:-HEAD}", but I'm not at a
machine where I can test that or work up a patch at the moment...
--
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
[BUG] "git rebase": fatal: Not a valid object name: ''
Hi, everyone, since ad8261d (rebase: use reflog to find common base with upstream) a rebase without arguments says "fatal: Not a valid object name: ''", caused by trying to determine the fork point with an empty $switch_to. I don't really see what the appropriate fix would be. :-( Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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
[BUG] git symbolic-ref does not recognize @ as the shortcut for HEAD
Hello, In https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.5.txt is mentioned: * Instead of typing four capital letters "HEAD", you can say "@" now, e.g. "git log @". However, `git symbolic-ref @` gives "fatal: No such ref: @", while `git symbolic-ref @` gives "refs/heads/master". I looked around in the archive and #git, but nobody seemed to be aware of the behaviour. I wonder if it's on purpose given the low level of symbolic-ref or if it's a bug. Mathieu Lemoine. -- 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] merge: make merge state available to prepare-commit-msg hook
Jonathan Nieder writes: > Matthieu Moy wrote: > >> Jonathan's answer is an option. Another one is > [...] >> So if the cleanup goes wrong, one can notice. > > test_when_finished also makes the test fail if the cleanup failed. Yes, I was mentionning it as opposed to "throwing the code at the toplevel of the shell", not as opposed to test_when_finished. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 v2 2/4] t7505: ensure cleanup after hook blocks merge
Ryan Biesemeyer writes:
> + test_when_finished "git merge --abort" &&
> + (
> + git checkout -B other HEAD@{1} &&
Weird indentation (space/tab mix).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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 5/5] implement @{publish} shorthand
From: "Jeff King"
Sent: Wednesday, January 08, 2014 9:37 AM
In a triangular workflow, you may have a distinct
@{upstream} that you pull changes from, but publish by
default (if you typed "git push") to a different remote (or
a different branch on the remote).
One of the broader issues is the lack of _documenation_ about what the
'normal' naming convention is for the uspstream remote. Especially the
implicit convention used within our documentation (and workflow).
This is especially true for github users who will normally fork a repo
of interest and then clone it from their own copy/fork. This means that
the 'origin' remote is _not_ the upstream. See
https://help.github.com/articles/fork-a-repo In my case 'origin' is my
publish repo (as suggested by Github) while 'junio' is the upstream (as
do some others). There are similar results from the likes of
Stackoverflow.
Much of the earlier discussion did appear to be as much a confusion over
terminology as that of coding a suitable solution ro Ram's original
forked-from issue.
I know it's been an issue I've had for some while
http://thread.gmane.org/gmane.comp.version-control.git/194175/focus=195385
Philip
--
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: [RFC v2] submodule: Respect requested branch on all clones
Am 09.01.2014 02:09, schrieb Francesco Pretto: > 2014/1/9 W. Trevor King : >> >> However, submodule..local-branch has nothing to do with remote >> repositories or tracking branches. > > My bad: this means the feature is still not entirely clear to me. > >> >> [branch "my-feature"] >> remote = origin >> merge = refs/heads/my-feature >> [submodule "submod"] >> local-branch = "my-feature" >> >> and I don't think Git's config supports such nesting. >> > > Aesthetically, It doesn't look very nice. And I'm not sure we even need that. What's wrong with having the branch setting in the .gitmodules file of the my-feature branch? The only problem I can imagine is accidentally merging that into a branch where that isn't set, but that could be solved by a merge helper for the .gitmodules file. >> I can resuscitate that if folks want, but Heiko felt that my initial >> consolidation didn't go far enough [2]. If it turns out that we're ok >> with the current level of consolidation, would you be ok with >> "non-checkout submodule..update" as the trigger [3]? > > For me it was ok with what you did: > - > if "just_cloned" and "config_branch" > then > !git reset --hard -q" > fi > - > > So yes: at the first clone 'checkout' keeps attached HEAD, while > 'merge' and 'rebase' attach to the branch. It have the impression that attaching the head to the given branch for merge and rebase might be the sensible thing to do, but it would be great to hear from users of merge and rebase if that would break anything for them in their current use cases for these settings. > If it's not the first clone, you should take no action (and your > original patch was ok about this). I'm not sure this is the right thing to do, after all you configured git to follow that branch so I'd expect it to be updated later too, no? Otherwise you might end up with an old version of your branch while upstream is a zillion commits ahead. >> I think >> that adding a halfway step between the current status and full(ish) >> submodule..local-branch support is just going to confuse people > > Well, for now you got some success in confusing me with this "local-branch" :) > > At certain point you may ask maintainers what are the accepted > features (because all these debates should be about getting, or not > getting, endorsement about something) and finalize a patch so people > can further review. First I'd like to see a real consensus about what exactly should happen when a branch is configured to be checked out (and if I missed such a summary in this thread, please point me to it ;-). And we should contrast that to the exact checkout and floating branch use cases. So what should happen on initial clone, later updates, updates where the local and the remote branch diverged, when superproject branches are merged (with and without conflicts), on a rebase in the superproject and so on. After that we can discuss about how to implement them (even though I believe we won't need a new submodule command at the end of this process, simply because if it isn't configurable we cannot teach git checkout and friends to do that automatically for us later). And from reading this discussion I believe we need another value for the ignore option which only ignores changes to the SHA-1 but not to work tree modifications of a submodule work tree relative to its HEAD (or make that two: another one which ignores untracked files too and only shows modification of tracked files). Otherwise users of the floating or attached model can easily miss submodule modifications. -- 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
