* Re: git clean --exclude broken?
From: Todd Rinaldo @ 2011-08-24 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vliuio65w.fsf@alter.siamese.dyndns.org>
On Aug 24, 2011, at 4:23 PM, Junio C Hamano wrote:
> Todd Rinaldo <toddr@cpanel.net> writes:
>
>> I think I have found a new bug in 1.7.5:
>
> My quick check indicates 1.7.3 behaves the same way, and 1.7.2.5 didn't
> have --exclude option, so this does not seem to be anything particularly
> new in the 1.7.5 release.
No. I was just clarifying what my binary was for research purposes.
>
>> # The problem (Why is foo/ removed?)
>> $>git clean -dXf --exclude=/foo
>> Removing bar/
>> Removing foo/
>
> Why is this command line giving -X that tells us not to use the ignore
> rules, and --exclude option at the same time?
My more complicated use of the command wanted to use the .gitignore rules to cleanup ignored files with the exception of 1 directory. I believe -dxf --exclude is also broken in the same way.
^ permalink raw reply
* Re: Problem with S_IFGITLINK
From: Nguyen Thai Ngoc Duy @ 2011-08-24 23:15 UTC (permalink / raw)
To: Adam Kłobukowski; +Cc: Michael J Gruber, git
In-Reply-To: <4E551904.303@gmail.com>
2011/8/24 Adam Kłobukowski <adamklobukowski@gmail.com>:
> I may try to implement it, but I my knowledge of Git internals is equal to
> zero. If someone can point me what has to be done - I'll be gratefull.
Git stores mode in the index (struct cache_entry#ce_mode, cache.h) and
in tree objects (see tree-walk.c). Basically you define a new set of
S_IS* and S_IF* macros and use them instead of standard ones.
Translations from struct stat#st_mode will be needed, I think
ce_mode_from_stat() does that job.
So:
- read index and checkout: entry.c
- read and update index: read-cache.c
- read tree objects: tree-walk.c
- write tree objects: cache-tree.c
- anywhere that checks struct cache_entry#ce_mode needs to convert to
use the new defines
Another way, less changes, is redefine S_IS* and S_IF* and ignore
system values. Then make wrapper for stat() and lstat(), convert
system values to git values. You can put these wrappers in compat
directory. See git-compat-util.h, mingw port for example already
redefine these functions for Windows platform.
--
Duy
^ permalink raw reply
* [ANNOUNCE] Git 1.7.6.1
From: Junio C Hamano @ 2011-08-24 23:51 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git 1.7.6.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.7.6.1.tar.{gz,bz2} (source tarball)
git-htmldocs-1.7.6.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.7.6.1.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.7.6.1-1.fc13.$arch.rpm (RPM)
Git v1.7.6.1 Release Notes
==========================
Fixes since v1.7.6
------------------
* Various codepaths that invoked zlib deflate/inflate assumed that these
functions can compress or uncompress more than 4GB data in one call on
platforms with 64-bit long, which has been corrected.
* "git unexecutable" reported that "unexecutable" was not found, even
though the actual error was that "unexecutable" was found but did
not have a proper she-bang line to be executed.
* Error exits from $PAGER were silently ignored.
* "git checkout -b <branch>" was confused when attempting to create a
branch whose name ends with "-g" followed by hexadecimal digits,
and refused to work.
* "git checkout -b <branch>" sometimes wrote a bogus reflog entry,
causing later "git checkout -" to fail.
* "git diff --cc" learned to correctly ignore binary files.
* "git diff -c/--cc" mishandled a deletion that resolves a conflict, and
looked in the working tree instead.
* "git fast-export" forgot to quote pathnames with unsafe characters
in its output.
* "git fetch" over smart-http transport used to abort when the
repository was updated between the initial connection and the
subsequent object transfer.
* "git fetch" did not recurse into submodules in subdirectories.
* "git ls-tree" did not error out when asked to show a corrupt tree.
* "git pull" without any argument left an extra whitespace after the
command name in its reflog.
* "git push --quiet" was not really quiet.
* "git rebase -i -p" incorrectly dropped commits from side branches.
* "git reset [<commit>] paths..." did not reset the index entry correctly
for unmerged paths.
* "git submodule add" did not allow a relative repository path when
the superproject did not have any default remote url.
* "git submodule foreach" failed to correctly give the standard input to
the user-supplied command it invoked.
* submodules that the user has never showed interest in by running
"git submodule init" was incorrectly marked as interesting by "git
submodule sync".
* "git submodule update --quiet" was not really quiet.
* "git tag -l <glob>..." did not take multiple glob patterns from the
command line.
----------------------------------------------------------------
Changes since v1.7.6 are as follows:
Alex Neronskiy (2):
Fix documentation of fetch-pack that implies that the client can disconnect after sending wants.
Document the underlying protocol used by shallow repositories and --depth commands.
Andrew Wong (1):
rebase -i -p: include non-first-parent commits in todo list
Bert Wesarg (1):
Documentation: clearly specify what refs are honored by core.logAllRefUpdates
Brandon Casey (2):
t/t7407: demonstrate that the command called by 'submodule foreach' loses stdin
git-submodule.sh: preserve stdin for the command spawned by foreach
Brian Harring (1):
get_indexed_object can return NULL if nothing is in that slot; check for it
Carlos Martín Nieto (1):
Documentation: clarify the invalidated tree entry format
Clemens Buchacher (3):
error_routine: use parent's stderr if exec fails
propagate --quiet to send-pack/receive-pack
notice error exit from pager
Dmitry Ivankov (1):
doc/fast-import: clarify notemodify command
Emilio G. Cota (2):
Documentation: ignore *.pdf files
Documentation/Makefile: add *.pdf to `clean' target
Erik Faye-Lund (1):
connect: correctly number ipv6 network adapter
Fredrik Kuivinen (1):
Makefile: Track changes to LDFLAGS and relink when necessary
Heiko Voigt (2):
add gitignore entry to description about how to write a builtin
add technical documentation about ref iteration
Jack Nagel (1):
Documentation: minor grammatical fix in rev-list-options.txt
Jakub Narebski (2):
gitweb: Serve text/* 'blob_plain' as text/plain with $prevent_xss
gitweb: Serve */*+xml 'blob_plain' as text/plain with $prevent_xss
Jeff King (10):
combine-diff: split header printing into its own function
combine-diff: calculate mode_differs earlier
combine-diff: handle binary files as binary
refactor get_textconv to not require diff_filespec
combine-diff: respect textconv attributes
tag: accept multiple patterns for --list
docs: document --textconv diff option
t7400: fix bogus test failure with symlinked trash
fast-export: quote paths in output
am: refresh the index at start and --resolved
Jens Lehmann (7):
submodule add: test failure when url is not configured in superproject
submodule add: allow relative repository path even when no url is set
submodule add: clean up duplicated code
fetch: Also fetch submodules in subdirectories in on-demand mode
submodule add: always initialize .git/config entry
tests: print failed test numbers at the end of the test run
submodule: update and add must honor --quiet flag
Johannes Schindelin (1):
get_pwd_cwd(): Do not trust st_dev/st_ino blindly
Jon Seymour (2):
Add a test to check that git ls-tree sets non-zero exit code on error.
Ensure git ls-tree exits with a non-zero exit code if read_tree_recursive fails.
Julian Phillips (1):
remote-curl: Add a format check to parsing of info/refs
Junio C Hamano (29):
diff-index --quiet: learn the "stop feeding the backend early" logic
checkout -b <name>: correctly detect existing branch
sha1_file.c: "legacy" is really the current format
zlib wrapper: refactor error message formatter
zlib: wrap remaining calls to direct inflate/inflateEnd
zlib: wrap inflateInit2 used to accept only for gzip format
zlib: wrap deflate side of the API
zlib: wrap deflateBound() too
zlib: zlib can only process 4GB at a time
zlib: allow feeding more than 4GB in one go
t/gitweb-lib.sh: skip gitweb tests when perl dependencies are not met
cygwin: trust executable bit by default
git-remote.txt: avoid sounding as if loose refs are the only ones in the world
check-ref-format doc: de-emphasize the implementation detail of a ref
git.txt: de-emphasize the implementation detail of a ref
glossary: update description of "tag"
glossary: update description of head and ref
glossary: clarify description of HEAD
submodule sync: do not auto-vivify uninteresting submodule
"branch -d" can remove more than one branches
test: skip clean-up when running under --immediate mode
checkout: do not write bogus reflog entry out
reset [<commit>] paths...: do not mishandle unmerged paths
diff -c/--cc: do not mistake "resolved as deletion" as "use working tree"
receive-pack: do not overstep command line argument array
helping smart-http/stateless-rpc fetch race
Prepare for 1.7.6.1
Update draft release notes for 1.7.6.1
Git 1.7.6.1
Martin von Zweigbergk (2):
Documentation: use [verse] for SYNOPSIS sections
rebase: clarify "restore the original branch"
Michael Haggerty (6):
git-svn: Demonstrate a bug with root commits in mergeinfo ranges
git-svn: Disambiguate rev-list arguments to improve error message
git-svn: Correctly handle root commits in mergeinfo ranges
gitattributes: Clarify discussion of attribute macros
gitattributes: Reword "attribute macro" to "macro attribute"
Do not use C++-style comments
Michael Schubert (1):
help_unknown_cmd: do not propose an "unknown" cmd
Michael Witten (1):
filter-branch: Export variable `workdir' for --commit-filter
Namhyung Kim (1):
git-remote.txt: fix wrong remote refspec
Nguyễn Thái Ngọc Duy (3):
Break down no-lstat() condition checks in verify_uptodate()
checkout-index: remove obsolete comment
fetch-pack: check for valid commit from server
Ori Avtalion (1):
pull: remove extra space from reflog message
Pavan Kumar Sunkara (1):
git-config: Remove extra whitespaces
Peter Collingbourne (1):
Documentation: git-filter-branch honors replacement refs
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2011-08-24 23:51 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites as well:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work". "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken". It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).
Please remember to always state
- what you wanted to do;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen;
- what you expected to see; and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:
git://repo.or.cz/alt-git.git/
Impatient people might have better luck with the latter one (there are a
few other mirrors I push into at sourceforge and github as well).
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".
The "html" and "man" are auto-generated documentation from the tip of
the "master" branch; the tip of "html" is extracted to be visible at
kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The above URL is the top-level documentation page, and it has links to
documentation of older releases.
The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script to maintain the two documentation branches are
found there as dodoc.sh, which may be a good demonstration of how to
use a post-update hook to automate a task after pushing into a
repository.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.7.6 done on
June 26, 2011. You can expect that the tip of the "master" branch is
always more stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.6.1. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).
The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master", or a
topic that already was in "next" was reverted from "next" because fatal
flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong, David D. Kilzer and Sam Vilain on git-svn.
- Simon Hausmann and Pete Wyckoff on git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
gitweb.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard on Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund and others for their
effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
^ permalink raw reply
* What's cooking in git.git (Aug 2011, #07; Wed, 24)
From: Junio C Hamano @ 2011-08-25 0:09 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
I've sifted topics to the ones meant for 1.7.7 and the others that I'd
prefer to cook a bit longer in "next" during the upcoming feature freeze,
which should happen by the end of the week.
Please help us make the upcoming release as solid as we could. Thanks.
--------------------------------------------------
[Stalled]
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Needs documentation updates.
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* jc/merge-reword (2011-05-25) 1 commit
(merged to 'next' on 2011-08-24 at aa5cf7b)
+ merge: reword the final message
Will merge to "master".
* nk/branch-v-abbrev (2011-07-01) 1 commit
(merged to 'next' on 2011-08-24 at e9152cf)
+ branch -v: honor core.abbrev
Will merge to "master".
* jk/pager-with-external-command (2011-08-19) 1 commit
(merged to 'next' on 2011-08-24 at 083f5da)
+ support pager.* for external commands
(this branch is used by jk/pager-with-alias and jk/pager-with-alias; uses jk/color-and-pager.)
Up to this part (but not "alias") the topic looked unconditionally a good
thing to do.
Will aim to merge to "master" by -rc1.
* fk/use-kwset-pickaxe-grep-f (2011-08-20) 5 commits
(merged to 'next' on 2011-08-23 at 93ba509)
+ Use kwset in grep
+ Use kwset in pickaxe
+ Adapt the kwset code to Git
+ Add string search routines from GNU grep
+ Add obstack.[ch] from EGLIBC 2.10
Will aim to merge to "master" by -rc1.
* jc/maint-autofix-tag-in-head (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at 18cee02)
+ commit: reduce use of redundant global variables
Will merge to "master".
* bw/doc-repo-layout (2011-08-23) 2 commits
(merged to 'next' on 2011-08-24 at 605c730)
+ Mark http-fetch without -a as deprecated
+ Documentation: Grammar correction, wording fixes and cleanup
Will merge to "master".
* ci/forbid-unwanted-current-branch-update (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at 1e93b67)
+ Show interpreted branch name in error messages
+ Prevent force-updating of the current branch
Will aim to merge to "master" by -rc1.
* di/fast-import-blob-tweak (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at 52eef2a)
+ fast-import: treat cat-blob as a delta base hint for next blob
+ fast-import: count and report # of calls to diff_delta in stats
Will aim to merge to "master" by -rc1.
* di/fast-import-tagging (2011-08-23) 2 commits
(merged to 'next' on 2011-08-24 at 67e0937)
+ fast-import: allow to tag newly created objects
+ fast-import: add tests for tagging blobs
Will aim to merge to "master" by -rc1.
* di/fast-import-deltified-tree (2011-08-14) 2 commits
(merged to 'next' on 2011-08-23 at ee30265)
+ fast-import: prevent producing bad delta
+ fast-import: add a test for tree delta base corruption
Will aim to merge to "master" by -rc1.
* di/fast-import-ident (2011-08-11) 5 commits
(merged to 'next' on 2011-08-23 at 9b86391)
+ fsck: improve committer/author check
+ fsck: add a few committer name tests
+ fast-import: check committer name more strictly
+ fast-import: don't fail on omitted committer name
+ fast-import: add input format tests
Will aim to merge to "master" by -rc1.
* di/fast-import-doc (2011-08-17) 1 commit
(merged to 'next' on 2011-08-23 at dab4088)
+ doc/fast-import: document feature import-marks-if-exists
Will merge to "master".
* jc/combine-diff-callback (2011-08-20) 1 commit
(merged to 'next' on 2011-08-24 at 9f9b42d)
+ combine-diff: support format_callback
(this branch is used by fg/submodule-ff-check-before-push.)
Will merge to "master".
* jc/maint-clone-alternates (2011-08-23) 2 commits
(merged to 'next' on 2011-08-23 at 7280deb)
+ clone: clone from a repository with relative alternates
+ clone: allow more than one --reference
Will aim to merge to "master" by -rc1.
* nd/maint-clone-gitdir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at cbf052b)
+ clone: allow to clone from .git file
+ read_gitfile_gently(): rename misnamed function to read_gitfile()
Will aim to merge to "master" by -rc1.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
Not urgent; will not be in 1.7.7.
* rc/diff-cleanup-records (2011-08-17) 2 commits
(merged to 'next' on 2011-08-23 at b8414f5)
+ Merge branch 'rc/histogram-diff' into HEAD
+ xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
Will aim to merge to "master" by -rc1.
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
Not urgent; will not be in 1.7.7.
* jk/color-and-pager (2011-08-19) 10 commits
(merged to 'next' on 2011-08-23 at cbb9495)
+ want_color: automatically fallback to color.ui
+ diff: don't load color config in plumbing
+ config: refactor get_colorbool function
+ color: delay auto-color decision until point of use
+ git_config_colorbool: refactor stdout_is_tty handling
+ diff: refactor COLOR_DIFF from a flag into an int
+ setup_pager: set GIT_PAGER_IN_USE
+ t7006: use test_config helpers
+ test-lib: add helper functions for config
+ t7006: modernize calls to unset
(this branch is used by jk/pager-with-alias and jk/pager-with-external-command.)
Will aim to merge to "master" by -rc1.
* jk/pager-with-alias (2011-08-19) 1 commit
- support pager.* for aliases
(this branch uses jk/color-and-pager, jk/pager-with-external-command and jk/pager-with-external-command.)
Perhaps will drop.
* nd/decorate-grafts (2011-08-19) 5 commits
(merged to 'next' on 2011-08-23 at 475d27e)
+ log: decorate "replaced" on to replaced commits
+ log: decorate grafted commits with "grafted"
+ Move write_shallow_commits to fetch-pack.c
+ Add for_each_commit_graft() to iterate all grafts
+ decoration: do not mis-decorate refs with same prefix
Will aim to merge to "master" by -rc1.
* va/p4-branch-import (2011-08-22) 4 commits
(merged to 'next' on 2011-08-24 at f67f8af)
+ git-p4: Add simple test case for branch import
+ git-p4: Allow branch definition with git config
+ git-p4: Allow filtering Perforce branches by user
+ git-p4: Correct branch base depot path detection
(this branch uses va/p4-rename-copy.)
Will merge to "master".
* va/p4-rename-copy (2011-08-22) 5 commits
(merged to 'next' on 2011-08-24 at f1faa94)
+ git-p4: Process detectCopiesHarder with --bool
+ git-p4: Add test case for copy detection
+ git-p4: Add test case for rename detection
+ git-p4: Add description of rename/copy detection options
+ git-p4: Allow setting rename/copy detection threshold
(this branch is used by va/p4-branch-import.)
Will merge to "master".
* da/difftool-mergtool-refactor (2011-08-19) 4 commits
(merged to 'next' on 2011-08-23 at a1cc3be)
+ mergetools/meld: Use '--output' when available
+ mergetool--lib: Refactor tools into separate files
+ mergetool--lib: Make style consistent with git
+ difftool--helper: Make style consistent with git
Will merge to "master".
* mg/branch-set-upstream-previous (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at acef0b6)
+ branch.c: use the parsed branch name
Will merge to "master".
* di/parse-options-split (2011-08-11) 2 commits
(merged to 'next' on 2011-08-23 at 6cd667f)
+ Reduce parse-options.o dependencies
+ parse-options: export opterr, optbug
Will merge to "master".
* mh/attr (2011-08-14) 7 commits
(merged to 'next' on 2011-08-23 at 22faa6e)
+ Unroll the loop over passes
+ Change while loop into for loop
+ Determine the start of the states outside of the pass loop
+ Change parse_attr() to take a pointer to struct attr_state
+ Increment num_attr in parse_attr_line(), not parse_attr()
+ Document struct match_attr
+ Add a file comment
Will aim to merge to "master" by -rc1.
* mh/iterate-refs (2011-08-14) 6 commits
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
Not urgent; will not be in 1.7.7.
* jn/plug-empty-tree-leak (2011-08-16) 2 commits
(merged to 'next' on 2011-08-23 at aee2184)
+ merge-recursive: take advantage of hardcoded empty tree
+ revert: plug memory leak in "cherry-pick root commit" codepath
Will merge to "master".
* ac/describe-dirty-refresh (2011-08-11) 1 commit
(merged to 'next' on 2011-08-23 at b873611)
+ describe: Refresh the index when run with --dirty
Will merge to "master".
* en/merge-recursive-2 (2011-08-14) 57 commits
(merged to 'next' on 2011-08-23 at ba6ad0d)
+ merge-recursive: Don't re-sort a list whose order we depend upon
+ merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-dest
+ t6036: criss-cross + rename/rename(1to2)/add-dest + simple modify
+ merge-recursive: Avoid unnecessary file rewrites
+ t6022: Additional tests checking for unnecessary updates of files
+ merge-recursive: Fix spurious 'refusing to lose untracked file...' messages
+ t6022: Add testcase for spurious "refusing to lose untracked" messages
+ t3030: fix accidental success in symlink rename
+ merge-recursive: Fix working copy handling for rename/rename/add/add
+ merge-recursive: add handling for rename/rename/add-dest/add-dest
+ merge-recursive: Have conflict_rename_delete reuse modify/delete code
+ merge-recursive: Make modify/delete handling code reusable
+ merge-recursive: Consider modifications in rename/rename(2to1) conflicts
+ merge-recursive: Create function for merging with branchname:file markers
+ merge-recursive: Record more data needed for merging with dual renames
+ merge-recursive: Defer rename/rename(2to1) handling until process_entry
+ merge-recursive: Small cleanups for conflict_rename_rename_1to2
+ merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
+ merge-recursive: Introduce a merge_file convenience function
+ merge-recursive: Fix modify/delete resolution in the recursive case
+ merge-recursive: When we detect we can skip an update, actually skip it
+ merge-recursive: Provide more info in conflict markers with file renames
+ merge-recursive: Cleanup and consolidation of rename_conflict_info
+ merge-recursive: Consolidate process_entry() and process_df_entry()
+ merge-recursive: Improve handling of rename target vs. directory addition
+ merge-recursive: Add comments about handling rename/add-source cases
+ merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
+ merge-recursive: Fix deletion of untracked file in rename/delete conflicts
+ merge-recursive: Split update_stages_and_entry; only update stages at end
+ merge-recursive: Allow make_room_for_path() to remove D/F entries
+ string-list: Add API to remove an item from an unsorted list
+ merge-recursive: Split was_tracked() out of would_lose_untracked()
+ merge-recursive: Save D/F conflict filenames instead of unlinking them
+ merge-recursive: Fix code checking for D/F conflicts still being present
+ merge-recursive: Fix sorting order and directory change assumptions
+ merge-recursive: Fix recursive case with D/F conflict via add/add conflict
+ merge-recursive: Avoid working directory changes during recursive case
+ merge-recursive: Remember to free generated unique path names
+ merge-recursive: Consolidate different update_stages functions
+ merge-recursive: Mark some diff_filespec struct arguments const
+ merge-recursive: Correct a comment
+ merge-recursive: Make BUG message more legible by adding a newline
+ t6022: Add testcase for merging a renamed file with a simple change
+ t6022: New tests checking for unnecessary updates of files
+ t6022: Remove unnecessary untracked files to make test cleaner
+ t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
+ t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
+ t6036: tests for criss-cross merges with various directory/file conflicts
+ t6036: criss-cross with weird content can fool git into clean merge
+ t6036: Add differently resolved modify/delete conflict in criss-cross test
+ t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
+ t6042: Ensure rename/rename conflicts leave index and workdir in sane state
+ t6042: Add tests for content issues with modify/rename/directory conflicts
+ t6042: Add a testcase where undetected rename causes silent file deletion
+ t6042: Add a pair of cases where undetected renames cause issues
+ t6042: Add failing testcase for rename/modify/add-source conflict
+ t6042: Add a testcase where git deletes an untracked file
Will aim to merge to "master" by -rc1.
* fg/submodule-ff-check-before-push (2011-08-20) 2 commits
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
+ push: Don't push a repository with unpushed submodules
(this branch uses jc/combine-diff-callback.)
Will aim to merge to "master" by -rc1.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Not urgent; will not be in 1.7.7.
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* js/i18n-scripts (2011-08-08) 5 commits
(merged to 'next' on 2011-08-23 at a1b5529)
+ submodule: take advantage of gettextln and eval_gettextln.
+ stash: take advantage of eval_gettextln
+ pull: take advantage of eval_gettextln
+ git-am: take advantage of gettextln and eval_gettextln.
+ gettext: add gettextln, eval_gettextln to encode common idiom
Will merge to "master".
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories. Will keep it in "next" at least for one cycle,
until we start hearing real-world success reports on the list.
Not urgent; will not be in 1.7.7.
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)
From: R @ 2011-08-25 0:13 UTC (permalink / raw)
To: git, gitster
Udhshdhhs
Sent from my Verizon Wireless 4G LTE smartphone
------Original Message------
From: Junio C Hamano <gitster@pobox.com>
To: <git@vger.kernel.org>
Date: Wednesday, August 24, 2011 5:09:09 PM GMT-0700
Subject: What's cooking in git.git (Aug 2011, #07; Wed, 24)
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
I've sifted topics to the ones meant for 1.7.7 and the others that I'd
prefer to cook a bit longer in "next" during the upcoming feature freeze,
which should happen by the end of the week.
Please help us make the upcoming release as solid as we could. Thanks.
--------------------------------------------------
[Stalled]
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
Needs documentation updates.
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* jc/merge-reword (2011-05-25) 1 commit
(merged to 'next' on 2011-08-24 at aa5cf7b)
+ merge: reword the final message
Will merge to "master".
* nk/branch-v-abbrev (2011-07-01) 1 commit
(merged to 'next' on 2011-08-24 at e9152cf)
+ branch -v: honor core.abbrev
Will merge to "master".
* jk/pager-with-external-command (2011-08-19) 1 commit
(merged to 'next' on 2011-08-24 at 083f5da)
+ support pager.* for external commands
(this branch is used by jk/pager-with-alias and jk/pager-with-alias; uses jk/color-and-pager.)
Up to this part (but not "alias") the topic looked unconditionally a good
thing to do.
Will aim to merge to "master" by -rc1.
* fk/use-kwset-pickaxe-grep-f (2011-08-20) 5 commits
(merged to 'next' on 2011-08-23 at 93ba509)
+ Use kwset in grep
+ Use kwset in pickaxe
+ Adapt the kwset code to Git
+ Add string search routines from GNU grep
+ Add obstack.[ch] from EGLIBC 2.10
Will aim to merge to "master" by -rc1.
* jc/maint-autofix-tag-in-head (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at 18cee02)
+ commit: reduce use of redundant global variables
Will merge to "master".
* bw/doc-repo-layout (2011-08-23) 2 commits
(merged to 'next' on 2011-08-24 at 605c730)
+ Mark http-fetch without -a as deprecated
+ Documentation: Grammar correction, wording fixes and cleanup
Will merge to "master".
* ci/forbid-unwanted-current-branch-update (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at 1e93b67)
+ Show interpreted branch name in error messages
+ Prevent force-updating of the current branch
Will aim to merge to "master" by -rc1.
* di/fast-import-blob-tweak (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at 52eef2a)
+ fast-import: treat cat-blob as a delta base hint for next blob
+ fast-import: count and report # of calls to diff_delta in stats
Will aim to merge to "master" by -rc1.
* di/fast-import-tagging (2011-08-23) 2 commits
(merged to 'next' on 2011-08-24 at 67e0937)
+ fast-import: allow to tag newly created objects
+ fast-import: add tests for tagging blobs
Will aim to merge to "master" by -rc1.
* di/fast-import-deltified-tree (2011-08-14) 2 commits
(merged to 'next' on 2011-08-23 at ee30265)
+ fast-import: prevent producing bad delta
+ fast-import: add a test for tree delta base corruption
Will aim to merge to "master" by -rc1.
* di/fast-import-ident (2011-08-11) 5 commits
(merged to 'next' on 2011-08-23 at 9b86391)
+ fsck: improve committer/author check
+ fsck: add a few committer name tests
+ fast-import: check committer name more strictly
+ fast-import: don't fail on omitted committer name
+ fast-import: add input format tests
Will aim to merge to "master" by -rc1.
* di/fast-import-doc (2011-08-17) 1 commit
(merged to 'next' on 2011-08-23 at dab4088)
+ doc/fast-import: document feature import-marks-if-exists
Will merge to "master".
* jc/combine-diff-callback (2011-08-20) 1 commit
(merged to 'next' on 2011-08-24 at 9f9b42d)
+ combine-diff: support format_callback
(this branch is used by fg/submodule-ff-check-before-push.)
Will merge to "master".
* jc/maint-clone-alternates (2011-08-23) 2 commits
(merged to 'next' on 2011-08-23 at 7280deb)
+ clone: clone from a repository with relative alternates
+ clone: allow more than one --reference
Will aim to merge to "master" by -rc1.
* nd/maint-clone-gitdir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-24 at cbf052b)
+ clone: allow to clone from .git file
+ read_gitfile_gently(): rename misnamed function to read_gitfile()
Will aim to merge to "master" by -rc1.
* jc/traverse-commit-list (2011-08-22) 3 commits
(merged to 'next' on 2011-08-24 at df50dd7)
+ revision.c: update show_object_with_name() without using malloc()
+ revision.c: add show_object_with_name() helper function
+ rev-list: fix finish_object() call
Not urgent; will not be in 1.7.7.
* rc/diff-cleanup-records (2011-08-17) 2 commits
(merged to 'next' on 2011-08-23 at b8414f5)
+ Merge branch 'rc/histogram-diff' into HEAD
+ xdiff/xprepare: improve O(n*m) performance in xdl_cleanup_records()
Will aim to merge to "master" by -rc1.
* fk/make-auto-header-dependencies (2011-08-18) 1 commit
(merged to 'next' on 2011-08-24 at 3da2c25)
+ Makefile: Use computed header dependencies if the compiler supports it
Not urgent; will not be in 1.7.7.
* jk/color-and-pager (2011-08-19) 10 commits
(merged to 'next' on 2011-08-23 at cbb9495)
+ want_color: automatically fallback to color.ui
+ diff: don't load color config in plumbing
+ config: refactor get_colorbool function
+ color: delay auto-color decision until point of use
+ git_config_colorbool: refactor stdout_is_tty handling
+ diff: refactor COLOR_DIFF from a flag into an int
+ setup_pager: set GIT_PAGER_IN_USE
+ t7006: use test_config helpers
+ test-lib: add helper functions for config
+ t7006: modernize calls to unset
(this branch is used by jk/pager-with-alias and jk/pager-with-external-command.)
Will aim to merge to "master" by -rc1.
* jk/pager-with-alias (2011-08-19) 1 commit
- support pager.* for aliases
(this branch uses jk/color-and-pager, jk/pager-with-external-command and jk/pager-with-external-command.)
Perhaps will drop.
* nd/decorate-grafts (2011-08-19) 5 commits
(merged to 'next' on 2011-08-23 at 475d27e)
+ log: decorate "replaced" on to replaced commits
+ log: decorate grafted commits with "grafted"
+ Move write_shallow_commits to fetch-pack.c
+ Add for_each_commit_graft() to iterate all grafts
+ decoration: do not mis-decorate refs with same prefix
Will aim to merge to "master" by -rc1.
* va/p4-branch-import (2011-08-22) 4 commits
(merged to 'next' on 2011-08-24 at f67f8af)
+ git-p4: Add simple test case for branch import
+ git-p4: Allow branch definition with git config
+ git-p4: Allow filtering Perforce branches by user
+ git-p4: Correct branch base depot path detection
(this branch uses va/p4-rename-copy.)
Will merge to "master".
* va/p4-rename-copy (2011-08-22) 5 commits
(merged to 'next' on 2011-08-24 at f1faa94)
+ git-p4: Process detectCopiesHarder with --bool
+ git-p4: Add test case for copy detection
+ git-p4: Add test case for rename detection
+ git-p4: Add description of rename/copy detection options
+ git-p4: Allow setting rename/copy detection threshold
(this branch is used by va/p4-branch-import.)
Will merge to "master".
* da/difftool-mergtool-refactor (2011-08-19) 4 commits
(merged to 'next' on 2011-08-23 at a1cc3be)
+ mergetools/meld: Use '--output' when available
+ mergetool--lib: Refactor tools into separate files
+ mergetool--lib: Make style consistent with git
+ difftool--helper: Make style consistent with git
Will merge to "master".
* mg/branch-set-upstream-previous (2011-08-19) 1 commit
(merged to 'next' on 2011-08-23 at acef0b6)
+ branch.c: use the parsed branch name
Will merge to "master".
* di/parse-options-split (2011-08-11) 2 commits
(merged to 'next' on 2011-08-23 at 6cd667f)
+ Reduce parse-options.o dependencies
+ parse-options: export opterr, optbug
Will merge to "master".
* mh/attr (2011-08-14) 7 commits
(merged to 'next' on 2011-08-23 at 22faa6e)
+ Unroll the loop over passes
+ Change while loop into for loop
+ Determine the start of the states outside of the pass loop
+ Change parse_attr() to take a pointer to struct attr_state
+ Increment num_attr in parse_attr_line(), not parse_attr()
+ Document struct match_attr
+ Add a file comment
Will aim to merge to "master" by -rc1.
* mh/iterate-refs (2011-08-14) 6 commits
- Retain caches of submodule refs
- Store the submodule name in struct cached_refs
- Allocate cached_refs objects dynamically
- Change the signature of read_packed_refs()
- Access reference caches only through new function get_cached_refs()
- Extract a function clear_cached_refs()
I did not see anything fundamentally wrong with this series, but it was
unclear what the benefit of these changes are. If the series were to read
parts of the ref hierarchy (like refs/heads/) lazily, the story would
have been different, though.
Not urgent; will not be in 1.7.7.
* jn/plug-empty-tree-leak (2011-08-16) 2 commits
(merged to 'next' on 2011-08-23 at aee2184)
+ merge-recursive: take advantage of hardcoded empty tree
+ revert: plug memory leak in "cherry-pick root commit" codepath
Will merge to "master".
* ac/describe-dirty-refresh (2011-08-11) 1 commit
(merged to 'next' on 2011-08-23 at b873611)
+ describe: Refresh the index when run with --dirty
Will merge to "master".
* en/merge-recursive-2 (2011-08-14) 57 commits
(merged to 'next' on 2011-08-23 at ba6ad0d)
+ merge-recursive: Don't re-sort a list whose order we depend upon
+ merge-recursive: Fix virtual merge base for rename/rename(1to2)/add-dest
+ t6036: criss-cross + rename/rename(1to2)/add-dest + simple modify
+ merge-recursive: Avoid unnecessary file rewrites
+ t6022: Additional tests checking for unnecessary updates of files
+ merge-recursive: Fix spurious 'refusing to lose untracked file...' messages
+ t6022: Add testcase for spurious "refusing to lose untracked" messages
+ t3030: fix accidental success in symlink rename
+ merge-recursive: Fix working copy handling for rename/rename/add/add
+ merge-recursive: add handling for rename/rename/add-dest/add-dest
+ merge-recursive: Have conflict_rename_delete reuse modify/delete code
+ merge-recursive: Make modify/delete handling code reusable
+ merge-recursive: Consider modifications in rename/rename(2to1) conflicts
+ merge-recursive: Create function for merging with branchname:file markers
+ merge-recursive: Record more data needed for merging with dual renames
+ merge-recursive: Defer rename/rename(2to1) handling until process_entry
+ merge-recursive: Small cleanups for conflict_rename_rename_1to2
+ merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
+ merge-recursive: Introduce a merge_file convenience function
+ merge-recursive: Fix modify/delete resolution in the recursive case
+ merge-recursive: When we detect we can skip an update, actually skip it
+ merge-recursive: Provide more info in conflict markers with file renames
+ merge-recursive: Cleanup and consolidation of rename_conflict_info
+ merge-recursive: Consolidate process_entry() and process_df_entry()
+ merge-recursive: Improve handling of rename target vs. directory addition
+ merge-recursive: Add comments about handling rename/add-source cases
+ merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
+ merge-recursive: Fix deletion of untracked file in rename/delete conflicts
+ merge-recursive: Split update_stages_and_entry; only update stages at end
+ merge-recursive: Allow make_room_for_path() to remove D/F entries
+ string-list: Add API to remove an item from an unsorted list
+ merge-recursive: Split was_tracked() out of would_lose_untracked()
+ merge-recursive: Save D/F conflict filenames instead of unlinking them
+ merge-recursive: Fix code checking for D/F conflicts still being present
+ merge-recursive: Fix sorting order and directory change assumptions
+ merge-recursive: Fix recursive case with D/F conflict via add/add conflict
+ merge-recursive: Avoid working directory changes during recursive case
+ merge-recursive: Remember to free generated unique path names
+ merge-recursive: Consolidate different update_stages functions
+ merge-recursive: Mark some diff_filespec struct arguments const
+ merge-recursive: Correct a comment
+ merge-recursive: Make BUG message more legible by adding a newline
+ t6022: Add testcase for merging a renamed file with a simple change
+ t6022: New tests checking for unnecessary updates of files
+ t6022: Remove unnecessary untracked files to make test cleaner
+ t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
+ t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
+ t6036: tests for criss-cross merges with various directory/file conflicts
+ t6036: criss-cross with weird content can fool git into clean merge
+ t6036: Add differently resolved modify/delete conflict in criss-cross test
+ t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
+ t6042: Ensure rename/rename conflicts leave index and workdir in sane state
+ t6042: Add tests for content issues with modify/rename/directory conflicts
+ t6042: Add a testcase where undetected rename causes silent file deletion
+ t6042: Add a pair of cases where undetected renames cause issues
+ t6042: Add failing testcase for rename/modify/add-source conflict
+ t6042: Add a testcase where git deletes an untracked file
Will aim to merge to "master" by -rc1.
* fg/submodule-ff-check-before-push (2011-08-20) 2 commits
(merged to 'next' on 2011-08-24 at 398e764)
+ push: teach --recurse-submodules the on-demand option
+ push: Don't push a repository with unpushed submodules
(this branch uses jc/combine-diff-callback.)
Will aim to merge to "master" by -rc1.
* hv/submodule-update-none (2011-08-11) 2 commits
(merged to 'next' on 2011-08-24 at 5302fc1)
+ add update 'none' flag to disable update of submodule by default
+ submodule: move update configuration variable further up
Not urgent; will not be in 1.7.7.
* jc/lookup-object-hash (2011-08-11) 6 commits
(merged to 'next' on 2011-08-24 at 5825411)
+ object hash: replace linear probing with 4-way cuckoo hashing
+ object hash: we know the table size is a power of two
+ object hash: next_size() helper for readability
+ pack-objects --count-only
+ object.c: remove duplicated code for object hashing
+ object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* js/i18n-scripts (2011-08-08) 5 commits
(merged to 'next' on 2011-08-23 at a1b5529)
+ submodule: take advantage of gettextln and eval_gettextln.
+ stash: take advantage of eval_gettextln
+ pull: take advantage of eval_gettextln
+ git-am: take advantage of gettextln and eval_gettextln.
+ gettext: add gettextln, eval_gettextln to encode common idiom
Will merge to "master".
* fg/submodule-git-file-git-dir (2011-08-22) 2 commits
(merged to 'next' on 2011-08-23 at 762194e)
+ Move git-dir for submodules
+ rev-parse: add option --resolve-git-dir <path>
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage outweighs any benefit for having this new
feature. Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories. Will keep it in "next" at least for one cycle,
until we start hearing real-world success reports on the list.
Not urgent; will not be in 1.7.7.
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
(merged to 'next' on 2011-08-24 at 712c115)
+ revert: Propagate errors upwards from do_pick_commit
+ revert: Introduce --continue to continue the operation
+ revert: Don't implicitly stomp pending sequencer operation
+ revert: Remove sequencer state when no commits are pending
+ reset: Make reset remove the sequencer state
+ revert: Introduce --reset to remove sequencer state
+ revert: Make pick_commits functionally act on a commit list
+ revert: Save command-line options for continuing operation
+ revert: Save data for continuing after conflict resolution
+ revert: Don't create invalid replay_opts in parse_args
+ revert: Separate cmdline parsing from functional code
+ revert: Introduce struct to keep command-line options
+ revert: Eliminate global "commit" variable
+ revert: Rename no_replay to record_origin
+ revert: Don't check lone argument in get_encoding
+ revert: Simplify and inline add_message_to_msg
+ config: Introduce functions to write non-standard file
+ advice: Introduce error_resolve_conflict
Will keep it in 'next' at least for one cycle.
Not urgent; will not be in 1.7.7.
^ permalink raw reply
* Re: git clean --exclude broken?
From: Junio C Hamano @ 2011-08-25 1:38 UTC (permalink / raw)
To: Todd Rinaldo; +Cc: git
In-Reply-To: <7vliuio65w.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Todd Rinaldo <toddr@cpanel.net> writes:
>
>> I think I have found a new bug in 1.7.5:
>
> My quick check indicates 1.7.3 behaves the same way, and 1.7.2.5 didn't
> have --exclude option, so this does not seem to be anything particularly
> new in the 1.7.5 release.
>
>> # The problem (Why is foo/ removed?)
>> $>git clean -dXf --exclude=/foo
>> Removing bar/
>> Removing foo/
>
> Why is this command line giving -X that tells us not to use the ignore
> rules, and --exclude option at the same time?
The documentation and the implementation of "git clean" is quite confused.
Here is what is said about "-e":
-e <pattern>::
--exclude=<pattern>::
Specify special exceptions to not be cleaned. Each <pattern> is
the same form as in $GIT_DIR/info/excludes and this option can be
given multiple times.
But in reality, it is not about "not be cleaned" at all. A better
description to reflect what the implementation actually does is probably
this:
In addition to what are found in usual places like .gitignore (per
directory) and $GIT_DIR/info/exclude, consider these patterns to
be in the ignore rules.
This mirrors what --exclude parameter to "ls-files" does [*1*].
I can however see a use case where the user wants to say something like
this which is quite different:
I know "git clean" (or "git clean -x" or "git clean -X") will try
to remove paths A, B and C. I want it remove them except for this
particular path C by adding --except=C option to the command line.
And the current documentation does look like it is describing such an
option. But that is not what --exclude option is about.
One solution might be to say "I know the usual rules stored in .gitignore
and the like tell us to that 'foo' is ignored (and to be cleaned), but for
this invocation only, please treat 'foo' is _not_ ignored.", and there
indeed is a way to do so:
$ git clean -d -X -e \!foo
(the backslash before '!' is to avoid history substitution in some shells).
[Footnote]
*1* This part in builtin/clean.c looks a bit distasteful:
for (i = 0; i < exclude_list.nr; i++)
add_exclude(exclude_list.items[i].string, "", 0, dir.exclude_list);
The last parameter should be &dir.exclude_list[EXC_CMDL] because we are
adding exclude patterns from the command line. It works by accident
only because EXC_CMDL happens to be defined as 0.
^ permalink raw reply
* Re: [RFC] branch: list branches by single remote
From: Thiago Farina @ 2011-08-25 2:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Michael Schubert, Jeff King, git
In-Reply-To: <7vei0apsj9.fsf@alter.siamese.dyndns.org>
On Wed, Aug 24, 2011 at 3:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
> [Footnote]
>
> *1* It does not have to be a weekly _posting_ on the list but can be a
> well-known Wiki page or even a bug tracker. Whatever medium is used for
> this purpose, there _must_ be a built-in mechanism to expire entries away
> that are inactive for more than some reasonable limit (say two to three
> weeks).
Host the project on Google Code for bug tracking? Use rietveld for
code reviews (ike codereview.chromium.org and codereview.appspot.com)?
^ permalink raw reply
* Re: [PATCH RFC] gitk: Allow commit editing
From: Jeff King @ 2011-08-25 3:07 UTC (permalink / raw)
To: Michal Sojka; +Cc: git, paulus
In-Reply-To: <87obzlwpx0.fsf@steelpick.2x.cz>
On Fri, Aug 19, 2011 at 02:23:39PM +0200, Michal Sojka wrote:
> > Invoking rebase behind the scenes makes me very nervous. In particular:
> >
> > 1. There is nothing to indicate to the user that they are rewriting a
> > string of commits, which is going to wreak havoc if any of the
> > commits have been published elsewhere (either pushed somewhere, or
> > even present in another local branch). I.e., rebasing generally
> > needs to be a conscious decision of the user.
>
> I added a warning if the edited commit is contained in a remote branch.
> Would you consider this sufficient?
It's likely problematic if the commit appears in the history of any
other ref, unless they are also planning on rebasing that ref, too
(which you can't really know, but it is probably better to warn).
-Peff
^ permalink raw reply
* Re: [PATCH] gitk: Allow commit editing
From: Jeff King @ 2011-08-25 3:14 UTC (permalink / raw)
To: Michal Sojka; +Cc: git, paulus
In-Reply-To: <1313756753-26498-1-git-send-email-sojka@os.inf.tu-dresden.de>
On Fri, Aug 19, 2011 at 02:25:53PM +0200, Michal Sojka wrote:
> + if {[exec git branch -r --contains=$rowmenuid] ne {}} {
> + if {![confirm_popup [mc "The commit you are going to edit appears in at least one\
> + remote branch. It is a bad idea to change a branch that is\
> + possibly used by other people. See git-rebase(1) for details.\n\n\
> + Do you want to continue?"]]} return }
We frown on using porcelain like "git branch" here, because it was not
meant to be scriptable (i.e., its behavior may change in future
releases).
As I mentioned elsewhere, I think you really want to see whether the
commit is referenced by any other ref, not just branches; if it is, then
the rebase is potentially problematic. You can do that with something
like:
us=`git symbolic-ref HEAD`
git for-each-ref --format='%(refname)' |
while read ref; do
test "$ref" = $us" && continue
echo "^$ref"
done |
git rev-list HEAD --stdin
That will give a list of commits found only on HEAD and nowhere else
(i.e., those which are safe to rebase). If your commit is among them,
then it's safe.
Speaking of which, notice that I used HEAD here. What happens with your
patch if I do:
$ git checkout foo
$ gitk bar
and select a commit to edit that is not in "foo"?
-Peff
^ permalink raw reply
* One MMORPG git facts
From: Marat Radchenko @ 2011-08-25 6:53 UTC (permalink / raw)
To: git
In-Reply-To: <416D1A48-9916-4E44-A200-3A13C39C4D70@gmail.com>
Lawrence Brett <lcbrett <at> gmail.com> writes:
>
> Hello,
>
> I am very interested in using git for game development. I will be working
> with a lot of binaries (textures, 3d assets, etc.) in addition to source
> files. I'd like to be able to version these files, but I understand that
> big binaries aren't git's forte.
Define "big".
I have one MMORPG here under Git. 250k revisions, 500k files in working dir
(7Gb), 200 commits daily, 250Gb Git repo, SVN upstream repo of ~1Tb.
Some facts:
1. It is unusable on 32bit machine (here and there hits memory limit for a
single process
2. It is unusable on Windows (because there's no 64bit msysgit)
3. git status is 3s with hot disk caches (7mins with cold)
4. History traversal means really massive I/O.
5. Current setup: 120Gb 10k rpm disk for everything but .git/objects/pack,
separate 500Gb (will be upgraded to 1Tb soon) disk for packs
6. git gc is PAIN. I do it on weekends because it takes more than a day to run.
Also, limits for git pack-objects should be configured VERY carefully, it can
either run out of ram or take weeks to run if configured improperly.
7. With default gc settings, git wants to gc daily (but gc takes more than a
day, so if you follow its desire, you're in gc loop). I set objects limit to a
very high value and invoke gc manually.
8. svn users cannot sensibly do status on whole working copy (more than 10 mins)
9. svn users only update witha nightly script (40 mins)
10. git commit is several seconds because it writes 70Mb commit file.
11. It is a good idea to run git status often so that working copy info isn't
evicted from OS disk caches (remember, 3s vs 7min)
12. Cloning git repo is one more pain. 100mbps network here, so fetching 250Gb
takes some time. But worse, if cloning via git:// protocol, after fetching git
sits for several hours in "Resolving deltas" stage. So, for initial cloning
rsync is used.
13. Here and there i hit scalability issues in various git commands (which i
report to maillist and most [well, all, except the one i reported this week] of
which get fixed)
Hope this helps to get the idea of how git behaves on a large scale. Overall,
i'm happy with it and won't return to svn.
^ permalink raw reply
* [GSoC update] Final report: Some observations
From: Ramkumar Ramachandra @ 2011-08-25 6:56 UTC (permalink / raw)
To: Git List
Cc: Junio C Hamano, Jonathan Nieder, Christian Couder,
Sverre Rabbelier
Hi,
I've been involved with the Git community since January 2010. Apart
from tiny miscellaneous patches, I spent two summers as a GSoC student
writing more chunky portions. I'll write down some of my personal
observations here; it's nothing new, but I hope the community can
benefit from learning what a (relatively) new contributor observes.
Classifying them as "positive" or "negative" attributes makes little
sense in my opinion.
1. I really like the Git and the community. It's a great piece of
software, and the community makes sure that it stays that way. As a
result, it arguably has a high entry barrier.
2. It's an exponential climb for a contributor. Looking back, I can
find issues with the first few patches that I contributed, but reviews
weren't as stringent. It also has to do with the parts of Git I've
tried to contribute to- I slowly went from writing tiny documentation
patches to large features.
3. Excellent timely reviews. If there's one reason I stayed around
despite all the difficulties, this has to be it. I don't know any
faster way to improve as a software engineer.
4. Language is beautiful and entertaining! People make use of their
language skills to write interesting reviews and commit messages, not
choppy dry ones.
5. High transparency. It looks like almost everything is on-list.
6. Largely impersonal. Although there are exceptions, people
generally don't talk about their personal lives; some people don't use
their real names.
Personally, I feel a little guilty because I feel that I've gained
more than I've given back. I'll try to make up for this over the
coming months and years.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH] rebase -i: clean error message for --continue after failed exec
From: Matthieu Moy @ 2011-08-25 7:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy5yiod1h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>>
>>> If after a failed "exec" instruction there are staged changes,...
>>
>> I have to wonder why whatever "exec" runs is mucking with the index in the
>> first place. Shouldn't we forbid it?
>
> I suspect your patch amounts to the same thing of forbidding, but
> detecting the lack of $author_script feels like it is covering up the
> symptom and not directly going for the cause of the symptom.
>
> I wonder if doing something like this would be more direct approach to
> achieve the same thing.
Not the same thing, but both patches could go well together.
Mine covers
pick deadbeef
exec make test
# :-( make test failed, I'm going to fix it
hack hack hack
git add changes
# OK, seems fixed.
git rebase --continue
# --> rebase tells me I forgot to commit my fixup patch
i.e. the user changed the index interactively, not within exec. Yours
covers the case where the command itself changes the index.
> + # Run in subshell because require_clean_work_tree can die.
> + dirty=f
> + (require_clean_work_tree "rebase") || dirty=t
This will display error messages like
Cannot rebase: You have unstaged changes
and right after
> warn "Execution failed: $rest"
> + test "$dirty" = f ||
> + warn "and made changes to the index and/or the working tree"
which sounds redundant. This should probably be
(require_clean_work_tree "rebase" 2>/dev/null) || dirty=t
but looking more closely at the patch, you're not the one introducing
this, it was already there since 92c62a3f.
> fi
> +
> ;;
> *)
I think this one can be removed, there's usually no blank line before ;;
in the code.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2011, #07; Wed, 24)
From: Michael Haggerty @ 2011-08-25 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4a2mjx6.fsf@alter.siamese.dyndns.org>
On 08/25/2011 02:09 AM, Junio C Hamano wrote:
> * mh/iterate-refs (2011-08-14) 6 commits
> - Retain caches of submodule refs
> - Store the submodule name in struct cached_refs
> - Allocate cached_refs objects dynamically
> - Change the signature of read_packed_refs()
> - Access reference caches only through new function get_cached_refs()
> - Extract a function clear_cached_refs()
>
> I did not see anything fundamentally wrong with this series, but it was
> unclear what the benefit of these changes are. If the series were to read
> parts of the ref hierarchy (like refs/heads/) lazily, the story would
> have been different, though.
I am still working on lazy reading and hierarchical storage of reference
caches. It's OK with me if you defer merging the above patch series
until I have made more progress on the more significant improvements.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Buggy handling of non-canonical ref names
From: Michael Haggerty @ 2011-08-25 7:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
In-Reply-To: <7vaaayo369.fsf@alter.siamese.dyndns.org>
On 08/25/2011 12:27 AM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>> What is the policy about reference names and their canonicalization?
>>
>> The overall policy has been that we care about well-formed input, and
>> everything else is "undefined", even though as you found out some of them
>> try to work sensibly.
>>
>>> $ git check-ref-format /foo/bar ; echo $?
>>> 0
>>>
>>> $ git check-ref-format --print /foo/bar
>>> /foo/bar
>>
>> I think these are bogus. Patches welcome.
>
> I actually think the former is correct and the latter should strip the
> leading slash. Essentially what "check-ref-format" (and the underlying
> check_ref_format() function) validates is if the given user string can be
> used under $GIT_DIR/refs/ to name a ref, and $GIT_DIR/refs//foo/bar is
> (because we "tolerate duplicated slashes" cf. comment in the function) the
> same as $GIT_DIR/refs/foo/bar and is allowed.
I can live with either way, but I should point out that such an extra
slash can be problematic when used naively in conjunction with Python's
standard glue-together-pathname function, os.path.join() [1]:
$ python
>>> import os
>>> os.path.join('.git', '/foo/bar')
'/foo/bar'
>>>
Maybe there are other examples of libraries with these semantics.
> I think what is missing is a unified way to canonicalize the refnames
> (which led to the inconsistencies you observed), and I strongly suspect
> that check_ref_format() should learn to return the canonicalized format
> (if asked by the caller) and the caller should use the canonicalized
> version after feeding end-user input to it.
>
> Then the plumbing "check-ref-format --print" can use it just like any
> other caller that should be (or already are) using check_ref_format()
> to validate the end-user input.
Indeed, regardless of the policy about leading slashes, this is a good
plan. I will try to find time to work on it.
> Yes, such a change will update the overall policy I stated earlier and
> narrow the scope of "undefined" down a bit, by uniformly codifying that
> leading and duplicate slashes are removed to be nice to the user.
Michael
[1] http://docs.python.org/library/os.path.html#os.path.join
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: One MMORPG git facts
From: J.H. @ 2011-08-25 7:57 UTC (permalink / raw)
To: Marat Radchenko; +Cc: git
In-Reply-To: <loom.20110825T081519-218@post.gmane.org>
On 08/24/2011 11:53 PM, Marat Radchenko wrote:
> Lawrence Brett <lcbrett <at> gmail.com> writes:
>
>>
>> Hello,
>>
>> I am very interested in using git for game development. I will be working
>> with a lot of binaries (textures, 3d assets, etc.) in addition to source
>> files. I'd like to be able to version these files, but I understand that
>> big binaries aren't git's forte.
>
> Define "big".
>
> I have one MMORPG here under Git. 250k revisions, 500k files in working dir
> (7Gb), 200 commits daily, 250Gb Git repo, SVN upstream repo of ~1Tb.
Given the differences, I'm morbidly curious, which actually ends up
being the more usable version control system of a project of this scale?
It sounds like (from what you've said) git is generally faster,
assuming it can get enough resources (which can obviously be hard at the
scales your talking).
- John 'Warthog9' Hawley
^ permalink raw reply
* [PATCH] Do not allow refnames to start with a slash
From: Michael Haggerty @ 2011-08-25 8:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, cmn, Michael Haggerty
In-Reply-To: <4E55FFAA.9030904@alum.mit.edu>
Previously, refnames with leading slashes were handled inconsistently.
So forbid them altogether.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
This patch chooses the alternative of forbidding leading slashes,
because I feel that it is the safer option. It is like Carlos's patch
but with documentation changes, test-suite additions, and an
corresponding change to git.py. If anybody knows of other
implementations of the ref format checking code, please let me know.
This patch applies to either master or maint. Since it restricts the
DWIM behavior in some cases, master is probably the better choice.
Documentation/git-check-ref-format.txt | 7 ++++---
git_remote_helpers/git/git.py | 3 ++-
refs.c | 3 +++
t/t1402-check-ref-format.sh | 4 ++++
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index c9fdf84..238b185 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -34,15 +34,16 @@ git imposes the following rules on how references are named:
category like `heads/`, `tags/` etc. but the actual names are not
restricted.
-. They cannot have two consecutive dots `..` anywhere.
+. They must not start or end with slash `/`.
+
+. They cannot have two consecutive dots `..` anywhere or end with a
+ dot `.`.
. They cannot have ASCII control characters (i.e. bytes whose
values are lower than \040, or \177 `DEL`), space, tilde `~`,
caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
or open bracket `[` anywhere.
-. They cannot end with a slash `/` nor a dot `.`.
-
. They cannot end with the sequence `.lock`.
. They cannot contain a sequence `@{`.
diff --git a/git_remote_helpers/git/git.py b/git_remote_helpers/git/git.py
index a383e6c..6df53aa 100644
--- a/git_remote_helpers/git/git.py
+++ b/git_remote_helpers/git/git.py
@@ -55,7 +55,8 @@ def valid_git_ref (ref_name):
# command. The rules were derived from the git check-ref-format(1)
# manual page. This code should be replaced by a call to
# check_ref_format() in the git library, when such is available.
- if ref_name.endswith('/') or \
+ if ref_name.startswith('/') or \
+ ref_name.endswith('/') or \
ref_name.startswith('.') or \
ref_name.count('/.') or \
ref_name.count('..') or \
diff --git a/refs.c b/refs.c
index 6f313a9..84c5af3 100644
--- a/refs.c
+++ b/refs.c
@@ -880,6 +880,9 @@ int check_ref_format(const char *ref)
const char *cp = ref;
level = 0;
+ if (*cp == '/')
+ /* no leading slashes */
+ return CHECK_REF_FORMAT_ERROR;
while (1) {
while ((ch = *cp++) == '/')
; /* tolerate duplicated slashes */
diff --git a/t/t1402-check-ref-format.sh b/t/t1402-check-ref-format.sh
index 1b0f82f..b05ca26 100755
--- a/t/t1402-check-ref-format.sh
+++ b/t/t1402-check-ref-format.sh
@@ -18,6 +18,10 @@ invalid_ref 'foo'
valid_ref 'foo/bar/baz'
valid_ref 'refs///heads/foo'
invalid_ref 'heads/foo/'
+invalid_ref '/foo'
+invalid_ref 'foo/'
+invalid_ref '/foo/bar'
+invalid_ref 'foo/bar/'
invalid_ref './foo'
invalid_ref '.refs/foo'
invalid_ref 'heads/foo..bar'
--
1.7.6.8.gd2879
^ permalink raw reply related
* Re: [RFC] branch: list branches by single remote
From: Michael J Gruber @ 2011-08-25 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Schubert, Jeff King, git
In-Reply-To: <7vei0apsj9.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 24.08.2011 20:34:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>>> As suggested, I've just called it "--glob" for now.
>>
>> Well, again, what's the point in replicating
>>
>> http://permalink.gmane.org/gmane.comp.version-control.git/172228
>>
>> and how is it different?
>> As I've mentioned, I've been in the middle of polishing that up.
>
> It is not unusual for a similar itch to happen to different people
> independently.
>
> If this were something you reposted even a WIP re-polish within the past
> two weeks, I would understand and even sympathise with your irritation,
> but please don't expect everybody to dig back FOUR MONTHS worth of mail
> backlog to find an topic that may or may not be abandoned by the original
> author. Perhaps we would need a weekly posting of topics people have
Well, I've mentioned it earlier in this thread, though without a link.
It's the time when several of us are off-line for a couple weeks. I've
also mentioned it in the thread about filtering by remote.
On a side note, the list here usually does require people to search
back, and much longer than this, on frequently requested issues. But how
does a newcomer discover "frequently"? Right, by searching back years,
not months.
> posted, found to be not quite ready yet, and are still being polished and
> not abandoned [*1*]?
>
> Having said that, I still appreciate that you posted a link to the
> previous topic:
>
> http://thread.gmane.org/gmane.comp.version-control.git/172226
>
> so that the discussions in this thread to scratch the same "itch" can
> benefit from the points raised in the previous thread that need to be
> considered.
>
> The old thread talks about renaming existing options and transition plans
> to make the "listing" mode of "branch" and "tag" more similar, which may
> be a good plan in the longer term.
>
> I however can see that teaching "--glob" to both "branch" and "tag" (in
> other words, "tag -l" would become a synonym for "tag --glob") an equally
> good longer term plan.
I don't care about the names, but I'd hate to introduce more
inconsistencies. The implementation is a non-brainer, it's really
something only Apple could get a patent on. The other Michael and I came
up with basically the same patch because it follows "automatically". But
the ui is important.
So I'll take the opportunity and discuss this further in the cover
letter for the upcoming series.
Michael
^ permalink raw reply
* [PATCH 0/5] RFC: patterns for branch list
From: Michael J Gruber @ 2011-08-25 8:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Michael Schubert
In-Reply-To: <4E5607E0.1050300@drmicha.warpmail.net>
This mini series is about introducing patterns to the list mode of
'git branch' much like the pattern for 'git tag -l'. There are several
related things which are to be considered for the ui design:
git log
=======
For "log" and friends, "--glob" is a means to specify revision arguments by
matching refs. Note that we have
--branches[=<pattern>] matching in refs/heads
--tags[=<pattern>] matching in refs/tags
--glob=<glob-pattern> matching in refs/
git tag
=======
For "tag", we have a pattern matching in refs/tags, but only in the list mode
of "tag", which is invoked by "-l", or automatically when there are no
arguments. There is no pattern related option, it's "always on" in list mode.
I.e., in list mode it behaves much like
git log --no-walk --oneline --tags=
with a different format string, and an optional argument stuck at the end of
the line. (git for-each-ref is another related interface, but plumbing, so I'll
skip it here.)
git branch
==========
Analogous to "git tag", "branch" has several modes, one of which is list mode.
It is currently activated (and possibly modified) by "-v" and "-vv", and when
there are no arguments. So, at the least,
git branch -v[v] <pattern>
should match just like "git tag -l <pattern>" does. And that is what the first
patch in my series does.
Then we need an option to invoke list mode. The natural candidate "-l" is taken
by the badly named reflog option, which is why I suggested "--list" and moving
the reflog option to "-g" over time.
I'm open to other suggestions as long as they keep and improve the consistency
between "git tag" and "git branch". I never liked their different implicit
modes/subcommands but have been around long enough to know that they are there
to stay.
"git tag" should probably learn the same long option and others. And why not
verify tags given by a pattern?
Both "tag" and "branch" could activate list mode automatically on an invalid
tag name rather than dieing:
git tag v1.7.6\*
Warning: tag 'v1.7.6*' not found.
v1.7.6
v1.7.6-rc0
v1.7.6-rc1
v1.7.6-rc2
v1.7.6-rc3
v1.7.6.1
On the other hand, one might think about implementing both list modes (tag and
branch) using the revision machinery and custom format strings, or
for-each-ref; rather than both differently as it is now.
'-l' is the natural short option name for '--list'. This is taken for the
rarely used or needed 'create reflog' option. I'd change the latter to
'-g,--create-reflog' (cmp. log) and take '-l,--list' but know the reaction
already.
-v[v] sanity
============
'-v' and '-vv' both take considerable time (because they need to walk).
It makes more sense to have '-v' display cheap output (upstream name)
and '-vv' add expensive output (ahead/behind info). '-vvv' could add super
expensive info (ahead/equivalent/behind a la cherry-mark).
These are changes to current porcelain ui behaviour, so I deem this to be OK
(too late for 1.7.7, of course). The option renaming needs a transition
(not done in this series).
Michael J Gruber (5):
branch: allow pattern arguments
branch: introduce --list argument
t6040; test branch -vv [independent, can go in as is testing current behaviour]
branch: restructure -v vs. -vv
branch: give patchsame count with -vvv
Documentation/git-branch.txt | 20 +++++++++---
builtin/branch.c | 65 +++++++++++++++++++++++++----------------
remote.c | 12 ++++++--
remote.h | 2 +-
t/t3203-branch-output.sh | 24 +++++++++++++++
t/t6040-tracking-info.sh | 41 ++++++++++++++++++++++++--
wt-status.c | 2 +-
7 files changed, 127 insertions(+), 39 deletions(-)
--
1.7.6.845.gc3c05
^ permalink raw reply
* [PATCH 3/5] t6040; test branch -vv
From: Michael J Gruber @ 2011-08-25 8:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Michael Schubert
In-Reply-To: <cover.1314259226.git.git@drmicha.warpmail.net>
t6040 has a test for 'git branch -v' but not for 'git branch -vv'.
Add one.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t6040-tracking-info.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 19de5b1..19272bc 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -51,6 +51,22 @@ test_expect_success 'branch -v' '
test_i18ncmp expect actual
'
+cat >expect <<\EOF
+b1 origin/master: ahead 1, behind 1
+b2 origin/master: ahead 1, behind 1
+b3 origin/master: behind 1
+b4 origin/master: ahead 2
+EOF
+
+test_expect_success 'branch -vv' '
+ (
+ cd test &&
+ git branch -vv
+ ) |
+ sed -n -e "$script" >actual &&
+ test_i18ncmp expect actual
+'
+
test_expect_success 'checkout' '
(
cd test && git checkout b1
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCH 5/5] branch: give patchsame count with -vvv
From: Michael J Gruber @ 2011-08-25 8:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Michael Schubert
In-Reply-To: <cover.1314259226.git.git@drmicha.warpmail.net>
This results in output like such as
mjg/attr-filetype 9d2536e [origin/next: ahead 35,
behind 1430, same 46] attr: make attributes depend on file type
all on one line.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 2 ++
builtin/branch.c | 24 ++++++++++++++++--------
remote.c | 12 +++++++++---
remote.h | 2 +-
t/t6040-tracking-info.sh | 19 ++++++++++++++++++-
wt-status.c | 2 +-
6 files changed, 47 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 59d729a..770b2e4 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -117,6 +117,8 @@ OPTIONS
Show sha1 and commit subject line for each head, along with
the name of the upstream branch (if any). If given twice, print
the relationship to the upstream branch (ahead/behind), as well.
+ If given three times, show ahead/behind/same information like
+ `git rev-list --count --cherry-mark`.
`--list` is implied by all verbosity options.
--abbrev=<length>::
diff --git a/builtin/branch.c b/builtin/branch.c
index 21ef5fc..0984bb7 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -361,7 +361,7 @@ static int ref_cmp(const void *r1, const void *r2)
static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
int verbose)
{
- int ours, theirs;
+ int ours, theirs, patchsame = 0;
struct branch *branch = branch_get(branch_name);
/* verbose >= 1 */
@@ -370,14 +370,22 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
strbuf_addch(stat, '[');
strbuf_addstr(stat, shorten_unambiguous_ref(branch->merge[0]->dst, 0));
- if (verbose >= 2 && stat_tracking_info(branch, &ours, &theirs)) {
- strbuf_addstr(stat, ": ");
- if (!ours)
- strbuf_addf(stat, _("behind %d"), theirs);
- else if (!theirs)
+ if (verbose >= 2 && stat_tracking_info(branch, &ours, &theirs, (verbose >=3) ? &patchsame : NULL)) {
+ strbuf_addstr(stat, _(": "));
+ const char *sep = "";
+ if (ours) {
strbuf_addf(stat, _("ahead %d"), ours);
- else
- strbuf_addf(stat, _("ahead %d, behind %d"), ours, theirs);
+ sep = _(", ");
+ }
+ if (theirs) {
+ strbuf_addstr(stat, sep);
+ strbuf_addf(stat, _("behind %d"), theirs);
+ sep = _(", ");
+ }
+ if (patchsame) {
+ strbuf_addstr(stat, sep);
+ strbuf_addf(stat, _("same %d"), patchsame);
+ }
}
strbuf_addstr(stat, "] ");
}
diff --git a/remote.c b/remote.c
index b8ecfa5..40cebef 100644
--- a/remote.c
+++ b/remote.c
@@ -1510,7 +1510,7 @@ int ref_newer(const unsigned char *new_sha1, const unsigned char *old_sha1)
/*
* Return true if there is anything to report, otherwise false.
*/
-int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
+int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs, int *num_patchsame)
{
unsigned char sha1[20];
struct commit *ours, *theirs;
@@ -1553,6 +1553,8 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
rev_argv[rev_argc++] = NULL;
rev_argv[rev_argc++] = "--left-right";
rev_argv[rev_argc++] = symmetric;
+ if (num_patchsame)
+ rev_argv[rev_argc++] = "--cherry-mark";
rev_argv[rev_argc++] = "--";
rev_argv[rev_argc] = NULL;
@@ -1567,11 +1569,15 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
/* ... and count the commits on each side. */
*num_ours = 0;
*num_theirs = 0;
+ if (num_patchsame)
+ *num_patchsame = 0;
while (1) {
struct commit *c = get_revision(&revs);
if (!c)
break;
- if (c->object.flags & SYMMETRIC_LEFT)
+ if (c->object.flags & PATCHSAME)
+ (*num_patchsame)++;
+ else if (c->object.flags & SYMMETRIC_LEFT)
(*num_ours)++;
else
(*num_theirs)++;
@@ -1591,7 +1597,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
int num_ours, num_theirs;
const char *base;
- if (!stat_tracking_info(branch, &num_ours, &num_theirs))
+ if (!stat_tracking_info(branch, &num_ours, &num_theirs, NULL))
return 0;
base = branch->merge[0]->dst;
diff --git a/remote.h b/remote.h
index 9a30a9d..31c1f28 100644
--- a/remote.h
+++ b/remote.h
@@ -149,7 +149,7 @@ enum match_refs_flags {
};
/* Reporting of tracking info */
-int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs);
+int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs, int *num_patchsame);
int format_tracking_info(struct branch *branch, struct strbuf *sb);
struct ref *get_local_heads(void);
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 9539882..f8bff61 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -24,6 +24,7 @@ test_expect_success setup '
advance d &&
git checkout -b b2 origin &&
git reset --hard b1 &&
+ git cherry-pick origin &&
git checkout -b b3 origin &&
git reset --hard HEAD^ &&
git checkout -b b4 origin &&
@@ -53,7 +54,7 @@ test_expect_success 'branch -v' '
cat >expect <<\EOF
b1 origin/master: ahead 1, behind 1
-b2 origin/master: ahead 1, behind 1
+b2 origin/master: ahead 2, behind 1
b3 origin/master: behind 1
b4 origin/master: ahead 2
EOF
@@ -67,6 +68,22 @@ test_expect_success 'branch -vv' '
test_i18ncmp expect actual
'
+cat >expect <<\EOF
+b1 origin/master: ahead 1, behind 1
+b2 origin/master: ahead 1, same 2
+b3 origin/master: behind 1
+b4 origin/master: ahead 2
+EOF
+
+test_expect_success 'branch -vvv' '
+ (
+ cd test &&
+ git branch -vvv
+ ) |
+ sed -n -e "$script" >actual &&
+ test_i18ncmp expect actual
+'
+
test_expect_success 'checkout' '
(
cd test && git checkout b1
diff --git a/wt-status.c b/wt-status.c
index 8836a52..522318a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -890,7 +890,7 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)
branch = branch_get(s->branch + 11);
if (s->is_initial)
color_fprintf(s->fp, header_color, _("Initial commit on "));
- if (!stat_tracking_info(branch, &num_ours, &num_theirs)) {
+ if (!stat_tracking_info(branch, &num_ours, &num_theirs, NULL)) {
color_fprintf_ln(s->fp, branch_color_local,
"%s", branch_name);
return;
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCH 1/5] branch: allow pattern arguments
From: Michael J Gruber @ 2011-08-25 8:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Michael Schubert
In-Reply-To: <cover.1314259226.git.git@drmicha.warpmail.net>
Allow pattern arguments for the list mode just like for git tag -l.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 7 +++++--
builtin/branch.c | 13 +++++++++----
t/t3203-branch-output.sh | 10 ++++++++++
3 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index c50f189..2152d48 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
[-v [--abbrev=<length> | --no-abbrev]]
- [(--merged | --no-merged | --contains) [<commit>]]
+ [(--merged | --no-merged | --contains) [<commit>]] [<pattern>]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
@@ -20,7 +20,10 @@ DESCRIPTION
With no arguments, existing branches are listed and the current branch will
be highlighted with an asterisk. Option `-r` causes the remote-tracking
-branches to be listed, and option `-a` shows both.
+branches to be listed, and option `-a` shows both. This list mode is also
+activated by the `-v` option (see below).
+<pattern> restricts the output to matching branches, the pattern is a shell
+wildcard (i.e., matched using fnmatch(3))
With `--contains`, shows only the branches that contain the named commit
(in other words, the branches whose tip commits are descendants of the
diff --git a/builtin/branch.c b/builtin/branch.c
index 73d4170..6b40815 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -260,6 +260,7 @@ static char *resolve_symref(const char *src, const char *prefix)
struct append_ref_cb {
struct ref_list *ref_list;
+ const char *pattern;
int ret;
};
@@ -297,6 +298,9 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
if ((kind & ref_list->kinds) == 0)
return 0;
+ if (cb->pattern && fnmatch(cb->pattern, refname, 0))
+ return 0;
+
commit = NULL;
if (ref_list->verbose || ref_list->with_commit || merge_filter != NO_FILTER) {
commit = lookup_commit_reference_gently(sha1, 1);
@@ -492,7 +496,7 @@ static void show_detached(struct ref_list *ref_list)
}
}
-static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
+static int print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit, const char *pattern)
{
int i;
struct append_ref_cb cb;
@@ -506,6 +510,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
if (merge_filter != NO_FILTER)
init_revisions(&ref_list.revs, NULL);
cb.ref_list = &ref_list;
+ cb.pattern = pattern;
cb.ret = 0;
for_each_rawref(append_ref, &cb);
if (merge_filter != NO_FILTER) {
@@ -523,7 +528,7 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
detached = (detached && (kinds & REF_LOCAL_BRANCH));
- if (detached)
+ if (detached && (!pattern || !fnmatch(pattern, "HEAD", 0)))
show_detached(&ref_list);
for (i = 0; i < ref_list.index; i++) {
@@ -695,8 +700,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
- else if (argc == 0)
- return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
+ else if (argc == 0 || (verbose && argc == 1))
+ return print_ref_list(kinds, detached, verbose, abbrev, with_commit, argc ? argv[0] : NULL);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
else if (rename && (argc == 2))
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 6b7c118..2df1d3d 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -67,6 +67,16 @@ test_expect_success 'git branch -v shows branch summaries' '
'
cat >expect <<'EOF'
+two
+one
+EOF
+test_expect_success 'git branch -v pattern shows branch summaries' '
+ git branch -v branch* >tmp &&
+ awk "{print \$NF}" <tmp >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
* (no branch)
branch-one
branch-two
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCH 4/5] branch: restructure -v vs. -vv
From: Michael J Gruber @ 2011-08-25 8:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Michael Schubert
In-Reply-To: <cover.1314259226.git.git@drmicha.warpmail.net>
ahead/behind info is expensive, upstream name info cheap. Therefore,
make -v output the upstream branch name and -vv add the ahead/behind
info.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 4 ++--
builtin/branch.c | 34 ++++++++++++++++------------------
t/t6040-tracking-info.sh | 8 ++++----
3 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 789ff02..59d729a 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -115,8 +115,8 @@ OPTIONS
-v::
--verbose::
Show sha1 and commit subject line for each head, along with
- relationship to upstream branch (if any). If given twice, print
- the name of the upstream branch, as well.
+ the name of the upstream branch (if any). If given twice, print
+ the relationship to the upstream branch (ahead/behind), as well.
`--list` is implied by all verbosity options.
--abbrev=<length>::
diff --git a/builtin/branch.c b/builtin/branch.c
index aed0aca..21ef5fc 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -359,29 +359,27 @@ static int ref_cmp(const void *r1, const void *r2)
}
static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
- int show_upstream_ref)
+ int verbose)
{
int ours, theirs;
struct branch *branch = branch_get(branch_name);
- if (!stat_tracking_info(branch, &ours, &theirs)) {
- if (branch && branch->merge && branch->merge[0]->dst &&
- show_upstream_ref)
- strbuf_addf(stat, "[%s] ",
- shorten_unambiguous_ref(branch->merge[0]->dst, 0));
+ /* verbose >= 1 */
+ if (!(branch && branch->merge && branch->merge[0]->dst))
return;
- }
-
strbuf_addch(stat, '[');
- if (show_upstream_ref)
- strbuf_addf(stat, "%s: ",
- shorten_unambiguous_ref(branch->merge[0]->dst, 0));
- if (!ours)
- strbuf_addf(stat, _("behind %d] "), theirs);
- else if (!theirs)
- strbuf_addf(stat, _("ahead %d] "), ours);
- else
- strbuf_addf(stat, _("ahead %d, behind %d] "), ours, theirs);
+ strbuf_addstr(stat, shorten_unambiguous_ref(branch->merge[0]->dst, 0));
+
+ if (verbose >= 2 && stat_tracking_info(branch, &ours, &theirs)) {
+ strbuf_addstr(stat, ": ");
+ if (!ours)
+ strbuf_addf(stat, _("behind %d"), theirs);
+ else if (!theirs)
+ strbuf_addf(stat, _("ahead %d"), ours);
+ else
+ strbuf_addf(stat, _("ahead %d, behind %d"), ours, theirs);
+ }
+ strbuf_addstr(stat, "] ");
}
static int matches_merge_filter(struct commit *commit)
@@ -408,7 +406,7 @@ static void add_verbose_info(struct strbuf *out, struct ref_item *item,
}
if (item->kind == REF_LOCAL_BRANCH)
- fill_tracking_info(&stat, item->name, verbose > 1);
+ fill_tracking_info(&stat, item->name, verbose);
strbuf_addf(out, " %s %s%s",
find_unique_abbrev(item->commit->object.sha1, abbrev),
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index 19272bc..9539882 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -36,10 +36,10 @@ test_expect_success setup '
script='s/^..\(b.\)[ 0-9a-f]*\[\([^]]*\)\].*/\1 \2/p'
cat >expect <<\EOF
-b1 ahead 1, behind 1
-b2 ahead 1, behind 1
-b3 behind 1
-b4 ahead 2
+b1 origin/master
+b2 origin/master
+b3 origin/master
+b4 origin/master
EOF
test_expect_success 'branch -v' '
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCH 2/5] branch: introduce --list argument
From: Michael J Gruber @ 2011-08-25 8:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Michael Schubert
In-Reply-To: <cover.1314259226.git.git@drmicha.warpmail.net>
Currently, there is no way to invoke the list mode with a pattern
because this is interpreted as branch creation.
Introduce a --list argument which invokes the list mode.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-branch.txt | 9 +++++++--
builtin/branch.c | 10 +++++++---
t/t3203-branch-output.sh | 14 ++++++++++++++
3 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 2152d48..789ff02 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git branch' [--color[=<when>] | --no-color] [-r | -a]
- [-v [--abbrev=<length> | --no-abbrev]]
+ [--list] [-v [--abbrev=<length> | --no-abbrev]]
[(--merged | --no-merged | --contains) [<commit>]] [<pattern>]
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
@@ -21,7 +21,7 @@ DESCRIPTION
With no arguments, existing branches are listed and the current branch will
be highlighted with an asterisk. Option `-r` causes the remote-tracking
branches to be listed, and option `-a` shows both. This list mode is also
-activated by the `-v` option (see below).
+activated by the `--list` and `-v` options (see below).
<pattern> restricts the output to matching branches, the pattern is a shell
wildcard (i.e., matched using fnmatch(3))
@@ -108,11 +108,16 @@ OPTIONS
-a::
List both remote-tracking branches and local branches.
+--list::
+ Activate the list mode. `git branch <pattern>` would try to create a branch,
+ use `git branch --list <pattern>` to list matching branches.
+
-v::
--verbose::
Show sha1 and commit subject line for each head, along with
relationship to upstream branch (if any). If given twice, print
the name of the upstream branch, as well.
+ `--list` is implied by all verbosity options.
--abbrev=<length>::
Alter the sha1's minimum display length in the output listing.
diff --git a/builtin/branch.c b/builtin/branch.c
index 6b40815..aed0aca 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -617,7 +617,7 @@ static int opt_parse_merge_filter(const struct option *opt, const char *arg, int
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, rename = 0, force_create = 0;
+ int delete = 0, rename = 0, force_create = 0, list = 0;
int verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;
int reflog = 0;
enum branch_track track;
@@ -656,6 +656,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('D', NULL, &delete, "delete branch (even if not merged)", 2),
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
+ OPT_BOOLEAN(0, "list", &list, "list branch names"),
OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
OPT__FORCE(&force_create, "force creation (when already exists)"),
{
@@ -695,12 +696,15 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, builtin_branch_usage,
0);
- if (!!delete + !!rename + !!force_create > 1)
+ if (!!delete + !!rename + !!force_create + !!list > 1)
usage_with_options(builtin_branch_usage, options);
+ if (argc == 0 || (verbose && argc == 1))
+ list = 1;
+
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
- else if (argc == 0 || (verbose && argc == 1))
+ else if (list)
return print_ref_list(kinds, detached, verbose, abbrev, with_commit, argc ? argv[0] : NULL);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index 2df1d3d..f2b294b 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -32,6 +32,20 @@ test_expect_success 'git branch shows local branches' '
test_cmp expect actual
'
+test_expect_success 'git branch --list shows local branches' '
+ git branch --list >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<'EOF'
+ branch-one
+ branch-two
+EOF
+test_expect_success 'git branch --list pattern shows matching local branches' '
+ git branch --list branch* >actual &&
+ test_cmp expect actual
+'
+
cat >expect <<'EOF'
origin/HEAD -> origin/branch-one
origin/branch-one
--
1.7.6.845.gc3c05
^ permalink raw reply related
* [PATCH] git-notes.txt: clarify -C vs. copy and -F
From: Michael J Gruber @ 2011-08-25 10:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johan Herland
In-Reply-To: <7v1v1pr97x.fsf@alter.siamese.dyndns.org>
The current description of '-C' together with the analogy to 'git commit
-C' can lead to the wrong conclusion that '-C' copies notes between
objects. Make this clearer by rewording and pointing to 'copy'.
The example for attaching binary notes with 'git hash-object' followed
by 'git notes add -C' immediately raises the question: "Why not use 'git
notes add -F'?". Answer it (the latter is not binary-safe).
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
This one has been lying around and fell under the rugs of the discussion
for a ui redesign which never happened. So I think it's still worth it.
---
Documentation/git-notes.txt | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
index 6a187f2..e8319ea 100644
--- a/Documentation/git-notes.txt
+++ b/Documentation/git-notes.txt
@@ -142,8 +142,9 @@ OPTIONS
-C <object>::
--reuse-message=<object>::
- Take the note message from the given blob object (for
- example, another note).
+ Take the given blob object (for example, another note) as the
+ note message. (Use `git notes copy <object>` instead to
+ copy notes between objects.)
-c <object>::
--reedit-message=<object>::
@@ -285,6 +286,8 @@ $ blob=$(git hash-object -w a.out)
$ git notes --ref=built add -C "$blob" HEAD
------------
+(You cannot simply use `git notes --ref=built add -F a.out HEAD`
+because that is not binary-safe.)
Of course, it doesn't make much sense to display non-text-format notes
with 'git log', so if you use such notes, you'll probably need to write
some special-purpose tools to do something useful with them.
--
1.7.6.845.gc3c05
^ 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