* What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-10-12 3:18 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'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
As a post-release ritual, I've rebuilt 'next' on top of 'master'.
--------------------------------------------------
[Graduated to "master"]
* ch/am-header (2009-09-25) 2 commits
(merged to 'next' on 2009-09-25 at f86e197)
+ git-am: force egrep to use correct characters set
+ git-am: fixed patch_format detection according to RFC2822
* ef/msvc-noreturn (2009-09-30) 2 commits
(merged to 'next' on 2009-10-07 at 66137a0)
+ add NORETURN_PTR for function pointers
+ increase portability of NORETURN declarations
jk: This is the latest round and I think should be ready for at least
'next' (maybe even 'master' as it is really about the build and not about
functionality).
* fc/mutt-alias (2009-09-30) 1 commit
(merged to 'next' on 2009-10-07 at df7ac20)
+ send-email: fix mutt regex for grouped aliases
jk: Latest round that addressed comments. Ready for 'next' if not
'master'.
* jk/reflog-date (2009-09-24) 1 commit
(merged to 'next' on 2009-09-29 at 43d444a)
+ improve reflog date/number heuristic
--------------------------------------------------
[New Topics]
* jp/maint-send-email-fold (2009-10-08) 1 commit.
- git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
* ks/precompute-completion (2009-10-05) 1 commit.
- Speedup bash completion loading
* pv/maint-add-p-no-exclude (2009-10-10) 1 commit.
(merged to 'next' on 2009-10-11 at 0ff2e96)
+ git-add--interactive: never skip files included in index
* sp/smart-http (2009-10-08) 4 commits.
- Smart fetch and push over HTTP: server side
- Add smart-http options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- Document the HTTP transport protocol
--------------------------------------------------
[Stalled]
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Ejected from 'next' as fast-import folks still seem to be discussing with
how to proceed.
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits.
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper. There is a re-roll planned.
* ne/rev-cache (2009-09-07) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
This seems to break at least t6001 when merged to 'pu'.
--------------------------------------------------
[Cooking]
* dk/blame-el (2009-09-29) 1 commit.
- git-blame.el: Change how blame information is shown.
Soon in 'next'.
* ef/msys-imap (2009-10-09) 8 commits.
- MSVC: Enable OpenSSL, and translate -lcrypto
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
- imap-send: remove useless uid code
* jn/gitweb-patch (2009-10-09) 1 commit.
- gitweb: Do not show 'patch' link for merge commits
Soon in 'next'
* mr/gitweb-snapshot (2009-09-26) 2 commits.
- gitweb: append short hash ids to snapshot files
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
* mr/instaweb-cgid (2009-09-26) 1 commit.
(merged to 'next' on 2009-10-11 at 99bcfaf)
+ instaweb: support mod_cgid for apache2
* tf/doc-pt-br (2009-09-23) 1 commit.
- Documentation: update pt-BR
The current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language
definition is not widely distributed yet (it just hit the development
tree). Need to revert these headings (or change the length of the section
underlines to match the length of translated names).
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
I am not happy with this one yet. I am contemplating to introduce a new
syntax "%[magic(param)<anything>%]" to generalize expressions of this and
line wrapping features in an extensible way.
* js/log-rewrap (2008-11-10) 3 commits.
. Add "%w" to pretty formats, which rewraps the commit message
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
... and the first two from this series will be useful to implement an
example magic "wrap", e.g. "%[wrap(i,j,w)%s%+b%]".
* jg/log-format-body-indent (2009-09-19) 1 commit.
- git-log --format: Add %B tag with %B(x) option
I think we should redo this on top of the first two patches from
js/log-rewrap series; %B(x) is just a special case %B(x,x,0), no? If a
magic value 0 (or negative) given to wrap-width does not disable wrapping,
we probably should make it so.
* bg/rebase-reword (2009-10-07) 1 commit.
- Teach 'rebase -i' the command "reword"
Soon in 'next'
* js/diff-verbose-submodule (2009-10-04) 1 commit.
- Add the --submodule-summary option to the diff option family
Dscho sounded like he has some corrections after list comments, but I did
not pick up his interdiff in the middle.
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* jc/fix-tree-walk (2009-09-14) 10 commits.
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- Aggressive three-way merge: fix D/F case
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
- unpack_callback(): use unpack_failed() consistently
- unpack-trees: typofix
- diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
This includes the fix to aggressive mode of three-way merge used by the
resolve strategy. I think the series is Ok for 'next'.
* jp/fetch-tag-match (2009-09-17) 1 commit.
- fetch: Speed up fetch by rewriting find_non_local_tags
I just queued this without reading nor thinking about it very much. I
personally liked my version that had far smaller number of lines changed
(which means I can be fairly certain that it did not introduce any
regression), but perhaps the majorly rewritten logic this patch gives us
may be easier to follow and maintain.
* jc/maint-blank-at-eof (2009-09-15) 0 commits.
(this branch uses jc/maint-1.6.0-blank-at-eof.)
The series does not have a commit of its own but is a preparation for
merging the original jc/1.6.0-maint-blank-at-eof topic to 'maint' and then
'master'
Soon in 'next'
* db/vcs-helper-rest (2009-09-03) 6 commits.
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged in 1.6.5.
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Add selftests verifying concatenation of multiple notes for the same commit
- Refactor notes code to concatenate multiple notes annotating the same object
- Add selftests verifying that we can parse notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- Teach notes code to free its internal data structures on request
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
Rerolled and queued.
* jn/gitweb-show-size (2009-09-07) 1 commit.
- gitweb: Add 'show-sizes' feature to show blob sizes in tree view
Soon in 'next'
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-10-11 at 7f34fb3)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* cc/reset-merge (2009-09-16) 4 commits.
. reset: add test cases for "--merge-safe" option
. reset: add option "--merge-safe" to "git reset"
. reset: use "unpack_trees()" directly instead of "git read-tree"
. reset: add a few tests for "git reset --merge"
* cc/sequencer-rebase-i (2009-08-28) 15 commits.
. rebase -i: use "git sequencer--helper --cherry-pick"
. sequencer: add "--cherry-pick" option to "git sequencer--helper"
. sequencer: add "do_commit()" and related functions working on "next_commit"
. pick: libify "pick_help_msg()"
. revert: libify cherry-pick and revert functionnality
. rebase -i: use "git sequencer--helper --fast-forward"
. sequencer: let "git sequencer--helper" callers set "allow_dirty"
. sequencer: add "--fast-forward" option to "git sequencer--helper"
. sequencer: add "do_fast_forward()" to perform a fast forward
. rebase -i: use "git sequencer--helper --reset-hard"
. sequencer: add "--reset-hard" option to "git sequencer--helper"
. sequencer: add "reset_almost_hard()" and related functions
. rebase -i: use "git sequencer--helper --make-patch"
. sequencer: add "make_patch" function to save a patch
. sequencer: add "builtin-sequencer--helper.c"
* lt/maint-traverse-trees-fix (2009-09-06) 1 commit.
. Prepare 'traverse_trees()' for D/F conflict lookahead
^ permalink raw reply
* Re: git log --graph
From: Dilip M @ 2009-10-12 3:01 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0910111135v4f3c75a7v6657f5dcfacf13ac@mail.gmail.com>
On Mon, Oct 12, 2009 at 12:05 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
>> I am trying git log --graph. (has commits in two branches...). But
>> always see one line :(
>
> It'll show you the history of one branch at a time online, you won't
> get the demo-ed multiple lines unless the branch you're looking at
> contains merges.
Understood. it shows only when I have merged conflicts!
In case, it is a fast forward merge. It doesn't show. Which is good :)
Thanks to all.
-
Dilip
^ permalink raw reply
* [PATCH] Aggressive three-way merge: fix D/F case
From: Junio C Hamano @ 2009-10-12 2:53 UTC (permalink / raw)
To: git
When the ancestor used to have a blob "P", your tree removed it, and the
tree you are merging with also removed it, the agressive three-way cleanly
merges to remove that blob. If the other tree added a new blob "P/Q"
while removing "P", it should also merge cleanly to remove "P" and create
"P/Q" (since neither the ancestor nor your tree could have had it, so it
is a typical "created in one").
The "aggressive" rule is not new anymore. Reword the stale comment.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This fixes one problem in the 3-way merge with corrected tree/index
entry order the jc/fix-tree-walk topic exposes.
t/t6035-merge-dir-to-symlink.sh | 2 +-
unpack-trees.c | 13 ++++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/t6035-merge-dir-to-symlink.sh b/t/t6035-merge-dir-to-symlink.sh
index b9a280e..d1b2287 100755
--- a/t/t6035-merge-dir-to-symlink.sh
+++ b/t/t6035-merge-dir-to-symlink.sh
@@ -74,7 +74,7 @@ test_expect_success 'setup a merge where dir a/b-2 changed to symlink' '
git tag test2
'
-test_expect_failure 'merge should not have conflicts (resolve)' '
+test_expect_success 'merge should not have conflicts (resolve)' '
git reset --hard &&
git checkout baseline^0 &&
git merge -s resolve test2 &&
diff --git a/unpack-trees.c b/unpack-trees.c
index c424bab..ec12341 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -767,7 +767,8 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
remote = NULL;
}
- /* First, if there's a #16 situation, note that to prevent #13
+ /*
+ * First, if there's a #16 situation, note that to prevent #13
* and #14.
*/
if (!same(remote, head)) {
@@ -781,7 +782,8 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
}
}
- /* We start with cases where the index is allowed to match
+ /*
+ * We start with cases where the index is allowed to match
* something other than the head: #14(ALT) and #2ALT, where it
* is permitted to match the result instead.
*/
@@ -811,12 +813,13 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
if (!head && !remote && any_anc_missing)
return 0;
- /* Under the new "aggressive" rule, we resolve mostly trivial
+ /*
+ * Under the "aggressive" rule, we resolve mostly trivial
* cases that we historically had git-merge-one-file resolve.
*/
if (o->aggressive) {
- int head_deleted = !head && !df_conflict_head;
- int remote_deleted = !remote && !df_conflict_remote;
+ int head_deleted = !head;
+ int remote_deleted = !remote;
struct cache_entry *ce = NULL;
if (index)
--
1.6.5.59.g7e3f2
^ permalink raw reply related
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-12 2:46 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091012014007.GA7674@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So now I am doubly confused. Did this feature exist, and was broken, and
> you actually fixed it in 63d285c, creating what looked like a regression
> but was actually intentional?
I do not think it was an intentional change. I _think_ the comment at the
beginning of show_files() tells us quite a bit---we don't do read-dir when
showing the indexed files, and I suspect that we used to rely on the fact
that not doing the read-dir made exclusion mechanism a no-op. After the
lazy .gitignore reading, I suspect that excluded() call started to
initialize the exclude mechanism lazily, and that is how the bug was
introduced, isn't it?
Regarding your patch, the loops deal with paths that are already in the
index, so removing the conditional skip looks like a sane thing to do.
^ permalink raw reply
* Re: [PATCH] disallow refs containing successive slashes
From: Nanako Shiraishi @ 2009-10-12 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vbpkdwyo2.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> Yes, one solution could be to fix every application handling branch, tag
>> or repo names to mimic the namechange done in the bowels of git. But i
>> think it is not worth the hassle.
> Besides, by rejecting what we used to accept you are breaking people's
> expectations. So I am moderately negative, unless you can say your "every
> application" is literally _tons_.
Isn't 1.7.0 a good release to break such people's expectations?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-12 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7vpr8tr2pe.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 03:22:05PM -0700, Junio C Hamano wrote:
> > I don't know if it is worth fixing now or not. It does seem a bit
> > inconsistent to me (since everything else is very clear that .gitignore
> > is only about untracked files), but nobody seems to have been
> > complaining for the last two years (and they may have, in fact, been
> > coding to the new behavior).
>
> This is one of those moments when I feel very blessed to have competent
> and diligent people around me ;-)
Well, I have to do _something_ to make up for all the brown paper bag
bugs. ;)
> I think you are right; that we shouldn't filter the output with gitignore
> entries when showing what is _in_ the index.
So being the diligent and competent soul that I am, I started to prepare
a patch for this, which is included below. But the plot thickens.
I bisected the change of behavior to 63d285c, as I mentioned. But when I
found the code that needed to be tweaked, it actually git-blames to a
much earlier date in "git show-files", which later became ls-files. See
9ff768e.
So now I am doubly confused. Did this feature exist, and was broken, and
you actually fixed it in 63d285c, creating what looked like a regression
but was actually intentional?
And more importantly, what do you want to do with it now?
---
builtin-ls-files.c | 8 --------
t/t3003-ls-files-exclude.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 8 deletions(-)
create mode 100755 t/t3003-ls-files-exclude.sh
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 2c95ca6..c5c0407 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -170,10 +170,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
if (show_cached | show_stage) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (show_unmerged && !ce_stage(ce))
continue;
if (ce->ce_flags & CE_UPDATE)
@@ -186,10 +182,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
struct cache_entry *ce = active_cache[i];
struct stat st;
int err;
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (ce->ce_flags & CE_UPDATE)
continue;
err = lstat(ce->name, &st);
diff --git a/t/t3003-ls-files-exclude.sh b/t/t3003-ls-files-exclude.sh
new file mode 100755
index 0000000..fc1e379
--- /dev/null
+++ b/t/t3003-ls-files-exclude.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='ls-files --exclude does not affect index files'
+. ./test-lib.sh
+
+test_expect_success 'create repo with file' '
+ echo content >file &&
+ git add file &&
+ git commit -m file &&
+ echo modification >file
+'
+
+check_output() {
+test_expect_success "ls-files output contains file ($1)" "
+ echo '$2' >expect &&
+ git ls-files --exclude-standard --$1 >output &&
+ test_cmp expect output
+"
+}
+
+check_all_output() {
+ check_output 'cached' 'file'
+ check_output 'modified' 'file'
+}
+
+check_all_output
+test_expect_success 'add file to gitignore' '
+ echo file >.gitignore
+'
+check_all_output
+
+test_done
--
1.6.5.rc3.240.g77692
^ permalink raw reply related
* Re: [PATCH] disallow refs containing successive slashes
From: Jonathan Nieder @ 2009-10-12 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vbpkdwyo2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> When the users make typoes (e.g. /foo//bar) you can accept the only sane
> correction (e.g. foo/bar) instead of rejecting, since the only thing the
> user can do after getting such a rejection is to correct it to that
> corrected name (e.g. foo/bar) himself and re-issue the command anyway.
> You can push the "hassle" down to the user, or you can fix the tool to
> remove the hassle from the user.
Yes, making check-ref-format stricter without changing its users to
massage their input would be a regression.
The problem Jens described is a git-gui bug. In lib/branch_delete.tcl,
line 57, the list of deletable branches is populated as follows:
foreach h [load_all_heads] {
if {$h ne $current_branch} {
$w_heads insert end $h
}
}
Since slashes coalesce, a user-supplied new branch name is not canonical
and checking "$h eq $current_branch" does not actually check if they are
the same branch. git-gui should be using the branch name as output by
"git check-ref-format --branch" after the branch is created.
But what about other scripts that assume each branch has only one
possible name? Maybe they could be forced to fix up the name early on
by making check-ref-format reject names with "//" in them and providing
a "git check-ref-format --print" to help.
Upside: scripts would complain loudly instead of failing subtly on input
with extra slashes if they forget to use "git check-ref-format --print"
when appropriate. Downside: users, including the 22 callers of
check_ref_format() in git, would have to be checked and probably changed
to avoid regressions.
Never having made that typo, I find it hard to consider such a change
worth the trouble, but it sounds doable.
Regards,
Jonathan
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Johannes Schindelin @ 2009-10-12 0:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Eugene Sajine, git
In-Reply-To: <200910102045.13374.jnareb@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 806 bytes --]
Hi,
On Sat, 10 Oct 2009, Jakub Narebski wrote:
> On Sat, 10 Oct 2009, Eugene Sajine wrote:
>
> > [something, but forgot to say whom he quoted:]
>
> > > %
> > > "To be fair, there are uses for XML. On Halloween, for example."
> > >
> > > - Johannes Schindelin, on git@vger.kernel.org
> > > %
> >
> > yeah, to show kids xml print outs as an answer to "trick or treat!".
> > Can save on candies;)
>
> Err, I think Dscho meant here that XML is so *scary*... Isn't it?
XML can be scary. Somebody on usenet once said something like: "XML is
just a skeleton; if you see a skeleton walking around, wouldn't you
be scared?"
What is really scary, though, is how many people really believe that just
using XML will magically solve all problems of this world. They really
believe that.
Ciao,
Dscho
^ permalink raw reply
* Script to convert git patches to Hg format
From: Mark Lodato @ 2009-10-11 22:56 UTC (permalink / raw)
To: git list
To make it easier to submit patches to a project using Hg, I wrote a
small script to convert the output of `git format-patch' to something
suitable for `hg import'. The latest version is available at:
http://github.com/MarkLodato/patch-converter
While `hg import' *can* read a git patch, it does not interpret the
date, and it includes the diffstat in the commit log. This script
fixes those problems.
The script worked well enough for me, but bugs may exist. If you have
ideas for improvement, patches are welcome :)
--
Mark
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-11 22:22 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091011191440.GA2532@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Oct 11, 2009 at 11:52:10AM -0700, Junio C Hamano wrote:
>
>> Thanks.
>>
>> The change looks innocent enough and I do not expect to see any unexpected
>> regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
>> queue this fix and aim for 1.6.5.1.
>
> I think this patch is good to apply, as there is no conceivable reason
> to even look at excludes when listing modified files.
>
> But this triggered my spider sense; shouldn't --exclude-standard simply
> be a no-op for ls-files when we are not listing untracked files? And
> bisecting, it seems that it is a very old regression caused by 63d285c
> (per-directory-exclude: lazily read .gitignore files, 2007-11-29).
>
> I don't know if it is worth fixing now or not. It does seem a bit
> inconsistent to me (since everything else is very clear that .gitignore
> is only about untracked files), but nobody seems to have been
> complaining for the last two years (and they may have, in fact, been
> coding to the new behavior).
This is one of those moments when I feel very blessed to have competent
and diligent people around me ;-)
I think you are right; that we shouldn't filter the output with gitignore
entries when showing what is _in_ the index.
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Jonathan Nieder @ 2009-10-11 22:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> So that users get to know how to configure git from the get-to with good
> practical example (color.ui = auto) that most people would probably like
> anyway.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Good idea. Some comments:
> +Git's configuration is distributed among different locations--this manual will
> +only to deal with 'global' (for the user) and 'repository' variables, where
> +'repository' variables take precedence over 'global' ones.
What are these different locations you speak of? If git’s configuration
is complicated to deal with, maybe that is something that could be
improved.
This is very early in the manual, where every word counts. I am not
very good at wording and do not have any better suggestions, but would
it be possible to more efficiently convey this:
Git reads its per-user configuration from ~/.gitignore.
That file can also be manipulated with the "git config"
command, which can be convenient in scripts or when using
operating systems like Windows where it is not clear where
the home directory is.
For example, if your terminal supports it, you can tell Git
to use color in the output for commands such as "git diff"
with "git config --global color.ui auto".
For more information and a list of possible settings, see
git-config(1).
By the way, this reminds me that I am not sure git-config(1) conveys the
list of configuration items in an ideal way. It can be easy to dismiss
that page as plumbing documentation when seeing it for the first time.
Should we ship a sample .gitconfig with all items included and comments
describing them, or a separate gitconfig(5)? Either would be easy to
generate from config.txt.
Thoughts?
Jonathan
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: eduard stefan @ 2009-10-11 21:12 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, msysgit
In-Reply-To: <be6fef0d0910101554p53d5532cp17768d2c95e9dbf@mail.gmail.com>
Tay Ray Chuan wrote:
> just to check, running
>
> echo list | git remote-curl http://github.com/loudej/spark.git
>
> and
>
> git clone http://github.com/loudej/spark.git
>
> both gives the same error message:
>
> An unhandled win32 exception occurred in git-remote-curl.exe [5820].
> Just-In-Time debugging this exception failed with the following
> error: No installed debugger has Just-In-Time debugging enabled. In
> Visual Studio, Just-In-Time debugging can be enabled from
> Tools/Options/Debugging/Just-In-Time.
>
> Check the documentation index for 'Just-in-time debugging, errors'
> for more information.
>
> in a dialog?
>
>> Is there any way to obtain more information from this crash?
>> Some debug mode?
>
> I'm assuming you're using the Microsoft Visual Studio development
> tools to compile git from the source. I'm cc'ing this to the msysgit
> mailing list, perhaps someone familiar with them can advise you
> further.
>
Git was compiled with msysGit, the errors are generated inside msysGit shell,
and VS2008 debugger gives this message:
"Unhandled exception at 0x00420354 in git-remote-curl.exe:
0xC0000005: Access violation reading location 0x00000000."
Have a nice day,
Eduard
^ permalink raw reply
* [PATCH] Documentation: add 'git replace' to main git manpage
From: SZEDER Gábor @ 2009-10-11 21:08 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
command-list.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/command-list.txt b/command-list.txt
index fb03a2e..59b0adc 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -92,6 +92,7 @@ git-reflog ancillarymanipulators
git-relink ancillarymanipulators
git-remote ancillarymanipulators
git-repack ancillarymanipulators
+git-replace ancillarymanipulators
git-repo-config ancillarymanipulators deprecated
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
--
1.6.5.85.g16dab
^ permalink raw reply related
* [ANN] gitsharp version 0.1.3 released
From: Meinrad Recheis @ 2009-10-11 21:10 UTC (permalink / raw)
To: git
Hello git community,
GitSharp intends to bring best native git support to Windows. So far
the command line interface is still alpha but the library
GitSharp.Core is already quite usable.
Status Report:
Porting of the jgit core is done, we are waiting for the jgit people
to commit something ;). Just kidding, we still need to port some code
from the jgit command line interface and we are working on a hand full
of porting bugs in the core. Some important bugs have been squashed
since the last release:
In a heroic debugging effort Nulltoken fixed the index-bug that made
git# incompatible to the original git. Now we are on track again.
Rolenun fixed git.exe which failed when started on windows via the
system %PATH%.
On top of that, there is a new user centric api which resides in
namespace Git. It simplifies interaction with git objects and
commands, hides the technical complexity of the core and should
provide a stable interface for your applications (once it is done).
The api is still work in progress, so please expect that it will be
changed / improved / extended, until everyone is happy with it. You
can see it in action in the repository browser demo at
http://github.com/henon/GitSharp.Demo
Have fun,
--Henon
^ permalink raw reply
* Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-10-11 20:56 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00910111353r20de1fb6u2289999491a9310a@mail.gmail.com>
On Sun, Oct 11, 2009 at 11:53 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> "Fix a bunch of pointer declarations".
>
> But in this patch you fixed *only* one pointer declaration:
> struct diffstat_t* data -> struct diffstat_t *data
Yeah, it's a remainder of a patch I sent some time ago. I don't know
why that didn't got picked up =/
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Thiago Farina @ 2009-10-11 20:53 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
"Fix a bunch of pointer declarations".
But in this patch you fixed *only* one pointer declaration:
struct diffstat_t* data -> struct diffstat_t *data
^ permalink raw reply
* [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-1-git-send-email-felipe.contreras@gmail.com>
Essentially; s/type* /type */ as per the coding guidelines.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index e1be189..b39c1b6 100644
--- a/diff.c
+++ b/diff.c
@@ -999,7 +999,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
total_files, adds, dels);
}
-static void show_shortstats(struct diffstat_t* data, struct diff_options *options)
+static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
{
int i, adds = 0, dels = 0, total_files = data->nr;
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..29d7b75 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 3/3] user-manual: use 'fast-forward'
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-3-git-send-email-felipe.contreras@gmail.com>
It's a compound word.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..42d92fd 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1384,7 +1384,7 @@ were merged.
However, if the current branch is a descendant of the other--so every
commit present in the one is already contained in the other--then git
-just performs a "fast forward"; the head of the current branch is moved
+just performs a "fast-forward"; the head of the current branch is moved
forward to point at the head of the merged-in branch, without any new
commits being created.
@@ -1719,7 +1719,7 @@ producing a default commit message documenting the branch and
repository that you pulled from.
(But note that no such commit will be created in the case of a
-<<fast-forwards,fast forward>>; instead, your branch will just be
+<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
The `git pull` command can also be given "." as the "remote" repository,
@@ -1943,7 +1943,7 @@ $ git push ssh://yourserver.com/~you/proj.git master
-------------------------------------------------
As with `git fetch`, `git push` will complain if this does not result in a
-<<fast-forwards,fast forward>>; see the following section for details on
+<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
Note that the target of a "push" is normally a
@@ -1976,7 +1976,7 @@ details.
What to do when a push fails
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If a push would not result in a <<fast-forwards,fast forward>> of the
+If a push would not result in a <<fast-forwards,fast-forward>> of the
remote branch, then it will fail with an error like:
-------------------------------------------------
@@ -2115,7 +2115,7 @@ $ git checkout release && git pull
Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
-changes git will simply do a "Fast forward" merge). Many people dislike
+changes git will simply do a fast-forward merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
doing this capriciously in the "release" branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
@@ -2729,9 +2729,9 @@ In the previous example, when updating an existing branch, "git fetch"
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
-commit. Git calls this process a <<fast-forwards,fast forward>>.
+commit. Git calls this process a <<fast-forwards,fast-forward>>.
-A fast forward looks something like this:
+A fast-forward looks something like this:
................................................
o--o--o--o <-- old head of the branch
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-1-git-send-email-felipe.contreras@gmail.com>
So that users get to know how to configure git from the get-to with good
practical example (color.ui = auto) that most people would probably like
anyway.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..ff2563a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -40,6 +40,33 @@ without any explanation.
Finally, see <<todo>> for ways that you can help make this manual more
complete.
+[[getting-started]]
+Getting started
+=============
+
+Git's configuration is distributed among different locations--this manual will
+only to deal with 'global' (for the user) and 'repository' variables, where
+'repository' variables take precedence over 'global' ones.
+
+You would probably want to start setting up something useful:
+------------------------------------------------
+$ git config --global color.ui auto
+------------------------------------------------
+
+This will make prettier the output of certain commands such as `git diff`, but
+that's not important; what is important here is that `color.ui` has been
+stored in the 'global' configuration.
+
+View and manually modify the configuration by opening `~/.gitconfig`:
+------------------------------------------------
+[color]
+ ui = auto
+------------------------------------------------
+
+Other locations are `/etc/gitconfig` (system), and `.git/config` (repository).
+
+More git configurations will be covered in the rest of the manual, if you want
+to learn more look at linkgit:git-config[1] for details.
[[repositories-and-branches]]
Repositories and Branches
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 0/3] Trivial patches
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
These are a bunch of no-brainers. The one for bool types has been discussed and
agreed before.
Felipe Contreras (3):
Fix a bunch of pointer declarations (codestyle)
git config: clarify bool types
user-manual: use 'fast-forward'
Documentation/user-manual.txt | 14 +++++++-------
builtin-config.c | 4 ++--
diff.c | 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 2/2] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
This is shorter, avoids the burder to think about the format of the
configuration file, and most guides out there prefer this form.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ff2563a..bab64f8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1008,13 +1008,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 0/2] user-manual: reorganize the configuration steps
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
This basically introduces the "getting started" section so users get familiar
with the configuration from the get-go, and also, most people prefer to teach
'git config --global' to setup the user name and email. Here are a few
examples:
git tutorial:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
GNOME:
http://live.gnome.org/Git/Developers
SourceForge:
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
github:
http://help.github.com/git-email-settings/
Felipe Contreras (2):
user-manual: add global config section
user-manual: simplify the user configuration
Documentation/user-manual.txt | 35 ++++++++++++++++++++++++++++++-----
1 files changed, 30 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: git log --graph
From: Jakub Narebski @ 2009-10-11 20:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sverre Rabbelier, Dilip M, git
In-Reply-To: <vpqhbu5zplr.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I personnally like the format of
>
> $ git log --graph --pretty=oneline --abbrev-commit
>
> with ui.color set to true in ~/.gitconfig.
You can use
$ git log --graph --oneline
nowadays for that. A bit shorter.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git log --graph
From: Matthieu Moy @ 2009-10-11 19:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dilip M, git
In-Reply-To: <fabb9a1e0910111135v4f3c75a7v6657f5dcfacf13ac@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
>> I am trying git log --graph. (has commits in two branches...). But
>> always see one line :(
>
> It'll show you the history of one branch at a time online, you won't
> get the demo-ed multiple lines unless the branch you're looking at
> contains merges.
That said, git log --graph --all will show multiple branches.
I personnally like the format of
git log --graph --pretty=oneline --abbrev-commit
with ui.color set to true in ~/.gitconfig.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox