* Re: [PATCH 3/3] Add a command "fix" to rebase --interactive.
From: Junio C Hamano @ 2009-12-05 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Michael Haggerty, git
In-Reply-To: <alpine.DEB.1.00.0912041943160.21557@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 4 Dec 2009, Junio C Hamano wrote:
>
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
>> > index 0bd3bf7..539413d 100755
>> > --- a/git-rebase--interactive.sh
>> > +++ b/git-rebase--interactive.sh
>> > @@ -302,7 +302,7 @@ nth_string () {
>> >
>> > make_squash_message () {
>> > if test -f "$SQUASH_MSG"; then
>> > - COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
>> > + COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
> ...
> IIRC "|" was not correctly handled by BSD sed (used e.g. in MacOSX).
You are right; we actually have seen and fixed a similar breakage. For
example, "git log --all-match --grep=BRE --grep=ERE" finds:
commit 1883a0d3b7ad7c9de1ac790bda6f1a6181237439
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Sep 19 23:52:49 2008 -0700
diff: use extended regexp to find hunk headers
Using ERE elements such as "|" (alternation) by backquoting in BRE
is a GNU extension and should not be done in portable programs.
and "sed" is defined to take BRE.
Tentatively I'd queue this on top of 3/3 for eventual squashing.
Thanks
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 5 Dec 2009 10:42:44 -0800
Subject: [PATCH] [squash to Add a command "fix"] Avoid "\(alternatives\|choices\)" in sed script
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 539413d..c30209e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -302,7 +302,7 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
- COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
+ COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)[tsnr][htd] commit message.*:$/\1/p" \
< "$SQUASH_MSG" | sed -ne '$p')+1))
echo "# This is a combination of $COUNT commits."
sed -e 1d -e '2,/^./{
--
1.6.6.rc1.31.g1a56b
^ permalink raw reply related
* Gui criticism
From: Ram Rachum @ 2009-12-05 18:51 UTC (permalink / raw)
To: git
Hello!
This is my first time on this list. I'm a Python developer who's been using git
for about a year. I generally like it, but I have several gripes about the GUI.
(My development machine is on Windows XP.) Would specifying these criticisms be
helpful to you?
Best Wishes,
Ram Rachum.
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Junio C Hamano @ 2009-12-05 19:06 UTC (permalink / raw)
To: Jeff King; +Cc: Maarten Lankhorst, Junio C Hamano, git
In-Reply-To: <20091204111158.GE27495@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Dec 03, 2009 at 12:30:46PM +0100, Maarten Lankhorst wrote:
>
>> When I was working on my code and made a mess that I wanted to undo,
>> I accidentally did it in the .git directory, and had a whole clone of
>> my last committed tree there.
>>
>> It can be triggered easily:
>>
>> mkdir test; cd test; git init; touch foo; git add foo; git commit -m
>> 'add foo'; cd .git; git reset --hard; [ -f foo ] && echo hello beauty
>>
>> Other parts of git could be affected, I haven't checked where exactly
>> the bug hides, so I was afraid to send in a patch
>
> Yuck. Thanks for the bug report. This is due to a too-loose check on my
> part in 49b9362 (git-reset: refuse to do hard reset in a bare
> repository, 2007-12-31).
>
> Junio, I think the following should go to maint (I didn't bother
> splitting the --merge and --hard code; --merge is in v1.6.2. I assumed
> we don't care about maint releases that far back).
Although I'll apply your patch to 'maint' and will merge it for 1.6.6, I
am not quite sure if this is the best fix in the longer run. Shouldn't we
go back to the top of the work tree and running what was asked there?
^ permalink raw reply
* Re: Gui criticism
From: Michael J Gruber @ 2009-12-05 19:25 UTC (permalink / raw)
To: Ram Rachum; +Cc: git
In-Reply-To: <loom.20091205T194800-496@post.gmane.org>
Ram Rachum venit, vidit, dixit 05.12.2009 19:51:
> Hello!
>
> This is my first time on this list. I'm a Python developer who's been using git
> for about a year. I generally like it, but I have several gripes about the GUI.
> (My development machine is on Windows XP.) Would specifying these criticisms be
> helpful to you?
No, unless they are specific bug reports.
The main problem is that we have too many GUIs, and the "main" ones are
in tcl/tk which not many people write. So there's a small developer base
for the standard GUI, and the rest prefers to split up and each do their
own GUI rather than work on a coordinated project. (I've tried to change
that before.)
Michael
^ permalink raw reply
* Re: Gui criticism
From: Felipe Contreras @ 2009-12-05 19:37 UTC (permalink / raw)
To: Ram Rachum; +Cc: git
In-Reply-To: <loom.20091205T194800-496@post.gmane.org>
Hello Ram,
On Sat, Dec 5, 2009 at 8:51 PM, Ram Rachum <cool-rr@cool-rr.com> wrote:
> This is my first time on this list. I'm a Python developer who's been using git
> for about a year. I generally like it, but I have several gripes about the GUI.
> (My development machine is on Windows XP.) Would specifying these criticisms be
> helpful to you?
I don't think the mailing list is the best place for this, that's why
I just started a project in SourceForge, so that users can post these
kinds of issues in the ideatorrent:
https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
I haven't made the announcement yet, but soon :)
--
Felipe Contreras
^ permalink raw reply
* Re: Speedlimit at "git clone"
From: Stefan Kuhne @ 2009-12-05 19:40 UTC (permalink / raw)
To: git
In-Reply-To: <4B17AA6B.7030000@access.denied>
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Stefan Kuhne schrieb:
Hello,
>
> how can i limit the download speed at "git clone"?
>
no one any idea?
Regards,
Stefan Kuhne
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]
^ permalink raw reply
* Re: Gui criticism
From: Martin Langhoff @ 2009-12-05 19:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051137u682a3a99ved9d19338b881b13@mail.gmail.com>
On Sat, Dec 5, 2009 at 8:37 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> I don't think the mailing list is the best place for this
Mailing lists and face to face events are _the_ best places.
> I just started a project in SourceForge
A new project is for code. And the existing GUIs need help, your help,
in the already existing mailing lists and codebases they have.
>, so that users can post these
> kinds of issues
In a safe place where developers won't read?
> I haven't made the announcement yet, but soon :)
How about picking an existing git GUI project you're prepared to help,
and... just... help? Code, documentation, screen mockups, graphic art?
Is it too... normal? Maybe too... productive?
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Gui criticism
From: Junio C Hamano @ 2009-12-05 20:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051137u682a3a99ved9d19338b881b13@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> I don't think the mailing list is the best place for this, that's why
> I just started a project in SourceForge, so that users can post these
> kinds of issues in the ideatorrent:
> https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
Two issues and a half offhand after entering one:
- I found the experience of adding an "idea" too clunky and slow.
Writing a well thought out e-mail can be done in the same time.
- Although enforcing a minimum structure of "idea" description is a good
thing to do, I found the current structure presented by that web page
lacks focus. It has problem description and a rather broad and vague
"idea", and it feels to me that it is promoting entering any garbage
without discussing feasibility, "pros-and-cons" or necessary steps to
achieve a particular goal.
- The largest issue of this kind of system is who will be moderating and
how capable they are.
^ permalink raw reply
* Re: Gui criticism
From: Felipe Contreras @ 2009-12-05 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ram Rachum, git
In-Reply-To: <7v3a3prxdt.fsf@alter.siamese.dyndns.org>
On Sat, Dec 5, 2009 at 10:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I don't think the mailing list is the best place for this, that's why
>> I just started a project in SourceForge, so that users can post these
>> kinds of issues in the ideatorrent:
>> https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
>
> Two issues and a half offhand after entering one:
>
> - I found the experience of adding an "idea" too clunky and slow.
> Writing a well thought out e-mail can be done in the same time.
Yeah, I agree; it's too slow right now, but it's the only way I've
found to host some kind of ideastorm.
The difference with e-mails is that ideas get votes, which helps to
find out what users really want:
http://brainstorm.ubuntu.com/
Also, the main action to do in this system should be "vote", that's
the action that should be fast.
> - Although enforcing a minimum structure of "idea" description is a good
> thing to do, I found the current structure presented by that web page
> lacks focus. It has problem description and a rather broad and vague
> "idea", and it feels to me that it is promoting entering any garbage
> without discussing feasibility, "pros-and-cons" or necessary steps to
> achieve a particular goal.
That's why ideas go to a sandbox, and then maintainers approve or reject them.
> - The largest issue of this kind of system is who will be moderating and
> how capable they are.
Indeed, that's one issue, but also, it needs a large inflow of votes,
and when popular ideas are identified, then it needs people to
actually implement them.
--
Felipe Contreras
^ permalink raw reply
* Re: Gui criticism
From: Junio C Hamano @ 2009-12-05 20:41 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051225y2d193a1fqfb38ebcce95719c3@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Also, the main action to do in this system should be "vote", that's
> the action that should be fast.
Actually I do not think you would want that, especially as a moderator (I
am assuming that you would be self-appointing to be one). What will you
do to help a "broad, vague, and infeasible idea" forward when it gets many
votes?
That is why I prefer a system that requires substance when voicing an
opinion ("Yes I like the solution because in addition to the original
problem description it will also help this use case"), and it also is the
reason I tend to ignore e-mails that only say "+1" on this list.
In other words, this is not a democracy, and you do not necessarily want a
democracy that is prone to populism.
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: David Aguilar @ 2009-12-05 20:44 UTC (permalink / raw)
To: Dilip M; +Cc: Johannes Schindelin, Marc Strapetz, git
In-Reply-To: <c94f8e120912050832o6d43672bla3beb1e3cedd7db3@mail.gmail.com>
On Sat, Dec 05, 2009 at 10:02:08PM +0530, Dilip M wrote:
> On Sat, Dec 5, 2009 at 8:31 PM, <Johannes.Schindelin@gmx.de> wrote:
>
> > As for "missing", do you refer to "paid service", or "yet another GUI"?
>
> Ahaha! I can say "a good gui" :)
>
> I was not knowing that this was "paid service". I saw the screenshot
> and tried it. No doubt, it has a _great_ ui interface. While installation I
> realized that it is licensed.
>
> - SOFTWARE Non-Commercial License,
> - SOFTWARE Commercial License,
> - SOFTWARE Enterprise License.
Aside from the other good GUIs out there, have you tried
git-cola?
http://cola.tuxfamily.org/
It's GPL and not too shabby.
The screenshots on the webpage are a bit out of date, though.
I should probably get to writing the release announcment and
updating the screenshots ;)
It probably also depends on your platform of choice.
I know some Windows users like explorer-integration, so stuff
like git-cheetah make a lot of sense for them. I was a little
sad to see that the tortoise-git guys didn't get the joke
(who wants a tortoise when you have a cheetah?) and didn't
just work on cheetah instead, but hey, it's all good.
Another example: eclipse users like eclipse integration so for
them egit makes perfect sense.
Maybe that makes git-cola the poor man's smartgit?
If that's the case then it looks like the poor man is still
winning according to the feature matrix on the git wiki ;)
I don't know.. I haven't used smartgit, but if there are
any features that people are itching to have that git-cola
doesn't then feel free to throw it on the backlog:
http://github.com/davvid/git-cola/issues
At first glance, the gitk-like history widget in smartgit
is very nice. I've been thinking about how to implement that in
PyQt for a while but haven't yet hammered it out.
Have fun,
--
David
^ permalink raw reply
* Re: [PATCH] bash: update 'git commit' completion
From: Shawn O. Pearce @ 2009-12-05 21:17 UTC (permalink / raw)
To: SZEDER G??bor; +Cc: Junio C Hamano, git
In-Reply-To: <1259974301-11593-1-git-send-email-szeder@ira.uka.de>
SZEDER G??bor <szeder@ira.uka.de> wrote:
> I just wanted to add the recently learnt '--reset-author' option, but
> then noticed that there are many more options missing. This patch
> adds support for all of 'git commit's options, except '--allow-empty',
> because it is primarily there for foreign scm interfaces.
>
> Furthermore, this patch also adds support for completing the arguments
> of those options that take a non-filename argument: valid modes are
> offered for '--cleanup' and '--untracked-files', while refs for
> '--reuse-message' and '--reedit-message', because these two take a
> commit as argument.
>
> Signed-off-by: SZEDER G??bor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH RESEND] git gui: make current branch default in "remote delete branch" merge check
From: Shawn O. Pearce @ 2009-12-05 21:18 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann, Junio C Hamano
In-Reply-To: <20091204212648.GA3979@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> wrote:
> We already do the same when locally deleting a branch.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
>
> lib/remote_branch_delete.tcl | 8 +++++++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
Thanks, applied.
--
Shawn.
^ permalink raw reply
* Re: Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Shawn O. Pearce @ 2009-12-05 21:19 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Peter Baumann, Jeff Epler, git
In-Reply-To: <20091204220730.GB3979@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> wrote:
> On Thu, Oct 29, 2009 at 08:34:54AM +0100, Peter Baumann wrote:
> > Cc ing Shawn as the git gui maintainer, as he might have missed this series
> > during his away time.
>
> Ping? A short reminder for Shawn as I do not see the patches in his
> tree.
I have a stack of git-gui patches which I've just ignored in
my inbox. I'll work through them this afternoon.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH 1/2] Fix applying a line when all following lines are deletions
From: Shawn O. Pearce @ 2009-12-05 21:32 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <1256160023-29629-2-git-send-email-jepler@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> wrote:
> If a diff looked like
> @@
> context
> -del1
> -del2
> and you wanted to stage the deletion 'del1', the generated patch
> wouldn't apply because it was missing the line 'del2' converted to
> context, but this line was counted in the @@-line
> ---
> lib/diff.tcl | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/lib/diff.tcl b/lib/diff.tcl
> index bd5d189..066755b 100644
> --- a/lib/diff.tcl
> +++ b/lib/diff.tcl
> @@ -664,6 +664,7 @@ proc apply_line {x y} {
> }
> set i_l $next_l
> }
> + set patch "$patch$pre_context"
Signed-off-by ?
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Shawn O. Pearce @ 2009-12-05 21:36 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <20091026193903.GA27319@unpythonic.net>
Jeff Epler <jepler@unpythonic.net> wrote:
> I've found another problem, which I'll work on as soon as I find a
> chance.
>
> When staging multiple "+" lines preceded by a "-" line that must be
> turned into context, the converted "-" line must come after *all* the
> "+" lines, not just the first one.
So the reason this series got stuck was this message, this bug is
enough to suggest we shouldn't apply it to my tree yet, so I've
been waiting for an update on the topic.
Also, I need a Signed-off-by line.
--
Shawn.
^ permalink raw reply
* Re: [PATCHv3 0/3] git-gui: more robust handling of fancy repos
From: Shawn O. Pearce @ 2009-12-05 22:15 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Markus Heidelberg
In-Reply-To: <1250467128-29839-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> As promised a long time ago (March 30), version 3 of the small patchset
> to improve handling of repositories in git gui. The most significant
> change is the addition of the third patch.
...
> Giuseppe Bilotta (3):
> git-gui: handle non-standard worktree locations
> git-gui: handle bare repos correctly
> git-gui: work from the .git dir
>
> git-gui/git-gui.sh | 88 +++++++++++++++++++++++++++++++++++++++++++---------
> 1 files changed, 73 insertions(+), 15 deletions(-)
Unfortunately this series doesn't apply to my tree, and I don't
have the blobs which are recorded in the index line, so I can't
easily 3-way merge it onto the current tip.
Would you be able to rebase it?
--
Shawn.
^ permalink raw reply
* Re: git-svn breakage on repository rename
From: Eric Wong @ 2009-12-05 22:22 UTC (permalink / raw)
To: Guido Stevens; +Cc: git, George Kuk
In-Reply-To: <4B197078.6050203@cosent.net>
Guido Stevens <guido.stevens@cosent.net> wrote:
> Hi Eric e.a.,
>
> I have a weird git-svn corner case that might interest you (or not at
> all). I'd appreciate any help or hints for moving beyond this problem.
>
> I'm using git-svn to do a full commit history analysis of the Zope +
> Plone CMS code bases as part of a research project with the University
> of Nottingham into open source knowledge dynamics.
>
> One of the repositories I'm importing breaks with a "Checksum mismatch",
> indicating a corruption. However, this error message occurs exactly at
> the point where the repository was renamed: from "Products.CMFPlone" to
> "Plone" (22715->22716). (Yes, it's the Plone core itself that resists
> analysis :-()
>
> The git-svn url for the later commits would be:
> http://svn-mirror.plone.org/svn/plone/Plone/trunk
>
> Whereas an older part of the code base lives at:
> http://svn-mirror.plone.org/svn/plone/Products.CMFPlone/trunk
>
> Funny thing is, git-svn detects this rename upfront but then breaks
> anyway. Which raises the questions:
>
> - is this breakage caused by the rename?
Hi Guido,
Yes. By default, git svn without --stdlayout does not attempt
to determine a repository root so parent following can be done.
On the other hand, Plone does appear to use a standard SVN layout.
> - or does git-svn handle the rename, and there is an actual corruption?
It should, let me know if the example I give below doesn't work
It looks like a big repo and they're worried about bandwidth:
"Do not make a checkout of the entire repository! This is likely to
get you blacklisted."
(ref: http://dev.plone.org/plone/wiki/RepoInfo)
> - is there any way I can work around this and get a valid or semi-valid
> git history for this project?
>
> I don't mind missing a few commits, since I'm not doing code development
> on this repository, only statistical analysis.
I would mind very much if git svn missed commits :>
> Solving this would also be helpful for anyone who wants to work on Plone
> development through git rather than through raw svn.
>
> :*CU#
>
> ----------------------------------------------------
> To reconstruct this error:
> ----------------------------------------------------
>
> $ git svn init https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
> $ cd Plone
> $ git svn fetch
Since Plone appears to use a standard trunk/branches/tags layout
recommended by SVN developers, can you try this instead?:
git svn clone -s http://svn-mirror.plone.org/svn/plone/Plone
If you don't care about branches/tags at all, you can also try
git svn clone --no-follow-parent \
https://svn-mirror.plone.org/svn/plone/Plone/trunk Plone
Also, in the future it'd be nice to know which version of git svn
you're using since bugs may be fixed in a newer version. Thanks!
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Eric Wong @ 2009-12-05 22:32 UTC (permalink / raw)
To: Sam Vilain, Alex Vandiver; +Cc: git
In-Reply-To: <1259786690-sup-8337@utwig>
Alex Vandiver <alex@chmrr.net> wrote:
> This hunk is wrong due to a mis-merge on my part -- the first 'push'
> line should have been removed, obviously. I'll wait for other
> comments before I push a v2, however.
Hi Alex,
I'll continue to defer to Sam for ack-ing SVK-related things.
One thing I am very picky about is wrapping lines at 80-columns or
less (hard tabs being 8 characters wide).
--
Eric Wong
^ permalink raw reply
* Re: svn svn returning 'fatal: Not a valid object name' on sourceforge svn repo
From: Eric Wong @ 2009-12-05 22:49 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git
In-Reply-To: <p0624081ac73dd6a1aaff@[63.138.152.192]>
Stephen Bannasch <stephen.bannasch@deanbrook.org> wrote:
> I use git svn often and normally it works fine.
>
> I getting a fatal error trying to clone the asciimathm svn repo at sourceforge:
>
> $ git svn clone --trunk=trunk --branches=branches http://asciimathml.svn.sourceforge.net/svnroot/asciimathml asciimathml-svn-git
> fatal: Not a valid object name
> ls-tree -z ./: command returned error: 128
>
> Anybody seen this kind of problem before.
>
> A svn co works fine.
>
> I'm using git version 1.6.5.1 on mac os 10.5.8.
Hi Stephen,
Passing the "-r4:HEAD" parameter to "git svn clone" should work. It
looks like the repository was initially miscreated and "trunk" was a
symlink (and not a directory) in r1.
I have not yet thought of a good solution to this, yet...
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Alex Vandiver @ 2009-12-05 22:51 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20091205223241.GB2120@dcvr.yhbt.net>
At Sat Dec 05 17:32:41 -0500 2009, Eric Wong wrote:
> I'll continue to defer to Sam for ack-ing SVK-related things.
>
> One thing I am very picky about is wrapping lines at 80-columns or
> less (hard tabs being 8 characters wide).
*nod* I've fixed up my local copy for v2 to rewrap things at < 80
columns, and will keep that in mind for the future.
- Alex
--
Networking -- only one letter away from not working
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Sam Vilain @ 2009-12-05 22:59 UTC (permalink / raw)
To: Alex Vandiver; +Cc: Eric Wong, git
In-Reply-To: <1260052934-sup-9563@utwig>
On Sat, 2009-12-05 at 17:51 -0500, Alex Vandiver wrote:
> At Sat Dec 05 17:32:41 -0500 2009, Eric Wong wrote:
> > I'll continue to defer to Sam for ack-ing SVK-related things.
> >
> > One thing I am very picky about is wrapping lines at 80-columns or
> > less (hard tabs being 8 characters wide).
>
> *nod* I've fixed up my local copy for v2 to rewrap things at < 80
> columns, and will keep that in mind for the future.
Hi, I've just seen the series, looks like a good idea. Just a couple of
questions then I'll review the code;
- when a change is merged upstream with svk, you will get multiple log
entries in a single commit message. What do you do with commits like
that?
- there are quite a few repos which will have empty commits (ie, no
changes), but with one or more of the above log entries, owing to a bug
which I can't seem to find the details of right now.. how might those
appear?
Thanks for your submission!
Sam
^ permalink raw reply
* Re: [PATCH] Cast &cp to eliminate a compile-time warning on FreeBSD 8-STABLE.
From: James P. Howard, II @ 2009-12-05 23:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091205161405.GA9272@sigill.intra.peff.net>
On Sat, Dec 05, 2009 at 11:14:05AM -0500, Jeff King wrote:
> On Fri, Dec 04, 2009 at 06:12:02PM -0500, James P. Howard, II wrote:
>
> > --- a/utf8.c
> > +++ b/utf8.c
> > @@ -449,7 +449,7 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
> > cp = (iconv_ibp)in;
> >
> > while (1) {
> > - size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
> > + size_t cnt = iconv(conv, (const char **)&cp, &insz, &outpos, &outsz);
> >
> > if (cnt == -1) {
> > size_t sofar;
>
> Aren't you now introducing a warning for all of the other platforms
> which take a "char **"? Should you instead just be building with
> OLD_ICONV=Yes on your platform? See commit fd547a9 for details.
Yes, and it was brought to my attention within 10 minutes of my first
post.
James
--
James P. Howard, II, MPA MBCS
jh@jameshoward.us
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: James P. Howard, II @ 2009-12-05 23:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091205162827.GA9584@sigill.intra.peff.net>
On Sat, Dec 05, 2009 at 11:28:27AM -0500, Jeff King wrote:
> If the latter, I think we would be better served by an option to simply
> turn off the template. Then that is also helpful for the case of people
> using decent editors, but who don't want to waste the CPU time on
> generating the template information (which can be substantial for things
> like media repositories).
Actually, I find this a reasonable solution for both cases and would be
willing to reimplment my change this way, as it meets my needs and would
be useful to others. The only question I have is, what should variable/
command line option be called?
James
--
James P. Howard, II, MPA MBCS
jh@jameshoward.us
^ permalink raw reply
* Re: [spf:guess] Re: [PATCH 2/5] git-svn: Make merge metadata accessible to make_log_entry
From: Alex Vandiver @ 2009-12-05 23:10 UTC (permalink / raw)
To: Sam Vilain; +Cc: Eric Wong, git
In-Reply-To: <1260053972.22680.5.camel@denix>
At Sat Dec 05 17:59:32 -0500 2009, Sam Vilain wrote:
> Hi, I've just seen the series, looks like a good idea. Just a couple of
> questions then I'll review the code;
>
> - when a change is merged upstream with svk, you will get multiple log
> entries in a single commit message. What do you do with commits like
> that?
If the user edited the merge message and supplied their own message,
nothing. If the first line is an SVK merge line, it inserts a message
"Merged from /svn/path/to/trunk:12345\n\n" at the top.
> - there are quite a few repos which will have empty commits (ie, no
> changes), but with one or more of the above log entries, owing to a bug
> which I can't seem to find the details of right now.. how might those
> appear?
Without seeing an example, I'm not sure offhand -- but what you're
describing does ring a bell, so I'm sure I've seen the mismerges
you're talking about as well.
- Alex
--
Networking -- only one letter away from not working
^ 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