* What's cooking in git.git (Nov 2008, #01; Sun, 02)
From: Junio C Hamano @ 2008-11-02 21:34 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek, pasky
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
There are backlog patches I'm planning to deal with later today; they do
not appear in this list.
----------------------------------------------------------------
[New Topics]
* mv/maint-branch-m-symref (Sat Nov 1 00:25:44 2008 +0100) 5 commits
+ update-ref --no-deref -d: handle the case when the pointed ref is
packed
+ git branch -m: forbid renaming of a symref
+ Fix git update-ref --no-deref -d.
+ rename_ref(): handle the case when the reflog of a ref does not
exist
+ Fix git branch -m for symrefs.
* rs/blame (Sat Oct 25 15:31:36 2008 +0200) 5 commits
- blame: use xdi_diff_hunks(), get rid of struct patch
- add xdi_diff_hunks() for callers that only need hunk lengths
- Allow alternate "low-level" emit function from xdl_diff
- Always initialize xpparam_t to 0
- blame: inline get_patch()
* ds/uintmax-config (Sun Oct 26 03:52:47 2008 -0800) 2 commits
- Add Makefile check for FreeBSD 4.9-SECURITY
- Build: add NO_UINTMAX_T to support ancient systems
I amended the topmost one to widen the applicability of this new feature
to all FreeBSD 4.*, not limited to 4.9-SECURITY; testing before this hits
'next' is appreciated.
* ds/autoconf (Sun Nov 2 01:04:46 2008 -0700) 2 commits
- DONTMERGE: fixup with a convenience macro
- autoconf: Add link tests to each AC_CHECK_FUNC() test
The topmost one is my attempt to simplify the new way of checking; the
resulting configure.ac produces the identical configure script with or
without it, so I think it is Ok, but testing before this hits 'next' is
appreciated. If all goes well, I think the two should be squashed into
one patch.
* jk/diff-convfilter-test-fix (Fri Oct 31 01:09:13 2008 -0400) 4 commits
+ Avoid using non-portable `echo -n` in tests.
+ add userdiff textconv tests
+ document the diff driver textconv feature
+ diff: add missing static declaration
* ar/maint-mksnpath (Mon Oct 27 11:22:09 2008 +0100) 7 commits
+ Use git_pathdup instead of xstrdup(git_path(...))
+ git_pathdup: returns xstrdup-ed copy of the formatted path
+ Fix potentially dangerous use of git_path in ref.c
+ Add git_snpath: a .git path formatting routine with output buffer
+ Fix potentially dangerous uses of mkpath and git_path
+ Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
+ Add mksnpath which allows you to specify the output buffer
* ar/mksnpath (Thu Oct 30 18:08:58 2008 -0700) 10 commits
+ Merge branch 'ar/maint-mksnpath' into ar/mksnpath
+ Use git_pathdup instead of xstrdup(git_path(...))
+ git_pathdup: returns xstrdup-ed copy of the formatted path
+ Fix potentially dangerous use of git_path in ref.c
+ Add git_snpath: a .git path formatting routine with output buffer
+ Fix potentially dangerous uses of mkpath and git_path
+ Merge branch 'ar/maint-mksnpath' into HEAD
+ Fix potentially dangerous uses of mkpath and git_path
+ Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
+ Add mksnpath which allows you to specify the output buffer
----------------------------------------------------------------
[Will be merged to 'master' soon]
* cj/maint-gitpm-fix-maybe-self (Sat Oct 18 20:25:12 2008 +0200) 1 commit
+ Git.pm: do not break inheritance
Looked Ok; will be in 'master' soon.
* gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
+ gitweb: generate parent..current URLs
+ gitweb: parse parent..current syntax from PATH_INFO
+ gitweb: use_pathinfo filenames start with /
+ gitweb: generate project/action/hash URLs
+ gitweb: parse project/action/hash_base:filename PATH_INFO
Seventh iteration.
* ag/blame-encoding (Wed Oct 22 00:55:57 2008 +0400) 1 commit
+ builtin-blame: Reencode commit messages according to git-log
rules.
Looked Ok; will be in 'master' soon.
* mv/parseopt-checkout-index (Sat Oct 18 03:17:23 2008 +0200) 1 commit
+ parse-opt: migrate builtin-checkout-index.
Looked Ok; will be in 'master' soon.
* sh/rebase-i-p (Wed Oct 22 11:59:30 2008 -0700) 9 commits
+ git-rebase--interactive.sh: comparision with == is bashism
+ rebase-i-p: minimum fix to obvious issues
+ rebase-i-p: if todo was reordered use HEAD as the rewritten parent
+ rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
+ rebase-i-p: only list commits that require rewriting in todo
+ rebase-i-p: fix 'no squashing merges' tripping up non-merges
+ rebase-i-p: delay saving current-commit to REWRITTEN if squashing
+ rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
+ rebase-i-p: test to exclude commits from todo based on its parents
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
* np/index-pack (Thu Oct 23 15:05:59 2008 -0400) 5 commits
+ index-pack: don't leak leaf delta result
+ improve index-pack tests
+ fix multiple issues in index-pack
+ index-pack: smarter memory usage during delta resolution
+ index-pack: rationalize delta resolution code
The buglets that caused people on 'next' some surprises are quickly
killed. Thanks.
----------------------------------------------------------------
[Stalled]
* jk/diff-convfilter (Sun Oct 26 00:50:02 2008 -0400) 8 commits
- enable textconv for diff in verbose status/commit
- wt-status: load diff ui config
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Needs review.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
* jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
+ Fix reading of cloud tags
Request-for-review-and-ack sent; still waiting for response.
----------------------------------------------------------------
[Dropped]
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
. Use xdiff caching to improve git blame performance
. Allow xdiff machinery to cache hash results for a file
. Always initialize xpparam_t to 0
. Bypass textual patch generation and parsing in git blame
. Allow alternate "low-level" emit function from xdl_diff
Réne started code restructuring, which is queued to 'pu'; this series is
dropped.
----------------------------------------------------------------
[On Hold]
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Ian Hilt @ 2008-11-02 21:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20081102093533.GE4066@artemis>
On Sun, 2 Nov 2008, Pierre Habouzit wrote:
> On Sun, Nov 02, 2008 at 06:18:08AM +0000, Junio C Hamano wrote:
> > Having said that, if we were to do this, let's do it the right way and put
> > these "temporary" files under $GIT_DIR.
>
> Agreed, I should have done that.
Perhaps like this:
my $compose_filename = $repo->repo_path() . "/sendemail.msg.$$";
where $repo is a repository instance.
Ian
^ permalink raw reply
* What's in git.git (Nov 2008, #01; Sun, 02)
From: Junio C Hamano @ 2008-11-02 21:35 UTC (permalink / raw)
To: git
There are several topic branches destined for 'maint' that have been
cooking and have graduated to 'master', and I'll make the noise about
1.6.0.4 louder once they are merged, but not yet.
On the 'master' front, there are quite a few git-gui updates.
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (3):
Plug a memleak in builtin-revert
Add --verbose|-v to test-chmtime
Use test-chmtime -v instead of perl in t5000 to get mtime of a file
Charles Bailey (1):
git-archive: work in bare repos
Deskin Miller (2):
git-svn: change dashed git-config to git config
git-svn: change dashed git-commit-tree to git commit-tree
Gustaf Hendeby (1):
git-gui: Help identify aspell version on Windows too
Jakub Narebski (1):
Documentation/gitattributes: Add subsection header for each attribute
Jan Krüger (1):
Documentation: clarify information about 'ident' attribute
Jeff King (4):
correct cache_entry allocation
pack-objects: avoid reading uninitalized data
fix overlapping memcpy in normalize_absolute_path
send-pack: do not send out single-level refs such as refs/stash
Jonas Fonseca (1):
asciidoc: add minor workaround to add an empty line after code blocks
Junio C Hamano (1):
Start 1.6.0.4 cycle
Linus Torvalds (1):
Add file delete/create info when we overflow rename_limit
Markus Heidelberg (1):
bash completion: add doubledash to "git show"
Nanako Shiraishi (1):
Install git-cvsserver in $(bindir)
Pierre Habouzit (1):
git send-email: avoid leaking directory file descriptors.
Thomas Rast (1):
add -p: warn if only binary changes present
Tom Preston-Werner (1):
add instructions on how to send patches to the mailing list with Gmail
Tommi Virtanen (1):
Install git-shell in bindir, too
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (6):
git-gui: Make Ctrl-T safe to use for conflicting files.
git-gui: Fix the blame window shape.
git-gui: Add a search command to the blame viewer.
git-gui: Fix the blame viewer destroy handler.
git-gui: Add a dialog that shows the OpenSSH public key.
git-gui: Add a simple implementation of SSH_ASKPASS.
Christian Stimming (1):
git-gui: Update German translation.
Jan Krüger (1):
Introduce receive.denyDeletes
Joey Hess (1):
git-daemon: set REMOTE_ADDR to client address
Johannes Sixt (6):
git-gui: Do not automatically stage file after merge tool finishes
git-gui: Remove space from the end of aspell's reply before processing
git-gui: Fix switch statement in lib/merge.tcl
git-gui: Show a round number of bytes of large untracked text files
git-gui: Mark-up strings in show_{other,unmerged}_diff() for localization
git-gui: Do not munge conflict marker lines in a normal diff
Junio C Hamano (4):
receive-pack: fix "borrowing from alternate object store" implementation
compat/cygwin.c: make runtime detection of lstat/stat lessor impact
Stop using compat/regex.c on platforms with working regexp library
Update draft release notes to 1.6.1
Petr Baudis (12):
git-gui: Clarify the Remote -> Delete... action
git-gui: Squash populate_{push,fetch}_menu to populate_remotes_menu
git-gui: Add support for adding remotes
git-gui: Add support for removing remotes
git-gui: mkdir -p when initializing new remote repository
git-gui: Use git web--browser for web browsing
git-gui: Add Explore Working Copy to the Repository menu
git-gui: gui.autoexplore makes explorer to pop up automatically after
picking
git-gui: Avoid using the term URL when specifying repositories
git-gui: Make input boxes in init/clone/open dialogs consistent
git-gui: Fix removing non-pushable remotes
git-gui: Fix fetching from remotes when adding them
Shawn O. Pearce (1):
git-gui: Show/hide "Sign Off" based on nocommitmsg option
Tom Preston-Werner (1):
connect.c: add a way for git-daemon to pass an error back to client
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 21:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Sam Vilain, git
In-Reply-To: <20081030132453.GB24098@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> * 'git track' would do what git add -N does now.
> * 'git untrack' would do what 'git rm --cached' does now.
Ok with me up to here.
>> + * 'git undo' would do what 'git checkout HEAD --' does now
> ...
> I have no constructive proposal to replace it though, but I believe git
> undo would cause lots of harm.
I'm in agreement.
> * git-send-email should be either more interactive, or less: either
> just use the damn configuration, or propose a mode where it spawns
> an editor for each patch so that you can add further comments.
In principle I'd agree, but I use send-email non-interactively myself (I
type Meta/SE where Meta is an independent checkout of my 'todo' branch),
so I am not sure if the "just use the configuration" is an added
requirement. I also have this in .git/config in the repo:
[sendemail]
smtpserver = /usr/bin/msmtp
to = git@vger.kernel.org
suppressfrom
signedoffcc = false
> * git-send-email should be able to format-patches by himself (IOW
> accept most of format-patch arguments and deal with the patch list
> by himself, which is usable if the previous point is implemented).
I earlier was against this, mostly out of the "each tool to do the job it
was designed to do well" principle, but with your workflow description and
Peff's comment, I am open to add this kind of "run format-patch internally"
wrapper behaviour to send-email which is already a Porcelain anyway.
>> + * 'git am -3' the default; with global option to make it not the
>> + default for those that prefer the speed of -2
I am moderately negative on this, but not because of performance concern.
The --3way fall back is done only when it is necessary, and there is no
"prefer the speed" involved. It is between "stop when the patch does not
apply because there may be something iffy going on" and "assume it is Ok
in such an iffy case to pretend that you apply the patch to the original
copy and cherry-pick the result to your updated tree". IOW, it is a
safety concern.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 22:01 UTC (permalink / raw)
To: Theodore Tso; +Cc: Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030143918.GB14744@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> Here are my favorites:
>
> * Add the command "git revert-file <files>" which is syntactic sugar for:
>
> git checkout HEAD -- <files>
This is good; I do not recall offhand what we do if some of the <files> do
not appear in HEAD right now, but I have a suspicion that it would be a
no-op, in which case interested parties may first want to fix checkout to
remove such paths.
Also I thiink you can add "git revert-commit [$committish]" as a synonym
to the current "git revert [$committish]" if it makes things easier to
explain to others.
> * Change the argument handling for "git format-patch" so it is
> consistent with everything else which takes a set of commits. Yes,
> it means that where people have gotten used to typing "git
> format-patch origin", they'll have to type instead: "git
> format-patch origin..", but's much more consistent.
I think that has already happened some time ago in the sense that you can
say "origin.." and it does what you want. I do not think it merits to
deprecate the original one --- if you do not like it, you do not use it
nor teach it to others.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 22:17 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Nicolas Pitre, Matthieu Moy, Theodore Tso, Sam Vilain, git
In-Reply-To: <20081030170329.GK24098@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:
>
>> If you have a file argument, the --hard option is redundant, isn't it?
>> So what about simply "git reset <file>" ?
>
> errrrm, git reset <file> resets the index notion of the file to its status
> in HEAD... which I'm sure is *somehow* useful to "some" people ;P
I'd agree that 'reset' is rather unfortunate. It very originally was all
about the index (the "mixed" semantics, specifically "git reset" without
any committish nor any pathspec, was the original use case) and nothing
else. IOW, "I staged a wrong change, let's start over by discarding all
staged changes". A logical extension to it is "git reset -- pathspec",
IOW, "I know which paths I fubared, please reset only these paths, as
other staged changes are Ok".
So "reset <file>" is very much useful.
Then 'reset' learned to also muck with HEAD, so "reset HEAD^" (still
mixed, without any pathspec) can be used to amend the latest commit but
without losing the state you would eventually want to arrive at. A
logical extension to this was "git reset --hard HEAD^" to nuking instead
of amending the mistake, and "git reset --soft HEAD^" to save the trouble
of staging the changes when the mistake you are fixing is small compared
to the entire change.
"checkout [$committish] $path" came much later, and the command is all
about index and files, and never about resetting HEAD. "checkout $path"
does "reset --hard $path" (notice there is no $committish in either one)
would have done, so we stopped enhancing the "reset" command in that
direction.
^ permalink raw reply
* Re: git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Tomi Pakarinen @ 2008-11-02 22:21 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811022203.41092.fg@one2team.net>
CVS's branch does not appear on cvsps's output, until you do a commit
to it. git-cvsimport
relies on cvsps and can not do much about this...
Last problem may arise, if you try to do incremental imports from cvs to git.
For incremental imports you must start import from same location in
cvs each time.
If you have made first import from beginning of history, sequent
imports must start
from there too. Otherwise cvsps will renumber patch sets.
Tomi.
On Sun, Nov 2, 2008 at 11:03 PM, Francis Galiegue <fg@one2team.net> wrote:
> Maybe it's due to the other bug that I reported with git-cvsimport a few days
> ago: namely, it does NOT see branches created by CVS with no commits in them
> (ie, create the branch and that's it, don't touch anything).
>
> The problem is very serious, since it seems to trigger another bug which
> prevents git-cvsimport from working at all. cvsps DOES see the commit
> correctly (branc exists for this file at 1.47.6):
>
> ---
> Members:
>
> src/java/com/one2team/database/bean/impl/relation/reporting/Register.java:1.47->1.47.6.1
> ---
>
> But on the imported git repository, the diff is rather 1.60 -> 1.47.6.1! As a
> result, the repository is plain unusable.
>
> As to the first problem, git finds 6 branches, cvs log finds 8 for the same
> module. git finds 22 tags, cvs log finds 29!
>
> --
> fge
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 22:27 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081031003154.GA5745@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> + * 'git push --matching' does what 'git push' does today (without
>> + explicit configuration)
>
> I think this is reasonable even without other changes, just to override
> any configuration.
I don't. Can't you say "git push $there HEAD" these days? I vaguely
recall that there is a way to configure push that way for people too lazy
to type "origin HEAD" after "git push".
>> + * 'git export' command that does what
>> + 'git archive --format=tar --prefix=dir | tar x' does now
>
> I agree, if you mean "does what ... does now" means "looks to the user
> like ... is happening". This is much more sanely done using
> git-checkout-index (though somebody suggested "remote export", which
> would need to use tar itself).
I think I was neutral in the discussion that led to the removal of
"git-export", but the rationale IIRC was exactly because "git-export" can
be done by simply piping "git-tar" to tar. On the other hand, if all you
had was "export" and you wanted to create a release tar/zip ball, you have
to first create a (potentially huge) hierarchy in the filesystem only to
archive it. This change needs to defend that the benefit of being able to
create a new non-git checkout elsewhere on the filesystem far outweighs
the downside of addition of another command (i.e. "eek, why does git have
that many commands" from new people).
^ permalink raw reply
* Re: git-cvsimport BUG: some commits are completely out of phase (but cvsps sees them all right)
From: Francis Galiegue @ 2008-11-02 22:31 UTC (permalink / raw)
To: tomi.pakarinen; +Cc: git
In-Reply-To: <f299b4f30811021421w2ef43792l7514ab3a0506077a@mail.gmail.com>
Le Sunday 02 November 2008 23:21:44 Tomi Pakarinen, vous avez écrit :
> CVS's branch does not appear on cvsps's output, until you do a commit
> to it. git-cvsimport
> relies on cvsps and can not do much about this...
>
Well, there's another file that cvsps generate (in $HOME/.cvsps) that helps
here and that is named ":<method>:<method_args>:#path#to#cvsroot#modulename."
This file contains the needed information. As far as I can see though,
git-cvsimport does not use it.
> Last problem may arise, if you try to do incremental imports from cvs to
> git. For incremental imports you must start import from same location in
> cvs each time.
> If you have made first import from beginning of history, sequent
> imports must start
> from there too. Otherwise cvsps will renumber patch sets.
>
The plan would be to convert all modules in one go, with no one committing in
the meantime, so that's not a problem.
I'll try and dig a little deeper into git-cvsimport and see if I can make it
use this information...
--
fge
^ permalink raw reply
* Re: commit type
From: bd_ @ 2008-11-02 23:02 UTC (permalink / raw)
To: 7rans; +Cc: git
In-Reply-To: <loom.20081101T034635-562@post.gmane.org>
On Fri, Oct 31, 2008 at 11:15 PM, 7rans <transfire@gmail.com> wrote:
> Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
>
>> So you want to force this onto all Git users?
>
> Not at all. It would be a purely optional. You would never even need to know the
> feature existed if you didn't want to use it. So I'm not sure how that is
> forcing it upon anyone.
>
> Moreover, I suggested it b/c I would find such a feature very useful, and, by
> extension, thought others might as well. Perhaps others have done something
> similar, in which case it would be interesting the hear their take, or on the
> other hand they've never considered it before, but now can consider the
> potential utility of just such a feature.
>
>> If yes: that murmur you hear in the background, it might well be the
>> collective "thanks, but no thanks" of people who do not want that type of
>> distinction between different commits
>
> There is no need to make one. It's purely annotative.
The problem with this approach is that it begins to dictate a set of
annotations which are considered 'more important' by the git core than
others. By allowing in your 'commit type', it sets a precedent that
git will add random, possibly not backwards compatible metadata
changes just to support the local policies of some subset of git
users. It's far better to provide a generic feature that will cover
all users; and using the commit description, with hooks to enforce
proper format according to local policy, is just that.
If using the commit description, with hooks to enforce whatever
formatting you prefer, is not sufficient for your needs, then it would
be useful to discuss exactly how this would be deficient, and then
possibly think about adding a /generic/ feature that meets your needs.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #01; Sun, 02)
From: David Syzdek @ 2008-11-02 23:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David M. Syzdek, pasky
In-Reply-To: <7vbpwx3j7q.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 2, 2008 at 12:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Here are the topics that have been cooking. Commits prefixed
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'.
>
> The topics list the commits in reverse chronological order. The topics
> meant to be merged to the maintenance series have "maint-" in their names.
>
> There are backlog patches I'm planning to deal with later today; they do
> not appear in this list.
>
> ----------------------------------------------------------------
> [New Topics]
>
> * mv/maint-branch-m-symref (Sat Nov 1 00:25:44 2008 +0100) 5 commits
> + update-ref --no-deref -d: handle the case when the pointed ref is
> packed
> + git branch -m: forbid renaming of a symref
> + Fix git update-ref --no-deref -d.
> + rename_ref(): handle the case when the reflog of a ref does not
> exist
> + Fix git branch -m for symrefs.
>
> * rs/blame (Sat Oct 25 15:31:36 2008 +0200) 5 commits
> - blame: use xdi_diff_hunks(), get rid of struct patch
> - add xdi_diff_hunks() for callers that only need hunk lengths
> - Allow alternate "low-level" emit function from xdl_diff
> - Always initialize xpparam_t to 0
> - blame: inline get_patch()
>
> * ds/uintmax-config (Sun Oct 26 03:52:47 2008 -0800) 2 commits
> - Add Makefile check for FreeBSD 4.9-SECURITY
> - Build: add NO_UINTMAX_T to support ancient systems
>
> I amended the topmost one to widen the applicability of this new feature
> to all FreeBSD 4.*, not limited to 4.9-SECURITY; testing before this hits
> 'next' is appreciated.
>
> * ds/autoconf (Sun Nov 2 01:04:46 2008 -0700) 2 commits
> - DONTMERGE: fixup with a convenience macro
> - autoconf: Add link tests to each AC_CHECK_FUNC() test
>
> The topmost one is my attempt to simplify the new way of checking; the
> resulting configure.ac produces the identical configure script with or
> without it, so I think it is Ok, but testing before this hits 'next' is
> appreciated. If all goes well, I think the two should be squashed into
> one patch.
I tested the above changes on FreeBSD. The changes worked on FreeBSD
4.9 worked.
However pthread is linked on FreeBSD 4.x by using `-pthread' instead
of `-lpthread'. The current pu branch forces the use of Pthreads and
links using an invalid flag. I am working on a patch now.
^ permalink raw reply
* [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-02 23:20 UTC (permalink / raw)
To: Andy Parkins, git; +Cc: Pete Harlan
Add configuration option hooks.showrev, letting the user override how
revisions will be shown in the commit email.
Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
This allows, for example, to show full diffs in the post-receive email
to simply after-the-fact reviewing of commits. Perhaps others would
find this useful also.
contrib/hooks/post-receive-email | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 4136895..a365c3f 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -38,6 +38,12 @@
# hooks.emailprefix
# All emails have their subjects prefixed with this prefix, or "[SCM]"
# if emailprefix is unset, to aid filtering
+# hooks.showrev
+# The shell command used to format each revision in the email, with
+# "%s" replaced with the commit id. Defaults to "git rev-list -1
+# --pretty %s", displaying the commit id, author, date and log
+# message. To list full patches separated by a blank line, you
+# could set this to "git show -C %s; echo".
#
# Notes
# -----
@@ -390,8 +396,13 @@ generate_update_branch_email()
echo ""
echo $LOGBEGIN
- git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
- git rev-list --pretty --stdin $oldrev..$newrev
+ git rev-parse --not --branches |
+ grep -v $(git rev-parse $refname) |
+ git rev-list --stdin $oldrev..$newrev |
+ while read onerev
+ do
+ eval $(printf "$showrev" $onerev)
+ done
# XXX: Need a way of detecting whether git rev-list actually
# outputted anything, so that we can issue a "no new
@@ -627,6 +638,7 @@ recipients=$(git config hooks.mailinglist)
announcerecipients=$(git config hooks.announcelist)
envelopesender=$(git config hooks.envelopesender)
emailprefix=$(git config hooks.emailprefix || echo '[SCM] ')
+showrev=$(git config hooks.showrev || echo 'git rev-list -1 --pretty %s')
# --- Main loop
# Allow dual mode: run from the command line just like the update hook, or
--
1.6.0.3.533.ge0502
^ permalink raw reply related
* Re: [PATCH] contrib/hooks/post-receive-email: Make revision display configurable
From: Pete Harlan @ 2008-11-02 23:24 UTC (permalink / raw)
To: Andy Parkins, git
In-Reply-To: <1225668059-12670-1-git-send-email-pgit@pcharlan.com>
Sorry for the repeat emails....this first-time "git send-email" user was
a little surprised that it appears to always cc git@vger...
<hides behind rock>
--Pete
Pete Harlan wrote:
> Add configuration option hooks.showrev, letting the user override how
> revisions will be shown in the commit email.
^ permalink raw reply
* [EGIT PATCH 1/1] Respect background when drawing history in SWT.
From: Robin Rosenberg @ 2008-11-02 23:38 UTC (permalink / raw)
To: Shawn O. Pearce, git
Use transparent text background for drawing text to make the history
look nice when there is a background pattern or effects like alternating
background colors for each row.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../egit/ui/internal/history/SWTPlotRenderer.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
index 23ec255..c4ee282 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
@@ -89,7 +89,7 @@ protected void drawText(final String msg, final int x, final int y) {
final int texty = (y * 2 - textsz.y) / 2;
g.setForeground(cellFG);
g.setBackground(cellBG);
- g.drawString(msg, cellX + x, cellY + texty);
+ g.drawString(msg, cellX + x, cellY + texty, true);
}
protected Color laneColor(final SWTLane myLane) {
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* [PATCH] Make Pthread link flags configurable
From: david.syzdek @ 2008-11-02 23:43 UTC (permalink / raw)
To: git; +Cc: David M. Syzdek
From: David M. Syzdek <david.syzdek@acsalaska.net>
FreeBSD 4.x systems use the linker flags `-pthread' instead of the
linker flags `-lpthread' when linking against the pthread library.
Signed-off-by: David M. Syzdek <david.syzdek@acsalaska.net>
---
Makefile | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 489774d..6737cb0 100644
--- a/Makefile
+++ b/Makefile
@@ -229,6 +229,7 @@ INSTALL = install
RPMBUILD = rpmbuild
TCL_PATH = tclsh
TCLTK_PATH = wish
+PTHREAD_LIBS = -lpthread
export TCL_PATH TCLTK_PATH
@@ -691,6 +692,7 @@ ifeq ($(uname_S),FreeBSD)
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
THREADED_DELTA_SEARCH = YesPlease
ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
+ PTHREAD_LIBS = -pthread
NO_UINTMAX_T = YesPlease
NO_STRTOUMAX = YesPlease
endif
@@ -1017,7 +1019,7 @@ endif
ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
- EXTLIBS += -lpthread
+ EXTLIBS += $(PTHREAD_LIBS)
LIB_OBJS += thread-utils.o
endif
ifdef DIR_HAS_BSD_GROUP_SEMANTICS
--
1.6.0.2.GIT
^ permalink raw reply related
* [EGIT PATCH 1/1] Some error handling for GitDocument
From: Robin Rosenberg @ 2008-11-02 23:46 UTC (permalink / raw)
To: Shawn O. Pearce, git
We sometimes (rarely) gets errors from unresolvable trees. Do not just
throw a NullPointerException.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
This is primarily necessary to track down a rare problem, but we
should have error handling here anyway.
.../egit/ui/internal/decorators/GitDocument.java | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
index 3724304..6e10144 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
@@ -21,6 +21,7 @@
import org.spearce.jgit.lib.RefsChangedEvent;
import org.spearce.jgit.lib.Repository;
import org.spearce.jgit.lib.RepositoryListener;
+import org.spearce.jgit.lib.Tree;
import org.spearce.jgit.lib.TreeEntry;
class GitDocument extends Document implements RepositoryListener {
@@ -52,7 +53,14 @@ void populate() throws IOException {
String baseline = GitQuickDiffProvider.baseline.get(repository);
if (baseline == null)
baseline = "HEAD";
- TreeEntry blobEnry = repository.mapTree(baseline).findBlobMember(gitPath);
+ Tree baselineTree = repository.mapTree(baseline);
+ if (baselineTree == null) {
+ Activator.logError("Could not resolve quickdiff baseline "
+ + baseline + " corresponding to " + resource + " in "
+ + repository, new Throwable());
+ return;
+ }
+ TreeEntry blobEnry = baselineTree.findBlobMember(gitPath);
if (blobEnry != null) {
Activator.trace("(GitQuickDiffProvider) compareTo: " + baseline);
ObjectLoader loader = repository.openBlob(blobEnry.getId());
--
1.6.0.3.578.g6a50
^ permalink raw reply related
* PHP購物車資料庫網站專案
From: 姚佳真 @ 2008-11-02 23:57 UTC (permalink / raw)
To: gipsylisa
山鉧科技網頁設計
我們的宗旨：客戶的每ㄧ件小事情，都是山鉧的大事情
我們在推出企業形象網站包含前台網頁美工+後台管理程式
限時限量專案價 只要$29,900
(在送ㄧ年100MB不限流量網站空間)
我們做的不只是網站，而是您企業的入口
ㄧ個好的企業網站資料即時更新的速度是很重要的
企業ｅ化的高品質團隊，打造您的網路門面
選擇山鉧成就您的夢想
～～～～～～～～～～～～～～～～～～～～～～～～～～
PS: 線上購物網站我們還可提供刷卡機制，
與線上列印帳單全省超商+郵局繳費......等金流服務機制
～～～～～～～～～～～～～～～～～～～～～～～～～～
歡迎來電洽詢黃專員（Sam）：0980119812 / 0938764395
上網搜尋『 網頁設計山鉧 』即可找到我們
～～～～～～～～～～～～～～～～～～～～～～～～～～
本公司另外提供關鍵字SEO排序服務
保證將您的網站在Yx / Gx ...排在第一頁
歡迎來電詢問!!!
～～～～～～～～～～～～～～～～～～～～～～～～～～
^ permalink raw reply
* [RFC PATCH] git-svn: proper detection of bare repositories
From: Deskin Miller @ 2008-11-03 0:09 UTC (permalink / raw)
To: git; +Cc: normalperson
I keep coming across commands like this, which don't work properly in bare
repositories, and thinking that they need to be patched (see e.g. ddff8563, or
Duy's comments on the thread starting at
http://thread.gmane.org/gmane.comp.version-control.git/98849), but now I'm not
so sure. For one, despite this patch working, it turns out that 'git --bare
svn <cmd>' also works (and presumably has) for some time.
Is git --bare the correct way to deal with this situation? That is to say, do
we intend commands to 'just work' regardless of whether the repo is bare or
not, or should the user be thinking about the difference and including --bare
in the command invocation when necessary? I'm a vote for the 'just work' camp,
but it seems a lot of things aren't necessarily that way. On the other hand,
the majority of commands do just work.
I guess I'm asking for a sanity check before I write any more such patches;
certainly I find them useful, as the issues come up during my normal use of
Git, but I don't want to be pursuing things of no use to anyone else, or
(worse) things that are fundamentally wrong for some reason I don't understand
yet.
-- 8< --
When in a bare repository (or .git, for that matter), git-svn would fail
to initialise properly, since git rev-parse --show-cdup would not output
anything. However, git rev-parse --show-cdup actually returns an error
code if it's really not in a git directory.
Fix the issue by checking for an explicit error from git rev-parse, and
setting $git_dir appropriately if instead it just does not output.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
git-svn.perl | 14 ++++++++++----
t/t9100-git-svn-basic.sh | 9 +++++++++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 56238da..d25e9be 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -42,6 +42,7 @@ use File::Path qw/mkpath/;
use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/;
use IPC::Open3;
use Git;
+use Error qw/:try/;
BEGIN {
# import functions from Git into our packages, en masse
@@ -214,11 +215,16 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
"but it is not a directory\n";
}
my $git_dir = delete $ENV{GIT_DIR};
- chomp(my $cdup = command_oneline(qw/rev-parse --show-cdup/));
- unless (length $cdup) {
- die "Already at toplevel, but $git_dir ",
- "not found '$cdup'\n";
- }
+ my $cdup = undef;
+ try {
+ $cdup = command_oneline(qw/rev-parse --show-cdup/);
+ $git_dir = '.' unless ($cdup);
+ chomp $cdup if ($cdup);
+ $cdup = "." unless ($cdup && length $cdup);
+ }
+ catch Git::Error::Command with {
+ die "Already at toplevel, but $git_dir not found\n";
+ };
chdir $cdup or die "Unable to chdir up to '$cdup'\n";
unless (-d $git_dir) {
die "$git_dir still not found after going to ",
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 843a501..fdbc23a 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -265,4 +265,13 @@ test_expect_success 'able to set-tree to a subdirectory' "
test -z \"\`git diff refs/heads/my-bar refs/remotes/bar\`\"
"
+test_expect_success 'git-svn works in a bare repository' '
+ mkdir bare-repo &&
+ ( cd bare-repo &&
+ git init --bare &&
+ GIT_DIR=. git svn init "$svnrepo" &&
+ git svn fetch ) &&
+ rm -rf bare-repo
+ '
+
test_done
--
1.6.0.3.524.g47d14
^ permalink raw reply related
* Re: [PATCH] asciidoc: add minor workaround to add an empty line after code blocks
From: Kalle Olavi Niemitalo @ 2008-11-03 0:12 UTC (permalink / raw)
To: git
In-Reply-To: <18071eea0811011642g6bc36530sf2036ef15ce0df82@mail.gmail.com>
"Thomas Adam" <thomas.adam22@gmail.com> writes:
> Something the ELinks project does is distribute a fixed version
> of the asciidoc script to avoid annoying asciidoc errors each
> time there's a new asciidoc release.
Actually, we only distribute the AsciiDoc configuration files.
I should perhaps add the actual asciidoc Python script to the
ELinks source tree as well. That seems to be the recommendation
in the AsciiDoc manual.
http://www.methods.co.nz/asciidoc/userguide.html#_shipping_stand_alone_asciidoc_source
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Geoff Russell @ 2008-11-03 1:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810291610340.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Thu, Oct 30, 2008 at 1:40 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 29 Oct 2008, Geoff Russell wrote:
>
>> I want to export "the last N days" of a repository to create a copy
>> which has an origin which is the state of the repository N days ago and
>> has all the history between then and now.
>>
>> Can fast-export do this?
>
> Yes. See the --since=... option.
Sorry, I didn't explain what I want very well. N days ago I had a
working directory in
a state S with files F1,F2,F3,... I want to dump all the history
before then so that
this is my new starting point, so I want to keep all changes since
then. In general,
this is impossible if there are multiple branches which influence what
happens between
N and now, but in the simple non-branching case it should be possible.
Fast-export with From..To revisions (or with --since=...) just gives changes
since the point N days ago.
Basically I'm trying to do an "rcs -o:1.xyz" where xyz is
a version and I want to prune before that to shrink a large and unwanted
history.
Thanks,
Geoff Russell
>
> Hth,
> Dscho
>
>
--
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069
^ permalink raw reply
* Re: commit type
From: 7rans @ 2008-11-03 1:34 UTC (permalink / raw)
To: git
In-Reply-To: <3e8340490811021502p70ab40a1ocdc9fca012769a29@mail.gmail.com>
bd_ <bdonlan <at> gmail.com> writes:
> The problem with this approach is that it begins to dictate a set of
> annotations which are considered 'more important' by the git core than
> others. By allowing in your 'commit type', it sets a precedent that
> git will add random, possibly not backwards compatible metadata
> changes just to support the local policies of some subset of git
> users. It's far better to provide a generic feature that will cover
> all users; and using the commit description, with hooks to enforce
> proper format according to local policy, is just that.
>
> If using the commit description, with hooks to enforce whatever
> formatting you prefer, is not sufficient for your needs, then it would
> be useful to discuss exactly how this would be deficient, and then
> possibly think about adding a /generic/ feature that meets your needs.
Except for going so far as to add full-on tagging to commits, I'd don't see how
it could be more generic. Perhaps I'm misunderstood. I'm not suggesting any
particular set of types, if that's what you think. Just the ability to add one.
For example:
git commit -m "describe some change" --type anything-at-all
So the types *I* would use are 'major', 'minor' and 'bug', but others could use
whatever types they'd like. Ie. developers could have their one type policies.
And I agree, it would be cool to define hooks to enforce the policy.
The problem with adding them to the description is that other tools have no idea
about them and so can't not display them when they aren't wanted --a logging
tool is a good example. It is also means more complicated scripting is required
to do anything with them, not a huge deal, but a pita nonetheless.
^ permalink raw reply
* error: non-monotonic index
From: Peter Teoh @ 2008-11-03 2:32 UTC (permalink / raw)
To: git
I git pull and got errors, then git repack and pull again......the
error increased....what happened?
/hdc1/download/2.6/linux26-acer>git pull
remote: Counting objects: 3959, done.
remote: Compressing objects: 100% (668/668), done.
remote: Total 2422 (delta 1934), reused 2154 (delta 1702)
Receiving objects: 100% (2422/2422), 409.97 KiB | 8 KiB/s, done.
Resolving deltas: 100% (1934/1934), completed with 757 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
e946217..45beca0 master -> origin/master
* [new tag] v2.6.28-rc3 -> v2.6.28-rc3
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
fatal: Needed a single revision
45beca08dd8b6d6a65c5ffd730af2eac7a2c7a03 - not something we can merge
/hdc1/download/2.6/linux26-acer>git repack
Counting objects: 9, done.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), done.
Total 9 (delta 0), reused 0 (delta 0)
/hdc1/download/2.6/linux26-acer>git pull
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
error: non-monotonic index
fatal: Needed a single revision
45beca08dd8b6d6a65c5ffd730af2eac7a2c7a03 - not something we can merge
--
Regards,
Peter Teoh
^ permalink raw reply
* [Announce] teamGit v0.0.4
From: Abhijit Bhopatkar @ 2008-11-03 3:22 UTC (permalink / raw)
To: git; +Cc: bain
Hi people,
I have just tagged the teamgit repo as v0.0.4
The improvements over v0.0.3 include
rudimentary blame support, sign-off support, apply-mailbox support,
send patch using desktop email client service support (makes mailto:
request to desktop service).
One minor but "i find it really usefull" features is that if you
select a commit in log and quit, it will print the commit hash to
stdout.
So now you can embed it in git commands or scirpts to fire up a visual
commit selection,
like
git-show `teamigt ./` will show the selected commit etc.
This is really helpful and (correct me if i am wrong) i couldn't find
other gui that does this, may be will be a good addition to gitk?
Links:
http://www.devslashzero.com/teamgit
http://www.devslashzero.com/teamgit/download
Abhijit,
Short log follows
---
Abhijit Bhopatkar (36):
Added .desktop file and icons to install target
Added support files for running checkinstall
Don't depend on qt 4.4.1 we can do with just 4.4
Changed the signoff check box label
Added auto "add sign off line" to commit
Added auto sign off option to general settings
Added auto sign off option in settings
Change libqt-core to libqtcore4 for intrepid in checkinstall
script
Make default new project directory ~/linux-2.6
Add base dir selection for new project dialog
Current project is no longer used
Add base dir selection to the new projects dialog
Fix new project stuff to open up correct repo after clone
Cleaned up icons directory
Removed unneeded icon pngs
Qdevelop cleaned up the project fine
Added git blam support to backend gitprocess
Added file annotation support with commit search
Make sure first column is visible when searching
Scrool annotation text box to top after receiving annotaion
Cleanup: we no longer use mutex
Bring annotated file to front when received
FIX: Open dialog failed to refresh the UI
Added apply mailbox function to git process backend
Added support to push to a selected remote
Removed an uneeded debug output message
Added apply mail action in tools
Added apply mail functionality
Fix: apply mail didn't use the file provided in path and did
nothing
Fix: Make apply mail actully store the last path for it to
remember later
Fix: apply mail did not refresh after operation completed
Added send patch by email functionality
Added send patch by mail in toolbar menu
Activated send patch by mail menu action
Added quit action to file menu and activated it
teamGit will now print sha id of the selected commit while
exiting to stdout
Horst H. von Brand (1):
Fix typo in src/mainwindowimpl.cpp
^ permalink raw reply
* Re: [PATCH] filter-branch: add git_commit_non_empty_tree and --prune-empty.
From: Junio C Hamano @ 2008-11-03 4:58 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, pasky, srabbelier
In-Reply-To: <1225445204-28000-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> +case "$prune_empty,$filter_commit" in
> +',')
> + filter_commit='git commit-tree "$@"';;
> +'t,')
> + filter_commit="$functions;"' git_commit_non_empty_tree "$@"';;
> +','*)
> + ;;
> +*)
> + die "Cannot set --prune-empty and --filter-commit at the same time"
> +esac
This is only style issue, but I find the above extremely difficult to
read. If it were either:
case ... in
,) do "neither set case" ;;
t,) do "prune but not filter case" ;;
*) do "both set case" ;;
esac
or (rather amateurish but conveys what it wants to do more clearly):
case ... in
'','') do "neither set case" ;;
t,'') do "prune but not filter case" ;;
t,t) do "both set case" ;;
esac
I wouldn't have to wonder which sq pairs with which one.
> diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
> index b0a9d7d..352b56b 100755
> --- a/t/t7003-filter-branch.sh
> +++ b/t/t7003-filter-branch.sh
> @@ -262,4 +262,12 @@ test_expect_success 'Tag name filtering allows slashes in tag names' '
> test_cmp expect actual
> '
>
> +test_expect_success 'Prune empty commits' '
> + make_commit to_remove &&
> + (git rev-list HEAD | grep -v $(git rev-parse HEAD)) > expect &&
I am not sure what this one is doing.
- Isn't this the same as "git rev-list HEAD^"?
- Do you need a subshell?
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Sam Vilain @ 2008-11-03 5:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <7v3ai9226q.fsf@gitster.siamese.dyndns.org>
On Sun, 2008-11-02 at 14:27 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> + * 'git push --matching' does what 'git push' does today (without
> >> + explicit configuration)
> >
> > I think this is reasonable even without other changes, just to override
> > any configuration.
>
> I don't. Can't you say "git push $there HEAD" these days? I vaguely
> recall that there is a way to configure push that way for people too lazy
> to type "origin HEAD" after "git push".
I don't think it's about laziness, it's more about making sure that
without specifying behaviour, the action of the command is conservative.
Pushing all matching refs is not conservative; it's "magic". And in my
experience, people get bitten by it, because they think, "ok, time to
push this branch", type "git push" and then a lot more than they
expected gets pushed.
I can see that some people want this behaviour by default; but to me
"push the current branch back to where it came from" seems like far more
a rational default for at least 90% of users.
Sam.
^ 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