* [PATCH 2/2] fetch: Speed up fetch of large numbers of refs
From: Julian Phillips @ 2009-10-22 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091022210444.18084.61685.julian@quantumfyre.co.uk>
When there are large numbers of refs, calling read_ref for each ref is
inefficent (and infact downright slow) - so instead use for_each_ref
to build up a string list of all the refs that we currently have,
which significantly improves the volume.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
builtin-fetch.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index acb08e4..0f53cbd 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -489,7 +489,8 @@ static int add_existing(const char *refname, const unsigned char *sha1,
int flag, void *cbdata)
{
struct string_list *list = (struct string_list *)cbdata;
- string_list_insert(refname, list);
+ struct string_list_item *item = string_list_insert(refname, list);
+ item->util = (void *)sha1;
return 0;
}
@@ -606,9 +607,14 @@ static void check_not_current_branch(struct ref *ref_map)
static int do_fetch(struct transport *transport,
struct refspec *refs, int ref_count)
{
+ struct string_list existing_refs = { NULL, 0, 0, 0 };
+ struct string_list_item *peer_item = NULL;
struct ref *ref_map;
struct ref *rm;
int autotags = (transport->remote->fetch_tags == 1);
+
+ for_each_ref(add_existing, &existing_refs);
+
if (transport->remote->fetch_tags == 2 && tags != TAGS_UNSET)
tags = TAGS_SET;
if (transport->remote->fetch_tags == -1)
@@ -631,8 +637,13 @@ static int do_fetch(struct transport *transport,
check_not_current_branch(ref_map);
for (rm = ref_map; rm; rm = rm->next) {
- if (rm->peer_ref)
- read_ref(rm->peer_ref->name, rm->peer_ref->old_sha1);
+ if (rm->peer_ref) {
+ peer_item = string_list_lookup(rm->peer_ref->name,
+ &existing_refs);
+ if (peer_item)
+ hashcpy(rm->peer_ref->old_sha1,
+ peer_item->util);
+ }
}
if (tags == TAGS_DEFAULT && autotags)
--
1.6.5.rc2
^ permalink raw reply related
* feature "git tag -r" to show tags and commits they are pointing to
From: Eugene Sajine @ 2009-10-22 21:24 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
Currently there is no way you can get the commits your tags are
pointing to by using git tag.
The only way i found is to use rev-parse (which is by the way not
supported by the bash_completion)
It seems reasonable to have upper level command like:
$ git tag -r
to output
v0.1 8794hke84f9e8h9ef9eh949793...
v0.2 jhkd934398e9f499f47w9789o97...
$ git tag -n -r
v0.1 "super message" 8794hke84f9e8h9ef9eh949793...
v0.2 "another message" jhkd934398e9f499f47w9789o9f...
$ git tag -r v0.2
v0.2 jhkd934398e9f499f47w9789o9f...
What do you think?
Thanks,
Eugene
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-22 21:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
2009/10/22 Howard Miller <howard@e-learndesign.co.uk>:
>> You can use either "git merge --squash" or "git rebase --interactive"
>> (changing 'pick' to 'squash').
>>
>
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
>
> Thanks again
>
Oh..... more reading of the help. It's this I take it...
" For example, if you want to reorder the last 5 commits, such that
what was HEAD~4 becomes the new HEAD. To achieve that, you
would call git-rebase like this:
$ git rebase -i HEAD~5"
Would it be ungrateful to suggest that the existence of that option
isn't clear from the synopsis at the start of the help? :-) I guess
I can put the SHA1 identifier of the first commit in my branch too?
Anyway, I'll go and try it and see what happens.
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Junio C Hamano @ 2009-10-22 21:35 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910221424n220449b9vda26f032174b6fa7@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Hi,
>
> Currently there is no way you can get the commits your tags are
> pointing to by using git tag.
> The only way i found is to use rev-parse (which is by the way not
> supported by the bash_completion)
>
> It seems reasonable to have upper level command like:
>
> $ git tag -r
>
> to output
>
> v0.1 8794hke84f9e8h9ef9eh949793...
> v0.2 jhkd934398e9f499f47w9789o97...
>
> $ git tag -n -r
>
> v0.1 "super message" 8794hke84f9e8h9ef9eh949793...
> v0.2 "another message" jhkd934398e9f499f47w9789o9f...
>
> $ git tag -r v0.2
> v0.2 jhkd934398e9f499f47w9789o9f...
>
>
> What do you think?
Not intereseted at all, as this does not look anything more than "because
I could", not "because this is useful and sorely lacking".
The "super message" and such are actually useful to humans, but "v0.1" is
much more useful than 8794hke to humans, and these tag names are just as
usable as the hexadecimal commit object names to the tools. You can say
"git show v0.1^0" and "git show 8794hke" and get the same thing.
Heck, "8794hke" is not even hexadecimal, and the fact that you did not
even notice it is a _S*RE_ sign that they are not useful to humans.
If you _are_ a human, that is ;-)
In other words, please do not justify such a proposal with "I want to have
'git tag' command to show the commit object name". Rather, justify _why_
(1) you _need_ to show the commit object name to begin with, and (2) the
output _has_ to come from 'git tag' and not 'git rev-parse'.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Junio C Hamano @ 2009-10-22 21:42 UTC (permalink / raw)
To: skillzero
Cc: Nguyen Thai Ngoc Duy, Jakub Narebski, Junio C Hamano,
Git Mailing List
In-Reply-To: <2729632a0910220831x4b67021eg772abc8b751ef7e5@mail.gmail.com>
skillzero@gmail.com writes:
> Just an FYI, but I've been using this series for a while. I'm actually
> relying on sparse support in our internal build system (via my private
> build with this series) so I hope it doesn't go away :) I haven't
> really noticed any problems (I thought the index state got out of sync
> once, but I couldn't reproduce the problem later). Here's some
> feedback though:
> ...
> That said, the current level of sparse support provided by this series
> is good enough for me because I can build my own scripts like this on
> top of it to automate things.
Thanks for sharing. It is the best approach to start by adding minimum
core level support and then to let people (like you) with real-world needs
to experiment with custom wrapper scripts, to figure out what user-level
concepts and workflows work and useful (and what don't and aren't), and
what additional core level features is helpful to support them. Over
time, successful custom wrappers will become the best-current-practice and
can be folded back into the mainline, and everybody will benefit.
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Jakub Narebski @ 2009-10-22 21:57 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
On Thu, 22 Oct 2009, Howard Miller wrote:
> > You can use either "git merge --squash" or "git rebase --interactive"
> > (changing 'pick' to 'squash').
> >
>
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
Actually using "git merge --squash" is a bit different from using
"git rebase --interactive".
1. "git merge --squash"
>From documentation:
--squash::
Produce the working tree and index state as if a real
merge happened (except for the merge information),
but do not actually make a commit or
move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
cause the next `git commit` command to create a merge
commit. This allows you to create a single commit on
top of the current branch whose effect is the same as
merging another branch (or more in case of an octopus).
This means for example if you did your changes on a separate
topic branch, and you want to merge your changes into 'master'
branch, you would do
$ git checkout master
$ git merge side-branch
which would result in the following history:
---*---*---*---*---*---*---*---M <-- master
\ /
\-.---.---.---.---.---.-/ <-- side-branch
If you used '--squash' option to git-merge, because changes were
made in throwaway topic branch, and as you said only final result
matter, you would get:
$ git checkout master
$ git merge --squash side-branch
---*---*---*---*---*---*---*---M' <-- master
\
\-.---.---.---.---.---. <-- side-branch
where commit M' has the same contents (the same tree) as commit M
in previous example, but is not a merge commit.
If you simply want to squash last say 5 commits into one, you can
use "git merge --squash" for it in the following way:
$ git reset --hard HEAD~5
$ git merge --squash --no-ff HEAD@{1}
which means basically: rewind to state 5 commits back, then merge
in changes from before rewind, squashing them. The --no-ff is needed
because otherwise it would be fast-forward and no commit would be
created.
2. "git rebase --interactive"
The interactive rebase is meant to edit commits being rebased, but
it can be used simply to edit commits. It includes 'squash' command
that can be used to concatenate (squash) commits.
So to squash last say 5 commits into one, you would use
$ git rebase --interactive HEAD~5
then edit provided list of commands and commits to read something like
this:
pick deadbee The oneline of this commit
squash fa1afe1 The oneline of the next commit
...
squash beedead The oneline of the that commit
i.e. replace 'pick' command by 'squash' command.
This is a very powerfull command, and can be used for example to turn
series of say 5 commits into series of say 2 commits; not simply squashing
to a single commit, but reducing number of commits (and presumably
cleaning up those commits).
HTH (hope that helps)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: requesting info page (and pdf) doc releases
From: Rustom Mody @ 2009-10-22 22:13 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git
In-Reply-To: <4AE0C362.3030900@gentoo.org>
On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>
> hi there!
>
>
> would be nice to get info pages (and pdf) doc releases in addition to
> html and man pages. i imagine such a change to the release machine
> should not be too hard to integrate. we could use it in gentoo.
>
> thanks,
>
>
>
> sebastian
+1
Why only gentoo? I would use it on ubuntu or windows as well
^ permalink raw reply
* Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given
From: Junio C Hamano @ 2009-10-22 22:26 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: git, Clemens Buchacher, Bjorn Steinbrink, Daniel Barkalow,
Thomas Rast
In-Reply-To: <20091022192145.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> the change breaks --squash to merge a branch, doesn't it?
>
> % git checkout feature # from your master branch
> % work; git commit; work; git commit
> % git checkout master # go back to your master branch
> % git merge --squash feature
>
> This is a useful way to clean up changes that were built
> in small steps that turned out to be worth only a commit.
Incidentally we seemed to have seen an end user request for exactly this
workflow.
A reroll has been queued, as below, with an update to a test script that
expects --no-commit to be a no-op for fast-forward.
-- >8 --
Traditionally "git merge --no-commit" meant just that: do not create a new
commit even when a merge succeeds. But this leads to confusion when the
merged commit is a descendant of the current commit, in which case we
succeed the merge by fast-forwarding and without creating a new commit.
Also when the merged commit is already a part of the history, we succeeded
without doing anything.
Error out when --no-commit is given but the merge would result in a
fast-forward or an up-to-date.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-merge.c | 11 +++++++++++
t/t7600-merge.sh | 4 +---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..2149aed 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -829,6 +829,12 @@ static int evaluate_result(void)
return cnt;
}
+static void check_no_commit(const char *msg)
+{
+ if (!option_commit)
+ die("The merge will %s but --no-commit was given.", msg);
+}
+
int cmd_merge(int argc, const char **argv, const char *prefix)
{
unsigned char result_tree[20];
@@ -996,6 +1002,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* If head can reach all the merge then we are up to date.
* but first the most common case of merging one remote.
*/
+ check_no_commit("be a no-op because you are up-to-date");
finish_up_to_date("Already up-to-date.");
return 0;
} else if (allow_fast_forward && !remoteheads->next &&
@@ -1006,6 +1013,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
struct object *o;
char hex[41];
+ if (allow_fast_forward && !squash)
+ check_no_commit("fast forward");
+
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
if (verbosity >= 0)
@@ -1074,6 +1084,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
if (up_to_date) {
+ check_no_commit("be a no-op because you are up-to-date");
finish_up_to_date("Already up-to-date. Yeeah!");
return 0;
}
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index e5b210b..86b0537 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -265,9 +265,7 @@ test_debug 'gitk --all'
test_expect_success 'merge c0 with c1 (no-commit)' '
git reset --hard c0 &&
- git merge --no-commit c1 &&
- verify_merge file result.1 &&
- verify_head $c1
+ test_must_fail git merge --no-commit c1
'
test_debug 'gitk --all'
--
1.6.5.1.124.g746fb6
^ permalink raw reply related
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-22 22:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Thomas Rast, Eugene Sajine, git
In-Reply-To: <81b0412b0910220940n78ddb774i30338147327b198a@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> These are quite verbose. Could they be conditional on something like
> advice.describeHints?
Concurred. Please make it so.
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: A Large Angry SCM @ 2009-10-22 22:20 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Stephen Boyd, Junio C Hamano, git, Kirill Smelkov,
Shawn O. Pearce
In-Reply-To: <fabb9a1e0910221011r957246dx3162cd675ff16800@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
>> Junio C Hamano wrote:
>>> * ks/precompute-completion (2009-10-05) 1 commit.
>>> (merged to 'next' on 2009-10-14 at adf722a)
>>> + Speedup bash completion loading
>>>
>>> Are people happy with this?
>> No. I now have rebase.sh, am.sh, etc. in my completion
>
> I would really like it if running 'make && make install' in git.git
> would also build the completion script, I don't want to have to
> remember to run 'cd contrib/completion && make' every time we get new
> completion options :P.
>
Please do not for completion on those that did not ask for it.
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Johannes Schindelin @ 2009-10-22 23:07 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Sverre Rabbelier, Stephen Boyd, Junio C Hamano, git,
Kirill Smelkov, Shawn O. Pearce
In-Reply-To: <4AE0DAB3.1030103@gmail.com>
Hi,
On Thu, 22 Oct 2009, A Large Angry SCM wrote:
> Sverre Rabbelier wrote:
> > Heya,
> >
> > On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
> > > Junio C Hamano wrote:
> > > > * ks/precompute-completion (2009-10-05) 1 commit.
> > > > (merged to 'next' on 2009-10-14 at adf722a)
> > > > + Speedup bash completion loading
> > > >
> > > > Are people happy with this?
> > > No. I now have rebase.sh, am.sh, etc. in my completion
> >
> > I would really like it if running 'make && make install' in git.git
> > would also build the completion script, I don't want to have to
> > remember to run 'cd contrib/completion && make' every time we get new
> > completion options :P.
> >
>
> Please do not for completion on those that did not ask for it.
It is about installing git-completion.bash, AFAICT, not about forcing your
shell into loading them by default. IOW something I wished for already in
Feb 2008, but was unable to convince anybody of.
Ciao,
Dscho
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: A Large Angry SCM @ 2009-10-22 23:05 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, Shawn O. Pearce, Junio C Hamano, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <fabb9a1e0910221556s694a344ag8e5ae07c35351ee4@mail.gmail.com>
Sverre Rabbelier wrote:
> How am i forcing completion on those that did not ask for it? Nothing
> changes compared to the old situation....
>
>> On Oct 22, 2009 5:20 PM, "A Large Angry SCM" <gitzilla@gmail.com
>> <mailto:gitzilla@gmail.com>> wrote:
>>
>> Sverre Rabbelier wrote: > > Heya, > > On Thu, Oct 22, 2009 at 03:34,
>> Stephen Boyd <bebarino@gmail.co...
>>
>> Please do not for completion on those that did not ask for it.
>
Your original email included 'make && make install'; it's the "make
install" part I'm concerned about.
^ permalink raw reply
* Git 1.6.5.1 for Windows
From: Johannes Schindelin @ 2009-10-22 23:29 UTC (permalink / raw)
To: msysgit, git
Git Release Notes (Git-1.6.5.1-preview20091022)
Last update: 22 October 2009
Find it at http://code.google.com/p/msysgit/downloads/list
These release notes describe issues specific to the Windows release.
General release notes covering the history of the core git commands are
included in the subdirectory doc/git/html of the installation directory.
Look for files starting with RelNotes.
Known issues
- Some commands are not yet supported on Windows and excluded from the
installation; namely: git archimport, git cvsexportcommit, git cvsimport,
git cvsserver, git instaweb, git shell.
- The Logitec QuickCam software can cause spurious crashes. See "Why does
make often crash creating a sh.exe.stackdump file when I try to compile my
source code?" on the MinGW Wiki
(http://www.mingw.org/wiki/Environment_issues)
- The Quick Launch icon will only be installed for the user running setup
(typically the Administrator). This is a technical restriction and will
not change.
- Git Bash launched through the Explorer shell extension does not have the
git icon in its taskbar. This is a technical restriction and will not
change.
- curl uses $HOME/_netrc instead of $HOME/.netrc.
- If you want to specify a different location for --upload-pack, you have to
start the absolute path with two slashes. Otherwise MSys will mangle the
path.
- git and bash have serious problems with non-ASCII file names (Issue 80,
159).
- If configured to use plink, you will have to connect with putty first and
accept the host key.
- When run from cmd.exe instead of Git Bash, some characters seem to be
"swallowed" from Git's output (Issue 192).
- There are a spurious write errors during rebase (Issue 200) that seem not
to be reproducible on most computers.
- As merge tools are executed using the MSys bash, options starting with "/"
need to be handled specially: MSys would interpret that as a POSIX path,
so you need to double the slash (Issue 226). Example: instead of "/base",
say "//base". Also, extra care has to be paid to pass Windows programs
Windows paths, as they have no clue about MSys style POSIX paths -- You can
use something like $(cmd //c echo "$POSIXPATH").
Changes since Git-1.6.4-preview20090729
New Features
- Comes with official git 1.6.5.1.
- Thanks to Johan 't Hart, files and directories starting with a single dot
(such as '.git') will now be marked hidden (you can disable this setting
with core.hideDotFiles=false in your config) (Issue 288).
- Thanks to Thorvald Natvig, Git on Windows can simulate symbolic links by
using reparse points when available. For technical reasons, this only
works for symbolic links pointing to files, not directories.
- A lot of work has been put into making it possible to compile Git's source
code (the part written in C, of course, not the scripts) with Microsoft
Visual Studio. This work is ongoing.
- Thanks to Sebastian Schuberth, we only offer the (Tortoise)Plink option in
the installer if the presence of Plink was detected and at least one Putty
session was found (Issue 319).
- Thanks to Sebastian Schuberth, the installer has a nicer icon now.
Bugfixes
- Thanks to Sebastian Schuberth, git svn picks up the SSH setting specified
with the installer (Issue 305).
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Nicolas Pitre @ 2009-10-23 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Thomas Rast, Eugene Sajine, git
In-Reply-To: <7v63a7f4ka.fsf@alter.siamese.dyndns.org>
On Thu, 22 Oct 2009, Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > These are quite verbose. Could they be conditional on something like
> > advice.describeHints?
>
> Concurred. Please make it so.
I don't have a strong opinion either ways, but is having a less verbose
message in the _error_ path really a big issue?
Nicolas
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-23 0:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: Eugene Sajine, git
In-Reply-To: <f1e86b9095d63c6541d0a8df6a1cf8eadfe247bb.1256226187.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> @@ -259,7 +260,14 @@ static void describe(const char *arg, int last_one)
> printf("%s\n", find_unique_abbrev(sha1, abbrev));
> return;
> }
> - die("cannot describe '%s'", sha1_to_hex(sha1));
> + if (unannotated_cnt)
> + die("cannot describe '%s'"
> + " with only\nannotated tags. Try --tags.",
Did you mean UNannotated tags here?
> + sha1_to_hex(sha1));
> + else
> + die("cannot describe '%s'"
> + " with tags\nTry --always, or create some tags.",
> + sha1_to_hex(sha1));
> }
>
> qsort(all_matches, match_cnt, sizeof(all_matches[0]), compare_pt);
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-23 0:28 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Thomas Rast, Eugene Sajine, git
In-Reply-To: <alpine.LFD.2.00.0910222011200.21460@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Thu, 22 Oct 2009, Junio C Hamano wrote:
>
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>> > These are quite verbose. Could they be conditional on something like
>> > advice.describeHints?
>>
>> Concurred. Please make it so.
>
> I don't have a strong opinion either ways, but is having a less verbose
> message in the _error_ path really a big issue?
Thanks for catching a thinko---I somehow thought the patch was about
warning when we give an annotated tag that is farther than an unannotated
one.
It should be good enough to unconditionally give hints upon an error, as
long as they are correct.
^ permalink raw reply
* Re: confusion with git diff-tree output
From: Jeff King @ 2009-10-23 0:54 UTC (permalink / raw)
To: David Roundy; +Cc: git
In-Reply-To: <117f2cc80910211523m5c1399aej594398fb6597e5de@mail.gmail.com>
On Wed, Oct 21, 2009 at 06:23:08PM -0400, David Roundy wrote:
> You're right. I figured I must be overlooking something obvious, and
> that was it. What surprised me was that -p implies -r, which is not
> documented. Since the -p output was recursive, I incorrectly presumed
> that this was the default.
It's due to hysterical raisins:
http://article.gmane.org/gmane.comp.version-control.git/54078
-Peff
^ permalink raw reply
* Re: [RFC PATCH] git-gui: Allow staging multiple lines at once
From: Jeff Epler @ 2009-10-23 1:53 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Shawn O. Pearce
In-Reply-To: <20091022195116.GB3944@book.hvoigt.net>
On Thu, Oct 22, 2009 at 09:51:16PM +0200, Heiko Voigt wrote:
> Tested it and it works like a charm. I will include Shawn in the CC: so
> he can comment.
Thanks, but don't miss the v2 patch:
http://thread.gmane.org/gmane.comp.version-control.git/130968
this fixes a bug staging line(s) followed only by deletions.
Jeff
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Eugene Sajine @ 2009-10-23 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5svf6x9.fsf@alter.siamese.dyndns.org>
Please, disregard...
I was looking for this info in order to create second tag for the same
commit. For example if the first tag created by somebody or
automatically (CI, release system), so i could add a verbose tag.
But i just realized that i don't need commit id for that - just tag
the tag, stupid...
Thanks,
Eugene
On 10/22/09, Junio C Hamano <gitster@pobox.com> wrote:
> Eugene Sajine <euguess@gmail.com> writes:
>
>> Hi,
>>
>> Currently there is no way you can get the commits your tags are
>> pointing to by using git tag.
>> The only way i found is to use rev-parse (which is by the way not
>> supported by the bash_completion)
>>
>> It seems reasonable to have upper level command like:
>>
>> $ git tag -r
>>
>> to output
>>
>> v0.1 8794hke84f9e8h9ef9eh949793...
>> v0.2 jhkd934398e9f499f47w9789o97...
>>
>> $ git tag -n -r
>>
>> v0.1 "super message" 8794hke84f9e8h9ef9eh949793...
>> v0.2 "another message" jhkd934398e9f499f47w9789o9f...
>>
>> $ git tag -r v0.2
>> v0.2 jhkd934398e9f499f47w9789o9f...
>>
>>
>> What do you think?
>
> Not intereseted at all, as this does not look anything more than "because
> I could", not "because this is useful and sorely lacking".
>
> The "super message" and such are actually useful to humans, but "v0.1" is
> much more useful than 8794hke to humans, and these tag names are just as
> usable as the hexadecimal commit object names to the tools. You can say
> "git show v0.1^0" and "git show 8794hke" and get the same thing.
>
> Heck, "8794hke" is not even hexadecimal, and the fact that you did not
> even notice it is a _S*RE_ sign that they are not useful to humans.
>
> If you _are_ a human, that is ;-)
>
> In other words, please do not justify such a proposal with "I want to have
> 'git tag' command to show the commit object name". Rather, justify _why_
> (1) you _need_ to show the commit object name to begin with, and (2) the
> output _has_ to come from 'git tag' and not 'git rev-parse'.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Jeff King @ 2009-10-23 2:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: Björn Steinbrink, Daniel Barkalow, Sean Estabrooks, git
In-Reply-To: <200910211005.29053.trast@student.ethz.ch>
On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote:
> What if any combination of fetch and merge always gave you the long
> form? After all, even if you do have a tracking branch for whatever
> you are merging, that information is probably useless and it would be
> nicer if all of the following resulted in the long form:
>
> * git fetch git://git.kernel.org/pub/scm/git/git pu
> git merge FETCH_HEAD
>
> * git remote add origin git://git.kernel.org/pub/scm/git/git
> git fetch origin
> git merge origin/pu
>
> * git fetch git://git.kernel.org/pub/scm/git/git pu:tmp
> git merge tmp
Maybe it's just me, but I actually prefer the shorthand names. Five
years from now when I browse the history and see that I merged
remote branch "mike/topic", I'll know exactly what that means: developer
Mike's version of a certain topic branch. But I am not likely to care
about exactly where we were storing developer repos at that time.
But probably that is an artifact of the workflow. The scenario I am
describing above implies a somewhat centralized workflow, where the
shorthand contains all of the interesting information. In a totally
distributed, we-don't-share-anything-except-the-url-namespace setup of
an open source repo, the full URL makes more sense.
So maybe it is something that should be optional.
-Peff
>
> and so on.
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Daniel Barkalow @ 2009-10-23 3:43 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Björn Steinbrink, Sean Estabrooks, git
In-Reply-To: <20091023025434.GA29908@sigio.peff.net>
On Thu, 22 Oct 2009, Jeff King wrote:
> On Wed, Oct 21, 2009 at 10:05:27AM +0200, Thomas Rast wrote:
>
> > What if any combination of fetch and merge always gave you the long
> > form? After all, even if you do have a tracking branch for whatever
> > you are merging, that information is probably useless and it would be
> > nicer if all of the following resulted in the long form:
> >
> > * git fetch git://git.kernel.org/pub/scm/git/git pu
> > git merge FETCH_HEAD
> >
> > * git remote add origin git://git.kernel.org/pub/scm/git/git
> > git fetch origin
> > git merge origin/pu
> >
> > * git fetch git://git.kernel.org/pub/scm/git/git pu:tmp
> > git merge tmp
>
> Maybe it's just me, but I actually prefer the shorthand names. Five
> years from now when I browse the history and see that I merged
> remote branch "mike/topic", I'll know exactly what that means: developer
> Mike's version of a certain topic branch. But I am not likely to care
> about exactly where we were storing developer repos at that time.
>
> But probably that is an artifact of the workflow. The scenario I am
> describing above implies a somewhat centralized workflow, where the
> shorthand contains all of the interesting information. In a totally
> distributed, we-don't-share-anything-except-the-url-namespace setup of
> an open source repo, the full URL makes more sense.
>
> So maybe it is something that should be optional.
Surely you ought to be able to get the short form with "pull", though, if
you happen to like short forms. So it would make sense to decide how to
format the merge message based entirely on an option, not at all on
whether you use pull or fetch+merge.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git svn: fix fetch where glob is on the top-level URL
From: Eric Wong @ 2009-10-23 4:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Adam Brewster, Daniel Cordero, git
In-Reply-To: <20091021144113.GA7440@cumin>
>From 3abaf9fdf216fd0307bb9e9f03772bd80a64177c Mon Sep 17 00:00:00 2001
From: Adam Brewster <adambrewster@gmail.com>
Date: Thu, 22 Oct 2009 21:26:32 -0700
Subject: [PATCH] git svn: fix fetch where glob is on the top-level URL
In cases where the top-level URL we're tracking is the path we
glob against, we can once again track odd repositories that keep
branches/tags at the top level. This regression was introduced
in commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d.
Additionally, the leading slash is now optional when tracking
the top-level path to be consistent with non-top-level paths.
We now allow both of the following "branches" in [svn-remote
"foo"] sections of $GIT_CONFIG:
; with a leading slash (this worked before 6f5748e1)
branches = /*:refs/remotes/*
; now it it also works without a leading slash
branches = *:refs/remotes/*
Thanks to Daniel Cordero for the original bug report and
bisection.
[ew: commit message]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Daniel Cordero <theappleman@gmail.com> wrote:
> Hello,
>
> when trying to clone a svn repo with the command-line:
>
> $ git svn clone -b / http://svn.collab.net/repos/svn/
>
> (that is, each folder in the root of the repo should be considered it's
> own branch)
> the clone sometimes[1] fails saying:
>
> ref: 'refs/remotes/' ends with a trailing slash, this is not permitted by git nor Subversion
>
> The offending config is:
> [svn-remote "svn"]
> url = http://svn.collab.net/repos/svn
> branches = /*:refs/remotes/*
>
>
> This used to work in the past; I bisected the bad commit to
>
> commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
> Author: Adam Brewster <adambrewster@gmail.com>
> Date: Tue Aug 11 23:14:03 2009 -0400
>
> svn: allow branches outside of refs/remotes
>
>
> Thanks in advance.
>
>
> [1] It does work when the URL has at least 1 folder of depth
> (e.g. suffix "trunk" to the above URL).
>
> Its config section is:
> [svn-remote "svn"]
> url = http://svn.collab.net/repos/svn
> branches = trunk//*:refs/remotes/*
>
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..2e9a720 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1768,7 +1768,7 @@ sub read_all_remotes {
my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=$svn_refspec$!) {
- my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
+ my ($remote, $local_ref, $remote_ref) = ($1, "/$2", $3);
die("svn-remote.$remote: remote ref '$remote_ref' "
. "must start with 'refs/'\n")
unless $remote_ref =~ m{^refs/};
@@ -1780,7 +1780,7 @@ sub read_all_remotes {
$r->{$1}->{url} = $2;
} elsif (m!^(.+)\.(branches|tags)=$svn_refspec$!) {
my ($remote, $t, $local_ref, $remote_ref) =
- ($1, $2, $3, $4);
+ ($1, $2, "/$3", $4);
die("svn-remote.$remote: remote ref '$remote_ref' ($t) "
. "must start with 'refs/'\n")
unless $remote_ref =~ m{^refs/};
@@ -1980,7 +1980,7 @@ sub find_ref {
foreach (command(qw/config -l/)) {
next unless m!^svn-remote\.(.+)\.fetch=
\s*/?(.*?)\s*:\s*(.+?)\s*$!x;
- my ($repo_id, $path, $ref) = ($1, $2, $3);
+ my ($repo_id, $path, $ref) = ($1, "/$2", $3);
if ($ref eq $ref_id) {
$path = '' if ($path =~ m#^\./?#);
return ($repo_id, $path);
--
Eric Wong
^ permalink raw reply related
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-23 5:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200910222357.15189.jnareb@gmail.com>
2009/10/22 Jakub Narebski <jnareb@gmail.com>:
> On Thu, 22 Oct 2009, Howard Miller wrote:
>
>> > You can use either "git merge --squash" or "git rebase --interactive"
>> > (changing 'pick' to 'squash').
>> >
>>
>> Actually thinking some more.... I don't understand something about
>> this. I don't actually want to merge or rebase with anything. I just
>> want to say "make those commits a series of commits on a branch into
>> just one commit with a new message". I seriously suspect I'm missing
>> the point somewhere but what has that got to do with merging or
>> rebasing?
>
> Actually using "git merge --squash" is a bit different from using
> "git rebase --interactive".
>
>
> 1. "git merge --squash"
>
> From documentation:
>
> --squash::
> Produce the working tree and index state as if a real
> merge happened (except for the merge information),
> but do not actually make a commit or
> move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
> cause the next `git commit` command to create a merge
> commit. This allows you to create a single commit on
> top of the current branch whose effect is the same as
> merging another branch (or more in case of an octopus).
>
> This means for example if you did your changes on a separate
> topic branch, and you want to merge your changes into 'master'
> branch, you would do
>
> $ git checkout master
> $ git merge side-branch
>
> which would result in the following history:
>
>
> ---*---*---*---*---*---*---*---M <-- master
> \ /
> \-.---.---.---.---.---.-/ <-- side-branch
>
>
> If you used '--squash' option to git-merge, because changes were
> made in throwaway topic branch, and as you said only final result
> matter, you would get:
>
> $ git checkout master
> $ git merge --squash side-branch
>
> ---*---*---*---*---*---*---*---M' <-- master
> \
> \-.---.---.---.---.---. <-- side-branch
>
>
> where commit M' has the same contents (the same tree) as commit M
> in previous example, but is not a merge commit.
>
> If you simply want to squash last say 5 commits into one, you can
> use "git merge --squash" for it in the following way:
>
> $ git reset --hard HEAD~5
> $ git merge --squash --no-ff HEAD@{1}
>
> which means basically: rewind to state 5 commits back, then merge
> in changes from before rewind, squashing them. The --no-ff is needed
> because otherwise it would be fast-forward and no commit would be
> created.
>
>
> 2. "git rebase --interactive"
>
> The interactive rebase is meant to edit commits being rebased, but
> it can be used simply to edit commits. It includes 'squash' command
> that can be used to concatenate (squash) commits.
>
> So to squash last say 5 commits into one, you would use
>
> $ git rebase --interactive HEAD~5
>
> then edit provided list of commands and commits to read something like
> this:
>
> pick deadbee The oneline of this commit
> squash fa1afe1 The oneline of the next commit
> ...
> squash beedead The oneline of the that commit
>
> i.e. replace 'pick' command by 'squash' command.
>
> This is a very powerfull command, and can be used for example to turn
> series of say 5 commits into series of say 2 commits; not simply squashing
> to a single commit, but reducing number of commits (and presumably
> cleaning up those commits).
>
>
> HTH (hope that helps)
> --
> Jakub Narebski
> Poland
>
Hi Jakub,
Yes it helps a lot. What I *don't* care about (or want to do) is
actually do a merge or a rebase I just want to change history. Well,
that's what I thought I wanted. What I suppose I really want is the
full history for *me* and a second branch with the 'reduced' history
to push to my client. I suppose that's different yet again?
Howard
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-23 5:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <26ae428a0910222236l58bc64b7l12c4cff09b086dac@mail.gmail.com>
>
> Hi Jakub,
>
> Yes it helps a lot. What I *don't* care about (or want to do) is
> actually do a merge or a rebase I just want to change history. Well,
> that's what I thought I wanted. What I suppose I really want is the
> full history for *me* and a second branch with the 'reduced' history
> to push to my client. I suppose that's different yet again?
>
> Howard
>
Actually, what I should have said in the first place is that this is
specifically nothing to do with the main trunk. We are doing small
custom developments for clients away from the main project
development. So we specifically don't want to merge or rebase with the
master - that's never going to happen. I want to keep the development
branch in tact for my reference, but when I push (the custom
development branch) to the client I need that sanitized. I think I
finally have it clear in my own head now!
Howard
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Johannes Sixt @ 2009-10-23 5:48 UTC (permalink / raw)
To: Howard Miller; +Cc: Jakub Narebski, git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
Howard Miller schrieb:
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
The easiest way (IMHO) to achieve this is certainly:
# start a new branch at the tip of the series
$ git checkout -b all-in-one the-series
# squash 17 commits
$ git reset --soft HEAD~17
$ git commit
Now you have a new branch 'all-in-one' that has the same contents as the
original series 'the-series', but with only one commit:
$ git diff the-series..all-in-one # must show no differences
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox