* Re: [bug][bisected] git-svn with root branches
From: Eric Wong @ 2009-10-22 18:55 UTC (permalink / raw)
To: Adam Brewster; +Cc: Daniel Cordero, git
In-Reply-To: <c376da900910220824g2948dc2sa1156bda59b49405@mail.gmail.com>
Adam Brewster <adambrewster@gmail.com> wrote:
> > > The offending config is:
> > > [svn-remote "svn"]
> > > url = http://svn.collab.net/repos/svn
> > > branches = /*:refs/remotes/*
> > >
> >
> > Reverting the left hand side of these two regexps from Adam's commit
> > seems to fix the problem.
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index eb4b75a..56af221 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -1765,7 +1765,7 @@ sub read_all_remotes {
> > my $use_svm_props = eval { command_oneline(qw/config --bool
> > svn.useSvmProps/) };
> > $use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
> > - my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
> > + 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);
> > @@ -1979,7 +1979,7 @@ sub find_ref {
> > my ($ref_id) = @_;
> > foreach (command(qw/config -l/)) {
> > next unless m!^svn-remote\.(.+)\.fetch=
> > - \s*/?(.*?)\s*:\s*(.+?)\s*$!x;
> > + \s*(.*?)\s*:\s*(.+?)\s*$!x;
> > my ($repo_id, $path, $ref) = ($1, $2, $3);
> > if ($ref eq $ref_id) {
> > $path = '' if ($path =~ m#^\./?#);
> > ---
> >
> > I'm not sure why Adam decided the leading slash needed to be removed for
> > the git refspec. That said, the globbing/branching code still makes me
> > want to hide under a rock and I'm generally afraid to touch it.
> > I'll wait for Adam to chime in since he's braver than I am :)
> >
> >
> How's this for brave: I'm not sure why I did that either.
>
> Looking at it again it seems correct for the leading / to be ignored because
> it has no meaning. What's the difference between the above config and
> "branches = *:refs/remotes/*" (besides the fact that one works and one
> doesn't)? In both cases I think I've asked for all of the top-level
> directories to be branches. But that has nothing to do with the rest of the
> patch, so it shouldn't have been included.
>
> Given all of that I would be more inclined to fix this with something like
> the following:
>
> diff --git a/git-svn.perl b/git-svn.perl
> index eb4b75a..cd8a93b 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);
> --
> 1.6.5.1.63.ga9d7.dirty
>
> That is, continue disregard the / on the actual input because it means
> nothing, and add a / in places where the code will crash if it's not there.
> Even better would be to find out _why_ $path and $local_ref need a leading /
> and fix it that way, but that's more work that I don't have time for right
> now.
Thanks for the feedback Adam,
Yeah, I'm confused by that myself :x /me kicks himself again
> On the other hand it doesn't really matter because git svn init won't accept
> -b '' (to create the configuration I proposed above), so I have no practical
> objection to Eric's solution.
Meanwhile, your patch looks good to me. Let me know if you want write
a commit message for it or if you want me to do it.
I actually tried editing my $GIT_CONFIG in $EDITOR to have a bare '*' as
the ref glob:
[svn-remote "svn"]
url = http://svn.collab.net/repos/svn
branches = *:refs/remotes/*
Since I've tried it, I suspect others may try editing $GIT_CONFIG in the
same way as well.
--
Eric Wong
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Stephen Boyd @ 2009-10-22 18:56 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git, Kirill Smelkov, Shawn O. Pearce
In-Reply-To: <fabb9a1e0910221011r957246dx3162cd675ff16800@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> 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.
Perhaps a top-level completion rule would work? I don't know if building
completion for every user would be appropriate.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Stephen Boyd @ 2009-10-22 19:01 UTC (permalink / raw)
To: Jakub Narebski
Cc: Junio C Hamano, git, Giuseppe Bilotta, Mark Rada, Nick Edelen,
Nguyen Thai Ngoc Duy
In-Reply-To: <m3ljj3es02.fsf@localhost.localdomain>
Jakub Narebski wrote:
>> * sb/gitweb-link-author (2009-10-15) 1 commit
>> - gitweb: linkify author/committer names with search
>>
>> Soon in 'next'.
>>
>
> Is this version that uses title attribute to show that this link is
> different in that it leads to search results, not an action view?
>
Yes.
^ permalink raw reply
* make info failing with asciidoc 8.4.5? (git 1.6.5.1)
From: Sebastian Pipping @ 2009-10-22 19:11 UTC (permalink / raw)
To: git
While asciidoc 8.2.6 works fine for me, with version 8.4.5 I get errors
like this from make info:
ASCIIDOC user-manual.xml
WARNING: [colophon] missing specialsections section
WARNING: [dedication] missing specialsections section
WARNING: [bibliography] missing specialsections section
WARNING: [appendix] missing specialsections section
WARNING: [preface] missing specialsections section
WARNING: [glossary] missing specialsections section
WARNING: [index] missing specialsections section
FAILED: [listdef-bulleted] missing section: [listtags-None]
make: *** [user-manual.xml] Error 1
Thought you might want to know.
Sebastian
^ permalink raw reply
* Re: [msysGit] Re: [PATCH v5 0/8] imap-send: Windows support
From: Junio C Hamano @ 2009-10-22 19:20 UTC (permalink / raw)
To: Johannes Sixt
Cc: Johannes Schindelin, msysgit, Erik Faye-Lund, git, Erik Faye-Lund
In-Reply-To: <200910222011.02737.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Donnerstag, 22. Oktober 2009, Johannes Schindelin wrote:
>> If there are no objections, I will apply them tomorrow.
>
> The series is already in pu (FYI),...
Please don't mind me; if msysgit people are happy with this series that
affects only msysgit, I would be a lot happier to get a pull request to
merge them with Acks and Sign-offs from you guys directly into 'master',
rather than me shepherding the series from 'pu' down to 'master'.
^ permalink raw reply
* Updating a branch.
From: elyod72 @ 2009-10-22 19:21 UTC (permalink / raw)
To: git
I am a newbie to git, so please bear with me.
Here is the scenario that I am struggling with:
I have my Master branch.
I then create a new branch named Test.
I then make changes and additions to the test branch.
At the same time I make changes to the Master branch.
Now I want to update the Test branch with the latest information from the
Master branch.
How do I go about doing that?
Thanks for you time and help.
--
View this message in context: http://www.nabble.com/Updating-a-branch.-tp26015707p26015707.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
From: Jari Aalto @ 2009-10-22 19:25 UTC (permalink / raw)
To: git
In-Reply-To: <4AE0A961.7040900@gmail.com>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/merge-options.txt | 88 ++++++++++++++++++++-------------------
1 files changed, 45 insertions(+), 43 deletions(-)
Stephen Boyd <bebarino@gmail.com> writes:
>> + controlled by the configuration option merge.stat.
>> +
>> + With -n or --no-stat do not show a diffstat at the end of the
>
> I thought we needed a plus before new paragraphs in these situations?
Corrected.
Thanks,
Jari
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index adadf8e..48d04a5 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,43 +1,42 @@
--q::
---quiet::
- Operate quietly.
-
--v::
---verbose::
- Be verbose.
-
---stat::
- Show a diffstat at the end of the merge. The diffstat is also
- controlled by the configuration option merge.stat.
-
--n::
---no-stat::
- Do not show a diffstat at the end of the merge.
+--commit::
+--no-commit::
+ Perform the merge and commit the result. This option can
+ be used to override --no-commit.
++
+With --no-commit perform the merge but pretend the merge
+failed and do not autocommit, to give the user a chance to
+inspect and further tweak the merge result before committing.
---summary::
---no-summary::
- Synonyms to --stat and --no-stat; these are deprecated and will be
- removed in the future.
+--ff::
+--no-ff::
+ Do not generate a merge commit if the merge resolved as
+ a fast-forward, only update the branch pointer. This is
+ the default behavior of git-merge.
++
+With --no-ff Generate a merge commit even if the merge
+resolved as a fast-forward.
--log::
+--no-log::
In addition to branch names, populate the log message with
one-line descriptions from the actual commits that are being
merged.
++
+With --no-log do not list one-line descriptions from the
+actual commits being merged.
---no-log::
- Do not list one-line descriptions from the actual commits being
- merged.
-
---no-commit::
- Perform the merge but pretend the merge failed and do
- not autocommit, to give the user a chance to inspect and
- further tweak the merge result before committing.
---commit::
- Perform the merge and commit the result. This option can
- be used to override --no-commit.
+--stat::
+-n::
+--no-stat::
+ Show a diffstat at the end of the merge. The diffstat is also
+ controlled by the configuration option merge.stat.
++
+With -n or --no-stat do not show a diffstat at the end of the
+merge.
--squash::
+--no-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
@@ -46,19 +45,9 @@
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).
-
---no-squash::
- Perform the merge and commit the result. This option can
- be used to override --squash.
-
---no-ff::
- Generate a merge commit even if the merge resolved as a
- fast-forward.
-
---ff::
- Do not generate a merge commit if the merge resolved as
- a fast-forward, only update the branch pointer. This is
- the default behavior of git-merge.
++
+With --no-squash perform the merge and commit the result. This
+option can be used to override --squash.
-s <strategy>::
--strategy=<strategy>::
@@ -67,3 +56,16 @@
If there is no `-s` option, a built-in list of strategies
is used instead ('git-merge-recursive' when merging a single
head, 'git-merge-octopus' otherwise).
+
+--summary::
+--no-summary::
+ Synonyms to --stat and --no-stat; these are deprecated and will be
+ removed in the future.
+
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
--
1.6.4.3
^ permalink raw reply related
* Re: Updating a branch.
From: Avery Pennarun @ 2009-10-22 19:26 UTC (permalink / raw)
To: elyod72; +Cc: git
In-Reply-To: <26015707.post@talk.nabble.com>
On Thu, Oct 22, 2009 at 3:21 PM, elyod72 <elyod72@gmail.com> wrote:
> I have my Master branch.
> I then create a new branch named Test.
> I then make changes and additions to the test branch.
> At the same time I make changes to the Master branch.
> Now I want to update the Test branch with the latest information from the
> Master branch.
>
> How do I go about doing that?
git checkout Test
git merge Master
^ permalink raw reply
* Re: Re: [RFC] What to you think about a loose status for submodules?
From: Heiko Voigt @ 2009-10-22 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann, Lars Hjemli
In-Reply-To: <7vy6n4339k.fsf@alter.siamese.dyndns.org>
On Wed, Oct 21, 2009 at 01:23:19PM -0700, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
>
> > For such a workflow I would like to implement what I call 'loose'
> > submodules. Where a
> >
> > git clone project.git
> > cd project
> > git submodule init && git submodule update
> >
> > would omit the 'help' folder. But in case I specify it directly like
>
> I thought a blanket "submodule init/update" wasn't even a recommended
> practice for this exact reason. We tried to keep the default not to
> gratuitously populate and checkout all submodule repositories, but
> probably what you are trying to do was made more difficult by mistake
> because people who wanted the other behaviour pushed too hard?
Currently if a project has submodule its either use all submodules or
none. There is nothing in between.
> Defaulting to "do not populate and checkout unless explicitly asked"
> sounds like the right thing to do, and if we broke it, it should be
> corrected, I think. Shouldn't it be a simple matter of teaching "--all"
> option to "submodule init" (and "update") to let them blindly affect all
> submodules, while making the default not to do anything?
Not completely. As said above I want something 'in between' because some
small submodule might be necessary to compile the project. And they are
submodules because they are shared code, so more than one project is
using them. And then there are optional submodules like pugins or
documentation which are not needed for compilation.
> > git config submodule."name".relation tight
>
> I do not think this should be a project-wide configuration that is
> recorded in .gitmodules; if you are "help documentation" participant to
> the project you would want "help" submodule, and other people will want
> different submodules.
>
> It would probably make more sense to introduce the notion of "module
> groups", similar to the way "remote update <group>" can name a group of
> remotes to affect. Then documentation people can say
>
> submodule init doc && submodule update
That makes sense. If I understand it correctly the group definitions
would then be stored in .gitmodules ?
Thinking further we could also name the group definition 'view'. In the
notion of different kind of views for a project. That way a doc
developer would get a set of options which make more sense for him
(thinking about extending this to sparse checkout). But first lets
consider submodules.
> if .gitmodules file records the mapping from "doc" to one or more
> submodules (e.g. "help" and "doc"). If we are going to take this route,
> it would still make sense to teach "--all" to "submodule init" and perhaps
> default to init the "default" group if one exists, instead of making the
> parameterless "init" a no-op as I suggested earlier.
I like this idea.
> But it is quite a long time since I looked at git-submodule.sh so please
> take the above with a healthy dose of salt.
I am not sure what is the best way to create such a group mapping using
our config files though. I would like to allow multiple groups/views to
have the submodules like:
[submodule "doc"]
path = Documentation
views = doc
[submodule "help"]
path = help
views = doc
[submodule "core"]
path = core
views = doc default
[submodule "app"]
path = app
views = default
What do you think?
cheers Heiko
^ permalink raw reply
* Re: [RFC PATCH] git-gui: Allow staging multiple lines at once
From: Heiko Voigt @ 2009-10-22 19:51 UTC (permalink / raw)
To: Jeff Epler; +Cc: git, Shawn O. Pearce
In-Reply-To: <20091019195456.GA11121@unpythonic.net>
On Mon, Oct 19, 2009 at 02:54:57PM -0500, Jeff Epler wrote:
> When applying less than a full hunk, it's still often desirable to apply
> a number of consecutive lines.
>
> This change makes it possible to sweep out a range of lines in the diff view
> with the left mouse button, then right click and "Stage Lines For Commit".
>
> The selected lines may span multiple hunks.
Thanks a lot! Very nice. I've been planning to implement this sometime
myself but never got around it.
Tested it and it works like a charm. I will include Shawn in the CC: so
he can comment.
cheers Heiko
^ permalink raw reply
* Re: [RFC] What to you think about a loose status for submodules?
From: Junio C Hamano @ 2009-10-22 19:58 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann, Lars Hjemli
In-Reply-To: <20091022194446.GA3944@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> I am not sure what is the best way to create such a group mapping using
> our config files though. I would like to allow multiple groups/views to
> have the submodules like:
>
> [submodule "doc"]
> path = Documentation
> views = doc
>
> [submodule "help"]
> path = help
> views = doc
>
> [submodule "core"]
> path = core
> views = doc default
>
> [submodule "app"]
> path = app
> views = default
>
> What do you think?
That, or alternatively:
[submodule "doc"]
path = Documentation
[submodule "help"]
path = help
[submodule "core"]
path = core
[submodule "app"]
path = app
[view "default"]
modules = core app
[view "doc"]
modules = core doc help
Or even (mimicking the way how "git remote" defines remote groups):
[submodule "doc"]
path = Documentation
[submodule "help"]
path = help
[submodule "core"]
path = core
[submodule "app"]
path = app
[submodule]
default = core app
doc = core doc help
^ permalink raw reply
* Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-22 20:03 UTC (permalink / raw)
To: git
Hello,
I have a branch with a whole series of commits. I want to export this
work to be customer (to their svn repo if that has any bearing on it).
All the stuff in the history is irrelevant to my customer ("committing
now, going to bed" etc.) so I'd like to create a new branch that only
has one commit.. the end point with a new message. Is this possible?
Thanks again!
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Bill Lear @ 2009-10-22 20:30 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910221303n493fb7s701269d694110685@mail.gmail.com>
On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>Hello,
>
>I have a branch with a whole series of commits. I want to export this
>work to be customer (to their svn repo if that has any bearing on it).
>All the stuff in the history is irrelevant to my customer ("committing
>now, going to bed" etc.) so I'd like to create a new branch that only
>has one commit.. the end point with a new message. Is this possible?
git rebase is your friend.
Bill
^ permalink raw reply
* Re: Updating a branch.
From: Tim Henigan @ 2009-10-22 20:31 UTC (permalink / raw)
To: elyod72; +Cc: git
In-Reply-To: <26015707.post@talk.nabble.com>
On Thu, Oct 22, 2009 at 3:21 PM, elyod72 <elyod72@gmail.com> wrote:
>
> I am a newbie to git, so please bear with me.
> Here is the scenario that I am struggling with:
>
> I have my Master branch.
> I then create a new branch named Test.
> I then make changes and additions to the test branch.
> At the same time I make changes to the Master branch.
> Now I want to update the Test branch with the latest information from the
> Master branch.
>
> How do I go about doing that?
In general, the following is recommended:
1) If possible, complete your work on the Test branch without merging
the changes. Save your merge (and any potential conflict resolution)
for when the Test branch is complete and fully tested.
2) If Test absolutely requires the changes made in Master, then perform
a "git rebase master" from your Test branch. This operation replays
the commits you have made to Test on top of your latest commit to
Master.
See the gitworkflows man page [1] for further information. The section on
"Topic Branches" should be helpful.
This post [2] on StackOverflow has some helpful info as well.
-Tim
[1] http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
[2] http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Marcus Camen @ 2009-10-22 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <ca433830910161604g5a6bde76n26eb2b1e8155fb36@mail.gmail.com>
On Samstag 17 Oktober 2009, Mark Lodato wrote:
> I just realized I forgot to say something in my last email: THANK
> YOU!!! I have been looking forward to this for a long time. I was
> planning to one day to sit down and start thinking about how to
> implement a smart protocol, and then I see a post saying that not only
> has someone figured out the protocol, but he has implemented it!
> Amazing! This is really crucial for corporate adoption, at least at
> my job. We need to have strong authentication for many users, and the
> SSH key management is just a nightmare, not to mention that not all
> users can SSH due to firewalls. This will save me so much time and
> frustration. Thanks!
As I am using git in a corporate environment I couldn't agree more. smart-
http definitely is the most import addition to git in the last months.
So far I didn't carry out extensive production runs but my first tests
already showed that the smart-http backend solves many problems we have
with the dumb webdav approach (no hooks, insane amount of http requests,
slow performance, ...).
As I have a systems engineer (not a C coder) perspective on git I cannot
comment an any possible glitches of this implementation. I just want to
make sure that everyone recognizes just how import smart-http is for
corporate environments and that the current patch already solves a lot of
problems.
Regards,
Marcus
^ permalink raw reply
* requesting info page (and pdf) doc releases
From: Sebastian Pipping @ 2009-10-22 20:41 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* Detached HEAD and "git log --all"
From: Jakub Narebski @ 2009-10-22 20:37 UTC (permalink / raw)
To: git
When discussing differences between concept and implementation
of branches in Git and in Mercurial on StackOverflow[1] (abusing
SO comment system a bit), Steve Losh[2] wrote that he was surprised
by the fact that "git log --all" doesn't include commits made
on detached HEAD.
While documentation clearly states:
--all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
on the command line as <commit>.
and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
it is nevertheless a bit strange that "git log --all" doesn't list
all (everything).
This is of course only an issue if we are on detached HEAD; I guess
that semantics of `--all` option to git-log predates this feature.
[1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
[2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
--
Jakub Narębski http://stackoverflow.com/users/46058/jakub-narebski
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Bill Lear @ 2009-10-22 20:44 UTC (permalink / raw)
To: Howard Miller, git
In-Reply-To: <19168.49405.775024.649626@lisa.zopyra.com>
On Thursday, October 22, 2009 at 15:30:53 (-0500) Bill Lear writes:
>On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>>Hello,
>>
>>I have a branch with a whole series of commits. I want to export this
>>work to be customer (to their svn repo if that has any bearing on it).
>>All the stuff in the history is irrelevant to my customer ("committing
>>now, going to bed" etc.) so I'd like to create a new branch that only
>>has one commit.. the end point with a new message. Is this possible?
>
>git rebase is your friend.
Someone correct me if I'm wrong.
% git branch
* master
% git checkout -b my_work_branch
% [work work work, commit, commit, commit]
% git rebase -i master
You'll then get an editor buffer that looks like this:
pick 16730c6 baz 0
pick 2a844e7 baz 1
pick d6e71dc baz 2
pick d1a6995 baz 3
pick 157e675 baz 4
# Rebase ef0a89e..157e675 onto ef0a89e
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Edit this to keep what you need:
pick 16730c6 baz 0
squash 2a844e7 baz 1
squash d6e71dc baz 2
squash d1a6995 baz 3
squash 157e675 baz 4
then exit the editor. It'll pop you in another editor session to
type in a commit message for these, just type in what you need and
exit and you'll have the new commit with all the olds ones squashed
into it.
Bill
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Jacob Helwig @ 2009-10-22 20:51 UTC (permalink / raw)
To: Bill Lear; +Cc: Howard Miller, git
In-Reply-To: <19168.50232.47935.864407@lisa.zopyra.com>
On Thu, Oct 22, 2009 at 13:44, Bill Lear <rael@zopyra.com> wrote:
> On Thursday, October 22, 2009 at 15:30:53 (-0500) Bill Lear writes:
>>On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>>>Hello,
>>>
>>>I have a branch with a whole series of commits. I want to export this
>>>work to be customer (to their svn repo if that has any bearing on it).
>>>All the stuff in the history is irrelevant to my customer ("committing
>>>now, going to bed" etc.) so I'd like to create a new branch that only
>>>has one commit.. the end point with a new message. Is this possible?
>>
>>git rebase is your friend.
>
> Someone correct me if I'm wrong.
>
> % git branch
> * master
> % git checkout -b my_work_branch
> % [work work work, commit, commit, commit]
> % git rebase -i master
>
Alternatively, you could use git merge --squash
git checkout master
git merge --squash topic
See git-merge(1) for details.
rebase --interactive it excellent for cleaning up history, especially
if you want to end up with more than one commit at the end. merge
--squash is usually sufficient if all you need is one commit at the
end.
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-22 20:58 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Bill Lear, git
In-Reply-To: <8c9a060910221351w12e6c610kb842263e1c02ea63@mail.gmail.com>
>
> Alternatively, you could use git merge --squash
>
> git checkout master
> git merge --squash topic
>
> See git-merge(1) for details.
>
> rebase --interactive it excellent for cleaning up history, especially
> if you want to end up with more than one commit at the end. merge
> --squash is usually sufficient if all you need is one commit at the
> end.
>
Brilliant, thanks everybody!! I'll go and back up my database and have
a play with these options.
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Jakub Narebski @ 2009-10-22 20:59 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910221303n493fb7s701269d694110685@mail.gmail.com>
Howard Miller <howard@e-learndesign.co.uk> writes:
> I have a branch with a whole series of commits. I want to export this
> work to be customer (to their svn repo if that has any bearing on it).
> All the stuff in the history is irrelevant to my customer ("committing
> now, going to bed" etc.) so I'd like to create a new branch that only
> has one commit.. the end point with a new message. Is this possible?
You can use either "git merge --squash" or "git rebase --interactive"
(changing 'pick' to 'squash').
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-22 21:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3hbtrdu1r.fsf@localhost.localdomain>
> 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
^ permalink raw reply
* [PATCH 1/2] remote: Make ref_remove_duplicates faster for 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>
The ref_remove_duplicates function was very slow at dealing with very
large numbers of refs. This is because it was using a linear search
through all remaining refs to find any duplicates of the current ref.
Rewriting it to use a string list to keep track of which refs have
already been seen and removing duplicates when they are found is much
more efficient.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
remote.c | 39 +++++++++++++++++++++------------------
1 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/remote.c b/remote.c
index 73d33f2..a97c2c3 100644
--- a/remote.c
+++ b/remote.c
@@ -6,6 +6,7 @@
#include "revision.h"
#include "dir.h"
#include "tag.h"
+#include "string-list.h"
static struct refspec s_tag_refspec = {
0,
@@ -734,29 +735,31 @@ int for_each_remote(each_remote_fn fn, void *priv)
void ref_remove_duplicates(struct ref *ref_map)
{
- struct ref **posn;
- struct ref *next;
+ struct string_list refs = { NULL, 0, 0, 0 };
+ struct string_list_item *item = NULL;
+ struct ref *prev = NULL;
for (; ref_map; ref_map = ref_map->next) {
if (!ref_map->peer_ref)
continue;
- posn = &ref_map->next;
- while (*posn) {
- if ((*posn)->peer_ref &&
- !strcmp((*posn)->peer_ref->name,
- ref_map->peer_ref->name)) {
- if (strcmp((*posn)->name, ref_map->name))
- die("%s tracks both %s and %s",
- ref_map->peer_ref->name,
- (*posn)->name, ref_map->name);
- next = (*posn)->next;
- free((*posn)->peer_ref);
- free(*posn);
- *posn = next;
- } else {
- posn = &(*posn)->next;
- }
+
+ item = string_list_lookup(ref_map->peer_ref->name, &refs);
+ if (item) {
+ if (strcmp(((struct ref *)item->util)->name,
+ ref_map->name))
+ die("%s tracks both %s and %s",
+ ref_map->peer_ref->name,
+ ((struct ref *)item->util)->name,
+ ref_map->name);
+ prev->next = ref_map->next;
+ free(ref_map->peer_ref);
+ free(ref_map);
}
+
+ item = string_list_insert(ref_map->peer_ref->name, &refs);
+ item->util = ref_map;
+ prev = ref_map;
}
+ string_list_clear(&refs, 0);
}
int remote_has_url(struct remote *remote, const char *url)
--
1.6.5.rc2
^ permalink raw reply related
* [PATCH 0/2] Speedup fetch with large numbers of refs
From: Julian Phillips @ 2009-10-22 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
These two commits make fetch quite a bit faster when dealing with
large numbers of refs. Unfortunately I've lost the exact figures, but
my silly test respository (50000 tags, 1 branch) went from something
like 30s for a "fetch --tags" that did nothing, to about 5.
Julian Phillips (2):
remote: Make ref_remove_duplicates faster for large numbers of refs
fetch: Speed up fetch of large numbers of refs
builtin-fetch.c | 17 ++++++++++++++---
remote.c | 39 +++++++++++++++++++++------------------
2 files changed, 35 insertions(+), 21 deletions(-)
^ permalink raw reply
* [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
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