* Re: After-the-fact submodule detection or creation
From: Alex Riesen @ 2007-12-07 7:37 UTC (permalink / raw)
To: Michael Poole; +Cc: git
In-Reply-To: <87ir3bp5sf.fsf@graviton.dyn.troilus.org>
Michael Poole, Fri, Dec 07, 2007 04:01:04 +0100:
> It seems like using the current submodule code would mean that this
> kind of import would need two passes over the foreign repository,
> rather than one if the branch could be created after the parent tree
> is initially imported. I can live with that -- it is a rather unusual
> case -- but maybe there is a better way.)
Import the core module in a branch all by itself, and merge it in
every support branch?
Supp1: o-o-o-----o-o-o-o-o-o-o
/
Core: o-o-o-o-o
\
Supp2: o-o-------o-o-o-o
^ permalink raw reply
* Re: In future, to replace autotools by cmake like KDE4 did?
From: Marcel Holtmann @ 2007-12-07 7:56 UTC (permalink / raw)
To: J.C. Pizarro; +Cc: gcc, git, David Miller, Daniel Berlin, Ismail Donmez
In-Reply-To: <998d0e4a0712061810k18e6388jde9d7bc5bd006b57@mail.gmail.com>
Hi,
> The autotools ( automake + libtool + autoconf + ... ) generate many
> big
> files that they have been slowing the building's computation and
> growing
> enormously their cvs/svn/git/hg repositories because of generated
> files.
>
> To see below interesting links:
> 1. http://dot.kde.org/1172083974/
> 2. http://sam.zoy.org/lectures/20050910-debian/
> 3. https://lwn.net/Articles/188693/
> 4. http://en.wikipedia.org/wiki/GNU_Build_Tools
> 5. http://en.wikipedia.org/wiki/GNU_Automake
>
> The benefits could be:
> * +40% faster in the KDE4 building vs KDE 3.5.6.
> * elimination of redundant and unnecesary generated files as those
> from autotools.
> * smaller cvs/svn/git/hg repositories.
stop spreading this FUD. If you leave the auto-generated files from
autotools in the source control repositories, then it is your fault.
They are generated files and can always be generated. Hence putting
them under revision control makes no sense and so don't do it. And
more certain don't complain about it if you did.
Regards
Marcel
^ permalink raw reply
* Re: how to create v2 patch
From: Wincent Colaiuta @ 2007-12-07 8:11 UTC (permalink / raw)
To: Tilman Schmidt; +Cc: Mike Hommey, Pascal Obry, git
In-Reply-To: <475855D6.201@imap.cc>
El 6/12/2007, a las 21:04, Tilman Schmidt escribió:
> Am 01.12.2007 14:43 schrieb Mike Hommey:
>> On Sat, Dec 01, 2007 at 02:17:39PM +0100, Pascal Obry wrote:
>>> Tilman Schmidt a écrit :
>>>> I have produced a patch, submitted it to LKML, received a few
>>>> comments, committed appropriate changes to my local git tree,
>>>> and now want to submit a revised patch. How do I do that?
>>>> If I just run git-format-patch again, it produces my original
>>>> patch plus a second one containing my updates, but what I need
>>>> is a single new patch replacing the first one.
>>> Can't you merge both of your changes in your local repository? I
>>> would
>>> do that with an interactive rebase.
>>
>> Or just git commit --amend when committing.
>
> Hmm. But wouldn't each of these approaches lead to my original
> commit being removed from my git repository?
Not immediately, but eventually. Let's say you have a history like this:
A--B--C--D
And you amend commit D to become D':
A--B--C--D'
\
D
You effectively have two "branches" now, but one of them (the original
D) is unreferenced and will eventually be garbage collected. In other
words, your ongoing development will look like this:
A--B--C--D'-E--F--G
\
D
At this point the only thing which references commit D will be your
reflog, and with default settings that means that the commit will hang
around for at least 90 more days before being pruned during garbage
collection.
> And isn't removing
> commits that have already been published strongly discouraged?
Yes, normally that statement is true (because someone else may have
based work on top of "D" and if you delete "D" then you just pulled
the rug out from under them). But as others have pointed out, posting
a PATCH to a mailing list isn't the same thing as "publishing a
commit", so I won't repeat what's already been explained.
If, however, you really had *published* the commit (ie. pushed it out
to an accessible repository) then you'd want to use "git revert"
rather than "git commit --amend".
A--B--C--D--D'--E--F
Reverting doesn't delete any commits at all; instead it introduces a
new commit (D') which undoes the change introduced in D. So you're
undoing the *effect* of D without actually "undoing" the fact that you
committed and published it.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH/RFC (take 3)] autoconf: Add test for OLD_ICONV (squelching compiler warning)
From: Wincent Colaiuta @ 2007-12-07 8:22 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Linus Torvalds, Blake Ramsdell, Junio C Hamano, Pascal Obry,
Ramsay Jones, Arjen Laarhoven, Brian Gernhardt
In-Reply-To: <1196990840-1168-1-git-send-email-jnareb@gmail.com>
El 7/12/2007, a las 2:27, Jakub Narebski escribió:
> Update configure.ac (and config.mak.in) to keep up with git
> development by adding [compile] test whether your library has an old
> iconv(), where the second (input buffer pointer) parameter is declared
> with type (const char **) (OLD_ICONV).
>
> Test-proposed-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Tested and working here on Mac OS X 10.5.1/Darwin 9.1.0 (where we no
longer have an old iconv):
configure: CHECKS for header files
checking for old iconv()... no
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH/RFC (take 3)] autoconf: Add test for OLD_ICONV (squelching compiler warning)
From: Wincent Colaiuta @ 2007-12-07 8:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narebski, git, Linus Torvalds, Blake Ramsdell, Pascal Obry,
Ramsay Jones, Arjen Laarhoven, Brian Gernhardt
In-Reply-To: <7v7ijr7yph.fsf@gitster.siamese.dyndns.org>
El 7/12/2007, a las 8:26, Junio C Hamano escribió:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Is something like the patch below what you wanted to try?
>
> This looks sensible. Will apply.
This works for those using autoconf. Junio, did you get a chance to
look at the patch I posted for people who don't use autoconf?
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH/RFC (take 3)] autoconf: Add test for OLD_ICONV (squelching compiler warning)
From: Blake Ramsdell @ 2007-12-07 8:29 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Linus Torvalds, Wincent Colaiuta, Junio C Hamano,
Pascal Obry, Ramsay Jones, Arjen Laarhoven, Brian Gernhardt
In-Reply-To: <1196990840-1168-1-git-send-email-jnareb@gmail.com>
On Dec 6, 2007 5:27 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Is something like the patch below what you wanted to try?
Yes. Not sure if main() is required, so it might be shorter if that's
removed, but not really relevant as long as it works.
And CHECKS for header files might be considered chatty.
Blake
--
Blake Ramsdell | http://www.blakeramsdell.com
^ permalink raw reply
* Re: git guidance
From: Andreas Ericsson @ 2007-12-07 8:40 UTC (permalink / raw)
To: Al Boldi
Cc: Johannes Schindelin, Phillip Susi, Linus Torvalds, Jing Xue,
linux-kernel, git
In-Reply-To: <200712070737.18519.a1426z@gawab.com>
Al Boldi wrote:
> Johannes Schindelin wrote:
>> Hi,
>
> Hi
>
>> On Fri, 7 Dec 2007, Al Boldi wrote:
>>> You need to re-read the thread.
>> I don't know why you write that, and then say thanks. Clearly, what you
>> wrote originally, and what Andreas pointed out, were quite obvious
>> indicators that git already does what you suggest.
>>
>> You _do_ work "transparently" (whatever you understand by that overused
>> term) in the working directory, unimpeded by git.
>
> If you go back in the thread, you may find a link to a gitfs client that
> somebody kindly posted. This client pretty much defines the transparency
> I'm talking about. The only problem is that it's read-only.
>
> To make it really useful, it has to support versioning locally, disconnected
> from the server repository. One way to implement this, could be by
> committing every update unconditionally to an on-the-fly created git
> repository private to the gitfs client.
>
Earlier you said that you need to be able to tell git when you want to make
a commit, which means pretty much any old filesystem could serve as gitfs.
Now you're saying you want every single update to be committed, which would
make it mimic an editor's undo functionality. I still don't get what it is
you really want.
> With this transparently created private scratch repository it should then be
> possible for the same gitfs to re-expose the locally created commits, all
> without any direct user-intervention.
>
> Later, this same scratch repository could then be managed by the normal
> git-management tools/commands to ultimately update the backend git
> repositories.
>
That's exactly what's happening today. I imagine whoever wrote the gitfs
thing did so to facilitate testing, or as some form of intellectual
masturbation.
So, to get to the bottom of this, which of the following workflows is it you
want git to support?
### WORKFLOW A ###
edit, edit, edit
edit, edit, edit
edit, edit, edit
Oops I made a mistake and need to hop back to "current - 12".
edit, edit, edit
edit, edit, edit
publish everything, similar to just tarring up your workdir and sending out
### END WORKFLOW A ###
### WORKFLOW B ###
edit, edit, edit
ok this looks good, I want to save a checkpoint here
edit, edit, edit
looks good again. next checkpoint
edit, edit, edit
oh crap, back to checkpoint 2
edit, edit, edit
ooh, that's better. save a checkpoint and publish those checkpoints
### END WORKFLOW B ###
If you could just answer that question and stop writing "transparent" or
any synonym thereof six times in each email, we can possibly help you.
As it stands now though, nobody is very interested because you haven't
explained how you want this "transparency" of yours to work in an every
day scenario.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Better value for chunk_size when threaded
From: Andreas Ericsson @ 2007-12-07 8:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List, Nicolas Pitre
In-Reply-To: <9e4733910712061558k19fbc864ia1fb7a3431fd2603@mail.gmail.com>
Jon Smirl wrote:
> I tried some various ideas out for chunk_size and the best strategy I
> found was to simply set it to a constant. How does 20,000 work on
> other CPUs?
>
> I'd turn on default threaded support with this change. With threads=1
> versus non-threaded there is no appreciable difference in the time.
>
> Is there an API to ask how many CPUs are in the system? It would be
> nice to default the number of threads equal to the number of CPUs and
> only use pack.threads=X to override.
>
I posted a patch to implement that just yesterday. It might need some
polishing, but it hasn't received any comments so far.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [BUG/RFC git-gui] password for push/pull in case ofgit+ssh://repo
From: Alxneit-Kamber Ivo @ 2007-12-07 8:57 UTC (permalink / raw)
To: Thomas Harning, Jeff King; +Cc: git
In-Reply-To: <47582D5F.7070003@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]
On Thu, 2007-12-06 at 12:11 -0500, Thomas Harning wrote:
> Ivo Alxneit wrote:
> > when i use git-gui (0.9.0) to push/pull to/from a git+ssh://repo i have
> > to supply my password to ssh. i get the password prompt from ssh on the
> > controlling shell. as i often use several shells and git-gui might run
> > in the background it is rather bothering to find the correct shell where
> > ssh expects the password. could this be changed (in a safe way) in
> > git-gui e.g. like pinentry pops up a window when gpg is used to sign
> > emails?
> >
> > p.s. please cc me. i have not subscribed to the list
> >
> > thanks
> >
> I know this doesn't answer the problem exactly, but if you use ssh keys
> and some sort of key management utility (such as Keychain or maybe Gnome
> keyring?), you can dodge the password entry problem and never have to
> enter a password (pending you register your ssh key with the server [ex:
> ssh-copy-id servername])
>
>
> Another option that might answer your problem (and could be potentially
> integrated into git-gui) is the usage of the SSH_ASKPASS environment
> variable.
>
> SSH_ASKPASS is a program to execute to get the passphrase that works by
> reading console output from the program.
thanks to both of you.
in essence you are telling me to use the infrastructure provided by ssh
to ask fo the password. i'll try :-)
--
Dr. Ivo Alxneit
Laboratory for Solar Technology phone: +41 56 310 4092
Paul Scherrer Institute fax: +41 56 310 2688
CH-5232 Villigen http://solar.web.psi.ch
Switzerland gnupg key: 0x515E30C7
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-bisect feature suggestion: "git-bisect diff"
From: Ingo Molnar @ 2007-12-07 9:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
would be nice to have:
git-bisect diff
that enables one to have a look at the currently open bisection window,
in git-log -p format. This would often be much faster to analyze than
looking at git-bisect visualize. (and it could also be used in non-GUI
workflows)
Right now i have this silly git-bisect-diff script:
git-log -p "`git-bisect log | grep good | tail -1 | cut -d' ' -f3`".."\
`git-bisect log | grep bad | tail -1 | cut -d' ' -f3`"
Ingo
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-12-07 9:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcixtnm4.fsf@gitster.siamese.dyndns.org>
Heavy merges to 'master' continues. We are almost there for -rc0.
Merged to 'master' are:
* Colorized "add -i" (Dan Zwell)
* Talk more about diff options in "git log" documentation (Miklos)
* git-gui 0.9.1 preview
* Make cvsserver act more like receive-pack (Michael Witten)
* "git-clean <paths>" limits the damage to named paths
* Use right Perl in Documentation/Makefile
Also people's favorite topic "squelching compilation warnings for iconv"
is included.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
David Symonds (1):
Change from using email.com to example.com as example domain, as per RFC
2606.
Junio C Hamano (2):
git grep shows the same hit repeatedly for unmerged paths
git-am -i: report rewritten title
Nguyễn Thái Ngọc Duy (3):
Add missing inside_work_tree setting in setup_git_directory_gently
Do check_repository_format() early
Do check_repository_format() early (re-fix)
----------------------------------------------------------------
* The 'master' branch has these since the last announcement
in addition to the above.
Björn Steinbrink (1):
git config: Don't rely on regexec() returning 1 on non-match
Brian M. Carlson (1):
git-gui: Reorder msgfmt command-line arguments
Christian Stimming (2):
Update git-gui.pot with latest (few) string additions and changes.
Update German translation. 100% completed.
Jakub Narebski (1):
autoconf: Add test for OLD_ICONV (squelching compiler warning)
Jeff King (1):
t7300: add test for clean with wildcard pathspec
Johannes Sixt (2):
git-gui: Improve the application icon on Windows.
for-each-ref: Fix quoting style constants.
Junio C Hamano (12):
Run the specified perl in Documentation/
git-cvsserver runs hooks/post-update
Revert "git-am: catch missing author date early."
Documentation: color.* = true means "auto"
git config --get-colorbool
Color support for "git-add -i"
git-clean: Honor pathspec.
config --get-colorbool: diff.color is a deprecated synonym to color.diff
hg-to-git: handle an empty dir in hg.
do not discard status in fetch_refs_via_pack()
git-status documentation: mention subdirectory behaviour
Update draft release notes to 1.5.4
Kristian Høgsberg (1):
Rewrite builtin-fetch option parsing to use parse_options().
Matthias Kestenholz (1):
Documentation: add --patch option to synopsis of git-add
Michael Witten (1):
git-cvsserver runs hooks/post-receive
Michele Ballabio (2):
git-gui: fix a typo in lib/commit.tcl
git-gui: update it.po and glossary/it.po
Miklos Vajna (2):
Include diff options in the git-log manpage
Update Hungarian translation. 100% completed.
Nanako Shiraishi (1):
Update ja.po for git-gui
Robert Schiele (1):
git-gui: install-sh from automake does not like -m755
Wincent Colaiuta (1):
Silence iconv warnings on Leopard
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-12-07 9:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vzlwps8zf.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.
----------------------------------------------------------------
[Graduated to 'master']
* jc/clean-fix (Wed Dec 5 22:28:06 2007 -0500) 2 commits
This does fix limited test cases I tried, but the original breakage
around the directory related options are probably still there.
* jc/docmake-perl (Fri Nov 30 18:36:34 2007 -0800) 1 commit
Let's see if I can get a straight answer from Merlyn if this fixes the
issue for him.
* jc/addi-color (Wed Dec 5 22:12:07 2007 -0800) 3 commits
This is Dan Zwell's colorized interactive add.
* jc/git-log-doc (Thu Nov 1 15:57:40 2007 +0100) 1 commit
Rewrote Miklos's patch rather extensively. Need to be in v1.5.4.
* kh/fetch-optparse (Tue Dec 4 02:25:47 2007 -0500) 1 commit
Makes fetch parameter parser to use optparse.
* mw/cvsserver (Wed Dec 5 01:15:01 2007 -0800) 2 commits
Make cvsserver to call post-update and receive hooks to act more like
receive-pack.
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
* pr/mergetool (Wed Dec 5 09:19:13 2007 +0200) 1 commit
+ Open external merge tool with original file extensions for all
three files
Waiting for Ted's Ack but I think this is safe. Hoping to merge before
v1.5.4-rc0.
* jc/spht (Thu Dec 6 00:14:14 2007 -0800) 7 commits
+ Use gitattributes to define per-path whitespace rule
+ core.whitespace: documentation updates.
+ builtin-apply: teach whitespace_rules
+ builtin-apply: rename "whitespace" variables and fix styles
+ core.whitespace: add test for diff whitespace error highlighting
+ git-diff: complain about >=8 consecutive spaces in initial indent
+ War on whitespace: first, a bit of retreat.
This teaches apply and diff about the customizable definition of what
whitespace breakages are, and the customization can be refined per-path
using the attributes mechanism. It would be to nice to have this in
v1.5.4.
----------------------------------------------------------------
[Actively cooking]
* cc/help (Sun Dec 2 06:08:00 2007 +0100) 4 commits
- Use {web,instaweb,help}.browser config options.
- git-help: add -w|--web option to display html man page in a
browser.
+ Documentation: describe -i/--info option to "git-help"
+ git-help: add -i|--info option to display info page.
Not a must, but would be very nice to have in v1.5.4.
* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit
- Start preparing the API documents.
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.
* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
+ Support builtin aliases
Cute hack.
----------------------------------------------------------------
[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.
----------------------------------------------------------------
[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, so I do not mind merging this as long as people
find it useful.
* 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
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
* 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/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/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
* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit
. revert/cherry-pick: start refactoring call to merge_recursive
* 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/diff-relative (Thu Dec 6 09:48:32 2007 -0800) 1 commit
. Make "diff" Porcelain output paths as relative to subdirectory.
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Junio C Hamano @ 2007-12-07 9:58 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20071207093439.GA21896@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> would be nice to have:
>
> git-bisect diff
>
> that enables one to have a look at the currently open bisection window,
> in git-log -p format. This would often be much faster to analyze than
> looking at git-bisect visualize. (and it could also be used in non-GUI
> workflows)
Hmm. It is very unfortunate that "bisect log" is taken for something
unrelated, so tentatively let's call it lumber.
$ git bisect lumber [-p] [--stat]
would give you the short-hand, hopefully.
---
git-bisect.sh | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 7a6521e..ee26624 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[start|bad|good|skip|next|reset|visualize|replay|log|run]'
+USAGE='[start|bad|good|skip|next|reset|visualize|log|replay|lumber|run]'
LONG_USAGE='git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
reset bisect state and start bisection.
git bisect bad [<rev>]
@@ -15,6 +15,8 @@ git bisect reset [<branch>]
finish bisection search and go back to branch.
git bisect visualize
show bisect status in gitk.
+git bisect lumber
+ show bisect status in git log.
git bisect replay <logfile>
replay bisection log.
git bisect log
@@ -328,6 +330,12 @@ bisect_visualize() {
eval gitk refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
}
+bisect_lumber() {
+ bisect_next_check fail
+ not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*")
+ eval git log "$@" refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
+}
+
bisect_reset() {
test -f "$GIT_DIR/BISECT_NAMES" || {
echo "We are not bisecting."
@@ -451,6 +459,8 @@ case "$#" in
bisect_next "$@" ;;
visualize)
bisect_visualize "$@" ;;
+ lumber)
+ bisect_lumber "$@" ;;
reset)
bisect_reset "$@" ;;
replay)
^ permalink raw reply related
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: Sergei Organov @ 2007-12-07 10:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0712062107520.21625@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 6 Dec 2007, Sergei Organov wrote:
>
>> Prepend $(prefix)/share/man to the MANPATH environment variable before
>> invoking 'man' from help.c:show_man_page().
>
> This commit message is severely lacking. Why would you _ever_ prefer the
> installed man pages before invoking "man", which should find them
> anyway?
Obviously because you want manual pages corresponding to the version of
git you are invoking, not any random version of man-pages man may find
by default.
--
Sergei.
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Junio C Hamano @ 2007-12-07 10:25 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <7v63za4yic.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Ingo Molnar <mingo@elte.hu> writes:
>
>> would be nice to have:
>>
>> git-bisect diff
>>
>> that enables one to have a look at the currently open bisection window,
>> in git-log -p format. This would often be much faster to analyze than
>> looking at git-bisect visualize. (and it could also be used in non-GUI
>> workflows)
>
> Hmm. It is very unfortunate that "bisect log" is taken for something
> unrelated, so tentatively let's call it lumber.
>
> $ git bisect lumber [-p] [--stat]
>
> would give you the short-hand, hopefully.
More seriously...
-- >8 --
git-bisect visualize: work in non-windowed environments better
This teaches "git bisect visualize" to be more useful in non-windowed
environments.
(1) When no option is given, and $DISPLAY is set, it continues to
spawn gitk as before;
(2) When no option is given, and $DISPLAY is unset, "git log" is run
to show the range of commits between the bad one and the good ones;
(3) If only "-flag" options are given, "git log <options>" is run.
E.g. "git bisect visualize --stat"
(4) Otherwise, all of the given options are taken as the initial part
of the command line and the commit range expression is given to
that command. E.g. "git bisect visualize tig" will run "tig"
history viewer to show between the bad one and the good ones.
As "visualize" is a bit too long to type, we also give it a shorter
synonym "view".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-bisect.sh | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 7a6521e..bb6fe84 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -324,8 +324,23 @@ bisect_next() {
bisect_visualize() {
bisect_next_check fail
+
+ if test $# = 0
+ then
+ case "${DISPLAY+set}" in
+ '') set git log ;;
+ set) set gitk ;;
+ esac
+ else
+ case "$1" in
+ git*|tig) ;;
+ -*) set git log "$@" ;;
+ *) set git "$@" ;;
+ esac
+ fi
+
not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*")
- eval gitk refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
+ eval '"$@"' refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
}
bisect_reset() {
@@ -449,7 +464,7 @@ case "$#" in
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
- visualize)
+ visualize|view)
bisect_visualize "$@" ;;
reset)
bisect_reset "$@" ;;
^ permalink raw reply related
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: Junio C Hamano @ 2007-12-07 10:39 UTC (permalink / raw)
To: Sergei Organov; +Cc: Johannes Schindelin, git
In-Reply-To: <87d4ti7qu1.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Thu, 6 Dec 2007, Sergei Organov wrote:
>>
>>> Prepend $(prefix)/share/man to the MANPATH environment variable before
>>> invoking 'man' from help.c:show_man_page().
>>
>> This commit message is severely lacking. Why would you _ever_ prefer the
>> installed man pages before invoking "man", which should find them
>> anyway?
>
> Obviously because you want manual pages corresponding to the version of
> git you are invoking, not any random version of man-pages man may find
> by default.
While I almost agree with the rest of your sentence, you have to realize
that it is obviously not obvious if somebody asked you to clarify.
How about this:
Prepend $(prefix)/share/man to the MANPATH environment variable
before invoking 'man' from help.c:show_man_page(). There may be
other git documentation in the user's MANPATH but the user is asking
a specific instance of git about its own documentation, so we'd
better show the documentation for _that_ instance of git.
Having written that, it is very tempting to further clarify the above:
Usually, if a user has his own version of git and regularly uses it
by having the non-system executable directory (e.g. $HOME/bin/git)
early in his $PATH, its corresponding documentation would also be in
a non-system documentation directory (e.g. $HOME/man) early in his
$MANPATH, and this change is a no-op. The only case this change
matters is where the user installs his own git outside of his $PATH
and $MANPATH, and explicitly runs his git executable
(e.g. "$HOME/junk/git-1.5.4/bin/git diff").
When you clarify it this way, the change does not look as useful
anymore, does it? How typical would that use be, to run your git
executable by always naming it by path without relying on $PATH
environment variable?
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-12-07 10:53 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Phillip Susi, Linus Torvalds, Jing Xue,
linux-kernel, git
In-Reply-To: <475906F7.5010309@op5.se>
Andreas Ericsson wrote:
> So, to get to the bottom of this, which of the following workflows is it
> you want git to support?
>
> ### WORKFLOW A ###
> edit, edit, edit
> edit, edit, edit
> edit, edit, edit
> Oops I made a mistake and need to hop back to "current - 12".
> edit, edit, edit
> edit, edit, edit
> publish everything, similar to just tarring up your workdir and sending
> out ### END WORKFLOW A ###
>
> ### WORKFLOW B ###
> edit, edit, edit
> ok this looks good, I want to save a checkpoint here
> edit, edit, edit
> looks good again. next checkpoint
> edit, edit, edit
> oh crap, back to checkpoint 2
> edit, edit, edit
> ooh, that's better. save a checkpoint and publish those checkpoints
> ### END WORKFLOW B ###
### WORKFLOW C ###
for every save on a gitfs mounted dir, do an implied checkpoint, commit, or
publish (should be adjustable), on its privately created on-the-fly
repository.
### END WORKFLOW C ###
For example:
echo "// last comment on this file" >> /gitfs.mounted/file
should do an implied checkpoint, and make these checkpoints immediately
visible under some checkpoint branch of the gitfs mounted dir.
Note, this way the developer gets version control without even noticing, and
works completely transparent to any kind of application.
Thanks!
--
Al
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-12-07 11:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejdy4yuw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * pr/mergetool (Wed Dec 5 09:19:13 2007 +0200) 1 commit
> + Open external merge tool with original file extensions for all
> three files
>
> Waiting for Ted's Ack but I think this is safe. Hoping to merge before
> v1.5.4-rc0.
Nice. I don't think this would break anything. By the way, this would
I think also make Emacs (emerge) choose correct major mode for syntax
highlighting etc., so it is not only for Meld...
> * jc/spht (Thu Dec 6 00:14:14 2007 -0800) 7 commits
> + Use gitattributes to define per-path whitespace rule
> + core.whitespace: documentation updates.
> + builtin-apply: teach whitespace_rules
> + builtin-apply: rename "whitespace" variables and fix styles
> + core.whitespace: add test for diff whitespace error highlighting
> + git-diff: complain about >=8 consecutive spaces in initial indent
> + War on whitespace: first, a bit of retreat.
>
> This teaches apply and diff about the customizable definition of what
> whitespace breakages are, and the customization can be refined per-path
> using the attributes mechanism. It would be to nice to have this in
> v1.5.4.
By the way, is there some helper plumbing scripts can use to check
attributes for given file (given pathname), either in working area, or
in repository (I am thinking there to use gitattributes for
configuring syntax highlighting (extension to syntax) in gitweb);
perhaps even in the index.
> * jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
> + Support builtin aliases
>
> Cute hack.
By the way, beside "git view" alias (with configurable backend, be it
gitk, qgit, giggle or gitview) it would be nice to have "git unstash"
as an alias to "git stash apply" (it would not matter here that
command think of itself as 'git stash' here).
> ----------------------------------------------------------------
> [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.
We would have to change the paragraph in INSTALL about git wrapper
(which would be no longer optional, or at least no longer optional in
the sense that you can just delete/not install this file), and its
conflict with (old) GNU Interactive Tools (the other 'git').
> [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, so I do not mind merging this as long as people
> find it useful.
That would be nice to have, although as somebody[*1*] said, you usualy
know that you should have pushed branch into stack when you want to
'pop'. So it would be nice to have (if possible and easy to implement)
also "git checkout --previous" or "git checkout -".
Robin Rosenberg wrote about nice hack to implement "cd -" like
behavior:
Robin Rosenberg wrote:
> I abuse git bisect for this temporary switcing. It only gives me a one
> level memory, but otoh the git prompt tells me I'm on a discourse.
>
> [me@lathund GIT (rr/abspath|BISECTING)]$ git checkout master
> Switched to branch "master"
>
> [me@lathund GIT (master|BISECTING)]$ git checkout HEAD~2
> Note: moving to "HEAD~2" which isn't a local branch
> If you want to create a new branch from this checkout, you may do so
> (now or later) by using -b with the checkout command again. Example:
> git checkout -b <new_branch_name>
> HEAD is now at afcc4f7... Merge branch 'js/prune-expire'
>
> [me@lathund GIT (afcc4f7...|BISECTING)]$ git bisect reset
> Previous HEAD position was afcc4f7... Merge branch 'js/prune-expire'
> Switched to branch "rr/abspath"
> [me@lathund GIT (rr/abspath)]$
[*1*] I'm sorry for no attribution
> * 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
What is the status of this thingy, by the way?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Ingo Molnar @ 2007-12-07 11:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsrq3iox.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> wrote:
> (1) When no option is given, and $DISPLAY is set, it continues to
> spawn gitk as before;
>
> (2) When no option is given, and $DISPLAY is unset, "git log" is run
> to show the range of commits between the bad one and the good
> ones;
>
> (3) If only "-flag" options are given, "git log <options>" is run.
> E.g. "git bisect visualize --stat"
>
> (4) Otherwise, all of the given options are taken as the initial part
> of the command line and the commit range expression is given to
> that command. E.g. "git bisect visualize tig" will run "tig"
> history viewer to show between the bad one and the good ones.
nice. One small detail though: i frequently ssh to testboxes that have
DISPLAY set but i want text output. So git-bisect view --text should be
a special-case perhaps?
Ingo
^ permalink raw reply
* Re: git guidance
From: Jakub Narebski @ 2007-12-07 11:47 UTC (permalink / raw)
To: Al Boldi
Cc: Andreas Ericsson, Johannes Schindelin, Phillip Susi,
Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <200712071353.11654.a1426z@gawab.com>
Al Boldi <a1426z@gawab.com> writes:
> Andreas Ericsson wrote:
>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back to "current - 12".
>> edit, edit, edit
>> edit, edit, edit
>> publish everything, similar to just tarring up your workdir and sending
>> out ### END WORKFLOW A ###
>>
>> ### WORKFLOW B ###
>> edit, edit, edit
>> ok this looks good, I want to save a checkpoint here
>> edit, edit, edit
>> looks good again. next checkpoint
>> edit, edit, edit
>> oh crap, back to checkpoint 2
>> edit, edit, edit
>> ooh, that's better. save a checkpoint and publish those checkpoints
>> ### END WORKFLOW B ###
>
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or
> publish (should be adjustable), on its privately created on-the-fly
> repository.
> ### END WORKFLOW C ###
It looks like it is WORKFLOW A (with the fact that each ',' is file
save stated explicitely rather than implicitely).
> For example:
>
> echo "// last comment on this file" >> /gitfs.mounted/file
>
> should do an implied checkpoint, and make these checkpoints immediately
> visible under some checkpoint branch of the gitfs mounted dir.
>
> Note, this way the developer gets version control without even noticing, and
> works completely transparent to any kind of application.
Why not use versioning filesystem for that, for example ext3cow
(which looks suprisingly git-like, when you take into account that
for ext3cow history is linear and centralized, so one can use date
or sequential number to name commits).
See GitLinks page on Git Wiki, "Other links" section:
http://www.ext3cow.com/
Version control system is all about WORKFLOW B, where programmer
controls when it is time to commit (and in private repository he/she
can then rewrite history to arrive at "Perfect patch series"[*1*]);
something that for example CVS failed at, requiring programmer to do
a merge if upstream has any changes when trying to commit.
[*1*] I have lost link to post at LKML about rewriting history to
arrive at perfect patch _series_. IIRC I have found it first
time on this mailing list. I would be grateful for sending this
link if you have it. TIA.
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: Sergei Organov @ 2007-12-07 11:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vodd23i1v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> On Thu, 6 Dec 2007, Sergei Organov wrote:
>>>
>>>> Prepend $(prefix)/share/man to the MANPATH environment variable before
>>>> invoking 'man' from help.c:show_man_page().
>>>
>>> This commit message is severely lacking. Why would you _ever_ prefer the
>>> installed man pages before invoking "man", which should find them
>>> anyway?
>>
>> Obviously because you want manual pages corresponding to the version of
>> git you are invoking, not any random version of man-pages man may find
>> by default.
>
> While I almost agree with the rest of your sentence, you have to realize
> that it is obviously not obvious if somebody asked you to clarify.
Probably.
>
> How about this:
>
> Prepend $(prefix)/share/man to the MANPATH environment variable
> before invoking 'man' from help.c:show_man_page(). There may be
> other git documentation in the user's MANPATH but the user is asking
> a specific instance of git about its own documentation, so we'd
> better show the documentation for _that_ instance of git.
This sounds nice to me. Do you want me to re-submit the patch with
modified commit message?
>
> Having written that, it is very tempting to further clarify the above:
>
> Usually, if a user has his own version of git and regularly uses it
> by having the non-system executable directory (e.g. $HOME/bin/git)
> early in his $PATH, its corresponding documentation would also be in
> a non-system documentation directory (e.g. $HOME/man) early in his
> $MANPATH, and this change is a no-op. The only case this change
> matters is where the user installs his own git outside of his $PATH
> and $MANPATH, and explicitly runs his git executable
> (e.g. "$HOME/junk/git-1.5.4/bin/git diff").
First, I don't think you need to clarify like this. It is just
implementation detail of git-help that it uses 'man', and thus
implicitly relies on MANPATH. The essential thing has been already
stated above: git-help should show correct documentation.
Second, the change is still useful even if user did put custom path to
'git' into its PATH, but didn't even thought of customizing
MANPATH. Besides, a user could be entirely unaware of 'man' the utility.
> When you clarify it this way, the change does not look as useful
> anymore, does it?
Yes, it still does, I think. I doubt it's that obvious that 'git help'
uses MANPATH at all. Besides, it's not 'git man', isn't it? To further
emphasize my point, we don't require user to tweak MANPATH in order to
get corresponding 'git --help' output, isn't it? Also, please look here:
$ ~/git/bin/git help -a | head -n 3 | tail -n 1
available git commands in '/home/osv/git/bin'
$ git help -a | head -n 3 | tail -n 1
git commands available in '/usr/bin'
$
And the last, basing on the same arguments, it's not that useful that
'git xxx' invokes correct 'git-xxx' command by prepending installation
path to the PATH, isn't it?
Overall, I just want 'git help' to behave consistently.
> How typical would that use be, to run your git executable by always
> naming it by path without relying on $PATH environment variable?
To tell the truth, I'd prefer to just use -M option of man and don't
rely on MANPATH at all, so that 'git help' will issue error if there is
no documentation installed for this particular version of git.
[BTW, git-help lacks his own man page, so I can't actually argue on a
ground of some documentation of git-help.]
--
Sergei.
^ permalink raw reply
* Re: In future, to replace autotools by cmake like KDE4 did?
From: Jakub Narebski @ 2007-12-07 12:14 UTC (permalink / raw)
To: J.C. Pizarro; +Cc: gcc, git, David Miller, Daniel Berlin, Ismail Donmez
In-Reply-To: <998d0e4a0712061810k18e6388jde9d7bc5bd006b57@mail.gmail.com>
"J.C. Pizarro" <jcpiza@gmail.com> writes:
> The autotools ( automake + libtool + autoconf + ... ) generate many big
> files that they have been slowing the building's computation and growing
> enormously their cvs/svn/git/hg repositories because of generated files.
[cut]
And this is relevant for this mailing list exactly how? From the whole
autotools package git uses only autoconf, and only as an optional part
to configure only Makefile configuration variables.
Generated files should not be put into version control, unless it is
for convenience only in separate branch like HTML and manpage versions
of git documentation are in 'html and 'man' branches, respectively.
The same could be done with ./configure script.
Although there was some talk about whether giw should use autotools,
or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
instead of its own handmade Makefile...
--
Jakub Narebski
ShadeHawk on #git
^ permalink raw reply
* Re: git guidance
From: Andreas Ericsson @ 2007-12-07 12:30 UTC (permalink / raw)
To: Al Boldi
Cc: Johannes Schindelin, Phillip Susi, Linus Torvalds, Jing Xue,
linux-kernel, git
In-Reply-To: <200712071353.11654.a1426z@gawab.com>
Al Boldi wrote:
> Andreas Ericsson wrote:
>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back to "current - 12".
>> edit, edit, edit
>> edit, edit, edit
>> publish everything, similar to just tarring up your workdir and sending
>> out ### END WORKFLOW A ###
>>
>> ### WORKFLOW B ###
>> edit, edit, edit
>> ok this looks good, I want to save a checkpoint here
>> edit, edit, edit
>> looks good again. next checkpoint
>> edit, edit, edit
>> oh crap, back to checkpoint 2
>> edit, edit, edit
>> ooh, that's better. save a checkpoint and publish those checkpoints
>> ### END WORKFLOW B ###
>
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or
> publish (should be adjustable), on its privately created on-the-fly
> repository.
> ### END WORKFLOW C ###
>
So you *do* want an editor's undo function, but for an entire filesystem.
That's a handy thing to have every now and then, but it's not what git
(or any other scm) does.
> For example:
>
> echo "// last comment on this file" >> /gitfs.mounted/file
>
> should do an implied checkpoint, and make these checkpoints immediately
> visible under some checkpoint branch of the gitfs mounted dir.
>
> Note, this way the developer gets version control without even noticing, and
> works completely transparent to any kind of application.
>
One other thing that's fairly important to note is that this can never
ever handle changesets, since each write() of each file will be a commit
on its own. It's so far from what git does that I think you'd be better
off just implementing it from scratch, or looking at a versioned fs, like
Jakub suggested in his reply.
You're also neglecting one very important aspect of what an SCM provides
if you go down this road, namely project history. You basically have two
choices with this "implicit save on each edit":
* force the user to supply a commit message for each and every edit
* ignore commit messages altogether
Obviously, forcing a commit message each time is the only way to get some
sort of proper history to look at after it's done, but it's also such an
appalling nuisance that I doubt *anyone* will actually like that, and since
changesets aren't supported, you'll have "implement xniz api, commit 1 of X"
messages. Cumbersome, stupid, and not very useful.
Ignoring commit messages altogether means you ignore the entire history,
and the SCM then becomes a filesystem-wide "undo" cache. This could
ofcourse work, but it's something akin to building a nuclear powerplant
to power a single lightbulb.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 3/3] Color support for "git-add -i"
From: Wincent Colaiuta @ 2007-12-07 12:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejdzd1aw.fsf@gitster.siamese.dyndns.org>
El 6/12/2007, a las 21:18, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> What are the other options?
>>
>> - Make git-add--interactive part of builtin-add so as to be able to
>> use the core.whitespace code directly? (ideally yes and at some point
>> in the future it seems inevitable that this will happen, but it will
>> require a fair bit of work)
>>
>> - Fork a second "git diff-files" process to capture the colorized
>> version of the output? (may set off the "kludge" alarm)
>>
>> - Something else?
>
> - Realize that whitespace clean-up can be risky and change semantics
> depending on the material you are editing. Do not do the clean-up
> during "add -i", but before. IOW, add an alias that does an
> equivalent of:
>
> git diff HEAD >tmp
> git apply -R <tmp
> git apply --whitespace=fix <tmp
>
> then encourage users to clean-up their whitespace gotchas early (and
> test the result!), before even attempting to run "git add -i".
In principle I agree with what you're saying but I think I didn't make
myself clear; I wasn't talking about actually *cleaning-up* whitespace
problems from inside "git add -i", I was talking about *display* of
whitespace problems only. In other words, I don't want the situation
where I think it's ok to stage a hunk only because I mistakenly think
it's free of whitespace problems. In other words, if one part of Git
("git diff") says the diff is "this" and another part ("git add -i")
says the diff is "that" and there's a discrepancy, then that sounds
like a bug to me.
Seeing as speed is not a concern here (when displaying diffs the
bottleneck is really how fast the user can read, not how fast git
emits the text), correctness is important, and git-add--interactive
will eventually become part of builtin-add anyway, I personally think
the optimum solution is this one: run the diff tools twice, once
without color and once with; the former is used for internal
processing as before and the later is used for display only. This
approach has the advantage that the whitespace colorization provided
by "git diff-files" can evolve and become more sophisticated (per-path
attributes etc) and "git add -i" will automatically benefit from it.
But I wanted to throw the question out there for input first, in any
case, I have a patch implementing my proposal and I'll send it out in
a minute.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Teach "git add -i" to colorize whitespace errors
From: Wincent Colaiuta @ 2007-12-07 12:35 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
Rather than replicating the colorization logic of "git diff-files" we
rely on "git diff-files" itself. This guarantees consistent colorization
in and outside "git add -i".
Seeing as speed is not a concern here (the bottleneck is how fast the
user can read, not how fast "git diff-files" runs) we do this by
actually running it twice, once without color and once with.
In this way as the whitespace colorization provided by "git diff-files"
evolves (per-path attributes, new classes of whitespace error), "git
add -i" will automatically benefit from it and stay in synch.
Also, by working with two sets of diff output (an uncolorized one for
internal processing and a colorized one for display only) we minimize
the risk of regressions because the changes required to implement this
are minimally invasive.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
This applies on top of these patches that Junio sent out yesterday:
git config --get-colorbool
Color support for "git-add -i"
I've tested it here and it works for me but it would be nice if
someone else could play with it and see if this is good.
git-add--interactive.perl | 67 +++++++++++++++++++-------------------------
1 files changed, 29 insertions(+), 38 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 1019a72..e492fac 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -525,42 +525,21 @@ sub add_untracked_cmd {
sub parse_diff {
my ($path) = @_;
my @diff = run_cmd_pipe(qw(git diff-files -p --), $path);
- my (@hunk) = { TEXT => [] };
+ my @colored = run_cmd_pipe(qw(git diff-files -p --color --), $path)
+ if $diff_use_color;
+ my (@hunk) = { TEXT => [], DISPLAY => [] };
- for (@diff) {
- if (/^@@ /) {
- push @hunk, { TEXT => [] };
+ for (my $i = 0; $i < @diff; $i++) {
+ if ($diff[$i] =~ /^@@ /) {
+ push @hunk, { TEXT => [], DISPLAY => [] };
}
- push @{$hunk[-1]{TEXT}}, $_;
+ push @{$hunk[-1]{TEXT}}, $diff[$i];
+ push @{$hunk[-1]{DISPLAY}},
+ $diff_use_color ? $colored[$i] : $diff[$i];
}
return @hunk;
}
-sub colored_diff_hunk {
- my ($text) = @_;
- # return the text, so that it can be passed to print()
- my @ret;
- for (@$text) {
- if (!$diff_use_color) {
- push @ret, $_;
- next;
- }
-
- if (/^\+/) {
- push @ret, colored($new_color, $_);
- } elsif (/^\-/) {
- push @ret, colored($old_color, $_);
- } elsif (/^\@/) {
- push @ret, colored($fraginfo_color, $_);
- } elsif (/^ /) {
- push @ret, colored($normal_color, $_);
- } else {
- push @ret, colored($metainfo_color, $_);
- }
- }
- return @ret;
-}
-
sub hunk_splittable {
my ($text) = @_;
@@ -578,7 +557,9 @@ sub parse_hunk_header {
}
sub split_hunk {
- my ($text) = @_;
+ my $text = shift;
+ my $display = shift;
+ $display = $text unless $display;
my @split = ();
# If there are context lines in the middle of a hunk,
@@ -594,16 +575,19 @@ sub split_hunk {
my $i = $hunk_start - 1;
my $this = +{
TEXT => [],
+ DISPLAY => [],
OLD => $o_ofs,
NEW => $n_ofs,
OCNT => 0,
NCNT => 0,
ADDDEL => 0,
POSTCTX => 0,
+ USE => undef,
};
while (++$i < @$text) {
my $line = $text->[$i];
+ my $display = $display->[$i];
if ($line =~ /^ /) {
if ($this->{ADDDEL} &&
!defined $next_hunk_start) {
@@ -615,6 +599,7 @@ sub split_hunk {
$next_hunk_start = $i;
}
push @{$this->{TEXT}}, $line;
+ push @{$this->{DISPLAY}}, $display;
$this->{OCNT}++;
$this->{NCNT}++;
if (defined $next_hunk_start) {
@@ -637,6 +622,7 @@ sub split_hunk {
redo OUTER;
}
push @{$this->{TEXT}}, $line;
+ push @{$this->{DISPLAY}}, $display;
$this->{ADDDEL}++;
if ($line =~ /^-/) {
$this->{OCNT}++;
@@ -662,8 +648,10 @@ sub split_hunk {
(($n_cnt != 1) ? ",$n_cnt" : '') .
" @@\n");
unshift @{$hunk->{TEXT}}, $head;
+ unshift @{$hunk->{DISPLAY}},
+ $use_color ? (colored $fraginfo_color, $head) : $head;
}
- return map { $_->{TEXT} } @split;
+ return @split;
}
sub find_last_o_ctx {
@@ -794,7 +782,9 @@ sub patch_update_file {
my ($ix, $num);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
- print colored_diff_hunk($head->{TEXT});
+ for (@{$head->{DISPLAY}}) {
+ print;
+ }
$num = scalar @hunk;
$ix = 0;
@@ -836,7 +826,9 @@ sub patch_update_file {
if (hunk_splittable($hunk[$ix]{TEXT})) {
$other .= '/s';
}
- print colored_diff_hunk($hunk[$ix]{TEXT});
+ for (@{$hunk[$ix]{DISPLAY}}) {
+ print;
+ }
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
@@ -889,14 +881,13 @@ sub patch_update_file {
next;
}
elsif ($other =~ /s/ && $line =~ /^s/) {
- my @split = split_hunk($hunk[$ix]{TEXT});
+ my @split = split_hunk($hunk[$ix]{TEXT},
+ $hunk[$ix]{DISPLAY});
if (1 < @split) {
print colored $header_color, "Split into ",
scalar(@split), " hunks.\n";
}
- splice(@hunk, $ix, 1,
- map { +{ TEXT => $_, USE => undef } }
- @split);
+ splice (@hunk, $ix, 1, @split);
$num = scalar @hunk;
next;
}
--
1.5.3.7.1079.gb270a-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox