* 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: 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: 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
* 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
* 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
* 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
* 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: 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
* 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: [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
* 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: 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: 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: [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
* 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: [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
* 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: 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
* 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: [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: [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
From: Stephen Boyd @ 2009-10-22 18:50 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87iqe7zspn.fsf@jondo.cante.net>
Jari Aalto wrote:
> +--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.
I thought we needed a plus before new paragraphs in these situations?
^ permalink raw reply
* Re: [msysGit] [PATCH v5 7/8] mingw: enable OpenSSL
From: Johannes Sixt @ 2009-10-22 18:38 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: msysgit, git, Erik Faye-Lund
In-Reply-To: <1256144691-2908-8-git-send-email-kusmabite@gmail.com>
On Mittwoch, 21. Oktober 2009, Erik Faye-Lund wrote:
> Since we have OpenSSL in msysgit now, enable it to support SSL
> encryption for imap-send.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* [PATCH ef/msys-imap] mingw: use BLK_SHA1 again
From: Johannes Sixt @ 2009-10-22 18:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: msysgit, Erik Faye-Lund, git, Erik Faye-Lund, Junio C Hamano,
Marius Storm-Olsen
In-Reply-To: <200910222011.02737.j6t@kdbg.org>
Since NO_OPENSSL is no longer defined on Windows, BLK_SHA1 is not defined
anymore implicitly. Define it explicitly.
As a nice side-effect, we no longer link against libcrypto.dll, which has
non-trivial startup costs because it depends on 6 otherwise unneeded
DLLs.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
On Donnerstag, 22. Oktober 2009, Johannes Sixt wrote:
> ... and I have one more patch to be applied on top of the series.
Here it is. I haven't tested the MSVC aspect of the patch. I would
appreciate feedback in this regard.
-- Hannes
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 5403fad..f666d2f 100644
--- a/Makefile
+++ b/Makefile
@@ -911,6 +911,7 @@ ifdef MSVC
NO_REGEX = YesPlease
NO_CURL = YesPlease
NO_PTHREADS = YesPlease
+ BLK_SHA1 = YesPlease
CC = compat/vcbuild/scripts/clink.pl
AR = compat/vcbuild/scripts/lib.pl
@@ -960,6 +961,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
UNRELIABLE_FSTAT = UnfortunatelyYes
OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo
NO_REGEX = YesPlease
+ BLK_SHA1 = YesPlease
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/fnmatch
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
COMPAT_OBJS += compat/mingw.o compat/fnmatch/fnmatch.o compat/winansi.o
--
1.6.5.rc3.70.gfc1aa
^ permalink raw reply related
* Re: [msysGit] Re: [PATCH v5 0/8] imap-send: Windows support
From: Johannes Sixt @ 2009-10-22 18:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysgit, Erik Faye-Lund, git, Erik Faye-Lund
In-Reply-To: <alpine.DEB.1.00.0910221942150.1263@felix-maschine>
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), and I have one more patch to be applied on
top of the series.
-- Hannes
^ permalink raw reply
* Re: [msysGit] [PATCH v5 0/8] imap-send: Windows support
From: Johannes Schindelin @ 2009-10-22 17:42 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-1-git-send-email-kusmabite@gmail.com>
Hi,
On Wed, 21 Oct 2009, Erik Faye-Lund wrote:
> Here's the 5th iteration of my patches for Windows-compatibility in
> imap-send.
>
> - Patch 1-3 is about getting rid of or rewriting
> code with portability issues.
> - Patch 4 fixes a compilation error on Windows
> - Patch 5 enables compilation of imap-send
> - Patch 6-7 enables SSL-suport for mingw
> - Patch 8 enables imap-send and SSL for msvc
>
> The only change compared to the previous iteration
> is that patch 7 and 8 enables NEEDS_CRYPTO_WITH_SSL.
>
> Please note that I haven't tested Patch 8 with
> NEEDS_CRYPTO_WITH_SSL under MSVC, as I don't have a
> working setup with both msysgit and MSVC installed.
>
> I'd love it if someone with such a working setup
> could verify that it works, preferrably also with
> BLK_SHA1 enabled.
If there are no objections, I will apply them tomorrow.
Ciao,
Dscho
^ 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