* [msysgit] how to detect git.exe directory?
From: Marco Costalba @ 2007-12-23 16:25 UTC (permalink / raw)
To: msysgit, Git Mailing List
Hi all,
I'm progressing on qgit installer for windows, I have switched to
MSVC for compiling Qt4 and qgit sources and I have to say that first
results are very good, qgit.exe now seems to work without problems or
artifacts and the speed is much more similar to what we achieve under
the Linux platform (read much higher).
So it seems Qt+mingw is not the _best_ possible solution.
Anyhow, under Vista you cannot simply copy qgit.exe in the git
directory (OS barfs regarding some administrative rights, note that *I
am* the administartor!), so to make qgit.exe work git.exe file must be
in PATH.
To easy the user and allowing to call qgit.exe double clicking on a
nice desktop icon I need a way to know where git.exe is installed *at
runtime*.
So my question is: "What is the preferred way to detect git directory
at runtime for msysgit files?"
- environment variable ??
- windows registry ??
- others ?
I don't plan to use the cygwin version of git but going directly to
the "long term" solution that is msysgit.
Thanks for your help
Marco
^ permalink raw reply
* gitk / git-gui and Tk 8.5 don't play nice together
From: Kevin Williams @ 2007-12-23 15:02 UTC (permalink / raw)
To: git
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 152 (RENDER)
Minor opcode of failed request: 4 (RenderCreatePicture)
Serial number of failed request: 541
Current serial number in output stream: 549
Is this a known issue? Do I need to file a bug report or something?
^ permalink raw reply
* Problem with git shortlog documentation
From: Gustaf Hendeby @ 2007-12-23 14:16 UTC (permalink / raw)
To: Git Mailing List
Hi!
I was just looking through the documentation for git shortlog, and realized
there is a problem with FILES section close to the bottom. In the version I
built of the man page (asciidoc 8.2.1, yes I used the compatibility define) the
filename .mailmap is missing, and the text starts with "If this file exists, ...".
Looking at the webpage version of the man page
(http://www.kernel.org/pub/software/scm/git/docs/git-shortlog.html) gives
another version, still not what I had expected: "mailmap:: If this file exists,
...", which is not much better.
Unfortunately, I'm completely illiterate in asciidoc/xmlto so I have no idea
where to start to look for a fix for this without changes to the text.
Hopefully someone else on the list is more knowledgeable. Or is it maybe better
to just reformulate this passage slightly to get around the problem? Something
like this (would we then like to reindent this? it would make the change look
much bigger), which seems to work with my asciidoc version:
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index e14720b..c37ab66 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -38,8 +38,7 @@ OPTIONS
FILES
-----
-.mailmap::
- If this file exists, it will be used for mapping author email
+ If the file .mailmap exists, it will be used for mapping author email
addresses to a real author name. One mapping per line, first
the author name followed by the email address enclosed by
'<' and '>'. Use hash '#' for comments. Example:
/Gustaf
^ permalink raw reply related
* Re: Updated Kernel Hacker's guide to git
From: Dieter Ries @ 2007-12-23 13:05 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712230715490.15596@localhost.localdomain>
Robert P. J. Day schrieb:
> On Sun, 23 Dec 2007, Jeff Garzik wrote:
>
>> Robert P. J. Day wrote:
>>> On Sun, 23 Dec 2007, Jeff Garzik wrote:
>>>
>>>> Another year, another update! :)
>>>>
>>>> The kernel hacker's guide to git has received some updates:
>>>>
>>>> http://linux.yyz.us/git-howto.html
>>>>
>>>> This includes all the input sent to me in the past several months,
>>>> as well as a few new tips and tricks I use on a regular basis.
>>>>
>>>> In general, this document is designed to be a quick-start cookbook,
>>>> and not a comprehensive introduction.
>>> there's one issue i have with this document, and that's that i wish it
>>> more carefully distinguished between regular git "user" tasks, and git
>>> "developer" tasks.
>>>
>>> i may be mistaken, but it would seem that a lot of folks are going to
>>> be what i call basic users, who only want to update their git tree,
>>> check the logs, check the status and so on. and if they start to get
>>> ambitious, they might make some changes to the tree, do a diff, and
>>> submit a patch. but in the beginning, they won't be making commits or
>>> switching branches, etc.
>>>
>>> in short, i can see the value of something like a "getting started
>>> with git as a basic user" tutorial. does such a thing exist?
>> hmmm. There's the tutorial linked at the bottom of the page, which
>> in turn links to
>> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
>>
>> git is a developer's tool, so I sorta targetted that audience. I
>> definitely agree that is not only git audience...
>
> just to be clear, i'm not complaining about the quality of the
> document above, but when i got started with git, what i really wanted
> was a list of what i (as a simple, non-developer user) could do once i
> cloned a repository.
>
> to that end, i put together my own little reference list of git
> commands. for example, i collected ways to examine my repository --
> git commands like branch, tag, log/shortlog, what-changed, show, grep,
> blame, that sort of thing. exactly the kind of stuff a new user might
> want to know about, even without the ability to change anything.
Could you perhaps publish your reference list as kind of a christmas
gift to all basic users like me?
cu
Dieter
ps.: sorry for sending this twice, messed up recipients.
>
> just my $0.02.
>
> rday
> --
>
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry
> Waterloo, Ontario, CANADA
>
> http://crashcourse.ca
> ========================================================================
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: WANG Cong @ 2007-12-23 12:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <476E42BF.1010300@garzik.org>
On Sun, Dec 23, 2007 at 06:13:03AM -0500, Jeff Garzik wrote:
>Another year, another update! :)
>
>The kernel hacker's guide to git has received some updates:
>
> http://linux.yyz.us/git-howto.html
>
>This includes all the input sent to me in the past several months, as
>well as a few new tips and tricks I use on a regular basis.
>
>In general, this document is designed to be a quick-start cookbook, and
>not a comprehensive introduction.
Jeff, very good! I like it. Thank you! ;-)
>
>Merry Christmas and Happy Holidays to all!
>
Merry Christmas, kernel hackers!
Best wishes!
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Robert P. J. Day @ 2007-12-23 12:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <476E50DC.1040701@garzik.org>
On Sun, 23 Dec 2007, Jeff Garzik wrote:
> Robert P. J. Day wrote:
> > On Sun, 23 Dec 2007, Jeff Garzik wrote:
> >
> > > Another year, another update! :)
> > >
> > > The kernel hacker's guide to git has received some updates:
> > >
> > > http://linux.yyz.us/git-howto.html
> > >
> > > This includes all the input sent to me in the past several months,
> > > as well as a few new tips and tricks I use on a regular basis.
> > >
> > > In general, this document is designed to be a quick-start cookbook,
> > > and not a comprehensive introduction.
> >
> > there's one issue i have with this document, and that's that i wish it
> > more carefully distinguished between regular git "user" tasks, and git
> > "developer" tasks.
> >
> > i may be mistaken, but it would seem that a lot of folks are going to
> > be what i call basic users, who only want to update their git tree,
> > check the logs, check the status and so on. and if they start to get
> > ambitious, they might make some changes to the tree, do a diff, and
> > submit a patch. but in the beginning, they won't be making commits or
> > switching branches, etc.
> >
> > in short, i can see the value of something like a "getting started
> > with git as a basic user" tutorial. does such a thing exist?
>
> hmmm. There's the tutorial linked at the bottom of the page, which
> in turn links to
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
>
> git is a developer's tool, so I sorta targetted that audience. I
> definitely agree that is not only git audience...
just to be clear, i'm not complaining about the quality of the
document above, but when i got started with git, what i really wanted
was a list of what i (as a simple, non-developer user) could do once i
cloned a repository.
to that end, i put together my own little reference list of git
commands. for example, i collected ways to examine my repository --
git commands like branch, tag, log/shortlog, what-changed, show, grep,
blame, that sort of thing. exactly the kind of stuff a new user might
want to know about, even without the ability to change anything.
just my $0.02.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2007-12-23 12:13 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0712230701520.14863@localhost.localdomain>
Robert P. J. Day wrote:
> On Sun, 23 Dec 2007, Jeff Garzik wrote:
>
>> Another year, another update! :)
>>
>> The kernel hacker's guide to git has received some updates:
>>
>> http://linux.yyz.us/git-howto.html
>>
>> This includes all the input sent to me in the past several months,
>> as well as a few new tips and tricks I use on a regular basis.
>>
>> In general, this document is designed to be a quick-start cookbook,
>> and not a comprehensive introduction.
>
> there's one issue i have with this document, and that's that i wish it
> more carefully distinguished between regular git "user" tasks, and git
> "developer" tasks.
>
> i may be mistaken, but it would seem that a lot of folks are going to
> be what i call basic users, who only want to update their git tree,
> check the logs, check the status and so on. and if they start to get
> ambitious, they might make some changes to the tree, do a diff, and
> submit a patch. but in the beginning, they won't be making commits or
> switching branches, etc.
>
> in short, i can see the value of something like a "getting started
> with git as a basic user" tutorial. does such a thing exist?
hmmm. There's the tutorial linked at the bottom of the page, which in
turn links to http://www.kernel.org/pub/software/scm/git/docs/everyday.html
git is a developer's tool, so I sorta targetted that audience. I
definitely agree that is not only git audience...
Jeff
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Robert P. J. Day @ 2007-12-23 12:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <476E42BF.1010300@garzik.org>
On Sun, 23 Dec 2007, Jeff Garzik wrote:
> Another year, another update! :)
>
> The kernel hacker's guide to git has received some updates:
>
> http://linux.yyz.us/git-howto.html
>
> This includes all the input sent to me in the past several months,
> as well as a few new tips and tricks I use on a regular basis.
>
> In general, this document is designed to be a quick-start cookbook,
> and not a comprehensive introduction.
there's one issue i have with this document, and that's that i wish it
more carefully distinguished between regular git "user" tasks, and git
"developer" tasks.
i may be mistaken, but it would seem that a lot of folks are going to
be what i call basic users, who only want to update their git tree,
check the logs, check the status and so on. and if they start to get
ambitious, they might make some changes to the tree, do a diff, and
submit a patch. but in the beginning, they won't be making commits or
switching branches, etc.
in short, i can see the value of something like a "getting started
with git as a basic user" tutorial. does such a thing exist?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
^ permalink raw reply
* Re: cvsimport: trying to convert freebsd cvs to git
From: David Soria Parra @ 2007-12-23 12:06 UTC (permalink / raw)
To: git
In-Reply-To: <pan.2007.12.23.01.47.29@progsoc.org>
> If you have access to the raw ",v" files as you do, I would suggest you
> try out parsecvs. It will not do incremental imports but will you a good
> idea of how you can expect the converted repository to behave / act.
ParseCVS works out fine with the PHP repository for us while cvsimport
has some problems with branches. For me it looks like doing parsecvs on
an existing repository tries to check all ,v files but in fact producing
a more or less incremental update.
If you try to use parsecvs make sure that your branchname doesnot
contain / or ~ as this will cause an error on parsecvs. If you need it,
we have a simple patch for that with a small workaround on that.
^ permalink raw reply
* Updated Kernel Hacker's guide to git
From: Jeff Garzik @ 2007-12-23 11:13 UTC (permalink / raw)
To: Linux Kernel, Git Mailing List
In-Reply-To: <200612241807.kBOI746w008739@laptop13.inf.utfsm.cl>
Another year, another update! :)
The kernel hacker's guide to git has received some updates:
http://linux.yyz.us/git-howto.html
This includes all the input sent to me in the past several months, as
well as a few new tips and tricks I use on a regular basis.
In general, this document is designed to be a quick-start cookbook, and
not a comprehensive introduction.
Merry Christmas and Happy Holidays to all!
Jeff
^ permalink raw reply
* What's in git.git (stable frozen)
From: Junio C Hamano @ 2007-12-23 9:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7btaf4p.fsf@gitster.siamese.dyndns.org>
Stabilization cycle towards -rc2 continues.
The main point of -rc cycle is regression fixes and general
bugfixes, although a few new features managed to slip in.
- diff.external configuration variable serves the same purpose
as GIT_EXTERNAL_DIFF environment;
- "git diff --src-prefix=l/ --dst-prefix=k/" can be used to
change the usual prefix (i.e. a/foo vs. b/foo).
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Jeff King (2):
clone: correctly report http_fetch errors
git-send-email: avoid duplicate message-ids
* The 'master' branch has these since the last announcement
in addition to the above.
Charles Bailey (2):
Fix git-instaweb breakage on MacOS X due to the limited sed functionality
Remove old generated files from .gitignore.
Eric Wong (3):
git-svn: avoid leaving leftover committer/author info in rebase
git-svn: workaround a for broken symlinks in SVN
git-svn: avoid warning when run without arguments
Finn Arne Gangstad (1):
Improved submodule merge support
Gustaf Hendeby (1):
Make git send-email accept $EDITOR with arguments
H.Merijn Brand (1):
the use of 'tr' in the test suite isn't really portable
Jakub Narebski (1):
gitweb: fix whitespace in config_to_multi (indent with tab)
Jeff King (2):
test "git clone -o"
clean up 1.5.4 release notes
Jim Meyering (2):
git-filter-branch.sh: more portable tr usage: use \012, not \n.
Don't dereference NULL upon lookup failure.
Johannes Schindelin (6):
Support config variable diff.external
Document diff.external and mergetool.<tool>.path
rebase -p -i: handle "no changes" gracefully
git show <tag>: show the tagger
Teach diff machinery to display other prefixes than "a/" and "b/"
Mention git-shell's "cvs" substitution in the RelNotes
Johannes Sixt (3):
Plug a resource leak in threaded pack-objects code.
Clean up documentation that references deprecated 'git peek-remote'.
filter-branch: Remove broken and unnecessary summary of rewritten refs.
Junio C Hamano (8):
builtin-blame.c: remove unneeded memclr()
GIT 1.5.4-rc1
t4024: fix test script to use simpler sed pattern
fix git commit --amend -m "new message"
shell-scripts usage(): consistently exit with non-zero
Documentation: ls-files -v is about "assume unchanged".
Fix $EDITOR regression introduced by rewrite in C.
Documentation: describe 'union' low-level merge driver
Linus Torvalds (2):
unpack-trees: FLEX_ARRAY fix
Re(-re)*fix trim_common_tail()
Marco Roeland (1):
clone: fix options '-o' and '--origin' to be recognised again
Miklos Vajna (1):
everyday: replace 'prune' and 'repack' with 'gc'
Nicolas Pitre (2):
fix style of a few comments in diff-delta.c
make 'git describe --all --contains' work
Pierre Habouzit (4):
Fix segfault in diff-delta.c when FLEX_ARRAY is 1
git-tag: fix -l switch handling regression.
Force the sticked form for options with optional arguments.
parse-options: Add a gitcli(5) man page.
Ralf Wildenhues (1):
Fix some documentation typos.
Sam Vilain (1):
Clarify error response from 'git fetch' for bad responses
Sean Estabrooks (1):
Fix interactive rebase to preserve author email address
Shawn O. Pearce (3):
Avoid update hook during git-rebase --interactive
Catch and handle git-commit failures in git-rebase --interactive
Reallow git-rebase --interactive --continue if commit is unnecessary
Stefan Sperling (1):
Small comment fix for git-cvsimport.
Wincent Colaiuta (1):
Emit helpful status for accidental "git stash" save
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-12-23 9:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vwsrdaf3d.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. Others commits may be stashed in 'offcuts'.
The topics list the commits in reverse chronological order.
----------------------------------------------------------------
[New Topics]
* ab/pserver (Fri Dec 14 04:08:51 2007 +0000) 1 commit
- Authentication support for pserver
This needs careful security audit and a fix to its password
database format. Plaintext in .git/config is not acceptable.
* rs/pretty-safety (Thu Dec 20 13:20:15 2007 +0100) 1 commit
- Serious bug with pretty format strings & empty bodies?
I do not think what this addresses is any "serious" problem in
real life. But on the other hand I do not think it hurts. Will
take a look at it again and will merge.
* ar/commit-cleanup (Sat Dec 22 19:46:24 2007 +0100) 4 commits
+ Allow selection of different cleanup modes for commit messages
+ builtin-commit: avoid double-negation in the code.
+ builtin-commit: fix amending of the initial commit
+ t7005: do not exit inside test.
This is cleaned up since the last version Alex posted, and the
first three are fixes and clean-ups, so they will be merged.
The primary purpose of this series by Alex is to allow commits
to be made verbatim without stripping lines that begin with '#'
in the commit log messages, which would be a worthy goal, so I
do not mind merging it in 1.5.4.
* ph/describe-match (Fri Dec 21 22:49:54 2007 +0100) 1 commit
+ git-describe: Add a --match option to limit considered tags.
Even though this is a new feature, the impact to the main
codepath is minimum and I think it is Ok to merge it in 1.5.4,
but still seems to have a funny interaction with --contains. So
it will be on hold.
* jc/sys-select (Tue Dec 18 01:52:07 2007 -0800) 1 commit
- Do not include <sys/select.h> on pre- POSIX.1-2001 systems
This was done to help HP-UX port, but it appears that HP-UX
headers do not like to cooperate with usual _POSIX_VERSION rule,
so we probably need to scrap it and instead use manual
configuration instead.
----------------------------------------------------------------
[Graduated to 'master']
* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
The primary reason of this series is because I think we made the system
a lot less approachable by losing hackability. Although we still have
sample scripts in contrib/example for use of plumbing in scripts, they
will not help aspiring git-hacker-wannabees when our primary attention
has already shifted to moving things to C.
This currently consists of mostly stubs, although I wrote about a few
topics as examples. Nice to have in v1.5.4, but we need more writers.
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
Nothing to see. We are in -rc. Please test 'master'.
----------------------------------------------------------------
[Actively cooking]
Nothing to see. We are in -rc. Please test 'master'.
----------------------------------------------------------------
[On hold]
* nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit
- Move all dashed-form commands to libexecdir
I think this is a sane thing to do in the longer term. Will be in
'next' after v1.5.4. I think "leave porcelain on PATH" might be also a
good thing as a transition measure.
Incidentally, if we do not install dashed form of built-ins anywhere
(which is not this series is about --- this is just moving them out of
user's PATH), "git help -a" will stop showing them. I am not enthused
about removing the hardlinks to built-ins to begin with, but people who
want such a change need to first modify help.c:list_commands() to pick
up builtins without having git-foo hardlinks in gitexecdir. This may
need to happen anyway as mingw fallouts.
* js/remote (Wed Dec 5 19:02:15 2007 +0000) 4 commits
. Make git-remote a builtin
. Test "git remote show" and "git remote prune"
. parseopt: add flag to stop on first non option
. path-list: add functions to work with unsorted lists
This and Kristian's "git-clone in C" are on hold and will need
to be rebased, post 1.5.4.
----------------------------------------------------------------
[Stalled]
* ns/checkout-push-pop (Wed Dec 5 07:04:06 2007 +0900) 1 commit
- git-checkout --push/--pop
A reasonably cleanly written cute hack, and I do not see this breaking
the normal codepath. But I tend to agree with people that 'push' is
too late for forgetful mortals, and just a single "previous" would be
easier to use.
* jc/git-symref (Tue Dec 11 16:42:46 2007 -0800) 1 commit
- PARK: show-symref protocol extension.
This is a demonstration of a possible component in the future direction
for HEAD discovery done by git-clone.
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
+ Support builtin aliases
Even the original author has slight NAK on this and I tend to agree.
May want to eventurally revert from 'next' but we are not in a hurry
even to do that.
* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit
- Making ce_path_match() more useful by accepting globs
This was to allow "git diff-files -- '*.h'" (currently diff family
knows only the leading directory match and not fileglobs), but was shot
down by Alex. I tend to agree with him.
* jc/dashless (Sat Dec 1 22:09:22 2007 -0800) 2 commits
- Prepare execv_git_cmd() for removal of builtins from the
filesystem
- git-shell: accept "git foo" form
We do not plan to remove git-foo form completely from the filesystem at
this point, so these are not strictly necessary.
* jc/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
. Make "diff" Porcelain output paths as relative to subdirectory.
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
. pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
. ls-tree.c: refactor show_recursive() and rename it.
. tree-diff.c: split out a function to match a single pattern.
* jc/cherry-pick (Sun Dec 16 21:00:03 2007 -0800) 2 commits
. beginning of use of replay merge in revert
. revert/cherry-pick: start refactoring call to merge_recursive
* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
. merge-nu: a new merge backend without using unpack_trees()
. read_tree: take an explicit index structure
. gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix
^ permalink raw reply
* Re: [PATCH] Explain what 'ginstall' is
From: Jan Hudec @ 2007-12-23 9:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andy Dougherty, git
In-Reply-To: <m3tzmgpzlu.fsf@roke.D-201>
On Mon, Dec 17, 2007 at 17:21:08 -0800, Jakub Narebski wrote:
> [...]
> Second, the default autoconf macro AC_PROG_INSTALL *requires* that
> there is BSD-compatible `install' program (as 'install-sh' or
> 'install.sh') in the sources. Adding such script is (I think) not a
> problem; finding minimal portable[*1*] script is. So if you know
> one...
What's wrong with the one that comes with automake? It should be portable
the insane way ./configure script is -- which should be at least as much as
git -- and the license is compatible (MIT/X).
> Footnotes:
> ----------
> [*1*] By "portable" I mean here 'git portable', i.e. requiring only
> those shell constructs/features that git require, not necessary
> insanelt portable the way ./configure script is.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-23 8:59 UTC (permalink / raw)
To: Jan Hudec; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <20071223083708.GA3563@efreet.light.src>
On Sun, 23 Dec 2007 09:37:08 +0100, Jan Hudec <bulb@ucw.cz> wrote:
> On Thu, Dec 20, 2007 at 08:18:06 +0100, H.Merijn Brand wrote:
> > On Wed, 19 Dec 2007 13:31:58 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > > "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> > > > On Wed, 19 Dec 2007 11:57:21 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > > >> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> > > >> > On Tue, 18 Dec 2007 01:47:53 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > > >> > ...
> > > >> >> Merijn, discarding the earlier patch I did to configure it out for
> > > >> >> HP-UX, does the following patch based on Andreas's idea work for you?
> > > >> >
> > > >> > Probably not:
> > > >> >
> > > >> > HP-UX 10.20, 11.00, 11.11, 11.23/PA, and 11.23/IPF all have:
> > > >> >
> > > >> > /usr/include 103 > grep -r POSIX_VERSION *
> > > >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
> > > >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
> > > >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
>
> Please, note that the defines are _POSIX1_VERSION_*
> ^
Ow. good catch. Sorry, yes, missed that.
> > > >> > sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
> > > >> > sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
> > > >> > sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
> > > >> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_88)
> > > >> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_90)
> > > >> >
> > > >> > and the two 11.23 do have select.h
> > [...]
> >
> > If it is used to *define* _POSIX_VERSION, it should have come up too,
> > wouldn't it?
> >
> > The only define that comes close to something like YYYYMM is:
>
> No, it's not the only one. The _POSIX1_VERSION_* macros we are looking for
> are there below and they are defined this way too (did you miss them because
> of the trailing comment?)
No, because of the trailing _88, _90, and _93
> > X11/Xosdefs.h:#define X_POSIX_C_SOURCE 199300L
> >
> > usr/include 111 > grep -r POSIX.*YEAR .
> > Exit 1
> >
> > /usr/include 112 > grep -P -r 'POSIX.*\b(19\d\d|200\d)' .
> > ./sys/buf.h:#if (_POSIX_C_SOURCE >= 199309)
> > ./sys/buf.h:#endif /* (_POSIX_C_SOURCE >= 199309) */
> > ./sys/stdsyms.h:/* XPG3 semantics gets POSIX.1-1988 semantics by default */
> > ./sys/stdsyms.h: * This usage is obsolescent, "-D_POSIX_C_SOURCE=199506" is preferred */
> > ./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199506) && !defined(_INCLUDE_POSIX1C_SOURCE)
> > ./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199506 && !_INCLUDE_POSIX1C_SOURCE */
> > ./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199506) && !defined(_REENTRANT)
> > ./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199506 && !_REENTRANT */
> > ./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199309) && !defined(_INCLUDE_POSIX4_SOURCE)
> > ./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199309 && !_INCLUDE_POSIX4_SOURCE */
> > ./sys/unistd.h:# define _POSIX1_VERSION_88 198808L /* We support POSIX.1-1988 */
> > ./sys/unistd.h:# define _POSIX1_VERSION_90 199009L /* We support POSIX.1-1990 */
> > ./sys/unistd.h:# define _POSIX1_VERSION_93 199309L /* We support POSIX.1b-1993 */
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> And they are defined HERE.
>
> Obviously, there is no value for the 2001 standard, so if this is from HP-UX
> version that already has sys/select.h, it does not claim conformance to the
> posix standard. But than it might be that sys/select.h is not required, so
> the test might still work.
Good explanation
> > ./sys/unistd.h:# if !defined(_POSIX_C_SOURCE) || (_POSIX_C_SOURCE < 199309L)
> > ./sys/unistd.h:# else /* _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 199309L */
> > ./sys/unistd.h:# endif /* _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 199309L */
> > ./sys/unistd.h:/* Symbolic constants for sysconf() variables defined by POSIX.1-1988: 0-7 */
> > ./sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
> > ./sys/unistd.h:/* Symbolic constants for sysconf() variables added by POSIX.1-1990: 100-199 */
> > ./sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
> > ./sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
> > ./sys/unistd.h:# define _POSIX2_VERSION 199209L /* IEEE POSIX.2-1992 base standard */
> > ./sys/unistd.h:# define _POSIX2_C_VERSION 199209L /* IEEE POSIX.2-1992 C language binding */
> > ./limits.h:# define _POSIX_CLOCKRES_MIN 20000000 /* The CLOCK_REALTIME clock
> > ./X11/Xosdefs.h:#define X_POSIX_C_SOURCE 199300L
> > ./dce/cdsclerk.h:#if _POSIX_C_SOURCE >= 199506L
> > ./dce/rpcexc.h:#if _POSIX_C_SOURCE >= 199506L
> > ./dce/stubbase.h:#if _POSIX_C_SOURCE >= 199506L
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Jan Hudec @ 2007-12-23 8:37 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <20071220081806.0ccdf636@pc09.procura.nl>
On Thu, Dec 20, 2007 at 08:18:06 +0100, H.Merijn Brand wrote:
> On Wed, 19 Dec 2007 13:31:58 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> > > On Wed, 19 Dec 2007 11:57:21 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > >> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> > >> > On Tue, 18 Dec 2007 01:47:53 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > >> > ...
> > >> >> Merijn, discarding the earlier patch I did to configure it out for
> > >> >> HP-UX, does the following patch based on Andreas's idea work for you?
> > >> >
> > >> > Probably not:
> > >> >
> > >> > HP-UX 10.20, 11.00, 11.11, 11.23/PA, and 11.23/IPF all have:
> > >> >
> > >> > /usr/include 103 > grep -r POSIX_VERSION *
> > >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_88
> > >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_90
> > >> > sys/unistd.h:# define _POSIX_VERSION _POSIX1_VERSION_93
Please, note that the defines are _POSIX1_VERSION_*
^
> > >> > sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
> > >> > sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
> > >> > sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
> > >> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_88)
> > >> > sys/unistd.h:# if (_POSIX_VERSION == _POSIX1_VERSION_90)
> > >> >
> > >> > and the two 11.23 do have select.h
> [...]
>
> If it is used to *define* _POSIX_VERSION, it should have come up too,
> wouldn't it?
>
> The only define that comes close to something like YYYYMM is:
No, it's not the only one. The _POSIX1_VERSION_* macros we are looking for
are there below and they are defined this way too (did you miss them because
of the trailing comment?)
> X11/Xosdefs.h:#define X_POSIX_C_SOURCE 199300L
>
> usr/include 111 > grep -r POSIX.*YEAR .
> Exit 1
>
> /usr/include 112 > grep -P -r 'POSIX.*\b(19\d\d|200\d)' .
> ./sys/buf.h:#if (_POSIX_C_SOURCE >= 199309)
> ./sys/buf.h:#endif /* (_POSIX_C_SOURCE >= 199309) */
> ./sys/stdsyms.h:/* XPG3 semantics gets POSIX.1-1988 semantics by default */
> ./sys/stdsyms.h: * This usage is obsolescent, "-D_POSIX_C_SOURCE=199506" is preferred */
> ./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199506) && !defined(_INCLUDE_POSIX1C_SOURCE)
> ./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199506 && !_INCLUDE_POSIX1C_SOURCE */
> ./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199506) && !defined(_REENTRANT)
> ./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199506 && !_REENTRANT */
> ./sys/stdsyms.h:# if (_POSIX_C_SOURCE >= 199309) && !defined(_INCLUDE_POSIX4_SOURCE)
> ./sys/stdsyms.h:# endif /* _POSIX_C_SOURCE >= 199309 && !_INCLUDE_POSIX4_SOURCE */
> ./sys/unistd.h:# define _POSIX1_VERSION_88 198808L /* We support POSIX.1-1988 */
> ./sys/unistd.h:# define _POSIX1_VERSION_90 199009L /* We support POSIX.1-1990 */
> ./sys/unistd.h:# define _POSIX1_VERSION_93 199309L /* We support POSIX.1b-1993 */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And they are defined HERE.
Obviously, there is no value for the 2001 standard, so if this is from HP-UX
version that already has sys/select.h, it does not claim conformance to the
posix standard. But than it might be that sys/select.h is not required, so
the test might still work.
> ./sys/unistd.h:# if !defined(_POSIX_C_SOURCE) || (_POSIX_C_SOURCE < 199309L)
> ./sys/unistd.h:# else /* _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 199309L */
> ./sys/unistd.h:# endif /* _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 199309L */
> ./sys/unistd.h:/* Symbolic constants for sysconf() variables defined by POSIX.1-1988: 0-7 */
> ./sys/unistd.h:# define _SC_1_VERSION_88 7 /* _POSIX_VERSION: Date of POSIX.1-1988 */
> ./sys/unistd.h:/* Symbolic constants for sysconf() variables added by POSIX.1-1990: 100-199 */
> ./sys/unistd.h:# define _SC_1_VERSION_90 102 /* _POSIX_VERSION: Date of POSIX.1-1990 */
> ./sys/unistd.h:# define _SC_1_VERSION_93 103 /* _POSIX_VERSION: Date of POSIX.1b-1993 */
> ./sys/unistd.h:# define _POSIX2_VERSION 199209L /* IEEE POSIX.2-1992 base standard */
> ./sys/unistd.h:# define _POSIX2_C_VERSION 199209L /* IEEE POSIX.2-1992 C language binding */
> ./limits.h:# define _POSIX_CLOCKRES_MIN 20000000 /* The CLOCK_REALTIME clock
> ./X11/Xosdefs.h:#define X_POSIX_C_SOURCE 199300L
> ./dce/cdsclerk.h:#if _POSIX_C_SOURCE >= 199506L
> ./dce/rpcexc.h:#if _POSIX_C_SOURCE >= 199506L
> ./dce/stubbase.h:#if _POSIX_C_SOURCE >= 199506L
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* [PATCH 4/4] Allow selection of different cleanup modes for commit messages
From: Junio C Hamano @ 2007-12-23 3:55 UTC (permalink / raw)
To: git; +Cc: Alex Riesen
In-Reply-To: <1198382136-15724-3-git-send-email-gitster@pobox.com>
From: Alex Riesen <raa.lkml@gmail.com>
From: Alex Riesen <raa.lkml@gmail.com>
Date: Sat, 22 Dec 2007 19:46:24 +0100
Although we traditionally stripped away excess blank lines, trailing
whitespaces and lines that begin with "#" from the commit log message,
sometimes the message just has to be the way user wants it.
For instance, a commit message template can contain lines that begin with
"#", the message must be kept as close to its original source as possible
if you are converting from a foreign SCM, or maybe the message has a shell
script including its comments for future reference.
The cleanup modes are default, verbatim, whitespace and strip. The
default mode depends on if the message is being edited and will either
strip whitespace and comments (if editor active) or just strip the
whitespace (for where the message is given explicitely).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-commit.txt | 12 +++++++-
builtin-commit.c | 42 ++++++++++++++++++++++++--
t/t7502-commit.sh | 65 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 4261384..96383b6 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -11,7 +11,7 @@ SYNOPSIS
'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--allow-empty] [--no-verify] [-e] [--author <author>]
- [--] [[-i | -o ]<file>...]
+ [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
DESCRIPTION
-----------
@@ -95,6 +95,16 @@ OPTIONS
from making such a commit. This option bypasses the safety, and
is primarily for use by foreign scm interface scripts.
+--cleanup=<mode>::
+ This option sets how the commit message is cleaned up.
+ The '<mode>' can be one of 'verbatim', 'whitespace', 'strip',
+ and 'default'. The 'default' mode will strip leading and
+ trailing empty lines and #commentary from the commit message
+ only if the message is to be edited. Otherwise only whitespace
+ removed. The 'verbatim' mode does not change message at all,
+ 'whitespace' removes just leading/trailing whitespace lines
+ and 'strip' removes both whitespace and commentary.
+
-e|--edit::
The message taken from file with `-F`, command line with
`-m`, and from file with `-C` are usually used as the
diff --git a/builtin-commit.c b/builtin-commit.c
index 200eb9d..0e827d7 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -47,6 +47,19 @@ static char *logfile, *force_author, *template_file;
static char *edit_message, *use_message;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, untracked_files, no_verify, allow_empty;
+/*
+ * The default commit message cleanup mode will remove the lines
+ * beginning with # (shell comments) and leading and trailing
+ * whitespaces (empty lines or containing only whitespaces)
+ * if editor is used, and only the whitespaces if the message
+ * is specified explicitly.
+ */
+static enum {
+ CLEANUP_SPACE,
+ CLEANUP_NONE,
+ CLEANUP_ALL,
+} cleanup_mode;
+static char *cleanup_arg;
static int use_editor = 1, initial_commit, in_merge;
const char *only_include_assumed;
@@ -88,6 +101,7 @@ static struct option builtin_commit_options[] = {
OPT_BOOLEAN(0, "amend", &amend, "amend previous commit"),
OPT_BOOLEAN(0, "untracked-files", &untracked_files, "show all untracked files"),
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
+ OPT_STRING(0, "cleanup", &cleanup_arg, "default", "how to strip spaces and #comments from message"),
OPT_END()
};
@@ -346,7 +360,8 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (fp == NULL)
die("could not open %s", git_path(commit_editmsg));
- stripspace(&sb, 0);
+ if (cleanup_mode != CLEANUP_NONE)
+ stripspace(&sb, 0);
if (signoff) {
struct strbuf sob;
@@ -411,7 +426,12 @@ static int prepare_log_message(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
"# Please enter the commit message for your changes.\n"
- "# (Comment lines starting with '#' will not be included)\n");
+ "# (Comment lines starting with '#' will ");
+ if (cleanup_mode == CLEANUP_ALL)
+ fprintf(fp, "not be included)\n");
+ else /* CLEANUP_SPACE, that is. */
+ fprintf(fp, "be kept.\n"
+ "# You can remove them yourself if you want to)\n");
if (only_include_assumed)
fprintf(fp, "# %s\n", only_include_assumed);
@@ -435,10 +455,13 @@ static int message_is_empty(struct strbuf *sb, int start)
const char *nl;
int eol, i;
+ if (cleanup_mode == CLEANUP_NONE && sb->len)
+ return 0;
+
/* See if the template is just a prefix of the message. */
strbuf_init(&tmpl, 0);
if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
- stripspace(&tmpl, 1);
+ stripspace(&tmpl, cleanup_mode == CLEANUP_ALL);
if (start + tmpl.len <= sb->len &&
memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
start += tmpl.len;
@@ -591,6 +614,16 @@ static int parse_and_validate_options(int argc, const char *argv[],
only_include_assumed = "Explicit paths specified without -i nor -o; assuming --only paths...";
also = 0;
}
+ if (!cleanup_arg || !strcmp(cleanup_arg, "default"))
+ cleanup_mode = use_editor ? CLEANUP_ALL : CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "verbatim"))
+ cleanup_mode = CLEANUP_NONE;
+ else if (!strcmp(cleanup_arg, "whitespace"))
+ cleanup_mode = CLEANUP_SPACE;
+ else if (!strcmp(cleanup_arg, "strip"))
+ cleanup_mode = CLEANUP_ALL;
+ else
+ die("Invalid cleanup mode %s", cleanup_arg);
if (all && argc > 0)
die("Paths with -a does not make sense.");
@@ -817,7 +850,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
if (p != NULL)
strbuf_setlen(&sb, p - sb.buf + 1);
- stripspace(&sb, 1);
+ if (cleanup_mode != CLEANUP_NONE)
+ stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
die("no commit message? aborting commit.");
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 21ac785..aaf497e 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -89,4 +89,69 @@ test_expect_success 'verbose' '
'
+test_expect_success 'cleanup commit messages (verbatim,-t)' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo; } >expect &&
+ git commit --cleanup=verbatim -t expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d" |head -n 3 >actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup commit messages (verbatim,-F)' '
+
+ echo >>negative &&
+ git commit --cleanup=verbatim -F expect -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup commit messages (verbatim,-m)' '
+
+ echo >>negative &&
+ git commit --cleanup=verbatim -m "$(cat expect)" -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup commit messages (whitespace,-F)' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo; } >text &&
+ echo "# text" >expect &&
+ git commit --cleanup=whitespace -F text -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+test_expect_success 'cleanup commit messages (strip,-F)' '
+
+ echo >>negative &&
+ { echo;echo "# text";echo sample;echo; } >text &&
+ echo sample >expect &&
+ git commit --cleanup=strip -F text -a &&
+ git cat-file -p HEAD |sed -e "1,/^\$/d">actual &&
+ diff -u expect actual
+
+'
+
+echo "sample
+
+# Please enter the commit message for your changes.
+# (Comment lines starting with '#' will not be included)" >expect
+
+test_expect_success 'cleanup commit messages (strip,-F,-e)' '
+
+ echo >>negative &&
+ { echo;echo sample;echo; } >text &&
+ git commit -e -F text -a &&
+ head -n 4 .git/COMMIT_EDITMSG >actual &&
+ diff -u expect actual
+
+'
+
test_done
--
1.5.4.rc1.19.g9151fa
^ permalink raw reply related
* [PATCH 3/4] builtin-commit: avoid double-negation in the code.
From: Junio C Hamano @ 2007-12-23 3:55 UTC (permalink / raw)
To: git
In-Reply-To: <1198382136-15724-2-git-send-email-gitster@pobox.com>
The flag no_edit meant "we have got final message from the user
and will not editing it any further", but there were quite a few
places that needed to check !no_edit. Rename the variable to
use_editor and reverse the logic everywhere.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index d8f0dfd..200eb9d 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -48,7 +48,7 @@ static char *edit_message, *use_message;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, untracked_files, no_verify, allow_empty;
-static int no_edit, initial_commit, in_merge;
+static int use_editor = 1, initial_commit, in_merge;
const char *only_include_assumed;
struct strbuf message;
@@ -372,7 +372,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
strbuf_release(&sb);
- if (no_edit) {
+ if (!use_editor) {
struct rev_info rev;
unsigned char sha1[20];
const char *parent = "HEAD";
@@ -398,7 +398,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
return !!DIFF_OPT_TST(&rev.diffopt, HAS_CHANGES);
}
- if (in_merge && !no_edit)
+ if (in_merge)
fprintf(fp,
"#\n"
"# It looks like you may be committing a MERGE.\n"
@@ -513,9 +513,9 @@ static int parse_and_validate_options(int argc, const char *argv[],
argc = parse_options(argc, argv, builtin_commit_options, usage, 0);
if (logfile || message.len || use_message)
- no_edit = 1;
+ use_editor = 0;
if (edit_flag)
- no_edit = 0;
+ use_editor = 1;
if (get_sha1("HEAD", head_sha1))
initial_commit = 1;
@@ -796,7 +796,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/* Get the commit message and validate it */
header_len = sb.len;
- if (!no_edit) {
+ if (use_editor) {
char index[PATH_MAX];
const char *env[2] = { index, NULL };
snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
--
1.5.4.rc1.19.g9151fa
^ permalink raw reply related
* [PATCH 2/4] builtin-commit: fix amending of the initial commit
From: Junio C Hamano @ 2007-12-23 3:55 UTC (permalink / raw)
To: git
In-Reply-To: <1198382136-15724-1-git-send-email-gitster@pobox.com>
When amending initial commit without editor, the command
incorrectly barfed because the check to see if there is anything
to commit referenced the non-existent HEAD^1.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-commit.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 96410de..d8f0dfd 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -374,7 +374,7 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (no_edit) {
struct rev_info rev;
- unsigned char sha1[40];
+ unsigned char sha1[20];
const char *parent = "HEAD";
fclose(fp);
@@ -382,12 +382,12 @@ static int prepare_log_message(const char *index_file, const char *prefix)
if (!active_nr && read_cache() < 0)
die("Cannot read index");
- if (get_sha1("HEAD", sha1) != 0)
- return !!active_nr;
-
if (amend)
parent = "HEAD^1";
+ if (get_sha1(parent, sha1))
+ return !!active_nr;
+
init_revisions(&rev, "");
rev.abbrev = 0;
setup_revisions(0, NULL, &rev, parent);
--
1.5.4.rc1.19.g9151fa
^ permalink raw reply related
* [PATCH 1/4] t7005: do not exit inside test.
From: Junio C Hamano @ 2007-12-23 3:55 UTC (permalink / raw)
To: git
The way to signal failure is to leave non-zero in $?, not abort
the entire test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t7005-editor.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7005-editor.sh b/t/t7005-editor.sh
index 44228b5..c1cec55 100755
--- a/t/t7005-editor.sh
+++ b/t/t7005-editor.sh
@@ -37,7 +37,7 @@ test_expect_success 'dumb should error out when falling back on vi' '
if git commit --amend
then
echo "Oops?"
- exit 1
+ false
else
: happy
fi
--
1.5.4.rc1.19.g9151fa
^ permalink raw reply related
* Re: [PATCH] Allow selection of different cleanup modes for commit messages
From: Junio C Hamano @ 2007-12-23 3:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, git
In-Reply-To: <7v1w9ew1vm.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> So I wonder if we should perhaps:
>>
>> (a) Only add these messages at all when we do *not* do CLEANUP_ALL
>>
>> I personally would prefer (a) - since anybody who then explicitly uses
>> --cleanup={space|none} would presumably already know what he is doing.
>
> I thought about this a bit more, but then realized that people
> would still want to see the status output in their editors.
> This applies even to "verbatim" case.
>
> Which means that they need to remove the '#' lines when they do
> not use CLEANUP_ALL.
>
> So I am inclined to suggest we need to take (b).
... and I ended up doing the clean-up myself as I found a
handful buglets in the code before Alex's patch.
Will be posting them shortly.
^ permalink raw reply
* Re: [PATCH] Allow selection of different cleanup modes for commit messages
From: Junio C Hamano @ 2007-12-23 3:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LFD.0.9999.0712221107240.21557@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> So I wonder if we should perhaps:
>
> (a) Only add these messages at all when we do *not* do CLEANUP_ALL
>
> I personally would prefer (a) - since anybody who then explicitly uses
> --cleanup={space|none} would presumably already know what he is doing.
I thought about this a bit more, but then realized that people
would still want to see the status output in their editors.
This applies even to "verbatim" case.
Which means that they need to remove the '#' lines when they do
not use CLEANUP_ALL.
So I am inclined to suggest we need to take (b).
^ permalink raw reply
* Re: sane, stable renames; when a commit should commit twice
From: Junio C Hamano @ 2007-12-23 2:50 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git
In-Reply-To: <20071223020310.GA22450@freedbms.net>
Zenaan Harkness <zen@freedbms.net> writes:
> When should a commit, commit twice?
>
> When one or more git mv file renames/ moves are involved.
> ...
> Does this make sense?
Anything that feels right to you is right for _your_ project, so
asking that question does not add much value, but I would not
personally do that myself. I may have pure rename commits that
move files around without changing any contents in my history,
but that is only because there happened to be no need to change
the contents in those commits, not because I followed an
artificial "a rename-only commit, followed by a commit that
edits" dogma you seem to be suggesting.
If I move file common.c to lib/common.c and common.h to
include/common.h, I would definitely NOT record that as two
events, if common.c used to include common.h. My commit that
moves these two files will definitely contain edit to common.c
(now lib/common.c) that changes at least one line:
-#include "common.h"
+#include "../include/common.h"
in the same commit. If you split this as two events, your first
"rename only" commit would not even build.
^ permalink raw reply
* Re: sane, stable renames; when a commit should commit twice
From: David Symonds @ 2007-12-23 2:26 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git
In-Reply-To: <20071223020310.GA22450@freedbms.net>
On Dec 23, 2007 1:03 PM, Zenaan Harkness <zen@freedbms.net> wrote:
> When should a commit, commit twice?
>
> When one or more git mv file renames/ moves are involved.
>
> In such a case the commit ought to be split into two. Perhaps move the
> files in the first commit, then make the changes needed to support the
> move in the build chain (including changes in the moved files) in the
> second commit.
>
> This keeps a clean record of the move, making the move, and the
> associated changes (as two commits) a clean cherry.
>
> Does this make sense?
Not particularly. Git commits are not (conceptually) changes or
deltas; they are snapshots of a tree of files at a particular time.
How does the tree state at your above first commit make any sense? It
is broken. Git's rename/move detection is smart enough to notice that
a rename + small-changes is close enough to a rename, so just trust
that to get it right.
Dave.
^ permalink raw reply
* Re: cvsimport: trying to convert freebsd cvs to git
From: Anand Kumria @ 2007-12-23 1:47 UTC (permalink / raw)
To: git
In-Reply-To: <20071222171801.GE15286@genesis.frugalware.org>
On Sat, 22 Dec 2007 18:18:01 +0100, Miklos Vajna wrote:
> hi,
>
> recently Stefan reported that he tried to convert the freebsd cvs' src
> module to git and he failed. i tried to help him, but i failed, too.
> here are my efforts:
>
> he made the cvs available on a (relatively) fast rsync mirror at:
>
> rsync://ftp.spline.de/FreeBSD-CVS
>
> (so you don't have to use cvsup if it's a problem for you)
>
> so after mirroring it, i had:
>
> $ ls cvs
> CVSROOT/ CVSROOT-ports/ CVSROOT-src/ ports/ src/
>
A few days prior to your email, someone else asked a similar question:
Some tools you can use:
git-cvsimport (via cvsps)
parsecvs
fromcvs
cvs2svn (development branch)
There is a more detailed listing on the wiki at
<http://git.or.cz/gitwiki/
InterfacesFrontendsAndTools#head-8870e1c81cc93f9a7a7acb5e969924ee60182d6b>
If you have access to the raw ",v" files as you do, I would suggest you
try out parsecvs. It will not do incremental imports but will you a good
idea of how you can expect the converted repository to behave / act.
Anand
^ permalink raw reply
* sane, stable renames; when a commit should commit twice
From: Zenaan Harkness @ 2007-12-23 2:03 UTC (permalink / raw)
To: git
When should a commit, commit twice?
When one or more git mv file renames/ moves are involved.
In such a case the commit ought to be split into two. Perhaps move the
files in the first commit, then make the changes needed to support the
move in the build chain (including changes in the moved files) in the
second commit.
This keeps a clean record of the move, making the move, and the
associated changes (as two commits) a clean cherry.
Does this make sense?
I develop in the java world, and we use packages (directories, and
subdirectories, sub-sub... etc) a lot, and so it is not uncommon in my
10 years development, to decide to reorganise some package/dir every now
and then, and files, and whole dirs, get moved.
I've only been using git for a few weeks, but finding it truly awesome!
A little demanding in the initial learning curve - took me three days of
reading and a little experiementation here and there, before I finally
felt comfortable with rebasing, branching, etc, to effect my work
pattern.
Have used arch/tla, a little bzr, aegis for a couple of years long time
ago, some cvs, and bk for four months or so.
I'm hoping that the above workflow, which has just crystallized for me
in the last two days, makes sense.
zen
--
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.
^ 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